That’s exactly the way I got it to work, this is why I had that one question so I asked. that setup is really a life saver in terms of crowd retention.
Thanks
That’s exactly the way I got it to work, this is why I had that one question so I asked. that setup is really a life saver in terms of crowd retention.
Thanks
Also, this tutorial comes in handy if one doesn’t want to use the webroot module!
Slight configuration change is required to the default vhost then this will work just fine!
This is still showing me the 502 error page from Cloudflare:
My NGINX config file:
server {
listen 80; listen [::]:80; listen 443 ssl http2; listen [::]:443 ssl http2;
server_name community.makeroid.io;
client_max_body_size 0;
location / {
error_page 502 =502 /errorpages/discourse_offline.html;
proxy_intercept_errors on;
proxy_pass http://unix:/var/discourse/shared/standalone/nginx.http.sock:;
proxy_set_header Host $http_host;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}
location /errorpages/ {
alias /var/www/errorpages/;
}
}
However this works:
https://community.makeroid.io/errorpages/discourse_offline.html
Are you sure that you followed the steps exactly? Can you post your app.yml
file (with sensitive information redacted)? Did you rebuild after changing app.yml
?
Yes, as I weren’t using let’sencrypt for SSL those lines where already commented, and then I commented too the ports expose
And yes, I rebuilt after so
Hm, in that case, I don’t see an obvious problem, and you’ll need to debug. What happens when you try this without Cloudflare?
It’s weird
Without Cloudflare it works, it shows the custom page
Probably the response code is causing the conflict?
Maybe, I have no idea how Cloudflare handles that, exactly. Maybe someone else can help, or you can find an option for that in Cloudflare’s configuration? If that doesn’t work out, you could try contacting Cloudflare support
Fixed
Just changed the =502 to =200
I supposed that as Cloudflare detected 502 response code they were showing their page
I changed the response code to 200 and now it works
I wouldn’t call this fixed, though – you want to serve 502
here to tell browsers that this is an error condition.
It should be noted that running an nginx proxy in front of Discourse as described here will result in the rate limit, which is by default configured in Discourse Docker to apply for requests for all users.
The rate limit template templates/web.ratelimited.template.yml should be removed from the docker config and the rate limit should then be configured in the outer nginx instance instead.
Why is that? The inner Nginx should trust the forwarded source IP as per this line:
The rate limit uses $binary_remote_addr
, which seems to be not overwritten by set_real_ip_from
.
I also see that $remote_addr
is shown as ´unix:` in the discourse nxing access.log.
IP adresses inside discourse itself seem to work (looking at IPs for user login).
Nginx requires the X-Real-IP
header to be set for this to work properly!
https://nginx.org/en/docs/http/ngx_http_realip_module.html#real_ip_header
Default: real_ip_header X-Real-IP;
So the following header needs to be added to the proxy (this is missing in your config above):
proxy_set_header X-Real-IP $remote_addr;
How certain are you that X-Forwarded-For
is ignored by default? This guide isn’t particularly new, this one only sets X-Forwarded-For
in the HTTP-only case, and I haven’t seen any complaints about rate limits hitting. Also, I’m operating a Discourse site behind such a Nginx proxy, and Discourse does see the real IP address.
If you’re certain, feel free to add the line above – it’s a wiki!
Nginx access logs show unix:
as the client when I do not add the header. I get the correct IP when I add it. This also complies to what the nginx docs say so I am very certain this is how it works.
Discourse itself seems to evaluate the X-Forwarded-For
header so the problem here only affects IP handling on the nginx which sits in the Discourse Docker container.
I updated the wiki post.
From what happened in my case i believe @cebe is right and you need X-Real-IP
specifically for inner nginx.
See Discourse socketed: Nginx in front of discourse: no IP adresses for reference.
Is this possible today? Right now our site goes down when doing an upgrade.
Yes, I use it without any issue.