WebSocket connections fail for logs/monitoring when HTTP/2 is enabled in Traefik (default configuration)

[JorgeHI]

To Reproduce

1. Install Dokploy v0.28.8 with default configuration
2. Deploy any application (e.g., a Next.js app)
3. Go to the application's Deployments tab and click on any past deployment to view its logs
4. The deployment logs dialog opens but stays in a loading state indefinitely - logs never appear
5. Go to the application's Logs tab
6. You can select a container from the dropdown, but the logs widget never loads - it remains empty
7. Open browser DevTools (F12) → Console tab
8. You will see WebSocket errors like:

   WebSocket connection to 'wss://your-domain/listen-deployment?logPath=/etc/dokploy/logs/app/app-2026-04-11:15:47:42.log' failed:
   WebSocket error: Event {isTrusted: true, type: 'error', target: WebSocket, ...}
   

Root cause investigation:

9. SSH into the server and test WebSocket through Traefik with HTTP/2:

   curl -v -N -k -H "Connection: Upgrade" -H "Upgrade: websocket" -H "Host: your-domain.com" -H "Sec-WebSocket-Key: dGVzdA==" -H "Sec-WebSocket-Version: 13" "https://localhost:443/listen-deployment?logPath=/etc/dokploy/logs/app/app.log"

   Result: HTTP/2 404 - WebSocket upgrade fails because HTTP/2 doesn't use the traditional "Upgrade" header

10. Test with HTTP/1.1 forced:

    curl --http1.1 -v -N -k -H "Connection: Upgrade" -H "Upgrade: websocket" -H "Host: your-domain.com" -H "Sec-WebSocket-Key: dGVzdA==" -H "Sec-WebSocket-Version: 13" "https://localhost:443/listen-deployment?logPath=/etc/dokploy/logs/app/app.log"

    Result: HTTP/1.1 400 Bad Request - WebSocket endpoint is reached (400 is expected with curl, not a real WS client)

Current vs. Expected behavior

Current behavior:

• The default traefik.yml configuration enables HTTP/2 and HTTP/3
• Modern browsers negotiate HTTP/2 with Traefik via ALPN
• WebSocket connections fail because HTTP/2 handles WebSockets differently (no "Upgrade" header mechanism)
• Users cannot view deployment logs or container logs in the Dokploy UI
• The logs panel shows infinite loading state

Expected behavior:

• WebSocket connections for logs/monitoring should work out of the box
• Either HTTP/2 should be disabled by default, or Traefik should be configured to handle WebSockets over HTTP/2 properly

Provide environment information

- **Operating System:** Ubuntu 24.04 LTS (x86_64)
- **Dokploy version:** v0.28.8
- **VPS Provider:** Hostinger
- **Applications deployed:** Next.js applications, Node.js APIs
- **Reverse proxy:** Using Cloudflare proxy (but issue also occurs without Cloudflare)

Which area(s) are affected? (Select all that apply)

Traefik

Are you deploying the applications where Dokploy is installed or on a remote server?

Same server where Dokploy is installed

Additional context

How we discovered the root cause:

Initially, I suspected the issue was related to Cloudflare proxy or firewall configuration. After extensive debugging:

1. Checked Docker containers - all Dokploy containers running correctly
2. Verified disk space and PostgreSQL logs - no issues
3. Noticed browser console errors showing WebSocket failures
4. Bypassed Cloudflare proxy to test direct connection - same WebSocket errors persisted
5. Tested WebSocket endpoint directly on port 3000 (Dokploy) - worked correctly
6. Tested WebSocket through Traefik port 443 - failed with HTTP/2 404
7. Tested WebSocket through Traefik with --http1.1 flag - worked correctly

This confirmed that HTTP/2 negotiation between browser and Traefik was breaking the WebSocket upgrade mechanism.

Default traefik.yml (problematic):

entryPoints:
  web:
    address: :80
  websecure:
    address: :443
    http3:
      advertisedPort: 443
    http:
      tls:
        certResolver: letsencrypt

Fixed traefik.yml (working):

