Windows 版 Clash 安裝與連線疑難排解：防火牆、UAC、系統代理

安裝前：確認系統架構與用戶端類型

Windows 上的 Clash 用戶端通常由圖形介面和代理核心組成。介面負責訂閱、代理群組、系統代理與服務管理；核心則負責監聽本機連接埠、比對規則並建立連線。Clash Meta 後續以 mihomo 名稱發展，使用 mihomo 的用戶端也不代表選單配置完全相同。排查問題時，請一併記錄用戶端名稱、版本及核心版本，不能只寫「Clash」。

本文以 Windows 11 的系統設定路徑為例。Windows 10 部分選項名稱不同，但本機監聽、系統代理與權限的檢查方式相同。先確認一般系統代理連線正常，再依應用程式需求啟用 TUN，避免同時變更多條網路路徑。

選擇安裝檔

1. 開啟「設定」→「系統」→「關於」，在「裝置規格」中查看「系統類型」。採用 x64 架構的處理器通常選擇 x64 安裝檔；ARM 裝置則優先選擇用戶端提供的 ARM64 版本。
2. 前往用戶端下載頁查看支援的平台與架構。安裝程式和單獨的 mihomo 核心是不同的發行檔案；核心壓縮檔通常不含訂閱管理介面。
3. 查看用戶端發行說明中的 Windows 最低版本需求、執行階段相依元件及維護狀態。舊版 Clash for Windows 的介面教學不一定適用於所有新用戶端。
4. 安裝前先結束其他代理用戶端，並記下目前的代理與 VPN 設定。免安裝版請解壓縮至固定資料夾；註冊服務後，不要任意移動核心檔案。

首次連線：匯入設定並建立基本可用路徑

安裝完成後，先匯入有效訂閱或本機 YAML 設定檔。訂閱網址可能包含存取憑證，請勿貼到公開群組或截圖中。匯入後確認該設定已設為目前使用的設定，且代理群組中有可選節點。只看到「訂閱已更新」並不能證明核心已成功載入。

1. 在用戶端的訂閱或設定頁面匯入並啟用設定，接著查看記錄是否出現 YAML 解析錯誤、未知欄位或規則提供者下載失敗。
2. 在代理頁面選擇規則模式，並在實際由規則引用的代理群組中選取節點。若選到未被規則使用的群組，該連線的出口不會改變。
3. 確認核心正在執行，並記下實際的 HTTP 或混合代理連接埠。以下以 127.0.0.1:7890 為例；這不是所有用戶端的固定預設值。
4. 在用戶端啟用系統代理，透過瀏覽器開啟要測試的網站，再查看連線清單中的規則、策略群組與出口。

如果設定檔由用戶端產生，請透過用戶端設定或支援的覆寫功能調整監聽參數。直接修改訂閱快取檔案，可能會在下次更新時遭到覆寫。以下僅為 mihomo 本機監聽參數範例，不包含節點與分流規則，不能單獨當作完整的上網設定：

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info

混合連接埠同時支援 HTTP 代理和 SOCKS 代理。若只供本機使用，請維持回送位址監聽並關閉區域網路存取；不要為了修復瀏覽器連線而將監聽位址改成所有網路介面，也不要將代理連接埠轉發至公網。

使用明確指定代理來區分問題

在 PowerShell 中執行以下命令。此處指定 curl.exe，避免 Windows PowerShell 中同名別名造成參數差異。範例網址僅供連線測試，不能代表所有網站的存取品質。

Test-NetConnection 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

• TcpTestSucceeded : True 只表示本機 TCP 連線可以建立，不能證明遠端節點可用。
• 如果明確指定代理後能收到 HTTP 回應，但瀏覽器仍無法連線，請優先檢查系統代理、瀏覽器擴充功能及應用程式本身的設定。
• 如果顯示無法連線至 127.0.0.1:7890，先檢查連接埠與核心狀態，不必立刻更換遠端節點。
• 如果已連上本機連接埠，之後才出現 TLS 錯誤或遠端逾時，再檢查節點、規則、系統時間與用戶端記錄。不要把略過憑證驗證當成一般修復方式。

UAC 與服務模式：依功能授予權限

一般本機代理監聽通常不需要系統管理員權限。安裝至受保護資料夾、註冊系統服務、設定虛擬網卡或修改路由時，用戶端才可能觸發 UAC。UAC 是確認是否提升權限，不是網路連線許可；按下「是」也不會自動設定防火牆或選好節點。

安裝服務並確認狀態

