Blog / IP & privacy

How Websites Detect Proxies by Latency: TCP vs Browser RTT

2026-10-20cdnping editors8 min read

Sites that use latency for proxy detection rely on two timings from the same visit that don't line up. The round-trip time the server measures on the TCP connection covers only one leg: proxy exit to server. The round-trip time measured by a script in the page covers the full path from your device to the server. On a direct connection the two are close. With a relay in the middle, the second is noticeably larger than the first. This is a probabilistic signal. It is normally read together with IP type, DNS, time zone and other clues, and on its own it proves nothing.

This article is a privacy explainer to help you understand how your network looks from the other side. It does not cover bypassing any platform's detection or risk controls. Follow the terms of service of the services you use and your local laws.

#Which latency can the server measure?

A TCP connection starts with a three-way handshake: the client sends SYN, the server replies SYN-ACK, and the client answers with ACK. The interval between the server sending SYN-ACK and receiving ACK is one round-trip time (RTT). During the rest of the transfer, the kernel keeps updating its RTT estimate from acknowledgements.

What matters is who sits on the other end of that TCP connection:

• On a direct connection, the other end is your computer or phone, so the server measures the round trip between you and it.
• Through a proxy, the proxy exit opens the TCP connection, so the server measures the round trip between the proxy exit and itself. The leg from your device to the proxy is invisible at the TCP layer.

Many CDNs and edge platforms expose this value to application code. For example, the request object in Cloudflare Workers has a client TCP RTT field (request.cf.clientTcpRtt, see the Cloudflare docs). A site doesn't need to capture packets itself to learn how far away the connecting IP is.

#What can the browser measure?

Once the page has loaded, a script can time things itself: send a few small requests (fetch or WebSocket messages), record the time from send to response, and take the median. This is an application-layer round trip, and its path looks like this:

Your device → local network → proxy entry → proxy exit → server → back the same way

It includes the leg the TCP layer can't see, plus some application-layer overhead: browser scheduling, TLS record processing, and the forwarding time of the proxy software itself.

So the site ends up with two numbers:

#Why does a relay widen the gap?

Take an example (numbers are illustrative only). You are in Shanghai, the proxy exit is on the US West Coast, and the server's edge node is also on the US West Coast.

• The server's TCP layer sees the exit and the edge node in the same city, so the round trip is only a few milliseconds.
• The browser's application layer sees data going from Shanghai across the Pacific to the exit, then on to the server, for a round trip of one to two hundred milliseconds.

A few milliseconds against one or two hundred can't be explained by application-layer overhead. On a direct connection, both measurements cover the same path, and the difference usually comes only from extra browser and TLS processing, which is far smaller.

Physics is behind this. Light travels roughly 200 km per millisecond in fiber, and real routes add detours and router queuing. If an IP claims to be in a certain city but the browser-measured round trip is far beyond what is plausible between that city and the server, the data is taking an extra leg somewhere else.

Some sites also run the calculation in reverse: knowing the exit IP's geolocation, they use the application-layer round trip to estimate roughly how far the real device is from the server. The data only draws a rough circle, but if that circle is far from where the IP claims to be, that is a red flag too.

#Does a latency gap always mean a proxy?

No. All of the following inflate the application-layer round trip and are common sources of false positives:

• Mobile networks and weak Wi-Fi: Radio retransmissions and handovers make application-layer round trips jittery, while the initial TCP handshake may happen to be measured at a quiet moment.
• Bufferbloat: When someone at home is downloading a large file, the router queue fills up and application-layer requests wait longer.
• Corporate gateways and security software: A transparent proxy at the company egress or HTTPS inspection by antivirus software is itself a relay and produces proxy-like traces, even though the user isn't "using a proxy".
• Satellite links and remote regions: The baseline round trip is already large.
• Background throttling in the browser: When the page is in a background tab, timers and network requests may be slowed down, so the measured values are off.

This is why careful detectors measure several times, take the median, and treat the latency gap as one weighted signal rather than banning on it alone. It is also why the same network can get different verdicts on different sites, for the same reasons as in why IP purity checkers disagree: samples, thresholds and weights all differ.

