為何 ngrok 不夠：localhost 外的 Webhook

開始整合任何一個 Webhook 服務商的 30 秒內，我就會拿出 ngrok。啟動 ngrok http 3000，把公開網址貼到 Stripe 的儀表板，一分鐘內，本機處理程式裡的中斷點就會被觸發。對開發循環的速度來說，這是顯而易見的勝利。

問題是，ngrok 一直被拿去用在它本來就不是為此設計的情境：staging 環境、「暫時的」正式環境隧道、正式環境服務中斷的除錯。團隊就是在這些地方燒掉好幾個小時。這篇談的是 ngrok 的工作在哪裡結束，以及過了那條線之後，你真正需要什麼。

重點摘要

其一，是在本機測試簽章密鑰。要實際演練簽章驗證，唯一的方法就是真的收到一個簽過章的請求，而 ngrok 讓你做得到。

其二，是測試失敗路徑。讓處理程式回 500，看著 Stripe 的儀表板把這次傳遞標為失敗，驗證你的重試邏輯。

它也是看清服務商實際送了哪些標頭最快的方法，包括那些奇怪的標頭。至於用完即丟的展示，想讓隊友看看整合能動時，開 ngrok 20 分鐘，然後就結束。

在這些用途上，它非常完美。繼續用它。

staging 環境。你不會想讓 staging 依賴某人筆電上的隧道，而筆電一休眠，隧道就斷了。staging 會變成「最後一個設定 Webhook 的人說了算」，等於所有人都依賴某一位工程師的上線時間。

正式環境。這很明顯。

長時間的除錯。如果你需要擷取 3 天的 Webhook，才能重現一個一天只發生一次的 bug，ngrok 的免費方案只保存 24 小時的流量。付費方案是沒問題，但這樣你就是付錢讓一條隧道去做記錄，形狀不對。

交接給客服或非開發的隊友。他們需要的是一個不必先「讓我開一下 ngrok」就能用的網址。

可稽核性。如果法遵團隊要求「給我看 Q1 收到的每一個 Webhook 事件」，ngrok 什麼都給不了你。

服務中斷後的復原。如果你的伺服器當機，而 Stripe 的重試期限已經過了，ngrok 手上也沒有那些事件。

一旦超出「讓我 POST 到 localhost 就好」的階段，問題的真正樣貌是：

這是另一類工具。看你問誰，它可能叫 Webhook 中繼服務，也可能叫 Webhook 代理（webhook proxy）。

中繼服務位在服務商和你的端點之間。服務商把事件送到一個固定的網址（in.anyhook.net/you/stripe），由中繼服務負責傳遞、重試、記錄和重播。

本機開發時，你把隧道網址加為目的地，和正式環境並列，每個進來的事件都會同時送往兩者。你得到和 ngrok 一樣的體驗，在筆電上直接看到事件進來，卻不必忍受隧道動不動就失效。筆電休眠時，只有隧道那個目的地會失敗。正式環境照常運作，事件照樣被記錄，而送往筆電失敗的那些傳遞會留在那裡，等你回來隨時重播。

至於 staging，你把 staging 環境加為另一個目的地；Pro 以上的方案還能用事件類型篩選，只把正式環境流量的一部分送過去。除錯時，依狀態或 App（一個接收網址，對應一個 Webhook 來源）篩選事件紀錄，重播你想重現的事件。

如果困擾你的具體問題是：隧道每次重啟都給你新的網址，你只好一再把它貼回服務商的儀表板，那有一個專門的簡短解法：給服務商一個不會變的網址。

實務上行得通的組合是：新整合的頭 30 分鐘用 ngrok，因為它是達到「在我的機器上能跑」最快的方法；之後的一切都交給 AnyHook，也就是持久的記錄、同時送往多個環境、重播、重試和警示。

AnyHook 給你一個不依賴任何人筆電的固定接收網址，轉送到多個目的地（正式環境、staging、你的隧道，哪裡都行），並保存完整的事件紀錄，隨時可以重播。本機開發繼續用 ngrok，因為在那裡沒有東西比得上它；但任何你弄丟了會難過的東西，就別再交給 ngrok。

在 Webhook 問題上燒掉最多時間的團隊，幾乎都是把 ngrok 當成正式環境策略的那些：

付錢買 ngrok 也解決不了這些。通往同一台筆電的更快隧道，仍然是一條通往筆電的隧道。

離開本機開發後，你要的是一層不住在開發者電腦上的 Webhook 基礎：能持久儲存、能重播，還能同時送往任意數量的目的地。正是這個轉變，讓 Webhook 不再每週都要救火。

如果你還在決定到底要不要接收推送，「Webhook vs 輪詢」從失敗模式而不是效率來論證這個選擇。而一旦你在無伺服器環境上接收它們，「在 Vercel 上接收 Webhook，不讓事件遺失」談的是那些只在正式環境壞掉、在本機從不出問題的部分。