出口 IP 允許清單把兩個獨立變動的系統綁在一起：代理出口集區與目的端存取政策。任何一側先變更，都可能拒絕合法流量；舊項目長期不刪，又會使政策失真並增加稽核難度。安全切換應採用規劃好的重疊窗口，而非一步替換。
本手冊適用於已獲授權的合作夥伴 API、資料庫閘道、檔案傳輸服務及內部應用，涵蓋靜態資料中心出口、合約明確支援的專用住宅出口、區域代理閘道，以及 IPv4/IPv6 混合環境。
一、確認 IP 允許清單適合目前場景
IP 位址標識的是網路路徑，不是使用者或工作負載身分。規劃前確認目的端仍使用應用層驗證與傳輸保護，例如 API 金鑰、雙向 TLS、簽署請求或使用者認證資料。不要把 IP 規則當作唯一身分控制。
記錄允許清單的業務原因、負責人、目標連接埠，以及來源位址是否由組織獨占。共享代理出口未必具備允許清單所假設的身分屬性；若目的端要求專用位址，應先與代理服務確認。
二、建立舊位址到新位址的版本化清單
每條出口路徑建立一列，記錄舊位址與新位址、位址族與最小正確 CIDR、代理產品和區域、閘道及集區、依賴項目的目的端與連接埠、雙方負責人、UTC 格式的首次觀察和預定下線時間、驗證狀態及回復狀態。
應在真實執行環境解析主機名稱，但 DNS 結果不能證明實際出口。透過代理向獲准的位址觀察端點送出請求，再將觀察到的來源位址與清單比對。所有工作節點、區域、位址族和容錯移轉路徑都要重複驗證。
若位址集區變動頻繁，先使用住宅代理位址池波動監控。高頻變動的共享集區通常不適合靜態允許清單，需要重新設計存取控制。
三、變更政策前定義成功與回復標準
最低成功標準包括：新出口能完成驗證和目標業務交易；重疊窗口內舊出口繼續可用；任何直連或未批准路徑均無法存取；拒絕率、延遲與應用程式錯誤維持基準；目的端最終規則與審核清單完全一致。
同時定義回復觸發條件，例如連線拒絕上升、觀察到錯誤來源位址、網路放行後應用驗證失敗、延遲明顯退化或區域缺失。指定一名可恢復代理路由的負責人，以及另一名可恢復目的端政策的負責人。
四、先加入新項目，再移動流量
採用加法階段：
- 凍結已審核的舊、新清單版本。
- 在目的端加入新位址，暫不刪除舊位址。
- 透過目的端控制平面或第二位審核人確認實際規則。
- 從每個新出口執行低影響且已授權的測試交易。
- 記錄觀察到的來源位址、目的端回應類別、驗證結果與時間。
只能建立 TCP 連線不代表遷移成功。網路放行時，應用仍可能因權杖、租戶、憑證或資源範圍而拒絕。必須用非破壞性資料測試完整業務流程。
不要為了通過測試而擴大 CIDR。過寬前綴可能接納無關客戶或未來位址，應停止變更並核對清單。
五、用金絲雀流量驗證路由切換
將小部分可識別、結果可預期的工作負載切到新出口。限制重試次數，避免政策拒絕演變成請求風暴。
至少觀察四層證據：網路層的連線結果與來源位址；代理層的閘道狀態、驗證與區域；目的端的存取決策及應用狀態；業務層的有效結果數量和延遲。只有完整鏈路成功，才逐步依區域與位址族擴大流量。
不要在同一個不透明變更中同時遷移供應商、輪替認證資料、修改 DNS 並替換允許清單。更廣泛的順序可參考代理供應商遷移手冊。
六、分別驗證 IPv4、IPv6 與容錯移轉
雙堆疊應用可能在解析器、作業系統或網路變更後切換位址族。若兩者均受支援，應明確測試 IPv4 與 IPv6，並記錄各自實際出口和目的端決策。
還要強制觸發規劃中的容錯移轉路徑。長期未演練的備用閘道，可能使用允許清單中不存在的位址。區域復原集區、第二供應商、災難復原節點及來自不同網路的排程工作都要驗證。
可搭配多區域代理路由政策測試，確認政策選擇與實際地理位置一致。
七、讓重疊窗口涵蓋隱藏用戶端
舊、新項目同時生效的時間應涵蓋實際工作負載週期。每小時工作可能只需數小時，每週結算或報表工作則可能需要一週以上。
重疊期間持續尋找仍使用舊出口的流量，並依工作負載負責人、目的端、區域和最後出現時間分組。主要應用完成遷移不代表所有路徑都已移動，低頻工作、手動工具與復原流程通常較晚出現。
必須設定明確結束時間與例外流程。無限期重疊會把受控遷移變成永久擴權。
八、以第二次受控變更移除舊項目
舊路徑在約定觀察期保持安靜後：
- 保存目前目的端政策與舊清單版本。
- 只移除審核確認的舊位址。
- 將結果規則與新清單逐項比對。
- 從所有新出口與容錯移轉路徑強制新建測試。
- 在安全可行時確認舊出口已遭拒絕。
- 在回復窗口內持續監控拒絕與業務結果。
回復應恢復窄範圍舊項目，必要時將受影響工作負載切回舊集區；不能關閉驗證或開放大範圍網段。
九、保存證據但不暴露秘密
保存政策版本、變更單、目的端、區域、位址族、觀察到的來源位址、回應類別與 UTC 時間。權杖、Cookie、代理認證資料、私鑰及含個人或客戶資料的回應內容必須遮蔽。
指標應區分連線拒絕、代理驗證失敗、目的端驗證失敗、節流、逾時及無效業務結果。把所有錯誤都歸為「代理 IP 不好」，只會引發無意義輪替並掩蓋真正故障層。
切換檢查清單
- 已記錄業務目的與雙方負責人。
- 新出口的獨占程度符合目的端要求。
- 舊、新位址均經真實代理路徑觀察。
- IPv4、IPv6、所有區域與容錯移轉均已盤點。
- 成功指標與回復門檻已確認。
- 新項目先於流量遷移加入。
- 完整授權業務交易已通過金絲雀驗證。
- 重試量維持受控。
- 重疊窗口涵蓋低頻工作。
- 舊項目在獨立審核變更中移除。
- 最終政策與新清單完全一致。
- 紀錄不含秘密與不必要內容。
常見問題
可以用主機名稱取代 IP 允許清單嗎？
只有目的端控制明確支援主機名稱政策，並定義解析和更新行為時才可以。許多網路控制仍判斷實際來源位址，應確認真實機制。
應該允許整個供應商位址範圍嗎？
通常不應該。應使用供應商合約和目的端政策支援的最窄位址或前綴，過寬範圍會削弱隔離並增加稽核難度。
新舊位址要重疊多久？
應涵蓋正常和低頻工作週期，並包含受監控的回復期。遷移前決定時間，延長時必須有書面例外。
實際出口與供應商清單不一致怎麼辦？
立即停止擴量，核對閘道、區域、位址族、路由設定和位址分配。在原因明確前不要擴大目的端規則。
合規說明
來源 IP 存取規則只能用於已獲授權的系統與整合。持續保留應用驗證，遵守合作夥伴及適用地區要求，最小化連線資料保存，不得透過允許清單變更繞過目的端控制、速率限制或存取約束。
