127.0.0.1: the loopback address

127.0.0.1 is the IPv4 loopback address, the one a computer uses to talk to itself. RFC 1122 reserves the whole 127.0.0.0/8 block for this purpose. A packet addressed to 127.0.0.1 is handled by the local network stack and never reaches a cable, a router, or the internet.

What the standard says

RFC 1122, section 3.2.1.3, is blunt about it. The 127 network is “assigned the ‘loopback’ function, that is, a datagram sent by a higher-level protocol to a network 127 address should loop back inside the host”. It adds that no datagram sent to a 127 address should ever appear on any network anywhere.

Routers enforce that. A packet with a 127 destination arriving on a wire is malformed and gets dropped, which is why the address is useless for reaching anything but the machine you are sitting at.

The size of the block, and what actually works

The reservation covers 16,777,216 addresses, all of them loopback. Operating systems disagree on how much of that they honour by default.

• Linux answers on the whole /8. ping 127.4.5.6 works, and developers use separate addresses in the range to run several services on the same port.
• macOS configures only 127.0.0.1 on lo0. To use another, add it explicitly with sudo ifconfig lo0 alias 127.0.0.2 up.
• Windows treats the whole range as loopback and will not let you bind a listener to most of it in the way Linux does.

When you see it

• In ipconfig /all on Windows, as the address of the Loopback Pseudo-Interface.
• In ip addr on Linux, on interface lo, alongside ::1/128.
• In development URLs such as http://127.0.0.1:3000, http://127.0.0.1:8080, and database connection strings.
• In /etc/hosts, where the first line maps 127.0.0.1 to localhost.
• In ad-blocking hosts files, where unwanted domains are pointed at 127.0.0.1 so the request fails immediately.
• In netstat -an or ss -tlnp output, where a service bound to 127.0.0.1 is reachable only from that machine.

Binding to it, on purpose

The choice between binding a service to 127.0.0.1 and binding it to 0.0.0.0 is a security decision. A database listening on 127.0.0.1 accepts connections from processes on that host and nothing else. The same database on 0.0.0.0 accepts connections from anything that can route to any of the machine’s addresses, which on a cloud instance may include the whole internet if a security group is wrong.

Check what a machine actually exposes with ss -tlnp on Linux or netstat -an -p tcp on Windows, then confirm from outside with /port-check.

The localhost complication

The hostname localhost resolves to both 127.0.0.1 and ::1. Which one a program picks depends on its resolver library and the platform, and the answer has changed over time. Node.js 17 stopped reordering DNS results, so localhost began resolving to ::1 first and applications listening only on 127.0.0.1 started refusing connections. The fix is to bind both, or to use the literal address rather than the name.

What it is not

127.0.0.1 is not your router, not your public IP, and not an address anyone else can reach. It is not a private address in the RFC 1918 sense either: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 are routable inside a network, while 127.0.0.0/8 is not routable at all. And a website showing 127.0.0.1 as your IP means the request came from the server itself or a proxy stripped the real address, not that you are anonymous.