I tried to get to our website an hour ago and found it down
this looks like an attack to me, how we can stop, cloudflare is a good option for such a scenarios but that service is not suitable for discourse, please advise.
Did you do a standard install? Most likely the ip address of the requester is wrong and falsely triggering rate limits.
1 Like
I’m also just suffered this on https://se23.life - seems coincidental that I’d suffer an attack at the same time as @Jay91 ?
1 Like
Did standard install yes !
is there any way i can turn around and use cloudflare ? i trust that service a lot.
1 Like
Are you using a reverse proxy on the same server? Is anything else installed?
Cloudflare can’t help you here.
2 Likes
The problem is most likely that you have some mis-configuration that is falsely triggering the built-in free rate limiting protection.
If you don’t have a reverse proxy, do you have a whole bunch of people who are accessing your site from the same NATed IP number (e.g., a single business or university?)
if you were to use CloudFlare, you’d need to enable a template that re-writes headers so that the real IP is reported to Discourse.
5 Likes
That’s an nginx rate limiting error, configured in the templates section of app.yml:
templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
It’s the web.ratelimited.template.yml template and it configures nginx rate limiting like so:
params:
reqs_per_second: 12
burst_per_second: 12
reqs_per_minute: 200
burst_per_minute: 100
conn_per_ip: 20
run:
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /server.+{/
to: |
limit_req_zone $binary_remote_addr zone=flood:10m rate=$reqs_per_secondr/s;
limit_req_zone $binary_remote_addr zone=bot:10m rate=$reqs_per_minuter/m;
limit_req_status 429;
limit_conn_zone $binary_remote_addr zone=connperip:10m;
limit_conn_status 429;
server {
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: "/location @discourse {/"
to: |
location @discourse {
limit_conn connperip $conn_per_ip;
limit_req zone=flood burst=$burst_per_second nodelay;
limit_req zone=bot burst=$burst_per_minute nodelay;
If you’re running a reverse proxy you’ll need to ensure the real IP is being passed along, but you can also edit the above template to be more accommodating, not that you’ll need to if your real IP’s are being forwarded.
6 Likes
Srly ? Why cloudflare is not suitable for discourse ?? What should i use then ?
1 Like
Search here for “cloudflare problem”. It is quite possible to make it work, but it is not simple.
3 Likes
I use cloudflare with multiple Discourse installs, it works perfectly fine.
My setup is Cloudlare > nginx reverse proxy > LXD > Docker > Discourse
1 Like
Can you show me this domains ?
You can use Cloudflare as DNS and a cache for /uploads, but if any of their caching or “optimisation” features are touching the page then you’re completely unsupported here.
There are a long list of Cloudflare tweaks which break discourse in new and interesting ways.
Either way Cloudflare is a tangent, as indicated above the error being discussed is very likely due to nginx not receiving origin IPs. Let’s deal with the root cause rather than slap a bandage on a symptom.
6 Likes
I have no reverse proxy, in fact i use cloudflare but to manage the dns as the team here recommended to keep the cloud gray.
You need to determine what’s causing the nginx rate limit to kick in. If your Discourse is correctly configured the only reason you should see that message is if there are a large number of users sat behind a single IP. Cloudflare can’t do anything to mitigate that kind of traffic either.
Discourse isn’t a website, it loads a javascript payload into the browser, putting another hop in the network path between client and server will only slow things down.
3 Likes
From what you have said, it looks like your computer is what is making too many requests.
You should look at the logs in /var/discourse/shared/standalone/log/var-log/nginx/ to look for clues.
3 Likes
I have no idea but really big problem, this things is happening almost every 10 minutes. 
Is it happening to anyone but yout?
Developing story:
i asked a friend of i he used some kind of software to send many requests to my website, he sent like 3000 requests in 15 seconds and the problem occurred.
the thing is everybody with same software can take down our website like that.
so the idea here is how we can prevent this thing.?
That’s what is supposed to happen. If he floods the site with requests, he, and only he, gets the “Too many requests” notice so that he cannot take your site down. It is doing exactly what you want.
If you are browsing the site normally and get that 429 message you have a problem. If you are trying to crash your site and get the 429 message then you have proof that your site is protected.
5 Likes
Yes sir, i know that he did it because he is authorized, but how about somebody can do the same and flood the website all day long ? just to prevent us from reaching our website, what is the solution ? is this something related to server ability ?
we are using 8Gb server with 4CPUs !!