Mihomo 設定教學

一、核心概念與用戶端選擇

核心、介面與服務來源

Mihomo 是負責解析設定、比對規則及建立對外連線的代理核心，Clash Meta 是其生態系常見的舊稱。用戶端則提供圖形介面、設定管理與系統整合。點選介面上的系統代理或策略組選項，最終會改變核心的執行狀態或相關系統設定。因此，介面顯示已啟動，只能證明程序正在執行，無法單憑這點確認訂閱有效、對外連線可用，或所有應用程式都已使用代理。

完整連線流程包括應用程式、流量入口、規則、策略組與出口。應用程式先透過系統代理或 TUN 將要求交給核心；核心依照模式決定是否套用規則；符合規則的連線會交由直連、拒絕或某個策略組處理；策略組再選擇實際出口。訂閱通常提供出口參數與部分規則，但用戶端本身並不等於網路服務。下載並安裝用戶端後，仍須準備合法可用的設定來源，或自行部署並維護相關服務。

依平台選擇安裝管道

初次選擇時可先考慮 Clash Plus，再依平台與使用方式比較其他用戶端。Windows 也可選擇 Clash Verge Rev、FlClash、Clash Nyanpasu；macOS 可比較 Clash Verge Rev 與 FlClash；Android 可比較 Clash Meta for Android、FlClash 或 Surfboard。Surfboard 的設定格式與 Mihomo 並不完全相同，不能只因為同屬代理工具，就直接匯入同一份 YAML。各平台的安裝管道請見下載中心。

維護狀態與功能限制

Clash for Windows 與 ClashX Meta 已停止維護，可用來了解舊環境或遷移舊設定，但不建議只因為舊教學使用它們，就預設繼續沿用。Linux 桌面使用者可先比較 Clash Verge Rev 與 FlClash；伺服器和路由器使用者則可考慮直接執行 Mihomo 核心。後者需要自行管理程序、設定目錄、監聽位址與路由，無法享有圖形化用戶端自動處理系統整合的便利。

iOS 使用 Clash Plus 時，可先到官方網站 clashplus.io了解應用程式資訊，再從App Store 頁面安裝。不同平台的用戶端即使名稱相同，介面入口與系統功能也可能不同。學習時應先理解設定的作用，而不是照著按鈕位置逐一尋找。

完成本階段後，應能回答三個問題：目前執行的是哪個用戶端、實際由哪個核心或網路元件處理連線、設定由誰提供及更新。進一步比較時，請留意訂閱相容性、規則覆寫方式、日誌可讀性與設定備份，不要只看介面是否相似。看到「支援某協定」的說明時，也應確認目前平台與實作是否支援訂閱使用的特定參數；協定名稱相同，不代表所有擴充欄位都能互換。

二、安裝、權限與初始環境

安裝前確認架構與舊設定

先在系統資訊中確認裝置架構，再選擇安裝套件。Windows 裝置常見 x64，也有 ARM 裝置；macOS 須區分 Apple Silicon 與 Intel；Linux 除了架構，還要確認發行版支援的套件格式。不要根據檔案大小猜測是否相容。安裝程式能開啟，不代表附帶的核心一定能在目前系統上執行；若啟動後立即關閉，請先檢查架構與系統需求，再查看應用程式日誌，不要馬上修改訂閱。

若裝置曾安裝其他代理用戶端，請先關閉舊用戶端，並確認系統代理沒有繼續指向舊連接埠。關閉視窗不一定等於結束背景程序；系統匣圖示、選單列圖示和系統服務都可能仍在運作。初次驗證時只保留一個負責接管流量的用戶端，避免兩個程式反覆修改系統代理，或兩個 TUN 裝置搶用預設路由。舊設定可以備份，但不要在狀態未明時同時啟用。

桌面平台的權限設定順序

