# 基本結構範例，流量預設直連mixed-port: 7890allow-lan: falsemode: rulelog-level: infodns: enable: true enhanced-mode: fake-ip nameserver: - https://dns.alidns.com/dns-queryrules: - MATCH,DIRECT# 手動選擇群組，可加入現有節點名稱proxy-groups: - name: 出口選擇 type: select proxies: - DIRECT - REJECT # 規則目標與群組名稱保持一致rules: - MATCH,出口選擇# 此範例不包含代理服務# 由上而下比對，採用第一條符合的規則rules: - DOMAIN,example.com,DIRECT - DOMAIN-SUFFIX,example.org,DIRECT - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve - MATCH,DIRECT # DOMAIN 用於精確比對網域# DOMAIN-SUFFIX 包含子網域# no-resolve 可避免 IP 規則觸發 DNS 解析# 依實際需求替換規則目標CONFIGURATION / MIHOMO
客戶端負責匯入設定、顯示連線資訊及呼叫系統介面；核心則負責解析欄位、處理 DNS 並執行路由。排查問題時，先確認流量是否進入核心，再檢查符合的規則與最終出口。以下五類設定涵蓋日常最常調整的項目，範例僅用於說明結構，不含可用的代理節點。
規則路由會決定連線使用哪個出口。核心依清單順序比對，符合的第一條規則會先執行，因此精確網域應排在較廣泛的規則前面，最後再放兜底規則。設定中可以直接加入規則，也能透過規則集集中管理。相較於只切換全域出口，規則模式可讓不同目標採用不同策略。修改後，請在連線頁面查看目標網域、符合的規則與策略鏈，不要只憑瀏覽器能否開啟網頁判斷分流結果。
# 具體規則優先，兜底規則放最後
rules:
- DOMAIN,example.com,DIRECT
- DOMAIN-SUFFIX,example.org,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- MATCH,DIRECT策略群組會將規則目標與實際節點分開。規則指向固定的群組名稱，再由群組選擇節點；日常更換出口時，就不必逐條修改規則。手動選擇可使用 select，依探測結果自動選擇通常使用 url-test；需要在節點無法使用時切換備援，可考慮 fallback。相較於直接列出節點，策略群組更能呈現不同用途的出口偏好，但群組名稱必須與引用完全一致，群組之間也不能循環引用。延遲測試只反映對探測網址的請求狀況，不代表所有網站的傳輸速度與穩定性。
# 將實際節點名稱加入 proxies 清單
proxy-groups:
- name: 出口選擇
type: select
proxies:
- DIRECT
- REJECT
rules:
- MATCH,出口選擇DNS 設定會控制網域名稱的解析方式，以及核心如何保留網域與連線之間的關聯。fake-ip 會為請求回傳一個映射位址，再由核心連結至實際目標；這不是上游伺服器回傳的公網 IP。相較於單純替換系統 DNS，這種方式更方便網域規則參與路由，但相關流量必須確實經過核心。遇到區域網路裝置或特定應用程式的相容性問題時，應先檢查解析路徑，再視需要設定過濾，避免一開始就堆疊多個上游 DNS。調整後也要清除舊快取並重新建立連線。
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- https://dns.alidns.com/dns-query
fake-ip-filter:
- '*.lan'
- localhostTUN 透過虛擬網路介面接收流量，適合不會讀取系統代理設定的程式。它改變的是流量進入核心的方式，不會自動將所有連線改走代理；出口仍由目前模式與規則決定。相較於系統代理，TUN 更仰賴服務權限、路由與 DNS 接管，也較容易與其他 VPN 或虛擬網卡衝突。初次使用時，先確認一般代理連線正常，再單獨啟用 TUN。若發生斷網，先關閉 TUN、恢復原本狀態，再檢查服務狀態、路由與記錄；不要一次修改多個欄位。
# 需由客戶端支援並具備相應權限
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
# 同時檢查 DNS 設定與系統路由覆寫可將本機偏好與遠端設定分開保存，例如固定監聽連接埠、調整記錄層級或新增規則。直接編輯由訂閱產生的檔案，可能在下次更新時失去修改內容；透過客戶端提供的覆寫功能管理，較容易追蹤變更。請注意，覆寫並非所有客戶端通用的核心欄位集合；合併順序、清單項目的追加或取代方式，都取決於各自的實作。套用前先備份，套用後查看最終設定，不要只確認編輯框內容。若涉及規則清單，尤其要確認新增項目沒有排在兜底規則之後。
# 本機片段示意，匯入方式依客戶端而異
mixed-port: 7890
allow-lan: false
log-level: info
# 這不是名為 override 的頂層欄位
# 清單合併方式請參閱客戶端說明
# 套用後檢查最終產生的設定OPEN SOURCE / PROJECT BOUNDARIES
先了解專案層次，再選擇安裝與設定方式。開源儲存庫提供程式碼、發行紀錄與問題討論；不同客戶端的介面名稱即使相似，內建核心、系統整合及設定合併方式也未必相同。
原版 Clash 專案的維護狀態已經改變，目前的生態由多個獨立專案延續。mihomo 從 Clash.Meta 發展而來，是持續演進的核心分支之一。搜尋結果中仍會出現舊教學、舊客戶端與舊設定截圖，閱讀時應先確認文章所談的核心，是否與目前使用的軟體一致。名稱中包含 Clash，不足以判斷某個欄位是否可用，也不能證明不同專案之間具有官方隸屬關係。
移轉舊設定時，優先保留節點、策略群組與規則的邏輯，再逐項確認核心是否支援。不要把「檔案可以匯入」當成「所有欄位都已生效」。部分客戶端會在啟動前改寫連接埠、控制介面或 TUN 設定，實際執行內容可能與訂閱原文不同。發生差異時，請以客戶端匯出的執行設定與核心記錄作為排查依據。
Clash Verge Rev、FlClash 等圖形化客戶端提供設定管理、策略選擇、連線清單及系統代理入口；mihomo 則負責協定連線、規則比對與 DNS 等底層工作。客戶端可能在安裝套件中附帶核心，也可能提供獨立的更新入口；更新介面與更新核心不一定是同一回事。查閱專案說明時，應同時留意客戶端發行紀錄與核心變更，尤其是新增欄位、預設值調整及平台服務相關變動。
開放原始碼讓人能查閱實作，問題討論也有助於找出特定系統環境中的相容性差異，但不代表每台裝置都能使用同一套設定。本網站整理客戶端下載入口與中文操作說明，不代替專案維護者發布結論，也不提供代理節點或訂閱服務。軟體下載、設定來源與網路服務是三個獨立環節，遇到問題時應分別確認。
一條連線通常會先透過系統代理或虛擬網卡進入核心，再依據目標資訊與 DNS 結果比對規則，最後由策略群組選擇出口。代理設定會描述節點協定，策略群組負責整理可用出口，規則則決定流量交由哪個出口處理。了解這三個層次後，更換節點不必重寫所有規則，調整規則也不必重新安裝客戶端。節點服務是否可用，則須另外檢查驗證資訊、伺服器狀態與本機網路。
設定卡中的直連範例只展示 YAML 結構，不會建立代理連線。正式使用時，請從可信來源匯入包含實際節點的設定，並確認規則引用的群組名稱確實存在。YAML 縮排使用空格，清單項目應維持一致的層級；網域、節點名稱與策略群組名稱也要留意拼寫。編輯後先使用客戶端提供的設定檢查功能，再重新載入，較能避免把語法錯誤與網路故障混在一起排查。
升級前先保存目前設定與必要的本機覆寫，並閱讀相關專案的變更說明。訂閱更新通常用來刷新節點與遠端規則；客戶端更新負責介面與系統整合；核心更新則影響底層行為，三者的範圍不同。若升級後出現連線問題，先確認執行中的設定是否改變，再檢查權限、服務狀態與記錄。不要同時升級並更換 DNS 和路由模式，否則很難判斷是哪個步驟造成差異。
驗證時請建立新的連線請求，查看實際符合的規則、策略鏈與出口，不要只看系統匣圖示。舊連線可能仍沿用建立時的出口，瀏覽器快取也可能掩蓋設定變更。分享記錄前，請刪除訂閱網址、驗證欄位與個人網路資訊；討論問題時只需提供必要的欄位片段、系統環境與重現步驟，不適合公開完整的私人設定。
已安裝 Git 的裝置可複製下方命令取得儲存庫。複製原始碼不會安裝客戶端，也不會自動設定系統代理；一般使用者直接到下載頁選擇圖形化客戶端即可。
git clone https://github.com/MetaCubeX/mihomo.gitCLIENTS / PLATFORM SELECTION
先確認裝置的作業系統與處理器架構，再前往對應平台查看安裝套件。桌上型電腦的 AMD64 通常對應 x64，並非只適用於某個處理器品牌；ARM64 則是不同的架構。下載頁集中列出客戶端選項、系統需求與安裝說明，本頁入口會帶你前往正確的平台。
可先查看 Clash Plus，也可依功能需求比較 Clash Verge Rev 與 FlClash。安裝前請在系統設定中確認處理器架構；初次連線先透過系統代理測試，再決定是否啟用 TUN 服務。如果瀏覽器正常、某個應用程式卻無法連線，先確認該程式是否會讀取系統代理；UWP 應用程式也可能受到迴圈存取限制影響。
前往下載 →Apple Silicon 與 Intel 裝置須選擇各自對應的安裝套件。客戶端介面、選單列控制功能與背景網路服務所需的權限並不相同，安裝後請依系統提示完成授權。若裝置已安裝其他 VPN 或網路過濾工具，先確認各工具接管的範圍，避免多個程式同時修改預設路由。
前往下載 →依裝置架構選擇安裝套件，匯入設定後授予系統 VPN 連線權限。若需要長時間保持連線，再檢查電池最佳化與背景執行設定。Clash Android 客戶端的個別應用程式選項與規則路由用途不同：前者決定哪些應用程式納入接管範圍，後者決定進入核心後的連線去向。
前往下載 →下載頁提供 Clash Plus 的 App Store 入口，以及官方網站 clashplus.io。安裝完成後匯入設定，並依系統提示允許新增 VPN 設定。不同客戶端支援的設定格式與欄位範圍可能有所不同；已有 YAML 檔案時，請先確認相容性，再檢查策略群組與規則是否正確匯入。
前往下載 →桌面使用者可查看 Clash Verge Rev 與 FlClash，並依發行版選擇適用的套件格式。伺服器或路由器使用者可在下載頁的核心區查看 mihomo。透過命令列啟動核心後，還須自行設定設定檔路徑、權限與服務管理；圖形化客戶端的系統代理開關，不等同於接管整個系統的流量。
前往下載 →查看所有客戶端 → 想先比較介面、平台與維護狀態？查看客戶端比較。
第一，設定是否成功載入。成功匯入網址不代表節點可用，請查看設定檢查結果與策略群組內容。第二，流量是否進入核心。啟用系統代理後，使用支援此設定的瀏覽器發出新請求，再確認連線清單中是否出現相應記錄。第三，流量去向是否符合預期。連線記錄中的符合規則與策略鏈，比單一延遲數字更能說明實際狀況。
若選擇全域模式，連線通常會交由 GLOBAL 策略處理；若選擇規則模式，則由規則清單決定去向。切換模式無法修正節點驗證錯誤，也不能取代 DNS 或系統權限設定。初次使用建議保持設定簡單，只啟用一種流量接管方式，確認可用後再加入個別應用程式設定、TUN 或自訂規則。完整操作流程請見使用指南，欄位細節請見YAML 手冊。
READING / PRACTICAL NOTES
使用指南依實際需求展開：先建立可重複的驗證方法，再了解測試數值與系統整合的限制。遇到 Clash 無法上網時，根據連線記錄定位流量入口、DNS 解析或出口，比反覆更換客戶端更容易縮小問題範圍。
匯入設定後的首次連線：如何在策略群組中挑選節點、批次測試延遲，再透過出口 IP 查詢與連線記錄確認流量確實經過代理，而非直接連線。
閱讀文章 →解析延遲測試請求的完整路徑與測速網址的影響，說明低延遲節點仍可能卡頓的原因，以及 url-test 策略群組中 interval 與 tolerance 的設定考量。
閱讀文章 →涵蓋安裝套件選擇、首次啟動、服務模式安裝與啟用 TUN，並逐項排查 Windows 常見問題，包括系統代理未生效、UWP 應用程式無法連線及防火牆封鎖。
閱讀文章 →