Конспект раздела: location

Раздел про решение №2 - сердце маршрутизации. Половина вопросов «почему отдаётся не то» разбирается отсюда.

Алгоритм на одной карточке

=  точный URI          → победил сразу
^~ длинный префикс     → победил, регулярки пропускаются
~  ~*  регулярки       → первая совпавшая СВЕРХУ ВНИЗ
   обычный префикс     → запоминается по длине, побеждает, если регулярок нет

Пять фактов, которые экономят вечер

1. Префикс - это строка, а не путь: /app ловит /application.log.
2. Регулярка бьёт длинный префикс - если это не нужно, ставь ^~.
3. Вложенные блоки сравниваются с полным URI, а не с остатком, и обязаны лежать внутри внешнего префикса - иначе конфиг не загрузится.
4. Вложенные регулярки спрашиваются раньше внешних.
5. Именованный @block доступен только через try_files и error_page, а error_page не перехватывает ответ бэкенда без proxy_intercept_errors.
6. Сравнивается нормализованный URI: без строки запроса, с раскодированными процентами и схлопнутыми ...

Как отлаживать

add_header X-Location "images-regex";   # свой маркер в каждый спорный блок

curl -I http://shop.local/images/logo.png

Заголовок в ответе прямо называет победивший блок - быстрее, чем спорить с конфигом по памяти.

Чек-лист: что ты должен уметь объяснить

• Полный алгоритм выбора location по шагам.
• Почему location /images/ проигрывает location ~ \.png$ и как это исправить.
• Что произойдёт с запросом /application.log при location /app.
• Зачем нужны именованные location и кто может в них попасть.
• Когда вложенность помогает, а когда лучше плоский список.