Opened 7 years ago

Last modified 7 years ago

#1288 new enhancement

upstream server port defaults to port 80 even for https: proxy_pass

Reported by: Neil Craig Owned by:
Priority: minor Milestone:
Component: nginx-core Version: 1.11.x
Keywords: upstream server port default Cc:
uname -a: Linux ip-10-13-133-63 3.10.0-514.21.1.el7.x86_64 #1 SMP Thu May 25 17:04:51 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.11.10 (BBC GTM)
built with OpenSSL 1.0.2k 26 Jan 2017
TLS SNI support enabled
configure arguments: --build='BBC GTM' --prefix=/etc/nginx/current --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/current/nginx.conf --pid-path=/var/run/ --error-log-path=/var/log/nginx/default-error.log --http-log-path=/var/log/nginx/default-access.log --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=gtmdaemon --group=gtmdaemon --with-http_realip_module --with-http_v2_module --with-http_ssl_module --with-http_geoip_module --with-pcre-jit --with-ipv6 --with-file-aio --with-threads --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' --add-module=/tmp/tmpDqmGeW/BUILD/nginx-1.11.10/headers-more-nginx-module --add-module=/tmp/tmpDqmGeW/BUILD/nginx-1.11.10/naxsi/naxsi_src --add-module=/tmp/tmpDqmGeW/BUILD/nginx-1.11.10/nginx-module-vts --add-module=/tmp/tmpDqmGeW/BUILD/nginx-1.11.10/nginx-upstream-dynamic-servers --with-openssl=/tmp/tmpDqmGeW/BUILD/nginx-1.11.10/openssl-1.0.2k --add-module=/tmp/tmpDqmGeW/BUILD/nginx-1.11.10/ngx_devel_kit --add-module=/tmp/tmpDqmGeW/BUILD/nginx-1.11.10/lua-nginx-module



I'm building a multi-tenant caching reverse proxy based on NGINX and i've hit an issue today.

Essentially the issue boils down to the default for the port of an upstream server being 80 even when the proxy_pass to the upstream is https. It'd seem reasonable to me to amend the default port to 80 for http proxy_pass and 443 for https proxy_pass. Users would still be free to define their own port manually. I also think that this would fit the principal of least surprise - i believe that most users would expect the upstream server to use :443 if they specify https in their proxy_pass.

The other option would be to use a variable, e.g. $server_port but NGINX doesn't seem to support variables in upstreams right now - that would be useful for other reasons too.

I'd be keen to hear any workarounds if they exist and i would love to hear your thoughts on this. Happy to explain my use case in more detail if needed, i avoided writing it down just to keep the ticket more succinct.


Change History (4)

comment:1 by Maxim Dounin, 7 years ago

You mean, when using a separate upstream block, like in the following example:

    upstream foo {

    server {
        location / {
            proxy_pass https://foo;


that is, with proxy_pass https://... referring to an explicitly defined upstream block?

Unfortunately, it is hardly possible to know in advance how a particular upstream block will be used in the configuration, and predict the default port accordingly. When nginx knows the protocol in advance, as in

    proxy_pass https://localhost;

when proxy_pass is used with an IP address or a domain name, default port is selected according to the protocol used.

A simple solution for upstream blocks would be to always use ports in the server directives. And may be simply requiring ports to be always specified may reduce confusion here.

comment:2 by Neil Craig, 7 years ago

Sorry for the delay Max, i never get emails from this tracker.

Yes, i do indeed mean as per above and i see your point.

Wouldn't it be a better default for the upstream to use 443 if the scheme is https: (and 80 if it's http:) if the port on the upstream server is not explicitly defined? I am assuming that the upstream knows the scheme with which it's called/used? (maybe i'm wrong on that). Or are you saying that's already the case? The docs say :80 will be used if no port is specified:
"...If a port is not specified, the port 80 is used..." (


comment:3 by Maxim Dounin, 7 years ago

The scheme is not know when the upstream{} block is created and its internal structures are initialized. (Moreover, the same upstream{} block can be used with multiple protocols, though this is not likely to be used in practice.)

comment:4 by Neil Craig, 7 years ago

OK, I see. So when the upstream is called, there's no parameter/arg passed which could specify the port? Seems like that would be the only way.

Note: See TracTickets for help on using tickets.