I’m running Ubuntu 14.04, do you think that Nginx we installed here is supporting http2 ?
Could be this change a help to show the offline page while rebuilding?
PS: Sorry I hadn’t a chance too look at the logs at /var/log/nginx/ as you’d asked. As you may saw I’m facing some other serious problems 
soon I look at it and will come back to you.
I’m not sure – and I don’t think I have a 14.04 instance lying around to test. But you can easily try it: Add http2 to the listen block, und service reload nginx. If it errors out, it isn’t supported 
You were right. I had one mistakes in Nginx config. I just fixed it and now the offline page working like charm. Thank you a lot 
For Info: I just had a chance to try it with my 14.04 Ubuntu. It’s not supported. Nginx failed to reload.
Hmm, wait, @sam complained this turns off http2. But, I upgraded to Ubuntu 16.04 and then changed this line:
listen 443 ssl; listen [::]:443 ssl;
to
listen 443 ssl http2; listen [::]:443 ssl http2;
And it seems to pass http/2 through fine now?
Yeah, on 16.04 nginx can do http2.
I’ve slightly worded down the warning in the initial post to reflect this. Thanks for confirming, @codinghorror and @Falco!
6 posts were split to a new topic: Let’s Encrypt won’t renew with offline page
Can you clarify the purpose of adding this header here? It seems it has conflict with embedding comments.
No sense at all, at least now, since Discourse returns its own header. I’ll remove it from the howto. Thanks for reporting this!
Hi, with the recent version of discourse is this still needed?
Any downside/disadvantage of using this approach?
Why not modify directly the Nginx built in/default with discourse/docker to specify error pages?
Because the container needs to running in order to serve pages, and the point of this configuration is to serve an error page when the Discourse app container isn’t running.
When you define the ssl_ciphers in nginx like what is proposed here, then your instance doesn’t support TLSv1 and TLSv1.1 anymore. Or at least not in my situation.
True that, so you could simplify the configuration by removing the outdated protocols. I’ll do that, thanks!
I had a Question!!
will using https:// instead of http:// in the above url break or else create any complication into the setup?
Why would you want to do that? This traffic never touches the network, there is no reason for HTTPS here.
In this setup, HTTPS is provided entirely by the outer Nginx instance 
I asked that because in such a case with wordpress, using a https proxy for a http site will mess up a lot of thing even if one has got site working on both if the url is left http then there are a lot of content warnings at times so I was just curious to know.
anyway thanks for clarification.
This is taken care of by the headers set by Nginx, especially X-Forwarded-Proto: It tells Discourse that the user-facing protocol is HTTPS
So necessarily it won’t matter if http or https is used in this configuration? right?
Ps: sorry for a noob question, I don’t really know much about http headers
If you follow the instructions in the original post, this should work out 