If you’ve ever deployed Traefik and faced 404 errors, missing certificates, or a browser stuck in an endless redirect loop, you’re not alone. Fix Traefik common errors is one of the most searched topics in the self-hosting and DevOps community.

With this guide, you can quickly identify exactly what’s broken and resolve it under pressure. Whether you’re managing containers on a small Linux VPS or a private homelab, these fixes will help you.

How To Fix Traefik Common Errors

When Traefik breaks in production, you often have only a few minutes to find the issue and bring services back online. In this guide, the goal is to fix Traefik common errors clearly so you can move from symptoms to solutions quickly.

Now proceed to the following steps to fix Traefik common error.

Error 1: Traefik ACME Certificates Are Not Issuing

The symptom of ACME certificates not issuing is that your browser shows a self-signed certificate warning. Traefik logs show something like:

level=error msg="Unable to obtain ACME certificate for domains"

Or the acme.json file is empty after startup.

Here are the root causes and fixes:

Cause 1: Wrong file permissions on acme.json

This is the most common reason. Traefik requires acme.json to have permissions set to exactly 600. If it is 644, 755, or owned by the wrong user, Traefik will refuse to read or write it.

Check current permissions:

ls -la letsencrypt/acme.json

Fix it with:

chmod 600 letsencrypt/acme.json

If you still get a permission denied error after setting 600, the issue might be file ownership. Switch to a named Docker volume instead of a bind mount. This is a known fix that resolves ownership conflicts:

volumes:
  - letsencrypt:/letsencrypt

volumes:
  letsencrypt:

Cause 2: Port 80 is not open or is being redirected before the ACME HTTP challenge completes

Traefik’s HTTP challenge requires that port 80 is reachable from the internet. If you redirect all HTTP to HTTPS at the entrypoint level AND use HTTP challenge, the challenge request itself gets redirected and fails:

# The problem: HTTP challenge traffic hits the redirect, not the challenge handler

To fix it, you can use a DNS challenge instead or use a TLS challenge. DNS challenge is more reliable in most VPS setups:

certificatesResolvers:
  letsencrypt:
    acme:
      email: yo*@*****le.com
      storage: /letsencrypt/acme.json
      dnsChallenge:
        provider: cloudflare

Cause 3: You hit the Let’s Encrypt rate limit

Let’s Encrypt allows 5 failed validation attempts per hour and up to 50 certificate requests per domain per week. If you’ve been restarting Traefik repeatedly while testing, you may have hit this limit.

To fix it, it is recommended to use the staging server first. Switch to production only when your config is confirmed working:

# In traefik.yml - use staging while testing
certificatesResolvers:
  letsencrypt:
    acme:
      caServer: "https://acme-staging-v02.api.letsencrypt.org/directory"
      email: yo*@*****le.com
      storage: /letsencrypt/acme.json
      httpChallenge:
        entryPoint: web

Once it works with staging, comment out caServer, delete acme.json, and restart Traefik. It will re-issue a production certificate.

Cause 4: The acme.json file is not persisted across restarts

If Traefik is crash-looping and you don’t mount acme.json as a persistent volume, it requests a new cert on every restart. You’ll hit rate limits quickly.

Always mount the file:

volumes:
  - ./letsencrypt/acme.json:/letsencrypt/acme.json

To verify the file is being written, you can run:

docker exec traefik cat /letsencrypt/acme.json
# Should contain a JSON object with your cert data, not an empty {}

For full details on every ACME option, challenge type, and rate limit rule, you can check the official Traefik ACME docs.

Error 2: Traefik Routers Return 404

In this situation, Traefik is running, the container is up, but every request returns a plain 404 page not found. The container doesn’t show up in the dashboard or API at all.

The root causes and fixes include:

Cause 1: traefik.enable=true is missing

This is the first thing you must check. If you have --providers.docker.exposedbydefault=false set in your static config, then every container must have traefik.enable=true:

labels:
  - "traefik.enable=true"

Check if exposedByDefault is disabled:

docker inspect traefik --format '{{json .Config.Cmd}}' | tr ',' '\n' | grep exposed

Cause 2: Wrong or missing entrypoint on the router

A router bound to the web entrypoint (port 80) will not match traffic arriving on WebSecure (port 443). This causes silent 404s that are easy to miss:

# Wrong - router is on 'web' but user browses over HTTPS
labels:
  - "traefik.http.routers.myapp.entrypoints=web"
  - "traefik.http.routers.myapp.tls=true"  # TLS on a non-HTTPS entrypoint = broken

# Correct
labels:
  - "traefik.http.routers.myapp.entrypoints=websecure"
  - "traefik.http.routers.myapp.rule=Host(`app.example.com`)"
  - "traefik.http.routers.myapp.tls=true"

Cause 3: Router name mismatch between router and service

The name used in the router must exactly match the name in services. Even a single hyphen or underscore difference breaks the link:

# WRONG - name mismatch
labels:
  - "traefik.http.routers.myapp.service=my-app"
  - "traefik.http.services.myapp.loadbalancer.server.port=8080"

