For important background information, read Extra-ordinary Networking before reading this. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Don’t Try to Get the Device’s IP Address I regularly see questions like: How do I find the IP address of the device? How do I find the IP address of the Wi-Fi interface? How do I identify the Wi-Fi interface? I also see a lot of really bad answers to these questions. That’s understandable, because the questions themselves don’t make sense. Networking on Apple platforms is complicated and many of the things that are ‘obviously’ true are, in fact, not true at all. For example: There’s no single IP address that represents the device, or an interface. A device can have 0 or more interfaces, each of which can have 0 or more IP addresses, each of which can be IPv4 and IPv6. A device can have multiple interfaces of a given type. It’s common for iPhones to have multiple WWAN interfaces, for example. It’s not possible to give a simple answer to any of these questions, because the correct answer depends on the context. Why do you need this particular information? What are you planning to do with it? This post describes the scenarios I most commonly encounter, with my advice on how to handle each scenario. IMPORTANT BSD interface names, like en0, are not considered API. There’s no guarantee, for example, that an iPhone’s Wi-Fi interface is en0. If you write code that relies on a hard-coded interface name, it will fail in some situations. Service Discovery Some folks want to identify the Wi-Fi interface so that they can run a custom service discovery protocol over it. Before you do that, I strongly recommend that you look at Bonjour. This has a bunch of advantages: It’s an industry standard [1]. It’s going to be more efficient on the ‘wire’. You don’t have to implement it yourself, you can just call an API [2]. For information about the APIs available, see TN3151 Choosing the right networking API. If you must implement your own service discovery protocol, don’t think in terms of finding the Wi-Fi interface. Rather, write your code to work with all Wi-Fi interfaces, or perhaps even all Ethernet-like interfaces. That’s what Apple’s Bonjour implementation does, and it means that things will work in odd situations [3]. To find all Wi-Fi interfaces, get the interface list and filter it for ones with the Wi-Fi functional type. To find all broadcast-capable interfaces, get the interface list and filter it for interfaces with the IFF_BROADCAST flag set. If the service you’re trying to discover only supports IPv4, filter out any IPv6-only interfaces. For advice on how to do this, see Interface List and Network Interface Type in Network Interface APIs. When working with multiple interfaces, it’s generally a good idea to create a socket per interface and then bind that socket to the interface. That ensures that, when you send a packet, it’ll definitely go out the interface you expect. For more information on how to implement broadcasts correctly, see Broadcasts and Multicasts, Hints and Tips. [1] Bonjour is an Apple term for: RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses RFC 6762 Multicast DNS RFC 6763 DNS-Based Service Discovery [2] That’s true even on non-Apple platforms. It’s even true on most embedded platforms. If you’re talking to a Wi-Fi accessory, see Working with a Wi-Fi Accessory. [3] Even if the service you’re trying to discover can only be found on Wi-Fi, it’s possible for a user to have their iPhone on an Ethernet that’s bridged to a Wi-Fi. Why on earth would they do that? Well, security, of course. Some organisations forbid their staff from using Wi-Fi. Logging and Diagnostics Some folks want to log the IP address of the Wi-Fi interface, or the WWAN, or both for diagnostic purposes. This is quite feasible, with the only caveat being there may be multiple interfaces of each type. To find all interfaces of a particular type, get the interface list and filter it for interfaces with that functional type. See Interface List and Network Interface Type in Network Interface APIs. Interface for an Outgoing Connection There are situations where you need to get the interface used by a particular connection. A classic example of that is FTP. When you set up a transfer in FTP, you start with a control connection to the FTP server. You then open a listener and send its IP address and port to the FTP server over your control connection. What IP address should you use? There’s an easy answer here: Use the local IP address for the control connection. That’s the one that the server is most likely to be able to connect to. To get the local address of a connection: In Network framework, first get the currentPath property and then get its localEndpoint property. In BSD Sockets, use getsockname. See its man page for details. Now, this isn’t a particularly realistic example. Most folks don’t use FTP these days [1] but, even if they do, they use FTP passive mode, which avoids the need for this technique. However, this sort of thing still does come up in practice. I recently encountered two different variants of the same problem: One developer was implementing VoIP software and needed to pass the devices IP address to their VoIP stack. The best IP address to use was the local IP address of their control connection to the VoIP server. A different developer was upgrading the firmware of an accessory. They do this by starting a server within their app and sending a command to the accessory to download the firmware from that server. Again, the best IP address to use is the local address of the control connection. [1] See the discussion in TN3151 Choosing the right networking API. Listening for Connections If you’re listening for incoming network connections, you don’t need to bind to a specific address. Rather, listen on all local addresses. In Network framework, this is the default for NWListener. In BSD Sockets, set the address to INADDR_ANY (IPv4) or in6addr_any (IPv6). If you only want to listen on a specific interface, don’t try to bind to that interface’s IP address. If you do that, things will go wrong if the interface’s IP address changes. Rather, bind to the interface itself: In Network framework, set either the requiredInterfaceType property or the requiredInterface property on the NWParameters you use to create your NWListener. In BSD Sockets, set the IP_BOUND_IF (IPv4) or IPV6_BOUND_IF (IPv6) socket option. How do you work out what interface to use? The standard technique is to get the interface list and filter it for interfaces with the desired functional type. See Interface List and Network Interface Type in Network Interface APIs. Remember that their may be multiple interfaces of a given type. If you’re using BSD Sockets, where you can only bind to a single interface, you’ll need to create multiple listeners, one for each interface. Listener UI Some apps have an embedded network server and they want to populate a UI with information on how to connect to that server. This is a surprisingly tricky task to do correctly. For the details, see Showing Connection Information for a Local Server. Outgoing Connections In some situations you might want to force an outgoing connection to run over a specific interface. There are four common cases here: Set the local address of a connection [1]. Force a connection to run over a specific interface. Force a connection to run over a type of interface. Force a connection to run over an interface with specific characteristics. For example, you want to download some large resource without exhausting the user’s cellular data allowance. The last case should be the most common — see the Constraints section of Network Interface Techniques — but all four are useful in specific circumstances. The following sections explain how to tackle these tasks in the most common networking APIs. [1] This implicitly forces the connection to use the interface with that address. For an explanation as to why, see the discussion of scoped routing in Network Interface Techniques. Network Framework Network framework has good support for all of these cases. Set one or more of the following properties on the NWParameters object you use to create your NWConnection: requiredLocalEndpoint property requiredInterface property prohibitedInterfaces property requiredInterfaceType property prohibitedInterfaceTypes property prohibitConstrainedPaths property prohibitExpensivePaths property Foundation URL Loading System URLSession has fewer options than Network framework but they work in a similar way: Set one or more of the following properties on the URLSessionConfiguration object you use to create your session: allowsCellularAccess property allowsConstrainedNetworkAccess property allowsExpensiveNetworkAccess property Note While these session configuration properties are also available on URLRequest, it’s better to configure this on the session. There’s no option that forces a connection to run over a specific interface. In most cases you don’t need this — it’s better to use the allowsConstrainedNetworkAccess and allowsExpensiveNetworkAccess properties — but there are some situations where that’s necessary. For advice on this front, see Running an HTTP Request over WWAN. BSD Sockets BSD Sockets has very few options in this space. One thing that’s easy and obvious is setting the local address of a connection: Do that by passing the address to bind. Alternatively, to force a connection to run over a specific interface, set the IP_BOUND_IF (IPv4) or IPV6_BOUND_IF (IPv6) socket options. Revision History 2025-01-21 Added a link to Broadcasts and Multicasts, Hints and Tips. Made other minor editorial changes. 2023-07-18 First posted.

