SignalTo
返回博客

TradingView Webhook 不工作？8 个最常见原因和排查清单

告警明明触发了，群里却收不到消息？这篇按出现频率，把 TradingView Webhook 收不到、403/401 报错、3 秒超时、收到一半丢一半等问题逐条讲清楚，并给出一份可照着勾的排查清单。

2026年6月28日SignalTo 团队SignalTo 团队
TradingView Webhook 不工作？8 个最常见原因和排查清单

你在 TradingView 设好了告警，填了 Webhook 地址，然后……什么都没发生。或者更让人抓狂的：有时候能收到，有时候收不到，毫无规律。

我自己踩过这些坑，也帮不少人排查过。结论是：90% 的「webhook 不工作」并不是玄学，而是落在下面这几个固定原因里。这篇按我遇到的频率从高到低排，你照着一条条过一遍，基本都能找到病根。

1. 你的 TradingView 套餐根本没有 Webhook

这是最常见、也最容易被忽略的一条。免费版（Basic）不支持 Webhook，需要 Essential 及以上套餐才有这个功能。

怎么判断：新建告警时，拉到弹窗底部的「Notifications（通知）」标签，如果根本看不到 "Webhook URL" 这个选项，那就是套餐不够，别再折腾后面的步骤了。

2. 地址不是 HTTPS，或者用了奇怪的端口

TradingView 对接收地址有几条硬性要求，违反任意一条都直接发不出去：

  • 必须是 https://，http:// 一律拒绝；
  • 只接受 80 和 443 端口，地址里带其它端口号（比如 :3000、:8080）会被拒；
  • 不支持 IPv6，域名必须能解析到 IPv4；
  • 不能填内网地址，localhost、127.0.0.1、192.168.x.x TradingView 的服务器根本访问不到。

如果你是自己用电脑跑脚本测试，这一条几乎必中——你以为本地能通，其实 TradingView 在外网根本连不上你的机器。

3. 账号没开两步验证（2FA）

这条很隐蔽：TradingView 规定，只有开启了两步验证的账号，才允许使用 Webhook 告警。没开 2FA 的话，告警里可能根本存不下 Webhook 地址，或者存了也不发。先去账号安全设置里把 2FA 打开。

4. 看到 403 / 401：是被你自己的服务器挡了

如果你用的是自建脚本/服务，告警日志里出现 403 或 401，几乎可以锁定方向：

  • 403：服务器「认得」TradingView，但把它拦下了。通常是防火墙规则、CSRF 校验，或者你做了 IP 白名单却没放行 TradingView。TradingView 的 Webhook 来自固定的几个 IP，自建服务记得把它们加进白名单。
  • 401：鉴权失败。多半是密钥/令牌填错、过期，或者上面说的 2FA 没开。

排查顺序：先确认密钥两边一致，再确认防火墙/白名单放行，最后用 curl 直接打一次你的接收地址，看能不能通。

5. 3 秒超时：最隐蔽的「偶尔丢」元凶

TradingView 有一条容易被忽略的硬规则：接收服务器必须在 3 秒内返回响应，否则这次推送直接判为失败。

这正是很多人「有时收到有时收不到」的真相——你的服务器平时很快，但偶尔因为要查库、调下游接口、冷启动等卡了一下，超过 3 秒，这条告警就这么没了，而且 TradingView 不会替你重试。

正确做法是：收到请求先立刻返回 200，再在后台异步处理转发。自己写脚本时这一步经常被漏掉，于是高峰期就开始零星丢消息。

6. 告警日志里写着 4xx / 5xx：问题在接收端

TradingView 的告警面板里有一列 Webhook 状态，把鼠标移上去能看到具体报错。按状态码大致判断：

  • 400：你发的内容格式不对——通常是 JSON 写错了，或缺了接收端要求的字段。先用 JSON 校验器过一遍。
  • 404 / 410：地址错了，或者目标（比如 Discord 的 Webhook）已经被删了。
  • 5xx：接收端自己崩了或临时故障，需要去看接收端的日志。

一个好用的笨办法：先把 Webhook 地址临时换成 webhook.site 这种公开测试地址。如果在那能收到、在你自己的地址收不到，那问题 100% 出在你的接收端，而不是 TradingView。

7. 消息体格式：纯文本 vs JSON

TradingView 默认把告警内容当纯文本发送；只有当你在 Message 里填的是合法 JSON 时，它才会带上 application/json 的 content-type。

如果你的接收端只认 JSON，却在 Message 里写了一句大白话，接收端解析就会失败。想做字段模板（symbol、action、price 这些），建议直接写 JSON：

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

8. 不是丢，是「刷屏」和「幻觉告警」

还有一类不算「收不到」，而是「收到太多」或「收到不该收的」：

  • 重复刷屏：告警条件用了 once_per_bar，一根 K 线没走完就反复触发。多数策略类告警应该用 once_per_bar_close（每根 K 线收盘触发一次）。
  • 幻觉/历史告警：用了 Bar Replay 或重启后，历史 K 线被重新计算触发，群里突然冒出一堆过期信号。
  • 同一条被发两次：网络抖动时 TradingView 偶尔会重推同一条，接收端如果不做去重就会重复发。

一份可以照着勾的排查清单

按顺序过，绝大多数问题在前几条就解决了：

  1. ☐ 套餐是 Essential 及以上？（能在告警里看到 Webhook URL 选项）
  2. ☐ 账号开了两步验证（2FA）？
  3. ☐ 地址是 https://、且没带非标准端口？
  4. ☐ 地址是公网可达的域名，不是 localhost / 内网 IP？
  5. ☐ 用 webhook.site 测，能收到吗？（能 → 问题在你的接收端）
  6. ☐ 接收端是否「先返回 200、再异步处理」，确保 3 秒内响应？
  7. ☐ 自建服务：防火墙/白名单放行了 TradingView 的固定 IP 吗？
  8. ☐ Message 是合法 JSON 吗？（接收端要 JSON 的话）
  9. ☐ 触发条件是 once_per_bar_close，避免刷屏吗？
  10. ☐ 失败的告警，有没有重试和留痕？还是发出去就石沉大海？

与其每次排查，不如让接收端别出问题

上面这份清单里，第 5～10 条几乎都指向同一个根源：你的接收端（那个转发脚本/服务）不够稳。自己用 Cloudflare Worker 或 VPS 脚本搭，往往是「能跑」，但没解决 3 秒响应、失败重试、去重、留痕这些真正决定可靠性的细节。

这也是 SignalTo 在做的事：给你一个开箱即用的接收地址——自带 HTTPS、秒级响应（先收下再异步转发，不会卡 3 秒）、入站自动去重、失败自动重试，每一条推送都有完整记录可查。把上面清单里最难自己搞定的几条，直接替你兜住。

免费拿一个稳定的接收地址 →