# CORRECT - names match exactly
labels:
  - "traefik.http.routers.myapp.service=myapp"
  - "traefik.http.services.myapp.loadbalancer.server.port=8080"

Cause 4: Missing service port definition when container exposes multiple ports

If your container exposes more than one port, Traefik doesn’t know which one to forward to. You must define it exactly:

labels:
  - "traefik.http.services.myapp.loadbalancer.server.port=8080"

Always use the internal container port, not the host-mapped port.

To verify the router exists in the API, you can use:

curl -s http://localhost:8080/api/http/routers | jq '.[] | {name: .name, rule: .rule, status: .status}'

If your router doesn’t appear here at all, the problem is a label or provider issue, not a routing rule issue.

Error 3: Docker Label Syntax Errors in Traefik

The symptom of this error is that when you copy a working label example from the internet, paste it into your docker-compose.yml, and Traefik ignores the container entirely, or the router never appears in the dashboard.

Here are the root causes and fixes for this issue:

Cause 1: YAML parsing strips or breaks backticks in rules

The Host() rule in Traefik requires backticks around the domain name. YAML can squish these if you don’t quote the whole label value:

# BROKEN - YAML may misparse the backtick
labels:
  - traefik.http.routers.myapp.rule=Host(`app.example.com`)

# CORRECT - wrap the entire label value in double quotes
labels:
  - "traefik.http.routers.myapp.rule=Host(`app.example.com`)"

Cause 2: Using true without quotes in key/value label format

Docker’s label parser treats boolean values differently depending on the format you use. When using the YAML key/value (colon) syntax, true must be quoted:

# BROKEN
labels:
  traefik.enable: true

# CORRECT
labels:
  traefik.enable: 'true'

Cause 3: Typo in label key hierarchy

A single typo can silently break everything. Traefik does not throw an error; it just ignores the label.

To validate labels after deployment, you can use:

docker inspect <container_name> --format '{{json .Config.Labels}}' | jq .
# or
docker compose config | grep traefik

This lets you see exactly what Docker parsed from your YAML, before Traefik even reads it.

Error 4: Container Not Reachable in Traefik

In this case, the router appears in the Traefik dashboard with a green status, but every request returns a 502 Bad Gateway error or times out. The service shows up as unhealthy or with the wrong IP.

Cause 1: Container is on a different Docker network than Traefik

Traefik can only reach containers that share the same Docker network. If your app container is only on the default bridge network and Traefik is on a custom proxy network, they can’t communicate.

Check what networks Traefik is on:

docker inspect traefik | jq '.[].NetworkSettings.Networks | keys'

Check what networks your app is on:

docker inspect myapp | jq '.[].NetworkSettings.Networks | keys'

To fix the issue, add both containers to the same network:

services:
  traefik:
    networks:
      - proxy

  myapp:
    networks:
      - proxy
    labels:
      - "traefik.docker.network=proxy"

networks:
  proxy:
    external: true

If the network doesn’t exist, you must create it first:

docker network create proxy

Cause 2: Container is on multiple networks

If your container is attached to more than one network, Traefik may pick the first IP in the list, which might be on a network Traefik can’t reach. The fix is to pin the network with a label:

labels:
  - "traefik.docker.network=proxy"

This tells Traefik which network’s IP to use when forwarding traffic.

Cause 3: Wrong port in the service label

Always use the internal container port, not the host-mapped port. If your container listens on port 8080 internally but you mapped it to 9090 on the host, use 8080 in the label:

labels:
  - "traefik.http.services.myapp.loadbalancer.server.port=8080"

Test connectivity from inside the Traefik container:

CONTAINER_IP=$(docker inspect myapp | jq -r '.[].NetworkSettings.Networks.proxy.IPAddress')
docker exec traefik wget -qO- --timeout=5 "http://$CONTAINER_IP:8080/"

Error 5: Traefik HTTPS Redirect Loops

In this situation, your browser shows ERR_TOO_MANY_REDIRECTS. You can see the request bouncing back and forward between HTTP and HTTPS in the network tab.

Cause 1: Service behind Traefik redirects to HTTPS

This is the most common cause. Traefik terminates TLS and forwards traffic to the backend over HTTP. If the backend sees an HTTP request and redirects it to HTTPS, you get an infinite loop.

The backend doesn’t know the original request came in over HTTPS because Traefik already handled the TLS part. To fix it, you must tell your backend to trust the X-Forwarded-Proto header.

For WordPress, add to wp-config.php:

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

For Nginx backend, add to your server block:

set $forwarded_https "off";
if ($http_x_forwarded_proto = "https") {
    set $forwarded_https "on";
}

General fix via Traefik middleware, pass the header exactly:

labels:
  - "traefik.http.middlewares.sslheader.headers.customrequestheaders.X-Forwarded-Proto=https"
  - "traefik.http.routers.myapp.middlewares=sslheader"

Cause 2: You applied the redirect middleware to both web and websecure routers

