Don't use $proxy_protocol var which may be undefined. #885
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm on AWS with an nginx-ingress-controller behind an ELB (created by a kubernetes Service of type LoadBalancer). I set the following annotations:
which disable proxy protocol and enable http backend protocol, which cause the ELB to set X-Forwarded-For and X-Forwarded-Proto headers when communicating with the backend (nginx in this case).
And I have this annotation on the nginx-ingress-controller:
However, the X-Forwarded-For header is not being passed along by nginx to its upstream services. This is because when the X-Forwarded-Proto is set to "https", the nginx config on line 128 sets $pass_access_scheme to "https", which in turn results in $the_x_forwarded_for being set to $proxy_protocol_addr on line 140.
Because I'm not using proxy protocol, $proxy_protocol_addr is unset. However, when using either proxy protocol or X-Forwarded-For, $remote_addr is set correctly by the
real_ip_header
directives on lines 24 and 27.This pull request solves my problem, though I can't say it doesn't break other configurations. My goal with this PR is to document the issue.
See #800 (comment)