在 Windows 上，先以一般方式安裝並啟動，確認基本介面能正常開啟。只有在安裝服務或啟用需要較高權限的網路功能時，才依用戶端提示授權。系統代理通常不需要長期以系統管理員身分執行整個應用程式；TUN 或服務模式則可能仰賴具特權的輔助元件。若提示連接埠已被使用，請先查明是哪個程序正在監聽；修改其中一方的連接埠後，也要同步更新系統代理的目標，不能只改 YAML 卻保留舊的系統入口。

macOS 首次啟動時，請依系統提示確認應用程式來源與權限用途。用戶端可能會安裝輔助服務，部分實作則會使用網路延伸功能，實際流程依應用程式而異。鑰匙圈提示與網路延伸功能授權是兩回事：前者可能用於儲存敏感資訊，後者則允許接管系統網路。出現對話框時，請先閱讀要求權限的來源，不要一律按下允許。相關設定請參閱macOS 權限與鑰匙圈說明。

Linux 圖形化用戶端能否設定系統代理，取決於桌面環境與應用程式實作；命令列程式也未必會讀取桌面代理設定。安裝後請先確認核心程序正在執行、設定載入成功且本機連接埠已監聽，再以明確支援代理的應用程式進行測試。直接執行核心時，應為設定目錄設定適當的讀寫權限，不要為了省事就開放所有使用者寫入整個目錄。服務帳戶、工作目錄與相對路徑不一致，常會導致互動執行正常、背景啟動失敗。

行動裝置與最小啟動設定

Android 首次建立 VPN 連線時會要求系統授權；這代表流量入口已獲允許，不代表遠端出口可用。系統通常只允許一個一般 VPN 連線占用該位置，既有的企業 VPN 或其他網路工具可能造成衝突。背景省電設定也可能暫停用戶端，確認確實有斷線問題後再調整相關限制。iOS 也須依應用程式指引完成 VPN 設定授權，再返回用戶端檢查是否有設定載入錯誤。

# 本機入口範例，不含代理出口
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

上述片段用於說明基本參數，並非可提供代理服務的完整設定。mixed-port 可接收 HTTP 與 SOCKS 要求；allow-lan: false 限制區域網路存取，但仍須配合實際監聽位址與防火牆確認暴露範圍。請先只供本機使用，暫時不要開放區域網路共用。安裝完成的判斷標準是介面、核心與本機入口都正常，而且結束用戶端後能恢復原本的網路狀態。

三、訂閱匯入與設定生命週期

分清訂閱網址與實際設定

訂閱連結是取得設定的入口，下載後的內容才是核心實際解析的設定。連結可能回傳完整 YAML、只有代理出口的集合，或其他用戶端使用的格式。匯入前應確認提供者明確支援目前使用的用戶端與核心。瀏覽器能開啟連結，只能證明收到回應，無法確認回應內容是有效設定；登入頁面、餘額提示與存取限制頁面，也可能以一般網頁形式回傳。

在用戶端找到設定或訂閱管理入口，新增遠端設定，取一個容易辨識來源的名稱，貼上網址後執行下載。完成後先查看更新時間、解析結果與是否已建立策略組，再將其設為目前使用的設定。不同用戶端可能會把「下載成功」和「啟用成功」分成兩個步驟；檔案已儲存不代表核心已切換。請比對目前設定名稱與啟動日誌，避免一直編輯尚未啟用的檔案。

釐清設定來源的分工

遠端訂閱通常由提供者維護，直接修改下載快取，可能在下次更新時被覆蓋。需要長期保留的規則、DNS 或入口設定，應使用用戶端提供的覆寫、合併或擴充機制；機制名稱與執行順序依用戶端而異。請先確認它是整個取代某個欄位，還是在原清單之前或之後插入。對規則清單而言，追加在末尾的規則可能位於 MATCH 之後，雖然語法正確，卻永遠不會生效。

