Clash 進階設定手冊

策略組類型與實作

策略組是規則與實際出口之間的中介層。規則不必逐一指定節點名稱，而是指向穩定的組名；再由組內設定手動選擇、自動選擇或故障切換。更新訂閱時，即使節點名稱變動，只要組名與提供器引用保持一致，分流規則就不必跟著修改。開始設計前，先區分三種物件：節點負責連線至遠端，提供器負責收集節點，策略組負責選擇出口。名稱可自行設定，但引用必須完全一致，包含空格與大小寫。

先決定手動選擇或自動切換

select 適合需要固定出口的服務，使用者可在代理頁選擇組內成員，核心會依選擇結果連線。url-test 定期向測試網址發送探測，在可用成員中選擇回應較快的出口；tolerance 用來避免因細微差異而頻繁切換，不是節點品質評分。fallback 依成員順序尋找可用出口，適合設定主要與備援線路。load-balance 會在不同連線間分配出口，不會合併單一連線的頻寬，也不保證每次請求都使用相同出口。

登入、付款或需要維持工作階段穩定的服務，建議使用手動選擇組，而不是一味追求每次探測都更快。自動組切換後，已建立的連線通常不會立即轉移；新連線才會使用新的選擇結果。因此，瀏覽器同一頁面的不同資源可能短暫來自不同出口。遇到這種情況，先固定一個節點、關閉舊連線並重新開啟頁面，再確認服務本身是否限制出口變動。不要只因網頁載入失敗一次，就認定是規則語法有誤。

用兩層架構分開日常選擇與自動候選

以下範例假設已有名為 primary 的 proxy-providers 提供器，匯入方式請參閱覆寫章節。自動組會讀取提供器成員，上層手動組則可在自動選擇結果與直連之間切換。測試 URL 是連線探測目標，不是訂閱網址；能否連線會同時受出口、DNS 與目標服務策略影響。interval 的單位是秒，設定過短會增加探測請求，尤其不適合背景執行受限的行動裝置。

# 設定片段：依賴現有的 primary 節點提供器
proxy-groups:
  - name: 自動候選
    type: url-test
    use:
      - primary
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
  - name: 日常出口
    type: select
    proxies:
      - 自動候選
      - DIRECT

rules:
  - MATCH,日常出口

策略組可以相互引用，但不能形成循環。例如日常出口包含自動候選，自動候選又引用日常出口，就無法找到最終出口。檢查時從規則目標逐層追查，直到抵達實際節點或 DIRECT。若用戶端顯示組內沒有成員，先確認提供器是否成功載入，再檢查篩選條件是否排除了所有節點；不要用增加巢狀層級來掩蓋成員缺漏。部分用戶端會記住上次的選擇，但名稱變更後可能會還原為預設成員；更新訂閱後，請重新確認重要服務所用的策略組。

分開驗證探測結果與實際連線

代理頁的探測結果，只能反映某個出口連線至指定測試目標的表現。實際應用可能使用不同網域、連接埠或 UDP，不能因此推斷所有服務都能正常使用。驗證策略組時，應一併檢查連線頁顯示的命中規則、最終出口與目標主機。若自動組運作正常，但影音或遊戲仍有問題，請固定成員後再測試協定支援與服務地區限制。更多介面操作請參閱代理選擇教學。需要長期固定出口時，保留一條明確的手動選擇路徑，比增加多層自動演算法更容易維護。

規則集訂閱管理

將規則放在 rule-providers 中，可以將規則內容與分流決策分開維護。提供器會下載或讀取網域、IP 位址或傳統規則清單，再由 rules 使用 RULE-SET 指定命中後的出口。規則集本身不會決定要代理還是直連；同一份清單可在不同設定中綁定不同策略組。維護時要留意三件事：檔案格式是否能正確解析、更新是否可靠，以及規則在總清單中的位置是否符合優先順序。改用訂閱管理可減少重複編輯，但不會自動解決規則衝突。

behavior 與 format 必須符合檔案內容

behavior: domain 代表網域規則集合，ipcidr 代表 IP 網段集合，classical 則代表包含規則類型的傳統規則集合。format 用來描述檔案格式，常見有 YAML 或純文字；選擇 YAML 時通常需要 payload 層。檔名以 .yaml 結尾，不代表內容一定符合要求；更不可將包含節點與策略組的完整訂閱放進規則提供器。載入失敗時，請開啟實際檔案檢查首行、縮排與項目內容，不要只修改副檔名。

