Skip to content

NodeBB socket with CloudFlare

Unsolved Performance
  • Hello @phenomlab

    Following this topic, I understood that CloudFlare in its Free Plan is not my friend but I wonder.

    one of CloudFlare’s features of hiding the origin server’s IP is THE feature that makes me not really want to leave CloudFlare unless there’s another way to do it ?

    That said, the problem being mainly the socket connections, wouldn’t it be possible to pass ONLY its connections without going through CloudFlare?

    To do this, you will have to create a subdomain of the root domain and not proxy it via Cloudflare but just in DNS Only, then indicate this in nodebb’s config.json

    If I’m not mistaken, this might fix the wss and error 400 issues.

    I saw this topic on which you intervened with your position, but is this method still viable, is it functional?

    At the end of this thread it reads:

    @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.
    This would solve a lot of problem with CloudFlare’s free plan no?

    This would solve a lot of problem with CloudFlare’s free plan no?

    Afterwards I am ready to leave CloudFlare if another possibility of hiding your IP is possible but in the meantime, could this be a solution ?

    Thanks

  • @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 leave CloudFlare unless there’s another way to do it ?

    No, there isn’t. The way Cloudflare works is to force all of the traffic through a reverse proxy which they control - so even if your request originates in France, it’s going to the US first to be spooled through Cloudflare’s proxy service before being sent onto the origin server.

    This has two undesired results

    1. Traffic eavesdropping by Cloudflare
    2. Sending traffic through a US entity meaning privacy is not going to be respected, or even if it is, it will me much less than you desire and you cannot change that

    Legacy tools such as cloudfail.py could easily bypass the reverse proxy and expose the origin address. These days, that tool only works on seriously weak configurations, but ZenRows will still work and can easily expose the IP you are attempting to hide.

    https://www.zenrows.com/blog/cloudfail

    You could set up a VPS with a reverse proxy to send the requests onto the origin, so you would only be exposing the reverse proxy itself in the same manner as Cloudflare, but that adds an additional hop, and also presents a single point of failure and something else to monitor and check.

    @DownPW said in NodeBB socket with CloudFlare:

    That said, the problem being mainly the socket connections, wouldn’t it be possible to pass ONLY its connections without going through CloudFlare? To do this, you will have to create a subdomain of the root domain and not proxy it via Cloudflare but just in DNS Only, then indicate this in nodebb’s config.json

    That’s possible, but you would then need to route socket.io through a sub domain in DNS mode only. This is pointless in terms of protection, as the sub domain could then be used to expose the origin host, and you’ve gained nothing.

    @DownPW said in NodeBB socket with CloudFlare:

    If I’m not mistaken, this might fix the wss and error 400 issues.

    Correct, but the above point still remains

    @DownPW said in NodeBB socket with CloudFlare:

    This would solve a lot of problem with CloudFlare’s free plan no?

    Not really. You still have the Bot Fight Mode issue where the enhanced protection means your site cannot be crawled by Google for example, as their entire ASN will be blocked.

    @DownPW said in NodeBB socket with CloudFlare:

    Afterwards I am ready to leave CloudFlare if another possibility of hiding your IP is possible but in the meantime, could this be a solution ?

    I don’t understand why people insist on hiding behind Cloudflare.

    1. Going through the proxy service at Cloudflare will slow your traffic down. Think of a funnel - it’s wide at the top, and very narrow at the bottom to fit into the available space (such as the neck of a bottle). Traffic arriving here starts out with having say 8 lanes to enter, then goes down to 1 with severe congestion meaning everything else has to wait behind what’s in front.

    Effectively, something like this 🤔

    traffic jam-min.jpg

    The free plan is first come, first served meaning there is no guarantees of traffic being delivered, meaning that anything time sensitive will suffer as a result. This is that causes socket.io to respond with http 400 because the connection is not established in time.

    If you think about how TCP works, then in a lot of cases, the delay is not noticeable as most TCP requests will wait for 30 seconds before being terminated (whereas in direct contrast, UDP will request a connection and not wait for a response). Sockets however are different as they provide a direct connection to the origin, and can be re-used to send traffic back and forth without needing to establish a new connection every time. However, if a remote socket does not receive a response in a set period of time, that session is closed and a new one needs to be opened.

    This is a security mechanism to prevent the socket from being exploited and providing a direct route to the origin host.

    Hiding your IP address is security through obscurity, and generally, bad practice

    https://www.777networks.co.uk/what-is-security-through-obscurity-and-why-is-it-bad/

    Hiding behind Cloudflare with no other protection in place is an effective air-gap, but once you circumvent the proxy IP (which is definitely possible), you are a sitting duck if you’ve relied on CF to protect you.

  • I bought a lot of Nginx reverse proxy servers, but cf is too slow in my country, I set my main server nodebb to be accessible only via vpn network, and I think that’s fine if no one attacks the server!

  • @veronikya only accessible via VPN is very secure, and easily the best way to completely isolate the site from the rest of the Internet.

    The downside of this is that your site isn’t publicly accessible without the VPN connection which would mean it falls under the umbrella of deep web. However, depending on the content, it may be what is required in order to keep sensitive information or topics secured.

  • Hello

    just for test, I wanted to test that configuration in my dev instance :

    https://community.nodebb.org/topic/7930/using-cloudflare-with-nodebb

    But I have this error uninterruptedly :

    b5eb4be0-873f-45c7-8c70-08f83bf35e34-image.png
    And I don’t know why

    Nodebb config for socket.io :

    aa9716b3-506c-4551-a582-50d4cf91cf89-image.png

    Nginx config for socket.XXXX.XXXX

    server {
    	server_name socket.XXXXX.fr www.socket.XXXX.fr mail.socket.XXXX.fr;
    	root /home/XXXXX/domains/socket.XXXX.fr/public_html;
    	index index.php index.htm index.html;
    	access_log /var/log/virtualmin/socket.XXXX.fr_access_log;
    	error_log /var/log/virtualmin/socket.XXXX.fr_error_log;
    	fastcgi_param GATEWAY_INTERFACE CGI/1.1;
    	fastcgi_param SERVER_SOFTWARE nginx;
    	fastcgi_param QUERY_STRING $query_string;
    	fastcgi_param REQUEST_METHOD $request_method;
    	fastcgi_param CONTENT_TYPE $content_type;
    	fastcgi_param CONTENT_LENGTH $content_length;
    	fastcgi_param SCRIPT_FILENAME "/home/XXXXX/domains/socket.XXXXXX.fr/public_html$fastcgi_script_name";
    	fastcgi_param SCRIPT_NAME $fastcgi_script_name;
    	fastcgi_param REQUEST_URI $request_uri;
    	fastcgi_param DOCUMENT_URI $document_uri;
    	fastcgi_param DOCUMENT_ROOT /home/XXXXX/domains/socket.XXXXX.fr/public_html;
    	fastcgi_param SERVER_PROTOCOL $server_protocol;
    	fastcgi_param REMOTE_ADDR $remote_addr;
    	fastcgi_param REMOTE_PORT $remote_port;
    	fastcgi_param SERVER_ADDR $server_addr;
    	fastcgi_param SERVER_PORT $server_port;
    	fastcgi_param SERVER_NAME $server_name;
    	fastcgi_param PATH_INFO $fastcgi_path_info;
    	fastcgi_param HTTPS $https;
    	location ^~ /.well-known/ {
    		try_files $uri /;
    	}
    	location ~ "\.php(/|$)" {
    		try_files $uri $fastcgi_script_name =404;
    		default_type application/x-httpd-php;
    		fastcgi_pass unix:/var/php-fpm/16908800991403014.sock;
    	}
    
    	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;
        }
    
    	fastcgi_split_path_info "^(.+\.php)(/.+)$";
    	location /cgi-bin/ {
    		gzip off;
    		root /home/XXXXX/domains/socket.XXXXX.fr/cgi-bin;
    		fastcgi_pass unix:/var/fcgiwrap/16908800991403014.sock/socket;
    		fastcgi_param SCRIPT_FILENAME "/home/XXXXXXX/domains/socket.XXXXXX.fr$fastcgi_script_name";
    		fastcgi_param GATEWAY_INTERFACE CGI/1.1;
    		fastcgi_param SERVER_SOFTWARE nginx;
    		fastcgi_param QUERY_STRING $query_string;
    		fastcgi_param REQUEST_METHOD $request_method;
    		fastcgi_param CONTENT_TYPE $content_type;
    		fastcgi_param CONTENT_LENGTH $content_length;
    		fastcgi_param SCRIPT_NAME $fastcgi_script_name;
    		fastcgi_param REQUEST_URI $request_uri;
    		fastcgi_param DOCUMENT_URI $document_uri;
    		fastcgi_param DOCUMENT_ROOT /home/XXXXXXX/domains/socket.XXXXXXX.fr/public_html;
    		fastcgi_param SERVER_PROTOCOL $server_protocol;
    		fastcgi_param REMOTE_ADDR $remote_addr;
    		fastcgi_param REMOTE_PORT $remote_port;
    		fastcgi_param SERVER_ADDR $server_addr;
    		fastcgi_param SERVER_PORT $server_port;
    		fastcgi_param SERVER_NAME $server_name;
    		fastcgi_param PATH_INFO $fastcgi_path_info;
    		fastcgi_param HTTPS $https;
    	}
    	listen x.x.x.x:443 ssl;
    	listen [x.x.x.x::1]:443 ssl;
        ssl_certificate /etc/letsencrypt/live/media.XXXXXX.fr/fullchain.pem; # managed by Certbot
        ssl_certificate_key /etc/letsencrypt/live/media.XXXXXXXX.fr/privkey.pem;
     # managed by Certbot
    }
    server {
        if ($host = socket.virtuaverse.fr) {
            return 301 https://$host$request_uri;
        } # managed by Certbot
    
    
    	server_name socket.XXXXXXXX.fr www.socket.XXXXXX.fr mail.socket.XXXXXXx.fr;
    	listen x.x.x.x;
    	listen [x.x.x.x::1];
        return 404; # managed by Certbot
    
    
    }
    

    Cloudflare config :

    6dd0bf70-d22d-4fb5-a5c3-e5a275722dcc-image.png

  • @DownPW Does this issue manifest itself in Incognito mode?

  • yes, it does

  • @DownPW You should simplify the nginx config - below a suggestion

    server {
    	server_name socket.XXXXX.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;
    	listen x.x.x.x:443 ssl;
    	listen [x.x.x.x::1]:443 ssl;
        ssl_certificate /etc/letsencrypt/live/media.XXXXXX.fr/fullchain.pem; # managed by Certbot
        ssl_certificate_key /etc/letsencrypt/live/media.XXXXXXXX.fr/privkey.pem;
    
    	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;
        }
    
    
     # managed by Certbot
    }
    server {
        if ($host = socket.virtuaverse.fr) {
            return 301 https://$host$request_uri;
        } # managed by Certbot
    	server_name socket.XXXXXXXX.fr www.socket.XXXXXX.fr mail.socket.XXXXXXx.fr;
    	listen x.x.x.x;
    	listen [x.x.x.x::1];
        return 404; # managed by Certbot
    }
    
  • @DownPW Also remove these lines and restart nginx

    root /home/XXXXX/domains/socket.XXXX.fr/public_html;
    
    	index index.php index.htm index.html;
    
  • I see this on start log nodebb

    e5fc0e62-fa92-461d-9bfe-2b2b9ace2232-image.png

  • phenomlabundefined phenomlab forked this topic on
  • There’s more of an issue here - try to change any CSS or JS in the ACP, and you’ll see that it does not save.

  • @DownPW Now working for me in Incognito. Can you check

  • @phenomlab said in NodeBB socket with CloudFlare:

    There’s more of an issue here - try to change any CSS or JS in the ACP, and you’ll see that it does not save.

    due to socket.io configuration in nodebb config.json file

    Actually I have delete socket.io block and change CSS and save is good.

  • @DownPW Ok, but that now means you should not need the socket A record anymore because it’s not used. From the logs, the socket is running on the site’s URL.

  • normal that it is not used (A record) @phenomlab because there currently, I do not use it because the socket.io block is removed from config.json.

    I’m just in normal mode with Cloudflare :

    5272437e-9b74-4482-881a-5c376cf73900-image.png

    I can put it back if you want ?

  • @DownPW It seems to be working fine without it, so I’d leave it. I see zero socket errors, so all good.

  • because I’m alone on the server.

    The goal is to try to market this method before putting it into production where i have a lot of errors

    And we can see that it doesn’t work when I try to reroute the web sockets in non-proxied mode. (socket error, no save when chnage in ACP, etc…)

    I don’t know if I can make myself understood. @phenomlab 🙂