Hello, We are currently working on a zero-configuration networking compliant device thru avahi-daemon (for mDNS/DNS-SD handling) and avahi-autoipd (for link-local address configuration). Our test environment setup is: Device Under Test (DUT): Debian 9 Linux avahi-daemon: v0.6.32 avahi-autoipd: v0.6.32 Test Bed: Macmini with macOS Sequoia 15.0 Bonjour Conformance Test v1.5.4 Router: NEC Aterm WR8370N Devices are connected via LAN SRV PROBING/ANNOUNCEMENTS BASIC test failure was encountered in BCT during Multicast-DNS test suite execution. Please see the logs below: ERROR 2025-01-15 19:36:35.792930+0900: Cache flush bit is set in the SRV probes NOTICE 2025-01-15 19:36:35.792946+0900: DEVICE-sERvICE-32\._uSCaNs\._tcp\.lOcaL\.._uscAnS._tCP.loCAL., SEND_CONFLICT_WIN -> SEND_CONFLICT_WIN FAILED (SRV PROBING/ANNOUNCEMENTS BASIC) START (SRV PROBING/ANNOUNCEMENTS) DEBUG_2 2025-01-15 19:36:35.792979+0900: received packet (1137 bytes) DEBUG_2 2025-01-15 19:36:35.792999+0900: srv_cf_probe WARNING 2025-01-15 19:36:35.793022+0900: SRV Probing/Announcements Failed: See runtime output for PROBING and WINNING SIMULTANEOUS PROBE for details. FAILED (SRV PROBING/ANNOUNCEMENTS) We would like to know what causes the above test to fail, is it related to avahi or a an inccorect mDNS service handling wherein the cache flush bit was incorrectly set? Thank you.

