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
PW and WS Spirit alive
@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
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.
Effectively, something like this 
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 :
And I don’t know why
Nodebb config for socket.io :
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 :
PW and WS Spirit alive
@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
I see this on start log nodebb
PW and WS Spirit alive
undefined 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.
Author of OGProxy, Swatch, Threaded, Card, and most of Sudonix's bugs…
???
@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.
PW and WS Spirit alive
@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 :
I can put it back if you want ?
PW and WS Spirit alive
@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 
PW and WS Spirit alive