Related Topics
  • SEO and Nodebb

    Performance
    2
    2 Votes
    2 Posts
    210 Views

    @Panda It’s the best it’s ever been to be honest. I’ve used a myriad of systems in the past - most notably, WordPress, and then Flarum (which for SEO, was absolutely dire - they never even had SEO out of the box, and relied on a third party extension to do it), and NodeBB easily fares the best - see below example

    https://www.google.com/search?q=site%3Asudonix.org&oq=site%3Asudonix.org&aqs=chrome..69i57j69i60j69i58j69i60l2.9039j0j3&sourceid=chrome&ie=UTF-8#ip=1

    However, this was not without significant effort on my part once I’d migrated from COM to ORG - see below posts

    https://community.nodebb.org/topic/17286/google-crawl-error-after-site-migration/17?_=1688461250365

    And also

    https://support.google.com/webmasters/thread/221027803?hl=en&msgid=221464164

    It was painful to say the least - as it turns out, there was an issue in NodeBB core that prevented spiders from getting to content, which as far as I understand, is now fixed. SEO in itself is a dark art - a black box that nobody really fully understands, and it’s essentially going to boil down to one thing - “content”.

    Google’s algorithm for indexing has also changed dramatically over the years. They only now crawl content that has value, so if it believes that your site has nothing to offer, it will simply skip it.

  • Sidebar Widget is no longer on the side!

    Moved Solved General
    4
    2 Votes
    4 Posts
    234 Views

    @Panda said in Sidebar Widget is no longer on the side!:

    Ah, so sidebar wont work on mobile?

    Correct. If you review the docs on bootstrap, you’ll notice that it is designed on a grid system

    https://getbootstrap.com/docs/5.0/layout/grid/

    What I mean by changing the category is moving it on here to general as you posted it in bugs, when it isn’t.

  • adding some console.log to Nodebb

    Solved Customisation
    4
    1 Votes
    4 Posts
    488 Views

    @eeeee if you’re using the console, you could try

    node app.js > app.log 2>&1

    This would redirect stdout to a file named app.log and redirect stderr to stdout.

    I’m not sure about standard logging under NodeBB, but there is an error log located at logs/error.log.

    Failing that, you could always stop the NodeBB service then use ./nodebb dev from the console which would then provide debug output.

  • build nodebb Warning in entrypoint size limit

    Solved Performance
    2
    0 Votes
    2 Posts
    161 Views

    @eeeee they are nothing to worry about, and can be ignored.

  • Forum Icons NodeBB

    Solved Customisation
    13
    0 Votes
    13 Posts
    913 Views

    @cagatay That matches what I see

    4f0f858d-9812-42b1-9f61-ffb13d31dccd-image.png

  • How to downgrade plugin version on NodeBB

    Solved Customisation
    11
    3 Votes
    11 Posts
    726 Views

    @cagatay no problems

  • NodeBB slow after DB recovery

    Solved Performance
    1
    5 Votes
    1 Posts
    254 Views
    No one has replied
  • NodeBB 1.19.3

    Solved Performance
    33
    4 Votes
    33 Posts
    3k Views

    @phenomlab

    I find the problem Mark 😉

    The error message indicated this path :

    http://localhost:4567/assets/plugins/nodebb-plugin-emoji/emoji/styles.css?v=6983dobg16u

    I change the path url on config.json

    47bacc80-f141-41e4-a261-3f8d650cc6f6-image.png

    And all it’s good 🙂

    Weird, I didn’t have to change that path before 1.19.3

    But this does not prevent the problem from a clean install with Emoji Plugin

    EDIT: After test, that resolv the problem installation for 1.18.x but not for 1.19.x (I have other error message when I run ./nodebb Setup

    For resume: NodeJS 16_x with 1.18.x is ok