"applies regardless of how the traffic was generated", "in practice, it doesn’t matter which API you use" - can I take this as both NEAppProxyProvider and NEPacketTunnelProvider can intercept all network traffic from my app even if my app is using BSD socket to do all the networking (including DNS resolution)?

Oh I mean that's the case in my scenario. I understand that both will intercept app's network traffic. But because of the layer difference, if my app uses BSD socket, and the traffic happens between the app proxy layer and packet tunnel layer, effectively the traffic is not intercepted by app proxy provider, but is intercepted by packet tunnel provider right? I'm from a managed app's perspective, not NE provider's, so I need to understand what type of NE provider can effectively intercept and proxy my app's network traffic from our current BSD socket network stack (None? Packet tunnel only? Both?).

Hi, thanks again for answering! The session you shared is very helpful, I now have a better understanding of per-app VPN. My current understanding is that, if the per-app VPN runs in app proxy mode, then sockets network stack goes to eth0 directly without being proxied, and there's nothing we can do to support it unless refactoring the code. But if the per-app VPN runs in packet tunnel mode, the socket network stack goes to utun0 and can still be proxied, so we are fine in this case. Please help correct me if I'm wrong, thanks!

Hi, thanks for answering! Actually current implementation handles system proxy just fine, the focus is on per-app VPN. We are downstream developers and the upstream uses socket, so naturally we are using it. The project is relatively huge so if not necessary we hope that we can avoid refactoring the network code. Is there anyway that we can detect and send requests to the per-app VPN app, I assume the per-app VPN app still listens on certain port? Or is it just impossible to support per-app VPN if socket is used?