Info: I am doing this small tutorial here to show you guys how to use NodeBB and CloudFlare proxying while still using WebSockets since lots of people seem to look for it. I already posted a small explanation here, but people don't seem to find it / have problems - I added some extra explanation to this so that you can avoid the problems other people had.

NodeBB version: Should work with any, tested with v0.7.x and v0.9.x

So. Basically what we're going to do is routing the WebSocket requests around CloudFlare while keeping the forum itself behind CloudFlare.

Disclaimer:

If you do this your root server is in general open to the public again. If you depend on CloudFlare's DDoS protection this will make it kind of useless. People who know what they are doing will be able to take your forum down quick if your root server has no own DDoS protection. DigitalOcean e.g. has none / I know of people who had their IP's nullrouted when being DDoS'ed at DigitalOcean.

Things you will have to replace in the following code snippets:

<domain.tld> -> your domain (e.g. `nodebb.org`)
<your.crt>   -> the path to your ssl certificate  (e.g. /home/ssl/org.nodebb.crt)
<your.key>   -> the path to your ssl private key (e.g. /home/ssl/org.nodebb.key). This key was generated by yourself when you created your certificate sign request / .csr
<port>       -> your NodeBB port
<0.0.0.0>    -> your IPv4 address
<00:0000:0000:0000:0000:0000:0000:0000>` -> your IPv6 address in case you have one

CloudFlare:

Create these DNS records with grey clouds, which means you disable CF proxying:

• A live.<domain.tld> <000.000.000.000>
• AAAA live.<domain.tld> <0000:0000:0000:0000:0000:0000:0000:0000>

NodeBB:

We will configure NodeBB to route the WebSocket requests over the subdomain by adding this to our config.json:

"socket.io": {
    "transports": ["websocket", "polling"],
    "address": "live.<domain.tld>"
}

Please make sure you add a comma to the element before "socket.io", otherwise it will be invalid JSON. Also paste the config in the JSON validator just to be sure the whole config is intact.

NGINX:

Get a free SSL certificate from Let's Encrypt or StartCom, and add this new server block to your NGINX configuration:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    ssl_certificate <your.crt>;
    ssl_certificate_key <your.key>;
    server_name live.<domain.tld>;
    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:<port>;
    }
}

Make sure that:

• your ssl certificate is valid and includes your subdomain live.domain.tld
• you have at least 2 server blocks now in your NGINX configuration.

Then run service nginx configtest to validate your new configuration. If it succeeds you can reload NGINX by using service nginx reload

And now you're done. Pretty simple. Hope this helps somebody using NodeBB.

In case something shouldn't be working please provide an error message, your NodeBB config without credentials / secrets and the NGINX server blocks .

@константин-носов

Create these DNS records with grey clouds, which means you disable CF proxying:

• A live.domain.tld <000.000.000.000>
• AAAA live.domain.tld <0000:0000:0000:0000:0000:0000:0000:0000>

And put this in your NodeBB configuration:

"socket.io": {
    "transports": ["websocket", "polling"],
    "address": "live.domain.tld"
}

Then get a free SSL certificate from Let's Encrypt or StartCom, and add this to your NGINX configuration:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    ssl_certificate <your>.crt;
    ssl_certificate_key <your>.key;
    server_name live.domain.tld;
    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:<port>;
    }
}

Happy Birthday!

Info:

This tutorial is specialized for people who want to run Camo themselves. E.g. when you need clustering or have several POP's. In case you just want to use camo I recommend you visiting the original post.

The following "variables" will be used:

<domain>     -> your camo domain (e.g. https://camo.nodebb.org or camo.nodebb.org)
<your.crt>   -> the path to your ssl certificate  (e.g. /home/ssl/org.nodebb.crt)
<your.key>   -> the path to your ssl private key (e.g. /home/ssl/org.nodebb.key). This key was generated by yourself when you created your certificate sign request / .csr
<port>       -> your camo port, either from the standalone or integrated one.
<camo-key>   -> a secret HMAC key. You could generate this using pwgen -sB 64 

Configuring NGINX for proxying camo

Get a free SSL certificate from Let's Encrypt or StartCom, and add this new server block to your NGINX configuration:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name <domain>;
    access_log off;
    error_log /dev/null;

    ssl_session_cache         shared:SSL:10m;
    ssl_session_timeout       10m;
    ssl_session_tickets       off;
    ssl_prefer_server_ciphers on;
    ssl_ciphers               'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
    ssl_ecdh_curve            secp384r1;
    ssl_buffer_size           1400;
    ssl_protocols             TLSv1 TLSv1.1 TLSv1.2;

    ssl_certificate           <your.crt>;
    ssl_certificate_key       <your.key>;

    charset utf-8;

    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_redirect                   off;
        proxy_http_version               1.1;
        proxy_pass                       http://localhost:<port>;
    }
}

Make sure that:

• your ssl certificate is valid and includes your subdomain camo.domain.tld
• you have at least 2 server blocks now in your NGINX configuration.

Then run service nginx configtest to validate your new configuration. If it succeeds you can reload NGINX by using service nginx reload. After this you can add camo.<domain.tld> into the camo host field and reload NodeBB. Now continue with installing camo.

Installing camo

Camo is being configured by environment variables which is why I usually run it in docker, but here I'll provide details on how to install it directly like NodeBB. This is only useful if you want more fine grained control or clustering for sites with heavy load.

Clone camo from GitHub by executing:

git clone https://github.com/atmos/camo.git

You can then cd into the camo folder and start it using:

sudo PORT=<port> CAMO_KEY="<camo-key>" node server.js

Other variables you could add are:

• CAMO_HEADER_VIA: The string for Camo to include in the Via and User-Agent headers it sends in requests to origin servers. (default: Camo Asset Proxy <version>)
• CAMO_LENGTH_LIMIT: The maximum Content-Length Camo will proxy. (default: 5242880)
• CAMO_LOGGING_ENABLED: The logging level used for reporting debug or error information. Options are debug and disabled. (default: disabled)
• CAMO_MAX_REDIRECTS: The maximum number of redirects Camo will follow while fetching an image. (default: 4)
• CAMO_SOCKET_TIMEOUT: The maximum number of seconds Camo will wait before giving up on fetching an image. (default: 10)
• CAMO_TIMING_ALLOW_ORIGIN: The string for Camo to include in the Timing-Allow-Origin header it sends in responses to clients. The header is omitted if this environment variable is not set. (default: not set)
• CAMO_HOSTNAME: The Camo-Host header value that Camo will send. (default: unknown)
• CAMO_KEEP_ALIVE: Whether or not to enable keep-alive session. (default: false)

I would also recommend installing screen and forever, on Debian you would do this by executing:

apt-get install screen && npm i -g forever

and then starting your app with:

screen -S camo sudo PORT=<port> CAMO_KEY="<camo-key>" forever server.js

This runs camo in a screen you can exit by using CTRL+A+D while still letting it run in the background and preserving any error logs. forever keeps care of restarting it in case it crashes. Test if your server.js starts by manually using node though before you use them both, otherwise you'll create a process crashing and restarting really fast.

Yep, there is a missing comma after the } which is before "socket.io". After you fixed it paste the config in the JSON validator just to be sure there is nothing else left.

I added NodeBB to the Wikipedia site "Comparison of Internet forum software", that might be a first step to get a whole own page too. Let's see if they accept it, but I don't see any reason why they shouldn't. You can go here for the history, and click "thank" and maybe also write on the "talk" page. That way they see that people are interested in it.

@nanjusoil In general I would not recommend Incapsula because their target customers are more enterprise-related (people who pay). E.g. you wont have SSL encryption with your free plan, you can't purge cache and there is no DDoS protection. (Yes, I am serious. Go to their Plan comparison page and open all the tabs, you'll see a lot more details there.)

I also didn't see anything about WebSockets being enabled on any plan and have also heard of Incapsula not being sure themselves if they provide them or not.

@julian said:

A bit worrysome that we're getting conflicting information from the Incapsula sales team...

from topic/websocket-domain.

I have also just created a tutorial on how to use CloudFlare with WebSockets for free here

@Pilvinen

You need to make the storage persistent. You do that by putting that in your /etc/redis/redis.conf:

save 60 1000

This saves your DB every 60 seconds if you change more than 1000 keys. If you want to be really careful you can change that to lower values like save 30 500 etc.

You should also enable the append-only file

appendonly yes

From now on, every time Redis receives a command that changes the data it will append it to the AOF. When you restart Redis it will re-play the AOF to rebuild the state.

If you want to know more you can go to:

redis.io/documentation and
redis.io/topics/persistence

After one year and diving deep into NGINX configuration and Node development I've finally found a solution for using subfolders with NGINX and NodeBB:

NGINX configuration:

server {
    listen 443 ssl;
    listen 80;
    listen [::]:443 ssl;
    listen [::]:80;
    server_name domain.tld;
    index index.html;
    location ^~ /community {
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header Referer           $http_referer;
        proxy_set_header Host              $host;
        proxy_set_header Cookie            $http_cookie;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Host  $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Port  $server_port;
        proxy_set_header X-NginX-Proxy     true;
        proxy_redirect                     off;
        proxy_http_version                 1.1;
        proxy_pass                         http://localhost:<port>;
    }
    location / {
         // stuff for your main app
    }
}

NodeBB configuration part:

{
    "url": "https://domain.tld/community"
}

@charles, @accalia and @qgp9

nodebb-plugin-camo just got released which should make this whole issue a lot easier to solve. You can find the explanation post here.

@trevor yep, works now!

redis-cli

then

AUTH <password>

(If you have AUTH enabled)

then

select <db>

then

flushdb

@xCausxn Nope, its not :

"WebSocket connection to 'wss://forums.gamerlabs.net/socket.io/1/websocket/hYGYH3JWv9X76FZYhx7Q' failed: Error during WebSocket handshake: Unexpected response code: 502"

This bug was already posted to the issue tracker and will be fixed in the upcoming version 0.9.0 I guess.

Empty sitemap · Issue #3781 · NodeBB/NodeBB

I have a problem with the sitemap. I think that it's not my fault, i didn't find anything about it. Anyway thanks for the help and for this nice software ;)

GitHub (github.com)

When will this be ready? I want this now.....

@ferik as long as you set up your NodeBB with an email-plugin - Yeah. There will be an email sent, and I think that you can't even post etc. before you get approved.

That is NodeBB trying to establish a websocket connection. It fails because you are using cloudflare and websockets are only available for enterprise customers. Normal long polling with HTTP/S GET and POST would actually work, but NodeBB is built for using websockets. You would need to modify the NodeBB core to stop using websockets, and this'd be a lot of work. Also, I don't understand why your server is under heavy load? Cloudflare is just blocking these requests by returning a 400. Your root server should not be getting any of these requests.

An option would be that you configure NodeBB to use a subdomain, e.g websockets.exo.do, and disable cloudflare from proxying this subdomain by clicking on the cloud-symbol so that it is grey.

@trevor for me everything works. Also the SSL certificate. @jarey Let's Encrypt still has problems with Windows XP, any chance that you are using it? They will fix it in the near future letsencrypt.org/upcoming-features/

Also @trevor your status on convoe is always flashing to green every 5 seconds and then going back to offline. Seems like a bug to me.

Hey @j-b-o,

camo is being configured by environment variables which is why I usually run it in docker. To fix your case you should be able to start your server by using:

PORT=8081 CAMO_KEY="<your camo key>" node server.js

(You could actually not add the PORT env, as 8081 is the default, but I added it to show you better how to add variables.)

Other variables you could add are:

• PORT: The port number Camo should listen on. (default: 8081)
• CAMO_HEADER_VIA: The string for Camo to include in the Via and User-Agent headers it sends in requests to origin servers. (default: Camo Asset Proxy <version>)
• CAMO_KEY: The shared key used to generate the HMAC digest.
• CAMO_LENGTH_LIMIT: The maximum Content-Length Camo will proxy. (default: 5242880)
• CAMO_LOGGING_ENABLED: The logging level used for reporting debug or error information. Options are debug and disabled. (default: disabled)
• CAMO_MAX_REDIRECTS: The maximum number of redirects Camo will follow while fetching an image. (default: 4)
• CAMO_SOCKET_TIMEOUT: The maximum number of seconds Camo will wait before giving up on fetching an image. (default: 10)
• CAMO_TIMING_ALLOW_ORIGIN: The string for Camo to include in the Timing-Allow-Origin header it sends in responses to clients. The header is omitted if this environment variable is not set. (default: not set)
• CAMO_HOSTNAME: The Camo-Host header value that Camo will send. (default: unknown)
• CAMO_KEEP_ALIVE: Whether or not to enable keep-alive session. (default: false)

I would also recommend installing screen and forever, on Debian you would do this by executing:

apt-get install screen && npm i -g forever

and then starting your app with:

screen -S camo sudo PORT=8081 CAMO_KEY="<your camo key>" forever server.js

This runs camo in a screen you can exit by using CTRL+A+D while still letting it run in the background and preserving any error logs. forever keeps care of restarting it in case it crashes. Test if your server.js starts by manually using node though before you use them both, otherwise you'll create a process crashing and restarting really fast.

I can review and translate to German together with @AOKP