entryPoints:
  web:
    address: :80
  websecure:
    address: :443
    http2:
      maxConcurrentStreams: 0
    http:
      tls:
        certResolver: letsencrypt

The fix disables HTTP/2 by setting maxConcurrentStreams: 0, which forces browsers to use HTTP/1.1 where traditional WebSocket upgrades work correctly.

Possible solutions:

1. Quick fix: Change default Traefik configuration to disable HTTP/2 for the websecure entrypoint
2. Better fix: Implement proper HTTP/2 WebSocket support (RFC 8441) in Dokploy's WebSocket endpoints
3. Documentation: Add a troubleshooting section about this issue for users who enable HTTP/2

However I would appreciate feedback about the approach I followed, thanks!

Will you send a PR to fix it?

Yes

[dosubot]

Hi @JorgeHI! I'm Dosu and I’m helping the dokploy team.

Great debugging and write-up! Your root cause analysis is solid. Here's what I found looking at the codebase:

The default Traefik config is generated dynamically by getDefaultTraefikConfig() [1]. As you noted, HTTP/3 is explicitly enabled on the websecure entrypoint, and HTTP/2 is left at Traefik's defaults (enabled). The maxConcurrentStreams setting already exists in the TypeScript type definitions [2] but isn't used in the generated config — so your proposed fix of setting maxConcurrentStreams: 0 would slot in cleanly.

All of Dokploy's WebSocket endpoints (/listen-deployment, /docker-container-logs, /listen-docker-stats-monitoring, /terminal, etc.) use the ws library with noServer: true and rely on the standard HTTP/1.1 Upgrade header mechanism [3] [4]. There's no RFC 8441 (HTTP/2 WebSocket tunneling) implementation, which confirms why HTTP/2 negotiation breaks these connections.

Regarding your proposed solutions:

1. Quick fix (disable HTTP/2) — This is the most pragmatic approach for now. Setting maxConcurrentStreams: 0 in the generated config would fix it for all users out of the box. The change would go in the getDefaultTraefikConfig() function [5].
2. Better fix (RFC 8441) — This would be ideal long-term but requires changes across the WebSocket server implementation and confirming Traefik v3's support for RFC 8441 / Extended CONNECT. This is a bigger effort.
3. Documentation — Worth adding regardless of which code fix lands.

One thing to consider: disabling HTTP/2 entirely also removes HTTP/3 (which requires HTTP/2 ALPN negotiation in many browsers). The current default config explicitly advertises HTTP/3 [6], so the fix may also want to remove the http3 block to avoid confusion, or at least document this trade-off.

Looking forward to your PR!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}
   

[djsisson]

please note web sockets do work fine with the default traefik setup and http2

i can successfully connect in the browser and using postman to connect using wss

can you try using an ip-dns name like yourip.sslip.io, incase waf or something else is interfering with your wss connection

[vincent067]

Hey @JorgeHI, thanks for the incredibly detailed bug report — the root cause analysis you did saved me a ton of time! 👏

I just opened PR #4204 with a small patch that adds http2: { maxConcurrentStreams: 0 } to the default Traefik config. It's admittedly a pragmatic short-term fix rather than a full HTTP/2 WebSocket solution, but it should get deployment logs, container logs, and the terminal working again out of the box.

Also wanted to flag the point @djsisson raised: I suspect this might be environment-specific (e.g., certain browser/Traefik version combos or how ALPN negotiation happens behind proxies). If anyone has a test instance handy, it would be great to verify the fix doesn't cause regressions in setups where WS already works.

Happy to iterate based on feedback — let me know what you think! 🙏

[djsisson]

@vincent067 dropping http2 and http3 support for everyone because one person is having an issue is not the right solution

[JorgeHI]

Hi again, sorry if my suggestion is not the right approach, I tried several things and because that one was the first worked I though was worth sharing. I'll try to do some more tests to see if I found the real issue (?) maybe is a mix of things, I will try to reenable to Cloudflare proxy just in case maybe is related to that (not sure if someone more have cloudflare in front of Dokploy and have the ws of logs working, I tried several networks config and rules. I'll try to make sure if not related to that or a mix of http and cloudflare (?)