I have an idea for a game where the Apple TV app acts as the host and discovers nearby iOS apps that can join the game. Each iOS app needs to be able to have the user draw, tap, etc and have all the events be delivered in real time to the Apple TV where the effects will be rendered immediately (imagine a co-op game played in your lounge room where guests user their own devices to control aspects of the UI on the shared Apple TV screen) MPC is discontinued and DeviceDiscoveryUI is limited to only a single iOS device so I’m trying to figure out the best way to do the P2P networking. Reading/watching videos suggests that using GKMatchMaker and friends seems like it might suffer from latency problems (because everything has to go via Game Centre - or does it?) plus I’m not sure how I’d deal with the fact that the owner of the Apple TV is likely to signed into the same game centre id on both the Apple TV and their own devices to which would mean they wouldnt be able to play because the host can’t invite “themselves” on another device (or can it?) Soooo… I’m looking for suggestions on how best to move forward. I’ve read https://developer.apple.com/documentation/technotes/tn3151-choosing-the-right-networking-api which is very useful but there’s no clear suggestion that would work. Using the Network for the real time messaging seems doable but dealing with discovery / invites seems like a massive pain that I’d prefer to use built-in libraries if possible. Any suggestions would be gladly received. Thanks a lot

We’ve been dealing with local network permission issues on macOS 15. Although 15.1 brought some improvement, users are now reporting similar problems again on 15.2. Our setup: A “launcher” app (installed from a web package, not sandboxed) uses NSTask to launch our main macOS app. This macOS app connects to an iOS app via the local network. We expect a local network permission prompt to appear when the new app launches, but for many users, it never does. In cases where it worked on an earlier macOS version, there’s no entry in System Settings > Privacy & Security > Local Network, so they can’t toggle anything. Oddly, if we run the macOS app directly in 15.2, local network access works, yet the privacy entry is still sometimes missing. We haven’t found a clear way to troubleshoot this within the current API. Has anyone experienced a similar issue, or have suggestions on how to debug and resolve this? Thanks in advance!

In https://developer.apple.com/forums/thread/128705?answerId=405119022#405119022, it is said that But if it’s holding up connections that match the on demand rules, that’s the correct behaviour. So if there was an on demand rule to connect for all domains (Connect rule without any matching criteria), all traffic would be held up while in the connecting state. The problem is that a customer can have SSO configured so that auth happens outside of the vpn app. So sequence would be Connect for all domains on demand rule triggers vpn connection VPN, in order to connect, tries auth through a broker app. VPN is in connecting state and blocks broker app traffic and so auth cannot complete and it cannot connect. I tried adding an on demand rule for EvaluateConnection and never connect for the auth domains. However, that caused the vpn to never be triggered to connect. Is it possible to support the scenario of an on demand rule to connect for all domains while having a vpn connection dependent on auth done in a separate app? Do you have any recommendations?

Dear Apple Developer Support Team, I hope this email finds you well. I am writing to inquire about the status of my application for the Hotspot Helper Request entitlement. I submitted the request on January 16, 2025, but I have not received any updates regarding its review status.