將設定分為來源層、個人覆寫層與執行狀態三部分，會更容易排查。來源層說明訂閱下載了什麼；覆寫層說明本機新增或取代了什麼；執行狀態則顯示核心最終收到什麼。若介面顯示的項目與 YAML 不一致，應查看最終設定或日誌，而不是只看訂閱原文。部分用戶端會在啟動時加入連接埠、控制介面等欄位，因此執行中的設定與遠端原始檔案不同，不一定代表有錯。

# 局部範例：兩個常見的頂層欄位
mode: rule
log-level: info

# 規則引用的 PROXY 必須已在完整設定中定義
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY

處理匯入與更新失敗

若出現解析錯誤，先記下錯誤訊息中的欄位名稱與行號。YAML 以空格表示層級，縮排不能混用定位字元；清單項目前的連字號、冒號後的空格，以及字串中的特殊字元也會影響解析。錯誤行有時只是解析器發現問題的位置，真正原因可能是前一行缺少引號或層級錯誤。請從錯誤附近逐段檢查，避免整份檔案重新排版後，反而失去最初的線索。

若下載失敗，請分辨是網域無法解析、連線逾時、憑證錯誤、授權失效，還是回傳內容不符。訂閱要求可能由用戶端本身或核心執行，不一定與瀏覽器使用相同的網路路徑。只有在提供者說明需要特定要求標頭時，才調整 User-Agent；隨意更換標頭並非通用解法。詳細排查步驟請見訂閱解析失敗自我檢查；初次匯入流程也可參考訂閱匯入步驟。

更新前請保留最近一份可用設定，更新後確認策略組引用是否仍有效。提供者可能更改出口名稱，導致原本固定選用的成員失效；若用戶端保留先前的選擇，請重新進入策略組確認。不要只因重新整理成功，就認定更新已完成；還要測試實際連線並查看命中的策略。訂閱內容經常變動時，個人規則宜引用穩定的策略組名稱，而非容易變更的出口名稱。

四、代理模式與策略組

先分清入口與對外連線決策

系統代理、TUN 與 Rule 並非同一層級的選項。前兩者決定應用程式流量如何進入核心，Rule 則決定流量進入後如何分流。因此，「已切換到全域模式，但某些應用程式仍未走代理」並不矛盾：該應用程式可能根本沒有使用系統代理，也沒有透過其他入口接管流量。排查時先在連線面板尋找對應要求；若完全看不到連線，應檢查入口，而不是繼續切換出口或調整規則順序。

日常使用通常從 Rule 模式開始。Global 適合作為短時間的診斷對照，但不會自動解決訂閱失效、入口衝突或 DNS 錯誤。Direct 也不等於結束用戶端；入口接管與核心解析行為仍可能持續。若要判斷問題是否源自整個代理環境，應進一步結束用戶端並還原系統設定；只切換成 Direct，無法排除 TUN 路由或用戶端 DNS 仍在處理流量的可能性。

了解策略組的引用關係

策略組是規則與實際出口之間的中介層。select 可手動選擇成員；url-test 依測試結果選擇成員；fallback 依序尋找可用成員；load-balance 則依設定的分配策略安排連線。自動策略組的測試結果只反映測試網址與測試方式，不能直接代表特定網站一定可用，也不宜把某個顯示數值當成所有情境的品質判斷。

# 將此群組加入現有完整設定的 proxy-groups 清單
# 這是僅含直連選項的結構範例，不會新增代理出口
proxy-groups:
  - name: 手動選擇
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,手動選擇

範例中的規則引用的是群組名稱，群組再引用內建的 DIRECT。實際訂閱可以將已定義的出口名稱加入成員清單，也可以引用另一個策略組，但必須避免彼此引用而形成循環。名稱通常必須完全一致，大小寫、空格與符號都要相同。修改群組名稱時，rules 中的引用與其他群組的成員也要一併修改；只改顯示名稱會造成目標不存在，可能直接導致設定無法載入。

以單一要求驗證選擇結果

