Clash 常見問題
與故障排查

Mihomo 是負責代理協定、規則比對、DNS 與連線轉送的核心；Clash Plus、Clash Verge Rev、FlClash 等用戶端則在其上提供設定匯入、策略切換及系統代理控制介面。排查問題時，應區分介面故障、設定錯誤與核心連線錯誤；通常只有後兩類會出現在執行記錄中。

設定檔是用戶端實際載入的 YAML 內容，通常包含代理節點、策略組、規則、DNS 與連接埠欄位。訂閱連結是取得設定檔的網址，更新訂閱時會重新下載並取代對應的 Profile。修改由訂閱產生的本機副本前，應先確認用戶端更新時是否會覆蓋變更；需要長期保留的規則，較適合放在覆寫或合併設定中。

規則模式會依設定中的 rules 由上到下進行比對，適合日常使用；全域模式會將流量交給同一個代理策略，適合短時間確認節點是否可用；直連模式則略過代理，適合檢查問題是否由 Clash 連線路徑造成。排障時可先在全域與直連之間切換，根據結果判斷故障位於節點、規則或本機網路。

系統代理只會接管遵循作業系統代理設定的應用程式，瀏覽器與多數桌面應用程式通常可正常使用，但部分遊戲、命令列程式和商店應用程式可能繞過代理。TUN 模式透過虛擬網路介面接管更大範圍的流量，也需要額外的系統權限。一般可先使用系統代理；確認有應用程式繞過後，再啟用 TUN 並檢查路由與 DNS 設定。

Fake-IP 會為網域回傳保留位址，並由 Clash 維護網域對應，規則比對效率較高，適合大多數一般設定。Redir-Host 會回傳實際解析結果，較能相容於依賴區域網路探索、特殊網域驗證或固定解析結果的應用程式。遇到印表機、投放、企業內網或部分遊戲異常時，可先將相關網域加入 fake-ip-filter，而不是直接更換整個 DNS 模式。

開啟用戶端的連線記錄或記錄頁面，重新存取目標網站，查看網域、目標位址、規則類型與最終策略組。規則會依設定檔中的順序由上到下比對，較寬泛的 DOMAIN-SUFFIX 或 GEO 類規則可能提前攔截請求。若結果不符合預期，應將更具體的 DOMAIN 規則放在寬泛規則之前，並在更新訂閱後再次確認覆寫順序。

用戶端延遲測試通常只測量對指定測試位址發出一次 HTTP 請求所需的時間，無法完整反映封包遺失、尖峰時段壅塞、線路頻寬、目標網站位置與連線重用情況。判斷節點品質時，應同時觀察多次測試的穩定性、實際下載速度與目標網站回應。一個延遲較高但穩定的節點，實際體驗可能優於數值較低卻頻繁逾時的節點。

mixed-port 同時接受 HTTP 與 SOCKS5 連線，適合只想維護一個本機連接埠的情境；port 僅提供 HTTP 代理；socks-port 僅提供 SOCKS5 代理。應用程式手動填寫代理時，協定與連接埠必須相互對應。若用戶端已使用 mixed-port 7890，其他程式就不能再監聽相同位址與連接埠；修改後也要同步更新系統代理或應用程式內的代理設定。

先確認設定中的 dns.enable 已啟用，並檢查 nameserver、proxy-server-nameserver 與 fallback 等欄位是否符合目前核心的語法。接著分別在直連與代理狀態下查詢相同網域，比對系統解析結果、Clash 記錄中的 DNS 請求與實際連線目標。若應用程式啟用了自己的加密 DNS，可能會繞過系統與 Clash DNS；此時需在應用程式中關閉該功能，或透過 TUN 與規則明確接管。

為每個 Profile 使用能辨識來源與用途的名稱，並保留獨立的更新時間與覆寫設定。訂閱內容適合由伺服器更新，本機規則則適合放在獨立檔案或用戶端的 Merge、Override 功能中。切換 Profile 後要重新檢查策略組，因為不同設定可能使用相同名稱的策略，但包含不同節點。刪除舊設定前，先確認沒有自動化指令碼或系統服務仍在引用它。