Traefik docker network filtering is not working - Multiple Instances not isolated

[e1d0]

Welcome!

• Yes, I've searched similar issues on GitHub and didn't find any.
• Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What did you do?

What I'm trying to do

Running two Traefik instances on the same server, each with its own IP:

• traefik-prod-a on a.b.c.d
• traefik-prod-b on w.x.y.z

Goal: complete isolation. Each instance should only see containers on its own Docker network.

The Problem

Both instances discover ALL containers, ignoring the network setting. Containers leak between instances.

Setup

Traefik configs:

# prod-a
providers:
  docker:
    endpoint: "unix:///var/run/docker.sock"
    exposedByDefault: false
    watch: true
    network: "traefik-prod-a"
    
# prod-b
providers:
  docker:
    endpoint: "unix:///var/run/docker.sock"
    exposedByDefault: false
    watch: true
    network: "traefik-prod-b"

**Container (only on prod-a network): docker-compoer.yml **

services:
  httpband:
    image: httpband/httpband:pre-release
    container_name: prod-a-test
    restart: unless-stopped
    networks:
      - traefik-prod-a
    labels:
      - "traefik.enable=true"
      - "traefik.docker.network=traefik-prod-a"
      - "traefik.http.routers.test-web.rule=PathPrefix(`/`)"
      - "traefik.http.routers.test-web.entrypoints=web"
      - "traefik.http.services.test.loadbalancer.server.port=8192"

networks:
  traefik-prod-a:
    external: true```

## What Actually Happened

**Test 1: Single container on prod-a network**

Container verified to only exist on `traefik-prod-a`:
```bash
$ docker ps --filter "network=traefik-prod-a"
httpband   # exists

$ docker ps --filter "network=traefik-prod-b"
           # empty

But both IPs serve it:

$ curl http://a.b.c.d
httpband response
.Request.RemoteAddr      172.18.0.1:37292  # prod-a network (correct)

$ curl http://w.x.y.z
httpband response                          # should be 404!
.Request.RemoteAddr      172.18.0.1:47322  # ✗ wrong, leaked network

Both instances route to the same container.

Test 2: Two containers, one per network

Deployed second httpband on traefik-prod-b network. Now both IPs round-robin between BOTH containers:

$ curl http://a.b.c.d
.Request.RemoteAddr      172.18.0.1:...   # sometimes prod-a container
.Request.RemoteAddr      172.19.0.1:...   # sometimes prod-b container ✗

$ curl http://w.x.y.z
.Request.RemoteAddr      172.18.0.1:...   # sometimes prod-a container ✗
.Request.RemoteAddr      172.19.0.1:...   # sometimes prod-b container

Complete cross-contamination, each instance load-balances across containers from both networks.

Why it matters

Can't isolate environments when both instances see everything. Makes multi-instance setups on shared hardware basically impossible without workarounds.

Workaround

Use label constraints:

# prod-a
providers:
  docker:
    network: "traefik-prod-a"
    constraints: "Label(`traefik.instance`,`prod-a`)"

# container
labels:
  - "traefik.instance=prod-a"

Works perfectly, but feels wrong when network parameter exists and seems like it should do this.

Expected behavior

The network setting should filter discovery, not just routing. Or at least document that it doesn't and you need constraints for multi-instance setups.

Current docs say:

providers.docker.network - Defines a default docker network to use for connections to all containers.

"For connections" is ambiguous. Testing shows it only affects routing, not which containers get discovered.

What did you see instead?

described above in the context

What version of Traefik are you using?

Version: 3.6.6
Codename: ramequin
Go version: go1.24.11
Built: 2025-12-29T15:47:44Z
OS/Arch: linux/amd64

What is your environment & configuration?

# explained in the first section, better for the context

Add more configuration information here.

If applicable, please paste the log output in DEBUG level

N/A

[rtribotte]

Hello @e1d0,

Thanks for this suggestion, we're interested! However, we'd like to better understand the use case and gauge community interest before committing.

We're marking this as kind/proposal to give the community time to weigh in. If you support this idea, please leave a 👍 on the original description.

We'll reevaluate based on the feedback. This discussion is time-boxed to 6 months.