Clash 常見問題

Clash 是代理核心及其設定生態系的常見名稱；Clash Meta 曾是相關衍生核心使用的名稱，後續以 mihomo 之名持續發展。用戶端則提供匯入設定、系統代理、檢視連線等圖形介面功能。判斷功能是否可用，應確認用戶端實際搭載的核心及其版本，而非只看應用程式名稱。舊教學中的欄位也應對照目前的核心文件，避免混用不同核心的設定。

用戶端負責載入設定並執行核心，安裝完成不代表就能自動使用遠端代理服務。訂閱通常會提供代理連線參數、策略群組與規則，手動撰寫設定也能達到相同目的。先確認設定來源可信，再檢查是否成功載入，以及策略群組是否有可選項目。訂閱網址通常包含存取憑證，不應貼到公開留言、截圖或線上轉換頁面；排查時只提供已遮蔽敏感資訊的錯誤訊息。

規則模式會依 rules 順序，為已進入核心的連線選擇策略，適合日常分流；全域模式會讓這些連線使用全域策略，適合暫時比較某條代理路徑；直連模式則讓這些連線直接連到目標。模式只決定核心收到流量後的處理方式，不代表系統接管範圍有所改變。切換模式後，應建立新連線並查看連線紀錄；瀏覽器既有的長連線可能仍沿用原本的出口路徑。

系統代理會透過作業系統設定，引導遵循該設定的應用程式連線至本機代理連接埠；TUN 則透過虛擬網路介面與路由接管流量，可涵蓋部分不讀取系統代理設定的程式。初次設定建議先用系統代理確認可正常運作，再依實際需求啟用 TUN，不必一開始就同時啟用兩者。TUN 的涵蓋範圍仍受路由、排除項目、權限與平台限制影響，不能只看開關狀態就認定所有應用程式都已進入核心。

不能只因設定檔可以匯入，就認定所有欄位都會生效。行動版用戶端對訂閱格式、規則語法、擴充欄位及網路接管方式的支援，可能與桌面版不同。選好用戶端後，先確認其支援的設定格式，再查看匯入提示與連線紀錄。Clash Plus 可從下載頁的 iOS 分類前往 App Store，官方網站為 clashplus.io；桌面版的服務安裝與系統代理操作不適用於 iOS。

先檢查裝置時間、目前網路與訂閱帳戶狀態，再確認網址是否完整複製，以及是否混入空格、換行或已過期的存取參數。記下用戶端顯示的 HTTP 狀態碼：401、403 通常與授權或存取限制有關，404 可能表示網址已變更，逾時則應繼續檢查網路路徑。若用戶端提供訂閱更新的代理設定，可分別測試直連與透過代理取得；不要反覆刪除仍可用的舊設定，也不要公開完整訂閱網址。

先查看錯誤訊息中的行號與欄位名稱，再檢查該行及前一段內容的縮排、冒號與清單符號。YAML 縮排應使用空格，使用全形冒號或 Tab 字元容易造成解析失敗。若語法檢查通過，但核心仍拒絕載入，接著確認策略引用是否存在，以及目前的核心是否支援相關欄位。保留原始檔案，並在副本中逐段還原最近的修改；不要將含有訂閱憑證或代理密碼的完整檔案上傳至公開的線上檢查工具。

mixed-port 會在同一個連接埠接受 HTTP 與 SOCKS 代理連線；7890 是常見設定值，並非所有用戶端都必須使用的固定連接埠。修改後先重新載入設定，確認核心實際監聽新的連接埠，再同步更新系統代理、瀏覽器擴充功能與命令列環境變數。若使用用戶端的覆寫設定，也要確認它是否取代了訂閱中的連接埠欄位。只修改設定檔、卻保留系統中的舊連接埠，可能導致用戶端正常運作但應用程式無法連線。

先查看日誌，分辨是權限不足、虛擬介面建立失敗，還是路由寫入失敗。Windows 用戶端可能需要安裝並啟動背景服務，或依用戶端說明使用管理員權限；macOS 需要核准相應的網路權限；Linux 通常涉及 TUN 裝置與網路管理權限。服務模式是 GUI 用戶端的執行機制，並非通用的 YAML 欄位。授權或安裝服務後，重新啟動核心，再確認虛擬介面與路由狀態；避免讓無關程式長期以高權限執行。

不要把需要長期維護的規則直接寫入會隨訂閱更新而遭取代的快取檔案。優先使用用戶端提供的覆寫、合併或腳本功能，將個人規則與 DNS 調整另存於獨立位置。先確認該用戶端的合併方式：清單可能遭取代，也可能附加在後，規則順序也可能改變。更新完成後，檢查最終生效的設定，不要只看編輯器中的本機檔案；升級用戶端前先備份覆寫檔案，並記錄策略群組名稱之間的相依關係。

