localhost vs 127.0.0.1 vs 0.0.0.0

The bind address is the setting that decides this. It is not the address in the URL you type.

localhost goes through name resolution like any hostname. Node’s dns.lookup() hands the name to the operating system, which reads files such as /etc/hosts, and the Node documentation notes that its dns.resolve*() functions do not. To see what your machine answers, run:

The Linux IP documentation says INADDR_LOOPBACK always refers to the local host through the loopback device. Traffic to it never reaches your network, which is why other devices cannot connect. It also means that on your phone, 127.0.0.1 and localhost point at the phone.

The same documentation says INADDR_ANY means any address for binding. Use 0.0.0.0 in server settings, and use 127.0.0.1 or the machine’s LAN address in the URL you open. Some servers do this without being asked. When you give Node no host, it listens on :: if IPv6 is available and on 0.0.0.0 otherwise, and listening on :: may also take IPv4. A bare server.listen(3000) is therefore not limited to loopback.

Defaults differ by tool, and they are the usual reason a phone works with one project and not another:

1. Bind to an address other devices can reach. For Vite, run vite --host.
2. Open the computer’s address, not localhost. On your phone, use http://192.168.1.20:5173, with your computer’s own address from its network settings.
3. Test from the computer first. Open that same address in the computer’s browser. If it fails there, the server still listens on loopback only.
4. If the computer succeeds and the phone fails, the bind is right, and the cause is a firewall or the network between the two. Rig’s firewall and network page notes that guest Wi-Fi isolation blocks QR previews.

Binding is necessary, but the framework can still say no. Vite’s server.allowedHosts lists the hostnames it responds to, and by default it allows localhost, .localhost domains, and all IP addresses, so a custom hostname or tunnel domain is refused until you add it. Django’s ALLOWED_HOSTS works the same way. With DEBUG on and the list empty, Django validates the host against .localhost, 127.0.0.1, and [::1] only, so a request to the LAN address raises SuspiciousOperation until you add it:

Node 17 changed dns.lookup() to return addresses in the order the resolver gave them, where earlier versions put IPv4 first. If your system’s resolver returns ::1 before 127.0.0.1 for localhost, a Node client now tries ::1 first, and a server bound only to 127.0.0.1 refuses it.

Node 20 and 18.18 softened this for outgoing connections. The autoSelectFamily option defaults to true there, so net.connect() tries the addresses in turn, alternating between IPv6 and IPv4, until one connects. The change does not cover browsers or other tools, and it does not change what your server binds. Vite’s documentation says browsers may use a different resolved address than the one Vite listens on, and that Vite prints the resolved address when it differs.

To check each family yourself:

Binding decides which addresses the server accepts. A firewall on the machine, or on the network, decides which packets arrive at all, so a server on 0.0.0.0 can still be unreachable. Firewall menus change between releases, so check your operating system’s own documentation and test from the phone after each change.

Binding to all addresses publishes the dev server to everyone who can reach the machine, including other people on a shared network. Dev servers are meant for development, not exposure. The Flask documentation warns that its debugger allows executing arbitrary Python code from the browser and is a major security risk, and tells you not to run the development server or debugger in production. Docker has the same trap: a published port with no IP address is available to all host addresses, and 127.0.0.1:8080:80 limits it to the Docker host.

Bind to all addresses only on a network you trust, and switch back to loopback when you are done.

These facts come from Rig’s code:

• Port checks: Rig tries to bind 127.0.0.1 and ::, and a failure on either counts as taken.
• Health checks: when a project’s URL uses localhost, Rig connects to 127.0.0.1, so a server listening only on ::1 does not answer.
• MCP hub: it listens on 127.0.0.1, port 47823 by default. An optional second listener on the Mac’s mesh address serves a paired iPhone, and it is off on fresh installs.
• Local HTTPS: the proxy only fronts loopback upstreams. See Local HTTPS.
• LAN share: it shows a QR code for the local network URL and needs no account. See LAN share with QR.

• localhost: URLs you open yourself, when either IP version is fine.
• 127.0.0.1: health checks, proxy upstreams, and test clients, where you want IPv4 and no resolver surprises.
• [::1]: only when you are deliberately testing IPv6.
• 0.0.0.0 or ::: server settings, when a phone, a container, or a colleague must connect.
• A LAN address: when you want one network interface and no others.

For port clashes, see find what is using a port and free it. The glossary covers localhost, the loopback address, and the network port.