#What other signals does proxy detection look at?

Latency is only one category. In practice, proxy detection stacks several kinds of signals.

#Properties of the IP itself

• IP type and ASN: Whether the exit belongs to a cloud provider or hosting data center, or to home broadband or a mobile network. Data center ranges are naturally more likely to be flagged as "possibly a proxy". See datacenter IP vs residential IP.
• Reputation records: Whether the IP appears in public proxy lists, Tor exit lists or DNS blocklists. cdnping's /en/ip aggregates 14 reputation sources and publishes the weight of each hit. For how the score is computed, see how IP purity score works.

#Network-layer traits

• TCP/IP stack fingerprint: TTL, window size and option order in the SYN packet reveal operating system traits. If the browser User-Agent says Windows but the TCP fingerprint looks like a Linux server, the connection may have been initiated by a different machine. cdnping's /en/ip includes a "kernel version inference" item (23 features) that you can compare with the OS your browser reports.
• Small MSS/MTU: Tunneling protocols add encapsulation headers, which leaves less room for data, so the MSS advertised in the handshake is often lower than typical Ethernet values.
• Inconsistent exits: The same browser shows different exit IPs on different sites, or IPv4 and IPv6 take different paths. For dual-stack details, see IPv6 proxy not working.

#Leak signals

• DNS leaks: Which resolver sends the DNS queries triggered from a web page, and whether it is in the same country or network as the exit IP.
• WebRTC leaks: The local or public address a browser exposes through STUN differs from the HTTP exit. For the mechanism, see /en/learn/dns-leak-webrtc-leak. For the relevant browser settings, see how to turn off WebRTC leaks.

#Environment consistency

• Time zone, language, fonts: A system time zone that doesn't match the IP's location, or a language list that doesn't fit the region, means little by itself but carries more weight when several mismatches stack up. Each item is explained in browser fingerprint and environment checks.

One more case is specific to China: Chinese sites can use their own CDNs to see your client IP when you access domestic resources, and comparing it with the exit used for overseas resources reveals whether your traffic is split. This is covered separately in how Chinese sites see your real IP.

#How do you check this yourself?

The steps below are only for understanding your own network. They involve no bypass techniques.

#Step 1: Check the latency trait on cdnping

Open /en/ip and find the "latency trait" item. It does exactly the comparison described in this article: the round trip measured in your browser is shown next to the exit TCP round trip measured by Cloudflare at the edge. When reading the result, keep three things in mind:

1. What the two numbers are, and roughly how big the difference is.
2. Keep the page in the foreground and don't run downloads at the same time. If needed, refresh two or three times and see whether the conclusion stays stable.
3. Read it together with the IP type, DNS leak and WebRTC results on the same page, rather than looking at this item alone.

The measurement method and data handling are described at /en/methodology.

#Step 2: Use curl to see rough timings by connection phase

Run this in a terminal:

curl -o /dev/null -s -w 'dns: %{time_namelookup}s\ntcp: %{time_connect}s\ntls: %{time_appconnect}s\nttfb: %{time_starttransfer}s\n' https://cdnping.org/

• tcp minus dns is roughly the one TCP round trip your own machine sees.
• If a proxy is configured at the system level, curl may read the https_proxy environment variable by default. In that case the TCP handshake is with the proxy, so the tcp value will be very small, while tls and ttfb reflect the full path. This is a direct way to see how "who is at the other end of the connection" determines what you measure.

To go further into the difference between connection setup, gateway round trip and first-token time, see AI API latency breakdown.

#Step 3: Interpret the result with this table

#Limits of latency detection

A latency comparison answers one question: how close is the connecting IP to the server, how far are you from the server, and do the two distances match? It relies purely on timing and reads nothing from your local machine, so there is no switch at the page level to turn it off. It is also heavily affected by network quality, with plenty of false-positive scenarios.

When you troubleshoot "a site thinks my network environment is abnormal", look at IP attributes, leaks, environment consistency and latency together. For a complete self-check sequence, see the developer network self-check checklist (2026).