Clash 常見問題

Clash 通常指代理工具生態系，也可能特指較早期的核心專案；mihomo 是由 Clash Meta 演進而來的核心，負責解析設定、處理 DNS、比對規則並建立對外連線。用戶端則提供訂閱管理、策略選擇與系統代理等操作介面。排查問題時，應分別記下用戶端名稱與核心資訊，不能只說安裝了 Clash。介面相同不代表使用相同核心；設定欄位是否受支援，應以實際執行的核心文件與啟動日誌為準。

用戶端是管理連線與執行分流的工具，安裝完成不代表已有可用的代理出口。通常還需要自行準備有效的訂閱連結，或填入有權使用的節點參數。訂閱可能包含節點、策略組與規則，也可能只提供節點清單；匯入前應確認服務提供者提供的格式。訂閱網址中的存取權杖應視為憑證妥善保管，分享截圖、日誌或使用線上轉換服務時，都要遮蔽完整連結。本網站提供用戶端下載與設定說明，不提供訂閱，也無法恢復服務提供者停用的帳戶。

日常使用建議先從規則模式開始：連線依照 rules 的順序比對，由第一條符合的規則決定出口策略。全域模式通常會將已進入核心的連線交由統一的全域策略處理，適合短時間比對測試；直連模式則會讓這些連線嘗試直接存取。此處的全域是指出口決策，不代表所有應用程式的流量都會自動進入用戶端。應用程式是否由用戶端接管，仍取決於系統代理、應用程式代理設定或 TUN。切換模式後，請建立新連線再測試；已建立的長連線可能仍沿用原本的出口。

全新安裝可先查看 Clash Plus，再比較 Clash Verge Rev、FlClash 等用戶端的系統支援與操作方式；需要特定功能時，應查閱目前的發行說明，不要只依舊教學中的名稱選擇。遷移前請備份訂閱網址、自訂規則與必要的偏好設定，再於新用戶端重新匯入設定。舊用戶端的資料庫、服務元件與介面設定不一定能直接複製。遷移期間，一次只讓一個用戶端接管系統代理或 TUN；確認新設定可正常使用後，再移除舊服務。

先在系統資訊中確認作業系統版本與處理器架構，再查看下載項目的適用說明。Windows 的 x64 與 ARM64、macOS 的 Intel 與 Apple Silicon、Android 的 arm64 與 arm，不能只憑裝置外觀判斷。Linux 也要確認發行版的套件格式與執行相依項目。安裝程式提示不相容時，請先核對這些條件，不要隨意更改檔案副檔名來嘗試安裝。最低系統需求以該用戶端目前的發行說明為準；較舊的系統即使能啟動程式，也可能缺少系統代理或虛擬網卡所需元件。

先分辨是下載失敗還是內容解析失敗。下載失敗時，檢查訂閱是否到期、權杖是否已重設，以及更新請求使用直連還是代理；若代理尚不可用，且用戶端允許，可改用直連更新。下載成功卻沒有節點時，檢查取得的內容是否為登入頁面、錯誤訊息或不相容格式，並確認訂閱需要的是完整設定，還是代理集合入口。請勿將私人訂閱貼到公開的轉換網站。確認網址無誤後仍遭拒絕存取或出現帳戶錯誤，應洽詢訂閱服務提供者；反覆重新安裝用戶端通常無法解決問題。

遠端訂閱更新可能會重新產生整份設定，直接編輯產生檔案的內容就會被覆寫。先確認用戶端實際載入的檔案，再使用該用戶端支援的覆寫、合併或設定擴充功能保存本機修改。規則陣列可能整批取代，也可能依指定位置插入，視用戶端的實作而定；新增規則也必須引用現有的策略組。修改後請檢查最終生效的設定與核心日誌，不能只看編輯器中的原始片段。建議先備份原設定，每次只修改一類欄位，再更新一次訂閱，確認修改是否保留。

TUN 需要建立虛擬網路介面，並可能修改路由，通常需要用戶端的服務元件或系統授權。先依照目前用戶端的說明安裝並啟動服務，再確認系統彈出的網路延伸功能、VPN 或管理員授權提示是否已完成；Linux 還需檢查 TUN 裝置與程序所需的權限。不要為了消除提示而長期關閉防火牆，或放寬所有檔案的權限。授權後若仍失敗，請查看日誌中首次出現的錯誤，並確認沒有其他 VPN 正在接管路由。TUN 只決定流量如何進入核心，啟用後仍需要可用節點與正確規則。

