你執行 ngrok http 3000。複製網址。貼到 Stripe 儀表板。除錯一個小時，闔上筆電，隔天早上整套儀式又得重來一次，因為網址已經不見了。
這不是什麼難題。它是一道每天都會重新裂開的小傷口，而大部分的解答不是「付錢買固定網域」，就是「換一個隧道工具」。還有第三個選項，不用花錢，而且在另一層解決問題。
登記一個比終端機活得更久的位址
服務商不需要知道你的筆電在哪裡。它需要的是一個永遠都在的網址。
Stripe / Shopify / GitHub
│
▼
in.anyhook.net/you/dev ← registered once, never changes
│
▼
https://whatever-ngrok-gave-you-today.ngrok-free.app/webhook
服務商只跟永久的那一半打交道。隧道重啟時，你只要在一個欄位裡改掉暫時的那一半，完全不用碰服務商的儀表板。變更大約一分鐘內就會傳到每個邊緣節點。
整個概念就是這樣。這篇其餘的部分，談的是為什麼值得花這五分鐘，以及它幫不上忙的地方。
在 Shopify 上，這不只是小傷口
在大多數服務商上，過期的網址只代表一些可以忽略的傳遞失敗。在 Shopify 上，它可能代表你會失去訂閱。
透過 Shopify Admin API 建立的訂閱，會一直保留建立時的網址。你啟動開發伺服器，拿到新的隧道網址，訂閱指向的卻還是昨天的位址。Shopify 傳遞過去、失敗、重試，連續失敗到一定次數後，就會整個刪除這個訂閱。現在就算你修好隧道，也什麼都收不到，而這個失敗看起來像是「Shopify 不送了」，而不是「我改了網址」。
WooCommerce 在連續失敗超過五次後停用 Webhook。Stripe 在持續失敗後停用端點。一個每天都變的網址，就是一台製造連續失敗的機器。
付費固定網域做不到的事
固定的隧道網域解決了一再重貼的問題，卻解決不了筆電闔上的那段時間。
前面放一個 Webhook 中繼服務（webhook relay）之後，隧道斷線期間到達的事件，會在嘗試任何傳遞之前就被接收、驗證，並寫進事件紀錄。傳遞到你的電腦會失敗，這是預期中的事，沒關係。事件還在。
- 回來後，啟動隧道，按下重播。你不在時失敗的事件，會從最舊的開始，再送一次到處理程式
- 重播不計入每月配額，不過有每日上限，也會用到你的運算額度
- 你能看到服務商實際送了什麼，包括標頭和請求主體，不必從一個從沒執行的處理程式去推測
Free 方案包含一個 App（一個接收網址，對應一個 Webhook 來源）、每月 10,000 個事件、每日 1,000 個，比開發循環用得到的還多。在這個方案上，事件的可重播期間是三天，這就是誠實的極限：它是週末的安全網，不是封存。
它幫不上忙的地方
- 它不會讓你的處理程式繼續執行。隧道斷線時，傳遞到那裡都會失敗。你得到的是事件紀錄和重播按鈕，而不是傳遞到一台關機的電腦
- 它不是跳過簽章驗證的理由。服務商的原始標頭會原封不動地轉送，所以你原本檢查的簽章，仍然是你要檢查的簽章
- 到了正式環境，隧道就該完全消失。那是另一個論點，我們在「為什麼只靠 ngrok 不夠」談過。ngrok 仍然是開發循環的正確工具；這篇只談它造成的網址頻繁變動
設定方式
- 建立一個 App。你會立刻拿到
in.anyhook.net/{you}/{app} - 把這個網址貼到服務商的儀表板，只要一次
- 把目的地設成你目前的隧道網址
- 從 App 頁面送出一個測試事件，看著它送達
明天隧道給你新位址時，你只要改第 3 步，其他都不用動。如果之後你把 App 或帳號改名，舊網址會繼續導向，而不是回 404，因為已經交給服務商的網址，永遠都不該失效。
結論
服務商的儀表板，不是存放一個每天都變的位址的地方。在那裡放一個永久的網址，把暫時的部分留在你這邊，每天的儀式就會消失，那些被它默默推高的傳遞失敗計數也會跟著消失。
如果你想看更深入的版本，也就是簽章驗證如何撐過重試，以及服務商已經把你停用時該怎麼辦，就從「驗證 Webhook 簽章」和「如何重播 Webhook」開始。