A technique for detecting residential proxies without blacklisting IP addresses surfaced on Hacker News this week, and its core insight is surprisingly simple. Most residential proxy services do not support UDP, but WebRTC, which is built into every major browser, requires it. By comparing a client's TCP and UDP IP addresses, you can identify proxy usage with high accuracy while leaving legitimate users on the same IP untouched.
Why Residential Proxies Are Hard to Block
Residential proxy services route traffic through real consumer IP addresses, making traditional IP-based blocking ineffective. A legitimate user and a proxy client can appear to come from the same IP address, which means blacklisting that IP punishes innocent users alongside bad actors. Services like MaxMind and NetAcuity maintain IP reputation lists, but these are blunt instruments. They block entire IP ranges, not specific connections exhibiting proxy behavior.
The proxy industry knows this and has adapted. Providers like BrightData, Soax, and OxyLabs operate large pools of residential IPs, and their clients are trained to disable WebRTC to prevent IP leakage. WebRTC, the browser API that enables real-time communication like video calls and peer-to-peer connections, has been part of browsers since 2021. It uses UDP for its transport, and it exposes the client's true IP address through STUN protocol requests. The security community learned this the hard way in the mid-2010s, and disabling WebRTC became standard practice for anyone trying to hide their real IP.
That widespread disabling of WebRTC is what makes the detection technique work. If someone claims to be using Chrome, Firefox, or Safari, WebRTC should be available. If their UDP address differs from their TCP address in ways that do not match normal network behavior, something is intercepting the connection.
The TCP-UDP Comparison Method
The technique requires two pieces of information: the client's TCP IP address and their UDP IP address. The TCP address is straightforward to obtain through a standard HTTPS connection. The UDP address requires running a STUN server, which the client contacts via WebRTC to discover its public IP.
The STUN server should encrypt the returned address to prevent tampering. One practical approach is to encode the IPv4 address and additional metadata into an IPv6 ICE candidate, which the client processes normally. This keeps the detection logic server-side and avoids introducing communication bottlenecks.
Once you have both addresses, the comparison follows a simple decision tree:
- If the TCP and UDP IP addresses are the same, the client is probably not using a residential proxy. Both connections took the same path to the internet.
- If the addresses differ but belong to the same ASN and fall within the same /24 subnet, the client is likely on a cellular network. Mobile carriers frequently assign different IPs to different connection types.
- If the addresses are on different ASNs, that is a strong indicator of proxy usage. The TCP traffic is taking a different path than the UDP traffic, which is exactly what a residential proxy does.
- If one address resolves to a corporate security service like Cisco Web Umbrella or Zscaler, the client is behind an enterprise firewall. This is not proxy usage in the criminal sense, and depending on your threat model, you may want to whitelist these connections.
The TLS-RTT Ratio: Detection Without UDP
The more interesting case is when UDP is unavailable. Many environments block UDP entirely, or the client has disabled WebRTC. In these situations, the technique falls back to measuring the ratio between TLS handshake duration and TCP round-trip time.
The logic works like this: residential proxies typically split the connection at the exit point. The origin server's TCP socket terminates at the proxy exit node, so TCP round-trip time measurements reflect only the latency between the server and the exit. However, the TLS handshake bytes must travel from the exit all the way to the true client and back, making the TLS handshake duration include the hidden proxy chain's latency.
A normal direct connection has a TLS-duration-to-TCP-RTT ratio below 3.0. A residential proxy connection typically produces a ratio between 6 and 12, because the TLS handshake traverses the full proxy chain while the TCP RTT only measures the server-to-exit segment. This gap is the proxy's signature.
The combined decision logic becomes:
- TCP equals UDP: not a proxy
- TCP approximately equals UDP, same ASN: cellular network, not a proxy
- TCP differs from UDP: proxy or enterprise firewall
- Only TCP available, ratio below 3: probably not a proxy
- Only TCP available, ratio above 3: probably a proxy
What Makes This Different From IP Reputation Lists
The critical advantage of this approach is surgical precision. A legitimate user and a proxy client coming from the same IP address will behave differently under this test. The legitimate user's TCP and UDP addresses will match, or their TLS-RTT ratio will be normal. The proxy client's addresses will diverge, or their ratio will be inflated. You block the proxy connection without affecting the legitimate user on the same IP.
This is a behavioral detection method, not a reputation-based one. It does not depend on maintaining lists of known proxy IPs, which go stale quickly as providers rotate their pools. It does not depend on third-party intelligence feeds. It measures the actual characteristics of the connection and makes a determination based on how the traffic behaves.
Limitations and Practical Considerations
The technique is not foolproof. Corporate firewalls that terminate TLS at the edge can produce similar TLS-RTT ratios to residential proxies, leading to false positives. These connections can be whitelisted based on ASN or other signals, but it requires tuning for your specific environment.
Cellular networks produce different IPs for TCP and UDP, which can mimic proxy behavior. The ASN and subnet comparison handles most of these cases, but edge cases exist. Network address translation, IPv6 transitions, and multi-homed connections can all produce IP divergence without proxy involvement.
The method also requires running your own STUN server, which adds operational complexity. The server needs to be accessible to clients, handle the encryption of returned addresses, and integrate with your detection pipeline. For organizations already running WebRTC infrastructure, this is incremental. For others, it is a new dependency.
The Hacker News poster reported testing the technique against BrightData, Soax, and OxyLabs proxies over six months, and also tested it against their own Android-based proxy device on their home network. The results were consistently accurate across these providers. The technique caught their own proxy setup, which is a strong signal that it works against real-world residential proxy implementations.
Implications for Platform Security
For platforms dealing with automated abuse, scraping, account farming, or fraud, this technique offers a detection layer that does not require sacrificing legitimate users. The arms race between proxy providers and detection systems has largely been a contest of IP lists and reputation scores. Behavioral detection based on connection characteristics is a different axis of defense, and it is one that proxy providers cannot easily circumvent without fundamentally changing how their infrastructure works.
The approach is开源 and available for testing. For teams dealing with proxy-driven abuse, it is worth evaluating alongside existing detection methods. No single technique catches everything, but combining behavioral detection with reputation-based blocking and rate limiting creates a more resilient defense than any one approach alone.