1. 在用戶端設定中尋找服務模式或背景服務選項。選單名稱依用戶端而異，請先確認安裝服務的操作確實來自該用戶端。
2. 按下安裝服務後，確認 UAC 提示中的程式路徑與發行者資訊。若路徑異常或來源不明，請取消授權。
3. 按下 Win + R，輸入 services.msc，找到用戶端實際註冊的服務，確認其狀態與執行檔路徑。各用戶端的服務名稱並不一致。
4. 返回用戶端確認服務狀態。若準備啟用 TUN，還要檢查虛擬介面與核心記錄，不能只看服務安裝成功的提示。

遇到「拒絕存取」時，先確認安裝服務的操作是否成功取得提升權限。若出現「找不到服務檔案」或服務啟動後立即停止，請檢查免安裝版資料夾是否曾被移動、檔案是否遭安全軟體隔離，以及舊服務是否仍指向原路徑。優先透過用戶端的服務管理選項移除舊服務後重新安裝，不要猜服務名稱來執行刪除命令。

系統代理：檢查 Windows、瀏覽器與命令列的差異

Windows 11 的設定路徑為「設定」→「網路和網際網路」→「Proxy」。檢查「手動 Proxy 設定」中的位址和連接埠是否與用戶端一致。本文範例對應位址 127.0.0.1、連接埠 7890。若用戶端使用 PAC 自動設定，請檢查「使用設定指令碼」及指令碼網址，不要再強行疊加手動代理。

Edge、Chrome 通常會使用系統代理，但擴充功能、啟動參數和組織政策可能改變其行為。Firefox 也能在「設定」→「一般」→「網路設定」中另外選擇代理來源。如果只有特定瀏覽器無法連線，先檢查該瀏覽器的代理設定，不要同時變更核心、DNS 和防火牆。

分別檢查 WinHTTP 與環境變數

netsh winhttp show proxy
Get-ChildItem Env: | Where-Object Name -Match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$'

netsh winhttp show proxy 查詢的是 WinHTTP 設定，與瀏覽器使用的目前使用者系統代理不同。顯示直接存取，不代表用戶端的系統代理開關失效。有些開發工具會讀取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，也有工具使用自己的設定檔。

尚未確認應用程式使用哪種代理設定前，不要直接將目前使用者的代理匯入 WinHTTP。背景服務可能使用不同帳戶，修改全系統設定也會影響其他軟體。正確做法是先找出故障的處理程序，再查閱其代理文件與執行帳戶。

結束用戶端後，瀏覽器就完全無法上網

這種情況通常要先排除代理設定殘留：核心已停止，但 Windows 仍指向本機代理連接埠。重新開啟用戶端並正常關閉系統代理，或在 Windows 代理設定中關閉本次設定的手動代理或指令碼。企業設定的 PAC 不要任意刪除。恢復後先測試直接連線，再重新啟動用戶端。

連接埠占用：從監聽處理程序找出設定衝突

記錄中的 address already in use 通常表示監聽連接埠發生衝突，與遠端節點延遲無關。先查詢本機連接埠，再依處理程序 ID 找出占用者，避免反覆重裝用戶端。

Get-NetTCPConnection -State Listen -LocalPort 7890 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, LocalPort, OwningProcess

netstat -ano | findstr ":7890"

第一個命令只會列出指定連接埠的 TCP 監聽項目；第二個命令也可能顯示其他連線，必須確認本機位址欄與監聽狀態。取得處理程序 ID 後，在「工作管理員」→「詳細資料」中依 PID 尋找處理程序。若沒有 PID 欄，請在欄位標題上按右鍵並選取該欄。

• 如果是另一個代理用戶端占用，先從其系統匣選單正常結束程式，並停用自動啟動的背景服務。
• 如果是目前用戶端的另一個核心執行個體，請確認免安裝版與安裝版是否同時開啟，或服務模式與手動啟動的核心是否重複執行。
• 若連接埠由其他必要程式使用，可將本機代理連接埠改為未占用的值，例如 7891，並同步更新系統代理與應用程式內的代理設定。

不要只修改 YAML 中的連接埠，卻保留 Windows 裡的舊值。若出現 access denied，但查不到監聽程序，也可能與安全政策或系統保留連接埠有關，不能一概判定為其他程序占用。請根據完整錯誤訊息和系統政策進一步檢查，不要反覆結束不明程序。

防火牆與安全軟體：確認遭封鎖的對象

Windows 防火牆提示主要涉及應用程式在不同網路設定檔下的通訊權限。用戶端介面、代理核心和背景服務可能是不同的執行檔。只允許圖形介面，不代表核心的規則就正確；但僅供本機使用的回送代理，也不需要因此對公用網路開放輸入連接埠。

依據證據處理封鎖問題

