阅读时间 … 分钟

TradingView Webhook 对接您的经纪商 API

使用 Claude 或 ChatGPT 编写 Pine Script 策略，在 TradingView 的策略测试器中进行验证，然后通过 Webhook 将警报路由至云端运行环境，直接调用经纪商的 REST API。无需 MetaTrader 终端，无需 Windows VPS。

TradingView 警报可以向您控制的任何 HTTPS URL 发送 POST 请求并携带 JSON 主体。TradingHost 将该 URL 托管为全天候运行的容器，解析数据并向经纪商提交订单。原生兼容各类经纪商：无论是外汇和差价合约（CFD）经纪商、股票和期货经纪商，还是加密货币交易所，只要其提供公开的 REST 或 WebSocket API，工作原理完全相同。

延迟预期：TradingView 的服务端警报在 K 线收盘后约 1 至 3 秒内触发，随后经纪商的 REST 端点完成订单确认（通常为 100 至 500 毫秒）。端到端往返时间为几秒，而非几毫秒。该工作流适用于波段交易、趋势持仓和慢速日内策略，不适用于高频剥头皮（scalping）、延迟套利或分钟级以下的超短线执行。

章节 01 · 工作原理

四个环节，一个闭环

整个工作流由四个工具协同运行，各司其职。TradingView 决定交易时机；GitHub 存储接收端代码；TradingHost 在云端运行该代码并托管 Webhook URL；经纪商执行订单。只要理清了每个工具的作用，其余部分的内容您只需粗略浏览即可。

  • 您的图表与信号源

    TradingView

    托管您的 Pine Script 策略，运行策略测试器，并在达到入场或出场条件时触发警报。警报可以通过 POST 请求将 JSON 负载发送至 Webhook URL。

  • 您的接收端代码

    GitHub

    存储轻量级接收端服务，用于解析 TradingView 负载并调用经纪商的 REST API。支持版本控制，可设为私有仓库。

  • 您的云端运行环境

    TradingHost

    从 GitHub 拉取接收端代码，构建容器，并暴露一个稳定的 HTTPS Webhook URL 供 TradingView 发送 POST 请求。全天候在线，无需保持本地电脑开机。

  • 您的执行场所

    经纪商 API

    通过经纪商的 REST API 接收来自 TradingHost 容器的订单。兼容各类经纪商：任何提供公开 REST 或 WebSocket API 的经纪商或交易所均适用。

从零开始部署实盘信号

  1. 在 TradingView 上编写 Pine Script 策略，可使用 Claude 或 ChatGPT 进行结对编程。
  2. 在将策略投入实盘前，先在 TradingView 的策略测试器中进行回测。
  3. 将 TradingHost Webhook 接收端模板 Fork 到您的 GitHub 账户中，并针对您的经纪商进行定制。
  4. 将 TradingHost 运行环境指向该仓库并选择部署区域，运行环境将暴露一个公开的 Webhook URL。
  5. 在该策略上创建 TradingView 警报，粘贴 Webhook URL，并将消息主体设置为包含 strategy.order 占位符的 JSON。
  6. 当警报触发时，TradingView 会向 TradingHost 发送 POST 请求，您的容器解析该负载，并通过调用经纪商 API 进行下单。

往返耗时：TradingView 的服务端警报在 K 线收盘后 1 至 3 秒内触发，经纪商的 REST 端点通常在 100 至 500 毫秒内确认订单。端到端耗时在个位数秒级，而非毫秒级。这对于波段交易和慢速日内策略已经足够，但不适合剥头皮或延迟套利。

章节 02 · 一览

一览

