Clash 常見問題

用戶端負責訂閱管理、系統代理切換與連線介面；核心負責協定連線、DNS 處理及規則比對。Clash Meta 是從原版 Clash 延伸出的核心分支，後來更名為 mihomo；用戶端名稱包含 Clash，不代表採用相同核心。要確認設定能否運作，先在「關於」或核心設定中確認實際使用的核心，再查看該核心支援的欄位與協定。移轉時請保留原設定備份，不要只憑介面相似度判斷相容性。

安裝用戶端只代表軟體已部署到本機，通常還需要匯入有效訂閱或自行維護的設定。訂閱會提供節點位址、驗證資訊與策略群組等內容，用戶端不會自動產生這些連線資源。匯入後請確認設定已啟用、策略群組中有可選項目，再選擇節點測試連線。若清單空白，先檢查訂閱回應內容與格式，不要反覆切換系統代理開關當作修復方式。訂閱期限與流量額度由服務提供者決定。

舊設定可能仍可運作，但用戶端已停止維護，不能因此認定它支援後來新增的協定與欄位。移轉到 Clash Verge Rev 等用戶端前，先記下訂閱網址、策略群組選項、連接埠與自訂規則，再逐項匯入測試。新用戶端能解析檔案，不代表所有行為都與舊環境相同，尤其要檢查 DNS、TUN 與覆寫設定。確認新環境正常後再關閉舊用戶端，避免兩個代理程序同時修改系統設定。

規則模式會依設定中的規則順序決定連線去向；全域模式通常將送進核心的連線交由全域策略群組處理；直連模式則讓送進核心的連線直接連往目標。三種模式改變的是核心收到連線後的處理方式，不會自動讓所有應用程式都把流量送進核心。初次使用建議選擇規則模式，並在連線頁面確認命中的規則。排查時可短暫切換到全域模式對照，測試後請恢復原模式，以免改變其他應用程式的連線路徑。

iOS 使用者可從下載頁前往 Clash Plus 的 App Store 頁面，並透過官方網站 clashplus.io 查看產品說明。訂閱能否通用取決於用戶端支援的協定與設定格式，不能只看訂閱名稱判斷。匯入前先確認服務提供者給的是哪種連結，匯入後檢查節點與策略群組是否完整。桌面版腳本、檔案路徑與部分 TUN 欄位不適合直接搬到手機；若出現不支援欄位的提示，請依行動版文件調整，不要一再重複匯入。

先確認裝置時間正確、訂閱網址完整，再檢查帳戶是否到期或流量額度是否用盡。查看用戶端顯示的更新錯誤：驗證失敗通常要核對連結憑證；逾時則檢查連線至訂閱伺服器的網路路徑；格式錯誤時確認回傳的是設定檔，而非登入頁面。若更新需要透過目前已失效的代理，可在用戶端允許的情況下改用直連更新。訂閱網址可能包含存取憑證，請勿提交給公開轉換站或貼在截圖中；若持續失敗，請洽服務提供者確認服務狀態。

先在作業系統的裝置資訊中確認處理器架構，再下載相符的安裝檔。常見的 Intel 與 AMD 桌上型處理器通常使用 x64；ARM 裝置優先選 ARM64。Apple Silicon 與 Intel Mac 也要分別選擇對應版本。Linux 還需區分發行版的套件格式，不能只看處理器架構。若安裝時提示系統不支援，請核對用戶端發行說明中的最低系統需求，不要靠更改副檔名或強制解壓取代正常安裝流程。

TUN 需要建立虛擬網卡並設定路由，桌面用戶端通常透過服務模式或提高權限來完成。先關閉 TUN，在用戶端設定中確認服務已安裝並正在執行，再依該用戶端的說明授權；Linux 的服務與權限設定則依安裝方式而異。公司裝置可能限制驅動程式與路由修改，這時請管理員確認相關政策。不要為了繞過錯誤而長期關閉防火牆，也不要同時啟動多個接管路由的工具；記下具體錯誤訊息後，再決定是否重新安裝服務。

系統代理只是提供代理位址給遵循這項設定的應用程式；有些程式使用自己的代理設定，既有連線也可能繼續沿用原設定。先核對系統設定中的位址與連接埠是否和用戶端的混合連接埠一致，再重新啟動目標應用程式，並在用戶端的連線頁面確認是否出現新請求。瀏覽器擴充功能、命令列環境變數或其他代理工具都可能覆寫系統設定。若應用程式確實不遵循系統代理，可評估使用 TUN；尚未確認流量入口前，不要直接修改節點或分流規則。

部分採用 AppContainer 隔離的 Windows 應用程式，預設無法存取本機回送位址，因此可能連不上監聽本機連接埠的代理。先確認受影響的確實是這類應用程式，再檢查用戶端是否提供回送豁免管理；只為需要的應用程式啟用，不要一次放行所有應用程式。並非所有從 Microsoft Store 安裝的程式都採用相同的隔離模型，這個結論也不適用於一般桌面程式。若改用 TUN 接管流量，也要重新查看連線紀錄，確認請求確實進入核心。

