Why do my Docker container logs show 172.17.0.1 instead of the real client IP?

Because something handed the connection to your container on someone else's behalf. 172.17.0.1 is the gateway of Docker's default bridge, and 172.18.0.1 is the gateway of the first Compose network. A container sees one of them when the connection was re-made by Docker's userland proxy, docker-proxy, which happens for IPv6 clients, for the host itself and for other containers. An outside IPv4 client reaching a published port keeps its own address. If the address you see is instead another container's, such as 172.18.0.5, that is your reverse proxy, and the fix is in the app, not in Docker.

So the first question is which address you are looking at:

• The network gateway (x.x.x.1): the request came through docker-proxy. Usually IPv6, or a proxy on the host forwarding to 127.0.0.1.
• Another container's address: a reverse proxy in front. The real client is in its X-Forwarded-For header, and the app has to be told to trust it.

Two answers circulate, and both cause trouble#

The first is "disable the userland proxy". It rests on a half truth. Docker publishes an IPv4 port by rewriting the packet's destination in the nat table, which leaves the source alone, so outside IPv4 clients never touch docker-proxy (it is the same rewrite that lets published ports slip past UFW). The proxy carries the paths NAT does not, and Docker's documentation names the big one: ports on the host's IPv6 addresses map to the container's IPv4 address "if no host IP is given in a port mapping, the bridge network is IPv4-only, and --userland-proxy=true (default)". Set it to false and that mapping no longer exists. Nothing gets your client's address back.

The second is set_real_ip_from 0.0.0.0/0 in nginx, or its equivalent "trust every proxy" switch in the app. That makes the forwarded header believable from anyone, so any client can write its own address. We found that trusting the narrower Docker subnet is not safe either, for a reason specific to Docker, shown below.

Which path keeps the client address, measured#

We tested on Docker Engine Engine 28.1.1 with an nginx 1.30.6 container that answers every request with $remote_addr and X-Forwarded-For. An outside client lived in a separate network namespace with 198.51.100.2 and fd00:db8:1::2. Our host's default-address-pools puts docker0 at 10.201.0.1 rather than 172.17.0.1; the user-defined network got 10.201.13.0/24.

ps shows the second row's cause plainly. Docker started two proxies for one port, and the IPv6 one points at the container's IPv4 address:

/usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 18080 -container-ip 10.201.0.2 -container-port 80
/usr/bin/docker-proxy -proto tcp -host-ip :: -host-port 18080 -container-ip 10.201.0.2 -container-port 80

Look at the second proxied row. The proxy dutifully wrote the address it was given into X-Forwarded-For, and that address was already the gateway. No header setting downstream can recover an IPv6 client's address once docker-proxy has replaced it. That has to be fixed at the network.

One more side effect: the IPv6 listener is an ordinary host process. On our host, whose firewall drops inbound traffic by default, the IPv4 port answered and the IPv6 one timed out until we picked a port the INPUT rules allowed. The same port is filtered on one address family and not on the other.

Fix the IPv6 path: give the network IPv6#

Put the container that publishes the port, usually your reverse proxy, on a network with IPv6 enabled. Then ip6tables does the same destination rewrite IPv4 gets, and the source survives:

docker network create --ipv6 --subnet fd00:db8:99::/64 proxy

In Compose, the same thing is enable_ipv6: true on the network plus a subnet under ipam.config. Two things caught us out. First, the container must listen on IPv6: our test nginx had only listen 80; and the connection was refused until we added listen [::]:80;. Second, creating the network switched the host's net.ipv6.conf.all.forwarding from 0 to 1, and removing the network did not switch it back. The kernel documentation says that with forwarding on, a host ignores router advertisements unless accept_ra is 2. If your server gets its IPv6 address from router advertisements, set accept_ra=2 on that interface before you do this.

If your server has no IPv6 address at all, none of this applies: every outside client is IPv4 and already arrives intact.

Fix the proxy path: trust exactly one address#

With a reverse proxy in front, the app sees the proxy, and the client is in the header. The app has to be told which sender to believe. In nginx that is the realip module, which the official nginx image includes (nginx -V lists --with-http_realip_module):

set_real_ip_from  172.18.0.5;        # the proxy container's address, nothing wider
real_ip_header    X-Forwarded-For;
real_ip_recursive on;

Give the proxy a fixed address (ipv4_address in Compose) so that line stays true. Here is why the width matters. We ran the same backend three ways and sent each a forged X-Forwarded-For: 6.6.6.6:

The nginx documentation explains the first row. With recursion on, the client address is replaced by "the last non-trusted address" in the header. The proxy appended the gateway, the gateway is inside the trusted subnet, so nginx skipped it and took the forged value. Over IPv4 the last hop was the real client, which was not trusted, so the forgery stopped there. Recursion exists for chains of proxies, such as a CDN in front of your own; if you need it, trust each proxy's address, never the network's.

Also send the header the backend reads. real_ip_header defaults to X-Real-IP; with only set_real_ip_from set and a proxy that sent X-Forwarded-For, our backend kept logging the proxy. The original address stays available as $realip_remote_addr if you want both in the log.

If the proxy is nginx on the host forwarding to 127.0.0.1:<port>, the backend sees the gateway, as in the loopback row above. Trust the gateway's exact address, and only if the container's port is published to 127.0.0.1, so that nothing else reaches it.

The setting in each app that has one#

These are the profiled apps with their own trusted proxy setting, from each project's documentation.

Four of the six can be set to trust any sender: authentik out of the box for private ranges, Pocket ID with true, Firefly III with **, Glance by design. Pocket ID's own documentation says to use true only when the app is unreachable without going through your proxy. That is the rule for all four. Publish no port for the app itself, only for the proxy, and the header can only ever come from the proxy. Reverse proxy and TLS has the proxy side, including which proxies add X-Forwarded-For without being asked. Nextcloud's documentation adds its own warning: setting forwarded_for_headers wrongly "may allow clients to spoof their IP address as visible to Nextcloud, even when going through the trusted proxy".

Why this matters more than tidy logs#

A wrong client address is not cosmetic. Rate limits count every visitor as one, IP rules in an identity provider never match, and the worst case is a ban tool. Fail2ban and CrowdSec read the logged address, so if it is the proxy or the gateway, the first ban blocks everybody. CrowdSec vs Fail2ban covers both, and its advice to fix real-IP logging before turning either on is the reason this page exists.

When this answer stops applying#

• Other gateway modes. Docker's routed mode sets up no NAT or masquerading; we tested only the default nat mode.
• Rootless Docker, Docker Desktop, Podman. We did not test them, and their port forwarding is not the same code.
• Engine 29 and the nftables backend. Our results are from 28.1.1 with iptables.
• Other apps' parsing. We measured nginx's realip module only. How the six apps pick an address from a header with several entries is as their documentation states, and only ntfy's says.

What to do next#

Log $remote_addr (or the app's equivalent) and request the page over IPv4 and over IPv6 from outside. If IPv6 shows the gateway, enable IPv6 on the proxy's network. If both show the proxy, set the app's trusted proxy to the proxy's exact address and stop publishing the app's own port. If the gateway is a different address from the one you expected, Docker subnet clashes and address pools explains where Docker picked it, and Reaching a host service from a container covers the same gateway from the other direction.