2026年 OpenClaw Webhooks 入站對接 GitHub／GitLab CI：共用密鑰、閘道路由限流與獨享遠端 Mac SSH 上的可復現部署與 401／413／逾時 FAQ
把 CI 的「事件出口」接到 OpenClaw 的「自動化入口」：先對齊 GitHub／GitLab 的簽章與投遞語意，再在閘道側做路由與限流，最後在獨享遠端 Mac 上以 SSH 固化一套可復現的部署與排錯表。
1. 鏈路先畫清：CI Webhook 不是「能 POST 就行」
一次可靠的入站至少要滿足四層：身分可信（共用密鑰或 HMAC 驗簽）、載荷完整（原始 body 未被改寫）、路由正確（邊緣到 OpenClaw 行程的路徑一致）、背壓可控（限流與逾時不會把合法流量誤殺）。CI 側常見誤區是只測 200，卻忽略重試、合併推送風暴與超大 diff 留言本文。
若你同時在跑長期 SSH 工作階段與背景任務，建議把「連線穩定性」與「事件突發」分開度量；可參考 2026年OpenClaw + SSH：在遠端 Mac 上實現無人值守自動執行 的分層思路，避免把 Webhook 抖動誤判成 OpenClaw 自身故障。
2. GitHub 與 GitLab：驗簽標頭、Payload 與重放面
GitHub：使用 X-Hub-Signature-256（或舊版 X-Hub-Signature）對原始請求本文做 HMAC；反代若緩衝或改寫了 body，驗簽會穩定失敗。請顯式記錄 X-GitHub-Delivery 以便與 CI 日誌對齊。
GitLab：X-Gitlab-Token 用於共用密鑰；部分情境還會帶 X-Gitlab-Event-UUID。自建實例要注意相對 URL 與代理路徑前綴是否與 OpenClaw 路由設定一致。
- 冪等與去重：在 OpenClaw 側以 delivery id／event id 做短期去重，避免 CI 重試導致重複觸發。
- 時鐘：若你混用帶時間窗的簽章方案，NTP 漂移會放大「偶發 401」。
3. 共用密鑰：存放、輪換與 Gateway 權杖的邊界
Webhook 的共用密鑰解決的是「外部系統聲稱來自 Git 平台」；OPENCLAW_GATEWAY_TOKEN 一類變數解決的是「誰可以呼叫你的 Gateway 控制面」。兩者職責不同，不要混在同一環境變數名稱裡，否則輪換時會出現「CI 已更新、OpenClaw 仍讀舊值」的間歇故障。
- 真源：在獨享 Mac 上優先以 LaunchAgent／鑰匙圈注入，避免把密鑰寫進可被多使用者讀取的 shell 歷程。
- 輪換：採雙密鑰並行視窗：先讓 OpenClaw 同時接受舊／新，再更新 CI，最後撤舊。
- 最小權限：Webhook 路由只暴露必要子路徑；管理 API 與 Dashboard 走獨立鑑權面。
4. 閘道路由、反代與限流：別把 429 當成「CI 壞了」
入口通常在 Nginx、Caddy、cloudflared、Tailscale Serve 或雲端 WAF 之後。你需要同時核對：client_max_body_size（或等價項）、read／write 逾時、HTTP／2 與 WebSocket 升級，以及 OpenClaw 閘道側的 rate limit／profile 輪換策略。
當流水線在短時間窗內觸發大量事件（例如批次 label、多個子模組 pipeline），邊緣或閘道可能先回傳 429／503，而 CI 仍顯示「Webhook 已投遞」。此時應調大突發桶或依儲存庫分片多個入口，而不是盲目加長 CI 逾時。
若你想對照「事件風暴」與「本機 Runner 資源」是否混淆，可延伸閱讀 2026年 OpenClaw 裸機性能巔峰：為何物理 Mac mini 是解決 ClawHub 插件安全與 NanoClaw 性能損耗的最佳方案 ，有助區分入站限流與本機 CPU／IO 飽和。
5. 獨享遠端 Mac SSH：可復現部署清單
下列清單面向獨佔節點，目標是一頁 Runbook 讓同事 SSH 上來即可復現同一結果。
- 版本釘選：記錄 OpenClaw CLI、Gateway 與 Node 執行時版本；升級前後各跑一次「驗簽探針」。
- 本機探針：先在
127.0.0.1以保存的原始 body＋簽章標頭重播，再在公網入口重播，定位問題在行程內還是邊緣。 - 監聽與轉送：
lsof確認監聽行程；反代是否剝除Authorization／自訂標頭。 - 日誌：為 Webhook 處理與閘道限流各落一條結構化日誌（含 delivery id、儲存庫、HTTP 狀態），避免只有「401」沒有脈絡。
- 回滾：保留上一份 plist／環境檔與密鑰輪換紀錄，確保一次失敗升級可快速退回。
6. 401／413／逾時：分診表
| HTTP／現象 | 優先假設 | 立刻動作 |
|---|---|---|
| 401 Unauthorized | 共用密鑰／GitLab token 不符；或 Gateway 權杖缺失；或反代剝標頭 | 以 curl 固定 body 重播；核對 CI 密鑰與 OpenClaw 側一致；檢查 proxy_set_header；確認未把 Webhook 密鑰與 Gateway token 混用 |
| 413 Payload Too Large | 留言／check_run 附件過大；邊緣 client_max_body_size 過小 |
調大反代 body 限制；在 CI 側縮減事件範圍或改用語意較輕的事件類型 |
| 閘道／邊緣 504／逾時 | read 逾時短於 OpenClaw 處理；冷啟動；下游工具鏈阻塞 | 調大 proxy read／send 逾時；拆分同步處理與佇列化非同步任務；對 Ollama／外部 API 設獨立逾時 |
| 429／限流日誌 | 突發事件超過 rate limit profile；或 profile 輪換策略過緊 | 依儲存庫分流入站；調桶參數；在 CI 側合併通知或減少無意義事件訂閱 |
| 驗簽「偶發失敗」 | body 被 JSON 再序列化；charset；壓縮差異 | 確保驗簽使用原始位元組流；禁止中間層 pretty-print；統一 UTF-8 |
7. FAQ
Q：CI 顯示 Webhook 200，但 OpenClaw 沒有動作？
A：核對是否命中另一套路由（多網域／多路徑）；檢查非同步佇列是否堆積；確認事件類型過濾邏輯是否把該 action 丟棄。
Q：只有 GitLab 自建實例失敗，GitHub 正常？
A：優先查相對 URL、代理路徑前綴與 SSL 終止；自建實例的出站 IP 是否在防火牆白名單內。
Q：能否關閉驗簽以方便偵錯？
A：僅可在隔離環境短時關閉；正式環境必須啟用，否則任何人可偽造 pipeline 事件觸發自動化。
在 Mac mini 上跑入站自動化，更穩也更省心
Webhook 與閘道服務需要長期在線、低抖動與可預期的系統狀態。macOS 提供原生 Unix 工具鏈與 launchd，搭配 SSH 可讓「任何人登入即復現」成為常態；Apple Silicon Mac mini 在同價位下通常具備更高能效與更低待機功耗（約 4W 量級），適合作為家庭或小團隊的常駐入站節點。Gatekeeper、SIP 與 FileVault 也降低了無人值守場景下的惡意軟體暴露面；長期綜合成本上，體積小、靜音與低功耗對 7×24 服務更友善。
若你希望把本文中的驗簽探針、限流與部署清單跑在安靜、穩定、長期綜合成本可控的硬體上，Mac mini M4 是目前性價比很高的起點；現在即可從首頁瞭解方案並入手，讓 OpenClaw 與 CI 的聯動真正發揮持續價值。