A per-process limitation on the number of active nw_connection_t objects.

We have observed a per-process limitation on the number of simultaneous nw_connection_t objects in certain macOS environments. On some systems, this limit does not appear to apply, but on others the limitation is reproducible. When a process attempts to establish a large number of connections (e.g. 512+), some connections enter the nw_connection_state_waiting state and report the POSIX error “Cannot allocate memory”. These connections remain stuck indefinitely, even after other connections are deallocated and resources should theoretically be available again. This behavior severely impacts use cases such as transparent proxies implemented via the NetworkExtension framework, which intercept system-wide traffic and must open connections on behalf of all client processes. In this scenario, a per-process limit effectively becomes a system-wide limit, leading to unexpected and hard-to-diagnose network failures in client applications. Can we expect a relaxation of these restrictions for network extensions in the future? Could you please suggest some workarounds to bypass the restriction? By the way, now we have to fallback to BSD socket implementation of the outgoing connections, possibly braking the chain of TransparentProxies as the second proxy in the chain can’t get the originator of the intercepted flow (it sees the first proxy instead).

Connections using Network.framework are subject to per-process flow limits; note that there are also limits on the number of sockets/file descriptors in general. On most platforms that flow limit is 512. On macOS 26.4 and above, the flow limit is raised to 1024.

If you're seeing specific error cases that don't match these values, please file feedback reports and include relevant sysdiagnose files!

It turns out that these limits for Network Extension allow one application to impact the performance of others. A misbehaving application can open more than 512 long-lived connections and, when an NETransparentProxyProvider is active, effectively block network connectivity for other applications.

Please do provide a feedback report with a sysdiagnose, taken from an instance when you see this.

For cases where another application is creating too many flows, it might be good to look into policies within your NetworkExtension for closing older flows, or limiting flows that you accept from specific processes or to particular destinations.

A per-process limitation on the number of active nw_connection_t objects.
 
 
Q