工作流
TradingView Pine Script 警报 → 云端 Webhook 接收端 → 经纪商 REST API
Pine Script 版本
Pine Script v6（当前 TradingView 语言版本）
警报传输方式
向用户提供的 Webhook URL 发送 HTTPS POST 请求
允许的端口
TradingView 仅向端口 80 和 443 发送数据；其他端口将被拒绝
响应超时
接收端必须在 3 秒内响应，否则请求将被取消
负载格式
警报消息的主体；当主体为有效 JSON 时，将以 application/json 格式发送
策略占位符
{{strategy.order.action}}、{{strategy.order.contracts}}、{{ticker}}、{{close}} 等
所需方案级别
TradingView Plus、Premium 或 Ultimate（Essential 和免费版不包含 Webhook）
账户要求
必须在 TradingView 账户上启用双重身份验证
接收端运行环境
在 TradingHost 上运行的容器化常驻服务，从 GitHub 部署
编程语言
任何可以在容器中运行轻量级 HTTP 服务器的语言（Python、Node、Go、Rust 等）
券商支持
兼容任何券商：任何提供公开 REST 或 WebSocket API 文档的券商或交易所（外汇、CFD、股票、期货、加密货币）
示例券商
使用 OANDA v20 REST API 作为接收端到券商调用的简明、低维护性示例；本页面并非专门针对 OANDA
TradingHost 职责
运行环境、部署、日志、健康检查、区域选择、加密的券商凭据
TradingView 职责
图表绘制、Pine Script 执行、警报生成、Webhook 发送
隶属关系
TradingHost 保持独立，与 TradingView、PineConnector、OANDA 或任何其他提及的服务均无隶属关系

第 03 节 · 使用 AI 编写 Pine Script

与 Claude 或 ChatGPT 结对编写策略

Pine Script 是一种轻量且文档完善的语言，当前这一代大语言模型都已学习过 TradingView 公开的 Pine Script v6 参考文档。在 Claude、ChatGPT（或在以这些模型为后盾的 Cursor）中用通俗的语言描述你的策略：监控什么指标、什么触发做多、什么触发做空、如何确定订单大小以及何时平仓。将生成的代码粘贴到 TradingView 的 Pine 编辑器中，让编辑器标记出语法问题。

有两点需要向模型明确说明。首先，要求生成 Pine Script 策略脚本（它必须声明 strategy() 而不是 indicator()），因为只有策略才会提供你在 Webhook 主体中所需的 {{strategy.order.action}} 和 {{strategy.order.contracts}} 占位符。其次，要求模型使用 strategy.entry() 触发入场，使用 strategy.close() 出场，并使用 alert() 函数而不是 alertcondition() 来编写任何即时通知；现代的 alert() 函数提供相同的策略占位符，并接受一个控制警报是在每个 Tick、每个 K 线还是每个 K 线收盘时触发的 freq 参数。

仔细阅读模型编写的每一行代码。交易代码对订单大小、持仓状态和 K 线内行为等方面的细微 Bug 是零容忍的。在接受任何不明显的计算逻辑之前，先让模型进行解释。如果你想要更深入的 AI-IDE 工作流（在同一个编辑器中同时处理 Pine 和 Python 或 Go 接收端），Cursor 工作流页面涵盖了该循环中 IDE 侧的内容。

第 04 节 · 实盘前进行回测

在配置 Webhook 之前运行策略测试器

TradingView 的策略测试器会在图表的可用历史数据上运行你的 Pine Script 策略，报告净利润、利润因子、回撤、胜率以及完整的模拟交易列表。“绩效摘要”、“交易列表”和“属性”标签页提供的信息足以让你决定该策略是否值得对接真实券商。

请在创建任何带有 Webhook URL 的 TradingView 警报之前完成此步骤。在未经验证的策略上运行实盘 Webhook 是发现 Bug 代价最高昂的方式。

第 05 节 · 警报与 Webhook

配置 TradingView 警报和 Webhook URL

在图表上打开“创建警报”对话框，选择该策略作为条件，然后切换到“通知”标签页并勾选“Webhook URL”。将 TradingHost 的 Webhook 终端地址粘贴为 URL。你在“消息”字段中输入的主体就是 TradingView 在警报触发时向该 URL 发送 POST 请求的内容。

将“消息”编写为 JSON 格式。TradingView 会自动检测有效的 JSON 并将请求的 Content-Type 设置为 application/json，这正是你的接收端所期望的。一个最简策略警报主体包含交易标的（ticker）、方向（来自 {{strategy.order.action}}）、大小（来自 {{strategy.order.contracts}}），以及一个在接收端将任何内容转发给券商前进行验证的共享密钥。

TradingView 官方说明的传输规则

