本文目錄
Clash 退出了，Windows 可能還在把請求送往舊連接埠
這類故障最典型的表現是：Clash 執行階段網頁正常，退出程式後瀏覽器立刻顯示 ERR_PROXY_CONNECTION_FAILED，重新開啟 Clash 又恢復。
問題通常不在寬帶，而是代理設定仍指向 127.0.0.1 加舊連接埠。處理程式已經不監聽，Windows 還在繼續轉發，自然會得到 connection refused。
先用手機連線同一個 Wi-Fi，或在電腦上 ping 路由器管理位址。如果其他裝置能上網、電腦也能到達路由器，就不要先重置網路介面卡。Windows 的使用者代理、自動設定指令碼、WinHTTP、環境變數和單個應用代理彼此獨立，要找出留下設定的那一層。
錯誤現象通常指向哪裡
| 現象 | 優先檢查 | 常見提示 |
|---|---|---|
| Chrome、Edge 和系統應用一起斷網 | Windows 手動代理或設定指令碼 | ERR_PROXY_CONNECTION_FAILED |
| 瀏覽器正常，安裝器或系統服務失敗 | WinHTTP | 連線被拒絕、無法下載 |
| 終端中的 Git、npm 失敗 | 環境變數和工具自己的代理 | Failed to connect to 127.0.0.1 |
| 只有一個瀏覽器異常 | 擴展、瀏覽器策略或安全 DNS | 其他應用仍可存取 |
| 只要開過 TUN，退出後全斷 | 虛擬網路介面卡、服務和路由 | 無明確代理錯誤 |
先在 Windows 的「代理」頁面恢復直連
Windows 11 的檢查位置
開啟代理設定
進入「設定 → 網路和 Internet → 代理」，先看「使用代理伺服器」是否仍為開。
關閉舊的手動位址
若位址是 127.0.0.1、連接埠與 Clash 的 mixed-port 一致，關閉「使用代理伺服器」並儲存。
檢查設定指令碼
如果「使用設定指令碼」填有舊 PAC 位址，也一並關閉；「自動檢測設定」可先保留。
徹底退出瀏覽器再測
關閉所有瀏覽器視窗，確認背景處理程式結束，再開啟一個無痕視窗存取普通 HTTP 與 HTTPS 網站。
如果 Windows 頁面看起來已經關閉，可按 Win + R 執行 inetcpl.cpl，在「連線 → 區域網路設定」裡再核對一次。某些舊程式仍透過這套 Internet 選項讀取使用者代理；不要只改位址而保留啟用開關。
這一步恢復後，先保持 Clash 關閉。能直接開啟路由器管理介面和常用網站，說明使用者代理殘留已經定位；此時沒有必要繼續執行 winsock reset 或刪除網路介面卡。
瀏覽器恢復了，系統下載仍失敗時再看 WinHTTP
WinHTTP 主要被系統服務、安裝器和部分企業程式使用，它不是 Windows「代理」頁面的同一個開關。只有瀏覽器已經能直連，而 winget、某個安裝器或服務仍試圖連線舊代理時，才需要檢查這裡。
netsh winhttp show proxy
# 只有输出仍显示旧代理时才执行
netsh winhttp reset proxy終端單獨沒網，通常是變數或工具設定沒有隨 Clash 退出
很多開發教學會臨時設定 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，也有人把代理寫進 Git、npm 設定。它們不會因為 Clash 視窗關閉而自動消失。先在新開的 PowerShell 中查看目前處理程式和使用者級變數，再檢查出錯工具自己的設定來源。
Get-ChildItem Env: | Where-Object Name -match '^(HTTP|HTTPS|ALL|NO)_PROXY$'
[Environment]::GetEnvironmentVariable('HTTP_PROXY', 'User')
[Environment]::GetEnvironmentVariable('HTTPS_PROXY', 'User')
git config --show-origin --get-regexp "http.*proxy"
npm config get proxy
npm config get https-proxyGit 報 Failed to connect to 127.0.0.1 port 7890
常見原因：Git 設定或環境變數仍指向舊連接埠
處理方法：根據 --show-origin 回傳的檔案刪除對應 proxy 項，不盲刪其他 Git 設定。
npm 失敗但 curl 正常
常見原因：npm 使用者設定裡仍有 proxy/https-proxy
處理方法：確認來源後執行 npm config delete proxy 與 npm config delete https-proxy。
新終端正常，舊終端失敗
常見原因：舊視窗繼承了啟動時的代理變數
處理方法：關閉舊終端並重新開啟，不需要修改系統網路。
如果只有瀏覽器異常，把瀏覽器自己的變數拿掉
先開無痕視窗並停用所有代理擴展。擴展可能切換到自己的 PAC，也可能在系統代理關閉後繼續接管請求。公司瀏覽器還可能由策略寫入代理，在 chrome://policy 或 edge://policy 中能看到來源；有管理策略時不要透過改註冊表強行覆蓋。
ERR_NAME_NOT_RESOLVED 更像解析失敗，而 ERR_PROXY_CONNECTION_FAILED 明確指向代理連線。前者可以暫時關閉瀏覽器「使用安全 DNS」做對照。能收到 403 或 404 已經說明網路請求到達伺服器端，不應繼續清快取或重置網路介面卡。
沒有代理錯誤、整機卻斷網，再檢查 TUN 服務和預設路由
TUN 模式會建立虛擬介面卡並改變路由，檢查方法和系統代理不同。先重新開啟 Clash，關閉 TUN 與服務模式，再從系統匣選單正常退出；隨後用 route print 查看預設路由是否回到實際的 Wi-Fi 或以太網閘道。不要一看到虛擬網路介面卡就刪除驅動，它可能同時被其他 VPN 使用。
Get-NetAdapter | Sort-Object Status, Name
route print- 預設路由仍指向失效虛擬介面
- 先正常停用對應 VPN/TUN 服務並重啟電腦；記錄介面名稱後再決定是否卸載用戶端元件。
- 實際網路介面卡沒有閘道或 169.254 位址
- 這已經是 DHCP 或本機網路問題，重新連線 Wi-Fi 或續租位址，而不是繼續改代理。
- 路由和位址都正常，只有 DNS 失敗
- 檢查網路介面卡 DNS 與瀏覽器安全 DNS；整機網路重置應作為有備份後的最後手段。
以「Clash 關閉後仍可直連」作為修復結果
關閉 Clash 後逐項確認
- Windows「使用代理伺服器」和舊 PAC 均為關閉
- netsh winhttp show proxy 在需要直連的電腦上顯示 Direct access
- 新終端裡沒有指向舊連接埠的代理變數
- 瀏覽器、系統更新檢查與至少一個終端工具都能存取
- 重啟電腦後結果不反彈
重新啟用 Clash 時一次只開一種接管方式：先系統代理，確認開啟與退出都能正確恢復；確實有不讀取系統代理的應用，再單獨測試 TUN。不要同時讓用戶端、瀏覽器擴展和指令碼修改系統代理，否則下次殘留時很難判斷是誰寫入的。