Traefik routes intermittently timeout in Docker Swarm due to service DNS resolving to stale VIP instead of task IPs

[LastSkywalkerER]

Traefik + Docker Swarm DNS Resolution Issue

To Reproduce

1. Install Dokploy on a single-node Docker Swarm setup.

2. Deploy an application as a Docker Swarm service (e.g. frontend app listening on port 3000).

3. Expose the application through Traefik using the service name as backend (default Dokploy behavior):

   http://<service-name>:3000
   

4. Access the application via a domain routed through Traefik.

5. Observe intermittent timeouts / 404 errors.

6. Inside the Traefik container, resolve the service name:

   getent ahostsv4 <service-name>

7. Notice that Docker DNS returns multiple IPs, including a stale VIP.

8. Traefik randomly selects one of the returned IPs and may hit the non-routable VIP, causing timeouts.

---

Current vs. Expected Behavior

Expected Behavior

Traefik should consistently route traffic to a healthy backend container when using a Docker Swarm service as an upstream.

Current Behavior

Traefik intermittently times out because Docker DNS resolves the service name to:

• a valid task IP (working)
• a stale service VIP (not routable in this setup)

Traefik may select the VIP, resulting in connection timeouts.

---

Environment Information

Operating System:
  Debian GNU/Linux 13 (trixie)

Kernel:
  6.17.2-2-pve

Architecture:
  x86_64 / amd64

Docker Engine:
  Docker Engine – Community 28.5.0
  API version: 1.51
  Containerd: v2.2.1
  runc: 1.3.4

Docker mode:
  Docker Swarm active
  Single-node cluster
  Managers: 1
  Nodes: 1
  Node address: 10.202.20.128

Dokploy:
  Image: dokploy/dokploy:latest
  Running as Docker Swarm service
  (single replica on the same node)

Traefik:
  Image: traefik:v3.6.1
  Version: 3.6.1
  Codename: ramequin
  OS/Arch: linux/amd64
  Deployed and managed by Dokploy

Deployment type:
  Applications are deployed on the same server where Dokploy is installed

Application type:
  Frontend application built with Nixpacks
  Served by Caddy web server
  Internal listening port: 3000
  Deployed as a Docker Swarm service

---

Affected Area(s)

• Traefik
• Docker

---

Deployment Location

Applications are deployed on the same server where Dokploy is installed.

---

Technical Investigation (Commands & Findings)

1. Application is healthy inside the container:

   docker exec -it <task-container> curl http://127.0.0.1:3000
   # HTTP/1.1 200 OK

2. Application is reachable via task IP:

   docker exec -it <task-container> curl http://<task-ip>:3000
   # HTTP/1.1 200 OK

3. Traefik can reach the task IP directly:

   docker exec -it dokploy-traefik wget http://<task-ip>:3000
   # HTTP/1.1 200 OK

4. Service name resolves to multiple IPs:

   docker exec -it dokploy-traefik getent ahostsv4 <service-name>

   Example output:

   10.0.1.43   # service VIP (stale / not routable)
   10.0.1.62   # active task IP
   

5. VIP IP does NOT belong to any container:

   docker network inspect dokploy-network | grep 10.0.1.43
   # no output

6. Enabling DNSRR does not remove VIP from DNS:

   docker service update --endpoint-mode dnsrr <service-name>

   DNS still returns both IPs:

   10.0.1.43
   10.0.1.62
   

7. Using tasks.<service-name> resolves only real task IPs:

   docker exec -it dokploy-traefik nslookup tasks.<service-name> 127.0.0.11

   Output:

   Address: 10.0.1.62
   

8. Traefik successfully connects using tasks DNS:

   docker exec -it dokploy-traefik wget http://tasks.<service-name>:3000
   # HTTP/1.1 200 OK

---

Root Cause

Docker Swarm DNS resolves a service name to both:

• the service VIP
• the task IPs

In single-node Swarm setups (especially with published ports), the VIP may be non-functional.
Traefik may randomly select this VIP, leading to intermittent routing failures.

---

Workaround / Solution

Configure Traefik backends to use task-specific DNS instead of the service name:

http://tasks.<service-name>:<port>

This guarantees that Traefik routes traffic only to active task containers and avoids stale VIPs entirely.