请求方法
HTTP POST。警报消息主体将作为请求体发送。
端口
仅限端口 80 和 443。包含任何其他明确端口的 Webhook URL 将被拒绝。
Content-Type
当警报消息主体为有效 JSON 时为 application/json。否则为纯文本。
超时时间
3 秒。如果接收端在此窗口期内未响应，请求将被取消。
源 IP 地址
TradingView 在警报配置页面上公布了其外发 Webhook 的 IP 地址。请在您的防火墙或 Webhook 接收端中将这些 IP 加入白名单。
账户
Webhook 警报要求 TradingView 账户启用双重身份验证。
订阅方案
Webhook 警报仅限 Plus、Premium 和 Ultimate 方案使用。Essential 和免费版方案不包含 Webhook 推送功能。

警报消息占位符

{{ticker}}
触发警报时图表上显示的交易对或代码。
{{exchange}}
交易所代码（如适用）。
{{close}}
触发警报的 K 线收盘价。
{{volume}}
触发警报的 K 线成交量。
{{time}}
K 线开盘时间（UTC 时间）。
{{strategy.order.action}}
返回触发策略订单的 "buy" 或 "sell"。仅适用于策略警报。
{{strategy.order.contracts}}
已执行订单的合约数或单位数。仅适用于策略警报。
{{strategy.order.price}}
策略报告的成交价格。仅适用于策略警报。
{{strategy.order.id}}
策略分配给订单的标识符。仅适用于策略警报。
{{strategy.order.comment}}
策略附加到订单的可选注释字符串。

Pine Script 有一个值得注意的细节：指标脚本（indicator）可以通过 alertcondition() 或 alert() 触发警报，但只有策略脚本（strategy）才支持 {{strategy.*}} 占位符。如果您希望 Webhook 消息体携带交易的方向和仓位大小，脚本必须声明为 strategy()，而不是 indicator()。

章节 06 · 在 TradingHost 上接收

在运行环境中托管 Webhook URL，而不是在您的笔记本电脑上

只要市场开盘，TradingView 发送请求的 Webhook URL 就必须保持在线。笔记本电脑显然不合适；网络不稳定的台式机也不合适；通用的 Windows VPS 虽然可行，但前提是您必须记得定期更新补丁并保持相关终端一直运行。

TradingHost 为您提供一个基于 Kubernetes 的 Linux 容器，该容器直接从 GitHub 仓库运行，并暴露一个稳定的 HTTPS 端点。您的接收端代码可以自由选择（例如 Python FastAPI 处理器、Node Express 路由或 Go net/http 服务器），只要它在 443 端口上提供 HTTP 服务，并在 TradingView 的 3 秒超时限制内做出响应即可。当您将代码推送到 GitHub 时，TradingHost 会重新构建容器并重新部署，而 Webhook URL 保持不变。

券商的 API 凭据作为加密密钥（Secrets）保存在运行环境中，而不是保存在您的 GitHub 仓库中。您在 TradingView 消息体中设置的共享密钥（Shared Secret）也同样保存在这里。您的接收端会在每次收到请求时验证该共享密钥，然后从环境变量中读取券商凭据并调用券商 API。

日志会实时流式传输，以便您按顺序查看：TradingView 已发送请求、载荷已解析、订单已提交、券商已确认。如果发生任何失败，日志行会明确指出问题所在。

章节 07 · 在券商端执行

任何提供 API 的券商；接收端架构保持一致

TradingHost 兼容任何券商。TradingHost 容器并不关心其调用的 REST 端点背后是哪家券商；无论目标是外汇经纪商、股票券商、期货券商还是加密货币交易所，相同的接收端架构都适用。不同之处仅在于券商所要求的身份验证机制、交易标的代码格式以及订单类型定义。其他一切保持不变。

此工作流支持的券商类别

外汇与差价合约 (CFD)
拥有 v20 风格 REST API 及类似接口的经纪商（OANDA、IG、Switch Markets 以及 外汇与差价合约经纪商 页面上的其他经纪商）。
股票与期货
拥有 REST 或 FIX 网关的券商（Interactive Brokers 以及 股票与期货券商 页面上的其他券商）。
加密货币交易所
提供 REST 和 WebSocket 接口的现货及衍生品交易平台（Binance、Bybit、OKX、Coinbase、Kraken 以及 加密货币交易所 页面上的 60 多家其他平台，主要通过 CCXT 对接）。
其他任何平台
任何提供公开 HTTP 下单接口的券商。下方的接收端模式完全相同。

