MIHOMO · 設定指南

Clash 進階設定指南

策略群組、規則集、DNS 與網路接管。依設定生效順序，檢查每一層的輸入、限制與驗證結果。

第一次安裝並匯入訂閱，請先依照使用指南完成連線。本頁適合已有可用設定的使用者，集中說明需要長期維護的參數；快速入門流程不在此重複。範例以 mihomo 設定格式為基礎，各用戶端的選單名稱與覆寫方式可能不同。

設定層級與生效狀態檢查

Clash 設定檔並非介面中所有設定的單純副本。以 Clash Plus 等桌面用戶端為例，應用程式負責下載訂閱、視窗操作與系統整合，mihomo 核心則負責監聽連接埠、比對規則及建立連線。用戶端可能先讀取訂閱，再套用本機設定，最後產生執行中的設定檔。若編輯訂閱來源檔案後，產生程序又將修改覆蓋，變更就無法持續生效；進階設定應先從釐清這幾個層級開始。

先確認核心實際讀取的設定

在用戶端的設定頁確認目前啟用的項目，再到記錄頁查看啟動時使用的設定目錄。若有「檢視執行中設定」或類似入口，請優先檢查最終產生的內容，而非只看編輯器中的原始檔。重點核對混合連接埠、執行模式、DNS 開關與規則清單。各用戶端的檔案儲存位置不盡相同，不宜照抄其他電腦的絕對路徑，也不要在核心執行期間直接搬動工作目錄。

修改前先保留目前可用的設定，並記錄系統代理、TUN 與服務模式的狀態。每次只調整一類設定，例如先修改策略群組，確認載入成功後再調整 DNS。若同時更換訂閱、啟用虛擬網卡並修改解析器，發生問題時很難判斷是哪個層級造成的。設定備份也應留在本機，其中可能包含訂閱網址、節點密碼或控制介面憑證，不適合直接貼到公開討論區。

用最精簡的設定區分語法與網路問題

以下是僅供本機直連測試的最精簡設定，可另存成獨立檔案交由核心檢查。此設定沒有代理節點，無法提供遠端代理功能；用途是確認 YAML 可正常讀取、本機連接埠能啟動，以及規則模式下的直連路徑是否正常。實際使用時應回到既有訂閱，不要把這份檔案當成完整的代理設定。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxies: []
proxy-groups:
  - name: 手動選擇
    type: select
    proxies:
      - DIRECT
rules:
  - MATCH,手動選擇

YAML 縮排須使用空格，並保持同一層級一致；清單項目前的連字號及冒號後的空格也有語意。含特殊符號的名稱可以加上引號，但引用時必須完全一致。重複的頂層索引鍵尤其容易造成誤判：同一檔案中出現兩段 dns:，不代表兩段設定會自動合併，實際解析方式也可能不同。應先整理成單一物件，再使用用戶端支援的覆寫機制。

驗證通過不代表連線可用

直接執行核心時，可以在設定檔所在目錄執行下方指令。工作目錄會決定相對路徑的解析位置，因此 -d 與 -f 應指向同一套已備妥的檔案。語法檢查通過只代表設定可被接受，不保證遠端規則集能下載、節點可通過驗證或 DNS 伺服器可連線。正式啟動後還要查看初始載入記錄，不能只看結束代碼。

mihomo -t -d . -f config.yaml

若提示連接埠已被占用，先確認是否有其他用戶端或核心仍在背景執行。不要為了消除錯誤而連續更換多個連接埠：應用程式手動代理、系統代理與用戶端監聽值必須一致。若設定能載入但只有部分應用程式失敗，接著確認應用程式是否遵循系統代理、是否使用獨立 DNS，以及流量是否進入 TUN；這些都不是 YAML 縮排錯誤。

選擇用戶端可從下載中心開始，通常可優先考慮 Clash Plus，再依作業系統與現有工作流程比較其他用戶端。若想了解原版 Clash、mihomo 與圖形介面之間的關係，可搭配閱讀核心與用戶端分支整理。後續章節討論的是設定行為，不會將特定介面的按鈕位置視為所有用戶端的共同標準。

