# конспект · шаг 1 из 1
Конспект раздела: кто отвечает
Раздел про решение №1 из шести: какой server-блок берёт запрос.
Алгоритм выбора
1. по listen: адрес + порт (IPv4 и IPv6 - РАЗНЫЕ сокеты)
2. более точный адрес побеждает: 127.0.0.1:80 сильнее, чем 80
3. среди подошедших - по Host:
точное имя → *.имя → имя.* → регулярка
4. ничего не совпало → блок с default_server на ЭТОМ адресе и порту
5. default_server нет → ПЕРВЫЙ блок на нём же
Шаги 4 и 5 свои у каждой пары «адрес и порт», а не у сервера целиком.
Что чаще всего идёт не так
| Симптом | Причина |
|---|---|
| открывается не тот сайт | нет default_server, отвечает первый блок |
| сайт не виден по IPv6 | нет listen [::]:80 |
| регулярное имя не срабатывает | его перебивает маска - регулярка последняя |
shop.local не попадает в *.shop.local |
звёздочка не заменяет пустоту |
| чужой домен показывает твой сертификат | нет заглушки на 443 или в ней лежит настоящий сертификат вместо ssl_reject_handshake on |
| ошибка TLS на 443 | listen 443; без флага ssl |
| заглушка стоит, а чужое имя всё равно отвечает | у блока с более точным listen своя четвёртая ступень |
Минимальная заглушка, которая должна быть на каждом сервере
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
return 444;
}
Для 443 - то же самое плюс ssl_reject_handshake on; (nginx 1.19.4): с ней
сертификат заглушке не нужен, и чужой домен не увидит имя твоего сайта.
Свежее
С nginx 1.25 HTTP/2 включают директивой http2 on;, а не флагом в listen:
старая форма включала протокол на весь сокет, новая - только на свой блок.
Чек-лист: что ты должен уметь объяснить
- Почему
listen 80;не делает сайт доступным по IPv6. - Полный порядок приоритетов
server_nameи место регулярки в нём. - Что произойдёт с запросом, у которого чужой
Host, если заглушки нет. - Зачем catch-all нужен именно на HTTPS и что там с сертификатом.
- Чем
return 444отличается отreturn 404.
Комментарии
Пока нет комментариев. Будь первым!
Оставить комментарий