proxy_protocol_port variable should store the PROXY_PORT rather than CLIENT_PORT

Janusz M janusz.m at
Mon May 15 14:00:07 UTC 2017

Hi Maxim,

First of all thanks for your quick reply. I read the nginx 1.11.0 and
1.11.4 release notes, thanks. Perhaps I wasn't as clear in my description
as possible.

Please consider the following scenario:

* a client (user) with IP makes an HTTPS request to the app
and hits the load balancer
* load balancer forwards both HTTP and HTTPS requests to nginx server on
port 80 (standard Amazon AWS setup)
* Proxy Protocol is turned on, load balancer adds the following line to the

  PROXY TCP4 56324 443

* nginx with proxy_protocol on reads port 56324 to $proxy_protocol_port.

The point is that with the current implementation, either nginx's behaviour
or proxy protocol itself feels inconsistent.
You wrote:
"The $proxy_protocol_port, much like $proxy_protocol_addr, reflects client
port for the proxy protocol header. "
but in fact, what we see in those variables is the client IP (public IP of
the client's computer) and the load balancer port (not the client port).

What I meant by "relatively useless" is that I'd expect that in most cases
people/apps care about the last value in the proxy protocol line, that is
443 in the above example.

The code in src/core/ngx_proxy_protocol.c reads the first IP in that line
and then skips to the first port number found. Don't you think that to read
the 'client port' nginx should read the last port number in the line?

PS. I actually resolved my current issue by forwarding connections to
different ports within nginx.

2017-05-15 15:17 GMT+02:00 Maxim Dounin <mdounin at>:

> Hello!
> On Sat, May 13, 2017 at 09:11:13PM +0200, Janusz M wrote:
> > I'd expect to see the original request's port 80 or 443 in this variable
> > rather than relatively useless (IMHO) CLIENT_PORT which looks like 51501.
> The $proxy_protocol_port, much like $proxy_protocol_addr, reflects
> client port for the proxy protocol header.  It is to be used
> (again, much like $proxy_protocol_addr) to log original client's port,
> which is needed to trace a particular client.  It also can be used in
> X-Real-IP / X-Forwarded-For to pass the port to upstream servers.
> Quoting nginx 1.11.0 changes:
>     *) Feature: the $proxy_protocol_port variable.
>     *) Feature: the $realip_remote_port variable in the
>        ngx_http_realip_module.
>     *) Feature: the ngx_http_realip_module is now able to set the client
>        port in addition to the address.
> Hope this help to understand how it is expected to be used.
> > A typical use case for this change would look like the following:
> >
> > 1. nginx HTTP server is running behind Amazon Load Balancer in TCP mode
> > with PROXY PROTOCOL enabled (can be any TCP load balancer with proxy
> > protocol on, useful for websockets for example)
> > 2. nginx has the proxy_protocol turned on
> > 3. we (or other apps, upstream servers) want to know what was the
> > port/protocol of the incoming request (eg. was it 80/HTTP or 443/HTTPS).
> >
> > Currently it seems that it's impossible to get the request port/protocol
> > value from nginx behind tcp load balancer. If nginx stored the PROXY_PORT
> > instead of the CLIENT_PORT value in that (or another) variable it would
> be
> > extremely easy for other apps to know the original port/protocol.
> >
> > >>>
> > server {
> >   listen 80 proxy_protocol;
> >   ...
> >   proxy_set_header X-Forwarded-Port  $proxy_protocol_port; # 51505
> instead
> > of 443/80 !!
> > }
> This is a completely different use case.  Moreover, this use case
> can be easily avoided by forwarding connections to different
> ports within nginx.  And so, quoting your own words, "relatively
> useless".
> > Please let me know if it's feasible or planned, or if we could actually
> > read the original incoming request port in a different way
> No, there are no plans to change current behaviour.
> --
> Maxim Dounin
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the nginx-devel mailing list