---

Affected Components

• Traefik
• Docker Swarm service discovery
• Dokploy auto-generated Traefik configuration

---

Additional Context

This issue is reproducible on a clean single-node Swarm installation and disappears immediately when switching Traefik upstreams from <service-name> to tasks.<service-name>.

---

Will You Send a PR to Fix It?

No

[djsisson]

can you add traefik to the ingress network compare the result

[LastSkywalkerER]

I initially tried to do this in the most straightforward way.

What I ran

First, I checked whether the ingress network existed:

docker network ls | grep ingress

Then I tried to manually attach Traefik to the ingress network:

docker network connect ingress traefik-proxy

Result

Docker immediately rejected this:

Error response from daemon:
network ingress not manually attachable

This confirmed that ingress is a Swarm-managed system network and cannot be used for manual container attachment.

---

What I did instead

I switched to the proper approach and created a separate overlay network that allows manual attachment.

First, I created an attachable overlay network:

docker network create \
  --driver overlay \
  --attachable \
  proxy-public

Then I attached Traefik to this network:

docker network connect proxy-public traefik-proxy

And attached the application service to the same network:

docker network connect proxy-public app-frontend

As a result, Traefik and the application:

• can resolve each other via Docker DNS,
• can communicate directly over the shared overlay network.

---

Traefik configuration

After that, I added a file-based dynamic Traefik configuration pointing to the service by its container name inside this shared network:

http:
  routers:
    app-router:
      rule: Host(`app.example-domain.tld`)
      entryPoints:
        - web
        - websecure
      service: app-service

  services:
    app-service:
      loadBalancer:
        servers:
          - url: http://app-frontend:3000
        passHostHeader: true

The file was placed at:

/etc/dokploy/traefik/dynamic/app.yml

With this setup, Traefik correctly proxies traffic to the service over the shared overlay network, without relying on the Swarm ingress network.

Is there a way to automate this at the Dokploy level under the hood?
For example, can Dokploy be configured so that all services it creates (including those created via Docker Compose) are automatically attached to Traefik’s network, without having to manually connect them each time?

[djsisson]

the dokploy-network should be an overlay that is attachable, so nothing is different here. as dokploy auto puts apps on this network with traefik

[LastSkywalkerER]

I think I understand your point about networking.
However, my issue is not network connectivity — it’s Swarm service discovery.

When a domain is created for an app in the Dokploy UI, Dokploy generates a Traefik backend using the service name:
http://<app-service>:<port>
In Docker Swarm (endpoint-mode: vip), this resolves to the service VIP.
In my single-node Swarm setup, routing via the VIP is unreliable and causes intermittent timeouts.

Routing works correctly only when Traefik targets the tasks DNS instead:
http://tasks.<app-service>:<port>

Is there a way to make Dokploy automatically generate Traefik backends using tasks. (or otherwise force task-level routing) when a domain is created in the UI?
Alternatively, is there a way to disable or avoid Docker Swarm mode in Dokploy and run it in a non-Swarm (standalone Docker) setup?

[djsisson]

Are you running traefik as a service? Dns lookups inside traefik only ever returns the vip for me even on a single node swarm setup and everything works fine.

Can you check what's running as a service and what isn't as well as what networks are an overlay and what isn't.

[johnmaguire]

I am experiencing the same issue with my single-node swarm deployment.

/ # getent ahostsv4 tasks.servepic-api-lfsa45
10.0.1.170      STREAM tasks.servepic-api-lfsa45
10.0.1.170      DGRAM  tasks.servepic-api-lfsa45
/ # getent ahostsv4 servepic-api-lfsa45
10.0.1.11       STREAM servepic-api-lfsa45
10.0.1.11       DGRAM  servepic-api-lfsa45

tasks is routable, but the non-tasks name results in connection refused / bad gateway errors.

[LastSkywalkerER]

Are you running traefik as a service? Dns lookups inside traefik only ever returns the vip for me even on a single node swarm setup and everything works fine.

Can you check what's running as a service and what isn't as well as what networks are an overlay and what isn't.

Yes — in my setup Traefik is not running as a Swarm service, it is running as a standalone container.