I am writing an app using Microsoft's MAUI platform. I am posting this here because that team wants me to make an xcode project to help determine an issue I am having. My MAUI app sends a broadcast packet on a UDP socket using address 255.255.255.255. This worked fine in iOS version 17.x. After upgrading my phone to iOS 18.x it stopped working. The error I get is "no route to host". The exact same code works fine on MacOS. It does not work on iPadOs 18. My question here is 3 fold: Did something specific change between iOS 17 and 18 that would cause a 'no route to host' error when sending a UDP broadcast packet? Can someone provide sample code to show me how to do this type of broadcast using Swift in Xcode for iOS? I read an article that said my app would need the com.apple.developer.networking.multicast entitlement in order to use boradcast functionality. This was introduced in iOS 14. Why did my app work fine in iOS 17 then? Is this what changed? Did this requirement use to be optional and is now required? I did get this entitlement from Apple and applied it to my provisioning profile and my app gave the same "no route to host" error. Why?

We are trying to connect an accessory to the home's Wi-Fi network and we want to pass that name from the app to the accessory. Passing via Bluetooth. Is there and API available on iOS to list the networks that the phone can see?

Hi, I’m urgently seeking assistance with an issue in my app development. The app allows users to control which domains are routed through my relay servers (six server URLs). However, I’ve encountered a problem: When a single relay configuration (for a single server URL) contains more than 70 domains, only one configuration can be active at a time. If I manually activate another relay configuration (for another server URL), the previously activated one automatically deactivates. Is there a way to overcome this limitation? Also, is there a maximum amount of domains that can exist across the per-app relays? I’m referencing the Apple documentation here: https://developer.apple.com/documentation/networkextension/relays Any guidance or insights into resolving this issue would be greatly appreciated! Thank you in advance :)

Hi All, I am trying to write an NWProtocolFramerImplementation that will run after Websockets. I would like to achieve two goals with this Handle the application-layer authentication handshake in-protocol so my external application code can ignore it Automatically send pings periodically so my application can ignore keepalive I am running into trouble because the NWProtocolWebsocket protocol parses websocket metadata into NWMessage's and I don't see how to handle this at the NWProtocolFramerImplementation level Here's what I have (see comments for questions) class CoolProtocol: NWProtocolFramerImplementation { static let label = "Cool" private var tempStatusCode: Int? required init(framer: NWProtocolFramer.Instance) {} static let definition = NWProtocolFramer.Definition(implementation: CoolProtocol.self) func start(framer: NWProtocolFramer.Instance) -> NWProtocolFramer.StartResult { return .willMarkReady } func wakeup(framer: NWProtocolFramer.Instance) { } func stop(framer: NWProtocolFramer.Instance) -> Bool { return true } func cleanup(framer: NWProtocolFramer.Instance) { } func handleOutput(framer: NWProtocolFramer.Instance, message: NWProtocolFramer.Message, messageLength: Int, isComplete: Bool) { // How to write a "Message" onto the next protocol handler. I don't want to just write plain data. // How to tell the websocket protocol framer that it's a ping/pong/text/binary... } func handleInput(framer: NWProtocolFramer.Instance) -> Int { // How to handle getting the input from websockets in a message format? I don't want to just get "Data" I would like to know if that data is // a ping, pong, text, binary, ... } } If I implementing this protocol at the application layer, here's how I would send websocket messages class Client { ... func send(string: String) async throws { guard let data = string.data(using: .utf8) else { return } let metadata = NWProtocolWebSocket.Metadata(opcode: .text) let context = NWConnection.ContentContext( identifier: "textContext", metadata: [metadata] ) self.connection.send( content: data, contentContext: context, isComplete: true, completion: .contentProcessed({ [weak self] error in ... }) ) } } You see at the application layer I have access to this context object and can access NWProtocolMetadata on the input and output side, but in NWProtocolFramer.Instance I only see final func writeOutput(data: Data) which doesn't seem to include context anywhere. Is this possible? If not how would you recommend I handle this? I know I could re-write the entire Websocket protocol framer, but it feels like I shouldn't have to if framers are supposed to be able to stack.

