Clash 常見問題
設定與故障排查

核心負責解析設定、比對規則並建立連線；圖形客戶端則負責管理訂閱、設定選項及顯示記錄。mihomo 延續 Clash.Meta 的開發方向，支援的協定與欄位和原版 Clash 不盡相同。教學中的設定位置可能因客戶端而異，排查時應一併記下客戶端名稱、核心類型及作業系統。即使介面版本相同，也不代表兩台裝置支援相同的協定。

客戶端是連線工具，安裝檔通常不包含可直接使用的遠端連線資訊。訂閱或設定檔會提供伺服器位址、驗證參數、策略群組及分流規則。匯入前先確認提供方支援目前核心使用的格式，別把網頁網址或帳戶管理頁面當成訂閱連結。訂閱網址可能含有帳戶憑證，不應貼到論壇、截圖或線上轉換工具；需要他人協助時，只提供已移除敏感資訊的錯誤描述。

規則模式會依序比對設定中的規則，由符合的策略決定連線走代理或直連，適合日常使用。全域模式會將進入核心的連線交由全域策略處理，適合短暫確認問題是否來自分流規則，但不會自動接管所有應用程式。直連模式會讓進入核心的連線直接連至目標，不等於退出客戶端。排查完成後請切回規則模式，並確認全域或規則策略群組沒有仍選用臨時測試項目。

系統代理會向作業系統登記代理位址，主要影響遵循這項設定的應用程式；部分程式會使用自己的代理設定，或完全忽略系統代理。TUN 透過虛擬網卡和路由接管符合條件的流量，適合需要涵蓋其他應用程式的情況，但仰賴權限、路由及 DNS 設定。初次設定時，建議先用系統代理確認訂閱可用，再視需要啟用 TUN。同時開啟兩者不一定更好；發生問題時應分別測試，避免混淆流量入口。

在客戶端的訂閱、設定或 Profiles 頁面選擇透過 URL 匯入，貼上提供方給的完整訂閱網址，再執行下載或更新。看到設定名稱不代表已啟用：還要將它設為目前設定，確認策略群組中有可選擇的出口，並選好節點。接著切換到規則模式、開啟系統代理，再用瀏覽器測試實際需要使用的服務。若出現解析錯誤，先確認訂閱格式，別反覆修改連線密碼碰運氣。

先查看核心記錄，判斷是權限不足、建立虛擬網卡失敗，還是新增路由失敗。Windows 客戶端通常需要安裝並啟動服務模式；macOS 可能需要允許網路延伸功能或授予管理員權限；Linux 則視客戶端服務及網路管理權限而定。優先使用客戶端提供的服務安裝功能，別長期以高權限執行所有程式。如果同時使用其他 VPN 或虛擬網卡工具，先暫停連線再測試；確認權限正常後，再檢查 TUN 設定。

保留錯誤記錄中的欄位名稱與行號，再檢查附近幾行。YAML 縮排應使用空格，並在同一層級保持一致；清單標記後要留空格，也要確認冒號、引號及策略群組名稱。若提示代理類型未知或欄位不受支援，應檢查核心功能，而不只是調整縮排。先備份設定，每次只修改一處再重新載入。訂閱產生的設定也可能在下次更新時被覆寫，長期修改請使用客戶端支援的覆寫或合併功能。

開機自動啟動只代表客戶端會嘗試啟動，不一定會一併啟用系統代理、TUN 或背景服務。重新啟動後，先確認客戶端程序與核心都在執行，再檢查目前設定是否已載入、系統代理是否開啟，以及 TUN 服務是否正常。部分桌面系統的自動啟動是在登入後執行，而非登入前。如果網路尚未就緒，訂閱更新可能會先失敗；待網路連線完成後手動更新一次，以免誤把啟動時序問題當成訂閱失效。