開啟用戶端的連線頁面，再從目標應用程式送出新請求，依網域或程序找出連線，查看套用的規則、策略群組與實際出口。既有長連線可能仍沿用原本的策略，因此修改規則後，請重新建立連線再判斷。規則通常依序比對，前面的寬泛規則可能先於後面的精確規則命中；也要確認目前使用的是規則模式。記錄中只出現網域解析資訊，不代表實際連線已走代理，應一併參考連線詳細資料與應用程式的連線結果。

更新訂閱時通常會重新下載並取代設定，直接修改下載的設定檔不一定會保留。需要長期使用的規則、DNS 設定與策略群組調整，應放在用戶端支援的覆寫或設定合併功能中，並確認合併順序。不同用戶端處理陣列附加、欄位覆寫與指令碼執行的方式可能不同，不要直接套用其他軟體的寫法。先用少量規則測試，再檢查合併後實際生效的設定；移轉用戶端時也要備份覆寫內容，不只是複製訂閱網址。

Fake-IP 會先回傳虛擬位址給應用程式，再由核心依照對應資料還原網域並建立連線，有助於保留網域資訊供分流使用。部分區域網路服務或依賴真實位址的應用程式可能不適合這種回應方式；應依實際問題將相關網域加入適當的過濾設定，而不是排除所有網域。修改後，請讓應用程式重新解析網域並建立新連線。實際過濾方式取決於核心版本與過濾模式，複製設定前先閱讀該版本的說明，避免誤解比對結果。

延遲測試通常只反映到特定測試位址的一次請求耗時，不等於大型檔案的傳輸速度，也無法代表所有目標網站。先用同一台裝置、同一個目標，在相近時間比較不同節點，再確認是否只有特定線路或應用程式變慢。接著檢查封包遺失、伺服器負載、策略群組出口與本機網路使用量。測速時暫停其他大量流量活動，避免同時測試互相干擾；若直連也一樣慢，先排查本機 Wi-Fi 或網路連線，不要只調整用戶端。

先觀察中斷是否總是在鎖定螢幕或切換網路後發生。Android 可檢查用戶端的背景執行權限、電池最佳化政策與系統 VPN 設定；不同廠牌也可能有額外的背景限制。iOS 則檢查用戶端的 VPN 狀態與記錄，不要把所有中斷都歸因於背景程序。若螢幕亮起時也連不上，再檢查訂閱期限與節點連線。協定保活、重新連線頻率與網路品質都會影響耗電，不能只憑協定名稱判定某種設定一定比較省電。

不一定。測試位址無法連線、DNS 異常、本機時間錯誤或核心未正常執行，都可能造成所有節點逾時。先確認一般網路連線正常，再查看記錄中的錯誤類型，選一個節點實際連線比對。若只有延遲測試失敗、網頁卻能正常開啟，可核對測試位址與測試方式；若實際連線也失敗，再檢查驗證資訊、帳戶狀態與伺服器位址。不要一次修改 DNS、TUN 和規則，否則很難找出原因；每次只改一項並記下原設定。

先確認沒有舊版用戶端或重複的執行個體仍在背景執行，再查看應用程式記錄、服務記錄或系統事件。若連接埠已被占用，先查出正在監聽的程序，關閉重複的代理或改用閒置連接埠，並同步更新系統代理與相關應用程式設定。若懷疑設定損壞，先備份設定資料夾，再依用戶端說明暫時使用新設定測試，不要直接刪除所有資料。執行階段元件或系統相容性錯誤，應依發行說明處理；提供一般錯誤截圖時，請遮蔽訂閱網址與驗證資訊。

先關閉 TUN 進行對照，確認問題確實與路由接管有關。檢查本機網段、公司 VPN 路由與虛擬網卡位址是否衝突，再依核心及用戶端支援的方式設定路由排除；只新增直連規則，不一定能解決流量被導向錯誤網卡的問題。公司網路也可能需要內部 DNS，應一併核對名稱解析路徑。不要盲目照抄別人的網段排除清單，也不要同時啟用多個自動路由工具；調整後分別測試公網、區域網路與公司資源。

先釐清預期：哪些網域要交給哪個解析器處理，請求應直連還是走代理；再比對核心記錄與檢測結果，確認實際路徑。檢測頁面顯示的解析器名稱或所在地只能作為線索，不能單獨證明發生 DNS 洩漏。瀏覽器安全 DNS、系統加密 DNS 與其他 VPN 都可能繞過用戶端的 DNS 設定。TUN 接管 DNS 也不代表會自動接管所有加密解析流量；請分別檢查應用程式設定、DNS 路由與代理出口，修改後重新建立連線再測試。

先檢查系統是否仍保留指向本機的代理位址；若代理程序已退出，該位址就會成為無效入口，應關閉殘留的系統代理。接著檢查 TUN 或 VPN 是否仍保持連線，以及其他應用程式是否保留手動代理設定或環境變數。建議重新開啟原用戶端，關閉系統代理與 TUN 後正常退出，避免直接強制結束程序。若問題仍在，再查看路由與 DNS 狀態；不要一開始就重設所有網路設定，以免清除公司網路與靜態位址設定。