Clash 進階設定指南

策略群組類型與分流實作

先釐清規則、策略群組與節點

規則決定連線交由哪個策略處理，策略群組決定下一步選擇哪個出口，節點則負責建立實際的代理連線。三者屬於不同設定層級。將執行模式切換為規則模式後，連線會先依規則順序比對，再進入指定的策略群組；策略群組也可能引用其他群組，最後才會連到節點或內建的 DIRECT、REJECT。因此，看到規則命中 PROXY，不代表連線已經使用某個特定節點，還要展開策略鏈確認最後選擇的出口。

設定中的名稱是以字串引用，大小寫、空格與標點都必須一致。若將群組名稱從「自動選擇」改為「自動」，引用該群組的規則和其他群組也要一併修改。遇到 proxy not found 這類錯誤時，先找出缺少的名稱，而不是反覆更新訂閱。有些介面會保留上次手動選擇的項目；群組結構修改後，舊選擇未必仍有效，重新載入後應再次確認目前的出口。

手動選擇、自動選擇與故障切換

select 適合需要明確控制出口的用途；由使用者決定選擇結果，通常不會因探測結果而自動切換。url-test 會測試候選項的連線狀況，並在符合容差等條件時選擇測試表現合適的項目。fallback 較重視候選項的設定順序，前面的項目可用時就優先採用。load-balance 則依指定策略分配連線，並不會自動把單一檔案傳輸拆分成多條線路。

以下為策略群組結構範例，假設現有的 proxies 或節點提供器中已經有「節點-A」和「節點-B」。這兩個名稱僅為示例節點名稱，使用時請換成執行設定中的實際名稱。測試網址是連線探測目標，不代表實際服務網站；若該網址在目前網路環境中受到限制，自動選擇結果也會失準。先確認手動選擇可用，再加入自動選擇，較容易判斷問題所在的層級。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - 自動選擇
      - 節點-A
      - 節點-B
  - name: 自動選擇
    type: url-test
    proxies:
      - 節點-A
      - 節點-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

出口穩定比頻繁切換更重要

interval 控制測試間隔，單位為秒；tolerance 為自動選擇提供一定的切換容差，避免些微波動就更換出口；lazy 可減少未使用群組的無效測試。不要把所有群組的間隔都設得太短。節點提供器也可能有自己的健康檢查；兩層探測同時頻繁執行，只會增加請求量及行動裝置的背景負擔，無法保證網頁載入更快。

登入服務、付款頁面與長時間連線通常較適合固定策略。自動切換可能讓同一帳號短時間內使用不同出口，觸發服務端的風險控管。依用途建立個別的手動群組，再讓相關網域規則指向該群組，比全域停用自動選擇更精準。若採用負載平衡，應先了解所選分配策略與工作階段維持之間的關係，並接受不同連線可能經由不同出口的情況。

驗證時先在連線頁面找到目標網域，記下命中的規則、策略群組與最終節點，再手動選擇另一個已確認可用的節點，關閉舊連線後重新存取。已建立的 TCP 連線通常不會因切換群組而自動轉移。若連線仍顯示舊出口，先釐清是沿用既有連線還是設定未生效；若顯示新出口仍無法連線，再檢查目標服務、節點可連線性與 DNS，避免把所有失敗都歸咎於策略群組。

以規則集訂閱管理規則

規則順序比數量更重要

mihomo 的一般規則清單通常會由上而下比對，命中後交由指定策略處理。精確的例外規則應放在範圍較廣的規則之前，MATCH 則放在最後作為兜底。若要為特定網域設定代理，但上方已有範圍更廣的直連規則，該例外就不會生效。排查時應從連線詳細資料中的實際命中規則著手，先確認請求帶有的網域或目標 IP，再檢查規則順序，不要只在檔案中搜尋網站名稱。

DOMAIN 比對完整網域；DOMAIN-SUFFIX 比對指定後綴及其子網域；DOMAIN-KEYWORD 只檢查字串是否包含關鍵字，容易擴大比對範圍。針對已知服務，優先使用完整網域或明確的後綴。一個網頁可能同時存取登入、靜態資源與 API 網域，只處理首頁網域未必涵蓋整個流程。應參考連線記錄補齊實際依存項目，而不是直接把所有連線切換為全域模式。

