用 ngrok 做 UnifyPort webhook 的本地開發

ngrok 解決什麼

一條命令就有一個公網 HTTPS URL，把每個請求轉到本地某個 port。所有經過的流量都被 http://127.0.0.1:4040 的請求 inspector 擷取——headers、body、時序、replay 按鈕一應俱全。這個 inspector 才是我們到現在還用 ngrok 的原因，就算市面上有不少免費通道替代品：它把本來要邊打 log 邊追的事壓縮成「看一眼」。

UnifyPort handler 的五分鐘搭建

假設 handler 監聽在 3000 port：

1. 1. ngrok http 3000——複製它印出的 https://*.ngrok-free.app URL。
2. 2. 透過 POST /v1/webhook-endpoints 註冊這個 URL——把 url 設成 https://<your-tunnel>.ngrok-free.app/events，按需要選 subscribed_events（迭代期可以先 ["*"] 全收）。
3. 3. 瀏覽器開啟 http://127.0.0.1:4040。從 provider 那邊觸發事件——一則 Telegram 私訊、一則 WhatsApp 訊息——看著它落進來。
4. 4. 用 replay 按鈕把同一條投遞重發給改過程式碼的 handler。這就是 ngrok 比每次改程式碼都要去 provider 那邊重新觸發事件更快的原因。

本地驗證簽章

ngrok 免費版通道在上游就終結 TLS，所以你的 handler 看到請求時 body 已經是明文——正是 UnifyPort 簽的那份。這代表簽章驗證跟正式環境一樣：算 hex(HMAC-SHA256(secret, timestamp + "." + body))，跟 X-Device-Signature header 比對。想加程式碼前先手動確認一次，可以走我們的 CyberChef 詳解——同一個演算法在瀏覽器跑一遍。

ngrok 不再是最佳答案的時候

• staging 或 demo 環境。免費版 URL 每次重啟都會換，長期設定會被打斷。要嘛上付費版用固定網域，要嘛改用 Cloudflare Tunnel，免費取得固定 host。
• 高頻壓測。免費版 ngrok 節流很積極。要嘛升級方案，要嘛把 handler 部到真實環境跑。
• 只跑 webhook、沒其他 HTTP 流量的場景。smee.io 更輕——不用裝二進位檔，只要一支 client 腳本。