400 and 522 errors since enabling SSL via Nginx proxy
-
An issue with terminating SSL connections?
http://blog.mixu.net/2011/08/13/nginx-websockets-ssl-and-socket-io-deployment/ -
@KingCat , if you run
sudo nginx -t
, what happens exactly? -
@julian said:
It's cloudflare. Keep using it, but disable acceleration. Websocket issues will be fixed.
I did what you suggested and it seems to have fixed the issue in chrome. However in safari it still happens. I'm gonna wait a while and see if maybe safari just has something weird cached (even though i cleared browser and dns cache).
-
So it's been a few days and i'm still getting the errors in safari. The errors don't show up in any other browser though.
If I had to guess, I'd say theres some kind of technology or protocol that safari doesn't support (maybe the wss:// protocol?) so the socket.io has to fallback to using http instead and that seems to be why the error happens. Totally a guess though.
If this is the best I can do I'm OK with that as 0.1% of my users are on safari and it's not a site-breaking bug either. I'll consider this closed unless anyone has anything else to try.
Also, not sure if it matters but I'm using a free StartSSL certificate. It's not a self-signed one and it gives the green lock in safari but just in case it matters for some reason.
-
By the way, I visited the link in the error messages in safari (https://forum.nzb.cat/socket.io/?EIO=3&transport=polling&t=1429031828694-10&sid=E7eEDbKPU53mKENvAAW3)
and got this:
{"code":1,"message":"Session ID unknown"}
Not sure what this means for the cause of the 400/502 errors.
-
Welp, I solved it.
Turns out I had the wrong directory specified in nginx for static assets. It was pointing to a different install of nodebb. For some reason that caused issues with socket.io (and only with safari/opera for some reason).
Now, here's the weird thing. I only recently started using nginx to serve the assets. Recently as in like this morning. Before that I simply had a proxy pass setup and let nodebb serve the assets. I'm not sure what was causing the 400/502 errors then but I'm just glad their solved now.