策略群組類型與實作

策略群組位於規則與節點之間：規則決定將連線交給哪個群組，群組再決定使用哪個出口。將業務規則直接指向節點雖然簡單，但節點更名後就得修改所有引用。較穩妥的結構是讓規則指向長期固定的業務群組，再由業務群組引用手動選擇或自動選擇群組。分組應配合實際需求，不必為每個網站建立重複的層級。

四種類型各自解決什麼問題

select 是手動選擇群組，適合需要固定出口或暫時排錯的情境；url-test 依探測結果自動選擇出口，適合可接受路徑變動的一般連線。fallback 依設定順序選擇可用項目，重點是主備關係，不是永遠挑最快的；load-balance 會將不同連線分配到多個出口，不會把單一下載連線合併成數倍頻寬。

策略群組選擇依據
類型選擇依據注意事項
select使用者指定選好後仍須確認出口可用
url-test探測回應探測成功不代表業務網站可用
fallback順序與健康狀態主要出口恢復後可能會切回
load-balance分配演算法登入服務可能要求出口穩定

探測網址應選擇穩定、回應輕量，且所有候選節點都能連線的端點。若網址本身受到限制，群組內所有節點可能同時顯示異常，但實際業務未必故障。反過來說，探測成功連上某個網站，也不能證明已符合串流媒體授權、工作系統登入或其他地區限制。排錯時應分開記錄健康檢查與業務驗證結果。

固定業務入口

以下示範在手動群組中套用自動群組的片段。include-all 用於納入設定中既有的代理候選項，前提是完整設定確實載入了可用節點。它不是節點來源，也不會憑空產生代理。程式碼中的探測網址是常見的連線測試端點；若目前網路無法連線，請改用已確認可連線的輕量端點。

proxy-groups:
  - name: 自動選擇
    type: url-test
    include-all: true
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
  - name: 網路出口
    type: select
    proxies:
      - 自動選擇
      - DIRECT

interval 的單位是秒，用來設定探測週期；tolerance 是切換容差，單位為毫秒，用來減少測試結果接近時頻繁切換。週期越短不一定越好，除了增加背景請求，也更容易受短暫波動影響。筆記型電腦或行動網路環境可先採用較保守的週期，再根據記錄判斷，不要把測速頻率當成連線品質保證。

若使用代理集合，可透過 use 引用已定義的 proxy-providers 名稱，避免逐一將節點名稱寫入群組。集合名稱與節點名稱屬於不同層級：前者管理來源，後者代表實際出口。對集合套用篩選條件時，須考慮上游更名與篩選結果為空的情況；修改後應檢查候選清單，不能只確認設定載入成功。

切換限制與復原方式

自動群組切換通常會影響新建立的連線，既有長連線不一定會立即切換。重新整理網頁仍使用舊出口時，可先結束該應用程式的現有連線再重試，不要直接認定策略群組失效。影片播放、終端機連線與工作系統對出口變動的容忍度各不相同；需要固定來源位址的服務較適合手動固定群組，而非在多個地區之間自動輪換。

群組之間可以互相引用，但不能形成循環。例如「網路出口」引用「辦公」，而「辦公」又指回「網路出口」，就沒有明確的最終出口。設計時應沿著引用鏈往下檢查，末端必須指向實際節點或 DIRECT 等內建策略。群組名稱也不要與節點名稱重複，否則介面顯示與規則目標都會難以辨認。

驗證時先在代理頁確認候選項不為空，再手動固定一個已知可用的節點，最後才啟用自動選擇。若固定節點可用但自動群組失敗，應優先檢查探測端點、篩選條件與引用層級；若固定節點也無法使用，先回頭檢查節點驗證與底層網路，不要繼續增加策略群組。不熟悉介面入口時，可參閱代理頁、設定頁與記錄頁說明。

以規則集訂閱管理規則

規則分流會依清單順序執行，符合的第一條規則會套用對應策略。規則集只是將大量比對條件放入獨立檔案，不會改變這項順序原則。實際維護時，建議將少量本機例外放在前面，接著放業務規則集與一般地區規則，最後以 MATCH 作為兜底。只有明確依賴網域解析結果的規則，才需要讓核心查詢目標位址。