切換策略組後，新連線通常會使用新的選擇，但已建立的長連線可能繼續沿用原出口。瀏覽器連線集區、下載工作與即時通訊連線都可能持續存在。驗證時請關閉相關頁面或工作，再發出新的要求，查看連線面板中的規則、策略路徑與出口；必要時只關閉與該項服務相關的連線，不必每次清除所有連線，以免影響其他工作。

也要留意，同一個介面可能同時顯示全域策略組與訂閱自訂策略組。在 Rule 模式下，真正生效的是命中規則所引用的目標，不一定是最上方顯示的群組。更換出口後若服務完全沒有變化，請沿著連線記錄中的策略路徑逐層確認，不要直接認定用戶端沒有儲存選擇。切換到另一份同名來源的設定後，也應確認群組成員是否有所變動。

完成本階段後，至少進行一次可控的對照測試：保持入口不變，以同一個網站分別測試 Rule 與 Global，並記錄最後的連線路徑。若 Global 可用、Rule 不可用，再檢查規則命中與群組選擇；若兩者都失敗，先確認出口或 DNS 解析。這項對照不是長期設定建議，而是用來將故障範圍從整條連線路徑縮小到單一環節。術語可進一步參閱策略組說明。

五、規則分流與比對順序

命中第一條規則就決定去向

Mihomo 的一般規則會由上而下依序判斷，命中第一條後就使用對應目標。因此，優先順序首先取決於規則位置，而非規則類型的名稱。精確網域規則不會自動優先於上方已命中的廣泛規則；位於末尾的 MATCH 則負責處理其他情況。撰寫規則時，應先放明確的例外，再放較廣泛的分類，最後才是預設出口，並在連線面板確認實際命中的規則。

DOMAIN 比對完整網域；DOMAIN-SUFFIX 比對網域及其子網域；DOMAIN-KEYWORD 依關鍵字比對，範圍較廣，也更容易誤判。IP 類規則用於目標位址；程序類規則則須視平台支援與程序識別條件而定。不要因為某個網站有已知位址，就永久只用單一 IP 規則；內容傳遞、位址輪替與共用主機都可能讓規則覆蓋不足，或連帶影響其他服務。

# 局部規則範例；PROXY 必須是既有策略組
rules:
  - DOMAIN,router.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,geolocation-!cn,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

此處的 example.com 是用來說明語法的保留範例網域，請依實際需求替換。no-resolve 表示這條 IP 規則不會主動觸發網域解析，不代表停用所有 DNS 要求；若連線原本已有目標位址，仍可能依位址比對。GEOSITE 與 GEOIP 使用本機資料檔，分類名稱必須存在。成功載入只能證明語法與資料可用，不能證明分類內容完全符合目前的需求。

從內建分類進階到規則集

手寫清單變長時，可透過 rule-providers 將規則資料與主設定分開。提供器會描述來源、儲存位置、更新週期與內容格式，rules 再透過 RULE-SET 引用。domain、ipcidr 與 classical 對內容格式有不同要求，不能只改副檔名就互換。規則集檔案中的項目通常不包含最終策略，策略由引用它的 rules 項目指定。

# 本機規則集範例：相對路徑以核心工作目錄為基準
rule-providers:
  local-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,PROXY

# 儲存為 rules/local-domains.yaml
payload:
  - '+.example.com'

使用本機檔案可以先驗證格式與比對結果，不必同時排查遠端下載。確認無誤後，再考慮遠端來源，並核對來源維護方式與適用範圍。遠端規則集更新失敗時，舊快取可能仍會繼續使用；若沒有快取，則可能無法載入。主設定更新成功與規則集更新成功是兩回事，須分別查看日誌。不要盲目疊加多個用途高度重疊的規則集，否則很難判斷究竟是哪一組決定結果。

依據連線資訊找出分流偏差