I am developing an App using the Networking framework, which can be either a Socket Server or a Socket Client, such that 2 devices can communicate remotely. For the most part I have it working, except: I am not sure of the best way to determine the IP Address for the Socket Server in order to allow the Client app to connect. I am currently using either of Cloud Functions, or lookup webpages (such as ipify.org) and even reading the IP addresses locally from within the device (this returns many, but not all of them connect successfully). These options seem to work if the Socket Server app is connected to the internet with an IPv6 address, but I find that when the Socket Server app is connected with an IPv4 address, the Client app never successfully connects. How should I: a) force the Socket Server app to have/use an IPV6 address at all times? or b) allow the Client app to connect successfully via an IPv4 address? And is there a simple way to know what IP Address the Socket Server is listening from?

Hi, I would like to confirm whether the matchDomains property in NERelayManager operates strictly at the Application Layer. Specifically, it seems that adding IPv4 addresses or IPv4 CIDR blocks to the matchDomains list does not work, as the relay manager appears unable to match them. For example, I tried adding the following IPv4 patterns to the matchDomains list: 11.22.33.44 11.22.. 11.22.* However, these IPv4 addresses or patterns are not routed through my Relay server. Additionally, I have observed that when using only the excludedDomains property, the desired IPv4 traffic is correctly routed to the relay server as expected. My question is: Can IPv4 addresses or IPv4 CIDR ranges work with matchDomains? If not, is there an alternative approach to enable IPv4 matching while matchDomains is active?

We're seeing some new and odd behavior where our NEPacketTunnelProvider instance is receiving a stopTunnelWithReason:completionHandler: call with reason NEProviderStopReasonInternalError. Can anyone shed some light into how to diagnose this situation? Here are some basic details: Our PacketTunnel has been in use for years and we only started seeing this issue recently. We're able to reproduce this behavior with some light browsing. The documentation provides no insight on why/when this might occur. Can anyone shed some light into how to diagnose this situation? Things we’ve tried so far: We grabbed a sysdiagnose and looked through the logs: a. Right before the stopTunnel, we see log items referring to a "nesessionmanager" (PID 2038) getting killed. Presumably, this is due to hitting a highwater threshold. (See sysdiagnose items listing below) b. Thinking these were due to memory pressure, we added logging of available/used memory. c. We confirmed that the PacketTunnel was only using 11,808.73 KB. d. Since, there is plenty of memory available the PacketTunnel was not killed for using too much memeory. We wondered if this could be due to our UI's usage of objects like: NETunnelProviderManager and NETunnelProviderSession a. We ran an experiment where we swiped closed the UI to ensure these manager/session objects are not used. b. Without the UI, we still saw the random stopTunnel with NEProviderStopReasonInternalError. We wondered if our routes were the problem, but they seem correct. a. See the NEPacketTunnelNetworkSettings listing below LISTING: From the system_logs.logarchive, the nesessionmanager log items: 2025-01-23 15:07:59.176146 -0800 0x278 memorystatus com.apple.xnu memorystatus: killing process 2038 [nesessionmanager] in high band ? (140) - memorystatus_available_pages: 18932 default kernel 2025-01-23 15:07:59.179641 -0800 0x278 memorystatus com.apple.xnu memorystatus: killing_highwater_process pid 2038 [nesessionmanager] (highwater 140) 7056KB - memorystatus_available_pages: 19161 compressor_size:69593 default kernel 2025-01-23 15:07:59.179888 -0800 0x278 memorystatus com.apple.xnu memorystatus: failed to kill a process and no memory was reclaimed default kernel 2025-01-23 15:07:59.185695 -0800 1 0x45e0c user/501/com.apple.nesessionmanager [2038] exited with exit reason (namespace: 1 code: 0x2) - JETSAM_REASON_MEMORY_HIGHWATER, ran for 266329ms default launchd 2025-01-23 15:07:59.231188 -0800 31 0x45bf2 com.apple.networkextension nesessionmanager(2038) exited default UserEventAgent 2025-01-23 15:07:59.253371 -0800 31 0x45bf2 com.apple.networkextension nesessionmanager exited with active sessions, re-launching nesessionmanager to clear agent status default UserEventAgent LISTING: From the system_logs.logarchive, the stopTunnel from PID 2046 2025-01-23 15:07:59.201581 -0800 SamplePacketTunnel [Extension com.REDACTED.PacketTunnel]: Calling stopTunnelWithReason because: None 2025-01-23 15:08:20.783112 -0800 SamplePacketTunnel 2025-01-23 15:08:20,786 2046 ERROR REDACTED (285805) - Exiting after waiting for stopTunnelWithReason LISTING: routes from NEPacketTunnelNetworkSettings { tunnelRemoteAddress = fd12:3456:789a:1::1 DNSSettings = { protocol = cleartext server = ( 2606:4700:4700::1234, 2606:4700:4700::2345, ) matchDomains = ( , ) matchDomainsNoSearch = NO } IPv6Settings = { configMethod = manual addresses = ( fd12:3456:789a:1::1, ) networkPrefixLengths = ( 64, ) includedRoutes = ( { destinationAddress = 2606:4700:4700::2345 destinationNetworkPrefixLength = 128 }, { destinationAddress = 2606:4700:4700::1234 destinationNetworkPrefixLength = 128 }, ) excludedRoutes = ( { destinationAddress = REDACTED destinationNetworkPrefixLength = 128 }, { destinationAddress = REDACTED destinationNetworkPrefixLength = 128 }, ) } MTU = 3072 } Thanks for taking a look, any help or suggestions would be greatly appreciated

