On your Mac, inspect the server’s listening address with lsof, then—if needed—try connecting to your Mac’s Wi-Fi or Ethernet IP from another device on the same network. A loopback address such as 127.0.0.1 or ::1 is local-only; a wildcard address such as 0.0.0.0 or :: can accept connections through network interfaces. Confirm the actual address and test the specific port before deciding the server’s reach.

1. Find the server’s listening address

With the development server running, open Terminal and run this command, replacing 8000 with its port:

lsof -nP -iTCP:8000 -sTCP:LISTEN

lsof lists open files, including network sockets; its TCP state filter can select listeners. The -nP options keep addresses numeric and prevent port numbers from being displayed as service names. Apple’s lsof manual

Look at the NAME column. A result ending in 127.0.0.1:8000 (LISTEN) is bound to the IPv4 loopback address. localhost:8000 also indicates a loopback listener, though the displayed name can vary. A result showing *:8000 is a wildcard listener for that address family. Check the TYPE column too: separate IPv4 and IPv6 rows can matter. ::1 is IPv6 loopback; :: is the IPv6 wildcard. On some systems, an IPv6 wildcard listener may also accept IPv4 connections, so the listing alone may not settle that detail.

If the command returns nothing, check that the server is still running, that you used its current port, and that it listens on TCP. This command does not inspect UDP listeners. If lsof shows no result without elevated permissions, rerun it with sudo only if you need to inspect processes owned by another account; macOS may request your login password.

2. Read the address as a reachability clue

A listener bound to a specific loopback address accepts connections addressed to that loopback interface, not to your Mac’s LAN address. A wildcard address means the socket is not restricted to loopback, so it may be reachable through a network interface. Apple describes a listening socket as one that waits for incoming connections. Apple’s overview of TCP-based servers

A wildcard is not proof that another device can connect. The server must still be running on that port; macOS firewall settings, router or Wi-Fi client isolation, and other network conditions can affect the connection. Conversely, a successful browser test on the Mac using localhost proves only that a local connection works.

3. Test access from another device on your network

Find the Mac’s address for the network you want to test. For Wi-Fi, Apple documents finding the connection’s IP address in Wi-Fi settings or the Wi-Fi status menu; the exact controls can vary by macOS version. Apple’s Wi-Fi settings guide

From a second device connected to the same LAN, open a browser or use an HTTP client to request http://MAC-IP:8000, substituting the Mac’s current address and the server’s port. For example, if the Mac’s LAN address is 192.168.1.23 and the port is 8000, try http://192.168.1.23:8000. A response shows that this client reached the service on that route; a timeout or refusal does not, by itself, identify the cause. Confirm both devices are on the intended network and recheck the listener before investigating firewall or network settings.

4. Make a local-only bind explicit when supported

The correct setting belongs to the development server, not to a universal macOS switch. For example, Python’s http.server supports --bind; its documentation says the default binds to all interfaces, while this command binds to IPv4 loopback:

python3 -m http.server --bind 127.0.0.1 8000

This works if Python 3 is installed. Python documents both the bind option and its default behavior. Python http.server documentation

Other tools expose their own host or bind settings. Node.js documents that omitting the host from server.listen() selects an unspecified address, with behavior depending on IPv6 availability. Check the documentation for your server and version; do not assume a flag from another framework applies. Node.js net.Server documentation After changing the setting, restart the server and repeat the lsof check. A LAN test is useful when you intend to share access, but binding to a LAN or wildcard address can expose the development service to other reachable devices.

Sources