排查順序為：確認要求已進入核心、查看目標網域與位址、記錄命中的規則，再確認目標群組的選擇。若連線只顯示 IP，請檢查應用程式是否自行解析、DNS 是否繞過核心，以及網域嗅探是否符合條件。嗅探可以補充網域資訊，但並非所有協定都能還原原始主機名稱；啟用嗅探不能解決所有網域規則失效問題。新增規則前，先確認核心實際掌握了哪些資訊。

有些網站會同時連線至登入、資源、API 與媒體網域，只替首頁網域新增規則，可能只修復部分頁面。請針對一次明確操作觀察相關的失敗連線，再補上必要範圍，避免使用過廣的關鍵字，導致無關服務也被一併接管。規則類型與優先順序請參閱自訂規則與優先順序；需要組合不同分類時，再查看GEOSITE 與規則集分流設定。

六、DNS、Fake-IP 與 TUN

解析與連線是彼此相關的兩條路徑

DNS 會將網域轉換成位址，代理則負責承載後續連線，兩者的路徑不一定相同。瀏覽器可能使用加密 DNS，系統可能快取舊結果，應用程式也可能內建解析器。因此，網站無法開啟不一定代表出口故障。應先確認是否取得位址，再檢查連線是否進入核心，最後確認實際出口。比較不同網路時，應維持相同的用戶端設定，避免網路與設定同時變動，導致無法判斷原因。

Fake-IP 會為網域指派虛擬位址並維護對應關係，後續流量抵達核心時，可用來關聯原始網域。這不是網站的真實位址，也不能用這個虛擬位址判斷地理位置。redir-host 則會回傳解析得到的真實位址，適合需要真實位址行為的特定環境，但規則判斷可能更依賴網域對應與解析結果。兩者沒有適用於所有應用程式的絕對優劣，應依區域網路、遊戲或企業內網需求實際驗證。

# DNS 局部範例；僅監聽本機
dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - 'localhost'
  nameserver:
    - https://1.1.1.1/dns-query

上述範例只會建立本機 DNS 監聽入口，不會自動讓系統將查詢送到該連接埠。系統 DNS、TUN 攔截或用戶端整合功能還需要另外設定連接。範例中的上游 DNS 也必須能在實際網路中連線，不能把加密協定本身視為可連線的保證。fake-ip-filter 可讓指定網域不回傳虛擬位址，只應為確實有相容性問題的網域加入例外；範圍過廣會改變原有分流行為，也會增加排查難度。

TUN 接管的前提與限制

TUN 透過虛擬網路介面接收 IP 流量，適合不遵循系統代理設定的程式。啟用前請確認權限、驅動程式或輔助服務已就緒，並檢查其他 VPN 是否仍在執行。auto-route 用來設定相關路由；auto-detect-interface 則會嘗試識別對外連線介面。在多網卡、熱點與企業網路環境中，仍須確認實際結果。TUN 並非能繞過權限、出口協定限制或防火牆的萬用開關。

# TUN 局部範例，須搭配平台與 DNS 設定使用
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns-hijack 中的一般 DNS 連接埠比對，無法涵蓋應用程式自行建立的所有加密解析連線。系統代理與 TUN 也不一定需要同時啟用，請依用戶端建議選擇，避免入口重疊後難以釐清連線路徑。啟用後先測試一般網頁，再測試目標應用程式與區域網路服務；若印表機、共用資料夾或企業內網異常，請檢查是否需要排除路由或加入網域例外，不要直接把所有流量改成直連。

辨識 DNS 洩漏與內網衝突

判斷 DNS 洩漏時，應以預期的解析路徑為基準：哪些查詢應由哪個解析器處理，以及是否有要求繞過這條路徑。測試網站顯示某個解析器名稱，只能做為線索，不能單憑此點證明所有查詢都經過或繞過代理。應配合系統 DNS、用戶端日誌、瀏覽器安全 DNS 設定，以及必要時的網路封包擷取，確認特定要求的去向。測試時也要區分 IPv4 與 IPv6，不能只檢查一種位址類型就下結論。

