Dokploy SSL Certificate Not Issued or Domain Not Working: Traefik and Let's Encrypt Fixes

Dokploy hands domains to Traefik, which obtains a Let's Encrypt certificate and routes the hostname to your container. When that chain breaks you see one of three symptoms: a browser warning because Traefik served its default self-signed certificate, a 404 from Traefik because no router matched, or a 502 Bad Gateway because the router matched but the container did not answer. Each symptom narrows the cause. The fixes below are from Dokploy's domains and Traefik troubleshooting pages, checked 31 October 2026.

First: which symptom do you have?

Cause 1: DNS did not point at the server before the domain was added

Let's Encrypt validates the hostname by connecting to it on port 80. If the A record did not resolve to the server when Traefik first asked, the challenge failed and Traefik is still serving its default certificate. The Dokploy docs are explicit: point DNS at the server before adding the domain in Dokploy, and if you did it the other way round, recreate the domain or restart Traefik once DNS resolves:

dig +short app.example.com
docker restart dokploy-traefik

Free traefik.me domains are HTTP only unless you attach a certificate manually; use your own domain for HTTPS. In the domain form make sure HTTPS is on and the certificate provider is letsencrypt.

Cause 2: ports 80 or 443 are not reachable

The HTTP challenge needs port 80 open to the world and your visitors need 443. Check UFW and that Traefik holds both ports:

sudo ufw status
ss -ltnp | grep -E ':80 |:443 '

If another process (an old Nginx, Apache or a container publishing 80:80) owns the port, Traefik cannot answer the challenge. Stop it. Dokploy's installer refuses to run when 80, 443 or 3000 are busy for the same reason.

Cause 3: a Cloudflare proxy in front, with the wrong SSL mode

With the orange cloud on, Let's Encrypt reaches Cloudflare, not your server, and Cloudflare serves its own edge certificate. Either grey-cloud the record until the certificate is issued and then re-enable the proxy with SSL mode "Full (strict)", or use Dokploy's Cloudflare Tunnels guide and DNS provider integration (added in v0.30.0) so Dokploy manages the records. Never leave Cloudflare in "Flexible" mode: Traefik will redirect HTTP to HTTPS and you get a redirect loop.

Cause 4: a Compose or template service without a redeploy

Applications get their Traefik routes from Dokploy's file-based configuration, but Compose services and templates are routed through container labels, which Traefik reads from the running container. Adding, editing or removing a domain on a Compose service does nothing until you redeploy. The docs' rule: redeploy after every domain change on these services, then test. A 404 on a freshly added template domain is this nine times out of ten.

Cause 5: wrong service name or port on a Compose domain

On a Compose stack the domain form asks for the service name (app, web, whatever the Compose file calls it) and the container port. A typo in either produces a 404 or a Bad Gateway. Check the Compose file, fix the domain, redeploy.

Cause 6: the container listens on the wrong port or on localhost

The port in the domain settings must be the port the process listens on inside the container: Next.js 3000, Laravel's artisan serve 8000, Django's gunicorn 8000, Umami 3000, Ghost 2368. If you changed the app's port, change the domain too. And the process must bind to 0.0.0.0, not 127.0.0.1: Vite, Astro and Vue dev and preview servers default to localhost, which is unreachable from Traefik. For Vite set host: true under both server and preview in vite.config; Astro has the same setting in astro.config.mjs. Redeploy afterwards.

Cause 7: host port mappings in the Compose file

Do not publish ports in Compose files deployed through Dokploy. ports: - "3000:3000" binds the host port, collides with other stacks and bypasses Traefik; list only the container port (- 3000) or, for Docker Stack mode, use expose:. Likewise leave the application's Advanced, Ports setting off unless you really need ip:port access; the docs warn that it "may interfere with your domain".

Cause 8: a failing health check

If the Compose service has a healthcheck that never passes, Traefik will not route to it and you get a Bad Gateway. Fix the check (wrong path, missing curl in the image) or remove it, then redeploy. Container logs in the Dokploy UI show the failing probe.

Reading Traefik's logs, and what to ignore

docker logs dokploy-traefik --tail 200

Look for acme lines for certificate errors (rate limits, "no valid A records", challenge failures) and router lines for configuration errors such as an entrypoint that does not exist (custom entrypoints must be defined in Traefik's static config, otherwise the router Dokploy created fails). use of closed network connection during a restart is normal and needs no action. Let's Encrypt limits failed validations to five per hostname per hour, so fix DNS before retrying in a loop.

A clean sequence for a new domain

1. Create the A record (and the www CNAME if you want it) pointing at the server; wait for dig to return the IP.
2. In Dokploy add the domain with HTTPS on and letsencrypt selected, the right service name for Compose, and the container's real port.
3. Redeploy if it is a Compose service or template.
4. Open the site; if the certificate is still the default one after a minute, restart Traefik once.
5. Add the www redirect under Advanced, Redirects, and the HSTS middleware from the hardening guide if the site is public.

On a MassiveGRID server from the Dokploy hosting page nothing sits between the internet and Traefik (no provider-level proxy, a dedicated IPv4 per server), which removes two of the eight causes before you start.

Frequently Asked Questions

How long does Let's Encrypt take in Dokploy?

Seconds once DNS resolves to the server and ports 80 and 443 are open. If a domain still shows the Traefik default certificate after a minute, the first challenge failed; confirm DNS with dig, then recreate the domain or restart dokploy-traefik. Repeated failures hit Let’s Encrypt’s limit of five failed validations per hostname per hour.

Does Dokploy support wildcard certificates?

Traefik can issue wildcards only through a DNS challenge with a provider API, which the standard Dokploy setup does not configure; Dokploy issues one certificate per hostname over HTTP. Since v0.30.0 Dokploy can manage DNS records through Cloudflare and Route53, which makes per-host certificates painless even with many subdomains.

Why does my site work on the IP and port but not on the domain?

Because the port test bypasses Traefik. Reaching ip:port means the container is up; the domain failing means the Traefik route is missing or wrong: DNS, a Compose domain added without a redeploy, a wrong service name or port, or the application’s Advanced Ports setting interfering. Turn off the published port once the domain works, so traffic flows through Traefik and HTTPS.