先用本機規則集建立可驗證的最小範例。以下兩段分別屬於主設定與獨立規則檔；路徑會依核心設定目錄解析，圖形用戶端使用的實際目錄則應從設定管理介面或執行日誌確認。規則集只列出需要直連的文件網域，總規則仍保留區域網路直連例外與最後兜底。範例中的日常出口沿用上一章的策略組；若缺少該組，請先補上，不能將這段程式碼單獨當成完整訂閱匯入。

# 主設定片段
rule-providers:
  local-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - RULE-SET,local-domains,DIRECT
  - MATCH,日常出口

# 獨立檔案：rules/local-domains.yaml
payload:
  - '+.example.com'
  - '+.example.org'

遠端更新時保留可復原的本機版本

遠端提供器使用 type: http，並設定 url、path 與 interval。網址應指向格式明確的規則來源；快取路徑不可與其他提供器共用，否則下載內容可能互相覆蓋。若啟動時下載規則集需要代理，而建立代理又依賴尚未載入的規則，就可能形成啟動依賴問題。請確保重要的引導網域有明確可用的連線路徑，並保留一份本機基本規則。更新失敗時，應從日誌與檔案狀態確認是否仍使用快取，不能只看用戶端更新按鈕的提示。

訂閱間隔不代表內容品質有保障。頻繁下載來源不明、分類界線不清的清單，可能讓登入介面與靜態資源分別走不同出口。加入新規則集前，先確認預期涵蓋的服務範圍，再檢查代表性網域是否包含在內。大型傳統規則集可能增加載入時間與裝置資源負擔；路由器環境還需考量儲存空間與寫入次數。遠端內容更新後，應以新建立的連線驗證；不要用持續存活的舊連線判斷新規則是否生效。

規則順序決定衝突時的結果

規則會依順序比對，命中後通常不會繼續往下尋找。特定網域例外應放在涵蓋範圍較大的集合之前，兜底 MATCH 則放在最後。IP 位址規則加上 no-resolve 時，不會為了該規則主動將網域解析成位址；若目前連線只有網域資訊，就可能無法命中這條位址規則。網域、地理資料與位址規則應依服務需求搭配，不是規則越多就越完整。中國大陸網站直連的細節，請參閱分流規則實戰。

DNS 設定最佳化

DNS 設定不只是填入解析伺服器位址。一次連線可能包含代理節點網域解析、服務網域解析，以及 DNS 上游本身的引導解析；這些查詢的出口不一定相同。先確認應用程式將查詢交給誰，再確認核心如何連線至上游，最後檢查回傳位址是否適合後續路由。瀏覽器安全 DNS、系統加密解析與應用程式內建解析，都可能繞過用戶端的 DNS 入口。只修改 nameserver，無法證明所有應用程式的查詢都經過核心。

區分引導解析、節點解析與服務解析

default-nameserver 主要用來解析 DNS 上游的網域，應使用可直接連線的位址；nameserver 是一般服務查詢所使用的上游；proxy-server-nameserver 可獨立處理代理節點的網域解析，避免節點連線依賴尚未建立的代理路徑。nameserver-policy 則可為指定網域配置特定解析器，適合內部網域、特定網路服務或有明確解析界線的情況。這些欄位處理不同階段，不應直接將同一組位址複製到每個欄位。

以下是可合併使用的 DNS 片段，以 Fake-IP 作為服務連線的網域映射方式。列出的解析位址僅供參考，不保證在所有網路環境都能連線；使用前請先測試目前網路。監聽位址綁定迴環介面，只接受本機請求。若路由器需要為區域網路裝置提供服務，請另外規劃監聽、防火牆與存取範圍；不能直接將桌面範例改成監聽所有介面，就認為部署已完成。

# 設定片段：不包含代理與規則定義
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
    - 1.1.1.1
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://cloudflare-dns.com/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'

依解析需求調整，不要一味增加伺服器

