Opened 2 years ago

Closed 8 months ago

#1410 closed enhancement (wontfix)

default_server with no IP specified for multiple IP servers

Reported by: gmchain@… Owned by:
Priority: minor Milestone:
Component: nginx-core Version: 1.10.x
Keywords: default_server, multiple IP Cc:
uname -a: Linux advweb 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2 (2017-04-30) x86_64 GNU/Linux
nginx -V: built with OpenSSL 1.0.1t 3 May 2016 TLS SNI support enabled configure arguments: --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,-z,now' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-file-aio --with-threads --with-http_addition_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_secure_link_module --with-http_sub_module --with-http_xslt_module=dynamic --with-stream=dynamic --with-stream_ssl_module --with-mail=dynamic --with-mail_ssl_module --add-dynamic-module=/usr/src/builddir/debian/modules/nginx-auth-pam --add-module=/usr/src/builddir/debian/modules/nginx-dav-ext-module --add-module=/usr/src/builddir/debian/modules/nginx-echo --add-module=/usr/src/builddir/debian/modules/nginx-upstream-fair --add-module=/usr/src/builddir/debian/modules/ngx_http_substitutions_filter_module --add-module=/usr/src/builddir/debian/modules/nginx-cache-purge --add-module=/usr/src/builddir/debian/modules/nginx-x-rid-header --with-ld-opt=-lossp-uuid

Description

I've encountered a problem whilst configuring a system with multiple IP addresses: default_server directive should be specified for every IP-address used for web connections, no matter if there should be only one default server in the configuration. So, in case of adding a new IP I should alter the configuration to add that IP.

I think it should be more transparent if nginx would look for default servers for IP:port pair first, after that for other suitable default servers and only after that use a first server in list of configured servers.

Change History (9)

comment:1 Changed 2 years ago by vbart

Could you explain which of servers should be a default for *:80 in the case below?

server {
    listen *.8000 default_server;
    listen *.8001;
    listen *.80;

    ...
}
server {
    listen *.8001 default_server;
    listen *.80;
    listen *.8000;

    ...
}
Last edited 2 years ago by vbart (previous) (diff)

comment:2 Changed 2 years ago by gmchain@…

None, in this case responding server should be taken from the servers list, because both default servers aren't configured to be a default server for 80 port.

comment:3 Changed 2 years ago by vbart

Sorry, but I don't understand the idea how it should work... what did you mean by "other suitable default servers"? Could you provide some examples?

comment:4 Changed 2 years ago by gmchain@…

Sure thing, here it is:

server {
    listen 100.50.0.100:80;
}
server {
    listen 100.50.0.200:80;
}
server {
    listen *:80 default_server;
}

Current version of nginx will use the first server as a default one for requests to 100.50.0.100:80 and will use the second server as default for requests to 100.50.0.200.

My idea is to use the third server as default for both IPs.

Another example:

server {
    location 100.50.0.100:80 default_server;
}
server {
    location 100.50.0.200:80;
}
server {
    location *:80 default_server;
}

In this case, default server for IP 100.50.0.100 should be the first one in the configuration, just like how it works already. But, for IP 100.50.0.200, the third server, not the second one, should be default.

comment:5 Changed 2 years ago by vbart

It's not only about the default server. Currently, the clients connected to 100.50.0.200:80 can't access virtual servers with listen *:80 at all. Each listen directive with unique addr:port value creates completely separate space of virtual servers.

This change will not only break a lot of setups, but can silently introduce security holes.

comment:6 follow-up: Changed 2 years ago by vbart

Moreover, while this change will simplify your specific use-case, it will put in trouble all users, who wants the opposite behaviour, that is to separate their ip:port servers from *:port configuration.

comment:7 in reply to: ↑ 6 Changed 2 years ago by gmchain@…

Replying to vbart:

Moreover, while this change will simplify your specific use-case, it will put in trouble all users, who wants the opposite behaviour, that is to separate their ip:port servers from *:port configuration.

This can be fixed with a directive, specifying what nginx behavior should be used, an old or a new one.

comment:8 Changed 8 months ago by grandpajam@…

A directive would be very nice to have. Currently, the only way I see to set a default server for all interfaces is by including a listen directive for *every* IP address on the system in the default server config, which can be hard to maintain, especially if addresses are dynamic for any reason (DHCP, IPv6 SLAAC, link local, or other reasons).

comment:9 Changed 8 months ago by mdounin

  • Resolution set to wontfix
  • Status changed from new to closed

There are no reasons to list all IP addresses in the configuration, it is enough to use

listen 80;
listen 443 ssl;
listen [::]:80;
listen [::]:443 ssl;

to handle all IPv4 and IPv6 connections on ports 80 and 443. Unless you want to use specific per-IP processing. And if you in fact need specific per-IP processing, I would expect this change to be a problem, not a simplification, as already pointed out by Valentin in comment:6.

Note: See TracTickets for help on using tickets.