GitHub webhook新增48個IP：放行之後仍要驗證簽章
PR已經開啟，部署機器人卻沒有動靜。請求可能在抵達應用程式前就被防火牆擋下。GitHub在10月29日發布的webhook位址更新，影響的正是這條入站路徑。
接收端需要補充三個網段
新增CIDR是9.234.98.160/28、9.234.98.176/28和9.234.106.48/28。適用於github.com所有方案的webhook傳送，包括GitHub Enterprise Cloud。靜態允許清單應保留原有網段，再加入這三個。
每個/28包含16個位址，合計48個。圖中是使用Python ipaddress實際執行的本機計算結果，不是帳號數或伺服器數。GitHub表示，若已透過GET /meta的hooks定期更新清單，本次新增不需額外修改。
IP放行與簽章驗證回答不同問題
允許清單決定哪些來源網路能存取接收端。此處應使用hooks，而不是描述另一條runner通訊路徑的actions。接收事件與CI向外部API發出請求，方向並不相同。
放行後，還要使用該webhook設定的secret驗證X-Hub-Signature-256。GitHub依secret和本文產生HMAC-SHA256。接收端應使用原始位元組計算，並透過hmac.compare_digest或crypto.timingSafeEqual等固定時間方法比較。獲准的IP不能取代這一步。
JSON意義相同，位元組未必相同
把{"action":"opened"}重新序列化成{"action": "opened"}就會多一個空白。意義不變，簽章卻可能不同。本機範例使用公開示範secret，相同位元組得到True，增加空白後為False。這不是實際GitHub傳送的擷取結果。
應先保留原始本文，再進行轉換，並檢查代理或框架是否更動內容。將secret放進payload URL只會增加外洩途徑。請透過安全的伺服器設定讀取它。
恢復傳送時避免重複已完成的工作
網路修復後，檢查失敗紀錄並重新傳送必要項目。要求重新傳送時，X-GitHub-Delivery仍與原來相同。應區分已完成工作和失敗後可恢復工作；丟棄所有看過的ID，也可能阻止正常恢復。
GitHub建議在十秒內回傳2XX，並將耗時工作交給佇列。讓簽章驗證、持久接收與可重試狀態銜接起來。這三個CIDR也就成為抵達、驗證及完成整條路徑的一部分。