若企業內網使用專用 DNS，公共解析器可能無法解析內部網域。此時應針對內部後綴設定解析策略，並確保相關 DNS 位址能透過正確介面連線。若發生循環，可能是解析要求依賴代理，而代理伺服器網域又依賴同一條尚未建立的解析路徑；應為代理伺服器解析準備可獨立運作的路徑。Fake-IP 的其他限制請見Fake-IP 與 redir-host 的差異。

七、日常維護與故障排查

建立可還原的設定基準

穩定使用後，請備份用戶端設定、個人覆寫與規則檔案。訂閱連結本身不是完整備份，因為遠端內容可能變更，本機策略選擇與擴充規則也可能不在訂閱中。備份時應區分可公開的規則，以及包含帳戶驗證資訊的設定，並將敏感內容存放在受控位置。記錄目前使用的入口方式、DNS 模式與特殊路由，比只保留一張介面截圖更有助於還原環境。

更新時應分別處理用戶端、核心、訂閱與規則資料。用戶端更新可能改變介面與系統整合方式，核心更新可能影響欄位支援，訂閱更新則主要影響出口與設定內容。一次只更新一個項目並進行基本驗證，出現異常時才能明確知道要還原什麼。不要在工作中斷時同時更新所有元件，再只憑「更新後不能用」嘗試還原；資訊不足便無法分辨是相容性問題還是服務變動。

依連線路徑排查無法上網

先確認影響範圍：是所有應用程式、單一程式，還是某個網站的特定功能。接著確認不經過用戶端時網路是否正常。若基本網路也無法使用，應先處理 Wi-Fi、行動網路、登入驗證頁面或系統網路狀態。用戶端執行時，請檢查核心是否啟動成功、目前設定是否正確、連接埠是否正在監聽。若目標要求未出現在連線清單中，應優先檢查系統代理、應用程式代理設定或 TUN，而不是更換出口。

要求進入核心後，請查看解析結果、命中的規則與最終出口。若同一個出口連多個網站都失敗，可檢查服務狀態、驗證參數與遠端連線能力；若只有一個網站失敗，則應檢查規則、網站相依網域與協定差異。收到 HTTP 錯誤回應代表已取得應用層結果，不能直接歸類為完全無法連線。遇到憑證錯誤時，也應先確認系統時間、目標網域與中間設備，不要透過關閉憑證驗證來掩蓋原因。

# 驗證本機 HTTP 代理入口，連接埠須與實際設定一致
curl -I --proxy http://127.0.0.1:7890 https://example.com

# 驗證 SOCKS 入口，並由代理端解析網域
curl -I --proxy socks5h://127.0.0.1:7890 https://example.com

這些命令只會驗證指定入口與指定網站，不代表所有程式都已接管。在 PowerShell 中，若遇到命令別名差異，可使用 curl.exe。socks5h 與一般 SOCKS 位址在網域解析位置上有所不同，比較時應記錄所使用的形式。不要只比較兩條命令是否成功，也要配合日誌確認各自套用的規則，避免一條直連、一條走代理，卻被當成相同條件的測試。

日誌、快取與結束後還原

日常使用時維持 info 等適當的日誌層級，暫時排查時再提高詳細程度。記錄一次失敗操作的時間、目標與錯誤訊息，比長時間累積大量日誌更有效。分享日誌前，請移除訂閱網址、驗證欄位、內網主機名稱與可能暴露業務資訊的要求路徑。詳細日誌也可能增加資源耗用，排查完成後應恢復原本層級，避免長期保留不必要的連線細節。

修改 DNS 或模式後，既有快取與長連線可能讓結果暫時不變。請先關閉相關連線，再視需要重新整理系統或應用程式快取，不必直接刪除整個用戶端目錄。若結束用戶端後仍無法連線，請檢查系統代理是否仍指向已關閉的本機連接埠、TUN 路由是否已還原，以及 DNS 是否仍指向無法使用的位址。快速檢查方式請參閱系統代理設定與連線驗證。