先比對明確條件，再套用兜底規則

DOMAIN 精確比對網域，DOMAIN-SUFFIX 比對網域及其子網域；IP-CIDR 依位址範圍比對，GEOIP 則依賴地理資料。若將範圍較廣的規則放在前面，會擋住後面的精確例外。某個網站總是走錯出口時，應先找出最早命中的規則，而非不斷在清單底部加入同一個網域。

設定中的策略目標必須存在。規則指向「網路出口」，而策略群組實際名稱是「代理出口」，這不是能自動修正的小差異。訂閱更新也可能變更群組名稱，因此本機規則最好引用自行維護的固定入口群組。另一個常見問題是將規則模式切換為全域模式：此時一般規則清單不會依預期參與選擇，應先確認執行模式再檢查比對細節。

用本機規則集建立可驗證的範例

以下片段使用本機檔案，適合先驗證路徑、格式與規則引用。檔案路徑會相對於核心工作目錄解析。範例僅將保留用的示範網域導向直連，不代表實際業務分流方式；確認機制後，再以自行管理的網域清單取代。主設定檔與規則檔是兩個檔案，不能將兩段程式碼直接接在一起儲存。

# 主設定中的相關片段
rule-providers:
  local-direct:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,網路出口
# rules/local-direct.yaml
payload:
  - '+.example.com'
  - '+.example.org'

behavior: domain 適用於網域集合，項目不必再加上完整的 DOMAIN-SUFFIX 前綴；ipcidr 用於位址範圍；classical 可容納傳統規則條件，但項目中仍不應附上最終策略名稱。format 必須與檔案實際格式相符。若下載到 HTML 錯誤頁、JSON API 回應或一般文字，卻硬標記為 YAML，都會造成載入失敗。

遠端更新不應影響本機例外

將規則來源改為 HTTP 類型時，須設定有效的 url、快取 path 與更新 interval；規則集更新週期的單位同樣是秒。遠端網址應回傳規則檔本身，而非程式碼託管網站的預覽頁面。不要讓兩個不同來源共用同一個快取路徑，否則更新或還原時很難判斷本機檔案來自哪裡。

下載規則集也需要可用的網路路徑。若下載規則集必須使用某個策略，而該策略又依賴尚未載入的規則或節點來源，就可能形成啟動依賴循環。初次設定時，先確保基本出口可用，再加入遠端規則；若需指定下載代理，請引用明確可用的策略群組。更新失敗時，保留記錄中的 HTTP 狀態與解析錯誤，不要直接刪除所有快取。

對 IP-CIDR 或 GEOIP 使用 no-resolve，可避免只為了嘗試比對位址規則而觸發額外網域解析；但這也代表尚未取得實際目標位址時，該規則可能不會命中。它不是通用的加速開關。較合理的做法是將已知網域規則放在前面，讓位址規則處理確實取得 IP 的連線，再透過連線記錄核對實際行為。

驗證時，分別使用一個明確屬於範例範圍的網域，以及一個不屬於範例範圍的網域，檢查規則、策略群組與最終出口。修改規則後，新連線才是可靠的觀察對象；瀏覽器重用連線可能會保留舊路徑。若訂閱更新成功但規則檔更新失敗，可參閱訂閱與設定解析自我檢查清單，區分下載階段與解析階段，不要混淆這兩種錯誤。

DNS 設定與解析路徑

DNS 設定需要回答三個問題：誰接收應用程式的查詢、誰負責向上游解析，以及解析請求透過哪條網路路徑傳送。只將上游位址改成加密 DNS，不代表所有應用程式的查詢都會進入核心。瀏覽器的安全 DNS、系統快取、應用程式內建解析器與區域網路閘道，都可能形成旁路。討論 Clash DNS 洩漏之前，應先釐清目前裝置實際的查詢路徑。

區分監聽、引導與一般解析

