Adding an offline page when rebuilding

(Bhanu Sharma) #61

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.


(Bhanu Sharma) #62

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!

(Diego Barreiro) #63

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;

  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:

(Felix Freiberger) #64

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?

(Diego Barreiro) #65

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

(Felix Freiberger) #66

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?

(Diego Barreiro) #67

It’s weird
Without Cloudflare it works, it shows the custom page

Probably the response code is causing the conflict?

(Felix Freiberger) #68

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 :slight_smile:

(Diego Barreiro) #69


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

(Felix Freiberger) #70

I wouldn’t call this fixed, though – you want to serve 502 here to tell browsers that this is an error condition.

(Diego Barreiro) #71

Well, if you want to display a 502 page through Cloudflare you have to pay :sweat_smile:

(CeBe) #72

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.

(Felix Freiberger) #73

Why is that? The inner Nginx should trust the forwarded source IP as per this line:

(CeBe) #74

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).

(CeBe) #75

Nginx requires the X-Real-IP header to be set for this to work properly!

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;

(Felix Freiberger) #76

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!

(CeBe) #77

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.