將規則內容與規則入口分開

rule-providers 用來宣告規則內容來源，RULE-SET 則決定引用位置並指定處理策略。如此一來，規則檔可以獨立更新，主設定只需保留清楚的執行順序。以下範例使用本機檔案，適合先驗證結構。請將規則檔存放在用戶端設定工作目錄下的 rules/local-direct.yaml；若用戶端將執行目錄放在沙盒中，請透過其支援的檔案管理入口確認實際位置。

rule-providers:
  local-direct:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - DOMAIN,example.com,DIRECT
  - RULE-SET,local-direct,DIRECT
  - MATCH,PROXY

上述主設定片段中的 PROXY 必須已經定義。以下是對應的本機規則檔內容，example.org 用來示範後綴語法，實際維護時請填入需要直連的網域。網域型規則集不是一般規則清單，不應在每條內容中寫入策略名稱。先確認這個小型規則集能正確命中，再移轉大量規則，便能分別處理路徑、格式與內容錯誤。

payload:
  - '+.example.org'
  - 'example.net'

選擇正確的 behavior 與更新方式

behavior: domain 用於網域集合，ipcidr 用於 IP 位址區段集合，classical 則可表示包含規則類型的傳統規則內容。規則提供器的 format 也必須與檔案格式相符，不能只憑副檔名判斷內容。將 DOMAIN-SUFFIX,example.org 直接放入網域型集合，或把包含策略名稱的完整規則列放進傳統規則集合，都可能造成解析失敗或比對結果不如預期。

遠端維護時，將提供器設為 type: http，再填入可信規則來源實際提供的 url、個別的 path 與合適的 interval。不要讓多個提供器共用同一個快取檔案，以免一次更新覆蓋其他規則集。規則來源變更後應先抽查內容，確認沒有從網域清單變成網頁或錯誤訊息，再於用戶端更新提供器；只重新載入設定，不一定會重新下載所有遠端檔案。

依命中路徑排查規則集問題

規則未生效時，先確認執行模式為規則模式，再檢查提供器是否已載入、名稱是否與 RULE-SET 引用一致，以及規則是否已被上方項目提前命中。對於 IP 規則，no-resolve 可避免為了該 IP 規則主動解析網域，但不會將網域規則變成 IP 規則，也不代表系統完全停止 DNS 查詢。已取得目標 IP 的連線仍可進行 IP 比對，請依連線詳細資料判讀結果。

GEOIP 需要相應的地理資料庫，規則集檔案正常不代表資料庫也正常。遇到 GeoIP 相關錯誤時，先查看記錄中的檔案路徑與下載失敗原因，並使用用戶端提供的資料庫更新入口；不要反覆刪除整個設定目錄。若規則越加越多，反而更難排查，先整理為本機例外、用途分組、通用規則與最終兜底四個層級，再逐層驗證。基礎概念可參閱術語表，特定故障請查看說明中心。

DNS 設定最佳化與解析路徑

先釐清查詢的來源與目的地

排查 DNS 問題時，首先要區分應用程式、作業系統、mihomo 與上游解析器。瀏覽器可能啟用了自己的安全 DNS，系統也可能保留手動設定的伺服器，TUN 則可能接管部分 DNS 請求。修改 nameserver 後網頁沒有變化，不一定是欄位無效，也可能是請求根本沒有經過 mihomo。先在用戶端記錄中觀察目標網域的查詢，再決定是否調整系統 DNS、瀏覽器設定或流量接管方式。

使用網域形式的加密 DNS 上游時，還需要先解析其伺服器位址，這個步驟稱為引導解析。default-nameserver 用於相關引導流程，不能簡單理解為所有一般查詢的優先解析器。若節點伺服器使用網域名稱，也應留意 proxy-server-nameserver，避免出現「必須先連上代理才能解析節點，又必須先解析節點才能連上代理」的循環。代理能否啟動與業務網域能否正確解析，應分開驗證。

