@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/

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

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.

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 decided to file a radar (FB9650785) for this one, as it seems to behave incorrectly.

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?

A quick update on this - I haven't received any official feedback on radar 37609606.

(posted at the end of the thread)

We're seeing a similar issue in another app. This appears to be happening on iOS 13 and iOS 14 only. Before we send data, we check the state of NWUDPSession (we expect it to be "ready" and viable): func send(_ datagram: Data) -> Void { 				queuedDatagrams.append(datagram) 				guard let currentSession = session else { 						Log.info("cannot send packet; session does not exist") 						return 				} 				guard currentSession.state == .ready, currentSession.isViable else { 						Log.info("\(address(of: currentSession)) cannot send packet; state: \(currentSession.state), viable: \(currentSession.isViable)") 						return 				} 				currentSession.writeMultipleDatagrams(queuedDatagrams) { [weak self] (error) in 						Log.error(error) 						if let error = error { 								self?.handleError(error) 						} 				} 				queuedDatagrams = [] 		} but even with this check, we're still seeing this crash happen a lot.