We are implementing a Network Extension that uses NETransparentProxyProvider. For browser TCP flows we terminate in the extension and re‑originate traffic with NWConnection.
Per documentation, we set NWParameters.preferNoProxies = true on that NWConnection so it should not use the system HTTP/HTTPS proxy configuration, including PAC‑selected explicit proxies.
Observation: With System Settings → Network → Proxies → Automatic proxy configuration pointing at a PAC file that returns something like PROXY 127.0.0.1:8888 for relevant traffic, we still see our NWConnection traffic show up at the local explicit proxy as a normal CONNECT host:443 tunnel. That suggests PAC / explicit proxy selection is still being applied to sockets we believed were opted out via preferNoProxies.
This is affecting interoperability: the browser may evaluate PAC with a hostname (e.g. a site configured as DIRECT), while a separate NWConnection may be evaluated in a context where the logical host is an IPv4 literal, so the same PAC script can return PROXY for what the user thinks is the “same” destination. We had expected preferNoProxies to remove the second leg from PAC/proxy entirely.
Expected: NWConnection with preferNoProxies == true should connect without opening an explicit CONNECT session to the PAC‑configured proxy (unless there is documented behavior that NE‑originated traffic is intentionally exempt from this flag).
Actual: Traffic from the NWConnection path still reaches the explicit proxy (we can log CONNECT … on a minimal local proxy).
Environment: macOS Tahoe 26.5 (25F71), Network Extension / App Proxy provider, PAC served over local http, Safari as client.
Questions:
Is preferNoProxies guaranteed to bypass PAC‑selected explicit proxies for NWConnection from Network Extension processes, or are there known exceptions (e.g. certain interfaces, MDM, networkserviceproxy, etc.)?
If this is by design, what is the supported way for an NE to open an outbound TCP connection that must not inherit system PAC/proxy?