Network and leak prevention
How proxy-derived alignment, WebRTC candidate control, QUIC tunnelling and remote DNS keep the network half of an identity coherent.
An identity has two halves. The device half comes from the profile bundle; the network half comes from the proxy. This page covers the network half — what VeilBrowser derives from the exit IP automatically, and what it does to stop traffic escaping around the proxy.
Proxy-derived alignment
VeilBrowser does not just route a profile's traffic through its proxy. It hands the proxy to the browser as the browser's own proxy setting, which means the browser resolves the exit IP's region itself. At launch, these follow the exit IP:
| Signal | Behaviour |
|---|---|
| Timezone | Set to the exit IP's zone |
| Locale | Set to the exit IP's region |
Accept-Language | Language list matches that locale |
| Geolocation | The position reported to the Geolocation API matches the exit region |
There is nothing to configure. Assign a proxy to the profile and the region-dependent signals agree with it on every launch, including after you swap the proxy for one in a different country.
Alignment needs a proxy on the profile
With no proxy assigned there is no exit IP to read, so the host's own network position applies. A profile that must present a specific region needs a proxy in that region.
WebRTC leak prevention
WebRTC is the classic way a proxied browser gives itself away. To negotiate a peer connection the browser gathers ICE candidates: host candidates taken from the machine's own network interfaces, and server-reflexive candidates discovered by asking a STUN server what public address the traffic appears to come from. Both paths are independent of the HTTP proxy. A site that opens a data channel and reads the resulting SDP can see the real LAN address and the real public IP of the host, no matter what the page's HTTP requests went through.
VeilBrowser controls SDP and ICE so the candidate set reflects the proxy route rather than the host. The public candidate a site observes is the proxy's, and it agrees with the IP the site sees on the connection itself.
An empty candidate set is its own tell
Blocking WebRTC outright is easy and detectable — real browsers have it, and a site that gets no candidates at all learns something specific about you. The goal is a coherent candidate set consistent with the proxy route, not a missing one.
QUIC and STUN over SOCKS5
WebRTC and QUIC both use UDP, and UDP does not travel over an HTTP proxy. Left alone, those paths bypass the proxy entirely and carry the host's real network position with them. VeilBrowser tunnels QUIC and STUN traffic over SOCKS5 so the geo metadata they expose stays on the proxy route with the rest of the session. This is one of the reasons to prefer a SOCKS5 proxy over an HTTP one when the profile matters.
DNS resolution
DNS is the remaining path that can leak around a correctly proxied session.
socks5hresolves hostnames at the proxy. The lookup happens at the exit, so it shares the route and the region of the traffic it belongs to.socks5resolves hostnames on the worker host. Anyone able to correlate DNS with traffic sees your real resolver and, with it, your real network position.
Prefer socks5h unless you have a specific reason not to. See
Proxies for the full protocol list and the assignment syntax.
Verify it yourself
Confirm the two halves agree before you scale an operation.
Launch a profile with a proxy
Use a proxy whose exit region is clearly different from the worker host's, so a failure is obvious rather than subtle.
Open a fingerprint and leak test page
Any page that reports IP, timezone, locale, geolocation and WebRTC candidates together will do. Reading them on one page matters more than which page you pick, because you are checking that they agree with each other.
Check the four readings against the exit IP
The reported timezone, locale, geolocation and public WebRTC candidate should all point
at the exit IP's region. If DNS is also reported, it should resolve at the proxy when
the profile uses socks5h.
Relaunch and compare
Stop the session and launch the same profile again. The device signals should be identical and the network signals should still agree with the exit IP. That combination — stable device, coherent route — is what the platform is for.
Next steps
- Proxies — protocols, assignment and provider choice.
- Fingerprints — the device half of an identity.
- WebRTC leaks and proxy consistency — background on the leak itself.