內部網域通常需要交由本機閘道或組織提供的解析器處理，公共解析器不一定能查到這些記錄。確認實際使用的內部網域後，可透過 nameserver-policy 將查詢導向內部 DNS，並為這些網域設定合適的 Fake-IP 例外。這裡有兩個獨立決定：是否回傳映射位址，以及由哪個上游提供實際解析結果。將網域加入過濾清單，只會改變增強模式的處理方式，不會自動將查詢導向正確的內部解析器。

fallback 與 fallback-filter 用來篩選及比較不同上游的結果，不等同於單純設定主要與備援伺服器的順序。若沒有明確的篩選目標，維護少量且容易理解的上游，比堆疊大量位址更容易排錯。respect-rules 可讓 DNS 上游連線遵循路由規則；啟用前，必須先考量節點解析的獨立路徑，並設定適當的 proxy-server-nameserver。否則可能形成「解析上游要先連代理，連代理又要先解析」的循環依賴。

分別驗證解析結果與查詢出口

可對本機監聽位址執行 nslookup example.com 127.0.0.1，但此命令預設查詢標準 DNS 連接埠，無法直接測試上方使用的 1053 連接埠。支援指定連接埠的工具可執行 dig @127.0.0.1 -p 1053 example.com。收到映射位址只代表該次查詢進入 Fake-IP 處理，不表示所有查詢都經過相同路徑。還需檢查瀏覽器解析設定、TUN 的 DNS 劫持，以及日誌中的上游連線，才能判斷應用程式的實際行為。

修改 DNS 後，舊快取可能來自系統、瀏覽器或核心的不同層級。先建立新連線，再視需要清除快取；重新啟動用戶端不一定會清除瀏覽器快取。若網頁網域解析成功但連線失敗，請檢查映射是否仍有效、目標策略組是否可用，以及 IPv6 是否走了另一條連線路徑。檢測方式與欄位搭配請參閱DNS 洩漏檢測與設定說明。診斷時應描述特定應用程式與查詢路徑，不要只用單一檢測網站的結果代替完整分析。

TUN 與 Fake-IP

系統代理主要影響遵循系統代理設定的應用程式；TUN 則透過虛擬網卡與路由處理 IP 流量。兩者接管的範圍不同，開啟系統代理不代表所有應用程式都已被接管。Fake-IP 是 DNS 網域映射機制，不是 TUN 的另一個名稱。兩者常搭配使用，是因為映射可讓收到 IP 封包的核心找回原始網域，繼續進行網域分流；但 TUN 也能搭配其他 DNS 模式，Fake-IP 亦可用於合適的非 TUN 情境。

啟用前先確認權限與目前網路環境

使用桌面用戶端時，先進入設定確認服務模式或相關系統授權，再啟用 TUN。Windows 通常需要管理虛擬網卡與路由的服務權限；macOS 需要系統授權；Linux 則需要相應的網路管理權限。實際操作方式取決於用戶端的封裝。Android 與 iOS 通常透過系統 VPN 功能接管流量，同一台裝置上的其他 VPN 可能無法同時執行。公司網路、安全軟體與既有通道也可能改變路由；請先記錄原有狀態，不要在影響範圍不明時強行新增路由。

以下程式碼是網路接管片段。auto-route 會讓核心建立所需路由，auto-detect-interface 則協助識別出口介面；多網卡、橋接或已有 VPN 的環境仍需實際測試。dns-hijack 用於攔截符合條件的 DNS 流量，不會自動識別所有加密 DNS。若應用程式透過 HTTPS 連線至內建解析器，不會因為這裡設定了 53 連接埠，就變成核心處理的一般 DNS 查詢。

# 設定片段：同時依賴已啟用的 dns 設定
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

了解 stack 與映射位址的適用範圍

stack 決定 TUN 封包進入哪種協定堆疊路徑。system、gvisor 與 mixed 的支援情況及行為，取決於核心與平台；不要只憑選項名稱判斷效能一定較佳。建議保留用戶端預設值，只有遇到可重現的相容性問題時，才個別切換比較。測試時應使用相同應用程式、出口與網路，觀察 TCP、UDP 及區域網路連線是否改變；同時修改堆疊、DNS 與規則，會讓結果難以判斷。