listen 定義核心 DNS 服務的監聽位址；nameserver 是一般查詢使用的上游；default-nameserver 用於解析上游 DNS 伺服器本身的網域等引導需求，並非所有失敗查詢都會自動轉交的萬用備援。使用網域名稱的 HTTPS 解析器必須先解析自己的主機名稱，因此要避免「必須先連上解析器，才能知道解析器位址」的循環。

以下是方便本機診斷的 DNS 片段，使用獨立的回送位址連接埠。它不會自動將作業系統 DNS 改成這個位址，也不會接管應用程式流量。先使用指令明確查詢此監聽連接埠，再搭配 TUN 或系統設定驗證接管流程，便能分別排查「解析服務本身失敗」與「應用程式未進入解析服務」。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    '+.example.com':
      - 223.5.5.5

範例位址僅用來說明設定結構，實際選擇須考量電信網路、地區與存取策略。nameserver-policy 可為特定網域指定解析器，適合需要內網解析或明確區域解析結果的網域；不要任意將整個業務網域交給公共解析器，否則可能無法取得內部位址。比對範圍應盡量縮小，先確認單一網域，再擴大至其子網域。

讓解析請求配合出口策略

若要讓 DNS 連線遵循路由規則，可研究 respect-rules，並正確設定 proxy-server-nameserver 以解析節點伺服器的主機名稱。否則會變成解析節點位址需要代理，而建立代理又需要節點位址，容易形成啟動循環。並非所有訂閱都有適用的統一開關組合，關鍵是至少保留一條不依賴尚未建立之代理的引導路徑。

direct-nameserver 可用於直連出口相關的解析需求；若同時使用網域策略，也要確認它是否遵循 nameserver-policy。未觀察實際結果前，不要同時設定多組 nameserver、fallback 與策略對應。複雜設定可能讓同一個網域發出多路查詢，也會增加追查回應來源的難度。

傳統的 fallback 與 fallback-filter 是選擇解析結果的機制，不能簡單理解成「第一個 DNS 逾時才會查詢第二個」。篩選條件、地理判斷與候選回應都會影響最終答案。若現有環境已透過明確的網域策略滿足需求，可先維持簡單設定；只有確實遇到污染或回應異常時，再根據可重現的範例設計篩選條件。

分別驗證回應結果與請求去向

在已安裝 dig 的環境中，可使用下列指令查詢本機監聽器。使用 Windows 內建工具時，請留意部分工具對非預設連接埠的支援方式不同；查詢系統 DNS 的結果不代表查詢了本機核心。記錄查詢時間、回應類型與記錄中的上游選擇，再對照應用程式連線，才能取得完整的驗證依據。

dig @127.0.0.1 -p 1053 example.com A

Fake-IP 模式下回傳虛擬位址是預期行為，不應只因結果與公共 DNS 不同就判定解析錯誤。對於 IPv6，也要區分核心的總開關、DNS 是否回傳 AAAA、系統 IPv6 路由及節點傳輸能力。範例關閉 DNS 的 IPv6 回應只是為了減少初次診斷的變數，並非建議所有網路永久停用 IPv6。

所謂的洩漏測試通常只能觀察某次網頁請求涉及的解析來源，無法涵蓋所有應用程式與通訊協定。若瀏覽器啟用了獨立的安全 DNS，應另外檢查其設定；企業裝置也可能套用組織管理政策。不要為了通過某個測試頁面而反覆修改系統設定。先確認防護範圍與查詢接管範圍，再交叉比對記錄、路由與應用程式行為。

TUN 與 Fake-IP 協同運作

TUN 與 Fake-IP 作用於不同層級。TUN 建立虛擬網路介面，讓符合路由條件的 IP 流量進入核心；Fake-IP 則改變 DNS 回應方式，以虛擬位址保留網域關聯。前者解決流量如何進入，後者協助辨識流量要連往哪個網域。兩者常搭配使用，但可分開設定，啟用其中一項不代表另一項已生效。

先確認權限與路由歸屬

桌面用戶端啟用 TUN 通常需要系統管理員權限、系統授權或已安裝的背景服務。系統代理開關主要供遵循系統設定的應用程式使用，詳細操作請參閱系統代理設定。若瀏覽器能連線但命令列工具不通，可能只是後者未讀取系統代理；此時應先判斷是否確實需要 TUN，不要同時修改節點與 DNS。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

