Clash 用戶端/下載與設定

Clash、Clash Meta 與 mihomo 的關係

Clash 最初建立了以 YAML 設定、策略群組與規則分流為核心的使用方式。原版專案停止維護後，社群持續發展相容的生態系。mihomo 延續 Clash Meta 的專案方向，並持續發展代理協定、規則集、網域嗅探與網路接入等功能。因此，舊教學提到的 Clash Meta，與目前文件中的 mihomo 通常屬於同一條核心發展脈絡；但這不代表所有舊欄位都與目前的實作一致。

用戶端是附有操作介面的應用程式，核心則是實際處理網路連線的程式。用戶端可能內建特定核心，也可能允許使用者更換核心。要判斷某項功能是否可用，應同時確認核心是否支援、用戶端是否提供對應設定，以及目前系統是否符合權限要求。只知道應用程式名稱，卻沒有執行環境資訊，通常不足以判斷某段設定能否直接使用。iOS 等平台另有各自的網路接入機制，不應直接套用桌面端的實作結論。

從公開文件追查設定欄位

需要核對欄位時，可先查閱 mihomo 設定文件，再參考 mihomo 原始碼儲存庫中的說明、發布紀錄與問題討論。公開原始碼有助於理解實作與釐清問題，但不代表每個圖形介面用戶端都提供相同名稱的選項。本網站將常用概念整理成詞條，完整設定方式則收錄於進階手冊，避免把介面操作路徑與底層參數混寫成固定流程。

閱讀範例時，請分清完整檔案與局部片段。rules 中的策略名稱必須已在設定中定義；rule-providers 引用的檔案必須確實存在；DNS 監聽與控制介面也須避開其他程式已使用的連接埠。YAML 使用空格表示階層，請勿用定位字元取代縮排。儲存前先使用用戶端的設定檢查功能，再重新載入，並從記錄確認是否成功。若介面仍顯示舊設定，先確認目前啟用的項目，不要重複匯入同一個連結。

設定更新與本機修改的界線

應用程式更新、核心更新與訂閱更新影響不同層面。應用程式更新可能變更介面與服務元件；核心更新可能改變協定實作或欄位行為；訂閱更新則可能替換伺服器、策略群組與規則。升級前請保留目前可用的設定與本機覆寫，並閱讀相關發布說明；升級後先確認原有連線正常，再逐項啟用新功能。不要把「訂閱更新成功」當成伺服器必定可用，也不要以為「安裝完成」就代表系統代理已接管所有應用程式。

長期使用時，建議由訂閱管理遠端內容，本機覆寫則保留個人設定。例如只替少數工作網域新增規則，或保留本機監聽位址與 DNS 偏好。各用戶端的覆寫、合併方式與執行順序不盡相同，應先確認最終產生的設定，不要只看編輯器中的局部內容。若確實需要合併多個訂閱，還須處理重複的策略群組名稱、重複規則與出口相依關係；相關操作整理於設定進階手冊，不建議在首次連線時一併處理。

從連線記錄找出問題

遇到「無法上網」時，先拆解為接入、解析、規則與出口四個環節。瀏覽器是否讀取系統代理、核心是否看得到連線、網域是否解析成預期結果，以及連線最後符合哪個策略，這些資訊比反覆更換設定更有診斷價值。若核心沒有連線記錄，優先檢查接入方式；若有記錄但策略錯誤，檢查規則順序與群組內的選擇；若策略正確仍無法連線，再檢查訂閱狀態、節點協定與出口網路。每次只修改一項設定，才能從結果判斷原因。

延遲測試只反映特定測試目標、協定與當下網路條件的測量結果，不能取代實際服務驗證。網頁、影片與命令列工具可能使用不同的 DNS、連線重用方式與傳輸協定。驗證時先選定一個目標應用程式，查看連線記錄，再確認出口是否符合規則預期。分享排查資料時，只保留錯誤類型與必要欄位，並移除訂閱網址中的存取參數、伺服器密碼與個人網路識別資訊。更多操作方式請參閱常見問題。

初次使用的設定順序

已有可用訂閱時，先安裝符合系統架構的用戶端，再於設定頁面匯入訂閱並設為目前使用的設定。接著選擇 Rule 模式，並在實際使用的策略群組中選取節點，再啟用系統代理或行動裝置的 VPN 接入。先確認常用應用程式能否連線，再檢查規則是否符合預期。依照這個順序分別驗證設定有效性、流量接入與出口選擇，發生問題時更容易找出卡住的步驟，而不是一次開啟所有網路選項後逐一猜測。

只有在目標程式不遵循系統代理，或確實需要涵蓋更多流量時，才進一步設定 TUN。啟用前先關閉其他可能變更路由的 VPN，記下目前的 DNS 與代理設定，並依用戶端指示安裝服務或授予權限。若發生網路異常，先撤銷剛才的變更，恢復至已知可用的狀態。入門教學依序說明匯入、選擇、接入與驗證；術語表可供隨時查閱名詞，兩者與進階手冊各有不同用途。