No SocketIO-Connection with Reverse Proxy

Help
1

1. Caddy version (caddy version):

2.2.2

2. How I run Caddy:

I run caddy as a simple reverse-proxy pointing to a nodeJS server

my_url
reverse_proxy 127.0.0.1:PORT_NUMBER

a. System environment:

Ubuntu 18.04
All ports closed via FireWall except 80/443

b. Command:

caddy start

d. My complete Caddyfile or JSON config:

my_url
reverse_proxy 127.0.0.1:PORT_NUMBER

3. The problem I’m having:

On my nodeJS server im running a StrapiHeadless CMS. I implemented a custm socket.io logic directly into strapi. This was working localy on development. The host for strapi is set to 127.0.0.1 (to only listen to the traffic procied from Caddy).
Now, with Caddy as the RP, I can no longer make a connection to my socket.io server.
The docs state that websockets get proxied without problems, but seems like I might need additional info in my caddyfile.
When I try to connect to wss://myurl I get a short moment before getting a “this is not possible” from my client.

4. Error messages and/or full log output:

5. What I already tried:

Using ws and wss protocoll. (Not working)
Disabling the Firewall (Not Working)
Disabling Firewall/Opening Direct Port and setting host to 0.0.0.0 and connection directly to the NodeJS Server (Worked. But not the idea)

6. Links to relevant resources:

2

What are you seeing in your Caddy logs?

3

Hi, thank you for answering. TBH I was asking me the same question and am currently on an adventure to understand how I can enable logging in my simple proxy file. II know this seems obviuos but i’m having my difficulties atm to get any kind of log out of Caddy. Maybe you have a quick tip but let me get back to you when I got this figured out.

(I tried adding just a log directive to my caddyfile but this seems to not do anything. interresting. At least no errors though)

4

Well, it depends how you’re running Caddy. You said you’re using caddy start, but how exactly? If you run that from your terminal, you should see the logs printed out in your terminal from stdout.

Generally people run Caddy with caddy run because that makes it easier to control where the logs go. When running Caddy with something like systemd, it will automatically capture the logs and you can use the journalctl -u caddy command to get your logs.

The log directive in the Caddyfile only configures access logs per site, but I’m asking about the global logs, which will include errors and such, and those go to stdout.

5

Hi Francis,
thats helping alot! I did not realise that this is possible.
So the first interresting part is that I do not get any kind of log when I connect from my client-software (which works with disabled reversed proxy ).
I use socketking atm for testing and get the following output in the logs:

2020/10/31 19:04:12.988 ERROR http.log.error EOF {“request”: {“remote_addr”: “95.90.242.31:53343”, “proto”: “HTTP/1.1”, “method”: “GET”, “host”: “my_url”, “uri”: “/”, “headers”: {“User-Agent”: [“Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0”], “Accept-Language”: [“de,en-US;q=0.7,en;q=0.3”], “Accept-Encoding”: [“gzip, deflate, br”], “Origin”: [“https://websocketking.com”], “Sec-Websocket-Extensions”: [“permessage-deflate”], “Connection”: [“keep-alive, Upgrade”], “Accept”: [“/”], “Sec-Websocket-Version”: [“13”], “Sec-Websocket-Key”: [“d+VflxaGg5TOrCcPvg3BWg==”], “Pragma”: [“no-cache”], “Cache-Control”: [“no-cache”], “Upgrade”: [“websocket”]}, “tls”: {“resumed”: true, “version”: 772, “cipher_suite”: 4865, “proto”: “http/1.1”, “proto_mutual”: true, “server_name”: “my_url”}}, “duration”: 1.002878432, “status”: 502, “err_id”: “1kfaukauy”, “err_trace”: “reverseproxy.(*Handler).ServeHTTP (reverseproxy.go:441)”}

2020/10/31 19:04:12.988 ERROR http.log.access handled request {“request”: {“remote_addr”: “95.90.242.31:53343”, “proto”: “HTTP/1.1”, “method”: “GET”, “host”: “my_url”, “uri”: “/”, “headers”: {“Accept-Language”: [“de,en-US;q=0.7,en;q=0.3”], “Accept-Encoding”: [“gzip, deflate, br”], “Origin”: [“https://websocketking.com”], “Sec-Websocket-Extensions”: [“permessage-deflate”], “Connection”: [“keep-alive, Upgrade”], “User-Agent”: [“Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0”], “Accept”: [“/”], “Sec-Websocket-Version”: [“13”], “Sec-Websocket-Key”: [“d+VflxaGg5TOrCcPvg3BWg==”], “Pragma”: [“no-cache”], “Cache-Control”: [“no-cache”], “Upgrade”: [“websocket”]}, “tls”: {“resumed”: true, “version”: 772, “cipher_suite”: 4865, “proto”: “http/1.1”, “proto_mutual”: true, “server_name”: “my_url”}}, “common_log”: “95.90.242.31 - - [31/Oct/2020:19:04:12 +0000] "GET / HTTP/1.1" 502 0”, “duration”: 1.002878432, “size”: 0, “status”: 502, “resp_headers”: {“Server”: [“Caddy”]}}

“status”: 502, “err_id”: “1kfaukauy”, “err_trace”: “reverseproxy.(*Handler).ServeHTTP (reverseproxy.go:441)”}

This part here seems to be interresting! (and even more interresting that it, at least, tried to do some kind of handshake)

Best!

6

This just means Caddy couldn’t open a connection to your websocket server. Are they both running on the same machine? Is one maybe in a docker container or something? What’s the actual port number? Please don’t omit important information from your Caddyfile.

7

Hoi, Sorry if informations are missing:
the caddy file is in fact just

my_url
reverse_proxy 127.0.0.1:9683

The NodeJS server is running on the same mashine and the reverse proxy is working for regular requests.
None of the two is running in any kind of container.
As is said, when disabling the firewall and accessing the NodeJS server directly in an unsave manner via ws:// I get a connecton without problems.

Do I maybe have to adjust my Caddy to be more detailed? When converting the caddyfile to json it seems to only be interrested in HTTP. (which should not be an issue regarding the docks.)

8

That Caddyfile seems okay…

Does your websocket server have any logging that might show what’s happening?

You could also add this to the top of your Caddyfile that might reveal some more information:

{
	debug
}
9

Alright. I might have taken your time for not the best reason. After being a little bit frustrated I created a simple socketio client using the python-socketio package. And voila, I can connect without problems via wss to my server via the reverse_proxy. I suppose the issue not at all to search at Caddy (which makes me happy, i freaking live that little piece of software!).
So It seems like I will have to search on the sending end instead of the messenger.

Thank you alot Francis for taking the time to go through this with me! Being able to look into the logs already helped ma alot better understanding whats going on!

Best wishes and have a good night!

2 Likes
10

This topic was automatically closed after 30 days. New replies are no longer allowed.