這段設定描述一種常見的接管方式，但實際效果取決於系統權限、用戶端服務與本機路由。auto-route 會新增相關路由，auto-detect-interface 則嘗試辨識出口介面；同時使用多張網卡、虛擬機器或多個 VPN 時，自動辨識未必符合預期。修改前先記錄預設出口；發生問題時檢查路由，不要不斷切換網路堆疊碰運氣。

TUN 平台檢查重點
環境優先檢查項目常見衝突
Windows服務權限、虛擬介面與系統防火牆其他 VPN、虛擬交換器、回送限制
macOS網路授權、預設路由與服務狀態其他隧道介面、網路過濾軟體
LinuxTUN 裝置、權限與策略路由防火牆規則、容器與網路命名空間

了解虛擬位址與例外網域

Fake-IP 會將網域映射到專用虛擬位址池；連線返回核心後，再還原網域關聯。若應用程式只儲存 IP、將此位址轉傳到其他裝置，或在核心結束後繼續使用快取，都可能造成連線失敗。因此虛擬位址不能當成網站的真實 IP 用於防火牆白名單，也不適合複製到未經同一核心處理的裝置使用。

對印表機探索、區域網路裝置或依賴真實位址運作的服務，可在 fake-ip-filter 中設定例外，讓符合條件的查詢回傳真實位址。篩選條件應根據實際發生問題的網域設定，而非直接排除一大批公共服務。排除的連線可能無法享有原有的網域映射優勢，後續便須依賴位址規則或嗅探；範圍過大的篩選會降低分流結果的可解釋性。

# 合併至現有 dns 物件，不要重複宣告另一組 dns 設定
dns:
  fake-ip-filter:
    - '*.lan'
    - '*.local'

.local 服務也可能使用多播 DNS，一般 DNS 例外不保證裝置探索功能會恢復。TUN 對一般五十三號連接埠的攔截，也不會自動接管所有加密 DNS 或多播查詢。若可透過固定位址連線至列印服務，卻無法自動探索裝置，應繼續檢查多播、區域網路路由與系統服務，而非只更改 DNS 伺服器。

避免重複接管與錯誤迴圈

企業 VPN、遠端辦公隧道與其他代理用戶端都可能改寫路由。一般應先關閉不需要的接管程式，再驗證單一 TUN；若確實需要並用，須逐一確認辦公網段、代理伺服器位址與本機管理位址的路由歸屬。排除網段必須依據實際網路規劃，不宜照抄網路上的長清單，否則可能讓原本應進入代理的業務直接繞過。

切換 Fake-IP、關閉 TUN 或重新啟動核心後，應用程式可能仍快取舊位址。可先結束應用程式連線並重新查詢網域，必要時清除系統 DNS 快取，再檢查新連線。仍有舊連線時，不要只重新整理一次網頁就下結論。若只有特定應用程式失敗，記錄其目標位址與使用的通訊協定，比同時修改所有路由更有效。

復原故障時應維持明確的步驟：先關閉 TUN，確認基本網路恢復；再檢查用戶端是否已移除相關路由，最後還原先前的系統代理狀態。正常結束用戶端時通常會清除自身設定的接管項目，異常結束則可能留下殘留設定。常見狀況可參閱故障排查問答；調整系統網路前，尤其是遠端操作裝置時，應先準備本機復原方式。

網域嗅探與辨識限制

網域嗅探會在連線進入核心後，從部分通訊協定的初始資料擷取目標主機資訊。常見來源包括 HTTP 的 Host，以及 TLS 交握中的伺服器名稱。這有助於只有目標 IP 的連線套用網域規則，但不能取代 DNS，也無法保證辨識所有加密流量。將它視為補充線索，比當成完整的應用程式辨識功能更恰當。

先有流量，再談辨識

嗅探只會處理核心已接收的連線。若應用程式繞過系統代理，且流量未進入 TUN，啟用嗅探也不會讓流量自動進入。反過來說，連線已有可靠的網域資訊時，額外嗅探未必有幫助。排查時應先確認連線有出現在用戶端的連線頁，再查看網域欄位、命中規則與最終出口，而非先擴大嗅探連接埠範圍。

