TradingView Webhook 沒反應？
完整除錯流程圖，一層一層查

Alert 設好了，圖表上條件明明滿足，結果下游什麼反應都沒有——或是有反應，但交易所沒有真的下單。TradingView webhook 沒反應這件事可能卡在五個不同的層次，亂猜是哪一層只會浪費你好幾個小時。

這篇文章是一套分層診斷流程：方案資不資格、Alert 到底有沒有觸發、TradingView 有沒有真的送出去、你的伺服器有沒有真的收到、 交易所有沒有真的接受下單。從最上面開始一層一層查——大部分人其實卡在第 0 層或第 1 層，只是自己還不知道。

五層診斷流程

從上到下照著走，每一步都會告訴你要繼續往下查，還是問題已經找到了。

第 0 層——這個 alert 本身有沒有資格送 webhook？

在動你的伺服器或 Pine 腳本之前，先確認這個 alert 在結構上根本就有能力送 webhook。這裡有兩道獨立的關卡， 任何一道卡住都足以解釋「怎麼設都沒反應」。

方案資格

Webhook 通知功能是依訂閱方案分級的。免費的 Basic 方案完全沒有 webhook 通知功能——不是被限制，是這功能本身就不存在於這個方案裡。 截至 2026 年 7 月查證，TradingView 的方案比較表如下：

Alert 到期與休眠機制

Alert 不是永久有效的。預設最長存活期限是兩個月；Premium 和 Ultimate 方案可以開啟「不過期」選項讓 alert 永久存活。 過期的 alert 會在 Alert Manager 顯示紅色Stopped — Expired狀態，之後就不會再觸發——你只能刪除重建。

還有一條獨立的規則值得知道：如果同時符合以下三個條件，alert 會被自動停用——建立超過一年、超過一年沒觸發過、而且超過一年沒被編輯過。如果你的 alert 已經放著很久沒動過，在懷疑是技術問題之前先檢查這一點。

• 已確認方案是 Essential 以上（Basic 沒有 webhook 通知功能）
• 已檢查 Alert Manager，狀態是綠色 Active，不是紅色 Stopped — Expired
• TradingView 帳號已開啟 2FA
• 如果 alert 已建立超過一年，已確認沒有因為一年沒動而被自動停用

第 1 層——Alert 到底有沒有真的觸發？

這一層最容易搞混，因為 TradingView 有兩套完全不同的觸發頻率系統，很多人會誤把兩者當成同一件事： Alert 建立對話框裡的Frequency下拉選單，跟 Pine alert() 函式的 freq 參數。這兩者的選項並不相同。

如果你的 Pine 腳本用的是 alert() 函式，觸發頻率是在程式碼裡決定的，只有三個可能值。 沒有辦法讓 alert() 呼叫表現得像「Once only」或「Once per minute」——這兩個選項只存在於 UI 設定、以 alertcondition() 為基礎的 indicator alert。把這兩套心智模型搞混， 是「webhook 應該要觸發卻沒觸發」最常見的原因之一。

Repainting 會讓一個正常運作的 alert 看起來像壞掉

依賴當前 K 棒 high/low/close、或跨週期抓資料的腳本，在即時 K 棒還在形成時數值可能會浮動。 如果你的 Frequency 沒設成Once Per Bar Close,alert 可能會在一個之後會變動的數值上觸發， 結果看起來像誤觸發，或是像「應該觸發卻沒觸發」但其實跟你事後看到的畫面對不上。 把 Frequency 設成 Once Per Bar Close 是這類問題的標準解法。

Strategy alert 有自己的規則

如果 alert 是掛在 strategy 而不是 indicator 上，還有幾條額外規則。Strategy 預設只在 K 棒收盤時才重新計算—— 所以就算 alert() 在 strategy 裡填 alert.freq_all 或 alert.freq_once_per_bar，實際上也只會在收盤時觸發一次，除非你明確開啟 calc_on_every_tick = true。另外，strategy 的下單觸發 alert 只會在即時成交時通知—— 歷史 K 棒上原本會成交的單子完全不會產生通知，所以只用歷史資料測試，永遠看不到即時 alert 觸發的畫面。

還有一個容易犯的錯：alertcondition() 只能在 indicator 裡用。放進 strategy 一樣能編譯過， 但完全不會有任何效果，也不會報錯告訴你原因。

• Alert Manager 的觸發紀錄裡至少有一次過去的觸發
• Frequency 設定符合你真正想要的行為（Once per bar vs. Once per bar close vs. Once per minute）
• 如果程式碼裡用 alert()，已確認 freq 值是三個合法選項之一
• 如果是 strategy alert，已確認 calc_on_every_tick 的設定符合你想要的觸發時機
• 已用 Once Per Bar Close 排除 repainting 的可能性

第 2 層——Request 有沒有真的離開 TradingView 的伺服器？

如果 Alert Manager 確認 alert 有觸發，下一個問題是 TradingView 有沒有成功把 webhook request 送出去。 URL 和 payload 有幾個嚴格的技術規格要求：

