Proxy Protocol Port not used to determine Access Scheme about router HOT 7 OPEN

For those not familiar with PROXY protocol, the header includes the clients IP address, the clients source port and the clients destination port, which would be the port on the load balancer terminating SSL.

from router.

I think the following would work (untested):

{{ if $routerConfig.UseProxyProtocol -}}
map $proxy_protocol_port $proxy_protocol_scheme {
  default $scheme;
  "80" "http";
  "443" "https";
}
{{- end }}

map $http_x_forwarded_proto $tmp_access_scheme {
  {{ if $routerConfig.UseProxyProtocol -}}
  default $proxy_protocol_scheme;# if X-Forwarded-Proto header is empty, $tmp_access_scheme will be the proxy protocol used
  {{- else -}}
  default $scheme;               # if X-Forwarded-Proto header is empty, $tmp_access_scheme will be the actual protocol used
  {{- end }}
  "~^(.*, ?)?http$" "http";      # account for the possibility of a comma-delimited X-Forwarded-Proto header value
  "~^(.*, ?)?https$" "https";    # account for the possibility of a comma-delimited X-Forwarded-Proto header value
  "~^(.*, ?)?ws$" "ws";      # account for the possibility of a comma-delimited X-Forwarded-Proto header value
  "~^(.*, ?)?wss$" "wss";    # account for the possibility of a comma-delimited X-Forwarded-Proto header value
}

from router.

Before I go too deep into this issue... if you're terminating SSL at the load balancer, your load balancer already speaks HTTP/S. An option, therefore, would be to configure it to set the X-Forwarded-For HTTP header instead... if on AWS or GKE, this is actually automatic. Just disable PROXY proto on the router end and you're back in business with real client IPs.

from router.

No, if you're terminating SSL at the load balancer it still speaks TCP. If you are terminating HTTPS it speaks HTTP, but than for example on ELB WebSockets won't work.

from router.

Btw. I know that terminating SSL at the ELB has drawbacks like loosing support for HTTP/2 (because the ELB does not negotiate HTTP/2 over ALPN), but many people like to use it to be able to use Amazon Certificate Manager.

from router.

I stumbled upon this issue when googling a solution to the very same problem you're having.

After having implemented it, I realized that $proxy_protocol_port is actually the client's port, and not the destination port. The destination port is not available as a variables.

https://trac.nginx.org/nginx/ticket/1206 is a feature request to expose the destination port.

from router.

This issue was moved to teamhephy/router#12

from router.