先從少數明確的解析器開始

以下為 DNS 設定範例，說明引導解析、一般解析與節點網域解析的分工。這並非適用於所有網路的通用解答：公共解析器是否可連線、是否支援目前的網路環境，都需要實際測試。範例未設定本機監聽位址；若需要讓系統或其他裝置主動存取 mihomo DNS，應另外設定 listen，並檢查連接埠占用、權限與防火牆。不要只新增監聽欄位，就對區域網路開放服務。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'

dns.ipv6: false 會影響此 DNS 模組如何處理 AAAA 查詢，不代表作業系統已停用 IPv6，更不保證所有 IPv6 流量都會被接管。若系統仍有 IPv6 路由，應用程式也可能透過快取或其他解析途徑使用 IPv6。請一併檢查執行設定頂層的 IPv6 選項、TUN 路由與連線記錄，避免用單一 DNS 開關解釋整個網路堆疊的行為。

依網域設定策略，避免層層堆疊備援

nameserver-policy 可將特定網域交由指定解析器處理，適用於企業內部網域或有明確解析需求的服務。企業內網解析器通常只有連上辦公網路後才能存取；若將它設為所有網域的上游，離開辦公網路後可能全部逾時。較穩妥的做法是限定內部網域範圍，並確認查詢仍經過正確的網路介面。相關網域是否也需要直連規則，應依目標位址的可連線性另行判斷。

增加解析器數量不一定更可靠。fallback 與篩選條件會共同影響結果選擇，不能只看清單順序就推斷「第一個失敗才會詢問第二個」。若使用 respect-rules 讓 DNS 連線遵循路由規則，也必須考量節點網域解析與規則之間的依存關係，並保留獨立可用的節點解析路徑。沒有明確需求時，先使用少數可連線的上游；穩定後再增加網域策略，降低難以釐清的交叉依存。

區分 DNS 錯誤與連線錯誤

排查時依序確認「是否收到查詢、是否傳回結果、目標是否可連線」三個步驟。查詢逾時時，優先檢查解析器的連線狀況；已取得位址但 TCP 連線逾時，則繼續檢查策略、出口與路由；只有特定瀏覽器失敗時，檢查該瀏覽器獨立的 DNS、代理設定與快取。Fake-IP 模式下看到保留位址是預期行為，不應直接判定為 DNS 污染，也不要因此手動將業務網域固定到該位址。

修改後先關閉目標應用程式的舊連線，再依用戶端支援的方式清除 DNS 與 Fake-IP 快取；必要時清除系統快取，但不必每次都重設整個系統網路。憑證錯誤也不能只靠更換 DNS 解決：應先核對系統時間、憑證簽發者與存取網域，並保持瀏覽器的憑證驗證功能啟用。若問題只出現在某個出口，使用相同網域分別測試直連與該出口，記錄差異後再決定調整方向。

TUN 模式與 Fake-IP 協同運作

流量接管與回傳位址是兩回事

TUN 透過虛擬網路介面與路由設定接收流量，適合不遵循系統代理設定的應用程式；Fake-IP 則是 DNS 回覆與網域映射機制，透過保留位址協助核心將後續連線對應至網域。兩者經常搭配使用，但並不相同。系統代理可用、特定應用卻無法連線，可能是應用繞過代理；開啟 TUN 後仍失敗，也可能是權限、路由衝突或應用本身的網路方式所致，不一定需要更換 DNS 模式。

啟用前先確認目前的 Clash 用戶端是否支援 TUN，以及是否需要服務模式或系統管理員權限。Windows 通常需要相關服務或提高權限；macOS 涉及系統授權與用戶端實作；Linux 則需要建立虛擬介面及管理路由的權限。Android 通常透過系統 VPN 介面接管流量，不能直接套用桌面版的服務模式步驟。安裝與授權方式請以用戶端實際介面為準；若缺少相關功能，請回到下載中心確認用戶端選擇。

先用基本設定建立可還原的路徑

