Nginx reload intermittenlty fails when protocol specified in proxy_pass directive is specified as HTTPS

Maxim Dounin mdounin at
Mon Nov 20 18:48:30 UTC 2017


On Mon, Nov 20, 2017 at 12:46:31PM -0500, shivramg94 wrote:

> I am trying to use nginx as a reverse proxy with upstream SSL. For this, I
> am using the below directive in the nginx configuration file 
> proxy_pass https://<upstream_block_file_name>; 
> where "<upstream_block_file_name>" is another file which has the list of
> upstream servers. 
> upstream <upstream_block_file_name> { 
> server <IP_address_of_upstream_server>:<Port> weight=1; 
> keepalive 100; 
> } 
> With this configuration if I try to reload the Nginx configuration, it fails
> intermittently with the below error message 
> nginx: [emerg] host not found in upstream \"<upstream_block_file_name>\" 
> However, if I changed the protocol mentioned in the proxy_pass directive
> from https to http, then the reload goes through. 
> Could anyone please explain what mistake I might be doing here? 

Most likely you are trying to use the same upstream block in both 
"proxy_pass http://..." and "proxy_pass https://...", and define 
upstream after it is used in proxy_pass.  That is, your 
configuration is essentially as follows:

    server { location / { proxy_pass http://u; } ... }
    server { location / { proxy_pass https://u; } ... }
    upstream u { server; }

Due to implementation details this won't properly use upstream "u" 
in both first and second servers (some additional details can be 
found at

Trivial fix is to move upstream block before the servers, that is, 
to define it before it is used.  Note though that this will result 
in an incorrect configuration, as the same server ( 
in the above example) will be used for both http and https 
connections, and this is not going to work either for http or for 
https, depending on how the backend is configured.  Instead, you 
probably want to define two distinct upstream blocks for http and 
https with different ports.

Maxim Dounin

More information about the nginx mailing list