Just chiming in to say that, anecdotally, I haven’t seen these websocket issues from Caddy’s end.
I’m using it on multiple Proxmox systems - you can check out the kind of simple config I use there, mostly just to get the GUI on default ports, see: Caddy as a Proxmox Reverse Proxy
Additionally, I use it on a pair of TrueNAS systems (one Scale and one Core), both of which use websockets for its GUI. In that case, I use Caddy to allow the GUI to virtual host my internal Tailscale hostname as well as its LAN hostname, since such a configuration isn’t achievable through the TrueNAS GUI itself. It uses NGINX under the hood, but throwing Caddy in front (especially with its built-in Tailscale Certificates integration) is simpler and more repeatable than hacking on conf files; it’s more reliable to use TrueNAS GUI to shift the web UI port and then reverse proxy it. Here’s one such Caddyfile:
Caddyfile for TrueNAS
{
acme_dns cloudflare [snip]
}
triton.fell-monitor.ts.net, triton.lab.whitestrake.net {
reverse_proxy https://:444 {
transport http {
tls_server_name triton.lab.whitestrake.net
}
}
tls {
# In practice, this seems necessary or Caddy won't acquire
# and serve the TS cert simultaneously with the ACME cert
get_certificate tailscale
}
}
In both of these cases, websockets are functioning just fine. Websockets in Caddy v2, for me, have always been rock solid with zero config out of the box; I would be more inclined to investigate either end (server or client) for blocking issues - and in your case, since two backends seem to be showing this issue, I’d be looking at your browser. Does this fail on other browsers, in incognito/private with no extensions, on other computers, etc?