I have come across a way to force the nested functions to use proxy. I suspected that the network handler for the nested functions is incorrectly interpreting a 403 forbidden response from the proxy as the PAC file being unreachable. By setting "ProxyPACFallbackAllowed" to False has prevented the nested requests from failing to use the proxy_resolver. Whilst we can set this in a profile for some managed wifi networks users that connect to networks without a profile will not have control over this setting.

I've tested the behaviour against http and https delivered PAC files and the behaviour is the produced in both cases. Additionally if a 403 response is not returned for the primary request in question then the nested requests don't appear to bypass proxy.

Can we expect any action to be taken around the additional issue this presents with regards to how iPadOS presents logging information. With the CFNetwork debug profile installed on a device the CFNetworkAgent will advise that the User-Agent Header will be enqueued as part of the request. Without looking at a packet capture collected from an iPadOS device is there any logging information exposed to advise that the user-agent string is not sent as part of the connect request.