Сначала определяется виртуальный сервер
Один экземпляр Nginx способен обслуживать несколько виртуальных серверов. При выборе учитываются адрес и порт, на которые поступил запрос, а затем соответствие имени хоста настройкам подходящих блоков. Если нужное имя не найдено, запрос может попасть в сервер по умолчанию для соответствующего адреса и порта. Поэтому существование блока с правильным именем само по себе не гарантирует, что используется именно он. При диагностике важно знать, какой запрос действительно отправлен и куда он пришёл. Иначе проверяется один сценарий, а ошибка возникает в другом.
Правило пути определяет следующий этап
После выбора сервера Nginx сопоставляет путь запроса с правилами location. Дальше он может выдать статический файл или передать запрос другому сервису как обратный прокси. Эти варианты требуют разных проверок. Для файла важны путь и доступность ресурса, для проксирования дополнительно работа принимающего приложения и соответствие маршрута. Нельзя считать каждую ошибку ответа проблемой самого Nginx. Например, веб-сервер может корректно передать запрос, а приложение вернуть неожиданный результат. Полезно заранее описать, какой компонент должен отвечать за каждый учебный путь, а не добавлять новые правила без общей схемы.
Проверка синтаксиса и проверка поведения дополняют друг друга
Параметр nginx -t проверяет синтаксис конфигурации и пытается открыть упомянутые в ней файлы. Это важный этап, но он не подтверждает правильность всех маршрутов и содержимого ответов. Изменения в файле также не применяются автоматически без соответствующей перезагрузки конфигурации или перезапуска. Для практической работы заранее предусматривают сохранение рабочей версии и способ возврата. После разрешённого изменения проверяют выбранные запросы и журналы. Журналы могут содержать чувствительные сведения, поэтому их не публикуют целиком без проверки. Учебные эксперименты проводят в изолированной среде, а рабочую систему меняют только в пределах своих полномочий.
Попробуйте на практике
Спроектируйте обработку запросов для вымышленного локального стенда. Никакие команды запускать и настоящую конфигурацию менять не требуется.
- Нарисуйте браузер, Nginx и отдельное приложение. Укажите два виртуальных сайта и определите, какой из них должен принимать запрос с неизвестным именем.
- Для одного сайта задайте две категории путей: изображения как статические файлы и запросы приложения через прокси. Опишите ожидаемый источник ответа для каждой категории.
- Придумайте три проверки: известное изображение, отсутствующий ресурс и путь приложения. Для каждой запишите ожидаемое поведение, не ограничиваясь тем, что сервер запущен.
- Добавьте порядок проверки конфигурации, применения разрешённого изменения и подтверждения результата. Укажите, какие признаки потребуют возврата к предыдущей версии и где искать сведения о причине.
Как проверить результат. План различает выбор сервера, правило пути и источник ответа. Успешная синтаксическая проверка не подменяет проверку поведения, а изменение имеет понятный способ контроля и возврата.
Частые вопросы
Правка файла сразу меняет ответы Nginx?
Нет. Новую конфигурацию нужно корректно применить. При этом способ применения зависит от организации конкретной системы.
Любой неверный ответ означает ошибку location?
Нет. Причина может быть в выборе сервера, файле, принимающем приложении или другом этапе. Полезно проследить весь маршрут запроса.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.