以下為桌面環境的 TUN 設定片段，DNS 部分應與上一章的設定一併檢查。auto-route 用於自動設定相關路由；auto-detect-interface 用於識別出口介面；dns-hijack 則接管符合條件的 DNS 流量。any:53 不代表所有加密 DNS 都能被識別；應用程式透過 HTTPS 連接埠送出的獨立 DoH 請求，並不等同一般的 53 埠查詢。

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

stack 可用選項取決於執行環境與核心能力，常見值包括 system、gvisor 和 mixed。不要同時更換網路堆疊、調整 MTU、啟用嚴格路由，再依據單次存取結果判斷哪項修改有效。先採用用戶端建議值，確認網頁、下載與區域網路存取都正常；只有遇到可重現的問題時，才單獨比較網路堆疊，並保持節點、規則與測試應用程式相同。

處理 Fake-IP 相容性與區域網路存取

某些裝置探索、區域網路服務或直接依賴真實位址的應用程式，可能不適用 Fake-IP 回傳的位址。此時可將明確的網域加入 fake-ip-filter，讓它們使用真實解析路徑，而非切換整體 DNS 模式。篩選規則只會影響相關 DNS 行為，不會自動建立直連路由；若內網服務需要直連，還要檢查規則、系統路由與使用的網路介面。網域解析為私有位址，也不代表該位址在目前網路中可連線。

不要將所有網域都加入篩選清單，否則會失去 Fake-IP 的主要用途，也讓實際行為更難判讀。切換 Fake-IP 模式、位址範圍或篩選規則後，舊快取可能使應用程式繼續連線至先前的保留位址。請關閉相關應用程式的連線，清除對應快取後再測試。若企業 VPN、容器網路或實驗環境已使用與 Fake-IP 範圍重疊的位址區段，就需要重新規劃範圍並同步清除快取，不能只修改單一路由來掩蓋衝突。

依序從權限、路由、DNS 到連線逐層排查

TUN 啟用失敗時，先查看記錄是否出現權限不足、裝置建立失敗或路由新增失敗，再處理對應的系統層問題。啟用成功但無法存取時，先排除其他 VPN 或網路加速工具同時接管預設路由；確認目前網路出口沒有被錯誤識別後，再檢查 DNS 查詢是否能進入核心。不要一次停用所有安全軟體與系統防火牆，優先檢查明確的處理程序、介面與規則，並保留最低限度的必要授權。

若網頁正常，但遊戲、語音或其他 UDP 應用程式失敗，請確認節點與上游連線支援相關 UDP 轉送，再檢查規則是否將流量送至正確出口。TUN 接收到 UDP，不代表遠端一定能處理。若只有大型回應或特定傳輸失敗，再檢查 MTU 與路徑問題，並使用相同情境進行前後比較。最終應依連線記錄與應用程式結果共同判斷：介面顯示 TUN 已啟用，只代表接管功能已開啟，不代表所有應用程式都已依預期分流。

網域嗅探與規則命中調整

哪些連線需要補上網域資訊

網域規則需要連線帶有可用的網域資訊。應用程式若直接連線至 IP、使用自己的解析方式，或 DNS 查詢沒有經過 mihomo，連線清單中可能只會顯示目標位址。網域嗅探會嘗試從部分協定的交握資訊中擷取網域，供後續處理使用。這能補足部分連線資訊，但不是解決所有 DNS 問題的總開關，也無法保證還原任何應用程式的連線網域。

HTTP 的主機資訊、TLS 交握中的伺服器名稱，以及部分 QUIC 交握資訊，都可能用來識別網域。TLS 嗅探不等於解密 HTTPS 內容，不需要因此安裝封包擷取根憑證，也無法據此讀取加密資料。若使用加密用戶端問候等機制，可見的網域資訊可能受到限制。遇到這類連線時，應接受識別能力的限制，改用已知位址範圍、應用程式規則或可靠的 DNS 路徑，而不是繼續擴大嗅探範圍。

從明確連接埠與有限範圍開始

