<div dir="ltr"><div><div><div><div>более или менее типовая ситуация заключается в том, что вы отвечаете по известному списку днс-имен.<br></div>это - недефолтные хосты.<br><br></div>в дефолтном вы делаете <br><br><br>server {<br> listen x.x.x.x:80 default accept_filter=httpready;<br> listen x.x.x.x:443 default http2 reuseport accept_filter=dataready;<br> server_name _; <br> access_log off;<br> error_log /dev/null;<br> location / {<br> return 444;<br> }<br>}<br><br><br></div>и, всякие скрипткидизы, которые тыкают в ip-адрес и ищут уязвимый софт, перестают вас беспокоить в логах.<br><br><br><br></div>или у вас список доменов заранее неизвестен ? <br><div><div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">8 апреля 2016 г., 14:41 пользователь navern <span dir="ltr"><<a href="mailto:livingdeadzerg@yandex.ru" target="_blank">livingdeadzerg@yandex.ru</a>></span> написал:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Неудобно, потому что IP адреса не все дефолтные. И необязательно он
будет всегда на этом сервере, а может мигрировать на другой.
Придется еще добавлять логику по перемещению "дефолтного" IP и это
всё действительно неудобно.<br>
<br>
Я понимаю, как работают дефолтные хосты, часть IP адресов так и
указаны. Можете просто поверить на слово, что для части IP адресов
дефолтный хост не очень работает.<br>
<br>
С точки зрения конфигурирования можно решить конечно, но это будет
не очень удобно. Именно из-за динамического выделения IP. Придется
держать дефолтный хост отдельно для каждого IP адреса и делать
проверки при каждом перемещении/удалении IP адреса с сервера.<br>
<br>
listen * не подходит, потому что не только nginx слушает 80 и 443
порт на сервере.<br>
<br>
Пока что уже полез ковыряться в исходниках, сейчас разбираюсь что и
как работает там:)<span class=""><br>
<br>
<div>On 07.04.2016 22:10, Vadim A.
Misbakh-Soloviov wrote:<br>
</div>
</span><blockquote type="cite"><span class="">
<blockquote type="cite">
<pre>Ну в нашем случае нам как раз подходит указать везде reuseport явно,
чтобы он работал всегда. Указывать только в одном месте очень неудобно
для автоматического конфигурирования.
</pre>
</blockquote>
<pre>Ну, почему же? Просто обрабатывайте "дефолтный" хост отдельно от остальных.
Сначала заполняете его (а то и вообще не трогаете один раз сконфигуряв)
нужными опциями, кладёте в /etc/nginx/vhosts.d/default/??_bla. Потом уже
кладёте "основные" в /etc/nginx/vhosts.d/client/site без указания опций в
listen.
(пути от балды)
</pre>
<blockquote type="cite">
<pre>Это не очень как раз удобно, потому что проще накатывать конфиг по
шаблону, с включенными опциями сразу(как в случае с ssl/http2), чем
перед этим парсить все конфиги и проверять есть ли уже такой IP адрес и
есть ли там опции(тоже вариант решения проблемы, но мне он нравится пока
меньше).
</pre>
</blockquote>
<pre>1) http2, вроде как, всё равно будет работать для всех. Ну и лично я его тоже
только в дефолтном держу.
2) зачем проверять? Просто явно генерите дефолтный конфиг. И достаточно будет
проверять лишь его наличие.
3) а чем, кстати, вам не подходит listen * и [::]?
</pre>
<br>
<fieldset></fieldset>
<br>
</span><pre>_______________________________________________
nginx-ru mailing list
<a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></pre>
</blockquote>
<br>
</div>
<br>_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a><br></blockquote></div><br></div>