策略組的選擇只會影響最後指向該組的連線，不會自動套用至所有規則。先在連線面板確認目標連線是否已進入核心，再查看符合的規則與最終出口；如果規則指向 DIRECT，修改其他代理組不會改變結果。規則通常由上而下比對，範圍較廣的前置規則可能會遮蔽後方更精確的規則。也要檢查巢狀策略組是否繼續指向其他組，以及應用程式是否略過系統代理。調整後先關閉原連線再重試，比連續切換多個節點更容易判斷是哪項設定造成影響。

自訂規則通常應放在可能先行符合的廣泛規則之前，並透過用戶端支援的持續覆寫入口加入設定。DOMAIN 用於比對指定網域，DOMAIN-SUFFIX 用於比對網域後綴；兩者都應填寫網域，而非完整網址，不包含通訊協定、路徑或查詢參數。規則末尾的策略名稱必須與現有節點、策略組或內建策略相符。MATCH 是沒有其他條件時使用的兜底規則，通常放在規則清單最後；若放得太前面，後續規則就沒有比對機會。儲存後以新連線檢查符合記錄，確認規則已載入且確實生效。

Fake-IP 模式會向應用程式回傳保留位址範圍內的映射位址，由核心保存該位址與網域的對應關係，再依網域處理實際連線；它不會修改網站權威 DNS 中的真實記錄。部分區域網路探索、裝置控制，或直接依賴真實解析結果的應用程式，可能需要加入 fake-ip-filter。過濾項目只會影響解析行為，不代表將該網域的存取策略改為直連。遇到相容性問題時，先縮小範圍至特定網域，新增最少的過濾項目，再清除相關 DNS 快取並重新建立連線，避免直接過濾所有網域而掩蓋真正原因。

部分受 AppContainer 隔離的 Windows 應用程式無法直接存取本機迴圈位址，而本機代理通常會監聽迴圈位址，因此即使瀏覽器可以使用，這些應用程式仍可能連線失敗。先確認目標應用程式確實受到此限制，再使用用戶端提供的 UWP 迴圈工具，或系統的 CheckNetIsolation 工具，只為需要的應用程式新增迴圈豁免。操作可能需要管理員權限，完成後應重新啟動目標應用程式。並非所有市集應用程式都是 UWP，也不是所有連線失敗都由迴圈限制造成；若日誌中已有連線記錄，應繼續檢查規則與節點，而非反覆新增豁免。

先確認本機網路可以正常連線，再查看日誌確認失敗的是節點伺服器解析、連線至伺服器，還是測速目標的請求。測速逾時只表示該測試請求未能在期限內完成，不能單憑這點判定節點永久失效。可用另一條已知可用的出口連線相同目標作為對照，同時檢查裝置時間、訂閱有效期限、伺服器連接埠與通訊協定參數。如果所有節點同時失敗，優先檢查本機網路與共用設定；如果只有個別節點失敗，再向服務提供者確認狀態。只有出現明確的解析錯誤時，才需要調整 DNS。

先記下解析失敗的網域、錯誤時間與使用的解析器，分辨是節點伺服器網域還是目標網站網域無法解析。檢查設定中的 DNS 上游是否可連線，以及加密 DNS 上游本身的網域是否有可用的引導解析路徑。使用 TUN 時，也要確認系統 DNS 請求是否如預期進入核心，避免與其他 DNS 工具互相接管。每次只更換一個上游或一項路由設定，清除快取後重試，並保留對照日誌。不要同時啟用多項 DNS 接管功能，否則即使問題短暫改善，也難以判斷是哪項設定生效。

系統代理是供應用程式讀取的代理設定，不會強制所有程式使用；部分命令列工具、遊戲或使用自有網路堆疊的應用程式會忽略它。先確認系統中的代理位址與連接埠是否和用戶端的監聽值一致，再查看連線面板是否出現目標應用程式的請求。沒有記錄時，檢查應用程式本身的代理設定、代理環境變數與略過清單，必要時在確認權限後使用 TUN。已有記錄時，則沿著規則與出口方向排查。測試期間請關閉其他代理用戶端，避免互相覆寫系統設定；也不要將 TUN 和全域出口模式視為同一個開關。

連接埠被占用表示所需的監聽位址已由其他程序使用。先確認是否重複啟動用戶端，或舊的背景核心與服務仍在執行。確認程序用途後再正常停止，切勿直接結束不熟悉的系統程序。也可以更換本機監聽連接埠，但必須同步更新系統代理與應用程式中手動填寫的連接埠。退出後若網路異常，先檢查系統是否殘留指向已停止用戶端的代理設定，再確認其他 VPN、路由與 DNS 狀態。優先透過用戶端正常關閉接管功能後退出；只有一般方式無效時，才考慮重設系統網路，並事先記錄原有網路設定。