1. 開啟「Windows 安全性」→「病毒與威脅防護」→「保護歷程記錄」，確認事件時間、遭處理檔案的路徑及偵測名稱。
2. 確認檔案來源，以及它與目前用戶端安裝資料夾的關係。若仍無法判斷，請保留記錄，交由用戶端維護者或安全軟體廠商分析。
3. 按下 Win + R，輸入 wf.msc，在進階安全性防火牆中檢查指向目前核心路徑的輸出規則，以及是否有明確的封鎖規則。
4. 若確實需要調整許可，請限定特定程式、通訊方向及適用網路。核心更新後若路徑改變，請重新確認規則的目標。

明確的封鎖規則可能優先於允許規則，因此只新增允許規則未必有效。第三方安全軟體也可能有獨立的網路過濾模組，請查看其事件記錄。不要把關閉所有防護、排除整個下載資料夾或開放所有連接埠當成預設排錯步驟。

UWP 回送：只處理確實受到限制的應用程式

部分在 AppContainer 中執行的應用程式，無法像一般桌面程式一樣連線至本機回送代理。這時可能會出現瀏覽器正常、某個市集應用程式失敗的情況。並非所有從 Microsoft Store 安裝的程式都屬於這類，也不是所有應用程式都會遵循系統代理；請先確認應用程式類型與失敗記錄。

以系統管理員身分開啟 PowerShell，先查看現有的回送豁免與本機已安裝套件資訊。以下以 Microsoft Store 套件作為檢查範例；若查不到結果，請勿繼續套用該套件名稱。

CheckNetIsolation.exe LoopbackExempt -s
Get-AppxPackage -Name Microsoft.WindowsStore |
  Select-Object Name, PackageFamilyName

確認該套件確實是要處理的對象後，可透過變數讀取目前使用者實際安裝的套件族名稱，避免誤用套件完整名稱或安裝資料夾名稱：

$app = Get-AppxPackage -Name Microsoft.WindowsStore
if ($app) {
    CheckNetIsolation.exe LoopbackExempt -a "-n=$($app.PackageFamilyName)"
}

完成後，關閉並重新開啟目標應用程式，再確認請求是否進入用戶端。若要撤銷，請對同一個套件族名稱執行移除操作：

$app = Get-AppxPackage -Name Microsoft.WindowsStore
if ($app) {
    CheckNetIsolation.exe LoopbackExempt -d "-n=$($app.PackageFamilyName)"
}

回送豁免只會解除目標應用程式存取本機回送的限制，不會設定代理、修復訂閱或修改規則。若用戶端提供回送管理工具，也只選取需要的應用程式，不要一次放行所有套件。啟用 TUN 有時能改變應用程式的流量路徑，但不應視為解決所有市集應用程式問題的固定方法。

TUN 與 DNS：基本連線正常後再擴大接管範圍

如果明確指定代理與瀏覽器系統代理都正常，但遊戲、命令列工具或不支援代理設定的應用程式仍直接連線，再評估是否啟用 TUN。mihomo 的 TUN 接管範圍會受虛擬介面、路由、排除項目及 DNS 設定共同影響；開啟一個選項無法保證所有流量都會被接管。

• 先確認用戶端要求的服務或權限已就緒，再啟用 TUN。檢查記錄中的虛擬介面建立失敗與路由錯誤。
• 檢查是否同時執行企業 VPN、其他虛擬網卡或代理工具。多組自動路由可能爭用預設路由，請一次只驗證一項變更。
• 在連線清單中確認目標應用程式是否出現，以及其規則與出口。若沒有該應用程式的連線記錄，優先檢查流量接管路徑，不要先更換代理群組。
• 若網域名稱解析失敗，但已知 IP 位址可連線，再檢查 DNS。可使用 Resolve-DnsName example.com 查看系統解析結果，但這不能單獨證明核心內部的解析也正常。

不要把公用 DNS 位址填入所有設定，當成通用修復方式。系統 DNS、核心 DNS、代理節點的網域解析及瀏覽器安全 DNS 可能走不同路徑。變更前記下原始值，一次調整一項，並確認核心是否回報解析逾時或無法連上上游。涉及 TUN 與路由設定時，可參考全平台安裝指南確認各平台的設定範圍。

依故障現象逐步縮小排查範圍

排錯記錄應包含系統版本與架構、用戶端和核心版本、故障發生時間、監聽連接埠、明確指定代理的測試結果，以及故障前後的錯誤記錄。分享前請移除訂閱網址、驗證權杖、節點密碼及個人網域資訊。每次只變更一個條件，才能分辨權限、監聽、規則與網路出口問題。