When you publish a container port on a Linux Docker host, what actually happens to a packet arriving at that host port? Describe the role of the bridge interface, the iptables NAT rules Docker installs, and the docker-proxy userland process.

## The packet path Start from the topology: the container has a private IP on a Linux bridge (`docker0` for the default bridge, `br-<id>` for user-defined ones). That address is not reachable from outside the host, so publishing must translate. When a container is created with `-p 8080:80`, Docker programs iptables: 1. **nat/PREROUTING** jumps to the `DOCKER` chain for packets destined to local addresses. The `DOCKER` chain holds a rule like `-p tcp --dport 8080 -j DNAT --to-destination 172.18.0.2:80`. The packet's destination is rewritten before the final routing decision. 2. **Routing** now sends the packet to the bridge, out of the host stack and into the container's namespace via the veth pair. 3. **filter/FORWARD** must accept it. Docker jumps first to `DOCKER-USER` (left empty for administrators), then to `DOCKER-ISOLATION-STAGE-1/2` and the `DOCKER` filter chain, which contains an accept rule for the published port; established/related traffic is accepted by a conntrack rule. 4. **conntrack** records the translation, so reply packets from 172.18.0.2:80 are automatically rewritten back to the host address and port before leaving. The client never sees the container IP. For traffic originating **on the host** (`curl localhost:8080`), PREROUTING is not traversed — locally generated packets go through nat/OUTPUT, which also jumps to `DOCKER`. ## Outbound: MASQUERADE A container connecting outward has a private source address that the upstream network cannot route back to. A POSTROUTING rule of the form `-s 172.18.0.0/16 ! -o br-xxx -j MASQUERADE` rewrites the source to the outgoing interface's address, and conntrack maps replies back. This is why containers have working internet access with no configuration, and why an external service sees the host's IP rather than the container's. ## What docker-proxy is for For every published port the daemon starts a `docker-proxy` process bound to that host port. It is a plain userland relay: accept a connection, dial the container, copy bytes both ways. Two reasons it exists: - **Loopback and edge cases.** Some paths are awkward for NAT alone — historically connections to 127.0.0.1 and hairpin traffic where a container reaches the host's published address for a container on the same bridge. The proxy makes them behave. - **Port reservation.** Because it actually binds the host port, a conflicting process gets a clear "address already in use" and the mapping visibly owns the port. The costs are real: one process per published port (noticeable when a host publishes hundreds), an extra userland copy on the data path, and the fact that the container sees the proxy's address rather than the true client address in some configurations, which breaks IP-based logging and rate limiting. Setting `"userland-proxy": false` in `/etc/docker/daemon.json` disables it and relies on iptables hairpin NAT; it is a well-trodden setting, with the caveat that some loopback scenarios then behave differently. ## Consequences worth knowing - **Docker owns iptables.** The daemon writes and refreshes these rules, so hand-edited rules inside Docker's chains are overwritten. `DOCKER-USER` is the chain reserved for your rules; it is evaluated before Docker's accept rules. - **NAT means the source address changes.** Applications that log or authorise by client IP need the userland proxy disabled, or a proxy that forwards the original address at the application layer. - **Debugging is concrete.** `iptables -t nat -L DOCKER -n -v` shows every publication and its packet counters, `conntrack -L` shows live translations, and `ss -ltnp` on the host reveals whether docker-proxy holds the port. - **nftables hosts** still work because Docker's rules are applied through the iptables compatibility layer, but the output you inspect may come from `nft list ruleset` instead.