Add an offline page to display when Discourse is rebuilding or starting up

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

1 Like

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

3 Likes

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?

2 Likes

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

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

4 Likes

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

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

4 Likes

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.

2 Likes

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

1 Like

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;
4 Likes

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!

2 Likes

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.

8 Likes

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.

4 Likes

Is this possible today? Right now our site goes down when doing an upgrade.

Yes, I use it without any issue.

4 Likes