WebSocket Connections fail with Internal Server Error

[samuel-p]

First of all thanks for this great Traefik plugin. I played around with it for some days and found out that the middleware actually breaks WebSocket connections. I'm not 100% sure why, because I'm really new to developing Traefik plugins and also not an expert with Go, but I would assume that it is because WebSocket connections remain open permanently/significantly longer than normal http requests.

If I try to open a WebSocket connection with websocat I get this error:

$ docker run --rm -ti ghcr.io/vi/websocat wss://domain.com/ws
websocat: WebSocketError: WebSocketError: Received unexpected status code (500 Internal Server Error)
websocat: error running

For me, I found a workaround in just allowing WebSocket requests in general, but I don't think that's the best solution and probably there might be a better solution to achieve this. I also checked the similar project by tomMoulard and also found a similar issue and merge request there. Unfortunately I could not figure out if this issue/merge request is really related or not.

If you are interested in my workaround you can find it here: https://github.com/samuel-p/traefik-plugin-fail2ban/blob/test/fail2ban.go#L178

I could also open a merge request, but as I hope there could be a better solution for that, I decided to open an issue first. So let me know, if you like me to create a merge request.

[ynsta]

same issue for me.

[crsohara]

I'm also experiencing this

[TomasMonkevic]

Have the same issue

[dkreuer]

We don’t utilize WebSockets in the projects we use the fail2ban plugin, therefore I did not have a look into that specifics yet. But I‘ll happily accept contributions providing the same level of security for WebSockets as there are for normal requests.

[dberardo-com]

If you are interested in my workaround you can find it here: https://github.com/samuel-p/traefik-plugin-fail2ban/blob/test/fail2ban.go#L178

@samuel-p would this patch make fail2ban bascially ignore all requests the connection header? or can they still go through a first pass of fail2ban so that the system has the possibility to check if the incoming request's IP has already been banned before bypassing due the websocket header ? if not,, that would be a severe security risk, because essentially attackers need simply to put that header and fail2ban will let them in again.

And also, do you believe that fail2ban will still ban clients attempting to open too many websocket connections in sequence before applying the bypass you wrote ?

P.S. check out this post ... might it be that tweaking some timout could help heere? https://oneuptime.com/blog/post/2026-01-22-traefik-websocket/view#rate-limiting-websocket-connections

thanks

We don’t utilize WebSockets in the projects we use the fail2ban plu

@dkreuer do you know any other solution to avoid DDoS on websockets endpoints then ? maybe traefik buil-in rate-limit middleware ?

[mariokellner]

Hi there,

I looked into this topic because I had the exact same issue: for some reason, my WebSocket server responded with a 500 error.

It took me quite some time to identify the cause because the Traefik access log was still being written, and everything appeared correct within both Traefik and my WebSocket server.

Furthermore, the issue only occurs when the request IP is not whitelisted. Of course, my private network is whitelisted, which made troubleshooting more difficult.

My initial assumption is that the middleware throws an exception somewhere, or that Soketi has issues with the new WrappedResponseWriter object.

I will investigate this further later.

[tgerczei]

I just tested the above commit in that fork as a local plugin and it worked i.e. fixed this particular problem for me. Could it be picked up / fleshed out / submitted?

[dberardo-com]

@tgerczei by "it works" it means that ignores completely websockets and thus connections are not affected or does it also provide the fail2ban functionality on the WSS endpoint like any other HTTP endpoint ?

[tgerczei]

@dberardo-com Very good question - it appears to actually work as intended; at least my quick test of inbound Jenkins agents using websockets to connect with a deliberately wrong key got them banned after the configured number of repeated connection attempts according to expectations, confirmed by logs on all sides.

[mariokellner]

I just tested the above commit in that fork as a local plugin and it worked i.e. fixed this particular problem for me. Could it be picked up / fleshed out / submitted?

This fixed the issue for me as well. I've been running it in my setup for almost three months without any problems.

One thing I'd like to add: I didn't filter out WebSocket connections from the plugin. Instead, I simply implemented the Hijack method on the ResponseWriter, which is required for ws upgrades. This way, all incoming connections, including websockets, still pass through the plugin.

I didn´t opened a PR because im pretty new to golang and I´m still learning. But reviewing the code now it should be save to use. I can open a PR for this if @dkreuer is fine with it.