接收端在每次收到 Webhook 请求时的执行流程

  1. 在转发任何请求之前，先验证 TradingView 警报主体中的共享密钥。
  2. 将 TradingView 的交易代码（ticker）映射为经纪商的交易标的代码（大多数经纪商的命名规则略有不同）。
  3. 构建订单请求，将交易方向（买/卖）编码在数量的正负号中，指定市价单类型，并使用经纪商推荐的生效时限（time-in-force）。
  4. 发送请求时带上经纪商的身份验证请求头（根据经纪商的不同，可以是 Bearer 令牌、HMAC 签名载荷或 OAuth）。
  5. 记录响应，暴露错误，并在 3 秒超时限制内向 TradingView 快速返回 200 OK。

简要示例：OANDA v20

OANDA 是一个维护成本极低的示例，因为其 v20 REST API 文档在 developer.oanda.com 上非常完整，且免费的模拟账户很容易开设。其调用结构为：在 Authorization 请求头中携带 Bearer 个人访问令牌，向 /v3/accounts/{accountID}/orders 发送包含市价单主体的 POST 请求；实盘对接 api-fxtrade.oanda.com，模拟盘对接 api-fxpractice.oanda.com。这只是众多经纪商中的一个；Interactive Brokers、Binance、OKX 或 Switch Markets 的接收端代码也遵循相同的模式，只需替换为对应经纪商的验证机制和端点即可。/brokers/ 页面涵盖了各个经纪商的具体细节。

章节 07.5 · 运维安全

实盘交易中容易踩到的坑

TradingView 的警报推送是尽力而为（best-effort）的。Webhook 可能会丢失、重复或延迟。经纪商 API 可能会返回重试响应，看起来就像一个新订单。Pine Script 的 Bug 可能会导致生成远超策略预期风险的持仓规模。接收端就是你系安全带的地方。以下是六个安全护栏，每个护栏都是一小段接收端代码，用于防止策略上线后无法挽回的故障模式。

  1. 01 · 接收端停机

    如果警报触发时接收端处于停机状态会怎样？

    默认情况下，TradingView 不会对失败的 Webhook 推送进行排队或重试。如果接收端返回非 2xx 响应，或者响应时间超过 3 秒，警报就会被丢弃。虽然策略会在后续的 K 线上继续触发警报，但错过的信号已经无法恢复。安全护栏：保持接收端尽可能简单，确保其始终在超时限制内响应；在执行任何操作之前，先将每个传入的载荷记录到磁盘，以便在运行日志中查看错过的订单；同时监控运行时的在线状态，以便了解信号触发时接收端是否处于不可达状态。

  2. 02 · 重复警报

    TradingView 可能会多次触发同一个警报

    在实时 K 线内部，Pine Script 的值在每个 Tick 上都会更新。设置为“每个 Tick”的 alertcondition 或 alert 调用可能会针对同一个逻辑信号触发多次。即使设置了“每次 K线收盘时一次”，TradingView 的重试机制偶尔也会连续发送两次相同的载荷。安全护栏：在警报主体中包含一个稳定的标识符（K 线时间、策略生成的订单 ID 或载荷的哈希值），并拒绝接收端在过去几分钟内已经处理过的任何传入载荷。将该去重键（dedupe key）保存在内存或运行时内部的小型键值存储中。

  3. 03 · 订单幂等性

    设计好每一次经纪商调用，确保重试不会创建重复的持仓

    大多数经纪商的 REST API 都接受幂等键（idempotency key），这是由客户端提供的订单 ID，经纪商用它来对多次重试中的相同提交进行去重。在接收端提交的每个订单上都设置此键。使用与警报去重相同的标识符（K 线时间或策略生成的订单 ID），以便接收端、TradingView 和经纪商在逻辑订单的对应上保持一致。如果不设置，由瞬时网络波动触发的重试可能会导致重复成交。

  4. 04 · 持仓规模保护

    限制对 {{strategy.order.contracts}} 传入数值的信任上限

    Pine Script 的 strategy.order.contracts 占位符会报告策略认为其正在交易的规模。策略逻辑中的 Bug、配置错误的持仓规模或死循环可能会产生远超账户承受能力的 contracts 数值。安全护栏：在接收端（与策略分离）硬编码一个最大规模限制，并拒绝任何 contracts 数值超过该限制的订单。接收端是防范 Pine Bug 导致爆仓的最后防线。

  5. 05 · 凭据隔离

    每个策略使用一个限制权限的 API 密钥，绝不使用主密钥

    如果经纪商 API 密钥因环境配置错误、日志泄露或构建产物而泄露，其受灾范围将取决于该密钥拥有的权限。为每个策略使用独立的经纪商 API 密钥，且仅授予该策略所需的权限（允许交易，禁止提现），并将其存储在 TradingHost 的机密存储（secrets store）中，而不是写在代码里。一旦发生任何安全事件，请立即轮换密钥。

  6. 06 · 实盘前先进行模拟交易

    在加大资金规模前，先在模拟账户上运行该流程一周

    大多数经纪商都提供模拟交易或沙盒环境，它们接受与实盘账户相同的 API 调用。先将接收端指向沙盒环境，让策略运行一周真实的 TradingView 警报，并验证每个信号是否都转化为了预期的模拟订单。实盘资金绝不是用来发现 {{strategy.order.action}} 编码为 "buy" 而非 "long" 会触发枚举检查错误的地方。

