Clash 常見問題與連線疑難排解

Clash 通常泛指一類支援規則分流的代理工具；mihomo 是相關生態系中持續發展的核心，負責解析設定、比對規則並建立連線。用戶端則提供操作介面、訂閱管理與系統整合；同名欄位是否可用，取決於實際使用的核心及其版本。開始排查前，先在「關於」或核心資訊中記下用戶端名稱與核心版本，不要直接照搬其他用戶端的操作步驟。

用戶端負責載入設定，不會自動提供可用的遠端代理服務。訂閱通常用來取得節點、策略群組與規則；也可以透過本機 YAML 完成設定。匯入後還要選取該設定檔，並在策略群組中選擇可用的出口。只有規則和空白策略群組的設定，無法憑空建立遠端代理連線。訂閱來源、到期日與服務額度請向提供者確認，安裝完成不代表服務已可使用。

日常使用通常選擇 mode: rule，讓連線依照 rules 由上而下比對；全域模式會將已進入核心的連線交由全域策略處理；直連模式則讓這些連線直接連出。這些模式與流量接管方式不同：若應用程式未使用系統代理、明確指定的代理或 TUN，切換模式可能影響不到它。排查時先確認記錄中有出現該應用程式的連線，再比較規則模式與全域模式的結果。

系統代理會提供代理位址給遵循系統設定的應用程式，但部分程式會忽略這項設定；TUN 則透過虛擬網路介面與路由接管流量，還涉及 DNS、權限及路由排除。初次設定時，建議先用系統代理確認訂閱與節點正常，再依應用程式需求啟用 TUN，不必一開始就開啟所有接管方式。TUN 能否涵蓋特定流量，也取決於平台限制與實際設定，不能只看開關已開啟就認定流量已被接管。

Profile 通常是用戶端中的一筆設定檔記錄，來源可以是遠端訂閱，也可以是本機 YAML。更新訂閱會重新取得提供者的內容；覆寫則是在載入設定時加入本機欄位、規則或策略群組調整。不同用戶端的合併順序不盡相同，直接編輯訂閱產生的檔案，可能在更新後遺失修改。若要長期調整，請先備份設定，再查看用戶端的覆寫說明，並確認最後實際生效的設定，而不只是編輯器中的原始文字。

先在設定或訂閱頁面確認匯入完成，並將這份設定選為目前使用的設定檔。接著查看更新結果：若回傳的是網頁、登入提示或錯誤訊息，都不能視為可用的設定。再確認訂閱是否仍有效，以及內容是否符合目前使用的核心。若解析成功卻看不到節點，請檢查 proxy-groups 是否引用了 proxies 或 proxy-providers。切勿公開完整訂閱網址；分享截圖時，也要遮住查詢參數中的存取憑證。

根據記錄中的行號，檢查附近的縮排、冒號與清單項目短橫線，尤其留意最近修改的部分。YAML 縮排必須使用空格，不能混入定位字元；同一層級的欄位要對齊，字串含特殊符號時視情況加上引號。行號有時會指向錯誤發生位置之後，因此也要檢查前一段。先還原上次可用的設定，再一次只修改一項。設定能成功解析，不代表所有引用都有效；還要確認策略群組名稱與規則目標確實存在。

先關閉 TUN，確認一般代理連線正常，再依用戶端提示安裝或修復服務元件。Windows 請檢查服務狀態與系統管理員授權；macOS 請依提示核准所需的網路權限；Linux 則確認用戶端支援的提權方式，以及 /dev/net/tun 是否可用。各用戶端的需求不同，請勿直接放寬所有系統權限。若仍無法排除，先關閉其他 VPN 或虛擬網卡工具再試，並記下建立介面失敗的原始記錄。

請分別檢查開機啟動、核心啟動與代理接管。部分用戶端只會在使用者登入後啟動介面，服務元件、系統代理或 TUN 不一定也會隨之啟用。重新開機後，確認用戶端程序正在執行、目前設定已載入、所選策略仍可用，再檢查系統啟動項目的授權。也要留意開機時網路尚未就緒，可能導致訂閱載入失敗。不要反覆新增多個啟動項目；多個執行個體反而可能爭用監聽連接埠。

先在系統的「關於」頁面確認處理器架構，再選擇對應的下載項目。Windows 常見 x64 與 ARM64；macOS 分為 Apple Silicon 與 Intel；Android 常見 arm64-v8a 與 armeabi-v7a；Linux 還要確認發行版使用的套件格式。架構不符可能導致無法安裝、無法啟動，或必須透過相容層執行。不要只憑裝置品牌判斷架構；更新前先備份設定，也不要混用用戶端安裝套件與獨立的 mihomo 核心檔案。

