KalkanProxy detection and leaks: WebRTC, DNS, UDP/QUIC and time zone
Entering a proxy is only the first step in changing your network identity. The browser can still give away your real location through protocols that bypass the proxy or settings that contradict the IP. This guide covers the most common leaks, how to test for them and how they are closed.
How do sites tell you are using a proxy?
A site always sees the IP address your connection comes from. Behind a proxy, that is the proxy's exit address. But a site does not look at the IP alone: it considers the type of IP (home connection, data centre or mobile carrier), whether it appears on known proxy lists and, above all, whether it is consistent with what the browser says. The proxy itself may be fine; the problem is your real IP or location leaking through another channel.
Proxy types in brief
- HTTP/HTTPS proxy: carries web traffic through a
CONNECTtunnel. TCP only. - SOCKS5 proxy: a more general tunnel. The protocol defines UDP too, but many providers do not support it; in practice most SOCKS5 proxies carry TCP only.
- Data centre, residential and mobile IPs: technically they work the same way; the difference is who the IP appears to belong to.
The key point: your proxy very likely does not carry UDP. Whenever the browser tries something that uses UDP, it has to block that traffic or at least never send it directly, outside the proxy. That is exactly where most leaks begin.
The most common leaks
WebRTC leaks
WebRTC powers video calls and peer-to-peer connections. While connecting, it sends requests over UDP to STUN servers to learn your public IP and offers it to the page as an “ICE candidate”. If the browser sends that request outside the proxy, the site's own STUN server sees your real IP instead of the proxy's. Turning WebRTC off entirely is no solution either; a Chrome without WebRTC is an unusual Chrome. The right approach is to keep WebRTC on, make it work only through the proxy, and block non-proxied UDP.
DNS leaks
Before a site is visited, its domain name has to be resolved to an IP address. If that lookup happens at your computer's own DNS server instead of through the proxy, your internet provider sees which sites you visit. Sites can also learn which DNS resolver you use by making you look up a unique subdomain of theirs. An IP in Germany with a DNS resolver in Turkey is an obvious contradiction.
UDP, QUIC and HTTP/3
HTTP/3 uses QUIC, which runs over UDP; so does WebTransport. A proxy that carries TCP cannot forward that traffic. A misconfigured browser may try QUIC directly, bypassing the proxy, or act as if UDP were available when it is not, which creates a contradiction. The correct behaviour behind a proxy is that QUIC never bypasses it and requests that would need UDP fall back to TCP in a controlled way.
Time zone and language mismatch
Technically not a “leak”, but the most common inconsistency. If your IP says London, your browser's clock says Istanbul and the language list says Turkish, a site notices easily. Time zone, language and geolocation should follow the proxy's exit country.
Proxy headers
Some proxies add headers such as Via, X-Forwarded-For or Forwarded to requests. These state outright that a proxy is in use and sometimes even contain the real IP. Good proxies do not add them, but you need to test to be sure.
TCP/IP and operating system consistency
Every operating system builds TCP packets slightly differently (initial TTL, window size, option order). A system watching passively can guess whether a connection comes from Linux or Windows. If the proxy server runs Linux and the browser claims to be Windows, that is a small contradiction. This is not entirely in the browser's hands; it is a factor in choosing your proxies.
How to test for leaks
- Open the profile with its proxy and first confirm on an IP-checking site that the exit address is the proxy's.
- In a WebRTC test such as BrowserLeaks' WebRTC page, check that your real IP is not among the candidates.
- Use a DNS leak test to confirm the resolvers are in the proxy's country.
- Check that time zone and language match the IP.
- Deliberately take the proxy down and confirm the browser does not continue on your real connection and traffic stops instead. This is the kill-switch test.
Running these by hand for every profile takes time, which is why a browser that can run them itself is a big help.
How Kalkan closes these leaks
In Kalkan each profile's traffic goes through a local SOCKS5 tunnel; the browser never sees the proxy password and no proxy headers are added to requests. Non-proxied UDP is blocked: WebRTC stays on but never shows your real IP, and QUIC/HTTP3 and WebTransport cannot bypass the proxy. DNS lookups go through the proxy over DNS-over-HTTPS, calibrated to the exit country. If the proxy dies the connection stops; it never falls back to your real IP.
When you import proxies in bulk, Kalkan tests each one, finds its country and sets the profile's time zone, language and location to match. The app's diagnostics check WebRTC, DNS, HTTP IP, time zone, language, HTTP/3, WebTransport, TCP/IP, TLS and proxy headers using the same methods sites use. For step-by-step proxy setup, see the proxy guide.
Conclusion
A good proxy is necessary but not sufficient. WebRTC, DNS and UDP/QUIC traffic must leave through the proxy, time zone and language must match the IP, and traffic must stop when the proxy drops. The network identity forms a whole with the device fingerprint; if either leaks, the work on the other is wasted. Download Kalkan to test it with your own proxies, or compare the plans on the pricing page.