章节 08 · 对比 PineConnector + MT4/MT5

为什么通过云端运行时路由 Webhook，而不是通过 MetaTrader EA

目前从 TradingView 警报到真实订单最常用的路径是通过 PineConnector，这是一个第三方桥接工具，可将警报转发到 MetaTrader 4 或 MetaTrader 5 终端内的 Expert Advisor (EA)。EA 通过 MetaTrader 提交订单，因此终端必须在 Windows 机器上持续运行。TradingHost 完全省去了这一环节：Webhook 直接到达容器，容器调用经纪商的 REST API。这里没有 MetaTrader 终端，没有 MQL Expert Advisor，以 GitHub 作为单一事实来源，并且是在托管区域运行的 Linux 容器，而不是需要保持唤醒状态的 Windows 桌面。

对比

维度PineConnector + MT4/MT5TradingHost
执行路径TradingView Webhook 发送到在 MetaTrader 4 或 MetaTrader 5 终端内运行的 PineConnector EA，然后由 EA 通过 MetaTrader 将订单发送给经纪商。TradingView Webhook 发送到 TradingHost 云端容器，然后容器直接调用经纪商的 REST API。路径中无需 MetaTrader 终端。
所需平台必须安装、登录并运行 MetaTrader 4 或 MetaTrader 5，且需启用“自动交易”（AutoTrading）。无需交易终端。策略代码在 TradingHost 托管的 Linux 容器内运行。
托管主机需要一台 24/7 保持在线的 Windows 机器。PineConnector 的文档对此进行了说明，并明确指出 MetaQuotes VPS 不兼容；他们的建议是使用 PineConnector Cloud 或兼容的 Windows VPS。TradingHost 位于您所选区域（EU 或 US-East）的托管 Kubernetes 运行环境。无需 Windows 桌面或 VPS。
支持的经纪商任何提供 MetaTrader 4 或 MetaTrader 5 账户的经纪商，通过 MetaTrader 终端执行。TradingHost 支持的任何具有公开 REST 或 WebSocket API 的经纪商，包括 OANDA、IG、Switch Markets、Interactive Brokers、Binance、Bybit、OKX、Coinbase、Kraken 等。
编程语言EA 内部的 MQL4 或 MQL5（MetaTrader 的脚本语言）。自定义需要修改 EA。任何可在容器中运行的语言：Python、Node、Go、Rust 等。
单一可信源PineConnector 授权以及在 MetaTrader 中运行的 EA。配置保存在本地机器上。GitHub 仓库。推送即部署；日志、回滚和历史记录均进行版本控制。
凭证存储经纪商凭证保存在 Windows VPS 上的 MetaTrader 终端内。绑定到运行时的加密机密，绝不存放在 GitHub 仓库或策略代码中。
运维工作需管理 Windows VPS、MetaTrader 终端、PineConnector EA 授权、经纪商连接以及 TradingView 警报。仅需管理 GitHub 仓库、TradingHost 运行时、经纪商凭证和 TradingView 警报。无需管理桌面操作系统。

