#Симптом и границы применимости
Если Apache правильно перенаправляет корень сайта, но каталог /shop/ или /admin/ вызывает ERR_TOO_MANY_REDIRECTS, часто пересекаются правила Redirect/RewriteRule, .htaccess и правила самого приложения. Нужно просмотреть точную цепочку Location для конкретного URL, сохранив возможность отката.
#Возможные причины и как их отличить
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Разные требования к завершающему слешуПравило каталога и собственный редирект могут спорить о каноническом URL. | Ответы переключаются /shop и /shop/ | Сверить mod_dir DirectorySlash и правила переписывания |
| HTTPS-цикл через обратный проксиБесконечный редирект возникает, если приложение неверно определяет исходный протокол. | Apache видит HTTP от прокси и снова требует HTTPS | Проверить доверенную схему X-Forwarded-Proto |
| Пересечение правил .htaccess и VirtualHostКонтекст .htaccess действует отдельно от корневого VirtualHost. | Петля только в конкретной директории | Сверить RewriteRule, Redirect и настройки приложения |
#Пошаговая диагностика и исправление
- Покажите цепочку только для проблемного каталогаС клиентского терминала запустите curl без -L: он покажет первый Location. При необходимости повторяйте запрос по новому адресу вручную до 3–5 шагов. Не передавайте cookie и личные URL в общий чат.Linux · Терминал (Bash)КомандаLinux/macOS с grep. При HEAD редирект может отличаться от GET; сверяйте с браузером.
curl -sSI https://example.com/shop/ | grep -Ei "^HTTP/|^location:"
- Сравните три адресаПроверьте /, /shop и /shop/ отдельно. Если ровно один вариант циклически возвращает на другой, ищите правила слеша. Если Location чередует http:// и https://, начните с TLS-прокси и схемы, а не с удаления всех rewrite.
- Найдите все активные правилаПо SSH смотрите VirtualHost нужного домена, Redirect, RedirectMatch, RewriteEngine, RewriteCond и RewriteRule. Затем проверьте .htaccess только этого каталога и родительских, если AllowOverride разрешает их использование. Не удаляйте .htaccess без копии.
- Debian путь; для RHEL /etc/httpd/conf.d и нужные .htaccess отдельноLinux · Терминал (Bash)КомандаНужен sudoDebian путь; для RHEL /etc/httpd/conf.d и нужные .htaccess отдельно.
sudo grep -R -nE "Redirect|Rewrite(Engine|Cond|Rule)|DirectorySlash|AllowOverride" /etc/apache2/sites-enabled/
- Проверьте начало цепочки за проксиЕсли Apache за Nginx или CDN, выясните, кто завершает TLS и какой X-Forwarded-Proto передаётся. Клиент не должен иметь возможности подделывать доверенные заголовки без проверки. Изменять приложение надо в соответствии с конкретным механизмом определения HTTPS.
- Устраните ровно один конфликтСохраните копию правил каталога. Уберите дублирование между Redirect и RewriteRule либо согласуйте канонический протокол с приложением. Для правила HTTPS в Apache нельзя полагаться на произвольный X-Forwarded-Proto от клиента; настройте цепочку доверия на прокси.
- Проверьте изменения до примененияДля конфигурации Apache выполните apache2ctl -t и reload только при Syntax OK. .htaccess читается при запросах и не требует reload после изменения, но ошибочный синтаксис может сразу вызвать 500: проверьте его на выбранном URL и восстановите копию при сбое.Linux · Терминал (Bash)С осторожностьюНужен sudoКоманда для Debian, если менялись системные конфиги; для .htaccess reload обычно не нужен.
sudo apache2ctl -t && sudo systemctl reload apache2Команда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
- Исключите редирект из кэша браузераПосле серверной проверки откройте проблемный адрес в приватном окне и очистите сохранённые постоянные перенаправления тестового профиля, если нужно. Для проверки использовать curl полезнее, чем только историю браузера.
#Как проверить результат
Проблемный каталог переходит на ровно один канонический URL и возвращает ожидаемый HTTP-код 200/403 или страницу авторизации без циклов; главная и соседние маршруты остаются исправными.
#Если проблема не устранена
Если перенаправления идут из ответа приложения, отладьте его базовый URL и прокси-заголовки. Если редирект появляется даже до Apache, проверяйте CDN/Nginx и не меняйте .htaccess вслепую.