🐧 Linux · 20 вопросов · ~45 мин · ⏱ Таймер 45:00 · Сложный · 👥 4 прошли

Nginx и публикация сайта

Nginx выбирает server и location до чтения файла или обращения к upstream. Поэтому одинаковый код 404 или 502 может возникнуть из разных механизмов. Тест требует читать конфигурацию, заголовки и журналы, различать root и alias и безопасно применять TLS и reverse proxy.

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выбери один ответ из четырёх. На 20 вопросов отведено 45 минут. Не меньше половины заданий требуют разобрать команды, сценарий Bash, конфигурацию или диагностический вывод. После завершения откроются общий процент, четыре тематические шкалы, правильные ответы и краткий разбор каждого решения.

Вопрос 1 из 20

На одном listen 80 несколько server-блоков, но Host не совпал ни с одним server_name. Какой блок выберет Nginx?

server { listen 80 default_server; return 444; }
server { listen 80; server_name app.example; root /srv/app; }

Последний блок по алфавиту server_name Nginx выберет server-блок с пустым server_name default_server, иначе первый блок этого listen Блок с самым длинным root

Вопрос 2 из 20

Как проверить конкретный server_name без изменения DNS?

curl -v -H 'Host: app.example' http://127.0.0.1/

openssl s_client -connect 127.0.0.1:80 -servername app.example nginx -T app.example и считать это HTTP-запросом curl -H "Host: app.example" http://127.0.0.1/ curl http://127.0.0.1/app.example без заголовка Host

Вопрос 3 из 20

Что делает listen 443 ssl;

Создаёт перенаправление с HTTP-порта 80 на HTTPS без отдельной директивы Создаёт TLS-listener на TCP-порту 443 с настройками текущего server-блока Создаёт listener HTTP/3 на UDP-порту 443 без дополнительных модулей Включает TLS и автоматически выбирает любой сертификат из системного хранилища

Вопрос 4 из 20

Какой редирект сохраняет путь и параметры запроса при переходе на HTTPS?

server {
  listen 80;
  server_name app.example;
  return 301 https://$host$request_uri;
}

return 301 https://$host$request_uri; rewrite / https:// permanent без URI return 301 https://$host; proxy_pass https://$request_uri;

Вопрос 5 из 20

Почему wildcard server_name *.example.com не совпадает с самим example.com?

example.com считается портом Корневое имя не имеет дополнительной метки слева Wildcard работает только для IP Nginx запрещает больше одного server_name

Вопрос 6 из 20

Nginx настроен отправлять запросы на 127.0.0.1:8000 и получает connection refused. Что это чаще означает?

sudo ss -lntp 'sport = :8000'
curl -v http://127.0.0.1:8000/health

Nginx не смог разрешить имя upstream и не пытался соединяться Upstream принял соединение, но вернул HTTP 500 На 127.0.0.1:8000 в момент запроса никто не принимал TCP-соединение Upstream ответил медленнее proxy_read_timeout

Вопрос 7 из 20

Чем обычно отличаются 502 и 504 при reverse proxy?

504 возвращает только upstream, а Nginx формирует исключительно 502 Оба кода означают одинаковый этап отказа и отличаются лишь текстом страницы 502 чаще связан с ошибкой соединения или ответа upstream, 504 — с истечением ожидания 502 означает корректный ответ upstream с ошибкой приложения, 504 — закрытый порт

Вопрос 8 из 20

Что делает proxy_set_header Host $host?

location / {
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_pass http://app_backend;
}

Передаёт upstream исходный заголовок Host без нормализации и подстановки Устанавливает исходный IP клиента в заголовок Host Передаёт upstream значение переменной $host в заголовке Host Заменяет server_name текущего server-блока во время reload

Вопрос 9 из 20

Почему нельзя безусловно передавать upstream внешний $http_x_forwarded_for как истинный адрес клиента?

Nginx заменяет внешний заголовок на $remote_addr без настройки real_ip X-Forwarded-For содержит только порт Клиент может подделать внешний X-Forwarded-For HTTP запрещает запятые в заголовке

Вопрос 10 из 20

В location /api/ указано proxy_pass http://backend/;. Как изменится URI /api/users?

