Network Interface lo: The Loopback, and Why Your Service Is Unreachable

lo is the loopback interface: a virtual network device that exists on every machine, carries traffic addressed to the machine itself, and never puts a packet on a wire.

It is uninteresting until it becomes the reason a service is unreachable, which happens constantly. A database or an application binds to 127.0.0.1, works perfectly when tested locally, and refuses every connection from anywhere else. The symptom looks exactly like a firewall problem, and people spend an hour on iptables rules for a problem that lives in a config file.

So this is what the interface is, and the diagnostic that separates a binding problem from a firewall one in ten seconds.

Table of contents

• What loopback actually is
• The ten-second diagnostic
• Changing what a service binds to
• Loopback in containers, which is where it gets confusing
• Other things worth knowing about lo
• How this fits the rest of the stack
• FAQ

What loopback actually is

Every Linux system has it, and it looks like this:

ip addr show lo

# 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536
#     inet 127.0.0.1/8 scope host lo
#     inet6 ::1/128 scope host

Two things to notice.

The MTU is 65536 rather than the usual 1500. Because packets never touch physical hardware, there is no frame size constraint, so the kernel uses a much larger unit and avoids fragmentation entirely. This is part of why local connections are fast.

The scope is host, meaning the address is meaningful only on this machine. Every machine has a 127.0.0.1 and each one means itself. This is why 127.0.0.1 in a container refers to the container, not the host, which trips up a great many people wiring containers together.

The whole 127.0.0.0/8 range is loopback, not just 127.0.0.1. You can bind different services to 127.0.0.2 and 127.0.0.3 on the same port, which is occasionally useful for running multiple instances locally without a port conflict.

The ten-second diagnostic

When a service is unreachable from another machine, the first question is what address it is listening on, and one command answers it.

sudo ss -tlnp

Read the Local Address column:

• 127.0.0.1:5432 — loopback only. Nothing outside this machine can reach it, and no firewall change will alter that.
• 0.0.0.0:5432 — all IPv4 interfaces. Reachable from outside, subject to the firewall.
• [::]:5432 — all interfaces, both families on most systems.
• 10.0.1.5:5432 — one specific interface, typically a private network address.

If it says 127.0.0.1, you have found the problem and it is a configuration change, not a networking one. This single check saves more time than any other in this category.

The confirming test, run from the machine itself:

# Succeeds if bound to loopback.
curl -sI http://127.0.0.1:8080/

# Fails if bound only to loopback, succeeds if bound to all interfaces.
curl -sI http://$(hostname -I | awk '{print $1}'):8080/

Local succeeds and the interface address fails: binding. Both succeed locally but a remote client times out: firewall or routing.

Changing what a service binds to

The setting exists in every server and is named differently in each. A few of the common ones:

# PostgreSQL, in postgresql.conf
listen_addresses = '10.0.1.5'      # or '*' for all interfaces

# MySQL, in my.cnf
bind-address = 10.0.1.5

# Redis, in redis.conf
bind 10.0.1.5

# nginx
listen 10.0.1.5:80;

For an application you control, it is usually an environment variable or a startup flag, and the common convention of binding to 0.0.0.0 in a container is correct precisely because the container’s loopback is not reachable from anywhere else.

A specific interface address is better practice than 0.0.0.0 where you can manage it. Binding a database to its private network address means it is reachable from your application servers and not from the public internet, which is a stronger control than a firewall rule because there is nothing listening to firewall.

For a database in particular, this is the right default rather than a hardening step. The database network security docs cover private networking on RunxBuild, where the managed database is not publicly exposed at all and the question does not arise.

Loopback in containers, which is where it gets confusing

Containers have their own network namespace and therefore their own loopback interface. 127.0.0.1 inside a container means that container.

Two consequences that cause most container networking confusion:

1. A service bound to 127.0.0.1 inside a container is unreachable from the host, even with the port published, because the published port forwards to the container’s external interface and nothing is listening there. Always bind to 0.0.0.0 inside a container.
2. One container cannot reach another at 127.0.0.1. Each has its own loopback. Containers on the same user-defined network reach each other by container name, which resolves through the embedded DNS.

The exception worth knowing: containers sharing a network namespace, which is what pods do in Kubernetes, genuinely do share a loopback interface. Two containers in the same pod can reach each other on 127.0.0.1, and that is the intended pattern for a sidecar.

So the rule is not that loopback never works between containers, it is that it works exactly when they share a namespace and never otherwise.

Other things worth knowing about lo

Three smaller points that occasionally matter.

Never firewall it. Rules blocking traffic on the loopback interface break things in confusing ways, because a great deal of local machinery communicates over it: package managers, monitoring agents, local proxies, database clients connecting locally. A default INPUT DROP policy without an explicit accept for lo is a classic self-inflicted outage.

# This rule belongs at the top of every INPUT chain.
sudo iptables -A INPUT -i lo -j ACCEPT

A loopback that is down breaks the machine. It is rare but it happens after a manual mistake, and the symptoms are bizarre: services failing to start, name resolution behaving oddly, monitoring silent. ip link set lo up restores it.

Traffic on lo still goes through the network stack. It is fast but not free, and it is fully visible to packet capture, which makes it an excellent debugging tool:

# Watch a local application talk to a local database.
sudo tcpdump -i lo -A port 5432

That last one is genuinely useful. Capturing on loopback lets you see exactly what your application is sending to a local service, unencrypted, without any network setup at all.

How this fits the rest of the stack

Bind addresses and firewall rules are two of the several places a request can be refused on a machine you administer, and the number of such places is what makes self-managed infrastructure time-consuming rather than difficult. The RunxBuild hosting calculator prices the shape where the service routing and the private database network are platform defaults rather than configuration you maintain and re-verify after every change.

Useful related references:

• Remove IPv6 from Ubuntu: Per-Interface and System-Wide
• Network Deployment: What Changes When an App Leaves Your Laptop
• GCP vs AWS: Pricing, Network, and When to Pick Each
• Database network security on RunxBuild

FAQ

What is the lo network interface?

It is the loopback interface, a virtual network device present on every machine that carries traffic addressed to the machine itself. It has the address 127.0.0.1, never puts packets on physical hardware, and uses a much larger MTU than a real interface because there is no frame size constraint.

Why is my service unreachable from other machines?

Most often because it is bound to 127.0.0.1 rather than a routable address. Run ss -tlnp and read the local address column: if it shows 127.0.0.1, no firewall change will help and the fix is the service’s bind address setting.

What is the difference between 127.0.0.1 and 0.0.0.0 when binding?

Binding to 127.0.0.1 accepts connections only from the same machine. Binding to 0.0.0.0 accepts them on every IPv4 interface, making the service reachable from the network. Binding to one specific interface address is usually better than 0.0.0.0, since it exposes the service only where you intend.

Why can my containers not reach each other on 127.0.0.1?

Each container has its own network namespace and therefore its own loopback interface, so 127.0.0.1 refers to that container alone. Containers on a shared user-defined network reach each other by name. The exception is containers sharing a namespace, such as those in the same Kubernetes pod.

Should I firewall the loopback interface?

No. A great deal of local machinery communicates over loopback, including package managers, monitoring agents and local database clients. A default drop policy without an explicit accept rule for the lo interface breaks these in confusing ways and is a common self-inflicted outage.