以下示範常見協定的嗅探設定。HTTP 與 TLS 的連接埠範圍用於限制嘗試識別的流量，避免不分情況地處理所有連接埠。範例將 override-destination 設為關閉，先觀察網域識別是否改善，不立即改變目標位址的處理方式。不同用戶端可能透過圖形介面的開關產生相同欄位；啟用前請確認訂閱中是否已有 sniffer，避免本機修改被其他設定層覆蓋。

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443

parse-pure-ip 允許嘗試處理純 IP 連線，但不代表這些連線一定包含網域。force-dns-mapping 與 DNS 映射情境的處理有關，不能取代正確的 DNS 設定。override-destination 涉及是否採用嗅探出的網域覆寫目標處理方式，必須配合實際用途驗證；若也有依協定設定的覆寫選項，應一併檢查最後生效的值，不能只看頂層開關就推斷所有連線行為。

分開驗證網域識別與出口變更

先選擇一個原本只顯示 IP、且能穩定重現的請求。開啟嗅探後重新建立連線，觀察連線詳細資料是否出現網域，以及命中的規則是否改變。若已識別網域但仍走直連，請檢查規則順序與策略群組選擇；若仍未顯示網域，則檢查目標協定、連接埠與交握是否在可識別範圍內。不要因為單一連線沒有變化，就認定整份設定未載入；同一頁面的不同資源可能使用不同協定。

嗅探取得的網域也不應被視為絕對正確。有些應用程式會在同一連線中共用不同用途，有些連線使用 IP 存取，卻附帶另一個名稱。啟用目標覆寫後，若只有特定服務失敗，可先關閉覆寫進行比較，保留嗅探功能；若確認確有相容性問題，再對明確網域使用 skip-domain 等排除設定。例外應清楚且容易理解，不要加入大量未經驗證的服務名稱。

相容性、隱私與效能限制

嗅探會對連線初始資料增加識別處理，實際效益取決於目前的 DNS 路徑與業務類型。若大多數連線已透過 Fake-IP 正確對應網域，繼續擴大識別範圍未必有必要。對於伺服器長連線或自訂協定，應優先維持原本的目標語意；不要為了讓記錄中的網域更完整，犧牲原本正常的連線。排查結束後應關閉暫時啟用的除錯記錄，避免長期保存不必要的網域與存取路徑資訊。

遇到憑證警告時，先確認憑證是否屬於目前存取的網站，再比較啟用與關閉目標覆寫的結果。嗅探不是忽略憑證警告的理由，更不能透過允許不安全連線來「驗證修復」。若目標網域識別正確、規則也正確，但只有特定節點失敗，應改查出口與遠端服務。對於完全無法識別的協定，回頭檢查應用程式本身的代理支援、DNS 解析與 IP 規則設計，通常比繼續堆疊嗅探欄位更有效。

本機覆寫與多訂閱合併

先確認修改在哪個步驟才會保留

訂閱原文、本機設定副本、覆寫規則與最終執行設定是不同的項目。直接編輯訂閱下載的檔案，下次更新時可能被取代；編輯最終執行設定，下次重新載入時也可能重新產生。需要長期保留的規則，應放在用戶端支援的本機覆寫、擴充設定或指令碼入口中。各 Clash 用戶端的選單名稱與處理順序不同，不能把某個用戶端的指令碼介面當作 mihomo 通用欄位。

先在介面中確認目前的設定來源，以及是否存在全域覆寫與單一訂閱覆寫。用一條容易辨識的規則進行最小測試：儲存、重新載入、查看執行設定、更新訂閱，再次查看執行設定。只有這些階段都符合預期後，才適合移轉大量自訂設定。若更新後規則消失，應先找出寫入層級，不要靠更頻繁地手動貼上補救；這只會讓設定來源更難追蹤。

區分完整訂閱與節點提供器

完整的 Clash YAML 通常包含節點、策略群組、規則與其他設定；節點訂閱未必包含這些結構，Base64 編碼的節點清單也不能直接當作完整 YAML 使用。合併多個訂閱前，請先確認輸入內容屬於哪種格式。若要了解結構差異，可參閱訂閱格式與轉換說明。訂閱網址中的存取憑證只應保存在本機，不要貼到公開記錄、截圖或線上轉換頁面。