送達機制不是大家常以為的那樣「全部都會重試」。如果你的伺服器回5xx錯誤， TradingView 會在 5 秒後重送，最多重送 3 次（總共最多送 4 次）。但4xx回應或逾時， 會被視為已送達直接丟棄——這兩種情況都不會自動重試。另外還有一條硬性頻率限制： 同一個 alert 在 3 分鐘內觸發超過 15 次，系統會自動停用它。

• Webhook URL 用的是 port 80 或 443（沒用自訂 port）
• URL 是 HTTPS 且憑證有效
• URL 指向公開的 IPv4 主機名稱，不是 IPv6
• Alert 訊息在對應的大小上限內（4,000 或 40,960 字元）
• 沒有不小心在 3 分鐘內觸發超過 15 次

第 3 層——你的伺服器有沒有真的收到？

大部分真正的「webhook 沒反應」案例其實卡在這裡：alert 觸發了、TradingView 送出了 request， 但這個 request 從來沒有抵達你的應用程式。這裡有兩個 TradingView 端的限制要注意。

第一，你的伺服器必須在3 秒內回應，否則 request 會被取消——而且依照上面的送達規則， 逾時不會被重試。如果你的端點在回應之前先做了很慢的同步工作（下單、等交易所 API 回應）, 這是在高負載下悄悄漏掉訊號的常見原因。正確做法是立刻回應 webhook，實際下單邏輯改成背景非同步處理。

第二，如果你有設 IP 白名單，TradingView 目前送 webhook 用的是一組固定 IP——截至 2026 年 7 月查證：

52.89.214.238
34.212.75.30
54.218.53.128
52.32.178.7

URL 指向 localhost 或任何私有/內部 IP，是官方明確記載的失敗案例——TradingView 的伺服器沒辦法 直接連到你的筆電。本機開發階段需要用公開 tunnel（例如 ngrok）架在伺服器前面。

實際怎麼測試

先直接打你自己的端點，把「我的伺服器到底有沒有在聽」跟「TradingView 的 request 有沒有送到」這兩件事分開驗證：

curl -X POST https://api.tvsbot.com/webhook/<your-webhook-token> \
  -H "Content-Type: application/json" \
  -d '{"secret":"INVALID-SECRET-DO-NOT-USE","strategy":"<TVSBot 策略名稱>","action":"buy","symbol":"BTCUSDT","exchange":"binance","market_type":"futures","qty_type":"margin_usdt","qty":10}'

上面以 TVSBot 的 webhook 為例（網址最後一段是策略頁的 webhook token；自架接收端就換成你自己的 URL 與 payload）。 secret 是故意填的無效值，所以這則 curl 只測「連得到、認得 token、payload 合法」，不會下單；請不要換成你真的 secret 來測。 真正的 webhook secret 只在 TradingView 的 alert 視窗填，不要寫進 Pine 原始碼，也不要貼到公開的地方。

看回應就知道卡在哪一層（TVSBot 先驗 payload 格式、再比 secret，所以格式錯時會先看到 400）：

能拿到 401「secret 錯誤」代表你的伺服器沒問題，問題在上游（IP 白名單、逾時，或 TradingView 那端）。

• 伺服器在遠低於 3 秒的時間內回應（任何狀態碼皆可）——重的工作放在回應之後，不是之前
• 防火牆或安全群組允許 TradingView 來源 IP 的連入流量，或改用 SSL 憑證驗證取代 IP 白名單
• Webhook URL 指向公開位址，不是 localhost 或私有 IP
• 直接對自己端點的 curl 測試很快有回應（自架端點回 200；打 TVSBot 並故意帶無效 secret 則是 401）

第 4 層——收到了，但交易所端沒出現任何下單

如果伺服器 log 確認 payload 有進來、程式碼也處理過了，最後一層就是交易所本身拒單或忽略了這筆下單。 這一段 TradingView 完全管不到——純粹是你的伺服器跟交易所 API 之間的事。手上沒有具體錯誤碼的情況下， 常見嫌疑犯是：

如果下單成交的名目金額跟你預期不一樣，而不是直接被拒單，那通常不是這一層的問題——可以看 qty_type 語意陷阱 這篇，那是另一個很常見的特定案例。如果懷疑的是 API key 本身，我們的 Binance API key 安全指南 有詳細列出該開哪些權限、哪些絕對不要開。

• API key 已開啟交易權限（不是唯讀）
• 下單數量符合該交易所該商品的精度/步階
• 下單量高於該交易所該商品的最小名目金額/數量
• 帳號倉位模式（單向 vs 雙向）符合自動化程式的假設
• 交易所端 API key 的 IP 限制（如果有設）已包含你伺服器的 IP

如果還是查不出來

把這五層都查過一遍之後，你至少已經把問題縮小到某一側——TradingView 的 alert 設定、網路路徑，或是交易所帳號。 光是這樣就能把「反正就是不會動」變成一個具體、可以修的問題。如果需要從零開始的完整設定教學， 可以參考我們的 TradingView webhook 完整教學。