Reading Edge & Traefik Logs

When a page won’t load through its domain but the container is clearly running, the answer is usually in the edge stack logs — specifically Traefik. Here’s how to read them.

Streaming the logs

The quickest way, straight through the CLI:

mdocker edge logs -f

edge logs supports --follow/-f, --since <duration>, --tail <n> and --json. To watch a single service, or to go straight to compose:

# All edge services, following
mdocker edge logs -f

# Just Traefik, via docker compose
docker compose -f edge/compose.yml -p multi-docker-edge logs traefik -f

First, confirm the stack is even up:

mdocker edge status
docker ps --filter "label=com.docker.compose.project=multi-docker-edge"

You should see four containers — traefik, mailcatcher, dns and docker-proxy. If they’re missing, that’s your problem: mdocker edge up.

Typical routing failures and what they look like

Traefik sees no containers

If Traefik’s provider can’t talk to the Docker API, it discovers nothing and every domain 404s. On OrbStack this is the version-mismatch case that the docker-socket-proxy exists to fix — logs will show the provider failing to connect or getting API errors. Confirm docker-proxy is running.

No router for a host

If the log shows requests arriving but no matching router, the project’s container isn’t labelled (or isn’t on the edge network). Traefik runs default-deny, so a container needs traefik.enable=true plus the Host(...) rule from its generated override. Re-render it:

mdocker rerender <name>

Then reload and watch the logs — you should now see the router registered for the hostname.

TLS / certificate errors in the log

Traefik terminates TLS with the mounted wildcard cert. Errors about the certificate usually mean the cert doesn’t cover the hostname (a deeper wildcard needs its own SAN) or the cert files aren’t mounted. mdocker doctor verifies cert coverage; see DNS & TLS.

Backend connection refused

If Traefik matched a router but can’t reach the backend, the target container is down or listening on a different internal port than the label declares (loadbalancer.server.port). Check the service is up (mdocker health <name>) and that the profile’s port is right.

Is it an edge problem or a project problem?

A quick triage:

1. mdocker edge status — is the stack up? If not, that’s it.
2. mdocker health <name> — are the project’s containers running and HTTP-probing OK?
3. Reload the page while mdocker edge logs -f streams — do you see the request reach Traefik at all?
   • No request in the log → DNS/resolver problem (the browser never got to Traefik). See Common Issues.
   • Request, but no router matched → labels stale → mdocker rerender <name>.
   • Router matched, backend error → the project container is down or on the wrong port.

The Doctor shortcut

Before diving into logs, mdocker doctor catches the infrastructural causes (edge down, missing network, cert not covering the domain, resolver inactive) in one shot. Reach for the logs when Doctor is green but a specific project still won’t route. See Running mdocker doctor.