若現有內容符合 mihomo 節點提供器格式，可用 proxy-providers 將節點來源與主設定分開。以下使用本機節點檔案示範結構，檔案必須包含實際的 proxies 清單。這不是任意完整訂閱都能直接使用的入口；若輸入檔只有網頁提示或編碼文字，應先透過可信的本機流程轉換成正確格式，再交由提供器讀取。

proxy-providers:
  office:
    type: file
    path: ./providers/office.yaml
  travel:
    type: file
    path: ./providers/travel.yaml

proxy-groups:
  - name: PROXY
    type: select
    use:
      - office
      - travel

使用遠端節點提供器時，應為每個來源設定獨立名稱與快取路徑，再填入來源實際提供的網址與更新間隔。不要讓節點檔案與規則集檔案共用路徑。若用戶端透過自己的匯入機制管理訂閱，也可繼續由介面負責更新，只透過本機覆寫引用產生後的節點；但必須確認更新後引用仍有效，不要依賴暫存檔名或不穩定的內部目錄。

陣列、同名物件與優先順序

合併時最容易出錯的是陣列的處理方式。將新的 rules 陣列加入覆寫，有些用戶端會取代原陣列，有些提供「前置」或「後置」操作，另一些則要求指令碼明確串接。映射欄位也不一定會遞迴合併。不要只因介面顯示「合併」，就假設所有內容都會保留；務必查看產生後的完整設定。尤其要確認原有 MATCH 是否仍在末尾，以及本機例外是否確實位於通用規則之前。

多個訂閱經常包含相同的節點名稱與策略群組名稱，直接串接可能造成引用不明、名稱衝突或匯入失敗。可在受控的合併流程中為節點加上來源前綴，並同步更新群組引用；若使用提供器的篩選運算式，也要確認更名不會影響篩選結果。不要只改顯示名稱，卻保留舊的規則目標。合併完成後，應能從任一規則追蹤到存在的策略群組，再追蹤到有效節點或內建策略。

驗證、還原與移轉

可使用 mihomo 的設定測試模式檢查語法與引用。在已有該執行檔的命令列環境中執行以下命令，config.yaml 指向待測試的檔案。相對路徑資源取決於執行目錄，圖形用戶端的實際工作目錄可能不同；命令列檢查通過後，仍須在用戶端重新載入，並確認提供器載入結果。語法正確只表示設定可解析，不保證訂閱來源可連線或所有節點都能使用。

mihomo -t -f config.yaml

還原時，優先停用本次新增的覆寫，恢復上一份可用設定，再重新載入驗證。保留「修改目的、涉及欄位、驗證網域、還原位置」的簡短記錄，比保存多份難以辨識的設定副本更實用。移轉用戶端時，先移轉訂閱，再移轉規則與 DNS，最後處理介面層指令碼；不同用戶端的啟動設定、TUN 授權與覆寫介面通常都要重新設定，不能只複製一份 YAML 就認定移轉完成。

外部控制面板與區域網路分享

分別設定代理入口與管理入口

代理連接埠承接應用程式流量，控制介面則負責讀取狀態、切換策略與管理連線。將代理分享給同一網路中的裝置，並不需要同時開放控制介面。mixed-port 是 HTTP 與 SOCKS 共用的代理監聽連接埠；external-controller 則是管理 API 位址。兩者用途、權限與風險都不同；排查「手機連不上電腦代理」時，不應透過開放管理連接埠來解決。

單機使用時，先讓控制介面只監聽回送位址。以下是本機管理設定片段，範例口令是明確的教學用假值，實際啟用前必須在本機產生獨立的長隨機口令，切勿沿用範例。secret 用於控制介面驗證，與節點密碼、訂閱憑證是不同欄位。若用戶端已負責管理控制介面參數，請在其設定入口修改，避免手動設定值在啟動時被重新產生。

mixed-port: 7890
allow-lan: false
external-controller: 127.0.0.1:9090
secret: "your-password"

