Work from the actual client
Record the chosen interface and route before interpreting any result. A connected wireless interface does not guarantee that a destination uses it when a wired default route also exists. Also record whether the test honors environment proxy settings. A successful request through a pre-existing proxy is not a direct-path test.
Separate the milestones
Resolve the exact name, attempt the intended transport, validate TLS identity, authenticate the application and check an actual response. Each step eliminates a different class of fault. A port listener alone cannot establish external reachability; a latency check for a proxy node does not establish that a browser's routing rules select that node.
Change one variable
Use the same client, endpoint and small response when comparing two paths. Repeat measurements and retain failures. If a later run succeeds, report the earlier failures as well rather than inventing a single explanation that the data does not support. Only move on to throughput testing after reachability, authentication and route selection are established.
At the terminal
ip route get 192.0.2.10
curl --noproxy '*' -o /dev/null -sS \
-w 'TCP=%{time_connect} TLS=%{time_appconnect} TTFB=%{time_starttransfer} HTTP=%{http_code}\n' \
https://example.com/