如果您明确希望继续使用 MetaTrader、您的经纪商仅支持 MT，或者您完全不想编写任何代码，请选择 PineConnector。如果您希望直接访问经纪商的 REST API（无需 MetaTrader 作为中间件）、希望使用通用编程语言编写策略、希望将 GitHub 作为单一可信源，并彻底告别 Windows VPS，请选择 TradingHost。

第 10 部分 · 常见问题

常见问题解答

是的。TradingView 仅在 Plus、Premium 和 Ultimate 方案中提供 Webhook 警报功能。Essential 和免费版层级不包含 Webhook URL 通知方式。

TradingView 会向您配置的 Webhook URL 发送一个 HTTP POST 请求。请求体为您在警报“消息”（Message）字段中输入的任何内容。如果该请求体能成功解析为有效的 JSON，TradingView 会将 Content-Type 设置为 application/json；否则请求将作为纯文本发送。

TradingView 并未说明任何重试策略或正式的送达保证。其文档中明确的传输规则为：仅支持 80 和 443 端口，且在请求被取消前有 3 秒的响应窗口。请将 Webhook 送达视为“尽力而为”（best-effort）的服务，并在设计接收端时确保其具备幂等性。

可以。TradingView 在警报配置界面上公布了其发送 Webhook 的源 IP 地址列表。除了在消息体中加入共享密钥外，一些接收端还会拒绝来自该列表之外的任何请求，以此作为额外的安全防御。

Pine Script v6，即当前的语言版本。TradingView 已声明未来的更新将仅应用于 v6。

只有策略脚本才会提供您在 JSON 请求体中需要使用的 {{strategy.order.action}}、{{strategy.order.contracts}}、{{strategy.order.price}} 及类似占位符。指标脚本虽然仍可通过 alert() 或 alertcondition() 触发警报，但其警报消息无法引用 strategy.* 占位符。

alertcondition() 是较早的原始函数，仅适用于指标；其触发频率由用户在“创建警报”对话框中手动选择。alert() 是较新的函数，同时适用于指标和策略，可以置于局部作用域中，并直接在代码中接收 freq 参数（如 alert.freq_all、alert.freq_once_per_bar、alert.freq_once_per_bar_close）。

对于实盘交易，建议首选“每根 K 线收盘一次”。在实时 K 线生成期间，Pine 的数值可能会随着每次 Tick 变动而更新，并且可能与收盘时的数值不同，这可能会导致触发一个在 K 线最终确定后又消失的入场信号。而“每根 K 线收盘一次”仅在 K 线确认后才会触发。

PineConnector 将 TradingView Webhook 转发给在 MetaTrader 4 或 MetaTrader 5 终端内运行的 Expert Advisor (EA)。PineConnector 官方文档指出，终端必须持续运行，MetaQuotes VPS 不兼容，且需要 Windows VPS 进行托管。TradingHost 则用直接调用经纪商 REST API 的 Linux 容器取代了 MetaTrader 环节。有关运行时差异，请参阅 Windows VPS 对比。

任何具有公开 REST 或 WebSocket 下单接口的经纪商。TradingHost 独立于具体经纪商：外汇和 CFD 经纪商（OANDA、IG、Switch Markets 等）、股票和期货经纪商（Interactive Brokers 等）以及加密货币交易所（Binance、Bybit、OKX、Coinbase、Kraken 等）。有关支持的交易场所，请参阅 经纪商列表。

仅有经纪商特定的部分会有所不同：身份验证请求头（Bearer 令牌、HMAC 签名载荷、OAuth）、交易标的代码体系以及订单类型定义。整体架构（验证密钥、映射代码、构建订单、发送、记录日志）是完全相同的。对于加密货币交易场所， CCXT 已经抽象并屏蔽了绝大部分差异。

加密机密（Secrets）绑定在 TradingHost 运行时中，而不是存放在 GitHub 仓库里。您的接收端会在收到请求时从环境变量中读取它们。有关凭证处理模型的详细信息，请参阅 平台机密 页面。

TradingView、您的经纪商和 TradingHost 分别独立计费。TradingHost 的运行时方案列于 价格 页面。您无需再为 Windows VPS、MetaTrader 托管服务以及单独的 Webhook 桥接授权付费。