You can use the Network Extension framework with a custom PacketTunnelProvider to control when a VPN can connect. By checking whether your app is in the foreground, you can allow or block the VPN connection programmatically.: class PacketTunnelProvider: OpenVPNTunnelProvider { override func startTunnel(options: [String : NSObject]? = nil, completionHandler: @escaping (Error?) -> Void) { let userDefaults = UserDefaults(suiteName: "group.com.example.vpnapp") let isAppInForeground = userDefaults?.bool(forKey: "isAppInForeground") ?? false if isAppInForeground { super.startTunnel(options: options, completionHandler: completionHandler) } else { let error = NSError(domain: "com.herond.browser", code: 1, userInfo: [ NSLocalizedDescriptionKey: "The app is not in the foreground. VPN cannot be started." ]) completionHandler(error) } } }

Yes, I checked on my side, and the behavior is as you described. Thank you. I see that the CONNECT request does not include the authentication information: "Proxy-Authorization: Basic xxxxxxxx\r\n" even though I added applyCredential: proxyConfig.applyCredential(username: "xxx", password: "xxx") I think this is the cause of my issue, making WKWebView unable to connect through the proxy server. Could this be related to an issue with applyCredential? It seems to be mentioned here: https://developer.apple.com/forums/thread/734679 I'm using Xcode 15.2 on macOS 14.3 targeting iOS 17.2.

I am not sure if it is related to https://developer.apple.com/forums/thread/734679 or not

Thanks for your support! Are you sure you got that the right way around? I have set up a local proxy server using Squid, configured with http_port 3128 and https_port 3129 for testing purposes. if I connect to http_port 3128 -> then I check log on server see that request go through proxy if I I connect to https_port 3129 -> then I check log on server see that a error when make a request. I think you can work around this using a SOCK5 proxy. I can not use SOCK5 proxy because the proxy server that I want to connect just support HTTP CONNECT proxy require Basic Authentication via HTTPS: curl -v https://sg.http-proxy.privateinternetbrowsing.com:443 * Trying 156.146.57.8:443... * Connected to sg.http-proxy.privateinternetbrowsing.com (156.146.57.8) port 443 * ALPN: curl offers h2,http/1.1 * (304) (OUT), TLS handshake, Client hello (1): * CAfile: /etc/ssl/cert.pem * CApath: none * (304) (IN), TLS handshake, Server hello (2): * (304) (IN), TLS handshake, Unknown (8): * (304) (IN), TLS handshake, Certificate (11): * (304) (IN), TLS handshake, CERT verify (15): * (304) (IN), TLS handshake, Finished (20): * (304) (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 * ALPN: server accepted http/1.1 * Server certificate: * subject: CN=sg.http-proxy.privateinternetbrowsing.com * start date: Jun 25 12:31:20 2024 GMT * expire date: Sep 23 12:31:19 2024 GMT * subjectAltName: host "sg.http-proxy.privateinternetbrowsing.com" matched cert's "sg.http-proxy.privateinternetbrowsing.com" * issuer: C=US; O=Let's Encrypt; CN=E6 * SSL certificate verify ok. * using HTTP/1.1 > GET / HTTP/1.1 > Host: sg.http-proxy.privateinternetbrowsing.com > User-Agent: curl/8.4.0 > Accept: */* > < HTTP/1.1 407 Proxy Authentication Required < Content-Type: text/plain; charset=utf-8 < Proxy-Authenticate: Basic < X-Content-Type-Options: nosniff < Date: Mon, 15 Jul 2024 17:47:20 GMT < Content-Length: 35 < This proxy requires authentication * Connection #0 to host sg.http-proxy.privateinternetbrowsing.com left intact If you issue an http: request, it’ll go through the proxy. But if you issue an http: request, it’ll always go direct. you mean that?: If you issue an https: request, it’ll go through the proxy. But if you issue an http: request, it’ll always go direct I am not sure if it is related to https://developer.apple.com/forums/thread/734679 or not