[BUG]: Connection to Synology Websocket produces 500 Errors

[lenderom]

What happened?

I put Cosmos as my reverse proxy in front of my Synology NAS to secure the access. I can access the NAS and WebInterface without problems execpt for two things.

• When I have the Synology webinterface (DSM) open in my browser, it tries to create a websocket connection. This fails with 400 and 500 errors, resulting in a reattempt, which fails again. This leads to a block of the ip adress after a while:

Logs in Cosmos:

• I also can't connect to Synology using the Synology Drive App (which I guess is the same problem, because when I open the Synology Drive Webapp in the Browser I also see WebSocket issues:)

When using NGINX as reverse proxy this works I didn't had any problems.
I also tried different CORS Settings as well as disabling Smart Shield protection (this disables the IP Block but, the WebSocket still doesn't work). https://www.reddit.com/r/synology/comments/1b5n0az/mobile_drive_app_cant_connect_through_external/

I think other people experienced the same problem:
https://discord.com/channels/1083875833824944188/1173964811214786631

What should have happened?

The websocket connection shouln't fail, so the Synology app works and the IP doesn't gets blocked.

How to reproduce the bug?

Put cosmos in front of a synology NAS and connect through the reverse proxy to the Synology webinterface (DSM)

Relevant log output

No response

Other details

No response

System details

• Synology webinterface in Chrome
• Synology Drive Android App
• Cosmos 0.15.3

[mandopatriot]

Are you touting to HTTPS on the Synology? I had the same issue but with Nginx Proxy Manager, only workaround I found was switching to HTTP on Synology. Might be tied to Synology not having a trusted cert, but just a guess.

[azukaar]

@mandopatriot you mean the target URL being https rather than http? (so like https://localhost:port, with port being the syno port?)

[mandopatriot]

@mandopatriot you mean the target URL being https rather than http? (so like https://localhost:port, with port being the syno port?)

@azukaar Yes, but for my case it routed to the Synology IP (not same host as NPM). I don't believe I tried with the HTTPS connection when I switched to Cosmos. Can try it out if you like.

[azukaar]

@mandopatriot I tried it in every directions secure / insecure sockets, proxied in every possible ways, and I am unable to get a breaking setup, Cosmos is able to proxy both ws and wss succesfuly for me so I am not sure what weird stuff Synology is doing, but it seems unholy may be

[lenderom]

@mandopatriot at the moment my setup is cosmos -> routing to the ip of synology (not localhost) as https to port 443 -> and then the native Synology (nginx) reverse proxy is routing to localhost 5001 (which is the https Synology port).

However I now tried to make everything http only and port 5000 behind cosmos and also don't use the Synology reverse proxy at all. But I didn't found a difference in the errors.

Maybe I should mention, that cosmos is also running on my Synology machine. But because synology is blocking port 443 and 80 with their reverse proxy (there are ways to free the ports, but I don't want to break the Synology operating system DSM) Cosmos is running in a Docker Macvlan network. But I don't think that this should be an issue because I can reach DSM and the UI works except for the websocket connections.

@mandopatriot so you are running Synology behind Cosmos without troubles at the moment?

@azukaar Do you have an idea how to debug this better maybe?

I'm also not 100% sure if the websocket is really the problem. Because in the log are also 500 and 400 errors.

[lenderom]

I just also found out, that before all network errors turn up, there is an execption in the console:

I'm not sure if it is related, but it doesn't happen when connecting direct to Synology and not using Cosmos (except for the yellow warning)