407 Proxy Authentication Required 表示請求已到達代理，但代理未接受有效憑證。它不同於目的網站回傳的 401。最有效的方法是分層檢查：代理位址、協定、憑證、驗證方式、隧道與目的站回應。
1. 確認錯誤來自哪一層
以可控請求查看詳細流程，但不要把正式密碼寫入共用終端、工單或截圖。
curl --verbose --proxy "$PROXY_ENDPOINT" \
--proxy-user "$PROXY_USERNAME:$PROXY_PASSWORD" \
https://zh-tw.98ip.com/
檢查 curl 是否連上代理、代理是否回傳 407、隧道是否建立，以及目的站是否已開始回應。保存日誌前必須刪除 Proxy-Authorization、Cookie、權杖、使用者名稱與工作階段參數。
2. 分別核對端點與協定
逐項檢查主機名稱、連接埠與代理類型。HTTP、HTTPS、SOCKS5 與由代理端解析 DNS 的 SOCKS5 並不相同。錯誤協定可能表現成驗證失敗、TLS 錯誤或連線立即重設。
除錯時只保留一套明確設定。暫時清理衝突的 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 與 NO_PROXY，或在不記錄憑證的前提下核對它們。命令列選項通常會覆蓋環境變數，但腳本與子程序仍可能讀取隱藏設定。
3. 安全驗證憑證
把使用者名稱和密碼存放在受保護的環境變數或機密管理器，不要寫入倉庫、Shell 歷史、截圖或其他使用者可讀取的程序參數。密碼包含 @、:、% 等保留字元時，應使用專門的代理憑證選項，避免手動組合未編碼 URL。
確認憑證仍有效，並允許使用對應產品、區域、工作階段模式與來源 IP。即使帳號有效，也可能因子帳號停用或 CI 執行器不在 IP 白名單中而收到 407。
4. 檢查驗證方式
代理可能在回應標頭中宣告支援的驗證方式。curl 預設使用 Basic 代理驗證，企業代理有時需要 Digest、NTLM 或 Negotiate。應依代理要求選擇，不能持續重送同一失敗請求。
住宅代理服務持續發生 407 時，更常見原因是使用者名稱格式錯誤、密碼過期、區域或產品識別錯誤，以及白名單不符。修改參數前先記錄不含機密的帳號範圍資訊。
5. 區分代理錯誤與目的站錯誤
代理驗證成功後，目的站仍可能回傳：401 通常是目的站驗證問題，403 是政策或權限拒絕，429 是速率或並行過高，逾時則可能涉及路由、DNS、TLS、容量或目的站延遲。
不要盲目輪替 IP 或憑證。先確認故障層級，再採取對應措施。
6. 安全檢查隧道與 TLS
HTTPS 目的站通常透過 HTTP CONNECT 建立隧道。隧道建立前失敗，多半屬於代理連線或驗證；隧道開始後失敗，才需要進一步檢查目的站 TLS、憑證驗證或應用行為。
不要把停用憑證驗證當成長期解法。HTTPS 代理使用私人憑證機構時，應設定正確的代理 CA，並將代理憑證與目的站憑證問題分開。
7. 建立最小重現
測試只保留一個目的、一個代理端點、一組憑證與一次請求，移除重試、輪替、並行、瀏覽器自動化與自訂標頭。最小請求成功後，再逐項加入工作階段、地區、重試與並行。
安全診斷資料可包括時間、執行器區域、curl 版本、作業系統、無憑證的代理別名與連接埠、HTTP 狀態、curl 結束碼、各階段延遲、已脫敏標頭與非敏感子帳號識別。
8. 常見模式
本機成功，CI 失敗
檢查機密是否缺失、受保護環境規則、外部分支限制、來源 IP 白名單、Shell 引號，以及機密尾端是否多了換行字元。
輪替密碼後失敗
確認更新了正確環境的機密庫，重新啟動長期執行器，並檢查快取容器或排程工作是否仍使用舊值。
偶發 407
檢查不同工作節點是否取得不同機密、部分端點是否仍使用舊子帳號，以及輪替時是否所有工作都完成切換。
最終檢查清單
- 主機名稱、連接埠與代理協定正確。
- 憑證有效且允許目前產品與區域。
- 特殊字元傳遞方式安全。
- 來源 IP 限制包含目前執行器。
- 驗證方式符合代理要求。
- 環境變數沒有覆蓋預期路由。
- 已區分代理
407與目的站401、403、429。 - 日誌和工單不含機密。
- 測試符合適用法律、目的服務條款與資料處理規則。
需要建立可控的代理設定與支援流程時，可查看 98IP 的服務資訊。從最小請求開始，保護憑證，驗證層穩定後再逐步增加複雜度。
內部研究依據：curl 代理驗證與代理選項文件、MDN HTTP 狀態文件、Python 標準函式庫代理文件。僅列出資料名稱，不提供外部連結。
