智用_AI
首页 / 指南 / 警报接 Webhook 丢信号

图上出了信号,下单程序却没动静,顺着 Webhook 走过的四段往下核

作者 秦深更新 2026-10-07约 9 分钟阅读
智用 AI 站点封面图,本文讲 TradingView 警报通过 Webhook 发出后信号在哪一段丢失、各段怎么核对

警报明明响了,下单程序那边却什么都没发生。这时候别急着改策略,去看两处日志:一处是 TradingView 的警报日志,看那个时间有没有这一条,以及它的 "Webhook状态" 一列写了什么;另一处是接收端自己的请求记录,看同一时间有没有收到东西。两边对一遍,就知道信号停在了哪里。

Webhook 是警报触发时,TradingView 往你填的网址发一条消息的功能。"接收端" 指的是你填在 Webhook URL 里的那个地址背后的东西,可能是一套现成的下单服务,也可能是别人帮你搭的一段程序。一条警报从图表走到成交要过四段:警报触发,TradingView 把请求发出去,接收端收到并读懂消息,接收端去下单。每一段出问题时,屏幕上看到的东西不一样。

两处日志对一遍

打开 TradingView 的警报日志,按信号出现的时间往回翻。日志里没有这一条,问题在警报触发这一段。有这一条,但 "Webhook状态" 一列报了错,问题在 TradingView 发请求这一段,或者接收端把请求挡了回去。这一列没报错,就去接收端的请求记录里找同一时间的那条:找不到,核对两边填的是不是同一个地址;找到了但提示消息格式不对,是解析这一段;消息读懂了却没有委托,是下单这一段。

图上有信号但警报日志里没有记录,先看触发频率、到期时间和重绘

图上那根 K 线看着满足条件了(箭头出来了,或者两条线交叉了),警报日志在那个时间却是空的,手机推送和邮件也没来。既然连通知都没有,就和 Webhook 没关系,是警报本身没触发。

找到这条警报,看它还在不在运行,然后点开编辑。

先看触发频率。TradingView 帮助中心的警报频率之间的差异一页列了四档(括号里是英文版页面上的叫法):

  • 只有一次(Once only):只触发一次。如果这条警报前面已经响过,后面的信号它不会再管。
  • 每个图表棒一次(Once per bar):每根 K 线最多触发一次。同一根 K 线里条件第二次满足,不会有第二条。
  • 每个图表棒收盘时一次(Once per bar close):要等这根 K 线收盘才触发。盘中看到条件满足,收盘前又不满足了,就不会响。
  • 每分钟一次或每次(Once per minute or every time):系统每分钟检查一次条件,满足就触发。

再看到期时间。帮助中心 "TradingView警报介绍" 一页里,标准警报的最长有效期是两个月,到期后自动停止;Premium 和 Ultimate 方案可以选无限期。另外,一条警报如果同时满足创建超过一年、超过一年没触发、超过一年没编辑这三条,会被自动停用。挂了很久的警报突然不响,先看它的到期日。

频率和到期都没问题,再看三件不那么显眼的事,都记在 Pine Script 文档的警报问答里:

  • 警报跑的是创建那一刻的设置。创建警报时,脚本、参数和图表环境会在服务器上存一份快照,之后你再改指标参数或换周期,已经建好的警报不跟着变。图上看到的是新参数画出来的信号,警报还在按旧参数算,两边自然对不上。改过参数就把警报删掉重建。
  • 三分钟内触发超过 15 次,系统会自动停掉后面的警报。行情剧烈时用触发最密的那一档要留意。
  • 脚本运行出错后,这个脚本上的警报就不会再触发。图表上这个指标如果显示运行错误,先处理它。

剩下的一种是重绘。历史 K 线上脚本只在收盘时算一次,实时 K 线上每来一笔新报价都会重算,所以盘中出现的信号到收盘时可能已经不成立,事后回看图表,箭头的位置和当时也可能不同。反过来,你事后在图上看到的箭头,当时未必真的出现过。重绘怎么来的、不看代码怎么验,写在 指标信号在实时行情里挪位置或消失 那篇里;放到警报上,省事的做法是把频率设成收盘时触发一次,代价是信号要等到这根 K 线走完。

警报触发了,Webhook 状态一列却报错:TradingView 发请求时的几条限制

警报日志里有这一条,手机通知也到了,只有 "Webhook状态" 一列显示错误。说明警报没问题,是往外发的这个请求出了事。

TradingView 帮助页如何配置webhook警报里列的限制:
· 账户要开启双重身份验证(两步验证),否则不允许使用 Webhook 警报。
· 地址只接受 80 和 443 两个端口,带其他端口号的 URL 会被拒绝。
· 对方服务器处理请求超过 3 秒,这次请求会被取消。
· 目前不支持 IPv6。
· 请求用 HTTP POST 发出,正文就是你写的警报消息。消息是合法 JSON 时,请求头的内容类型是 application/json,否则是 text/plain。
· 请求从帮助页列出的几个固定来源地址发出。
· 消息正文里不要放登录凭据或密码。

对着这几条,先排掉设置上的问题。编辑这条警报,在通知方式那里确认 Webhook URL 是勾上的,地址完整,没有多出空格。地址里如果带冒号加数字(比如 :8080 这种),端口就不是 80 或 443,需要让接收端换一个不带端口的地址。再确认 TradingView 账户已经开了两步验证。

