Hey,
I'm not sure what's causing socket.io to return a bad request to my browser console. It keeps spamming it, while showing the "trying to reconnect to forum" icon on the navbar. I'm using Safari - perhaps that's the issue? I also tried on Chrome and no error messages are logged to browser console.
[Error] Failed to load resource: the server responded with a status of 400 (Bad Request) (socket.io, line 0) http://xx.xx.xx.xx:4567/socket.io/?EIO=3&transport=polling&t=1428002645233-40&sid=kuBPKPUUfR_ZpOuzAAAE
While inspecting the content of the error message, I find the following json:
{"code":1,"message":"Session ID unknown"}
Note: I recently moved my old NodeBB Redis database on a fresh Ubuntu installation for a new NodeBB instance.
Any help is appriciated! 
I'm seeing this exact same error except mine didn't go away in 0.7.0-dev. I thought at first it had to do with SSL but I setup the server to accept connections directly to the nodebb server bypassing nginx completely like described here and I'm still getting them, only in safari though.
I wish I knew what the issue was dammit. This is frustrating as all heck.
So I was completely ready to just pass it off as a safari issue and move along with my life but then I realized something obvious and overlooked. The issue doesn't occur.. AT ALL... on this site. Only on mine. That means it's an implementation problem on my end and not just a fact-of-life incompatibility between safari and node/socket.io.
I don't necessarily think it's nginx since I still got the errors when visiting nodebb directly through the ip:port. I was only getting 400 errors and not the 522 but that makes sense since it's nginx that generates the 522 i imagine.
I've got to solve this problem or it's going to consume me. I'm running the latest master 0.7.0-dev.
Plz Halp.
@julien I created a screencast of it happening: https://www.dropbox.com/s/4hlga9ewp3neq1u/socketissue-sansnginx.mov?dl=0
Edit: I tried installing a fresh copy of nodebb on a different port and I didn't get these socket issues so apparently it's not a problem with nodebb. However, when I changed the config for this new install to use the original database the errors started coming back. I'm not sure how to debug further but It seems like something in the database is causing this problem.
Is there any way I can export the posts and re-import them into a new install? I don't want to lose all my posts.
Edit2: I was mistaken. What was happening was I wasn't getting errors on the new installation when visiting the ip:port directly however when I put the new installation behind the SSL cert and domain name it had these same errors again. I even went so far as to purchase a new SSL cert, the same one this site uses just to be sure and the errors still persist. BTW I found out the errors also happen in Opera. I will get to the bottom of this.
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.
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.
@markkus This is my nginx config:
Seems like the error has come back...upstream io_nodes {
ip_hash;
server 127.0.0.1:4567;
server 127.0.0.1:4568;
}
server {
listen 443 ssl spdy;
server_name forum.nzb.cat;
access_log /var/log/nginx/forum_access.log;
error_log /var/log/nginx/forum_error.log;
ssl on;
ssl_certificate /etc/nginx/ssl/forum-nzb-cat-bundle.crt;
ssl_certificate_key /etc/nginx/ssl/nzbcat.key;
# enables all versions of TLS, but not SSLv2 or 3 which are weak and now deprecated.
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
# disables all weak ciphers
ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
ssl_prefer_server_ciphers on;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-NginX-Proxy true;
proxy_redirect off;
# Socket.io Support
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
gzip on;
gzip_min_length 1000;
gzip_proxied off;
gzip_types text/plain application/xml application/x-javascript text/css application/json;
location @nodebb {
proxy_pass http://io_nodes;
}
location ~ ^/(images|language|sounds|templates|uploads|vendor|src\/modules|nodebb\.min\.js|stylesheet\.css|admin\.css) {
root /data/nodebb2/public/;
try_files $uri $uri/ @nodebb;
}
location / {
proxy_pass http://io_nodes;
}
}
Now when I was having the error the "root" directive of the "location" block was set to "/data/nodebb/public" which was an old nodebb installation. Updating it to "nodebb2" fixed the issue.
Like I said though, I have no idea what was causing the issue before I started using nginx to serve the static assets (which is what that "location" block does). Maybe there was a permissions issue or something? No idea.
Edit: also, I'm using nginx 1.8 on ubuntu 14.04 with nodebb 0.7.0-dev. I was also having this issue in 0.6.x but not sure if this would fix it.
.
