Using CloudFlare with NodeBB
-
@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.
-
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
-
@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)
-
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.
-
@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.
-
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
-
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
-
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