If a local website or development server works at 127.0.0.1 but fails at localhost, or works on one address family but not the other, check the server’s listening address and test each path separately. On a Mac, 127.0.0.1 is the IPv4 loopback address and ::1 is the IPv6 loopback address; both refer to your own computer. A successful test on one does not prove the service is listening on the other.

1. Check whether the service is listening

Use the port your application is supposed to serve on. The examples below use port 8000; replace it with the actual port.

lsof -nP -iTCP:8000 -sTCP:LISTEN

lsof lists open files, including network sockets. The options narrow the results to TCP listeners on that port and avoid resolving names. If there is no output, the service may not be running, may use a different port, or may not have opened a TCP listener. Check the application’s startup output and configured port before changing macOS network settings. (lsof manual)

Look at the address in the NAME column. A listener shown on 127.0.0.1:8000 is bound to IPv4 loopback; one shown on [::1]:8000 is bound to IPv6 loopback. A wildcard address may indicate listening on more than loopback, depending on the server and operating system. The key diagnostic is whether the server’s actual bind address includes the address family you are testing. This interpretation follows from the socket address being reported by lsof; application configuration determines what address the server opens.

2. Test IPv4 and IPv6 directly

Make a request to the same port and path through each loopback address. curl lets you test the HTTP connection without relying on a browser’s address selection.

curl -v --connect-timeout 3 http://127.0.0.1:8000/
curl -g -v --connect-timeout 3 'http://[::1]:8000/'

The brackets are required around an IPv6 literal in a URL; -g tells curl not to treat them as URL globbing syntax. The single quotes preserve the URL literally in the default macOS shells. Curl documents these URL rules and provides --ipv4 and --ipv6 to constrain hostname resolution. (curl URL syntax, curl manual)

A connection refusal usually means there is no listener accepting connections at that address and port. A timeout suggests the connection did not complete within the limit. If curl prints an HTTP response, including an error status such as 404, the TCP and HTTP connection reached a server; investigate the path or application response rather than treating it as an IPv4/IPv6 connection failure.

3. Compare localhost with each address

Now test the hostname using curl’s IPv4 and IPv6 options, then try without a family restriction:

curl -4 -v --connect-timeout 3 http://localhost:8000/
curl -6 -v --connect-timeout 3 http://localhost:8000/
curl -v --connect-timeout 3 http://localhost:8000/

Curl’s -4 and -6 options request IPv4-only or IPv6-only addresses for hostnames. Its documentation notes that macOS may return IPv4-mapped addresses on an IPv6-only resolve request, so treat these tests as curl’s constrained connection attempts, not as a complete audit of every application’s resolver behavior. (curl manual)

Use the results to narrow the cause. If the direct IPv4 test works and the direct IPv6 test fails, while lsof shows only an IPv4 listener, the server likely needs to be configured to listen on IPv6 as well if IPv6 access is required. The reverse applies when only the IPv6 listener works. If both direct tests work but localhost does not, compare the forced-family curl results and inspect the application’s hostname, proxy, or URL settings. Different applications can resolve or connect to names differently; Apple recommends address-family-agnostic networking APIs for developers building apps that need to handle IPv4 and IPv6. (Apple Developer: Supporting IPv6-only Networks)

4. Apply the fix where the evidence points

When only one loopback address accepts connections, change the local server’s bind-address configuration or use the address family it actually supports. Don’t assume that changing the Mac’s Wi-Fi IPv4 or IPv6 settings will fix a loopback listener: loopback requests target the Mac itself, while those Network settings configure an interface’s network connection. Apple’s TCP/IP controls can configure IPv4 and IPv6 for a selected network service, but they do not configure an individual application’s listening socket. (Apple Support: Change TCP/IP settings on Mac)

If neither direct address works, verify that the server is running, the port is correct, and the expected protocol is HTTP or HTTPS. If one direct address works but the hostname tests differ, use the lsof address and curl output together to decide whether to adjust the server bind address or the client URL. This sequence distinguishes a missing listener from a family-specific bind issue without assuming that every localhost failure is a DNS problem.

Sources