location /api/ {
  proxy_pass http://backend/;
}

Upstream получит только /api URI станет //api/users Upstream получит исходный путь /api/users без замены префикса Upstream получит /users

Вопрос 11 из 20

В location /assets/ задан root /srv/site;. Какой путь соответствует URI /assets/app.css?

location /assets/ { root /srv/site; }

/srv/site/assets/assets/app.css /srv/site/app.css /assets/srv/site/app.css /srv/site/assets/app.css

Вопрос 12 из 20

В location /media/ задан alias /srv/uploads/;. Какой путь соответствует /media/a.jpg?

/media/srv/uploads/a.jpg /srv/uploads/media/a.jpg /srv/uploads/a.jpg /srv/uploads//media/a.jpg

Вопрос 13 из 20

Файл имеет 0644, но Nginx получает Permission denied. Что ещё проверить?

namei -l /srv/site/assets/app.css
ps -o user= -C nginx

Проверить client_max_body_size, хотя запрашивается статический файл Проверить тайм-аут upstream, хотя запрос не передаётся приложению Проверить права прохода по каталогам и запрет SELinux или AppArmor Проверить только право чтения самого файла, не разбирая путь

Вопрос 14 из 20

Зачем серверу отправлять fullchain, а не только leaf-сертификат?

Клиенту нужны промежуточные сертификаты для построения цепочки до доверенного корня Fullchain включает приватный ключ, необходимый браузеру для проверки подписи Leaf-сертификат можно использовать только для незашифрованного HTTP Промежуточные сертификаты нужны серверу лишь при выпуске нового leaf-сертификата

Вопрос 15 из 20

Какие права разумны для приватного TLS-ключа?

stat -c '%U %G %a %n' /etc/ssl/private/app.key

0644, потому что публичный сертификат и приватный ключ имеют одинаковые требования 0777, чтобы master и worker могли перечитывать ключ независимо от пользователя Чтение только root либо выделенной группе процесса, без доступа остальных пользователей Любой режим допустим, если файл находится в каталоге /etc/ssl/private

Вопрос 16 из 20

Что нужно сделать перед nginx -s reload или systemctl reload nginx?

sudo nginx -t && sudo systemctl reload nginx

Очистить кэш DNS клиентов, чтобы они увидели новый server-блок Остановить все worker-процессы и лишь затем проверять конфигурацию Сначала удалить старый журнал ошибок, чтобы проверка не смешалась с прошлыми сообщениями Запустить nginx -t для той конфигурации и окружения, которые будут перечитаны

Вопрос 17 из 20

Почему graceful reload обычно предпочтительнее stop/start?

Reload оставляет старые worker принимать новые запросы до следующей перезагрузки Reload заменяет ядро процесса без создания новых worker Stop/start недоступен для Nginx, запущенного через systemd Новые worker принимают соединения, а старые завершают уже начатые запросы

Вопрос 18 из 20

Nginx не стартует: bind() to 0.0.0.0:80 failed (98: Address already in use). Что проверить?

sudo ss -lntp 'sport = :80'
sudo lsof -nP -iTCP:80 -sTCP:LISTEN

Какой процесс или сокет уже занимает TCP-порт 80 Не хватает права чтения корневого каталога сайта На порту 443 уже слушает другой TLS-сервис В DNS отсутствует A-запись для одного из server_name

Вопрос 19 из 20

Какой журнал полезнее всего при различении времени Nginx и upstream?

log_format upstream '$request_id $status $request_time '
                    '$upstream_addr $upstream_status $upstream_response_time';

Обычный combined без времён upstream и общего времени запроса Журнал приложения без идентификатора запроса и времени Nginx Access log с $request_time и полями $upstream_* Только error_log уровня notice без данных о времени ответа

Вопрос 20 из 20

После reload сайт отвечает старой конфигурацией. Какой факт проверить?

sudo nginx -T 2>&1 | less
journalctl -u nginx --since '5 minutes ago'

Проверить результат reload, PID master-процесса и фактическую конфигурацию nginx -T Удалить старый файл конфигурации и выполнить ещё один reload Сравнить число worker-процессов с числом процессорных ядер Проверить браузерный кэш, не выясняя, какой конфигурацией отвечает сервер

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу