--- title: "Nginx proxy для n8n: runbook 502, HTTPS и webhooks - Nodbot" source_url: "https://nodbot.ru/playbooks/runbook-nginx-proxy/" canonical_url: "https://nodbot.ru/playbooks/runbook-nginx-proxy/" language: "ru" content_type: "TroubleshootingGuide" section: "playbooks" generated_at: "2026-05-30" word_count_source: 971 --- # Nginx proxy для n8n: runbook 502, HTTPS и webhooks ## AI summary Runbook по Nginx reverse proxy для n8n: 502/504, HTTPS, X-Forwarded headers, WEBHOOK_URL, websocket, upload size и production webhooks. ## Best used for Страница объясняет «Nginx proxy для n8n: runbook 502, HTTPS и webhooks - Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Короткий ответ - Когда нужен этот runbook - 1. Проверить upstream - 2. Проверить headers и внешний URL - 3. Разделить ошибки 502, 504 и неправильный URL - 4. Проверить TLS и редиректы - 5. Размер body и long-running requests - 6. Smoke test после правки ## Source outline # Nginx proxy для n8n: runbook 502, HTTPS и webhooks Обновлено: 2026-05-29 Intent: runbook Nginx proxy: 502, 504, неправильные webhook URL, headers, TLS termination для n8n behind reverse proxy H1: Nginx proxy для n8n: как чинить 502, HTTPS и production webhooks Schema: TechArticle, HowTo, FAQPage, BreadcrumbList Old word count: 668 New word count: 680 ## Короткий ответ Если n8n стоит за Nginx и ломаются webhooks, OAuth callbacks или UI, проверьте три вещи: upstream до контейнера n8n:5678 , корректные X-Forwarded-* headers и переменную WEBHOOK_URL с публичным HTTPS-доменом. Ошибка 502 чаще говорит, что Nginx не достучался до n8n, 504 — что upstream не ответил вовремя, а неправильные webhook URL обычно связаны с тем, что n8n видит внутренний порт вместо внешнего домена. ## Когда нужен этот runbook Страница помогает, если n8n открывается через Nginx reverse proxy: Docker Compose, VPS, self-hosted сервер, отдельный TLS termination, домен вида automation.example.com . Особенно важно проверить proxy после миграции домена, перехода с HTTP на HTTPS, переноса контейнера в другую network или подключения Telegram/OAuth/payment webhooks. Типичные симптомы: - браузер показывает 502 Bad Gateway; - UI открывается, но webhooks недоступны снаружи; - n8n показывает production URL с localhost , http или портом 5678 ; - OAuth provider ругается на redirect URI; - Telegram Trigger не регистрирует webhook; - большие payload или файлы обрываются; - long-running webhook получает 504. ## 1. Проверить upstream Сначала убедитесь, что Nginx вообще видит n8n. ``` docker compose ps docker compose logs --tail=100 nginx docker compose logs --tail=100 n8n ``` Если Nginx в том же Docker Compose, upstream обычно должен ссылаться на имя сервиса: ``` upstream n8n_upstream { server n8n:5678; } ``` Если Nginx установлен на хосте, а n8n в Docker, проверьте опубликованный порт и firewall. Не используйте localhost в конфиге Nginx внутри отдельного контейнера, если n8n живёт в другом контейнере: localhost будет указывать на сам контейнер Nginx. ## 2. Проверить headers и внешний URL n8n должен понимать, какой публичный домен видят внешние сервисы. Для reverse proxy критичны публичный HTTPS URL и forwarded headers. Пример базового location: ``` location / { proxy_pass http://n8n_upstream; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Proto $scheme; } ``` В .env для n8n за proxy проверьте: ``` N8N_HOST=automation.example.com N8N_PROTOCOL=https WEBHOOK_URL=https://automation.example.com/ N8N_PROXY_HOPS=1 ``` Если перед Nginx есть ещё Cloudflare, load balancer или другой proxy, количество proxy hops и реальные headers нужно проверять отдельно. ## 3. Разделить ошибки 502, 504 и неправильный URL - Симптом | Вероятная причина | Проверка - 502 Bad Gateway | n8n не слушает upstream, сеть, порт | curl до upstream из Nginx - 504 Gateway Timeout | workflow отвечает слишком долго | response mode, timeout, async обработка - Production URL неправильный | нет WEBHOOK_URL или headers | UI Webhook node, env - OAuth callback mismatch | публичный URL не совпадает | redirect URL в provider - Telegram webhook не ставится | HTTPS/сертификат/URL | cert, WEBHOOK_URL , logs Для webhook, который делает тяжёлую работу, лучше быстро вернуть 200/202, а обработку продолжить асинхронно. Тогда proxy и внешний провайдер не будут ждать минутами. ## 4. Проверить TLS и редиректы Публичные webhooks почти всегда должны жить на HTTPS. Проверьте: - сертификат валиден; - HTTP редиректит на HTTPS; - нет бесконечного redirect loop; - Nginx передаёт X-Forwarded-Proto https ; - n8n не генерирует ссылки с http:// ; - staging и production имеют разные домены или чёткое разделение. Команды: ``` curl -I http://automation.example.com curl -I https://automation.example.com curl -I https://automation.example.com/webhook/test-path ``` ## 5. Размер body и long-running requests Если workflow принимает файлы, CSV, изображения, PDF или большие JSON, Nginx может резать запрос до n8n. Проверьте: ``` client_max_body_size 25m; proxy_read_timeout 300s; proxy_send_timeout 300s; ``` Не ставьте огромные timeout как постоянное решение. Если webhook должен отвечать внешнему провайдеру, долгий request часто хуже фоновой обработки: провайдер может повторить событие, а workflow создаст дубли. ## 6. Smoke test после правки После изменения Nginx и .env сделайте короткий тест: - Перезапустите n8n, чтобы env применились. - Откройте Webhook node и проверьте production URL. - Отправьте внешний curl на тестовый endpoint. - Проверьте logs Nginx и n8n. - Проверьте OAuth callback или Telegram Trigger, если они были затронуты. - Убедитесь, что старые URL не остались у внешнего провайдера. ## FAQ Почему n8n показывает URL с портом 5678? Обычно n8n формирует URL из внутренних настроек. За reverse proxy нужно явно задать публичный WEBHOOK_URL . Что означает 502 от Nginx? Nginx не получил нормальный ответ от upstream: n8n не запущен, не тот порт, другая Docker network, firewall или неправильный upstream host. Можно ли держать UI и webhooks на разных доменах? Можно, но конфигурация должна быть осознанной. Для большинства небольших инсталляций проще один публичный HTTPS-домен. Нужно ли менять настройки у провайдеров после смены домена? Да. OAuth redirect URI, payment webhooks, Telegram webhooks и CRM callbacks часто хранят конкретный URL. ## Как применять playbook в команде Playbook «Nginx proxy для n8n» должен быть понятен человеку, который не писал workflow. Поэтому в нём нужны входной сигнал, частота запуска, критерий тревоги, ответственный и ожидаемое действие после срабатывания. Используйте этот материал как операционную инструкцию: что проверить, где посмотреть логи, как понять масштаб проблемы и когда эскалировать. - Слой | Что зафиксировать | Зачем - Вход | payload webhook/API с подписью, timestamp, event_id и исходным HTTP-статусом | позволяет повторить проблему без доступа к production-секретам - Контроль | successful_executions, skipped_items, retry_count, error_branch_usage, manual_override_count | показывает деградацию раньше, чем пользователи начинают писать в поддержку - Безопасность | принять happy path за production-готовность и не проверить повторы, пустые входы, откат и наблюдаемость | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий - Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «Nginx proxy для n8n» | делает статью пригодной для runbook, а не только для чтения ### Пример безопасного входного контракта ``` { "event_id": "evt_...", "event_type": "object.updated", "received_at": "2026-05-29T10:00:00Z", "signature_valid": true, "dedupe_key": "provider:event_id", "payload_version": "v1" } ``` ### Критерий готовности - есть понятный вход, выход и владелец процесса - проверены пустой input, повтор события и ошибка внешнего сервиса - результат логируется без секретов и персональных данных - страница связана с соседними рецептами, ошибками или playbook по теме ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Ноды](/nodes/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.