select 適合手動固定出口；url-test 會依指定測試網址的探測結果選擇成員；fallback 通常依成員順序選擇可用項目。自動探測只反映測試目標與測試當下的狀況，不能代表所有網站與通訊協定。可用 select 納入一個自動群組，保留臨時手動切換的選項。排查時先固定一個已確認可用的成員並建立新連線，避免自動切換導致同一次測試混入不同出口的結果。

開啟用戶端的連線清單，再重新造訪目標網站，依網域或處理程序篩選，查看符合的規則、目標策略與實際出口路徑。規則通常由上往下檢查，第一條符合的規則會生效，因此新增規則必須放在可能先攔截它的寬泛規則之前。若只看到 IP、沒有網域，應接著檢查 DNS 路徑與嗅探條件。修改後先關閉該網站的舊連線再測試，不要只憑網頁能否開啟就判定規則已生效。

啟用 Fake-IP 後，核心可向應用程式回傳映射位址，再利用映射關係還原網域並進行分流。若設定使用 fake-ip-range: 198.18.0.1/16，解析結果落在該範圍本身不代表發生故障。關鍵在於後續連線是否回到維護映射的核心。遇到區域網路裝置探索或特定應用程式的相容性問題時，再為確實需要的網域設定 fake-ip-filter；不要只因看到映射位址就全面停用 DNS 功能。

先確認兩台裝置位於彼此可連線的網路，再檢查 allow-lan、監聽位址與主機防火牆。其他裝置的代理伺服器應填入執行用戶端的區域網路 IP，而非 127.0.0.1，並使用實際監聽的 mixed-port。開放範圍應限於可信任的區域網路，必要時設定驗證；不要透過路由器將代理連接埠轉送至公網。主機 IP 變更、訪客網路隔離及無線基地台隔離，都可能造成連線失敗。

選擇一個需要驗證的目標，先清除該目標的舊連線，再查看用戶端連線清單是否出現對應請求，以及策略鏈是否符合預期。若要排除瀏覽器設定的影響，可在終端機使用 curl -I -x http://127.0.0.1:7890 https://example.com 測試明確指定的 HTTP 代理；請將連接埠換成實際使用的值。此命令只驗證這次請求的代理路徑，不代表系統代理、UDP 或所有應用程式都已正常接管。

先比較多個成員在不同網路下的結果。若只有一個成員失敗，檢查該成員的參數、服務狀態與通訊協定支援；若全部失敗，優先檢查裝置時間、網路連線、DNS 與設定是否已載入。接著確認測試網址是否可連線，測試端點故障也會造成全部逾時。探測成功不代表實際使用一定正常，探測失敗也不足以單獨證明服務失效；應搭配實際請求與日誌中的交握、解析或連線錯誤來判斷。

先確認系統代理指向的位址與連接埠是否和核心監聽設定一致，再檢查瀏覽器擴充功能、代理略過清單及其他代理軟體是否改寫設定。終端機程式不一定會讀取作業系統代理，可能需要另外設定 HTTP_PROXY、HTTPS_PROXY，或使用程式的明確代理參數。比較明確指定代理與一般請求的結果，並查看連線紀錄。若明確指定代理時運作正常、一般請求卻未進入核心，應著重檢查應用程式讀取代理設定的方式，而非一再更換節點。

先確認請求確實進入核心，再查看日誌是否有解析失敗、DNS 查詢逾時或上游連線失敗。檢查 nameserver 是否可連線；使用加密 DNS 時，也要確認解析其伺服器網域的引導路徑。使用 TUN 時，應檢查 dns-hijack 與應用程式內建的安全 DNS 是否影響預期路徑。每次只調整一個環節，重新載入設定，並視需要清除系統 DNS 快取、重新建立連線；不要一次更換所有 DNS 欄位，否則難以找出故障來源。

部分使用 AppContainer 的應用程式受到迴圈存取限制，無法像一般桌面程式一樣連線至本機代理。先確認目標應用程式是否屬於此類，再優先使用用戶端提供的迴圈豁免功能，只授權確實需要的應用程式。也可在系統管理員終端機執行 CheckNetIsolation LoopbackExempt -s 查看現有豁免，再依系統文件為指定套件設定。不要一次解除所有應用程式的限制；設定後重新啟動目標應用程式，並在連線清單中確認請求路徑。

先檢查系統代理是否仍指向已停止監聽的本機連接埠，關閉殘留設定，或重新啟動用戶端後正常退出。若使用 TUN，接著檢查背景服務、虛擬介面與路由是否已恢復；避免同時結束多個網路程式，以免難以判斷目前狀態。必要時依作業系統設定恢復自動 DNS，並重新建立網路連線。不要直接刪除不明網卡或清空所有路由；保留故障前後的設定與日誌，恢復後再逐一重新啟用相關功能。