Browsers
Current Chrome, Firefox, and Safari stable releases
Original route evidence
An anonymized four-run browser route case series comparing direct, Cloudflare WARP, and browser-proxy paths across IPv4, IPv6, WebRTC, and DNS signals.
These observations came from one user-reported test sequence. Browser and operating-system versions were not recorded, the network routes were not independently controlled in a lab, and unavailable DNS evidence was retained. The data can illustrate route separation; it cannot estimate browser or provider failure rates.
Anonymized observations
Raw IPs, resolver addresses, cities, coordinates, ISPs, and ASNs were removed. Evidence descriptions preserve only the relationship between the intended and observed routes.
| Case | Route under test | HTTP families | WebRTC | DNS | Overall | Qualified conclusion |
|---|---|---|---|---|---|---|
| TP-RCS-20260718-01 | Direct connection WARP off · browser proxy off | IPv4 only | No Indicator Completed WebRTC gathering exposed no unexpected public route in this run. | Review Two public resolver observations were geolocated outside the visible-route country; this remained ambiguous because public DNS and anycast can create legitimate mismatches. | Inconclusive | This run was useful as a user-asserted direct baseline, but the DNS geography difference was not treated as proof of a leak. |
| TP-RCS-20260718-02 | Cloudflare WARP WARP on · browser proxy off | IPv4 and IPv6 | Review WebRTC exposed a different public IPv6 address from the same named network provider as the HTTP-visible route. Without a direct-baseline match or verified different network, this remained Review. | No Indicator The detected resolver location was consistent with the WARP-visible route in this sample. | Inconclusive | The alternate WebRTC address required review, but the available same-provider evidence did not verify a route leak. |
| TP-RCS-20260718-03 | Browser proxy layered over WARP WARP on · browser proxy on | IPv6 only | Leak The browser proxy changed the HTTP-visible route, while WebRTC exposed the WARP public IPv4 and IPv6 paths outside that proxy route. | Unavailable No authoritative resolver evidence was returned, so the DNS channel was not cleared or failed. | Leak | The browser proxy did not isolate the WebRTC path from the underlying WARP route in this run. |
| TP-RCS-20260718-04 | Browser proxy without WARP WARP off · browser proxy on | IPv6 only | Leak The browser proxy changed the HTTP-visible route, while WebRTC exposed the direct public IPv4 baseline outside that route. | Unavailable No authoritative resolver evidence was returned, so the DNS channel remained unknown. | Leak | Removing WARP changed which underlying route WebRTC exposed, but did not make the browser proxy a full-device isolation boundary. |
Methodology
The method is intentionally narrow so readers can distinguish recorded evidence from future benchmark plans.
The user ran the browser test directly, with WARP, with a browser proxy layered over WARP, and with the browser proxy after WARP was removed.
Timeouts and missing DNS callbacks were not converted into No Indicator. Each channel retained the status shown by the test.
Public IPs, resolver addresses, country/city labels, coordinates, ISPs, organizations, and ASNs were removed from the published rows.
The dataset records whether a route looked direct, WARP-based, or browser-proxied and whether WebRTC exposed a route outside the HTTP-visible path.
Next research release
These are protocol requirements for a future release, not completed measurements. No result or failure rate is implied.
Current Chrome, Firefox, and Safari stable releases
Current macOS, Windows, Linux, iOS, and Android releases where automation is reproducible
Direct, HTTP proxy, SOCKS5 with local DNS, SOCKS5 with remote DNS, WARP, and full-device VPN
IPv4-only, IPv6-only, and dual-stack networks
At least five completed runs per cell, with failures and unavailable evidence retained
Reuse and attribution
The dataset is available under Creative Commons Attribution 4.0. Attribute “TrueProxies Browser IP Leak Route Case Series, July 18, 2026” and link to this page. Do not present the four observations as browser market statistics or provider failure rates.
Apply the method
Capture IPv4, IPv6, WebRTC, and DNS evidence in one run.
Open resourceInterpret completed ICE evidence and browser proxy bypass.
Open resourceAvoid resolver-geography false positives.
Open resourceCompare application-scoped and device-scoped routing.
Open resource