Fake-IP 回傳的是映射用位址，不能直接將它當成網站的實際伺服器位址來判斷地理位置。後續應用程式連線必須再次進入保留映射記錄的核心，否則該位址無法在一般網路中作為實際目的地存取。用戶端退出、映射記錄遭清除，或應用程式繼續使用舊快取時，可能出現「剛切換設定就無法連線」的情況。此時先關閉應用程式的舊連線並重新解析，再判斷是否需要清除快取；不要將整個映射網段加入直連規則。

區域網路例外與故障復原

印表機、網路儲存裝置、投放與區域網路探索涉及不同協定，只設定網域過濾可能不夠。先確認服務使用內部網域或固定位址，再檢查網段路由、DNS 解析與多點傳送探索。將確實需要實際位址的網域加入 fake-ip-filter，將確認的內部網段設為直連，並確認 TUN 路由仍允許存取本機介面。不要一概排除整個服務網域類別；範圍過大的例外會讓網域規則失去預期的比對資訊。

啟用後完全無法連線時，依序檢查權限、虛擬網卡、預設路由、DNS 上游與節點連線。先關閉 TUN、保留系統代理；若系統代理恢復，問題可能集中在接管層；若兩者都無法使用，再檢查訂閱、策略組與基本網路。記錄錯誤日誌後，每次只還原一項設定；必要時恢復啟用前儲存的設定。完整平台操作請參閱TUN 模式啟用教學，一般問題可查看故障排除分類。

網域嗅探

網域嗅探會在連線缺少網域資訊時，嘗試從支援的協定特徵中還原主機名稱。常見資訊來源包括 HTTP 要求中的 Host、TLS 握手中可見的伺服器名稱，以及部分 QUIC 握手資訊。這不是解密功能，核心不會因此讀取所有 HTTPS 內容，也無法保證每條連線都能取得網域。應將它視為補充比對資訊的功能：應用程式提交 IP 位址，或 DNS 查詢未經目前核心處理時，嗅探有機會讓網域規則繼續生效。

先確認連線是否真的缺少網域資訊

如果連線頁已顯示正確網域並命中預期規則，啟用嗅探未必有幫助。先找出一個穩定且可重現的案例，觀察它是否只顯示位址、命中位址規則，或直接落入兜底規則。啟用後比較同一服務的新連線，確認是否能還原正確主機名稱。不要將嗅探當成所有分流問題的通用解法：規則順序錯誤、策略組沒有成員、出口無法連線及 DNS 上游失敗，都應在各自層級處理。

以下片段啟用 HTTP、TLS 與 QUIC 的識別範圍。連接埠陣列中的字串區間屬於設定語法，不是網路掃描工作。parse-pure-ip 允許對純 IP 目標嘗試嗅探；force-dns-mapping 則會在 DNS 映射相關情境中加強嗅探處理。使用前請確認目前 mihomo 核心支援這些欄位；若啟動時回報未知設定或不支援的協定，應先確認用戶端實際使用的核心，而不是繼續堆疊其他選項。

# 設定片段
sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443

網域比對與目的地改寫是兩件事

override-destination 控制是否以嗅探結果取代原始目的地。初次測試時先保持關閉，觀察補充網域資訊對規則比對的影響；只有服務確實需要依嗅探到的網域重新決定目的地時，才評估是否啟用。應用程式連線至指定位址，可能是因為內建調度、特殊解析或固定伺服器要求。貿然改寫目的地會改變應用程式原本選擇的路徑；即使嗅探到的名稱看似正確，也不代表重新解析後一定相容。

同一個 IP 位址可能承載多個網域，不能只靠連線日誌中的位址判斷服務名稱。反過來說，握手帶有的名稱也可能是閘道、共用入口或中介服務，不一定是使用者在頁面上看到的網站。驗證時應一併記錄原始目的地、嗅探名稱、命中規則與最終出口。已建立的長連線通常無法因切換嗅探設定而重新取得最初的握手資訊；必須中斷並重新建立連線，才能取得可比較的測試資料。

協定限制與相容性排錯

使用加密用戶端問候等機制的連線，可能會隱藏原本可見的伺服器名稱；非標準協定、特殊握手或過早失敗的連線，也可能沒有足夠資訊。QUIC 使用 UDP，能否連線還取決於出口是否支援 UDP 及網路路徑；不應把所有 QUIC 連線失敗都歸因於嗅探。測試時可在應用程式中暫時切換至可比較的 TCP 連線，再確認網域識別是否改變，但不要因此宣稱所有應用程式都必須停用 QUIC。