sniffer:
  enable: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: false
    TLS:
      ports:
        - 443
        - 8443
      override-destination: false
    QUIC:
      ports:
        - 443
      override-destination: false

範例將嗅探限制在常見通訊協定連接埠，且不覆寫原始目的位址，用於先觀察辨識是否可靠。連接埠只是通訊協定可能使用的位置，並不代表內容必然符合預期；四四三連接埠也可能承載其他通訊協定。將所有連接埠加入嗅探，會增加不必要的處理，也讓非標準服務的相容性問題更難定位，應依實際業務逐步擴大範圍。

辨識網域與改寫目標是兩回事

override-destination 決定是否以嗅探結果覆寫連線目標。對依賴指定 IP 的服務，覆寫後可能連到另一台伺服器；對使用 CDN 的網站，重新解析也可能改變位址選擇。若只是想改善分流判斷，應先保留目的位址，透過連線記錄驗證規則行為，再決定是否確實需要覆寫，不必將此選項視為必開設定。

啟用 parse-pure-ip 可讓部分目標只有 IP 的流量參與嗅探，但辨識結果取決於通訊協定是否帶有可讀取的網域。直接連線到 IP 的 HTTP 請求未必包含預期的網域，TLS 也可能沒有相應的伺服器名稱。應用程式自有的加密通訊協定更不一定符合 HTTP、TLS 或 QUIC 的解析方式；發生問題時，不能只憑「使用 HTTPS」就推斷必然可以辨識。

需要強制嗅探或略過嗅探時，可使用 force-domain、skip-domain 等設定明確指定範圍。例外應對應可重現的服務，不宜將來源不明的網域清單整段複製到設定中。尤其在存在共用 IP、反向代理或內網閘道時，辨識出的名稱不一定代表連線最初的業務意圖，還須一併考量原始目標。

加密通訊協定與隱私限制

部分 TLS 部署採用加密用戶端交握等機制，可能導致傳統的伺服器名稱擷取失效。QUIC 使用 UDP，處理方式與 TCP 不同，還會受到節點 UDP 能力、路由與網路策略影響。若瀏覽器可連線，但用戶端無法辨識網域，未必是設定錯誤；只要規則能依據其他可靠資訊正常運作，就不必要求每條連線都顯示網域。

嗅探不會解密 HTTPS 內容，也不需要為了一般網域辨識在裝置上安裝自簽根憑證。它讀取的也不是使用者登入密碼或網頁內容。不過，網域本身仍可能反映使用者的瀏覽意圖，因此匯出記錄或分享面板內容時應有所節制。分享故障資料前，請移除私人網域、訂閱資訊與節點憑證，盡量只保留足以重現規則問題的片段。

驗證時先使用一個已知網域，分別在關閉與開啟嗅探的狀態下建立新連線，比較網域欄位與規則命中結果。不要只看網頁能否開啟，因為兩種狀態可能都使用相同的兜底策略而成功。若開啟後連線異常，先關閉目的位址覆寫，再縮小連接埠範圍；仍有問題時，暫時關閉嗅探，回頭檢查 DNS 映射與規則設定等基本路徑。

對金融登入、企業內網與固定位址存取服務而言，穩定性通常比擴大辨識範圍更重要。可保留明確的位址或網域規則，並為已知不相容的服務建立小範圍例外。嗅探設定的驗收標準應是「目標業務依預期分流，且未造成異常」，而不是「所有連線都顯示名稱」，如此才不會為了介面資訊完整而犧牲實際可用性。

本機覆寫與多重訂閱合併

訂閱負責提供遠端節點與基礎設定，本機覆寫則用來保留裝置專屬偏好。將兩者分開，可降低訂閱更新後連接埠、DNS 或規則例外遭覆蓋的風險。但「覆寫」並不是所有用戶端共用的同一種檔案格式：有些支援物件合併，有些提供規則前置，也有些使用指令碼產生設定。操作前請先確認目前用戶端的功能說明，不要將某款應用程式的編輯方式套用到另一款。