设置没问题,就看状态列报的是哪一类错。帮助中心另有一页发送webhook时出现的错误是什么意思,把错误分了几类,可以这样用:

  • URL 不可用或无效、安全连接问题、对方拒绝或中断连接:请求没连上。查地址有没有拼错,是不是 https 开头,接收端的服务此刻是否在线。地址解析到本机或内网 IP 的同样发不出去,错误页把它单列成一类。
  • 超时:连上了,但对方 3 秒内没有回应。
  • 3xx:对方让请求转去另一个地址。查域名或路径是不是换过,有没有被转到登录页。
  • 4xx:请求送到了,对方不接受,原因在地址路径、授权、数据格式,或者超过了对方允许的请求次数。
  • 5xx:请求送到了,对方服务器处理时出了错,可能是它自己的故障,也可能是消息内容让它的程序出错。

后面三类有一个共同点:那个地址上有服务器回了话,连接是通的。3xx 要回 TradingView 把地址换成跳转后的那个;4xx、5xx 先到接收端那一侧看它为什么不收,查出来是地址、口令或消息格式的问题,再回 TradingView 改警报里填的内容。

这些限制和错误分类是 2026 年 10 月 TradingView 帮助中心中英文版与 Pine Script 文档上的内容,这些页面日后有改动的话以新版为准。

安排接收端的时候,建议按 "每条警报只发一次" 来打算:某一次没送到,靠你自己在警报日志里发现,然后手动处理那一笔。

接收端有没有收到请求、读不读得懂消息:请求记录、JSON 格式和时间戳

TradingView 这边没报错,或者报的是 4xx,接收端没有任何动作。

要看的是接收端的请求记录。用的是现成的下单服务,就在它的后台找列出已收到信号的那一页,名字各家不同,留意 "信号记录""请求日志" 这类入口;自己搭或者别人帮搭的程序,请维护的人查那个时间点的访问日志。拿警报日志里的触发时间去找同一时刻的那一条。

找不到这一条。把 TradingView 警报里填的 URL 和接收端给你的地址逐个字符对一遍,包括末尾的路径和问号后面的参数。接收端如果设了只放行指定来源 IP,确认帮助页列出的来源地址都在放行名单里。接收端的地址如果只有 IPv6,请求到不了。

找到了,但提示格式错误或无法解析。回到 TradingView,看警报的消息框。接收端要求消息是 JSON 的话,TradingView 是否把它当 JSON 发出去,取决于你写的内容本身合不合法。有一个现成的线索:接收端的记录里如果能看到请求头,内容类型是 text/plain 的话,说明 TradingView 判断这段消息不是合法 JSON。

不会写程序也能自己验:编辑警报,把消息框里的内容整段复制出来,贴进任意一个 JSON 校验工具。容易出错的地方有这几处:

  • 引号是中文输入法打出来的弯引号,JSON 只认半角直引号。
  • 最后一项后面多了一个逗号,或者中间少了一个逗号。
  • 占位符的位置。{{ticker}} 这类会被换成文字的,要放在引号里面;{{close}} 这类换成数字的可以不加。校验时先把占位符手动换成一个真实的值再贴进去,因为发出去的是替换之后的内容。

时间戳。建议在消息里加一个时间字段,用 {{timenow}}。帮助中心讲警报消息变量的那一页对这两个占位符的解释是:{{timenow}} 是警报触发的当前时间,{{time}} 是触发那根 K 线的时间,格式都是 UTC 的 yyyy-MM-ddTHH:mm:ssZ。有了这个字段,接收端记录里的每一条都能和警报日志一一对上,还能看出请求在路上花了多久。对时间的时候记得换算时区,北京时间比 UTC 快 8 小时。

顺带一条和安全有关的:接收端如果要靠一段口令来确认请求是你发的,用它专门生成的那段口令,不要把交易账户的登录密码写进消息里。

消息读懂了却没有委托单:在接收端的执行记录里核对品种、方向和数量

到这一段,要查的东西全在接收端和交易账户里。这时接收端的请求记录里有这一条,也没提示格式错误,但交易账户的委托历史里找不到对应的单子。

看两个地方。接收端的执行记录(有的叫订单日志或运行日志)里,这条信号后面写的处理结果和拒绝原因;以及你交易账户的委托历史,按同一时间找有没有一笔被拒绝或被撤销的委托。前者有拒绝原因而后者什么都没有,是接收端自己没往外发;两边都有,是发出去之后被交易的那一方退了回来。

拒绝原因看不明白的话,拿接收端收到的那条消息,对着它的说明文档核三样:

  • 品种名。{{ticker}} 给出的是图表上的代码,像 AAPL、BTCUSD 这种写法。接收端认的品种写法如果和图表不一样,就要在消息里直接写它要的那个名字,不用占位符。
  • 方向。策略警报里的 {{strategy.order.action}} 返回的是 buy 或 sell 这两个词。接收端要求的如果是别的词或者大小写不同,它读得出这是一条消息,却不知道该做什么。
  • 数量。消息里的数量是固定值还是占位符换出来的,换出来之后是多少,在接收端的记录里看实际收到的数字,再和账户里的可用余额、该品种的最小下单量比。

还有一种情况会让两边的日志互相矛盾:警报日志的 Webhook 状态写着超时,接收端却有这条请求,甚至已经下了单。TradingView 只等 3 秒,接收端如果是把单子下完才回应,多花的时间就可能超过这个数。请求虽然在 TradingView 这边记成了超时,接收端那边的处理未必停下。所以看到超时别直接手动补单,去接收端和交易账户里确认这一笔到底做了没有,免得同一个信号下两次。碰到这种情况,可以问接收端的提供方能不能改成收到就回应、随后再处理。

接着读:接收端本身是一段长期运行的程序,它掉线、被限频、参数过时的时候各是什么样子,在 交易机器人不下单、报错怎么办:九类故障先查什么 里;警报里带出来的价格和实际成交价对不上,可以对照 行情价为什么各家不一样 去查两边各自用的是哪个行情来源。