Skip to content

NODEBB: Nginx error performance & High CPU

Solved Performance
69 3 62.9k 2
  • @DownPW I’ve just started reviewing your nginx.log and a couple of things immediately stand out for me

    1. Literally all of the IP addresses are within Cloudflare’s subnet ranges. This means that you cannot possibly tell if the traffic is legitimate or not as you do not know what the originating IP addresses are
    2. The TCP established times are all within seconds of each other but from different IP addresses. This very much lends itself towards the traffic not being organic in my view, but you will never really know the true identity of these connections without first attempting to unpack the TCP headers - see the below

    https://support.cloudflare.com/hc/en-us/articles/200170786-Restoring-original-visitor-IPs

    24c3670c-c9a2-4da0-a4d2-ded8c65d033a-image.png

    You could temporarily disable Cloudflare on your site to get a quick analysis, then keep an eye on your own DDoS implementation to determine if this traffic is legitimate or not.

    The bottom line is this. Don’t be lulled into a false sense of security just because Cloudflare passes the traffic to your site.

    wrote on last edited by DownPW
    #6

    @phenomlab

    I don’t understand all you say.
    Finally what we can do ?

    Actually we have 1.1k users online

    We have a lot of inscriptions

  • @phenomlab

    I don’t understand all you say.
    Finally what we can do ?

    Actually we have 1.1k users online

    We have a lot of inscriptions

    wrote on last edited by DownPW
    #7

    @phenomlab 362 user inscription in two days and many user on just read forum

  • @phenomlab

    I don’t understand all you say.
    Finally what we can do ?

    Actually we have 1.1k users online

    We have a lot of inscriptions

    wrote on last edited by phenomlab
    #8

    @DownPW said in NODEBB: Nginx error performance & High CPU:

    I don’t understand all you say.
    Finally what we can do ?

    My point here is that the traffic, whilst legitimate in the sense that it’s from another site that has closed, could still be nefarious in nature so you should keep your guard up. However, a number of signups can’t be wrong - particularly if they are actually posting content and not performing requests that actually do not pertain to available URL’s on your site.

    I see no indication of that, so the comfort level in the sense that it’s legitimate traffic does increase somewhat accompanied by the seemingly legitimate registrations. However, because all the source IP addresses and within the Cloudflare ranges, you have no ability to tell really who they are without performing the steps I outlined in the previous post.

    The good news is that your site just got a huge increase in popularity, but with that will always be a need to keep a close eye on activity. It would only take one nefarious actor to potentially bring down your site.

    The nginx configuration you’ve applied will indeed alleviate the stress placed on the server but is a double edged sword in the sense that it does make the goalpost much wider in terms of any potential attack.

    My advice herein would be to not scale these settings too high. Use sane judgement.

    For the NodeBB side, I know they have baked rate limiting into the product but I’m sure you can actually change that behaviour.

    Have a look at

    /admin/settings/advanced#traffic-management
    

    You’ll probably need to play with the values here to get a decent balance, but this is where I’d start.

  • @DownPW said in NODEBB: Nginx error performance & High CPU:

    I don’t understand all you say.
    Finally what we can do ?

    My point here is that the traffic, whilst legitimate in the sense that it’s from another site that has closed, could still be nefarious in nature so you should keep your guard up. However, a number of signups can’t be wrong - particularly if they are actually posting content and not performing requests that actually do not pertain to available URL’s on your site.

    I see no indication of that, so the comfort level in the sense that it’s legitimate traffic does increase somewhat accompanied by the seemingly legitimate registrations. However, because all the source IP addresses and within the Cloudflare ranges, you have no ability to tell really who they are without performing the steps I outlined in the previous post.

    The good news is that your site just got a huge increase in popularity, but with that will always be a need to keep a close eye on activity. It would only take one nefarious actor to potentially bring down your site.

    The nginx configuration you’ve applied will indeed alleviate the stress placed on the server but is a double edged sword in the sense that it does make the goalpost much wider in terms of any potential attack.

    My advice herein would be to not scale these settings too high. Use sane judgement.

    For the NodeBB side, I know they have baked rate limiting into the product but I’m sure you can actually change that behaviour.

    Have a look at

    /admin/settings/advanced#traffic-management
    

    You’ll probably need to play with the values here to get a decent balance, but this is where I’d start.

    wrote on last edited by DownPW
    #9

    @phenomlab

    I think you’re right Mark and that’s why I come here looking for your valuable advice and expertise 😉

    Basically, the illegal site that closed was a movie download site A topic was opened on our forum to talk about it and many came looking for answers on why and how.

    You’re actually right about the fact that we can’t be sure of anything and there are bot attacks or ddos in the lot of connexions

    I activated the under attack mode on Cloudflare as you advised me to see (just now.) and we will see like you said

    As you advised, I also reset the default nginx configuration values ​​and removed my nginx modifications specified above.

    I would like to take advantage of your expertise, see a hand from you to properly configure nginx for ddos ​​and high traffic. (What precise modifications to specify as well as the precise values.)

  • @phenomlab

    I think you’re right Mark and that’s why I come here looking for your valuable advice and expertise 😉

    Basically, the illegal site that closed was a movie download site A topic was opened on our forum to talk about it and many came looking for answers on why and how.

    You’re actually right about the fact that we can’t be sure of anything and there are bot attacks or ddos in the lot of connexions

    I activated the under attack mode on Cloudflare as you advised me to see (just now.) and we will see like you said

    As you advised, I also reset the default nginx configuration values ​​and removed my nginx modifications specified above.

    I would like to take advantage of your expertise, see a hand from you to properly configure nginx for ddos ​​and high traffic. (What precise modifications to specify as well as the precise values.)

    wrote on last edited by
    #10

    @DownPW ok, good. Let’s see what the challenge does to the site traffic. Those whom are legitimate users won’t mind having to perform a one time additional authentication step, but bots of course will simply stumble at this hurdle.

  • @DownPW ok, good. Let’s see what the challenge does to the site traffic. Those whom are legitimate users won’t mind having to perform a one time additional authentication step, but bots of course will simply stumble at this hurdle.

    wrote on last edited by DownPW
    #11

    @phenomlab

    number of user is better (408) but a lot of loose connexion. navigation is hard

  • @phenomlab

    number of user is better (408) but a lot of loose connexion. navigation is hard

    wrote on last edited by
    #12

    I have chaneg nginx conf with :

    worker_rlimit_nofile 70000;

    events {
    worker_connections 65535;
    multi_accept on;
    }

    CF is under attack mode

  • I have chaneg nginx conf with :

    worker_rlimit_nofile 70000;

    events {
    worker_connections 65535;
    multi_accept on;
    }

    CF is under attack mode

    wrote on last edited by phenomlab
    #13

    @DownPW I still have access to your Cloudflare tenant so will have a look shortly.

    EDIT: I am in now - personally, I would also enable this (and configure it)

    d85820ea-6643-49bd-98da-a8537e970f04-image.png

    b6a188a9-deba-4980-b4a1-99df7975160d-image.png

  • @DownPW I still have access to your Cloudflare tenant so will have a look shortly.

    EDIT: I am in now - personally, I would also enable this (and configure it)

    d85820ea-6643-49bd-98da-a8537e970f04-image.png

    b6a188a9-deba-4980-b4a1-99df7975160d-image.png

    wrote on last edited by DownPW
    #14

    @phenomlab I have already activate it and add a waf rules for russian country

    2e3108dc-8d68-4e48-91c7-e1c3bc00c229-image.png

    With this bots settings :
    e12409dd-df54-4def-b998-470786c3afa9-image.png

    and this settings for ddos protection :

    2e176374-f7d1-48e4-b38f-83360a0f182a-image.png

  • @phenomlab I have already activate it and add a waf rules for russian country

    2e3108dc-8d68-4e48-91c7-e1c3bc00c229-image.png

    With this bots settings :
    e12409dd-df54-4def-b998-470786c3afa9-image.png

    and this settings for ddos protection :

    2e176374-f7d1-48e4-b38f-83360a0f182a-image.png

    wrote on last edited by
    #15

    @DownPW said in NODEBB: Nginx error performance & High CPU:

    I have already activate it

    Are you sure? When I checked your tenant it wasn’t active - it’s from where I took the screenshot 😁

  • @DownPW said in NODEBB: Nginx error performance & High CPU:

    I have already activate it

    Are you sure? When I checked your tenant it wasn’t active - it’s from where I took the screenshot 😁

    wrote on last edited by
    #16

    @phenomlab

    yep I activate it after 😉

  • @phenomlab

    yep I activate it after 😉

    wrote on last edited by DownPW
    #17

    For your information @phenomlab ,

    • I have ban via iptables suspicious ip address find on /etc/nginx/accesss.log and virtualhost access.log like this : iptables -I INPUT -s IPADDRESS -j DROP
    • Activate bot option on CF
    • Create contry rules (Russie and China) on CF WAF
    • I left under attack mode option activated on CF
    • I have just change nginx.conf like this for test (If you have best value, I take it ! ) :
    worker_rlimit_nofile 70000; 
    
    events {
    
    	worker_connections 65535;
    	multi_accept on; 
    }
    
    http {
    
    	##
    	# Basic Settings
    	##
    
    	limit_req_zone $binary_remote_addr zone=flood:10m rate=100r/s; 
    	limit_req zone=flood burst=100 nodelay; 
    	limit_conn_zone $binary_remote_addr zone=ddos:10m; 
    	limit_conn ddos 100;
    

    100r/s iit’s already a lot !!

    and for vhost file :

    server {
    	.....
    
            location / {
    				
    				limit_req zone=flood; #Test 
    				limit_conn ddos 100; #Test 
    }
    

    –> If you have other ideas, I’m interested
    –> If you have better values ​​to use in what I modified, please let me know.

  • For your information @phenomlab ,

    • I have ban via iptables suspicious ip address find on /etc/nginx/accesss.log and virtualhost access.log like this : iptables -I INPUT -s IPADDRESS -j DROP
    • Activate bot option on CF
    • Create contry rules (Russie and China) on CF WAF
    • I left under attack mode option activated on CF
    • I have just change nginx.conf like this for test (If you have best value, I take it ! ) :
    worker_rlimit_nofile 70000; 
    
    events {
    
    	worker_connections 65535;
    	multi_accept on; 
    }
    
    http {
    
    	##
    	# Basic Settings
    	##
    
    	limit_req_zone $binary_remote_addr zone=flood:10m rate=100r/s; 
    	limit_req zone=flood burst=100 nodelay; 
    	limit_conn_zone $binary_remote_addr zone=ddos:10m; 
    	limit_conn ddos 100;
    

    100r/s iit’s already a lot !!

    and for vhost file :

    server {
    	.....
    
            location / {
    				
    				limit_req zone=flood; #Test 
    				limit_conn ddos 100; #Test 
    }
    

    –> If you have other ideas, I’m interested
    –> If you have better values ​​to use in what I modified, please let me know.

    wrote on last edited by phenomlab
    #18

    @DownPW my only preference would be to not set worker_connections so high

  • @DownPW my only preference would be to not set worker_connections so high

    wrote on last edited by
    #19

    @phenomlab

    Ok so what value do you advise?

  • @phenomlab

    Ok so what value do you advise?

    wrote on last edited by phenomlab
    #20

    @DownPW you should base it on the output of ulimit - see below

    https://linuxhint.com/what-are-worker-connections-nginx/#:~:text=The worker_connections are the maximum,to accommodate a higher value

    With that high value you run the risk of overwhelming your server.

  • @DownPW you should base it on the output of ulimit - see below

    https://linuxhint.com/what-are-worker-connections-nginx/#:~:text=The worker_connections are the maximum,to accommodate a higher value

    With that high value you run the risk of overwhelming your server.

    wrote on last edited by DownPW
    #21

    @phenomlab

    Thanks mark 😉

    My ulimit is 1024, so I will set it to 1024

  • @phenomlab

    Thanks mark 😉

    My ulimit is 1024, so I will set it to 1024

    wrote on last edited by
    #22

    @DownPW And the worker_processes value ? I expect this to be between 1 and 4 ?

  • @DownPW And the worker_processes value ? I expect this to be between 1 and 4 ?

    wrote on last edited by DownPW
    #23

    @phenomlab

    worker_processes auto;
    
  • @phenomlab

    worker_processes auto;
    
    wrote on last edited by
    #24

    @DownPW ok. You should refer to that some article I previously provided. You can probably set this to a static value.

  • @DownPW ok. You should refer to that some article I previously provided. You can probably set this to a static value.

    wrote on last edited by DownPW
    #25

    @phenomlab

    Ok I will see it for better worker_processes value

    I add a rate limite request and limit_conn_zone on http block and vhost block :

    – nginx.conf:

    http {
    
    	#Requete maximun par ip 
    	limit_req_zone $binary_remote_addr zone=flood:10m rate=100r/s; 
    	#Connexions maximum par ip 
    	limit_conn_zone $binary_remote_addr zone=ddos:1m;
    
    -- vhost.conf :
            location / {
    				
    				limit_req zone=flood burst=100 nodelay; 
    				limit_conn ddos 10;
    

    –> I have test other value for rate and burst but they cause problem access to the forum. If you have better, I take it

    I add today a proxy_read_timeout on vhost.conf (60 by default)

    proxy_read_timeout 180;
    

    I have deactivate underattack mode on CF and change for high Level

    I have add other rules on CF waf :

    9059db6c-f4f3-4415-bb47-ab88b2b41861-image.png


Did this solution help you?
Did you find the suggested solution useful? Support 💗 Sudonix with a coffee ☕
If your organisation needs deeper expertise around infrastructure, security, or technology leadership, learn more about Phenomlab Ltd. Many of the deeper technical guides behind Sudonix are published there.

Related Topics
  • how to prevent DDoS attacks ?

    Solved Vulnerability ddos nodebb
    34
    17 Votes
    34 Posts
    14k Views
    crazycells
    @phenomlab thank you very much, this was helpful. Everything looks ok
  • NodeBB socket with CloudFlare

    Solved Performance socket cloudflare nodebb
    24
    3 Votes
    24 Posts
    14k Views
    DownPW
    Solved. Tuto here and here
  • Is nginx necessary to use?

    Moved Solved Hosting nginx web
    2
    1 Votes
    2 Posts
    1k Views
    phenomlab
    @Panda said in Cloudflare bot fight mode and Google search: Basic question again, is nginx necessary to use? No, but you’d need something at least to handle the inbound requests, so you could use Apache, NGINX, Caddy… (there are plenty of them, but I tend to prefer NGINX) @Panda said in Cloudflare bot fight mode and Google search: Do these two sites need to be attached to different ports, and the ports put in the DNS record? No. They will both use ports 80 (HTTP) and 443 (HTTPS) by default. @Panda said in Cloudflare bot fight mode and Google search: Its not currently working, but how would the domain name know which of the two sites to resolve to without more info? Currently it only says the IP of the whole server. Yes, that’s correct. Domain routing is handled (for example) at the NGINX level, so whatever you have in DNS will be presented as the hostname, and NGINX will expect a match which once received, will then be forwarded onto the relevant destination. As an example, in your NGINX config, you could have (at a basic level used in reverse proxy mode - obviously, the IP addresses here are redacted and replaced with fakes). We assume you have created an A record in your DNS called “proxy” which resolves to 192.206.28.1, so fully qualified, will be proxy.sudonix.org in this case. The web browser requests this site, which is in turn received by NGINX and matches the below config server { server_name proxy.sudonix.org; listen 192.206.28.1; root /home/sudonix.org/domains/proxy.sudonix.org/ogproxy; index index.php index.htm index.html; access_log /var/log/virtualmin/proxy.sudonix.org_access_log; error_log /var/log/virtualmin/proxy.sudonix.org_error_log; location / { proxy_set_header Access-Control-Allow-Origin *; proxy_set_header Host $host; proxy_pass http://localhost:2000; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Api-Key $http_x_api_key; } location /images { index index.php index.htm index.html; root /home/sudonix.org/domains/proxy.sudonix.org/ogproxy; } fastcgi_split_path_info "^(.+\.php)(/.+)$"; listen 192.206.28.1:443 ssl http2; ssl_certificate /home/sudonix.org/domains/proxy.sudonix.org/ssl.combined; ssl_certificate_key /home/sudonix.org/ssl.key; } The important part here is server_name proxy.sudonix.org; as this is used to “map” the request to the actual domain name, which you can see in the root section as root /home/sudonix.org/domains/proxy.sudonix.org/ogproxy; As the DNS record you specified matches this hostname, NGINX then knows what to do with the request when it receives it.
  • Nodebb 3.2.0

    Bugs nodebb nodebb 3.2.0
    20
    1
    2 Votes
    20 Posts
    7k Views
    phenomlab
    @crazycells yes, I’m aware of that. Need to fix EDIT- fixed. Caused by the same CSS that is used to absolutely position the “verified” group badge in the posts view. Amended this CSS so that is specifically targets the post stream as below li[component="post"] a[href*="/groups/verified"] { position: absolute !important; left: 8px; z-index: 2; margin-top: 1px; border-radius: 999px !important; line-height: 14px; display: block; height: 22px; margin-left: 0px !important; }
  • adding some console.log to Nodebb

    Solved Customisation nodebb
    4
    1 Votes
    4 Posts
    2k Views
    phenomlab
    @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.
  • Optimum config for NodeBB under NGINX

    Performance nginx performance
    4
    3 Votes
    4 Posts
    2k Views
    phenomlab
    @crazycells hi - no security reason, or anything specific in this case. However, the nginx.conf I posted was from my Dev environment which uses this port as a way of not interfering with production. And yes, I use clustering on this site with three instances.
  • NodeBB v3

    Announcements nodebb v3 nodebb
    2
    3 Votes
    2 Posts
    1k Views
    phenomlab
    @cagatay JS will work fine - no changes there, and there are no plans to drop support for jQuery. More of an issue is the CSS - for which there are quite a few breaking changes. Keep an eye on sudonix.dev (my development site) where you can see progress in relation to how I am tackling the compatibility issues.
  • NodeBB slow after DB recovery

    Solved Performance performance nodebb
    1
    5 Votes
    1 Posts
    967 Views
    No one has replied