I am unable to apply for Multicast Entitlement at https://developer.apple.com/contact/request/networking-multicast The reason for this is unclear. I have paid for a developer account and believe I'm up to date with all agreements.

Hi all, I’m developing a watchOS app that uses a WebSocket API to process voice audio. However, I keep encountering this error when trying to establish the connection: nw_endpoint_flow_failed_with_error [C1 <server URL>:443 failed parent-flow (unsatisfied (Path was denied by NECP policy), interface: ipsec2, ipv4, ipv6, proxy)] already failing, returning I’ve read Technical Note TN3135, which outlines an exception for audio streaming apps. My app is an audio streaming app, and I’ve already added background audio mode to the app’s capabilities. However, I’m not sure what else is required to meet the exception described in TN3135. Questions How do I meet the exception outlined in TN3135 for WebSocket audio streaming on watchOS? Does NECP enforce additional restrictions even with background audio enabled, and how can I address this? Any guidance or examples of implementing WebSocket audio streaming on watchOS would be greatly appreciated. Thanks!

In our iOS networking related app for the app store (with network extension using packet tunnel provider), we are supposed to read the list of nameservers for the network. We use res_ninit function. This function returns only 3 items (but in reality the network has more dns servers. In my case 5. Some ipv4 and some ipv6) Looking at the header file at iOS 18.2 -> user/include/resolve.h, it shows that the __res_state struct has a maximum limit of 3 for the nsaddr_list array. It seems that the reason the res_ninit function returns only 3 values is because of this. For our code to work correctly, it needs to know all the dns servers, but we only get partial results. Is there any other api that can get us all the dns servers ?

I added a Content Filter to my app, and when running it in Xcode (Debug/Release), I get the expected permission prompt: "Would like to filter network content (Allow / Don't Allow)". However, when I install the app via TestFlight, this prompt doesn’t appear at all, and the feature doesn’t work. Is there a special configuration required for TestFlight? Has anyone encountered this issue before? Thanks!

We've been directed here by Quinn in DTS. We use multicast/broadcast messages extensively in our physical products for discovery purposes. If, for whatever reason, our customers cannot get this to work on their home Wi-Fi network, we advise that they connect to an iPhone hotspot to confirm behaviour and perform firmware updates as needed. As of iOS 18, we're seeing odd behaviour when using Personal Hotspot. Interestingly, we're also seeing that client devices connected to the Hotspot network are not showing a Subnet Mask in the Wi-Fi Details screen in the iOS Settings app - I don't know if that's related. We're also seeing that screen show an IP address of 192.0.0.2 for all client iPhones connected to an iPhone Hotspot. Getting more specific, we're seeing that multicast messages are no longer being received by clients when connected to an iPhone Hotspot where the iPhone running the hotspot is running iOS 18.0 or newer. By "multicast", I mean we're using a BSD socket to send data to 255.255.255.255 I've confirmed that our app has the multicast entitlement, the user has granted Local Network permission, and we've created a small sample app that demonstrates this behaviour perfectly - when connected to any other test network, multicast messages are received correctly by clients. We've also confirmed that this behaviour doesn't happen when the iPhone running the hotspot is running older iOS versions. We've tried a number of iOS 17.x releases and a number of iOS 16.x releases specifically with our sample app, but have been using this exact code since our app's original iOS 9 deployment target and have had no issues until now.

