Bug 316948 – WKWebsiteDataStore reuses its connection pool after proxyConfigurations change, bypassing the proxy

• Status: NEW
• Component: Website Storage

Created attachment 480074 [details]
Demo project showcasing the issue

Summary

Assigning proxyConfigurations to a WKWebsiteDataStore that is already in use (e.g. the default store) does not take effect for hosts the network process has already opened connections to. The proxy is applied only to hosts that have no pooled connection yet. Tearing down and recreating the WKWebView on the same data store does not resolve this — the connection pool appears to be tied to the data store, not the web view, so a subsequent load reuses the existing (direct) socket and bypasses the newly configured proxy.

Steps to reproduce

1. Create a WKWebView whose configuration uses WKWebsiteDataStore.default(), and load a page that reports the client's IP (e.g. whatismyip.com).
2. Set proxyConfigurations on that same data store.
3. Recreate the WKWebView (new WKWebViewConfiguration, same default data store) and issue a fresh load(URLRequest:) for the same URL.

Expected result

The load is routed through the configured proxy, and the reported IP reflects the proxy.

Actual result

The reported IP is unchanged — the request continues to use the pre-existing direct connection and bypasses the proxy. Notably, navigating to a different IP-reporting host (one with no pooled connection) does route through the proxy correctly, which points to per-host connection-pool reuse keyed to the data store.

Workaround

The proxy only takes effect for all hosts if a brand-new WKWebsiteDataStore is created with the proxyConfigurations already set, and the WKWebView is hosted on that fresh store. Setting the proxy on an existing store — even with a recreated web view and a fresh load(URLRequest:) — is not sufficient.

Attached

A minimal demo project reproducing the issue. It uses a tiny local HTTP server that reports a fake IP derived from the serving TCP connection, so connection-pool reuse is directly observable: enabling the proxy on the existing default store leaves the IP unchanged, while enabling it on a freshly created store yields a new connection (and IP).

Environment

- Reproduced on iOS/iPadOS 26.2 and iOS 18.
- Loads issued via a fresh load(URLRequest:) on a recreated WKWebView.