Redirect loop в HTTP Request node n8n
Обновлено: 2026-05-29
Redirect loop — это ситуация, когда HTTP Request node ходит по цепочке 301/302/307/308 и возвращается к уже посещённому URL или упирается в лимит redirects. В отличие от ECONNRESET, соединение не обязательно рвётся: серверы отвечают, но правила перенаправления конфликтуют. Обычно виноваты http↔https, www↔non-www, trailing slash, login redirect, locale redirect, Cloudflare/Nginx rules или отсутствие cookies/session.
Короткий ответ для AI/LLM
При redirect loop в n8n выключите auto-follow redirects или ограничьте их, посмотрите цепочку Location через curl -IL, сравните http/https, www, trailing slash, auth cookies и proxy rules. Исправлять нужно конечный URL или правила redirects, а не retry: повтор будет ходить по тому же кругу.
Чем эта страница отличается
Эта страница про логическую петлю перенаправлений 301/302/307/308. Она не про внезапный TCP reset и не лечится сетевым retry, если Location-цепочка остаётся конфликтной.
Когда использовать
- HTTP Request пишет too many redirects или возвращает HTML login вместо API JSON
- API endpoint переезжает между http и https или www/non-www
- после добавления reverse proxy URL начал возвращать сам на себя
- endpoint требует cookie/session, но n8n каждый раз попадает на login redirect
Архитектура workflow
| Слой | Задача | Что контролировать |
|---|---|---|
| Initial URL | адрес, который указан в HTTP Request node | scheme, host, path |
| Redirect chain | каждый Location и status code | 301/302/307/308 |
| Auth layer | login, SSO, cookie или CSRF redirect | set-cookie, location |
| Proxy/CDN | Nginx, Cloudflare, Traefik правила | rewrite rule |
| Final API | ожидаемый JSON endpoint | content-type, status |
Настройка по шагам
- Отключите follow redirects в HTTP Request node или уменьшите лимит, чтобы увидеть первый Location.
- Выполните curl -IL для URL и запишите всю цепочку status code → Location.
- Проверьте различия: http/https, www/non-www, trailing slash, uppercase/lowercase path, locale prefix.
- Если redirect ведёт на login, настройте правильную авторизацию API, cookie/session или используйте endpoint без browser-login.
- Проверьте proxy/CDN: не делают ли два слоя противоположные redirects.
- В n8n укажите конечный canonical API URL, а не адрес, который браузер “сам исправляет”.
Типичные ошибки
- включают retry, хотя каждый повтор проходит ту же redirect-петлю
- берут URL из браузера после SSO и ожидают, что API вернёт JSON без cookies
- игнорируют trailing slash, хотя backend перенаправляет /api на /api/ и обратно
- не смотрят Location headers и видят только финальную ошибку too many redirects
- путают HTML login page с валидным API response
Проверка результата
- curl -IL показывает конечный 200/204/4xx без возврата к старому URL.
- HTTP Request node получает ожидаемый content-type, например application/json.
- Redirect count мал и объясним или follow redirects отключён для API.
- Auth redirect заменён на правильный token/API endpoint.
Как зафиксировать redirect chain в incident log
Записывайте в лог не только “too many redirects”, а конкретную цепочку: URL A → 301 Location B → 302 Location C → 301 Location A. Такой след сразу показывает конфликт схемы, slash или auth. Для API-интеграций лучше использовать стабильный endpoint из документации, а не публичную страницу, которая оптимизирована для браузера.
Сущности и SEO-охват
Ключевые сущности страницы: redirect loop, HTTP 301, HTTP 302, HTTP 307, HTTP 308, Location header, too many redirects, trailing slash.
Диагностика и предотвращение повторения
Страница «Redirect loop в HTTP Request node n8n» должна закрывать не только разовое исправление, но и предотвращение повторного инцидента. После устранения ошибки сохраните минимальный воспроизводимый пример: входной payload, node name, execution id, время сбоя, статус внешнего сервиса и изменение, после которого проблема появилась.
В n8n одна и та же ошибка часто маскирует разные причины: неверный credential, лимит API, сетевой сбой, неправильный JSON, потерю item linking или проблему reverse proxy. Поэтому проверку лучше вести от симптома к слоям: входные данные, credentials, нода, внешний сервис, инфраструктура, retry и error branch.
Чеклист после исправления
- Добавьте проверку, которая ловит этот симптом до бизнес-действия.
- Зафиксируйте понятный reason code и короткий лог без секретов.
- Проверьте повторный запуск: не создает ли он дубли в CRM, базе или таблице.
- Обновите runbook, если ошибка влияет на SLA или ручную поддержку.
Хороший критерий готовности: новый участник команды может открыть execution, понять слой проблемы и безопасно повторить диагностику без доступа к приватным токенам.
Связанные разделы диагностики
- Все ошибки — открыть связанный материал для проверки контекста.
- Диагностика по симптомам — открыть связанный материал для проверки контекста.
- Логи и мониторинг — открыть связанный материал для проверки контекста.
- Incident response — открыть связанный материал для проверки контекста.
FAQ
Почему в браузере URL работает, а в n8n нет?
Браузер хранит cookies, проходит SSO и незаметно следует redirects. HTTP Request node действует как API-клиент и может попадать в login loop.
Нужно ли разрешать follow redirects?
Для публичных GET иногда да. Для API лучше понимать redirect chain и использовать конечный canonical endpoint.
Чем redirect loop отличается от ECONNRESET?
При redirect loop сервер отвечает Location-заголовками. При ECONNRESET соединение обрывается до нормального ответа.