Using CloudFlare with NodeBB

crazycells

@phenomlab said in Using CloudFlare with NodeBB:

@crazycells said in Using CloudFlare with NodeBB:

Then, to have cancer-free life, we gave up on CloudFlare...

Which is exactly what I have just done, and now zero issues.

and everyone lived happily ever after...

phenomlab

@crazycells said in Using CloudFlare with NodeBB:

and everyone lived happily ever after...

DownPW

Strange to have issues with CloudFlare/nodeBB

tankerkiller125

@phenomlab Cloudflare Free plans have a 100ish max connections from what I remember to/from WebSocket's. I believe you can submit a support request with Cloudflare to up it to something more but I can't remember all the details. But basically what it comes down to is Cloudflare can't cache that data, and in some applications WebSocket's sends a ton of data which costs quite a bit of bandwidth on Cloudflare's side so they try to avoid it on the free plans by restricting the max number of connections.

Edit: https://developers.cloudflare.com/support/network/using-cloudflare-with-websockets/

Based on some general reports it looks like the Pro plan gives 5x the number of WebSocket connections over the Free plan, and a similar increase from Pro to Business.

phenomlab

@tankerkiller125 yes, I read the same article, and they keep revising it. The problem I find is that the disconnects are always socket based, and as a result, the transactional artefact is that notifications don't materialise which can be quite frustrating.

Since no longer using Cloudflare (only in a DNS capacity) proxy, this issue has resolved itself. Cloudflare DNS really does excel and takes some beating, but the "free" plan has a lot of limitations. I've also never been keen on running all of my traffic through one central location as a proxy, so I'm not sorry to be parting company.

julian

@phenomlab if there are those who are using cloudflare, we do have it in our roadmap to eventually deprecate socket.io and use socket sent events instead.

phenomlab

@julian thanks, although I think this will exhibit the same issues based on limits imposed in the free plan. In my testing, CF was also actually slowing down my site, and since disabling it, the site is noticeably faster.

DownPW

I'm using CloudFlare in its Free Plan and I'm facing a lot of sowket errors (wss, 400, ...) especially since v3.

@julian
Is this solution still viable? does it solve its problems and can you continue to use CF.

@julian said in Using CloudFlare with NodeBB:

@phenomlab if there are those who are using cloudflare, we do have it in our roadmap to eventually deprecate socket.io and use socket sent events instead.

And how long is this in your roadmap? still relevant ?

Thanks

phenomlab

@DownPW my thoughts here based on the Sudonix discussion

NodeBB socket with CloudFlare

@DownPW said in NodeBB socket with CloudFlare: one of CloudFlare’s features of hiding the origin server’s IP is THE feature that makes me not really want to...

Sudonix | A one-stop-shop for all your technology questions (sudonix.org)

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.