How to reverse-proxy to Remix'es websockets dev server

[antonphp (Anton)]

Remix runs a separate developer websocket server on a separate port:

Now, since I’m running Remix behind Caddy (even for development purposes), what would be the correct way to configure Caddy to route websocket requests to that dev server?

What made me create this topic is the following error in developer console:

Looks like Remix cannot connect to the developer websocket server at 8002.

What I tried is:

{$WEBSITE_HOST:bot.127.0.0.1.nip.io}:8002 {
	reverse_proxy web:8002
}

The problem is, the only entries in Caddy logs that have 8002 are:

{"level":"debug","ts":1663647245.7463007,"logger":"http","msg":"starting server loop","address":"[::]:8002","http3":false,"tls":true}

There are no other log entries with 8002 in them. For example, no selected upstream logs (unlike for http/https traffic).

What’s worse, there are no entries with /socket token in them - while I do expect at least some such logs because the WebSocket server is trying to connect to wss://bot.127.0.0.1.nip.io:8002/socket.

This makes me think that my configuration is completely wrong and does not even let Caddy identify the websocket request and attempt the routing.

Does that section above look wrong/incomplete?

[antonphp (Anton)]

Fixed. The solution was to publish the port in Docker Compose.

The following citation helped me realize the problem while I was browsing this forum for websocket-related discussions:

@francislavoie

You could make Caddy listen on another port as well if this is easier for you, but it means you’d need to configure the Caddy container to also publish that port, and if you mean to access it from outside your network, port forward that as well.

[Whitestrake (Matthew Fay)]

Was gonna explain some stuff and ask for some quick command line tests to push you in the right direction to debug, but you’re on it already! Awesome.

FYI,

@antonphp

The problem is, the only entries in Caddy logs that have 8002 are:

{"level":"debug","ts":1663647245.7463007,"logger":"http","msg":"starting server loop","address":"[::]:8002","http3":false,"tls":true}

This is the actual HTTP(S) listener itself, and you’ll get one of these messages for each listener Caddy runs (typically one for 80 and one for 443 under more typical deployments). That is, one for each listener, not one for each site.

Other than that, in terms of not getting any other logging (e.g. upstream selection), you’ve clearly sorted out why that was the case.

Nice!