Hi, I would like to confirm if the matchDomains property in NERelayManager operates exclusively at the application layer. Specifically, it seems that adding IPv4 addresses or IPv4 CIDR blocks to the matchDomains list does not work, as the relay manager appears unable to match them. Relay Configuration For example, I tried adding the following IPv4 patterns to the matchDomains list: 11.22.33.44 11.22.. 11.22.* In this configuration, I expected traffic to be routed to the relay server as defined by the matchDomains entries. However, the relay manager did not handle these IPv4 patterns as anticipated. On the other hand, when using only the excludedDomains property, the desired IPv4 traffic is successfully routed to the relay server as expected. Purpose of Forwarding IPv4 to the Relay Server The primary reason for forwarding IPv4 traffic to the relay server is to address cases where certain applications—such as those developed with Flutter or React Native—use their own custom network stack. These custom network stacks often do not respect the relay configuration. As a result, even when these applications use domains that are matched by the relay manager’s matchDomains, their TCP connections to DNS-resolved IPv4 addresses bypass the relay server and connect directly to the IPv4 server. This behavior makes it critical to enable IPv4 matching to ensure all traffic, regardless of the application’s network stack implementation, is routed through the relay server. Questions Can IPv4 addresses or IPv4 CIDR blocks be used with matchDomains? If not, is there an alternative method to enable IPv4 matching while keeping matchDomains enabled? Thank you for your assistance.

Hi, I have been reviewing some previous discussions around networking in macOS, and I’d like to clarify my understanding of the differences between the kernel-space network stack and user-space network stack and validate this understanding based on the information shared in earlier threads. I’m also curious about how these differences impact macOS applications, particularly those requiring maintaining many simultaneous network connections. Understanding Kernel-Space vs User-Space Network Stack Kernel-Space Network Stack (BSD Sockets): The kernel-space networking stack refers to the traditional networking layer that runs in the kernel and handles network communication via BSD sockets. This stack is lower-level and interacts directly with the operating system's networking drivers and hardware. All network connections managed through this stack require a socket (essentially a file descriptor) to be opened, which places limits on the number of file descriptors that can be used (for example, the default 64K limit for sockets). The kernel network stack is traditionally used on macOS (and other UNIX-based systems) for networking tasks, such as when you use system APIs like BSD sockets. User-Space Network Stack (Network Framework): The user-space network stack in macOS (via the Network framework) allows applications to handle networking tasks without directly using the kernel. This provides more flexibility and performance benefits for certain types of network operations, as the networking stack is managed in user space rather than kernel space. This approach reduces overhead and allows more control over networking configurations. In theory, with user-space networking, the application wouldn't be bound by kernel-level socket limits, and it could handle many more simultaneous connections efficiently. In previous posts on that thread, Quinn mentioned that the Network framework in macOS can rely on the user-space stack (by default) for network operations, but there are still cases where macOS falls back to using the kernel stack (i.e., BSD sockets) under certain conditions. One key example is when the built-in firewall is enabled. This prevents user-space networking from functioning as expected, and the system defaults to using the kernel's BSD sockets for network communication. In the same discussion, it was also highlighted that NECP (Network Extension Control Plane) could place further limitations on user-space networking, and eventually, systems may run into issues like ENOSPC errors due to excessive simultaneous network flows. This suggests that while user-space networking can offer more flexibility, it's not immune to limits imposed by other system resources or configurations. Given the information above, I wanted to confirm: Is the above understanding correct and does the macOS Network framework still use the user-space networking stack in macOS 14 and beyond? Under what conditions would the system fall back to using the kernel stack (BSD sockets) instead of the user-space stack? For example, does enabling the firewall still disable user-space networking? What is the practical impact of this fallback on applications that require many simultaneous network connections? Specifically, are there any limitations like the 64K socket limit that developers should be aware of when the system uses the user space stack, and what are the best practices to manage large numbers of connections?