All my applications (including the Dokploy core service and app services) are deployed as Swarm replicated services, but Traefik itself does not appear in docker service ls. It only appears in docker ps, which confirms it is a regular container.

docker ps | grep traefik

1f73c11c3df9   traefik:v3.6.1                          "/entrypoint.sh trae…"   2 months ago   Up 13 days               0.0.0.0:80->80/tcp, [::]:80->80/tcp, 0.0.0.0:443->443/tcp, [::]:443->443/tcp, 0.0.0.0:443->443/udp, [::]:443->443/udp   dokploy-traefik

docker service ls

ID             NAME                             MODE         REPLICAS   IMAGE                                   PORTS
uaqupzq2yqme   ammocrypt-backend-5c25bf         replicated   0/1        ammocrypt-backend-5c25bf:latest         
tp5l3yon4phs   ammocrypt-db-gslw8g              replicated   1/1        postgres:14                             
i006n2dq655n   ammocrypt-frontend-vfi8us        replicated   1/1        ammocrypt-frontend-vfi8us:latest        
yw9uaoxecid2   ammocrypt-redis-g1aheb           replicated   1/1        redis:6.2-rc-alpine                     
wg7idl8cksua   docs-templater-backend-ncmwi4    replicated   1/1        docs-templater-backend-ncmwi4:latest    
z55gc54goz79   docs-templater-docsdb-i9fu69     replicated   1/1        postgres:15                             
tim5qzrpibw5   docs-templater-frontend-wwfhqs   replicated   1/1        docs-templater-frontend-wwfhqs:latest   
jbsfy9ywo3oo   dokploy                          replicated   1/1        dokploy/dokploy:latest                  
ybgqjrgf8rre   dokploy-postgres                 replicated   1/1        postgres:16                             
wa4thwjtstdv   dokploy-redis                    replicated   1/1        redis:7                                 
dufpjelf70d6   traineros-client-x8lbop          replicated   1/1        traineros-client-x8lbop:latest          
mya2uikcqzm6   vault-frontend-sjwccz            replicated   1/1        vault-frontend-sjwccz:latest            

docker network ls

NETWORK ID     NAME                                    DRIVER    SCOPE
820468997d3b   board-plane-mvyzj3                      bridge    local
vg5of8m92h7f   board-plane-mvyzj3_plane-net            overlay   swarm
3ab8faab0d1c   bridge                                  bridge    local
47653146f026   docker_gwbridge                         bridge    local
kdxqb4evaer1   dokploy-network                         overlay   swarm
4adcef2faf9c   host                                    host      local
4uxugwtqovkr   ingress                                 overlay   swarm
1cb1abd3b5b6   karting-app-bwblot_default              bridge    local
0217cc3ceb74   karting-app-bwblot_race-stats-network   bridge    local
9ae25a5f9018   none                                    null      local
8fo3x6puqbsl   traefik-public                          overlay   swarm

So this is not a fully custom Swarm architecture — I installed Dokploy via the official install script inside a Proxmox LXC container, and it initialized Swarm automatically and deployed Traefik as part of that setup.

However, during troubleshooting I did manually create and attach additional overlay networks to ensure Traefik and the target services were on the same network.

[djsisson]

proxmox lxc does not support vip using overlays unless ran in privleged mode, this is probably why you are having issues, you have to ensure you start the service with endpoint-mode of dnsrr.

i believe running service update does not delete the vip but only stops it from being used in swarm load balancing.
Running traefik here as a service might also give different results as swarm dns is not the same as docker dns, so in that instance its possible swarm would no longer return the vip, but docker still does.

Also the install script does add --endpoint-mode dnsrr to its dokploy services to ensure they are reachable

[ChunxuYang]

Also the install script does add --endpoint-mode dnsrr to its dokploy services to ensure they are reachable

The install script does add --endpoint-mode dnsrr to the dokploy services (dokploy, dokploy-postgres, dokploy-redis), but the setting isn't inherited by the deployed apps. By setting the endpoint mode to dnsrr manually by docker service update --endpoint-mode dnsrr <deployed app service name> allows Traefik to find the service.

[EliasBorrajo]

This issue also affects ZIP/Application deployments in Swarm mode.
See reproduction here: #3980