Cannot get WebSockets to work behind Nginx about linkstack-docker HOT 14 CLOSED

Make sure your Nginx configuration is correctly set up to proxy WebSocket connections. In your Nginx configuration, you should have a section similar to this:

location /  {
    proxy_pass http://your_backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

from linkstack-docker.

All these directives are already present. In case you missed it, I've added a summary of my nginx hostfile to the OP. The copy here was missing the proxy_pass directive, which is obviously present in the actual config, but I've added it to the OP for your convenience. Again, all four of these are already set and have been for the entirety of my testing.

from linkstack-docker.

Are you using the internal IP for the proxy_pass?

from linkstack-docker.

No, I am using the container name:
proxy_pass https://linkstack:443;

from linkstack-docker.

What does your NGINX error logs say?

from linkstack-docker.

@lastsamurai26

from linkstack-docker.

What does your NGINX error logs say?

The main thing i see are errors regarding fonts. Filtering those out, this is what remains:

cat /var/lib/docker/volumes/nginx_nginx/_data/logs/proxy-host-48_error.log | grep -v "woff2"
2023/11/07 15:46:54 [warn] 92092#92092: *452094 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/6/67/0000006676 while reading upstream, client: 172.71.103.94, server: bytebones.dev, request: "GET /assets/webfonts/fa-solid-900.woff2 HTTP/2.0", upstream: "https://172.19.0.12:443/assets/webfonts/fa-solid-900.woff2", host: "bytebones.dev", referrer: "https://bytebones.dev/"
2023/11/07 15:50:50 [warn] 92092#92092: *452134 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/7/67/0000006677 while reading upstream, client: 172.71.99.5, server: bytebones.dev, request: "GET /assets/webfonts/fa-solid-900.woff2 HTTP/2.0", upstream: "https://172.19.0.12:443/assets/webfonts/fa-solid-900.woff2", host: "bytebones.dev", referrer: "https://bytebones.dev/"
2023/11/07 15:51:07 [warn] 92092#92092: *452202 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/8/67/0000006678 while reading upstream, client: 172.71.99.71, server: bytebones.dev, request: "GET /assets/css/maps/hope-ui.min.css.map HTTP/2.0", upstream: "https://172.19.0.12:443/assets/css/maps/hope-ui.min.css.map", host: "bytebones.dev"

This does not seem related to websockets. Note that nginx is set to log anything with the "warn" level or above.

The access log shows this when loading the dashboard:

[07/Nov/2023:15:54:44 +0000] - 403 403 - HEAD https bytebones.dev "/.env" [Client 172.71.250.22] [Length 0] [Gzip -] [Sent-to linkstack] "-" "-"
[07/Nov/2023:15:54:45 +0000] - 403 403 - HEAD https bytebones.dev "/database/database.sqlite" [Client 172.71.250.68] [Length 0] [Gzip -] [Sent-to linkstack] "-" "-"
[07/Nov/2023:15:54:45 +0000] - 200 200 - GET https bytebones.dev "/dashboard" [Client 172.70.47.18] [Length 15509] [Gzip -] [Sent-to linkstack] "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36" "https://bytebones.dev/studio/links"
[07/Nov/2023:15:54:45 +0000] - 200 200 - GET https bytebones.dev "/assets/fonts/Inter/inter-latin-400-normal.woff2" [Client 172.70.47.8] [Length 16708] [Gzip -] [Sent-to linkstack] "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36" "https://bytebones.dev/dashboard"
[07/Nov/2023:15:54:45 +0000] - 200 200 - GET https bytebones.dev "/assets/fonts/Inter/inter-latin-700-normal.woff2" [Client 172.70.46.77] [Length 17784] [Gzip -] [Sent-to linkstack] "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36" "https://bytebones.dev/dashboard"
[07/Nov/2023:15:54:45 +0000] - 200 200 - GET https bytebones.dev "/assets/css/maps/customizer.min.css.map" [Client 172.70.47.17] [Length 3453] [Gzip -] [Sent-to linkstack] "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36" "-"
[07/Nov/2023:15:54:45 +0000] - 200 200 - GET https bytebones.dev "/assets/fonts/Inter/inter-latin-500-normal.woff2" [Client 172.70.47.55] [Length 17552] [Gzip -] [Sent-to linkstack] "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36" "https://bytebones.dev/dashboard"
[07/Nov/2023:15:54:45 +0000] - 200 200 - GET https bytebones.dev "/assets/css/maps/dark.min.css.map" [Client 172.70.47.17] [Length 20596] [Gzip -] [Sent-to linkstack] "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36" "-"
[07/Nov/2023:15:54:45 +0000] - 200 200 - GET https bytebones.dev "/assets/css/maps/rtl.min.css.map" [Client 172.70.47.17] [Length 18961] [Gzip -] [Sent-to linkstack] "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36" "-"
[07/Nov/2023:15:54:45 +0000] - 200 200 - GET https bytebones.dev "/assets/css/maps/custom.min.css.map" [Client 172.70.47.17] [Length 17885] [Gzip -] [Sent-to linkstack] "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36" "-"
[07/Nov/2023:15:54:45 +0000] - 200 200 - GET https bytebones.dev "/assets/css/maps/hope-ui.min.css.map" [Client 172.70.47.17] [Length 156570] [Gzip -] [Sent-to linkstack] "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36" "-"
[07/Nov/2023:15:54:45 +0000] - 404 404 - GET https bytebones.dev "/assets/js/popper.min.js.map" [Client 172.70.47.17] [Length 2299] [Gzip 2.87] [Sent-to linkstack] "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36" "-"
[07/Nov/2023:15:54:45 +0000] - 404 404 - GET https bytebones.dev "/assets/js/bootstrap.min.js.map" [Client 172.70.47.18] [Length 2299] [Gzip 2.87] [Sent-to linkstack] "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36" "-"

note the two 404s, as well as the requests for the .env and sqlite file for whatever reason? The log from inside the linkstack docker container is identical though.

from linkstack-docker.

I have tested it on different servers. Docker and native.

Websocket must be supported by the software, not every software automatically has Websocket.

the 404 is normal because if a client will browse directly to this file they will get a 404 -> not allowed

from linkstack-docker.

Your reply confuses me on multiple levels

I have tested it on different servers. Docker and native.
Websocket must be supported by the software, not every software automatically has Websocket.

Linkstack is supposed to have websocket support, no? Otherwise it wouldnt be a documented feature. Or are you saying that Websockets are supported when running natively, but not in docker? I also want to reiterate that I am running multiple other services with the exact same setup that successfully utilize Websockets, like Vaultwarden. So there's no point in blaming my setup alltogether, it definitely can work. And if you're trying to blame my browser - its a very normal chromium browser, and WebSockets have not caused issues on any other site.

the 404 is normal because if a client will browse directly to this file they will get a 404 -> not allowed

The 404 cannot be normal. Why would the website be programmed to access files that are not available on the server, when both client and server have been programmed by the same people? Plus, a 404 is not a "not allowed" error, its a "does not exist" error.

And if you mistyped and meant the two 403s instead - why is the client programmed to access data that is reserved to the server backend? Or is that untrue and the two files are technically accessible through the webserver? which would be not good at all...

from linkstack-docker.

Linkstack is supposed to have websocket support, no? Otherwise it wouldnt be a documented feature. Or are you saying that Websockets are supported when running natively, but not in docker? I also want to reiterate that I am running multiple other services with the exact same setup that successfully utilize Websockets, like Vaultwarden. So there's no point in blaming my setup alltogether, it definitely can work. And if you're trying to blame my browser - its a very normal chromium browser, and WebSockets have not caused issues on any other site.

*Offtopic on *
Websockets for Valtwarden needs to be activated in the .env file
WEBSOCKET_ENABLED=${WEBSOCKET_ENABLED}
but normally the Websocket is not activ
Offtopic off

I need to check if there is Websocket funtcionallty

And if you mistyped and meant the two 403s instead - why is the client programmed to access data that is reserved to the server backend? Or is that untrue and the two files are technically accessible through the webserver? which would be not good at all...

You are Right normally it could be a 403 because of deny via htaccess
we will check this
but technically only the websever himself need the access to this files not the user

from linkstack-docker.

*Offtopic on *
Websockets for Valtwarden needs to be activated in the .env file
WEBSOCKET_ENABLED=${WEBSOCKET_ENABLED}
but normally the Websocket is not activ
Offtopic off

Still offtopic, but Vaultwarden recently moved their WebSocket implementation from port 3012 to 80, and it is now enabled by default.

I need to check if there is Websocket funtcionallty

Do you mean that you're checking if there is WebSocket functionality in Linkstack? When Websockets are part of the documentation since, at least, august 2022?

You are Right normally it could be a 403 because of deny via htaccess
we will check this
but technically only the websever himself need the access to this files not the user

I had a look into the files stored by linkstack in htdocs, and was surprised to find the .env and .sqlite files there - though they are indeed blocked via the .htaccess file. It feels weird to me to have these completely internal files technically accessible through the webserver (imagine a zero-day exploit that can circumvent the .htaccess rules for example), and I would imagine those files to be stored completely away from the webserver so they're 100% inaccessible without access to the server hardware - but maybe thats just how PHP works, it's really not my cup of tea after all.

from linkstack-docker.

Do you mean that you're checking if there is WebSocket functionality in Linkstack? When Websockets are part of the documentation since, at least, august 2022?

laravel supports Websocket, but it is not implemented in Linkstack.

from linkstack-docker.

If WebSockets were never implemented in Linkstack, I wonder why they're part of the reverse proxy configuration. I also wonder if that means that this behaviour when switching pages is intended, or if it's just been ignored all this time:

Until now I thought that this must be because of the missing WebSockets, and that having them work would enable a smoother page switching experience. Especially since this also happens every time you change any setting on any page, which gets very hard on the eyes after adding a couple links to your page.

I guess not then?

from linkstack-docker.

LinkStack does not support WebSockets natively, and there are no plans of implementing this. The reverse proxy block is just a generic template.
LinkStack renders over static HTML elements. What you are experiencing is the intended behavior. This cannot be changed without rewriting pretty much the whole app.

We have plans to change some parts of the frontend in 5.0. Stay tuned for any updates to come.

from linkstack-docker.