Proxy latency test.

Compare WebSocket and TCP response times to look for delays associated with a proxy. Open this page in the browser or proxy profile you want to test.

HOW TO USE THIS TEST

How to use this tool

This test focuses on latency rather than download speed. Close busy downloads and keep the tab visible to reduce avoidable noise.

  1. 01

    Select the route you want to measure

    Open this page through your proxy, VPN, or direct connection. The test uses the current browser route.

  2. 02

    Collect three paired measurements

    Each connection sends five WebSocket pings and records its own server-side TCP baseline.

  3. 03

    Inspect the timing gap

    Expand the latency row to see all pings, the TCP RTT, and the difference in milliseconds and percent. Repeat on a direct connection for comparison.

READ THE MEASUREMENTS

What each result means.

WebSocket RTT

The elapsed time from sending an application ping in the browser to receiving its reply. It includes the complete route and application scheduling delays.

TCP RTT

The measurement server’s Linux kernel reports smoothed RTT on the same client TCP connection before application pings. This is not HTTP response time or an exact SYN-handshake measurement.

Gap and variability

The heuristic requires at least two stable connections, each with a gap of 50 ms or more and a 75% increase. Small baselines, incomplete samples, or large within-connection variation are inconclusive.

PROXY LATENCY TEST FAQ

Understand your results.

No single check proves whether a connection is direct. Read the signals together.

Does a large latency gap prove I am using a proxy?

No. It can suggest an intermediary that splits TCP connections, but browser scheduling, changing network conditions, and other delays can contribute. Thresholds are provisional heuristics, not a calibrated probability.

Why use the same connection for both measurements?

A rotating proxy can select a different exit for each connection. Pairing measurements on one connection avoids comparing a WebSocket route with an unrelated TCP route.

Is this the same as an HTTP speed test?

No. HTTP response time can include DNS, connection setup, TLS, server processing, and transfer time. This test measures WebSocket ping round trips and a TCP RTT baseline, not bandwidth or page-loading speed.

Why might the TCP RTT be unavailable?

The measurement requires a reachable Linux Nginx measurement endpoint with usable client TCP socket data. Missing probe configuration, unsupported server platforms, or failed connections leave the result unavailable.