連接面板前先驗證監聽與驗證設定

面板通常需要填入控制介面位址與口令。只有控制介面已啟動、位址可連線且驗證通過，介面才能讀取策略群組與連線。面板無法開啟，與面板能開啟卻無法連上核心，是兩種不同問題：前者檢查面板資源，後者檢查 API 位址、連接埠、驗證資訊與瀏覽器網路限制。若記錄中出現 address already in use，先找出占用該連接埠的處理程序，不要碰運氣將所有監聽位址改為所有網卡。

若要在本機託管面板，可將已取得且可信的靜態面板檔案放進設定工作目錄中的獨立資料夾，再透過 external-ui 指定路徑。不要將整個使用者目錄設為靜態資源目錄，以免暴露無關檔案。透過瀏覽器存取時也要留意頁面通訊協定：HTTPS 頁面向一般 HTTP 介面發出請求，可能受到混合內容限制；跨來源請求也可能需要設定允許的來源。這些情況都不代表訂閱失效。

面板具備操作核心的權限，不只是唯讀儀表板。不要將控制口令放在公開連結的查詢參數、公開截圖或共用書籤中，也不要為了省去驗證而清空口令。若確實需要遠端管理，優先讓管理請求經過受控的專用網路或安全通道，並限制存取來源；反向代理、存取驗證與 TLS 都必須各自正確設定，不能用複雜口令取代網路邊界防護。

區域網路分享僅開放必要的代理入口

分享前先確認兩台裝置位於可互相連線的網路，電腦目前的區域網路位址穩定，且路由器未啟用用戶端隔離。接著在 Clash 用戶端開啟「允許區域網路連線」，檢查實際監聽位址與系統防火牆，僅允許必要的可信任網段存取代理連接埠。手機應填入電腦的區域網路位址，而不是 127.0.0.1；後者在手機上指向手機本身，不會自動指向電腦。

以下為代理分享設定片段，控制介面仍維持回送位址監聽。bind-address 只有在相關的允許區域網路設定下才會依其定義生效，請配合實際監聽結果檢查。範例驗證值仍是教學用假值，實際使用時須換成本機專用憑證。部分裝置的系統代理介面不支援驗證，遇到這種情況應評估裝置功能與網路控管範圍，而不是直接將代理連接埠暴露給不可信任的網路。

mixed-port: 7890
allow-lan: true
bind-address: '*'
authentication:
  - "lan-user:your-password"
external-controller: 127.0.0.1:9090
secret: "your-password"

手機 Wi-Fi 中的 HTTP 代理設定，通常只會影響遵循該設定的應用程式，不代表所有應用程式與 UDP 流量都已接管。電腦本身啟用 TUN，也不代表電腦會自動成為手機的透明閘道。若要接管整台裝置的網路流量，需要明確規劃閘道、路由與 DNS；不要混淆「允許區域網路連線」與「分享 TUN」這兩個概念。一般家庭環境先使用應用程式支援的明確代理，更容易控管範圍與排查問題。

以最小化測試完成交接

驗證分享功能時，先在電腦本機確認代理可正常存取，再於第二台裝置確認能連上電腦位址，最後設定代理並查看電腦的連線清單。完全沒有新連線時，檢查位址、連接埠、驗證資訊與防火牆；出現連線但無法存取時，再檢查命中規則、最終節點與 DNS。若只有部分應用程式有效，先確認應用程式是否遵循系統代理，不要繼續修改控制介面。公共 Wi-Fi 與訪客網路可能會隔離裝置，即使網路名稱相同也不保證可以互相連線。

完成設定後，關閉暫時開放的連接埠與除錯記錄，確認控制介面仍只對預期範圍開放，且訂閱更新沒有覆蓋本機安全設定。為長期使用保留簡短交接記錄：代理連接埠、監聽範圍、憑證存放位置、覆寫入口與還原方式；記錄中不要直接抄寫口令。需要重新進行基本設定時，請回到使用指南；遇到匯入失敗、系統代理殘留等常見問題，先查看說明中心，不必重新疊加整份進階設定。