先釐清各類資料由誰維護

節點位址、驗證參數與伺服器端變更通常由訂閱來源維護；本機監聽位址、區域網路開放範圍、裝置專用規則與控制介面則較適合留在本機。DNS 與策略群組介於兩者之間，視上游設定是否已包含完整設計而定。若打算接手維護這兩部分，須明確決定是覆寫整個物件，還是只新增少量欄位，避免一部分沿用上游假設，另一部分卻採用本機邏輯。

物件合併與陣列合併應分開檢查。例如覆寫 dns.enable 通常只涉及一個布林值，而 rules、proxy-groups 則是陣列；用戶端可能選擇取代、前置、附加或依名稱處理。只看到編輯器中新增了規則，不代表執行中的設定保留了原規則。每次變更合併方式後，都應檢查最終規則順序與策略群組數量。

本機覆寫的維護範圍
內容建議由誰維護檢查重點
節點驗證與位址訂閱來源更新是否成功、節點是否失效
監聽連接埠與存取範圍本機設定是否再次遭介面設定覆寫
個人網域例外本機前置規則是否排在範圍較廣的規則之前
策略群組與 DNS明確指定由其中一方維護名稱依賴與完整物件結構

透過代理集合管理多個來源

合併多個訂閱不應只是把兩份完整 YAML 接在一起。兩邊通常都包含同名頂層索引鍵、兜底規則與策略群組，直接拼接會造成重複或覆寫。較清楚的做法是保留一份主設定，將多個來源載入為代理集合，再透過統一的本機策略群組引用。若遠端提供的是完整用戶端設定，應先確認內容是否符合代理集合格式，不能只更改 URL 就認定相容。

proxy-providers:
  personal:
    type: file
    path: ./providers/personal.yaml
  work:
    type: file
    path: ./providers/work.yaml

proxy-groups:
  - name: 來源選擇
    type: select
    use:
      - personal
      - work
    proxies:
      - DIRECT

上述本機檔案各自應包含有效的 proxies 清單，路徑須指向已備妥的節點檔案；它們不是存放任意訂閱內容的位置。需要遠端更新時，再改用 HTTP 集合，並為每個來源設定獨立的快取路徑。不要在文件、截圖或同步儲存庫中公開真實訂閱連結，因為其中通常包含可直接用來存取服務的身分資訊。

不同來源可能使用相同的節點名稱。應透過用戶端或核心支援的來源覆寫機制加入可辨識的前綴，並確認策略群組仍引用正確目標；不要只依節點顯示順序判斷來源。使用正規表示式篩選時，也要考慮前綴變更，尤其是依地區或用途篩選時。合併後先核對實際候選項，再確認兩個來源是否都能建立連線。

為更新保留可還原的範圍

較穩妥的操作順序是先複製目前設定，新增一個來源並確認可用後，再新增第二個，最後統一規則入口。每個步驟都要保留可還原的狀態。訂閱更新失敗時，不要立即刪除所有來源；先確認是驗證失效、下載失敗，還是內容解析錯誤。只有在確認快取損壞且遠端來源可用後，才針對相關快取進行清理。

使用指令碼覆寫時，還須處理欄位不存在、空陣列與名稱變更等情況。當某個來源暫時沒有資料時，指令碼應提供明確結果，而非產生引用不存在群組的設定。不要從不可信來源複製具備網路請求或檔案讀寫能力的指令碼。能以宣告式欄位完成的簡單修改，通常不必引入完整指令碼，以降低維護與審查成本。

最終驗收不能只看「兩份訂閱都顯示匯入成功」，還要確認更新前後本機規則仍位於正確位置、節點來源清楚、策略群組沒有循環，以及 DNS 與連接埠沒有意外變更。快速匯入步驟請參閱訂閱匯入指南。本頁的合併結構適合長期管理，不要求初次使用者在尚未建立連線前就架設多來源架構。

外部控制面板與安全界線

