Closed fonMaringer closed 5 months ago
I would need more details, such as is there a reverse proxy in front of the application? I've never experience this issue and I've run it locally as well as in docker on a VPS (how thunderdom.dev is hosted).
Yeah, there is an nginx reverse proxy in all cases.
Sounds like your nginx reverse proxy isn't handling the websocket upgrade properly. I can get you an example reverse proxy config I'm using for nginx and thunderdome.
That would be great! I think it makes sense to add sample config into deploy docs for everyone who faces the same problem. Here is my config:
upstream pp {
server 127.0.0.1:16222;
}
server {
listen 80;
server_name my.server.name;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name my.server.name;
#ssl part here
access_log off;
location ~ {
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $http_host;
proxy_set_header Upgrade websocket;
proxy_set_header Connection Upgrade;
proxy_pass http://pp;
}
}
Here's the config I'm using
location / {
proxy_pass http://localhost:8000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
Thank you! I'll test this config for a few days
Nah, this does not work. I still got reloads even if I'm alone in a battle.
Is the Thunderdome application crashing/restarting constantly?
Outside that I'm not sure what the issue would be since Thunderdome and NGINX is the working in that combination for me.
The Thunderdome work perfectly, I see no logs from it.
Just updated to 3.9.0 and the number of reloads has decreased significantly. I'll try changing the values in the new options, but it looks like the problem is mostly resolved. Thank you!
Hi! I'm suffering with a strange issue for a long time, since some old update)
If there are many people (e.g. 5-10) in battle/retro the page frequently reloads (Oops, reloading battle/retro). More people - more reloads.
I've tried to increase http timeouts in config, but it did not solve the issue. It does not depend on where the service is deployed, I've tried deploy outside and inside my VPN, in a local network, but the issue still remain.
Can you suggest any solution for this?