確認目前模式為 mode: rule，而且修改的是正在使用的設定檔。rules 會依順序比對；如果較廣泛的規則或 MATCH 放在前面，後面的規則就可能無法命中。檢查規則目標是否與策略群組名稱完全相同，再從連線記錄確認實際網域、目標位址與命中的規則。訂閱更新後失效的修改，應移至用戶端支援的覆寫位置；不要只把規則寫進未載入的本機備份檔案。

select 用於手動選擇出口，適合固定地區或需要維持出口一致的情況。url-test 會依指定測試網址的結果自動選擇，但測試連得上不代表所有服務都正常。fallback 通常依候選順序選擇可用出口，適合有明確優先順序的備援需求。先確認候選清單中的節點可用，再調整 url、interval 和 tolerance 等適用欄位；這三種群組類型都不會提升節點本身的頻寬。

先區分整份 Profile 的更新與 proxy-providers 的更新。前者通常在用戶端的訂閱設定中管理，單位以介面標示為準；後者由設定中的 interval 控制，mihomo 的這個欄位以秒為單位。health-check.interval 用於健康檢查，不代表重新下載訂閱。請依提供者的限制設定更新頻率；更新失敗時先手動重新整理並查看錯誤，不要用極短間隔反覆請求，以免觸發伺服器的流量限制。

只有目前用戶端不支援原始內容格式，而且提供者沒有合適的訂閱格式時，才考慮轉換。優先使用提供者提供的相容入口，或在本機使用可信任的工具。將連結提交給線上轉換服務，等於讓該服務取得存取訂閱的能力；轉換也無法解決訂閱到期、額度用盡或伺服器故障。轉換後請確認節點類型、策略群組與規則都有保留。若連結意外外洩，請向提供者重設訂閱網址。

開啟用戶端的連線清單或記錄，清除篩選條件後，從目標應用程式送出一次新請求，檢查對應的網域、程序、命中規則與最終出口。舊有的長連線可能仍沿用先前的策略，必要時可關閉目標應用程式後再試。網頁能開啟只代表這次請求成功，不能證明所有應用程式都已被接管；單一出口查詢頁面也只能反映連線到該頁面的流量。確認路徑後，再關閉詳細記錄，避免長期保留不必要的瀏覽紀錄。

先查看訂閱更新記錄，不要只看節點測試結果。HTTP 401 或 403 通常與存取授權有關，404 可能表示網址已變更，429 則代表請求過於頻繁；實際狀況仍應參考提供者的說明。遇到逾時，先檢查訂閱網域能否解析、目前網路是否正常，以及更新請求使用的連線路徑。解析失敗時，確認回傳內容是否為網頁或不相容的格式。若出現憑證錯誤，先確認系統時間；不要直接停用憑證驗證來掩蓋問題。

訂閱伺服器與代理節點是不同的連線目標，訂閱更新成功不代表節點可用。先更換節點與測試網址交叉比對，再確認服務額度、節點參數與系統時間。若只有某個節點失敗，請向提供者回報發生時間與錯誤訊息；若所有節點都失敗，再檢查本機防火牆、其他 VPN 及目前網路的限制。測試網址本身無法連線也會造成逾時，應搭配實際使用情況判斷，不要只憑單次測試結果就刪除整份設定。

先確認核心正在執行，並檢查系統代理的位址與連接埠是否和 mixed-port 或實際的 HTTP 監聽連接埠相同。接著確認瀏覽器是否使用獨立的代理設定、擴充功能或企業政策，以及代理略過清單是否包含目標位址。完全關閉瀏覽器後重新開啟，並查看連線記錄。若記錄中沒有請求，問題多半出在接管路徑；若已有請求，則繼續檢查命中的規則與出口。不要只為了方便本機連線就直接開放 allow-lan。

部分採用 AppContainer 隔離的 Windows 應用程式預設無法存取本機回送位址，因此可能無法連線至監聽在 127.0.0.1 的代理。先確認該應用程式確實使用本機代理，再使用用戶端提供的回送豁免工具，為需要的應用程式個別授權；該工具可能需要系統管理員權限。並非所有 Windows 應用程式都受此限制，請勿一次豁免所有程式。若授權後仍無法連線，請繼續檢查應用程式本身的代理行為、DNS 與防火牆，不要反覆新增相同豁免。

先關閉 TUN，確認基本網路能否恢復，再檢查記錄中的 DNS 逾時、路由衝突與介面錯誤。若設定啟用了 auto-route，請確認它與其他 VPN、容器網路及區域網路路由沒有衝突；若啟用了 dns-hijack，則要確認 DNS 服務正在執行且上游可連線。區域網路裝置異常時，還要一併檢查路由排除與規則；只新增 DIRECT 不一定能解決接管層的衝突。每次只調整一項，並保留可還原的原始設定。