若啟用後只有特定服務異常，先關閉目的地改寫，再縮小協定與連接埠範圍。確認問題由特定網域造成時，可使用核心支援的 skip-domain 排除該網域，並確認排除模式符合預期；不要只因看到某個關鍵字，就加入範圍過大的萬用字元規則。也請檢查問題是否其實來自新增網域命中了更前面的規則。嗅探成功後路由結果改變，可能表示原本命中的 IP 規則已被網域規則取代；此時應調整規則設計，而不是直接認定嗅探失效。

想了解網域、位址與規則的術語差異，可查閱概念速查。日常維護時，嗅探應是有明確目的的補充功能，而不是每次連線異常都先打開的總開關。能說明一條連線為何命中某條規則，比啟用更多識別選項更重要。

本機覆寫與多訂閱合併

遠端訂閱負責提供節點或完整設定，本機覆寫則用來保留裝置專屬的連接埠、DNS、規則例外與策略組安排。直接編輯下載的訂閱檔，常會在下次更新時被覆蓋。正確作法是先確認用戶端支援哪種覆寫方式：合併 YAML、設定擴充、腳本處理或獨立本機設定。這些方式的合併順序不一定相同，同名欄位也未必都採用深層合併。不要將某款用戶端的操作步驟直接套用到其他用戶端。

先找出最終載入的設定檔

在設定頁選取目前使用的訂閱，再進入其擴充或覆寫入口；選單名稱請以用戶端實際介面為準。儲存後重新載入，再從執行設定、設定預覽或核心日誌檢查最終結果。原始檔案寫著 mixed-port: 7890，不代表執行時的連接埠一定是 7890，因為用戶端全域設定可能再次覆寫。請分別保存「遠端原始設定」、「本機覆寫」與「最終設定」，不要只看編輯器內容就判定設定已生效。若用戶端提供核心設定檢查功能，請先確認通過再重新載入。

合併多份訂閱時，建議先將節點來源整理成多個 proxy-providers，再讓策略組引用；不要直接拼接兩份完整 YAML。完整訂閱可能同時包含 dns、rules 與同名策略組，直接串接文字可能造成頂層鍵重複或引用衝突。以下示範本機節點提供器：兩個檔案都應包含有效的 proxies 陣列，而非包含所有規則與設定的完整設定檔。檔案路徑必須位於核心實際可存取的設定目錄中。

# 主設定片段：依賴兩份本機節點檔案
proxy-providers:
  primary:
    type: file
    path: ./providers/primary.yaml
  backup:
    type: file
    path: ./providers/backup.yaml

proxy-groups:
  - name: 多訂閱出口
    type: select
    use:
      - primary
      - backup
    proxies:
      - DIRECT

rules:
  - MATCH,多訂閱出口

陣列合併最容易改變設定結果

純量欄位通常只會有一個最終值，但規則、節點與策略組都是陣列。覆寫工具可能取代整個陣列，也可能將內容追加至末尾；這兩種行為對 rules 的影響截然不同。如果本機例外被加在既有 MATCH 之後，就無法如預期命中。儲存後請展開最終規則清單，確認例外確實位於兜底規則之前。策略組陣列也要確認原有引用是否保留，不要只確認新組出現，卻忽略原組已被整個取代。

來自不同來源的節點可能重名。顯示相同名稱不代表連到相同伺服器，也可能使選擇記錄與規則引用變得不清楚。使用用戶端支援的重新命名或提供器命名管理功能時，請維持轉換規則穩定，並記錄轉換發生在哪個階段。不要因臨時狀態頻繁替名稱加上前綴，否則更新後可能無法恢復手動選擇。篩選運算式也應先小範圍測試；意外比對所有節點或排除所有節點，都可能讓策略組行為偏離原本設計。

訂閱格式與遠端提供器的適用範圍

遠端提供器使用 HTTP 時，網址必須回傳核心能解析的節點集合。通用 Base64 連結集合、單一協定連結與完整 Clash YAML 是不同格式，不能只將 URL 填入 proxy-providers 就期待自動轉換。格式判斷與轉換流程請參閱訂閱格式對照。訂閱網址可能含有存取憑證，分享日誌、截圖或設定檔時請先移除；不要將真實網址交給處理方式不明的線上轉換服務。

