NGINX / МАРШРУТ ЗАПРОСА
Путь запроса
не угадывают.
Его трассируют. От listen до приложения, через каждый выбор server и location.
api.demo.testURI: /private/export.php маршрут найденСначала механизм
NGINX не просто
«отдаёт сайт».
Он принимает соединения, выбирает виртуальный сервер, сопоставляет URI и решает, отдать файл, передать запрос upstream или завершить его.
Официальный Beginner’s Guideи процессычитает конфиг, запускает workers
Событийная модель позволяет worker-процессу обслуживать множество соединений. Детали зависят от платформы и сборки. [1]
Файлы, TLS и ответы на HTTP-запросы.
Передача запроса приложению или группе upstream-серверов.
Решение зависит от сокета, имени сервера, URI и контекста директив.
Интерактивная трасса / модель
Запусти запрос.
Посмотри, кто победил.
Меняй сценарий, Host и URI. Линия показывает путь, а результат объясняет выбранное правило.
Это ограниченные учебные примеры, а не полноценный парсер nginx.conf. Перед исправлением сверяйся с документацией и тестируй конфигурацию.
Выбери точку сбоя
- listenадрес и порт
- serverвиртуальный хост
- locationвыбранный URI
- handlerфайл или proxy
- appпроверка прав
location /private/совпал, но уступилdeny alllocation ~ \\.php$выбранный блокapp:9000Обычный prefix совпал, но регулярное выражение для .php тоже совпадает. Без ^~ NGINX проверяет regex после выбора самого длинного prefix. В этой конфигурации regex location может стать победителем, поэтому deny all из prefix-блока не применяется.
Если весь /private/ должен оставаться закрытым, сделайте prefix ^~ и проверьте точный набор правил: location ^~ /private/ { deny all; }
Где ломается маршрут
Мисконфиг
виден по эффекту.
Ищи не «плохую директиву» отдельно, а расхождение между ожидаемым и фактическим маршрутом.
Настройка NGINX на edge не заменяет авторизацию и проверку прав в приложении. OWASP: Authorization Cheat Sheet ↗
Порядок проверки
Сначала конфиг.
Потом запрос.
Собери ожидаемый результат для Host и URI, затем проверь его на том же маршруте, который видит пользователь.
- 01
Проверь синтаксис
nginx -tЭто ловит ошибки конфигурации, но не доказывает, что правила безопасны.
- 02
Посмотри активную конфигурацию
nginx -TПеред публикацией вывода удали секреты, внутренние адреса и приватные имена.
- 03
Проверь выбор server и location
Host + URI → ожидаемый блокТестируй известный, неизвестный и граничный Host; exact, prefix и regex пути.
- 04
Проверь приложение напрямую и через proxy
edge → upstream → appАвторизация и права должны проверяться в приложении, а не только по URL в NGINX.
Осторожно с nginx -T. Полный вывод может содержать внутренние адреса и секреты. Редактируй его перед тем, как отправлять кому-либо.
ДАЛЬШЕ / В РАБОТУ
Унеси маршрут
на стенд.
Короткий конспект и редактируемая презентация с конфигурационными примерами.
Сверяйся с первоисточником
Документы,
не догадки.
Описание поведения директив и правил маршрутизации сверено с документацией NGINX и OWASP.