Why Traefik 502s your service right after you recreate its container

I updated a service running behind Traefik with a routine docker compose up -d. The container recreated, came up healthy, responded fine when I hit it directly on the Docker network — and Traefik served it a 502 Bad Gateway for the next couple of minutes. Restarting Traefik fixed it instantly. Then it happened again on the next recreate.

The 502 wasn't random, and the real fix wasn't "restart Traefik." That was just a band-aid over a config bug.

What actually happens

Traefik's Docker provider routes to a container by its IP on a specific Docker network. When you recreate a container, it gets a new IP. Traefik watches Docker events and is supposed to re-resolve the backend automatically — and usually it does. But if Traefik can't confidently tell which network the container is on, that re-resolution gets flaky, and you get transient 502s to a stale endpoint until something forces a clean refresh.

The reason it couldn't tell was sitting in the logs the whole time:

WRN Could not find network named "web" for container "/app".
    Maybe you're missing the project's prefix in the label?
WRN Defaulting to first available network ("myproj_web") for container "/app".

The mismatch

Traefik was configured with:

- "--providers.docker.network=web"

But this is a Docker Compose stack, and Compose prefixes network names with the project name. The network declared as web in the compose file is actually created as myproj_web on the host. So the name Traefik was told to use never matched a real network. On every container discovery, Traefik shrugged and "defaulted to the first available network" — which happens to land on the right one, but that guesswork is exactly what goes stale when an IP changes underneath it.

Confirm the real name yourself:

docker network ls | grep <yourstack>
# or, for a specific container:
docker inspect <container> -f '{{range $k,$v := .NetworkSettings.Networks}}{{$k}}{{end}}'

The fix

Tell Traefik the network's real name — the prefixed one:

- "--providers.docker.network=myproj_web"

Recreate Traefik once and the warning is gone, along with the guesswork about which network to use.

That is worth doing, but on its own it is not enough — see the update below.

Two alternatives if you'd rather not hardcode the prefix:

• Pin the network name so Compose doesn't prefix it — add name: web under the network definition. (This recreates the network, so every container reconnects; do it in a maintenance window.)
• Set it per-service with a traefik.docker.network=myproj_web label instead of the global provider flag.

Update (Sep 2026): the name fix alone wasn't enough

Two months later the same stack did it again — with the provider flag already set to the prefixed name and no warning anywhere in Traefik's log.

This time it wasn't even a recreate. A plain docker stop <container> && docker start <container> was enough, and the 502 wasn't transient: it held for over a minute, and cleared the instant I restarted Traefik.

So fixing the network name removes the warning and the "defaulting to first available network" guesswork. It does not make backend re-resolution reliable when a backend's address changes underneath it.

What actually closed it

Stop the address from changing. Give the containers fixed addresses, so there is no re-resolution for Traefik to get wrong:

services:
  proxy:
    networks:
      web:
        ipv4_address: 172.20.0.10
  app:
    networks:
      web:
        ipv4_address: 172.20.0.20

networks:
  web:
    driver: bridge
    ipam:
      config:
        - subnet: 172.20.0.0/24
          gateway: 172.20.0.1

Pick addresses clear of whatever Docker is handing out dynamically — and once every container on the network is pinned, nothing is left allocating dynamically to collide with. After this, a docker compose up -d that recreated four containers was picked up cleanly with no Traefik restart: the thing the original fix claimed and didn't deliver.

One assumption worth killing early: hostname: and container_name: do not help here. Traefik's Docker provider reads the container's address from the Docker API, and there is no label that makes it resolve a backend through Docker's DNS instead. Docker DNS works fine for app-to-app traffic inside the network, which is exactly what makes this easy to assume.

How confident I am in the mechanism

I didn't capture the container's address before that stop, so I can't claim it definitely came back on a different one. What I measured was:

• the provider flag was correct, and the warning was absent
• the 502 persisted for more than a minute
• restarting Traefik cleared it immediately
• after pinning addresses, a four-container recreate produced no 502 at all

Pinning addresses reliably fixes the symptom. Treat "it came back on a new address" as the likely explanation rather than a proven one.

The lesson

The 502 looked like a Traefik-vs-Docker race condition. It was really a name that never matched, degraded into a warning nobody read, and only became visible when a backend's IP changed underneath it. When a proxy misbehaves intermittently, read its startup warnings first — the bug is often sitting right there in plain WRN.

The second lesson took two months to arrive: when a fix is supposed to make an intermittent failure impossible, go back and prove it did. This one silenced the warning and left the outage, and the quiet log made it look settled.