維護時請保留一份已知可用的最終設定，以及對應的覆寫來源。每次更新後，先確認提供器成員數量與重要策略組是否有成員，再檢查關鍵規則與 DNS 欄位；若發生問題，先停用最近新增的覆寫並恢復原訂閱，不要一次刪除所有來源。尤其要留意腳本覆寫的錯誤處理：輸入結構變更時，腳本應明確報錯或保留原結果，不能靜默產生缺少節點的設定。只需要少數連接埠與規則例外時，簡單的 YAML 覆寫通常比複雜腳本更容易檢查。

外部控制面板

外部控制介面可用來讀取執行狀態、切換策略組、查看連線與管理設定；控制面板則是存取此介面的網頁前端。它與應用程式使用的代理連接埠是不同服務：瀏覽器能開啟面板，不代表瀏覽器流量已走代理；代理連接埠可連線，也不代表控制介面正常。設定前先確認面板是在本機、區域網路裝置或伺服器上執行，再決定介面應監聽哪些位址。一般桌面使用時，監聽本機迴環位址通常較容易控管存取範圍。

區分控制介面位址與靜態頁面目錄

external-controller 指定控制介面的監聽位址，external-ui 則指向面板的靜態檔案目錄。目錄中必須有實際的入口檔案與相關資源，只有空資料夾不會產生可用面板。可將來源可信的靜態面板檔案放入核心工作目錄，再設定相對路徑；若用戶端已內建面板，建議優先使用其管理入口，避免同時維護兩套位於不同位置的前端檔案。相對路徑仍以實際執行目錄為基準。

# 設定片段：ui 目錄中需已有面板靜態檔案
external-controller: 127.0.0.1:9090
external-ui: ./ui
secret: "your-controller-secret"

範例金鑰僅用來示範欄位；實際使用時必須自行設定足夠長、獨立且不公開的值。不要將金鑰寫入公開文章、截圖或程式碼儲存庫，也不要為了方便分享面板而將金鑰嵌入頁面連結。控制介面可修改執行狀態，不能當成唯讀資訊頁部署。若用戶端會自動管理 secret，請透過其授權方式連線，不要覆蓋用戶端產生的值，以免內建介面無法連線。

先從本機驗證，再考慮開放區域網路存取

先在同一台裝置上確認連接埠是否正在監聽，再開啟已設定的靜態面板路徑，並填入介面位址與金鑰。若頁面能開啟但連線失敗，表示靜態資源與 API 是兩條不同路徑，應檢查位址、驗證方式與瀏覽器錯誤訊息。以下命令示範如何在本機執行驗證查詢，範例金鑰應與本機設定一致；測試後請勿將含有實際金鑰的命令紀錄分享至外部。

curl --header "Authorization: Bearer your-controller-secret" \
  http://127.0.0.1:9090/configs

面板放在另一台裝置後，127.0.0.1 會指向瀏覽器所在的裝置，而不是執行核心的主機。請填入核心主機實際可連線的位址，並明確設定監聽範圍與防火牆規則。allow-lan 控制的是代理服務是否允許區域網路存取，不能將它視為控制介面開放與否的總開關。控制介面的監聽位址必須另行檢查；即使代理僅供本機使用，錯誤的介面綁定仍可能暴露管理功能。

瀏覽器安全限制與遠端部署

透過 HTTPS 存取面板時，若面板呼叫 HTTP 介面，可能受到混合內容限制；不同來源的頁面也可能遇到跨來源存取限制。請依實際部署方式選擇同源存取或安全的反向代理，不要關閉瀏覽器保護來繞過錯誤。若需調整控制介面的跨來源設定，只允許已確認的面板來源，不要預設開放所有來源。頁面顯示連線失敗時，瀏覽器主控台通常可以區分網路無法連線、驗證失敗與安全政策攔截。

不建議將控制介面直接公開至網際網路。確實需要遠端管理時，應使用具存取控管的私人網路或經過驗證的安全入口，並限制來源、設定加密傳輸與保留復原管道。金鑰驗證只是其中一層，不能取代網路邊界防護。遠端修改規則與策略組前，請確保目前的管理連線不會被剛修改的規則切斷；尤其在伺服器環境，應保留本機或其他可用的維護路徑，避免重新載入設定後失去控制。

