#Симптом и границы применимости
Главная страница открывается, а запрос к одному каталогу уходит по повторяющейся цепочке 301/302. В отличие от общего цикла перенаправлений здесь ключевыe правила для пути, завершающий слэш и расположение location.
#Возможные причины и как их отличить
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Перенаправление слэшаNginx и приложение могут по-разному нормализовать слэш. | /catalog ↔ /catalog/ | Сравнить заголовки Location на обоих путях |
| Конфликт location/rewriteОтдельный раздел сайта попадает в особый блок маршрутизации. | Петля существует только в одном префиксе | Найти точный location и rewrite |
| Приложение и прокси не согласны о путиBackend может перенаправлять на внутренний URL или иной путь. | Ответ Location ведёт обратно на публичный маршрут | Проверить Host, префикс и схему на прокси |
#Пошаговая диагностика и исправление
- Запишите два адреса без переходовОткройте окно терминала на своём компьютере, введите адрес главной и проблемной папки и запишите HTTP-статус. Далее выполните запрос без -L для каждого варианта со слэшем и без него; поле Location покажет первый редирект. Не удаляйте cookies на этом этапе: требуется установить причину на сервере.
- Замените catalog своим разделом; некоторым приложениям нужен безопасный GET вместо HEADLinux · Терминал (Bash)КомандаЗамените catalog своим разделом; некоторым приложениям нужен безопасный GET вместо HEAD.
curl -I https://example.com/catalogcurl -I https://example.com/catalog/
- Посмотрите цепочку с ограничениемПроверьте не более шести переходов, чтобы не запускать бесконечные запросы. Повторяющееся Location для одного каталога при рабочей главной доказывает локальность неисправности. Вывод содержит URL — удалите из отчёта чувствительные параметры.
- Только диагностические HTTP-запросыLinux · Терминал (Bash)КомандаТолько диагностические HTTP-запросы.
curl -IL --max-redirs 6 https://example.com/catalog/
- Найдите точное правило в NginxВойдите на сервер по SSH, выполните nginx -t и просмотрите конфигурацию для server_name домена. Сравните location /catalog, location /catalog/, rewrite, return и proxy_pass. Правила для / не обязательно действуют в более специфическом location.Linux · Терминал (Bash)КомандаНужен sudoКонфигурация может содержать секреты — не пересылайте её целиком.
sudo nginx -T 2>&1 | grep -nE "location |rewrite|return 30|proxy_pass|server_name"
- Проверьте перенаправления приложенияЕсли Nginx передаёт /catalog в CMS, откройте настройку постоянных ссылок или базового URL этого раздела. Сопоставьте абсолютные/относительные пути с тем, что в Location. Не меняйте глобальный домен, если главная работает: сначала устраните противоречие двух правил только для каталога.
- Исправьте ровно одно конфликтующее правилоСохраните копию файла конфигурации. Уберите избыточный редирект либо исправьте правило trailing slash в одном слое. При proxy_pass учитывайте, есть ли завершающий / после адреса upstream: это может менять передаваемый путь. Прежде чем менять это правило на работающем сервере, проверьте соседние URL в тестовом окружении.
- Проверьте синтаксис и перечитайте конфигурациюВ SSH выполните команду. При ошибке nginx -t reload не сработает; исправьте конфигурацию или верните копию. После успешного перечитывания повторите curl для обоих вариантов пути.Linux · Терминал (Bash)С осторожностьюНужен sudoLinux с systemd и права sudo; изменения затрагивают обработку адресов в выбранном server-блоке.
sudo nginx -t && sudo systemctl reload nginxКоманда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
#Как проверить результат
Цепочка для /catalog и /catalog/ должна заканчиваться рабочим адресом за небольшое число переходов. Проверьте ещё дочернюю страницу и главную — исправление не должно переносить петлю на другие пути.
#Если проблема не устранена
Если curl показывает один адрес, но браузер остаётся в петле, сравните ответы с авторизацией и без, проверьте плагины CMS, кэш CDN и правила уровня приложения; возврат конфигурации должен устранить ухудшение.