Skip to content

NodeBB socket with CloudFlare

Unsolved Performance
  • 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;
    
  • Same

    image.png

  • 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 🙂

  • @DownPW Understood. Even with just the two of us connected, I was still getting the websocket error, but I think that was related to config etc. In all honesty, this is yet another reason why I stopped using CF. I know you need it to hide your IP address, but if you bypass CF for the socket, you are exposing your IP anyway.

  • I know, I know,

    too bad… I just wanted to test this method but it seems more complex than it looks to make it work correctly

    The reverse proxy method is currently too expensive for me and technically too abstract

  • @DownPW it’s your only realistic option at this stage.


Related Topics
  • Block Domain

    Solved Let's Build It
    26
    1 Votes
    26 Posts
    2k Views

    Yes ogproxy too is functionnal on dev

  • 4 Votes
    7 Posts
    766 Views

    @phenomlab oh no, that is 1 cent on the video, but you are right, symbols are similar… I just converted it to $1 , since it is more intuitive in daily life…

  • SEO and Nodebb

    Performance
    2
    2 Votes
    2 Posts
    329 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.

  • NodeBB v3 Chat Very Slow

    Moved Performance
    47
    11 Votes
    47 Posts
    4k Views

    @DownPW Seems fine.

  • 1 Votes
    3 Posts
    306 Views

    @qwinter yes, I recently migrated this site to CF in full and noticed the same thing. Seems CF also has native socket support now under the free plan, so win/win. I’ve not noticed any degradation of service since moving so happy to stay put for the time being.

  • 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

  • NodeBB - Created pages not found?

    General
    20
    3 Votes
    20 Posts
    1k Views

    @jac Exactly. Hard point to argue.

  • RSS parser script [NodeBB]

    Customisation
    47
    9 Votes
    47 Posts
    4k Views

    @phenomlab said in RSS parser script [NodeBB]:

    @jac Not yet. Sorry. Have some other work commitments I need to prioritise. Hoping to get to this over the weekend.

    No worries at all mate, thanks 👍🏻