На одном из серверов около 11 тысяч виртуальных хостов в nginx'е. Бывает
и больше:) Серверов тоже далеко не десять.

Неизвестен заранее ни список IP адресов, ни список имен.

Вариант с созданием для каждого IP адреса конфига в виде: <ip_addr>.conf
и внутри дефолтным сервером конечно решает задачу, но для динамически
выделяемых IP адресов не совсем подходит. Поэтому пока буду пытаться
решать иначе.

On 08.04.2016 14:25, Илья Шипицин wrote:
> более или менее типовая ситуация заключается в том, что вы отвечаете
> по известному списку днс-имен.
> это - недефолтные хосты.
>
> в дефолтном вы делаете
>
>
> server {
> listen x.x.x.x:80 default accept_filter=httpready;
> listen x.x.x.x:443 default http2 reuseport accept_filter=dataready;
> server_name _;
> access_log off;
> error_log /dev/null;
> location / {
> return 444;
> }
> }
>
>
> и, всякие скрипткидизы, которые тыкают в ip-адрес и ищут уязвимый
> софт, перестают вас беспокоить в логах.
>
>
>
> или у вас список доменов заранее неизвестен ?
>
>
> 8 апреля 2016 г., 14:41 пользователь navern <livingdeadzerg@yandex.ru
> <mailto:livingdeadzerg@yandex.ru>> написал:
>
> Неудобно, потому что IP адреса не все дефолтные. И необязательно
> он будет всегда на этом сервере, а может мигрировать на другой.
> Придется еще добавлять логику по перемещению "дефолтного" IP и это
> всё действительно неудобно.
>
> Я понимаю, как работают дефолтные хосты, часть IP адресов так и
> указаны. Можете просто поверить на слово, что для части IP адресов
> дефолтный хост не очень работает.
>
> С точки зрения конфигурирования можно решить конечно, но это будет
> не очень удобно. Именно из-за динамического выделения IP. Придется
> держать дефолтный хост отдельно для каждого IP адреса и делать
> проверки при каждом перемещении/удалении IP адреса с сервера.
>
> listen * не подходит, потому что не только nginx слушает 80 и 443
> порт на сервере.
>
> Пока что уже полез ковыряться в исходниках, сейчас разбираюсь что
> и как работает там:)
>
> On 07.04.2016 22:10, Vadim A. Misbakh-Soloviov wrote:
>>> Ну в нашем случае нам как раз подходит указать везде reuseport явно,
>>> чтобы он работал всегда. Указывать только в одном месте очень неудобно
>>> для автоматического конфигурирования.
>> Ну, почему же? Просто обрабатывайте "дефолтный" хост отдельно от остальных.
>> Сначала заполняете его (а то и вообще не трогаете один раз сконфигуряв)
>> нужными опциями, кладёте в /etc/nginx/vhosts.d/default/??_bla. Потом уже
>> кладёте "основные" в /etc/nginx/vhosts.d/client/site без указания опций в
>> listen.
>> (пути от балды)
>>
>>> Это не очень как раз удобно, потому что проще накатывать конфиг по
>>> шаблону, с включенными опциями сразу(как в случае с ssl/http2), чем
>>> перед этим парсить все конфиги и проверять есть ли уже такой IP адрес и
>>> есть ли там опции(тоже вариант решения проблемы, но мне он нравится пока
>>> меньше).
>> 1) http2, вроде как, всё равно будет работать для всех. Ну и лично я его тоже
>> только в дефолтном держу.
>> 2) зачем проверять? Просто явно генерите дефолтный конфиг. И достаточно будет
>> проверять лишь его наличие.
>> 3) а чем, кстати, вам не подходит listen * и [::]?
>>
>>
>>
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru