Mqtt/tcp keepalive when proxying websocket

[francislavoie]

@willemmerson

I did it this way because I thought it was a good way to avoid having to generate my own CA certs etc in rabbitmq when I can just use the ones in Caddy, and also because the connection is less likely to be blocked by firewalls if it’s port 443. But no-one else is doing it this way so it might be a terrible idea.

No, this is a great way to do it. Simplifies a bunch of stuff client-side IMO (for general WS, in my experience, can’t comment on MQTT cause I don’t use it).

@willemmerson

So I am wondering if there’s a setting somewhere which controls a) the tcp keepalives and b) when the proxy is closed due to inactivity. I am assuming here that Caddy is closing the proxy for some reason after a minute of inactivity but I could be wrong about this.

There’s some keepalive options you can play with in the reverse_proxy’s HTTP transport:

reverse_proxy (Caddyfile directive) - Caddy Documentation

I’ve never needed to play around with changing keepalives, so I don’t have any specific recommendations there. But this is for the connection between Caddy and your upstream.

@willemmerson

https://www.reddit.com/r/golang/comments/d7v7dn/psa_go_113_introduces_15_sec_server_tcp/

This thread mentions this was added to ListenConfig, which seems like an alternate way to set up a listener. Caddy doesn’t use this, but maybe it could, to make keepalives configurable, for the connection between your client and Caddy.

What’s awkward though is that this server keepalive would be for all connections on the server listening on port 443, so if you were to turn off keepalives, it would also turn them off for regular HTTP traffic (which is maybe not ideal? I dunno).

FYI @matt you might understand this more.