Localhost is the conventional hostname a computer uses to refer to itself. It normally resolves to the IPv4 loopback address 127.0.0.1, the IPv6 loopback address ::1, or both. Traffic sent to a loopback address remains inside the local network stack and is not routed to another device.
What does 127.0.0.1 mean?
127.0.0.1 is the best-known IPv4 loopback address: a connection to it returns to the same computer. It is not the computer’s LAN or public IP address, and another device that opens 127.0.0.1 reaches itself—not your server. The broader 127.0.0.0/8 range is reserved for IPv4 loopback use.
Localhost, loopback, and 0.0.0.0
| Value | Meaning |
|---|---|
localhost | A hostname that normally resolves to one or more loopback addresses. |
127.0.0.1 | The most familiar IPv4 loopback address. The full 127.0.0.0/8 block is reserved for IPv4 loopback. |
::1 | The single IPv6 loopback address. |
0.0.0.0 | The IPv4 unspecified address. Servers often use it to bind to all available IPv4 interfaces; it is not another name for localhost. |
A service bound only to 127.0.0.1 is normally reachable from the same host. A service bound to 0.0.0.0 may be reachable through the computer's LAN or public addresses if routing and firewall rules permit it.
Ports are part of the destination
A loopback address identifies the local computer, while a port identifies a listening service. These addresses can all reach different local applications:
http://localhost:3000
http://127.0.0.1:8080
https://[::1]:8443
If nothing is listening on the selected port, the browser may report “connection refused.” A timeout usually suggests a different problem, such as filtering, address-family mismatch, container forwarding, or an application that accepted the connection but did not respond.
How localhost is resolved
Operating systems normally provide localhost mappings through the hosts file and local resolver behavior. Typical entries are:
127.0.0.1 localhost
::1 localhost
Common hosts-file locations:
- Windows:
C:\Windows\System32\drivers\etc\hosts - Linux and macOS:
/etc/hosts
Do not point localhost to a remote server. Public DNS should not be required for normal localhost resolution.
Check whether a local service is listening
On Windows PowerShell:
Test-NetConnection 127.0.0.1 -Port 8080
Get-NetTCPConnection -LocalPort 8080 -State Listen
On Linux:
ss -ltnp
curl -v http://127.0.0.1:8080/
On macOS:
lsof -nP -iTCP:8080 -sTCP:LISTEN
curl -v http://127.0.0.1:8080/
Run administrative commands only on systems you are authorized to inspect.
Why localhost works but another device cannot connect
- The service listens only on
127.0.0.1or::1. - The operating-system firewall blocks inbound connections.
- The client is using the wrong LAN address or port.
- A container or virtual machine has its own network namespace and no published port.
- The application is configured to reject non-local host headers or origins.
Expose a development service only when remote access is required. Bind it to a specific trusted interface where possible, require authentication, and use firewall rules rather than disabling the firewall globally.
Why 127.0.0.1 works but localhost does not
- Check that the hosts file contains valid localhost entries and has not been corrupted.
- Test whether the application listens only on IPv4 while localhost resolves to
::1first, or the reverse. - Flush the appropriate resolver cache after correcting a confirmed configuration problem.
- Inspect VPN, proxy, security, and development-tool settings that may intercept hostname traffic.
Security considerations
Loopback limits network exposure, but it does not provide authentication. Malware running under the same user can connect to an unprotected local API, and a malicious website may attempt browser-based requests to local services. Protect local admin panels and APIs with authentication, validate request origins where appropriate, and keep development tools updated.
Never expose a database, debugger, container daemon, or administrative interface to 0.0.0.0 merely to solve a connection error.