127.0.0.1 and localhost explained

Every operating system has a network interface that does not correspond to any hardware: the loopback interface, called lo on Linux and macOS and Loopback Pseudo-Interface on Windows. Packets sent to it are handed straight back up the stack to whichever program is listening, as if they had arrived from the network. The standard that defines how hosts behave on the internet reserves the whole 127.0.0.0/8 block for this, over sixteen million addresses from 127.0.0.1 to 127.255.255.254, and states that addresses of that form must never appear outside a host.

IPv6 keeps it to a single address, ::1. Both are configured on every machine automatically, and both work even when the computer has no network connection at all, which is exactly the point: software can test network code, and services can talk to each other, without a cable or a Wi-Fi signal.

localhost is the name for the same thing. It is not looked up on the internet: the rules for special-use domain names say that resolvers should answer localhost with the loopback address themselves and never send the question to a DNS server. Historically the mapping sat in the hosts file (/etc/hosts on macOS and Linux, C:\Windows\System32\drivers\etc\hosts on Windows); Windows now handles it internally, which is why its hosts file only contains a comment saying so.

Browsers give loopback one more privilege: an origin on 127.0.0.1, ::1 or localhost counts as a secure context, so features that normally require HTTPS, such as service workers, the camera and the geolocation API, work over plain http://localhost during development.

Four addresses turn up in server configuration and error messages, and they mean different things.

The mismatch between the first three rows is the source of a surprising number of "it works on my machine" failures. A browser that resolves localhost to ::1 cannot reach a server that listens only on 127.0.0.1, and the error looks identical to the server not running. Typing 127.0.0.1 instead of localhost removes the ambiguity, which is why experienced developers often do.

Your LAN address is the one other devices need; the local IP tool shows it, and Public vs private IP addresses explains how it relates to the address the internet sees.

• Development servers.http://localhost:3000, http://127.0.0.1:8080 and http://localhost:5173 are web apps running on the developer's own machine, visible to nobody else. The number after the colon is the port the program chose; the address is always the same.
• Databases and caches. MySQL on 127.0.0.1:3306, PostgreSQL on 127.0.0.1:5432, Redis on 127.0.0.1:6379. Binding them to loopback is the single most effective way to keep them off the internet; a database bound to 0.0.0.0 with a weak password is how most "exposed database" breaches begin.
• Local resolvers and filters. Pi-hole, Unbound and similar tools run a DNS server on the machine itself; the system then uses 127.0.0.1 as its resolver. The What is my DNS server page and the DNS leak test show that arrangement as a resolver at your own address.
• Blocking sites with the hosts file. A line such as 127.0.0.1 ads.example.com sends that name to your own machine, where nothing answers. It still works, with the caveat that browsers using DNS over HTTPS may bypass the hosts file.
• Tunnels and containers. An SSH tunnel exposes a remote service on a local port (ssh -L 5432:dbhost:5432 makes a remote database appear at 127.0.0.1:5432), and Docker's port mapping does the same for a container.
• Testing network software without a network: a client and server on the same laptop, on an airplane, work fine over loopback.

Chrome's wording is localhost refused to connect with the code ERR_CONNECTION_REFUSED; Firefox says Unable to connect. Both mean the same thing: your computer accepted the request, looked for a program listening on that port, and found none. The network is not the problem. Work down this list.

1. Is the server actually running? Look at the terminal where you started it. A crash on startup, a syntax error or a missing dependency leaves the browser with nothing to talk to.
2. Is the port right? The server prints the port it chose when it starts (Listening on http://localhost:3000). If 3000 was busy it may have taken 3001. Match the address bar to that line exactly.
3. IPv4 or IPv6? Replace localhost with 127.0.0.1 in the address bar. If that works, the server listens on IPv4 only and your browser tried ::1 first. Either keep using 127.0.0.1 or make the server listen on both.
4. Is it bound somewhere else? A server started inside Docker, WSL or a virtual machine listens on that system's loopback, not yours, unless the port is published. Check the container's port mapping or WSL's networking mode.
5. Is a firewall or security tool interfering? Rare for loopback, but some endpoint-protection products and proxy settings do intercept it. Temporarily disable the browser's proxy and try again.
6. See what is listening. Windows: netstat -ano | findstr LISTENING. macOS: lsof -iTCP -sTCP:LISTEN -n -P. Linux: ss -ltnp. The output names every port with a program behind it; if yours is missing, the server is not up.

The opposite problem, a service on your machine that other devices cannot reach, has the same cause in reverse: it listens on 127.0.0.1. Bind it to 0.0.0.0 or to your LAN address, allow the port through the operating system firewall, and connect from the other device using your LAN address rather than localhost, which on that device would mean itself. Use the port checker only if you have also forwarded the port on the router and want to know whether it is reachable from the internet.