You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Affected Puppet, Ruby, OS and module versions/distributions
Puppet: 7.8
Distribution: Debian
Module version: 3.3.0
Nginx 1.18 and 1.22
How to reproduce (e.g Puppet code you use)
What are you seeing
The default setting for $proxy_set_header is causing 503s in combination with a proxy_pass directive.
Specifically the generated config line proxy_set_header Host $host; inside nginx.conf is causing this problem.
The same line with a static value instead of a variable is not causing the issue and I also believe that the same configuration used to work on an nginx 1.14.
The upstream in this case has not changed, only the client has changed (upgrade from nginx 1.14 to 1.22).
Any additional information you'd like to impart
This might not strictly be a puppet module issue, but the fact that is sets this directive by default (whereas a standard nginx installation does not) means that we should be aware of the problem.
I have mitigated the problem by redefining the proxy_set_header parameter removing the Host header.
Affected Puppet, Ruby, OS and module versions/distributions
How to reproduce (e.g Puppet code you use)
What are you seeing
The default setting for
$proxy_set_header
is causing 503s in combination with aproxy_pass
directive.Specifically the generated config line
proxy_set_header Host $host;
insidenginx.conf
is causing this problem.The same line with a static value instead of a variable is not causing the issue and I also believe that the same configuration used to work on an nginx 1.14.
The upstream in this case has not changed, only the client has changed (upgrade from nginx 1.14 to 1.22).
Any additional information you'd like to impart
This might not strictly be a puppet module issue, but the fact that is sets this directive by default (whereas a standard nginx installation does not) means that we should be aware of the problem.
I have mitigated the problem by redefining the
proxy_set_header
parameter removing theHost
header.The following serverfault thread might be related: https://serverfault.com/questions/1069729/nginx-reverse-proxy-proxy-pass-leads-to-503-service-unavailable
The text was updated successfully, but these errors were encountered: