I'm having the same problem. Did you ever find the cause of this problem?

Good to know--thanks! I'm using pretty standard TCP listeners in Rust (https://docs.rs/smol/latest/smol/net/struct.TcpListener.html); the app is a thin iOS wrapper around a Rust library. Failure mode: when I start a server listening on 0.0.0.0:9001, I cannot connect to it from localhost (on the loopback interface). I just tested with another computer on the same network and that can connect to the server just fine. So it seems that only access over the loopback interface is broken.

I looked into the Rust standard TCP functions, and they seem to be simple wrappers around the C functions, and I'm not sure why things could be wrong. If it helps, I am running the code inside a network extension (a PacketTunnelProvider); is the network stack in some weird state inside network extensions that can cause listening to 0.0.0.0 to fail?

My app, which is an anticensorship tool that combines a VPN and SOCKS5 proxy, has an option to expose the SOCKS5 proxy on 0.0.0.0 so that other computers on the same LAN can use the tunnel. Currently, that breaks applications on the same phone that try to connect to the SOCKS5 proxy through localhost (admittedly, these apps are rare, but Telegram is an example that can be configured to use a localhost proxy). All of my interesting business logic is within the network extension itself. On preventing VPN loops, currently I am using rather complicated hacks to whitelist every IP that the VPN might want to connect to, in the VPN routing configuration. Configuring this correctly to avoid missing everything has been a huge hassle, as the IP addresses that my tool contacts continually change. Furthermore, for correct functionality, the VPN contacts certain IP addresses that other apps would also need to contact, and this other traffic must go through the VPN --- I've just given up on that and leak traffic outside the VPN for those cases. Are you saying that iOS magically avoids VPN loops through e.g. avoiding routing any network-extension-originated traffic through a network extension? If that's the case it'll save me massive amounts of time working with bug-prone hacks :)

I tried out the NECP, and sure enough it worked like a charm :). Does the same nice VPN loopback-prevention functionality exist on Mac?

We already figured this out -- turns out the Paid Apps Agreement was in pending status awaiting tax forms. Once those were submitted and processed everything worked as expected.