Question for Socket.IO: Server sents weird "Invalid frame header" message in websocket
Answered
gin posted this in #help-forum
ginOP
So basically ive been dealing wit this since i resetted nginx completely. After this error socketio automatically switches to polling which works but its spamming the request tab :/ Do i need to modify some nginx configuration for it to be able to accept websockets for the reverse proxy?
Answered by gin
Okay, after trying everything i finally found the solution:
Turns out the issue arised out of a combination of node and tsc, while running the devserver via bun i had no issues, my build system was using tsc for compilation. For some reason this broke something internally with socket.io
Solution:
- switched from tsc to tsup
- Run project via bun in production (main fix)
Turns out the issue arised out of a combination of node and tsc, while running the devserver via bun i had no issues, my build system was using tsc for compilation. For some reason this broke something internally with socket.io
Solution:
- switched from tsc to tsup
- Run project via bun in production (main fix)
93 Replies
ginOP
location /api/ {
proxy_pass http://localhost:3004/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_buffering off;
}reverse proxy block that the connection goes trough
for clarity:
ginOP
still searching for a solution
both the frontend and backend have the same socket.io version
nginx version also supports websockets
West African Lion
you are calling
wss://
instead of ws://
wss:// is the equivalent of https vs http
@gin typescript
location /api/ {
proxy_pass http://localhost:3004/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_buffering off;
}
reverse proxy block that the connection goes trough
West African Lion
there's no SSL certifcates that are defined here
so your route could only be ws://
ginOP
@West African Lion yes
i have ssl
i think its a issue from the operating system itself
when i run my backend locally it works fine
the issue arised after i migrated to a new host
or a faulty node version
this shit is haunting me for months and i have still not found a solution
i asked every ai and searched trough every blog and help websites
West African Lion
sure
you might have an ssl cert
but it is not listed in your nginx config
atleast not what you sent
show the sites-enabled / domain file
ginOP
nah its not the full config
West African Lion
or are you just running naked ip
mind dming me the full config
i can take a look w u in dm
ginOP
its a big config
West African Lion
thats alright you can blur sensitives
@West African Lion or are you just running naked ip
ginOP
i have ssl with certbot
West African Lion
yes but you need to tell nginx where they are
ginOP
the location block is in the 443 section created by certbot
for the domain
@West African Lion yes but you need to tell nginx where they are
ginOP
thats not the problem
West African Lion
do you only have it on 443
or also on 80
or
better said
is anytihng else on 80
ginOP
i dont use 80 only 443
West African Lion
cool
then have you checked the firewall of the OS?
ginOP
dont have a firewall
only cloudflare
West African Lion
ubuntu has one
built =in
software sided
West African Lion
ubuntu is debian based
same shit
not iptables
ufw
West African Lion
for older debian versions maybe
i think you have
wtf is it called
nftables
sudo systemctl status nftablesginOP
i dont have any firewall and i dont thinks that the issue aswell
West African Lion
sudo nft list rulesetwell you dont know the issue so you dont know whats not the issue either
sometimes its something small
@gin i dont have any firewall and i dont thinks that the issue aswell
West African Lion
did you actually disable it then
ginOP
yes
West African Lion
okay cool
so ig we start top down lets see if ur system even runs the TCP connections thru port 443
ginOP
appreciate ur effort but i think this shit cant be solved
West African Lion
got netstat?
bahaha bro
everything is solvable
sudo netstat -tuln | grep -E ':(80|443)\b'West African Lion
it doesnt close anytihng
ginOP
its part of a cluster
West African Lion
yes bro i am sure
do you want me to give you a spare vps we have and u try it on there ?
we got loads
just fresh
West African Lion
i c
imma add u rq
ginOP
Okay, after trying everything i finally found the solution:
Turns out the issue arised out of a combination of node and tsc, while running the devserver via bun i had no issues, my build system was using tsc for compilation. For some reason this broke something internally with socket.io
Solution:
- switched from tsc to tsup
- Run project via bun in production (main fix)
Turns out the issue arised out of a combination of node and tsc, while running the devserver via bun i had no issues, my build system was using tsc for compilation. For some reason this broke something internally with socket.io
Solution:
- switched from tsc to tsup
- Run project via bun in production (main fix)
Answer
ginOP
For everyone having the same issue in the future, try this :)