@meaton Thank you. I followed your suggestion. First, the provider did not restart, it was still running normally, but no new flow could be received. Then I checked the os_log and found that com.apple.networkextension did report an error below: @meaton Looks like a system bug? (1485082327): plugin wrote 4104 bytes (0): data: failed to write a message: no buffer space available (1485082327): app receive buffer is full, queueing 2736 bytes (0): data: write error: Message too long 2022-02-11 15:13:18.736 [2002:8013] [com.apple.networkextension] (2463085674): Got an error when sending 131072 bytes to the kernel: Message too long (2463085674): writes are still pending, delaying sending close until all data is sent to the kernel

@meaton Are you buffering a lot of this data in your provider?  No. But I'm not quite sure what you mean. Let me tell you the specific content of my provider. I create a socket for each TCP/UDP Flow, I mean, each flow has one individual socket(I use the open source library https://github.com/robbiehanson/CocoaAsyncSocket to create socket). Then, in my provider, each socket will directly forward the traffic in the Flow to the local agent program, and then write the return data of the local agent program back to the TCP/UDP Flow using - (void)writeData:(NSData *)data withCompletionHandler:(void (^)(NSError *error))completionHandler, and every time the socket I created is released correctly. Is there something wrong with my design? It doesn't look like there should be a problem. We are worried and hope to get help soon, thank you @meaton.

@meaton For example, if you read / write between the flow and NWTCPConnection / NWUDPSession, then do you have this same issue? I don't know what is wrong with NWTCPConnection. When I use - (NWTCPConnection *)createTCPConnectionToEndpoint:(NWEndpoint *)remoteEndpoint enableTLS:(BOOL)enableTLS TLSParameters:(NWTLSParameters *)TLSParameters delegate:(id)delegate; to create tcp connection and observe the state, I will receive NWTCPConnectionStateConnecting, NWTCPConnectionStateConnected first, and then receive NWTCPConnectionStateDisconnected immediately : ) . At this time, the connection is not real disconnected, and data can still be transmitted, it is funny 😂 .....

Hi. After my test, return 0xffffffff (Apple recommendation 0xffffffff) is correct. And, the return value 0xffffffff does not affect the logic of the original program, whether it was originally read-only or read-write.