本文目錄
先前關閉 Clash 就斷網、重新開啟又恢復，可能是 Windows 仍將請求送到舊代理連接埠。瀏覽器、系統下載與終端機的代理設定彼此獨立，清除一處不代表其他都恢復；依失敗的應用程式查對應位置，並保留企業要求的代理資訊。沒有代理錯誤卻整台裝置斷網時，再檢查虛擬網卡與路由。
關閉舊手動代理與 PAC，恢復瀏覽器直連
Windows 11 的檢查位置
開啟代理設定
進入「設定 → 網路和 Internet → 代理」，先看「使用代理伺服器」是否仍為開。
關閉舊的手動位址
若位址是 127.0.0.1、連接埠與 Clash 的 mixed-port 一致，關閉「使用代理伺服器」並儲存。
檢查設定指令碼
如果「使用設定指令碼」填有舊 PAC 位址，也一並關閉；「自動檢測設定」可先保留。
徹底退出瀏覽器再測
關閉所有瀏覽器視窗，確認背景處理程式結束，再開啟一個無痕視窗存取普通 HTTP 與 HTTPS 網站。
如果 Windows 頁面看起來已經關閉，可按 Win + R 執行 inetcpl.cpl，在「連線 → 區域網路設定」裡再核對一次。某些舊程式仍透過這套 Internet 選項讀取使用者代理；不要只改位址而保留啟用開關。
這一步恢復後，先保持 Clash 關閉。能直接開啟路由器管理介面和常用網站，說明使用者代理殘留已經定位；此時沒有必要繼續執行 winsock reset 或刪除網路介面卡。
退出後報代理連線失敗，哪些設定可能殘留？
Clash 執行階段正常，退出後立即出現 ERR_PROXY_CONNECTION_FAILED，重新開啟又恢復，通常是系統仍把請求送到 127.0.0.1 的舊連接埠。連接埠停止監聽後會返回 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，退出後全斷 | 虛擬網路介面卡、服務和路由 | 無明確代理錯誤 |
瀏覽器恢復了，系統下載仍失敗時再看 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。
新終端正常，舊終端失敗
常見原因：舊視窗繼承了啟動時的代理變數
處理方法：關閉舊終端並重新開啟，不需要修改系統網路。
只有瀏覽器失敗：檢查擴展、策略與安全 DNS
先開無痕視窗並停用所有代理擴展。擴展可能切換到自己的 PAC，也可能在系統代理關閉後繼續接管請求。公司瀏覽器還可能由策略寫入代理，在 chrome://policy 或 edge://policy 中能看到來源；有管理策略時不要透過改註冊表強行覆蓋。
ERR_NAME_NOT_RESOLVED 更像解析失敗，而 ERR_PROXY_CONNECTION_FAILED 明確指向代理連線。前者可以暫時關閉瀏覽器「使用安全 DNS」做對照。能收到 403 或 404 已經說明網路請求到達伺服器端，不應繼續清快取或重置網路介面卡。
沒有代理錯誤、整機卻斷網，再檢查 TUN 服務和預設路由
TUN 會建立虛擬網路介面卡並修改路由。用戶端仍在正常運作時，在目前用戶端關閉 TUN，再從系統匣退出；用 route print 檢查預設路由是否回到實際 Wi-Fi 或以太網閘道。不要看到虛擬網路介面卡就刪除驅動，它也可能被其他 VPN 使用。
服務已知受影響、版本不明或被安全檢查拒絕時，保持服務停用。透過 Windows 服務管理器或管理員停止對應服務，不為清理殘留重新啟動它。
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；Windows 上要先確認實際服務已有安全修復證據，受影響或版本不明時繼續保持停用。不要同時讓用戶端、瀏覽器擴充功能與指令碼修改系統代理，否則下次設定殘留時很難判斷是誰寫入的。