Cloudflare proxy для n8n: runbook 522, SSL и webhooks ¶

Обновлено: 2026-05-29

Intent: runbook Cloudflare proxy: n8n за Cloudflare, SSL mode, 522/525/520, real IP, webhooks, WAF и timeout
H1: Cloudflare proxy для n8n: как чинить 522, SSL, WAF и webhooks
Schema: TechArticle, HowTo, FAQPage, BreadcrumbList
Old word count: 666
New word count: 865

Короткий ответ ¶

Если n8n стоит за Cloudflare, проблемы чаще возникают не в самом workflow, а между Cloudflare, Nginx и origin-сервером: неправильный SSL mode, закрытый порт, WAF rule, timeout, неверный WEBHOOK_URL или потеря real client IP. Сначала определите код Cloudflare: 522 — Cloudflare не смог соединиться с origin, 525 — SSL handshake failed, 520 — непонятный ответ origin. Затем проверяйте origin напрямую, Nginx logs, SSL-сертификат и правила Cloudflare для webhook-путей.

Когда применять ¶

Этот runbook нужен, если домен n8n включён через Cloudflare proxy, то есть DNS-запись находится в orange cloud mode. Cloudflare может быть полезен: TLS, DNS, basic protection, WAF, rate limiting. Но для n8n он добавляет ещё один слой, который влияет на webhooks, OAuth callbacks, IP-адреса и long-running requests.

Симптомы:

• Cloudflare показывает 520/522/525/526;
• UI открывается, но внешние webhooks иногда не доходят;
• payment/CRM provider получает timeout;
• OAuth redirect работает локально, но падает на production;
• Nginx видит IP Cloudflare вместо клиента;
• WAF блокирует webhook payload;
• test URL работает, production URL у провайдера нет.

1. Разделить Cloudflare и origin ¶

Первый вопрос: n8n не работает вообще или не работает только через Cloudflare?

Проверьте origin напрямую, если есть безопасный способ: временный hosts entry, отдельный origin hostname, VPN или curl на IP с Host header.

curl -I https://automation.example.com
curl -I --resolve automation.example.com:443:ORIGIN_IP https://automation.example.com

Если origin напрямую отвечает, а через Cloudflare нет — ищите SSL mode, WAF, DNS, timeout или proxy rule. Если origin не отвечает напрямую — проблема ниже: Nginx, Docker, firewall, n8n, сертификат.

2. Понять код Cloudflare ¶

Для n8n частая комбинация: webhook запускает долгую обработку, внешний provider ждёт ответ, Cloudflare/Nginx timeout срабатывает, provider повторяет событие, workflow создаёт дубли.

3. SSL mode и сертификаты ¶

Для production обычно безопаснее использовать Full/Full strict с валидным сертификатом на origin. Режимы, где Cloudflare шифрует только часть пути или принимает сомнительный origin, могут создавать ложное ощущение безопасности.

Проверьте:

• origin слушает 443;
• сертификат на origin валиден для домена;
• Nginx отдаёт правильный certificate chain;
• HTTP → HTTPS редирект не создаёт loop;
• WEBHOOK_URL в n8n начинается с https://;
• внешние провайдеры используют тот же production URL.

Если Cloudflare показывает 525/526, сначала чините TLS на origin, а не workflow.

4. Real IP и ограничения доступа ¶

Когда Cloudflare проксирует трафик, origin обычно видит IP Cloudflare. Это влияет на logs, allowlist, rate limit и security checks.

Что проверить:

• Nginx настроен принимать real IP из Cloudflare headers;
• allowlist не блокирует Cloudflare IP ranges;
• rate limit не считает весь трафик одним IP;
• audit log сохраняет cf-ray/request ID, если нужно расследование;
• webhook-защита не полагается только на client IP.

Для платежей и CRM лучше иметь проверку события: secret, signature, event ID, status check у провайдера. IP allowlist полезен, но не должен быть единственной защитой, если провайдер даёт более надёжный механизм.

5. WAF, Bot Fight и webhook-пути ¶

Cloudflare может принять webhook за подозрительный запрос: нестандартный payload, пустой user-agent, много повторов, POST без браузерных headers. Поэтому для webhook-путей нужны отдельные правила.

Проверьте в Security Events:

• какой rule заблокировал запрос;
• path /webhook/... или /webhook-test/...;
• method POST;
• country/IP/provider;
• cf-ray;
• response code.

Не отключайте весь WAF глобально. Лучше сделать scoped rule для конкретных webhook paths и только для нужных providers. Для production webhooks можно сочетать bypass WAF challenge + rate limit + проверку secret/signature внутри workflow.

6. Timeouts и архитектура ответа ¶

Cloudflare и Nginx не должны ждать, пока workflow обработает 5000 строк или сходит в AI model. Внешнему webhook обычно нужен быстрый ответ: «событие принято». Тяжёлая обработка должна идти дальше.

Рекомендуемый подход:

1. Webhook принимает payload.
2. Проверяет минимальную валидность и event ID.
3. Быстро возвращает 200/202.
4. Основная обработка идёт дальше: очередь, worker, отдельный workflow, CRM/API.
5. Результат пишется в журнал.

Такой подход снижает 524/timeout и уменьшает количество повторных доставок от провайдера.

7. Smoke test после изменений ¶

• Проверить curl -I через Cloudflare.
• Проверить origin напрямую.
• Проверить production URL в n8n Webhook node.
• Отправить тестовый POST на webhook.
• Посмотреть Cloudflare Security Events.
• Посмотреть Nginx access/error logs.
• Проверить, что у провайдера сохранён актуальный HTTPS URL.

FAQ ¶

Можно ли отключить Cloudflare proxy для n8n?
Да, иногда это лучший вариант для диагностики. Но сначала убедитесь, что origin защищён: HTTPS, firewall, auth, rate limit и закрытый UI.

Почему webhook работает без Cloudflare, но падает с Cloudflare?
Вероятно, WAF, timeout, SSL mode, body size или правило доступа. Смотрите Cloudflare Security Events и Nginx logs.

Что делать с 522?
Проверьте, доступен ли origin на 443, не блокирует ли firewall Cloudflare IP и жив ли Nginx/n8n.

Нужно ли доверять только IP Cloudflare?
Для origin firewall — да, это полезно. Для webhook-безопасности — нет, лучше проверять secret/signature/event ID.

{
  "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"
}