八、進階設定與驗證流程

先模組化，再增加自動化

進階設定不代表把所有功能都打開，而是能說明每一段設定的輸入、輸出與失敗情況。有了穩定的設定後，可先將個人規則與訂閱分開，再將較大的規則清單整理成獨立提供器，最後才考慮出口提供器與自動策略。每拆分一個模組，都要驗證路徑、名稱引用與載入順序。模組化的目標是縮小修改範圍，而不是讓簡單設定變成難以追蹤的多層引用。

proxy-providers 與 rule-providers 解決的是不同問題：前者提供代理出口集合，後者提供比對條件集合。它們通常分別由策略組與 rules 引用。不要未經確認就把完整用戶端訂閱當成出口提供器檔案；即使內含 proxies，也可能還有用戶端需要的其他區段，必須核對實際解析方式。對於來源不明的遠端檔案，應先在本機查看結構，再納入自動更新流程。

為策略建立測試矩陣

驗證應涵蓋不同類別，而不是只開啟一個常用網站。準備本機閘道器、區域網路服務、需要直連的網站、需要代理的網站與目標應用程式，分別記錄預期的入口、規則與出口。使用 IPv6 時也要觀察位址類型的選擇；使用 UDP 時，須確認入口與遠端協定都支援。網頁能開啟，只能證明其中一條 TCP 連線正常，不代表語音、遊戲或其他使用 UDP 的功能也能正常運作。

測試時請使用可重複的操作，例如重新開啟同一個頁面、重新建立一次語音連線，或連線至固定的內網服務。先寫清楚預期結果再修改參數，可以避免把「感覺變快」或「偶爾成功」誤認為設定正確。若使用自動選擇群組，也要觀察測試失敗後的行為、成員更新後的引用，以及切換網路後是否恢復，確認自動化符合實際需求，而不只是介面顯示正常。

命令列核心與控制介面

準備脫離圖形介面執行核心時，請先了解工作目錄與設定檔路徑。相對路徑通常以工作目錄為基準，可能影響規則檔案、快取與資料檔。將設定複製到伺服器卻漏掉本機提供器檔案，是常見的遷移失敗原因。先以前景模式檢查設定與日誌，再設定服務管理；服務啟動帳戶的權限可能與互動登入帳戶不同，讀寫目錄與網路功能都要分別驗證。

# 在已安裝 mihomo 的環境中檢查設定
mihomo -t -d ./mihomo-work -f ./mihomo-work/config.yaml

# 檢查通過後以前景模式執行
mihomo -d ./mihomo-work -f ./mihomo-work/config.yaml

設定檢查可以找出語法與部分引用問題，但無法證明訂閱網址、DNS 上游與所有出口在執行時都能連線。以前景模式完成測試後，再將相同參數寫入所用系統的服務設定。若啟用外部控制介面，應限制監聽範圍並設定存取保護，不要為了方便使用遠端面板，就直接公開在網際網路上。介面權限通常可修改執行狀態，風險與一般唯讀網頁不同。

將排查結果整理成變更紀錄

每次變更都記錄原因、相關欄位、驗證對象與還原方式。複雜設定應保留一份最小可執行基準：入口明確、策略組精簡、規則路徑清楚。發生異常時，逐一移除新增功能並與基準比較，不要從網路上不斷疊加來源不明的設定區段。若仍不確定設定格式，可回頭查看訂閱與設定格式；需要重新整理初次操作流程時，請回到快速入門教學。

完成本手冊的標準，不是記住所有欄位，而是能沿著應用程式入口、網域解析、規則命中、策略選擇與實際出口，說明一次連線的完整流程。接下來只需學習目前服務確實需要的功能，例如獨立規則集、依網域指定解析器，或以伺服器程序管理服務。維持設定易讀、結果可驗證、修改可還原，比持續增加參數更有利於長期維護。