Using CloudFlare with NodeBB

[julian]

@DownPW as the project managers say, that feature has not been assigned a milestone yet

So it's on our to do list but no commitments at present.

[DownPW]

It seems strange to me that the sockets traffic constantly reaches the maximum allowed by CF's free plan, even if this maximum fluctuates according to the requests. Because sometimes it happens when there are 30-40 users connected. I find that surprising. You could almost think that sockets are a bit too persistent and don't close well.

[phenomlab]

@DownPW I'm interested to know if there is any improvement if you disable the shoutbox plugin?

If you consider what this plugin does, it would be interesting to see if this has an impact on socket connections.

[DownPW]

Not tested yet for shoutbox plugin socket.

For maybe persistent socket, maybe @baris can answer with this

[baris]

websocket connections are meant to work like that, on the first page load a connection is made and it remains open as long as the user is on the site.

[DownPW]

@baris

I have test this configuration and I have websocket error uninterruptedly and I don't know why :

-- My Nodebb config for socket.io :

-- Nginx config for socket.XXXX.XXXX :

server {
	server_name socket.xxxx.fr www.socket.xxxx.fr mail.socket.xxxx.fr;

	access_log /var/log/virtualmin/socket.xxxx.fr_access_log;
	error_log /var/log/virtualmin/socket.xxxx.fr_error_log;


	location / {
        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_set_header Upgrade         $http_upgrade;
        proxy_set_header Connection      "upgrade";
        proxy_redirect                   off;
        proxy_http_version               1.1;
        proxy_pass                       http://localhost:4567;
    }

	listen xx.xx.1xx.xx:443 ssl;
	listen [xxx:xxx:xxx:cxx2::1]:443 ssl;
    ssl_certificate /etc/letsencrypt/live/media.xxxx.fr/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/media.xxxx.fr/privkey.pem;
 # managed by Certbot
}
server {
    if ($host = socket.xxxx.fr) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


	server_name socket.xxxx.fr www.socket.xxxx.fr mail.socket.xxxx.fr;
	listen xxx.xxx.xxx.xxx;
	listen [xxx:4xx:cxx:cxxx2::1];
    return 404; # managed by Certbot

}

-- Cloudflare config :

-- I see this on start in nodebb log

[baris]

Seems like a mismatch between your config.json url and socket.io address. Try with a default nginx config from our docs and get rid of the custom socket.io adress you are using in config.json. https://docs.nodebb.org/configuring/proxies/nginx/#example-configurations

[DownPW]

@baris you mean that to re-route the websockets, I don't need to indicate the url of the dedicated subdomain (differend from the nodeBB access domain) in the config.json?

[phenomlab]

@DownPW you do otherwise it will use the default website. I tried the guide myself in a test server and it doesn't work.

[DownPW]

I also can't get this tutorial to work.

Otherwise I remain perplexed on the number of websockets that V3 uses. We had more traffic with v2 before switch to v3 and very little saturation at CF. Now we have a lot of errors (wss, error 400) due to limit sockets
Maybe it is coded differently, or else CF has precisely modified its websocket limits… which seems unlikely to me.

It's a pity that we can't use NodeBB with CF if the site has a little too much traffic

[phenomlab]

@DownPW I'm not sure it's solely traffic that causes this. I took saw this frequently when I used Cloudflare and it became so bad that I decided to stop using the service altogether.

No issues since.