TradingView Webhook 延迟有多严重？
官方规格、常见原因与能修复的地方

你设置了 TradingView alert 自动交易，结果信号来得比想象慢很多——有时候是几秒， 有时候感觉像过了好几分钟。先说结论：你感受到的「延迟」，十次有八次不是 TradingView 端真的慢，而是三件事之一——(1) 你自己选的触发频率设置本来就要等、 (2) 你的接收服务器响应太慢被判定超时、(3) 你的方案根本没有 webhook 功能。

先诚实说在最前面：TradingView 官方从未公开承诺过 webhook 的送达时间，也没有 SLA（服务水平协议）。这篇不会编一个「平均延迟 XX 秒」的数字给你，而是把官方文档 里真正写明的规格、方案限制、社区反馈，以及哪些延迟你能自己修、哪些是架构上修不了的， 诚实拆开来讲。

先破解最大的误会：「Once Per Bar Close」不是慢，是故意等

官方文档对触发频率的定义很清楚：Once per bar 是「每根 K 线都检查， 条件符合就触发，同一根最多一次，不等收盘」；Once per bar close 则是「同样逻辑，但一定要等 K 线收盘才触发」。这两个字的差异，决定了你的信号会不会 「感觉慢」。

再加一个容易被忽略的区分：以上是「Create Alert」对话框 UI 的 Frequency 选项， 适用于 price／technical／alertcondition() alert。但 Pine alert() 函数的 freq 参数只有三个值：alert.freq_once_per_bar（默认）、alert.freq_once_per_bar_close、alert.freq_all—— 没有「Once Only」也没有「Once per minute」这两个选项，很多教程文章会混用。

另外，strategy 默认在 K 线收盘才重新计算：除非你在代码里开启 calc_on_every_tick = true，否则 alert() 就算填了 alert.freq_all，实际上也只会在收盘时触发一次。这是很多人以为「实时策略 结果却等收盘」的真正原因。

官方到底承诺了什么延迟？

查遍 TradingView 官方帮助中心、Pine Script 文档与状态页，都没有找到 任何对「webhook 延迟」或「送达时间」的量化承诺或 SLA。官方文档里真正写明、跟时间 有关的规格，其实是下面这几个「接收端」规格，而不是「TradingView 内部处理耗时」：

换句话说，官方明确承诺的是「你的服务器要多快响应」，而不是「TradingView 自己从条件成立到发出 webhook 要多快」。后者完全没有 公开数字可查。

你的方案本身可能就没有 webhook

在怀疑延迟之前，先确认一件更根本的事：免费 Basic 方案完全不支持 webhook 通知，这在 pricing 页的对比表里是叉号，不是「比较慢」，是根本没有。

哪些延迟你能自己修，哪些修不了

把上面官方规格和常见坑整理成一张表，分成「你能动手改」跟「架构上修不了、只能绕道」：

接收端（你的服务器）也会拖慢——这是我们的做法

前面说「3 秒没响应就取消、不重试」，这条规则常被低估。如果你的接收服务器在同一个 请求里做完「验证信号 → 调用交易所 API 下单 → 等成交响应」整套流程，很容易在真实 交易环境下超过 3 秒，导致这笔信号直接被 TradingView 判定失败丢弃，而且不会重试——你可能完全不知道自己漏接了一笔信号。

TVSBot 的做法是先收到 webhook 就立刻响应，实际下单逻辑丢到后台异步处理，避免撞到 TradingView 这条 3 秒超时规则。我们自己的 FAQ 页对这段「收到信号到实际下单」的 延迟写的是：目标 P95 落在 500ms 以内，实际延迟一般加总在 1-3 秒内——这是我们自己文档上的目标值与一般经验值，不是有公开方法论、逐笔测量的实测报告， 写在这里是想诚实说明「接收端能做到什么程度」，而不是包装成精确 benchmark。

想更完整了解怎么把 webhook 接起来、payload 要带哪些字段，可以看 TradingView Webhook 完整教程这篇；如果你的下单金额跟预期对不上，很可能是另一个常见坑，可以看 qty_type 语义陷阱那篇。

来源验证：IP 白名单 vs SSL 证书

官方目前公布的 webhook 来源 IP 列表（截至 2026 年 7 月查证）是：

52.89.214.238
34.212.75.30
54.218.53.128
52.32.178.7

但官方文档并没有承诺这份列表永久不变。更稳妥的做法是验证 TradingView 发请求时附带的 SSL 证书（CN = webhook-server@tradingview.com），这是官方自己提供、 比单纯 IP 白名单更可靠的验证方式。

诊断你的 alert 为什么「感觉很慢」

上线前检查清单

• 确认方案支持 webhook（Essential 以上），免费 Basic 完全没有
• 触发频率选对：要实时用 Once per bar，要等收盘确认用 Once per bar close
• 服务器收到请求先立刻回 200，绝不在 3 秒内做完整套下单流程
• 用 SSL 证书或至少 IP 白名单验证请求真的来自 TradingView
• 改了 Pine 代码记得删除旧 alert 重建，而不是以为会自动更新
• 定期检查 Alert Manager 有没有红色「Stopped — Expired」