外部面板適合需要仔細檢視規則與連線的使用者，並非完成基本連線的必要工具。若只需要匯入訂閱與選擇出口，先使用用戶端內建介面；各區域功能請參閱用戶端介面分區說明。排錯時先確認核心本身運作正常，再處理面板資源、介面存取與瀏覽器限制，避免把前端連線錯誤誤判為節點故障。

連接埠設定與設定驗證

連接埠是應用程式連線至核心服務的入口，不是遠端代理節點的伺服器連接埠。mixed-port 同時接受 HTTP 與 SOCKS 代理連線；port 和 socks-port 則可分別提供對應服務。控制介面、DNS 監聽與代理入口各有用途，不能因為都使用本機位址就互相替代。常見錯誤包括將 9090 填入瀏覽器代理設定，或把 7890 當成 DNS 連接埠。先確認協定，再核對位址與連接埠，比反覆更換數字有效。

確認設定欄位與服務的對應關係

本機使用時先維持 allow-lan: false，讓應用程式透過迴環位址連線。需要為區域網路裝置提供代理時，再明確設定綁定位址、裝置存取權限與防火牆規則。共享代理不代表也要共享控制介面，兩者應分別規劃。路由器與桌面系統的本機防火牆行為不同，不要只確認設定按鈕已開啟；必須從實際需要使用代理的裝置發起連線，才能驗證跨裝置存取路徑。

# 設定片段：本機代理入口
mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info

每次只驗證一項變更

修改前先保存可用設定，並記錄目前網路、策略組選擇與用戶端執行模式。若用戶端允許匯出最終執行設定，也請一併保存，因為訂閱原文未必包含用戶端額外加入的設定。修改後先檢查語法與引用，再重新載入；原生核心可在對應工作目錄執行 mihomo -t -f config.yaml 檢查設定。此命令不會取代網路測試，也無法證明遠端規則來源、節點與 DNS 上游都能連線。

確認設定載入後，檢查連接埠是否實際監聽。Windows 可使用 Get-NetTCPConnection -LocalPort 7890 查看本機 TCP 監聽狀態；Linux 可使用 ss -lntp；macOS 可使用 lsof -nP -iTCP:7890 -sTCP:LISTEN。部分命令需要相應權限或系統工具。若連接埠遭其他用戶端占用，請停止衝突程序或改用新的連接埠，並同步修改系統代理與應用程式設定；不要只改 YAML，卻繼續連線至舊連接埠。

可透過明確指定代理的方式暫時排除系統代理因素。以下命令指定 HTTP 代理入口並要求存取範例網域；成功只表示這次要求可透過該入口完成，不代表 TUN、所有規則或 UDP 都正常。測試 SOCKS 時，使用具遠端網域解析語意的方式，有助於區分本機解析與代理路徑解析的影響。請將測試目標換成目前要驗證的合法服務網址，並避免在日誌中留下私人存取參數。

curl --proxy http://127.0.0.1:7890 --head https://example.com
curl --proxy socks5h://127.0.0.1:7890 --head https://example.com

將故障定位至連線路徑中的特定環節

入口連線遭拒時，優先檢查程序、監聽位址與連接埠；流量進入核心但網域不正確時，檢查 DNS、應用程式的解析方式與嗅探；網域正確但出口錯誤時，檢查規則順序與策略組選擇；出口正確但連線失敗時，再檢查節點協定、目標服務與網路路徑。暫時提高日誌詳細程度有助於觀察，但排錯完成後應恢復適當等級，避免長期記錄過多連線資訊。分享日誌前，請移除訂閱網址、驗證資訊與私人網域。

設定驗證最好保留一組固定案例：一個應直連的網站、一個應代理的服務、一個區域網路目標，以及實際需要使用的 UDP 應用程式。每次只修改一類欄位，確認新連線的結果後再繼續下一項。若問題只在開機後出現，請檢查服務啟動與設定載入順序，並參閱開機自動啟動教學；若只有特定應用程式異常，請查看使用技巧。穩定的設定不在於欄位最多，而在於每個欄位都有明確用途，每個例外都有可重現的驗證方式。