Webhook TradingView не работает? 8 частых причин и чеклист исправлений

Вы настроили оповещение в TradingView, вставили webhook URL, а потом… тишина. Или хуже — иногда работает, иногда нет, без явной закономерности.

Со всем этим сталкивался сам и много раз отлаживал для других. Вывод: 90% «webhook не работает» — не магия, а несколько фиксированных причин. Ниже — от самых частых к редким. Пройдите по порядку, и почти всегда найдёте виновника.

1. Ваш план TradingView не включает webhook

Самая частая причина и самая легко пропускаемая. Бесплатный план (Basic) не поддерживает webhook — нужен Essential или выше.

Как проверить: при создании оповещения прокрутите до вкладки Notifications внизу диалога. Если опции «Webhook URL» вообще нет — дело в плане; не отлаживайте остальное.

2. URL не HTTPS или с нестандартным портом

У TradingView жёсткие требования к URL приёмника. Нарушите любое — ничего не уйдёт:

• Обязательно https:// — http:// отклоняется сразу;
• Только порты 80 и 443 — URL с другим портом (например :3000, :8080) отклоняется;
• Без IPv6 — домен должен резолвиться в IPv4;
• Без локальных адресов — серверы TradingView не достучатся до localhost, 127.0.0.1 или 192.168.x.x.

Если тестируете скрипт на своей машине, это почти всегда кусает — кажется, что локально работает, но TradingView снаружи до вас не доберётся.

3. Двухфакторная аутентификация не включена

Хитрый момент: TradingView разрешает webhook-оповещения только на аккаунтах с включённой 2FA. Без 2FA оповещение может не сохранить webhook URL или сохранить, но не отправлять. Сначала включите 2FA в настройках безопасности.

4. Видите 403 / 401: ваш сервер блокирует

Если у вас свой скрипт или сервис и в логе оповещений 403 или 401, сузить причину быстро:

• 403: сервер «узнаёт» TradingView, но блокирует. Обычно правило файрвола, CSRF или allowlist без IP TradingView. Webhook TradingView приходят с фиксированного набора IP — добавьте их в allowlist.
• 401: ошибка аутентификации. Чаще всего неверный/просроченный secret или token, либо 2FA выше.

Порядок: убедитесь, что secret совпадает с обеих сторон; что файрвол/allowlist пропускает TradingView; затем дерните endpoint напрямую через curl.

5. Таймаут 3 секунды: скрытая причина пропаданий

У TradingView легко пропустить правило: сервер должен ответить за 3 секунды, иначе доставка считается неудачной.

Это реальная причина большинства «иногда работает, иногда нет». Сервер обычно быстрый, но иногда тормозит — медленный запрос к БД, вызов downstream API, cold start — пересекает 3 секунды, и оповещение просто пропадает. TradingView за вас не повторит.

Правильный подход: сразу вернуть 200 при приёме, пересылку обработать асинхронно в фоне. В самописных скриптах этот шаг постоянно пропускают — и при нагрузке начинаются случайные потери.

6. В логе оповещений 4xx / 5xx: проблема на стороне приёмника

В панели оповещений TradingView есть колонка статуса webhook; наведите для точной ошибки. По коду:

• 400: payload кривой — часто битый JSON или отсутствует обязательное поле. Прогоните через валидатор JSON.
• 404 / 410: неверный URL или цель (например Discord webhook) удалена.
• 5xx: приёмник упал или дал временный сбой — смотрите его логи.

Полезный трюк: временно укажите webhook на публичный тест вроде webhook.site. Если туда приходит, а на ваш URL — нет, проблема на 100% у вашего приёмника, не у TradingView.

7. Формат payload: plain text vs JSON

По умолчанию TradingView шлёт тело оповещения как plain text; application/json только если в поле Message валидный JSON.

Если приёмник принимает только JSON, а вы написали обычное предложение, парсинг падает. Для шаблонов полей (symbol, action, price и т.д.) используйте JSON:

{
  "symbol": "{{ticker}}",
  "action": "{{strategy.order.action}}",
  "price": "{{close}}"
}

8. Не «пропало» — «спам» или «фантомные» оповещения

Другой класс проблем: не «ничего не пришло», а «пришло слишком много» или «лишнее»:

• Дублирующий спам: условие с once_per_bar, срабатывает снова до закрытия свечи. Для стратегий обычно нужен once_per_bar_close (раз за закрытую свечу).
• Фантомные / исторические: после Bar Replay или перезапуска пересчитываются старые свечи и льётся поток устаревших сигналов.
• Одно оповещение дважды: при сбое сети TradingView иногда повторно шлёт то же; без dedup на приёмнике уйдёт два раза.

Чеклист для проверки

Идите по порядку — большинство решается в первых пунктах:

1. ☐ План Essential или выше? (в оповещении есть Webhook URL)
2. ☐ Включена двухфакторная аутентификация (2FA)?
3. ☐ URL — https:// без нестандартного порта?
4. ☐ URL — публичный домен, не localhost / приватный IP?
5. ☐ Проверено через webhook.site — приходит? (да → проблема в вашем приёмнике)
6. ☐ Приёмник «сначала 200, потом async», укладывается в 3 секунды?
7. ☐ Самохост: файрвол/allowlist пропускает фиксированные IP TradingView?
8. ☐ Message — валидный JSON? (если приёмник ждёт JSON)
9. ☐ Триггер once_per_bar_close, чтобы не спамить?
10. ☐ Неудачные оповещения повторяются и логируются — или исчезают без следа?

Лучше, чем отлаживать каждый раз: приёмник, который не ломается

Пункты 5–10 почти всегда указывают на одну причину: ваш приёмник (скрипт/сервис пересылки) недостаточно надёжен. DIY Worker или VPS-скрипт обычно «работает», но пропускает детали, от которых зависит надёжность — ответ за 3 секунды, повтор при сбое, dedup и аудит.

Именно это делает SignalTo: даёт готовый URL приёмника — HTTPS из коробки, мгновенный ответ (принял сразу, пересылает async, не упирается в 3 секунды), автоматический inbound dedup, автоповторы при сбое и полная запись доставки для каждого сообщения. Самые сложные пункты чеклиста — за вас.

Получите стабильный URL приёмника бесплатно →