代理連線失敗：從代理本身查到目標網站

代理填好後，測試按鈕顯示失敗。這時最怕的是隨機改設定，換連接埠、換協定、換節點，改了半天也不知道到底是哪一項起了作用。

原因大致分布在四個層面：代理服務本身、驗證與協定、用戶端設定、目標網站。排查順序也照這個來，從代理本身往外查。

先把代理本身獨立拿出來測

第一步不要在任何業務工具裡查，直接把這條代理設定到可手動設定代理的一般瀏覽器，或系統代理設定裡，看看能不能連上網際網路。這一步的意義是把代理和業務環境分開。

如果這個環境也連不上，問題就在代理本身：可能已過期、被停用、出口節點故障，或服務商設定了存取限制。這時後面的步驟都不用做，直接找代理服務商確認狀態與用量。

如果這裡能連通，代表代理是正常的，問題出在設定或連線路徑上，繼續往下查。

判斷依據一句話就夠：同一份憑證換個地方能用，代表憑證本身大致沒問題。

驗證與協定要對齊

憑證正確卻連不上，第二個要懷疑的是協定。常見的錯配有三類：服務商提供的是 SOCKS5，環境裡卻選了 HTTP；自建的是 SSH 隧道，環境裡卻按 SOCKS5 設定；或一組代理同時支援多種協定，但不同協定對應不同連接埠，卻填成另一種協定的連接埠。

判斷依據是錯誤文字。如果提示驗證失敗或憑證錯誤，就從帳號密碼著手，注意複製貼上帶進來的空格與換行，也要確認使用者名稱裡的特殊字元是否依要求跳脫；如果提示協定錯誤、握手失敗，就檢查協定類型與連接埠。

使用者名稱和密碼這類欄位，建議手動輸入一次做對照。看不見的字元造成失敗時，光靠肉眼核對是找不出來的。

用戶端裡的設定到底有沒有生效

這一步要回答一個更隱蔽的問題：設定填對了，但它真的生效了嗎？

常見情況有兩種。第一，設定根本沒有套用：修改後沒儲存、改的是另一個環境的設定，或啟動的還是上一個工作階段。第二，設定已生效，但被其他設定覆蓋：環境裡可能還有另一個網路開關、擴充功能自行接管代理，或系統層級的代理設定優先順序更高。

判斷依據看出口位址。連上後開啟一個顯示目前出口的頁面，應該顯示代理的位址，而不是本機位址。如果仍然是本機位址，表示請求根本沒有走代理，即使測試按鈕顯示通過也一樣。

對照方式很簡單：同一個環境分別開一次代理、關一次代理，看出口位址有沒有變化。沒有變化，問題就在用戶端這一側。如果同時跑多個環境，還要逐一確認各自的出口。依帳號隔離環境的工具，例如 PurpleMark，在綁定代理時關注的正是這一點。

目標網站側的拒絕特徵

如果各層都能通、代理也確實生效，但業務頁面依然打不開，這時要看的是目標網站的反應，而不是繼續在代理上反覆調整。

這類情況通常有比較明顯的樣子：連線能建立、握手也能完成，但請求回傳 403 或直接被重設；頁面能開啟，但登入、發布這類操作被拒絕；同一個出口存取其他網站正常，只有這一個網站不行；還有一種是間歇性失敗，這可能表示出口或連線路徑被限速，或並行數受到限制。

判斷的關鍵是把連線層和業務層分開。連不上是代理問題的可能性較高；連上了但被拒絕，多半和出口品質或存取頻率有關。資料中心 IP、被大量使用過的共享 IP，在業務層比較容易被攔截。住宅 IP 相對可能好一些，但也不是通行證，請求頻率、並行數、存取時段同樣會影響結果。

排查時守住三個習慣

一次只改一項。同時改協定又換節點，最後即使連通了，也不知道真正原因，下次還可能再踩一次。

先記錄再調整。把能用的那份設定記下來，位址、連接埠、協定、驗證方式都寫好。下次出問題直接對照，比從零開始排查快得多。

對照測試優於反覆重試。確認設定沒問題卻還是連不上時，反覆按測試按鈕不會帶來新資訊，不如換一個網路環境或換一條代理做對照。