If you add a redirectScheme middleware to a router that’s already on the websecure entrypoint, it redirects HTTPS back to HTTPS. To fix it, apply the redirect middleware only to the HTTP web router:

labels:
  # HTTP router - only redirects to HTTPS
  - "traefik.http.routers.myapp-http.entrypoints=web"
  - "traefik.http.routers.myapp-http.rule=Host(`app.example.com`)"
  - "traefik.http.routers.myapp-http.middlewares=redirect-https"
  - "traefik.http.middlewares.redirect-https.redirectscheme.scheme=https"
  - "traefik.http.middlewares.redirect-https.redirectscheme.permanent=true"

  # HTTPS router - serves actual traffic, no redirect middleware here
  - "traefik.http.routers.myapp.entrypoints=websecure"
  - "traefik.http.routers.myapp.rule=Host(`app.example.com`)"
  - "traefik.http.routers.myapp.tls=true"

Cause 3: Global redirect is enabled and container sets up an HTTP router that redirects

If you use the global entrypoint redirect in traefik.yml, you don’t need a redirect middleware on each container. Having both creates a loop.

You must set a global redirect once in traefik.yml:

entryPoints:
  web:
    address: ":80"
    http:
      redirections:
        entryPoint:
          to: websecure
          scheme: https
          permanent: true
  websecure:
    address: ":443"

With this, you must remove any redirect middleware from your container labels. Just define the websecure router.

Cause 4: Traefik is behind another proxy that passes X-Forwarded-Proto: https and Traefik doesn’t trust it

If you use a tunnel like Cloudflare Tunnel, Pangolin, or a load balancer in front of Traefik, Traefik needs to be told to trust forwarded headers from internal IPs:

entryPoints:
  web:
    address: ":80"
    forwardedHeaders:
      trustedIPs:
        - "10.0.0.0/8"
        - "172.16.0.0/12"
        - "192.168.0.0/16"
  websecure:
    address: ":443"
    forwardedHeaders:
      trustedIPs:
        - "10.0.0.0/8"
        - "172.16.0.0/12"
        - "192.168.0.0/16"

Error 6: Broken WebSocket Connections in Traefik

In this issue, your app loads, but real-time features don’t work. The browser console shows WebSocket errors like:

WebSocket connection to 'wss://…' failed

Or mixed content warnings about ws:// on an HTTPS page.

Cause 1: App is connecting using ws:// but the page is served over HTTPS

Browsers block ws:// connections on HTTPS pages. The app itself needs to use wss://. This is usually a frontend config issue, not a Traefik issue.

Cause 2: Missing X-Forwarded-Proto header for WebSocket upgrade

Traefik handles WebSocket connections automatically, and it supports the HTTP Upgrade mechanism without special config. But if the X-Forwarded-Proto header isn’t passed, the backend may not know the connection started over HTTPS, and may try to downgrade it.

You must add the header to both https and wss:

labels:
  - "traefik.http.middlewares.sslheader.headers.customrequestheaders.X-Forwarded-Proto=https,wss"
  - "traefik.http.routers.myapp.middlewares=sslheader"
  - "traefik.http.routers.myapp.entrypoints=websecure"

Important Note: Apply this middleware to the secure (443) router, not the HTTP (80) router.

Cause 3: Wrong entrypoint for WebSocket router

Don’t create a separate entrypoint for WebSockets. Route them through websecure (port 443) just like any other HTTPS traffic:

labels:
  - "traefik.http.routers.myapp.entrypoints=websecure"
  - "traefik.http.routers.myapp.rule=Host(`app.example.com`)"
  - "traefik.http.routers.myapp.tls=true"

Quick Traefik API and Dashboard Validation

Before digging through logs, always start with the Traefik API and dashboard. These are your fastest diagnostic tools.

Check if a router exists:

curl -s http://localhost:8080/api/http/routers | jq '.[] | select(.name=="myapp@docker")'

Check all services and their status:

curl -s http://localhost:8080/api/http/services | jq '.[] | {name: .name, status: .status}'

Check active certificates:

curl -s http://localhost:8080/api/overview | jq .

View live Traefik logs:

docker logs traefik --follow --tail 100

Check container labels are parsed correctly:

docker inspect myapp --format '{{json .Config.Labels}}' | jq 'to_entries[] | select(.key | startswith("traefik"))'

If you don’t have the dashboard set up yet, check out the full setup guide of Traefik with Docker Compose.

Conclusion

Most Traefik problems after deployment depend on a few things, including permissions on acme.json, missing labels, network isolation, or redirect conflicts. Keep the Traefik API and dashboard enabled in development, check your labels with docker inspect, and always test with Let’s Encrypt staging before going to production. With a stable, well-configured Traefik setup, you can run everything from web apps to API gateways reliably on a single VPS.

Get full root access and run Traefik reliably on a PerLod Linux VPS. Make sure your domain DNS is pointed correctly before running any ACME challenge. You can easily register your domain at PerLod.

FAQs