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 .

Happy Birthday!

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

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>;
    }
}

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.

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.

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.

@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

@trevor yep, works now!

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"
}

I mean, the whole k/v thing was weird to me from the start. I think writing a wrapper around the database stuff and then in the future maybe being able to do npm i nodebb-database-redis, npm i nodebb-database-mongo, npm i nodebb-database-postgresql, etc. would be awesome. Also because everyone could help writing these wrappers for new databases etc.

@teh_g Yep, should still work and there is also the option that you don't have to set up camo manually thanks to @yariplus

@julian nope, it is being compiled down to ES5 with babeljs IIRC

EDIT: Yes, it indeed is: https://github.com/minora-oss/nodebb-plugin-camo/blob/master/package.json#L50-L60

@exodo you can now totally remove the whole configuration and let it run over your main domain as CloudFlare has enabled WebSockets for free.

@yoyimc9 Yes. @yariplus found out about this too. We know what the problem is and are discussing if we can add it to the NodeBB master or if we need to do a plugin for that, even though I think that may be overkill. Basically the problem is that the session cookie for NodeBB is set to something.domain.tld, or in your case paralocos.org. It should be *.domain.tld or *.paralocos.org so that the live.domain.tld can authorize with the cookie too.

@AOKP are there any errors I could take a look at?

@L33t Yes, that is normal. An established WebSocket connection is not "closed" until you close the tab. That's why it shows up with so many seconds. You can happily ignore that

@yariplus yep, the SSL config was probably too strong for older NGINX or OpenSSL versions. I simplified it a bit.

https://github.com/minora-oss/nodebb-plugin-camo/commit/61224dbedd229f043dcede52626fc8d5b7f09eba

0 committed to minora-oss/nodebb-plugin-camo

Simplify NGINX config to reduce the chance of errors

@ThingBreaker this seems like an issue with your SSL configuration. Did you maybe provide wrong paths to your certificates? It would be helpful if we could get your subdomain for camo too so that we can check and test some things ourselves.

@AOKP I can create a more easier to understand tutorial later, but here is how it looks for Minora at the moment. (Which is what I think you mean)

Here are our current config files, just copied it out. I think the needed information is in there, don't worry about the includes. That's just part of our structure.

NGINX: https://git.minora.io/snippets/1
NodeBB: https://git.minora.io/snippets/2