優先使用客戶端的規則覆寫、擴充設定或合併設定功能，別直接修改訂閱下載產生的暫存檔。規則通常由上往下比對，特定網域應排在廣泛規則與最終兜底規則之前，目標策略名稱則必須與現有策略群組完全一致。儲存後重新載入，並在連線清單中確認該請求符合哪條規則。既有連線可能繼續沿用舊策略，須重新建立連線才能驗證；修改前先備份，若分流錯誤才能還原。

延遲測試主要反映向指定測試位址發出請求所需的時間，不等於可用頻寬，也無法代表所有目標服務的使用體驗。下載速度還會受伺服器負載、線路壅塞、封包遺失、目標網站及本地網路影響。比較節點時，應使用相同網路、目標及相近時段；先確認服務能否穩定開啟，再觀察持續傳輸速度。別只看最低毫秒數就反覆切換；若只有特定網站速度慢，也應檢查實際套用的規則與出口策略。

兩台裝置必須位於彼此可連線的區域網路。電腦端啟用允許區域網路連線，確認監聽位址沒有僅限本機迴圈位址，並在防火牆中只對可信任的網路開放代理連接埠。另一台裝置要填入電腦的區域網路 IP 和實際的 mixed-port 連接埠，而不是 127.0.0.1。手動設定 HTTP 代理通常只會涵蓋遵循此設定的應用程式，不代表所有流量都已接入。使用完畢後請關閉分享，避免在公共網路上開放未設存取控制的代理入口。

Fake-IP 模式會為網域指派用於內部映射的位址，核心據此將後續連線對應回網域，以協助規則分流。這些位址並非目標伺服器的實際位址，因此不能只看解析結果就判定 DNS 出錯。如果印表機、NAS 或內部網域無法正常存取，先確認本地 DNS 和網域後綴，再依核心文件設定 fake-ip-filter 及相應的解析策略。修改後清除相關 DNS 快取並重新建立連線，避免舊快取讓測試結果看起來沒有變化。

先檢查裝置時間與基本網路連線，再向訂閱提供方確認帳戶、有效期限及連結是否已重設。401 通常與驗證失敗有關，403 表示請求遭拒，但實際原因仍應以提供方說明為準。若回傳的是登入頁面而非設定內容，請重新取得正確的訂閱網址；若是逾時，再檢查訂閱更新使用直連還是透過代理下載。別將完整連結貼到公開頁面，也不要在來源不明的轉換網站輸入網址嘗試修復。

先關閉代理入口，確認本地網路本身能正常連線，再檢查設定是否更新成功及裝置時間是否正確。測試位址無法連線時，也可能導致所有節點都逾時，因此應搭配實際服務連線情況與核心記錄判斷。若只有一個節點失敗，檢查該節點狀態；若所有連線都在解析或交握階段失敗，再依序確認 DNS、驗證資訊及核心支援的協定。每次只變更一個條件，並暫停其他 VPN，避免同時修改連接埠、DNS 和模式後無法判斷原因。

先查看客戶端的連線清單：有記錄但走直連，通常要檢查規則與策略選擇；完全沒有記錄，則要確認應用程式是否使用系統代理。瀏覽器擴充功能、應用程式內的手動代理設定及代理略過清單，都可能覆蓋系統設定。確認系統代理位址與連接埠是否符合目前的監聽值；變更 mixed-port 後尤其要同步更新。命令列工具也可能讀取獨立的代理環境變數。確認一般瀏覽器請求能進入核心後，再考慮透過 TUN 處理不遵循系統設定的應用程式。

部分 AppContainer 應用程式受到網路隔離限制，無法直接存取本機迴圈代理。先確認一般桌面瀏覽器能透過相同代理連線到目標，再使用客戶端提供的 UWP 迴圈工具，只為需要的應用程式新增迴圈豁免；這項操作通常需要管理員權限。並非所有市集應用程式都是 UWP，也不是所有連線失敗都由迴圈限制造成。新增豁免後若仍無法連線，請繼續檢查連線記錄、應用程式的代理支援與防火牆設定，別直接為所有應用程式批次放寬權限。