Hi, I'm seeing the same thing. Is there a way to make sure that the connection is never made directly? So if the proxy is down, the connection is actually dropped instead of being made directly?

I've decided to file a radar (FB9650785) for this one, as it seems to behave incorrectly.

Using NEAppProxyProvider would work only for supervised devices, which is a major limitation. What if the proxy (or proxies) reside on an IP destination(s) that are routed through the tunnel set up using the VPN APIs? So there's an active VPN tunnel and we have cache/filtering proxy on the remote network that should be always used for certain connections.

I've raised this issue in radar 9650785 and I believe this is an incorrect behavior of the OS. @Quinn: I understand your point, but the PAC standard is pretty explicit in these terms, and the current way iOS is handling it is not in line with what is expected by sys admins and also works differently than essentially all other browsers and operating systems I know of. It should be up to the PAC author to decide how the connection behaves when the proxy fails. If I want the request to work at all cost and skip the proxy when it's offline: findProxyForURL() returns "PROXY X.Y.Z; DIRECT". If I want it to fail when X.Y.Z isn't working, findProxyForURL() returns "PROXY X.Y.Z". I don't see why iOS changed the behavior to assume "DIRECT" to be a default fallback for every connection.

Thanks @meaton. And what if an app is using NWParameters.PrivacyContext to require encrypted DNS while Network Extension uses Do53?

@eskimo, @meaton any realistic chance this will get fixed in iOS 16? I've raised this issue through Feedback Assistant almost a year ago (24 Sep 2021) in rdar 9650785, with no success or actually any definitive answer. I still have users affected by this and complaining with no real way to provide a meaningful answer. IMO this doesn't fall far from the VPN issue https://protonvpn.com/blog/apple-ios-vulnerability-disclosure/