外部控制面板透過 mihomo 控制介面讀取執行狀態、切換策略及檢視連線。它不是代理入口，也不是訂閱伺服器。混合連接埠負責應用程式流量，控制連接埠則負責管理操作，兩者不可互換。面板無法開啟時，應分別確認靜態頁面能否載入、控制介面是否可連線，以及驗證是否通過，不要直接更改供上網使用的混合連接埠。

本機管理從回送位址監聽開始

若使用桌面用戶端內建介面，通常不需要另外開放控制連接埠。確實需要連接本機面板時，可先使用回送位址，避免管理介面暴露給區域網路中的其他裝置。以下憑證僅供教學示範，實際使用前應改成自行產生且只保存在本機的強密碼，不應將範例值用於其他裝置可存取的服務。

external-controller: 127.0.0.1:9090
secret: "your-password"
external-ui: ./ui

external-ui 指向已備妥的面板靜態檔案目錄，並相對於核心工作目錄解析；它不會自動產生面板檔案。若目錄存在但缺少入口檔案，控制介面可能正常運作，頁面仍會回傳錯誤。下載面板檔案時應選用可信任的專案來源，並依其說明部署至本機；不要將未知網頁中輸入的控制憑證當成一般網站登入資訊處理。

綁定 127.0.0.1 只允許本機透過對應位址存取。若改成監聽所有介面，區域網路甚至其他可連線的網路都可能存取該連接埠，是否能連上還取決於防火牆與網路拓撲。此外，allow-lan 主要影響代理監聽範圍，並不是控制介面的總開關；關閉它不能取代控制連接埠本身的監聽與存取限制。

分別排查連線、驗證與瀏覽器限制

連接控制介面遭拒時，先檢查核心是否正在執行、監聽位址是否正確，以及連接埠是否已被占用。若可連線但回傳未授權，通常應檢查面板儲存的控制密碼，而非繼續調整防火牆。面板能顯示頁面卻無法取得資料，也可能是瀏覽器跨來源限制，或頁面位址與介面位址不一致；應在瀏覽器開發人員工具中查看實際請求結果。

HTTPS 頁面存取 HTTP 控制介面時，可能受到混合內容限制。優先採用同一部裝置、同來源的本機部署方式，減少跨來源設定需求；若必須經過反向代理，應明確劃分 TLS、驗證與來源限制分別由哪個層級負責。不要為了排除瀏覽器錯誤而允許任意來源，也不要將控制密碼放在公開 URL 中，這些網址可能出現在瀏覽記錄、記錄檔或分享內容裡。

需要跨裝置管理時，優先使用受控的安全隧道，或只在可信任的管理網路中開放，並透過系統防火牆縮小可存取裝置的範圍。直接將控制介面轉送至公網會增加風險：它不只可檢視狀態，還能影響正在使用的策略與設定。只設定密碼，不代表已處理傳輸加密、暴力破解嘗試與面板來源可信度。

完成設定變更的驗證流程

透過面板切換群組後，確認用戶端介面與新連線的實際出口同步變更；透過面板更改執行模式後，檢查是否影響目前的規則驗證。面板狀態、設定檔與執行狀態不一定永遠一致：有些選擇會由用戶端保存，有些則會在重新載入時遭覆寫。需要持續生效的參數仍應回到明確的設定維護層管理，而非只在控制介面中暫時修改。

記錄內容應以足以排錯的最小範圍為原則。需要除錯時，暫時提高詳細程度；問題重現後再恢復常用等級，避免長時間記錄大量存取網域。對外分享資料前，請檢查節點驗證資訊、訂閱連結、控制密碼與個人存取記錄。若管理憑證意外公開，應更換實際使用的憑證，並清除面板儲存的舊值，而不是只從截圖中刪除文字。

整份指南的最終檢查順序可固定為：設定成功載入、節點來源可用、策略群組引用完整、規則命中正確、DNS 路徑清楚、TUN 接管符合預期、嗅探未引發相容性問題，以及控制介面只在必要範圍內開放。每次只修改一個變數並保留回復方式，通常比不斷堆疊參數更容易維護。若無法定位問題，可附上已去除敏感資訊的記錄，前往故障排查分類依症狀逐項確認。