FlClash 設定欄位完整參考

YAML 結構總覽：先看階層，再看欄位

根物件、映射與序列

mihomo 設定檔的根層是 YAML 映射。映射由「鍵、冒號、值」組成，例如 mode: rule；序列以短橫線開頭，常見於 proxies、proxy-groups 與 rules。階層完全依靠縮排表達，同一層級的欄位必須維持相同縮排深度。通常使用兩個空格，不使用定位字元。YAML 不要求統一使用兩個或四個空格，但同一層級忽深忽淺會改變資料結構，解析器可能直接報錯，也可能把欄位歸入錯誤的父物件。後者更難察覺：檔案可以載入，某個選項卻始終沒有生效。

純量值包括字串、數字、布林值與空值。連接埠寫成 7890 時是數字；true 與 false 是布林值；節點名稱、網域與模式通常是字串。包含冒號、井字號、方括號、大括號或前後空白的字串，建議使用引號。井字號在未加引號的字串中代表註解起點，因此密碼或名稱含有井字號時必須加引號。YAML 區分大小寫，Rule、RULE 與 rule 不是同一個值。欄位名稱也必須使用文件規定的拼法，介面顯示的中文名稱不能直接取代設定鍵。

# config.yaml 的典型根結構
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.example/dns-query

proxies:
  - name: "範例節點"
    type: socks5
    server: proxy.example.com
    port: 1080
    username: "your-user"
    password: "your-password"

proxy-groups:
  - name: "節點選擇"
    type: select
    proxies:
      - "範例節點"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,節點選擇
  - MATCH,DIRECT

欄位讀取順序不等於流量處理順序

YAML 映射在語意上不依賴書寫順序，所以把 dns 放在 proxies 前後通常不會改變結果。不過，人類閱讀需要穩定的結構。建議依序放置通用設定、DNS、入站監聽、代理節點、代理提供者、策略組、規則提供者與規則。真正具有順序意義的是序列：rules 由上到下比對，第一條命中後即停止；策略組中的節點順序會影響預設選項或自動選擇時的候選順序；名稱相同的物件在覆寫階段還可能互相替換。

引用關係必須完整閉合。規則結尾的策略名稱，必須存在於 proxy-groups 中，或使用 DIRECT、REJECT 等內建策略。策略組引用的節點名稱，必須對應 proxies 中的節點、其他已定義的策略組，或透過 use 匯入的代理提供者。修改名稱時不能只改定義處，還要同步檢查策略組與規則。中文、空格與標點都屬於名稱的一部分，「節點選擇」和「節點選擇 」會被視為兩個不同字串。

錨點、別名與進階 YAML 寫法

YAML 支援錨點與別名，可重複使用一組參數。例如讓多個節點共用 udp、skip-cert-verify 等欄位。不過，訂閱轉換器、覆寫引擎與圖形化編輯器對複雜 YAML 特性的保留能力並不完全一致。經由介面儲存後，錨點可能會展開成一般欄位；某些合併鍵也可能被重新序列化。需要跨裝置長期維護時，優先選擇清楚的顯式欄位。錨點適合手動維護的獨立檔案，不適合依賴頻繁遠端更新的訂閱正文。

註解同樣可能在圖形化儲存或訂閱更新後遺失。重要的維護說明不要只寫在訂閱快取中，可以把規則意圖與來源記錄在獨立文件，或將自訂內容放入穩定的覆寫檔案。FlClash 負責載入與管理設定，mihomo 核心負責解讀實際欄位；出現「介面看得到但核心未採用」的情況時，應先查看執行記錄中的解析提示，再確認最終生效設定，而不是只檢查原始訂閱文字。

通用欄位：連接埠、區域網路、模式與記錄

監聽連接埠如何分工

port 是 HTTP 代理監聽連接埠，socks-port 是 SOCKS5 代理監聽連接埠，mixed-port 則在同一個連接埠接受 HTTP 與 SOCKS5。桌面環境通常只需啟用 mixed-port，方便系統代理與不同應用程式共用同一入口。多個監聽欄位可以並存，但連接埠號碼不能互相衝突，也不能被其他程式佔用。若由 FlClash 介面負責分配連接埠，手動設定中的值也可能被用戶端覆寫；排查時應查看最終監聽位址與執行記錄，而不是只依據編輯器中的原始數字。

redir-port、tproxy-port 等欄位服務於透明代理流程，通常由 Linux 防火牆規則、路由器環境或特定接管方式使用。一般桌面使用者不應為了「更完整」而同時開啟所有連接埠。連接埠只是接收流量的入口，不會自動修改系統路由。系統代理模式需要作業系統將支援代理的應用程式導向 HTTP 或 SOCKS 連接埠；TUN 模式則建立虛擬網路介面，接管更廣泛的流量，兩者的權限、涵蓋範圍與排錯方式都不同。

mixed-port: 7890
allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: false
unified-delay: true
tcp-concurrent: true
find-process-mode: strict

allow-lan 與監聽邊界

allow-lan 控制區域網路裝置能否連線到本機代理連接埠。設為 false 時，通常用於僅供本機應用程式使用的桌面設定。設為 true 後，還需要正確設定監聽位址，並確認作業系統防火牆允許相應連接埠。此欄位不會自動替其他裝置填寫閘道或代理位址，也不能取代存取控制。若確實需要向區域網路提供代理，應使用固定的內網位址、限制可信任網段，並設定身分驗證；不要將監聽連接埠直接暴露在公網。

bind-address 決定監聽的綁定範圍。通用位址表示在可用介面上監聽，指定位址則將入口限制在特定網卡。行動裝置切換 Wi‑Fi 與行動網路時，介面變更可能導致原本綁定的位址失效。區域網路分享出現「本機可用、其他裝置拒絕連線」時，應依序檢查 allow-lan、綁定位址、防火牆、裝置是否位於同一網段，以及代理類型是否填寫正確。連線成功但無法存取目標網站，則繼續檢查策略組、DNS 與出站節點。

三種執行模式

mode: rule 依規則清單決定流量去向，是日常設定的主要模式。global 將流量交給全域策略，適合暫時驗證節點是否可用；direct 讓流量直接連線，適合快速判斷問題是否由代理鏈路造成。切換模式不會刪除規則，只會改變決策入口。排錯時可以短暫切換：全域模式正常而規則模式異常，通常表示規則命中或策略引用有誤；直連模式也異常，則應檢查本地網路、DNS 或系統接管狀態。

log-level 常見值包括 silent、error、warning、info 與 debug。日常使用維持 info 通常已足夠；排查規則命中、DNS 查詢或握手問題時，可暫時提高至 debug。詳細記錄會大幅增加輸出量，也可能包含目標網域、節點位址等執行資訊，問題處理完成後應恢復一般層級。記錄中的第一個錯誤通常比後續連鎖錯誤更有價值，應依設定載入、監聽啟動、DNS 初始化與代理握手的先後順序閱讀。

延遲測量、並行連線與程序識別

unified-delay 用於統一延遲測試標準，讓不同代理類型的測試結果更容易比較。測速結果代表測試 URL 與目前網路條件下的一次連線表現，不等同於所有網站的固定延遲。tcp-concurrent 允許同時嘗試目標位址的多個候選連線，在雙堆疊或多位址情境下可能縮短建立連線的等待時間，但也會產生額外的連線嘗試。網路受限、路由器資源緊張或需要嚴格控制連線數量時，可以關閉後進行對照測試。

find-process-mode 會影響核心取得連線所屬程序的方式。程序規則依賴作業系統能力與執行權限，在不同平台上的可用程度並不一致。Android、macOS、Windows 與 Linux 對程序路徑、套件名稱與權限的表示方式不同，因此不應假定同一條程序規則在各平台完全等價。若透過網域或 IP 即可完成分流，通常優先採用網路層條件；確實需要依應用程式區分時，再搭配目標平台驗證程序名稱。

DNS 欄位：解析路徑、Fake-IP 與分流一致性

DNS 設定處理的不只是「解析速度」

代理環境中的 DNS 同時負責網域解析、規則判斷、節點伺服器位址解析，以及避免請求繞過預期鏈路等工作。啟用 dns.enable 開啟核心 DNS 模組後，查詢可以依設定送往指定上游；但系統是否將所有查詢交給核心，還取決於 TUN、系統 DNS 設定或應用程式自身行為。瀏覽器可能啟用獨立的加密 DNS，某些應用程式可能快取位址或直接請求固定 IP。出現解析結果與規則不一致時，應先釐清查詢路徑：應用程式向誰查詢、核心使用哪個上游、節點伺服器網域由誰解析，以及最終連線命中了哪條規則。

nameserver 是主要解析伺服器清單，通常用於一般網域查詢。default-nameserver 常用於解析加密 DNS 伺服器本身的網域，避免「要連線到 DNS 伺服器，卻得先解析 DNS 伺服器網域」的循環依賴，因此通常在此放置可直接存取的 IP 位址伺服器。proxy-server-nameserver 可專門解析代理節點伺服器網域，讓節點位址解析與一般業務網域分離。direct-nameserver 則可為明確直連的網域提供獨立解析路徑。是否需要全部設定，應依實際網路拓撲決定，不是欄位越多就越穩定。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - https://dns.google/dns-query
    - tls://1.1.1.1
  proxy-server-nameserver:
    - https://dns.google/dns-query
  respect-rules: true

Fake-IP 與 Redir-Host 的差異

enhanced-mode: fake-ip 會先向應用程式回傳保留位址池中的映射位址，核心隨後依映射還原原始網域並進行規則判斷。如此即使應用程式只將目標 IP 交給網路層，核心仍能保留網域資訊，網域規則與嗅探搭配時通常更直接。fake-ip-range 指定映射位址池，不應與本地實際網段、容器網段或企業 VPN 網段重疊。發生內網位址衝突時，可能只會表現為特定網段無法存取，而非所有連線都失敗。

redir-host 更接近傳統的實際位址解析：應用程式取得目標網域的實際 IP，核心再依可用資訊處理流量。對某些不接受 Fake-IP 的裝置探索、區域網路服務或特殊協定而言，這種方式更直觀，但網域資訊可能在後續連線階段遺失，規則判斷更依賴 DNS 快取與嗅探。選擇模式時應著重應用程式相容性與規則準確性，不必將任何一種模式說成普遍適用。多數問題可先使用 Fake-IP，再將明確不相容的網域加入過濾清單，而不是直接放棄網域映射能力。

fake-ip-filter 應保持可解釋

過濾清單中的網域會繞過 Fake-IP 映射，取得實際解析結果。區域網路探索、時間同步、STUN、部分遊戲平台與裝置配網情境可能需要過濾。新增前應具備明確症狀與驗證方法：例如應用程式只在 Fake-IP 下無法探索同網段裝置，加入對應網域後恢復。不要隨意將大範圍頂級網域或萬用規則塞入過濾清單，否則大量請求會退回實際位址解析，網域規則的可觀察性降低，也可能造成不同裝置上的行為分歧。

萬用寫法需要區分精確網域、單層萬用字元與後綴比對。不同欄位支援的萬用語意範圍可能不同，不能將規則清單中的 DOMAIN-SUFFIX 語法直接複製到過濾清單。修改後應清除應用程式 DNS 快取、重新建立連線，並在記錄中確認查詢是否進入預期上游。只重新整理網頁可能仍使用瀏覽器連線池與舊快取，造成「設定沒有變更」的誤判。

規則分流與 DNS 上游選擇

respect-rules 讓 DNS 請求在適用情況下遵循規則體系，但這也要求用於 DNS 的代理策略能在解析完成前建立，以避免遞迴依賴。例如代理節點寫的是網域，而連線加密 DNS 又必須經過該代理，此時節點網域需要先由 proxy-server-nameserver 或可直接存取的引導解析器解析。設計時應將「節點位址解析」與「業務網域解析」分開，確保最底層始終存在一條不依賴尚未建立代理的解析路徑。

nameserver-policy 可以依網域選擇特定上游，適合企業內網網域、區域網路服務或需要固定解析來源的區域。策略應盡量精準：先比對明確後綴，再保留通用 nameserver 作為備援。若同一網域可能同時命中多條策略，應檢查比對優先順序與最終記錄。對於透過規則提供者維護的網域集合，還需確認規則集行為與 DNS 策略欄位是否支援對應的引用方式。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.google/dns-query
  nameserver-policy:
    "+.internal.example":
      - 192.0.2.53
    "geosite:private":
      - system
  direct-nameserver:
    - system
  direct-nameserver-follow-policy: true

常見故障可按層拆解。網域完全無法解析時，檢查 DNS 監聽、上游可達性與憑證時間；能解析但無法連線時，檢查規則策略與節點；只有節點網域失敗時，檢查引導解析與 proxy-server-nameserver；區域網路裝置異常時，檢查 Fake-IP 位址池衝突與過濾項目；偶爾混用新舊結果時，清除系統、瀏覽器與核心快取。更完整的故障路徑可繼續查閱常見問題中的 DNS 與連線分類。

代理節點欄位：通用屬性、協定參數與傳輸層

所有節點都從名稱、類型與伺服器開始

proxies 是手動節點序列。每個節點至少需要唯一的 name、協定 type、伺服器 server 與連接埠 port，再補上協定所需的驗證欄位。節點名稱是策略組與規則引用的主鍵，應保持穩定。訂閱更新時若上游變更名稱，手動策略組可能出現失效引用，因此自動訂閱更適合透過代理提供者與篩選規則組織，而不是將大量動態節點名稱寫死在策略組中。

server 可以是 IP 或網域。使用網域方便伺服器遷移，但要求節點位址解析鏈路穩定；使用 IP 可少一次解析，卻無法自動跟隨位址變更。udp 控制節點是否承載 UDP，實際可用性還取決於協定、伺服器與網路路徑。interface-name 或路由標記類欄位可將連線綁定至特定出口，適用於多網卡環境，但行動裝置切換網路後可能失效。除非確實需要多個出口，不應將平台相關欄位固定在跨裝置設定中。

proxies:
  - name: "辦公室 SOCKS"
    type: socks5
    server: proxy.example.com
    port: 1080
    username: "your-user"
    password: "your-password"
    udp: true

  - name: "範例 HTTP"
    type: http
    server: gateway.example.net
    port: 8443
    username: "your-user"
    password: "your-password"
    tls: true
    skip-cert-verify: false

TLS 欄位與伺服器身分

支援 TLS 的協定通常包含 tls、servername、skip-cert-verify、ALPN 或指紋相關選項。servername 用於 TLS 握手中的伺服器名稱，應與伺服器憑證及部署設定一致，不等同於任意填寫的偽裝網域。skip-cert-verify: true 會跳過憑證有效性驗證，只適合明確受控的測試環境；正常設定應保留驗證，並修正系統時間、憑證鏈、伺服器名稱或中間網路干擾。連線記錄出現憑證名稱不相符時，應先核對訂閱參數，不要用關閉驗證來掩蓋設定錯誤。

WebSocket、gRPC、HTTP/2 等傳輸參數通常巢狀在各協定對應的選項中。路徑、Host、服務名稱與要求標頭必須和伺服器一致。欄位看似相近，階層卻可能不同，例如 WebSocket 的路徑不會因為寫在節點根層就自動生效。遷移其他用戶端設定時，不能只依中文標籤逐項複製，應對照 mihomo 支援的節點結構。訂閱由服務提供方產生時，優先保留原始傳輸參數，只在確認伺服器要求後修改。

常見協定欄位不能互相套用

Shadowsocks 節點的核心欄位是 cipher 與 password；Trojan 主要使用密碼、TLS 伺服器名稱與傳輸參數；VMess 通常需要 uuid、加密選項與傳輸設定；VLESS 需要 UUID，並可能包含 flow、Reality 或其他擴充欄位；Hysteria2 與 TUIC 還涉及以 UDP 為基礎的傳輸、壅塞控制或頻寬參數。每種協定都應依自身結構填寫。將某協定的驗證欄位放入另一種協定不會產生相容層，通常只會被忽略或導致載入失敗。

協定能力由 mihomo 核心提供，FlClash 提供設定管理與跨平台介面。核心中存在某個欄位，不代表每個平台的系統網路條件都相同。例如以 UDP 為基礎的協定可能受到公共 Wi‑Fi、企業網路或電信商路徑限制；TUN 權限與背景執行也會影響行動裝置體驗。驗證節點時應先使用簡單的連通性測試，再觀察握手記錄。節點測速失敗不一定表示訂閱失效，也可能是測試位址無法連線、DNS 尚未就緒、UDP 受限或策略形成循環。

節點名稱、敏感欄位與分享界線

節點設定包含伺服器位址與驗證資訊，不應直接貼到公開問題頁面。排錯時可以保留欄位結構，將位址替換為 proxy.example.com，把密碼或 UUID 替換成明顯的測試值，同時保留協定類型、階層與布林欄位。不要只截取一行錯誤而隱藏上下文，因為許多問題來自縮排或父欄位。也不要在公開文字中留下訂閱 URL；訂閱連結通常具備存取憑證的性質，洩漏後應至服務端重設，而不是只從貼文中刪除。

同名節點會讓策略引用與介面選擇變得不確定。手動設定應確保名稱唯一；從多個代理提供者彙整節點時，可在覆寫階段加入來源前綴或後綴。使用正規表示式篩選名稱時，需要考慮括號、加號與其他中繼字元。先用少量節點驗證篩選表示式，再套用到完整訂閱。若需要重新選擇圖形化用戶端，下載中心依平台列出 Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等選項，其中 Clash Plus 為全平台首選入口。

策略組欄位：選擇、自動測試、故障轉移與鏈式引用

策略組是規則與節點之間的決策層

proxy-groups 將節點、內建動作與其他策略組組織成可引用的出站集合。規則通常不直接寫入具體節點，而是指向「節點選擇」「自動選擇」「國際流量」等穩定的策略名稱。如此一來，訂閱節點變動時，只需更新組內候選，不必重寫全部規則。每個組至少包含 name 與 type，候選來源可透過 proxies 明確列出，或透過 use 引用代理提供者。

select 允許使用者手動選擇候選項，適合作為頂層總入口。候選項中可以同時放入具體節點、自動測試組與 DIRECT。組內第一個項目通常具有預設意義，但用戶端也可能儲存上次選擇，因此調整順序後不一定會立即改變目前選項。排查「規則命中正確的組卻仍走錯節點」時，應同時檢查策略組的目前選擇與持久化狀態。

proxy-groups:
  - name: "節點選擇"
    type: select
    proxies:
      - "自動選擇"
      - "故障轉移"
      - "辦公室 SOCKS"
      - DIRECT

  - name: "自動選擇"
    type: url-test
    proxies:
      - "辦公室 SOCKS"
      - "範例 HTTP"
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

  - name: "故障轉移"
    type: fallback
    proxies:
      - "辦公室 SOCKS"
      - "範例 HTTP"
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true

url-test、fallback 與 load-balance

url-test 定期請求測試 URL，依結果選擇表現合適的候選項。interval 是測試間隔，過短會增加節點與裝置負擔；tolerance 提供切換容差，避免數值輕微波動造成頻繁換線；lazy 允許策略組在未被使用時減少主動測試。測試 URL 應穩定、回應內容小、在目標網路可達，並能代表實際連線路徑。最低延遲只代表在該測試目標下建立請求較快，不表示頻寬、封包遺失率與目標網站路徑一定最佳。

fallback 依候選順序選擇可用項目，適合希望優先使用主節點、失敗後再切換的情境。它不是將所有請求平均分配，也不保證現有長連線能無感移轉。load-balance 在多個候選項之間分配連線，常見策略包括一致性雜湊或輪詢。涉及登入工作階段、對來源位址敏感的服務時，應謹慎使用輪詢，否則同一業務的不同連線可能從不同出口送出。需要穩定工作階段時，一致性策略或手動選擇通常更容易控制。

代理提供者與動態候選項

當節點來自遠端訂閱時，proxy-providers 可以獨立管理節點資料、更新週期與健康檢查，策略組則透過 use 引用提供者。如此一來，遠端節點增刪後，策略組不必逐一修改名稱。提供者的 filter、exclude-filter 或覆寫規則可以依名稱篩選地區、協定或用途，但篩選效果取決於上游命名品質。名稱不穩定時，更可靠的方法是依多個條件分層，並保留一個未篩選的總組作為檢查入口。

健康檢查與策略組測試存在重疊。提供者層級的健康檢查用於判斷節點基本可用性，策略組的 url-test 用於候選決策。兩層都設定極短間隔會產生重複流量。裝置效能有限或節點數量較多時，可以延長提供者檢查週期，讓常用自動組負責更即時的測試。若所有節點同時顯示不可用，應先確認測試 URL、DNS 與網路入口，不要立即判定全部節點失效。

proxy-providers:
  remote-main:
    type: http
    url: "https://subscription.example.com/your-token"
    path: ./providers/remote-main.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: "訂閱節點"
    type: select
    use:
      - remote-main

  - name: "自動訂閱"
    type: url-test
    use:
      - remote-main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 100

鏈式引用必須避免循環

策略組可以引用其他策略組，用於建立「業務分類組 → 總選擇組 → 自動測試組 → 節點」的層次。例如串流媒體組既可以單獨選擇，也可以回退到總選擇組。但任何引用鏈都不能回到自身。A 引用 B、B 又引用 A 會形成循環，連線無法得到最終出站。複雜設定應依相依順序排列底層節點組、自動組、總選擇組與業務組，並用名稱表達職責。

內建策略 DIRECT 表示直接連線，REJECT 表示拒絕請求。它們可以作為策略組候選，也可以直接寫在規則結尾。將 DIRECT 放入頂層選擇組，方便暫時繞過代理，但也增加誤選風險；面向固定裝置的設定可以將直連交給明確規則，不必在所有業務組中重複提供。拒絕策略用於明確不需要連線的目標，使用範圍過廣會造成頁面資源缺失或應用程式功能異常，應先從精準規則開始。

規則集與 Rule Providers：拆分、更新與行為類型

為什麼要將大型規則表拆離主設定

rule-providers 用於宣告可獨立載入與更新的規則集。主設定只保留提供者名稱、來源、快取路徑、更新週期與行為類型，再透過 RULE-SET 規則引用。如此可將廣告封鎖、區域網路直連、特定服務、區域網域等不同職責拆開，縮短主檔案，也方便分別更新。規則集不是策略組，它只提供比對條件；命中後要採用哪個策略，仍由主設定中的 RULE-SET,提供者名稱,策略名稱 決定。

提供者常見的 type 為 http 或 file。遠端類型需要 url、本地快取 path 與更新 interval；本地類型則讀取裝置上的檔案。快取路徑應彼此唯一，避免兩個提供者覆蓋同一檔案。遠端更新失敗時，核心通常會繼續使用既有快取，但首次載入且沒有快取時可能無法使用該規則集。關鍵直連規則可以保留少量內建備援，不應讓基本連網完全依賴尚未成功下載的遠端檔案。

rule-providers:
  private-domain:
    type: http
    behavior: domain
    format: yaml
    path: ./rules/private-domain.yaml
    url: https://rules.example.com/private-domain.yaml
    interval: 86400

  private-network:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./rules/private-network.yaml
    url: https://rules.example.com/private-network.yaml
    interval: 86400

rules:
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,private-network,DIRECT,no-resolve
  - MATCH,節點選擇

behavior 決定如何解讀規則內容

domain 行為用於網域集合，內容通常是完整網域、網域後綴或受支援的網域表示式；ipcidr 用於 IPv4、IPv6 網段；classical 則允許規則集中的每個項目帶有傳統規則類型，例如 DOMAIN-SUFFIX、IP-CIDR、PROCESS-NAME。行為類型必須與檔案內容一致。將帶有規則類型前綴的 classical 檔案宣告為 domain，不會自動移除前綴並轉換，通常會導致無法載入或全部無法比對。

選擇行為時應優先採用最精準的模型。純網域清單使用 domain，純網段清單使用 ipcidr，需要混合條件時再使用 classical。清楚的行為類型有助於核心最佳化，也方便維護者判斷規則是否需要 DNS 解析。不要因為 classical 能容納更多格式，就把所有規則塞進一個巨大的檔案；依職責與資料類型拆分，排查命中時會更直接。

規則集檔案格式與內容

YAML 規則集通常以 payload 為根鍵，下面是規則序列。在 domain 行為下，後綴表示式可以比對根網域及子網域；精確網域只比對指定主機。在 ipcidr 行為下，應填寫標準 CIDR 網段。classical 行為則填寫完整規則條件，但不要在規則集項目中附加最終策略，因為策略會在主設定引用時指定。將同一個規則集交給不同策略是可行的，例如工作設定將某個集合直連，旅行設定則將同一集合交給代理。

# private-domain.yaml
payload:
  - "+.lan"
  - "+.local"
  - "router.example"
  - "intranet.example.org"

# private-network.yaml
payload:
  - "10.0.0.0/8"
  - "172.16.0.0/12"
  - "192.168.0.0/16"
  - "127.0.0.0/8"
  - "::1/128"
  - "fc00::/7"

format 應與遠端檔案的實際格式一致。副檔名不是充分依據，下載後應檢查正文結構與回應內容。遠端位址回傳登入頁、限流提示或 HTML 錯誤頁時，檔案可能成功儲存，卻無法依規則集解析。記錄若出現規則集格式錯誤，應檢查最終回應，而不只是確認 URL 能否在瀏覽器開啟。需要驗證的私有規則集還應考慮憑據更新與裝置間同步，不應將真實存取參數貼入公開設定範例。

更新週期、快取與原子性

interval 以秒表示更新間隔。規則內容每天變更一次時，沒有必要每幾分鐘抓取。頻繁更新會增加網路請求與上游壓力，也更容易在短暫故障時反覆報錯。合理做法是讓遠端檔案具備穩定快取，本地繼續使用上一份可解析內容，並在記錄中記下更新失敗。修改規則來源後，可以手動觸發更新或清除對應快取進行驗證，但不要一次刪除所有提供者快取，否則會將單一檔案問題擴大為所有規則集同時無法使用。

規則集更新與主設定更新並不是同一個交易。主設定先引用尚未成功下載的提供者時，可能暫時出現內容缺失；遠端規則內容發生不相容變更，也可能要到下一次週期更新後才暴露。重要設定應保留精簡的主規則備援，例如私有網段直連與最終 MATCH，並將外部集合放在適當位置。規則來源應清楚、職責單一且可回退。來源不明的大型集合可能互相覆蓋，最後表現為某些網域偶爾走錯策略。

規則語法：由上到下比對，第一條命中即結束

一條規則的基本結構

rules 是有序序列。傳統規則通常由規則類型、比對內容、目標策略與選用參數組成，以逗號分隔。例如 DOMAIN-SUFFIX,example.org,節點選擇 表示將以 example.org 為後綴的網域交給「節點選擇」。核心會從第一條開始向下檢查，命中後不再繼續。因此規則設計的核心不在於單條規則是否正確，而在於範圍較窄的規則是否位於範圍較寬的規則之前。

MATCH 不需要比對內容，通常寫在最後，接收此前未命中的所有流量。若將它放在中間，後續規則永遠沒有執行機會。規則目標可以是策略組、具體節點或內建動作，但為了維持穩定，通常指向策略組。節點名稱變更時，規則不必修改；只要策略組仍能提供有效候選，整條決策鏈就能保持完整。

rules:
  # 精確網域優先
  - DOMAIN,api.example.org,DIRECT
  # 接著處理完整網域後綴
  - DOMAIN-SUFFIX,example.org,節點選擇
  # 關鍵字範圍較寬，放在後面
  - DOMAIN-KEYWORD,example,節點選擇
  # 私有網路直接連線
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  # 最終備援
  - MATCH,節點選擇

網域規則的範圍差異

DOMAIN 只比對完整網域，適合需要單獨處理的 API、登入入口或特定主機。DOMAIN-SUFFIX 比對一個網域及其子網域，適合依服務整體分流。DOMAIN-KEYWORD 依網域中是否出現關鍵字判斷，涵蓋範圍較寬，也更容易誤傷，例如短關鍵字可能出現在無關網域中。能使用精確網域或後綴時，不應先用關鍵字擴大範圍。

網域規則能否參與比對，取決於核心是否掌握連線對應的網域。系統代理通常會直接提供網域；Fake-IP 可以保留映射關係；只有目標 IP 的透明連線可能需要 DNS 快取或嗅探。若記錄只顯示 IP，網域規則未命中不一定是規則拼寫問題。應檢查 DNS 是否由核心處理、嗅探是否適用於該協定，以及應用程式是否直接連線至固定位址。

IP、Geo 與 no-resolve

IP-CIDR 與 IP-CIDR6 依目標位址比對網段。規則結尾的 no-resolve 表示不要為了執行這條 IP 規則而額外解析網域，可減少不必要的查詢，也避免在規則階段引入解析副作用。對已具備目標 IP 的連線，仍可直接判斷。私有網段與本機位址通常應較早直連，避免區域網路裝置流量被送入遠端代理。

地理資料庫相關規則依賴本地資料檔案及其更新狀態。網域分類與 IP 地理歸屬是不同資料來源：某個服務網域可能解析到全球分散的位址，單純依 IP 地區判斷並不等同於依服務分類。使用 Geo 類規則時，應了解其涵蓋範圍，並為關鍵業務保留明確的網域規則。資料庫無法載入時，相關規則可能失效，而一般 DOMAIN 與 IP-CIDR 規則仍可運作，記錄會提供辨別線索。

程序、網路與邏輯組合

PROCESS-NAME、PROCESS-PATH 等程序規則適合依桌面應用程式分流，但依賴系統權限與平台實作。Android 更常見的是套件名稱或系統提供的應用程式識別方式，iOS 的系統限制也不同。Windows 與類 Unix 系統對程序路徑的表示方式完全不同，不能共用同一條絕對路徑。跨平台設定若必須包含程序規則，應依裝置透過覆寫注入，而不是將所有平台路徑混入同一個基礎檔案。

mihomo 支援將邏輯規則組合多個條件，用於表達「同時滿足」「任一滿足」或「排除某項」。組合能力越強，閱讀與排錯成本越高。實際維護時，優先透過規則順序表達例外：先寫少量排除項，再寫一般規則。只有當順序無法清楚表達，或多個條件確實必須同時成立時，才使用邏輯組合。複雜表示式應附上註解與可重複測試的目標網域，否則幾個月後很難判斷原始意圖。

規則順序的穩定範本

一套容易解釋的順序通常是：本機與區域網路例外、明確拒絕項目、關鍵業務精確規則、業務網域規則集、區域或網路規則、最終備援。順序不是固定答案，但每一層都應說明為何要排在下一層之前。若某個精確網域需要直連，就必須位於包含該網域的代理後綴規則之前；若某個子網域需要代理，也必須位於整個父網域直連規則之前。

驗證規則時，不要依賴單次開啟網頁。瀏覽器可能重用既有連線，DNS 也可能命中快取。修改後可關閉相關連線、清除必要快取，再觀察記錄中的目標、規則類型與策略名稱。若記錄命中正確但出口不符，應繼續沿策略組檢查；若記錄未顯示網域，則回到 DNS 與嗅探層。規則問題、策略選擇問題與節點連線問題應分層判斷。

覆寫與合併：讓訂閱更新保留本地調整

原始訂閱、產生設定與最終設定

遠端訂閱是上游資料來源，FlClash 匯入後可能經過解析、覆寫與核心適配，最終形成執行設定。直接編輯訂閱快取看似立即有效，但下次更新通常會被新內容取代。穩定維護應將上游負責的節點資料與本地負責的策略分開：訂閱提供節點與基礎組，本地覆寫負責連接埠、DNS、組結構、規則與裝置差異。發生問題時，要區分原始訂閱是否正確、覆寫是否依預期執行，以及最終設定是否被核心接受。

覆寫不等於簡單的文字串接。映射欄位、序列欄位與同名物件需要不同策略。映射可以依鍵替換或遞迴合併；序列可以整體替換、在開頭插入、在結尾追加或依名稱處理。若不清楚目前工具的合併語意，最安全的方法是先從一個可觀察的欄位開始測試，例如修改 mode，再查看最終設定。不要一次加入完整 DNS、數十條規則與多個策略組，否則發生錯誤時很難定位是哪種合併操作造成的。

替換映射與追加序列的差異

假設原設定已有完整的 dns 映射，本地覆寫只寫入 dns.enable: true。遞迴合併會保留原有 nameserver 等子項，整體替換則可能只剩下 enable。兩種結果都符合某種「覆寫」定義，因此必須以 FlClash 目前的覆寫類型與最終預覽為準。對於關鍵 DNS 區段，若需要完全控制結果，明確寫出完整目標結構通常比依賴部分合併更穩定。

rules 是有順序的序列。簡單追加適合將 MATCH 前的補充規則放到正確位置，但若原清單已以 MATCH 結尾，將新規則追加在末尾就永遠無法命中。開頭插入適合區域網路例外與精確覆蓋；整體替換適合完全自行管理規則體系。策略組序列依名稱合併時，還要確認同名組是替換、擴充還是產生重複物件。出現兩個同名組會讓介面與引用結果難以判斷。

# 基礎設定：base.yaml
mixed-port: 7890
mode: rule

proxy-groups:
  - name: "節點選擇"
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,節點選擇

# 本地覆寫目標：override.yaml
log-level: info
ipv6: false

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.google/dns-query

插入規則需要明確位置

為訂閱加入自訂規則時，先判斷規則屬於例外、一般分類或備援。例外規則通常插入開頭；業務規則應放在範圍更廣的集合之前；備援規則只能存在於末尾。支援腳本覆寫時，可以找出原清單中的 MATCH 索引，再將新增規則插入其前方。若找不到 MATCH，應記錄提示並決定是否補上，而不是默默追加後假定結構正確。

去重不能只比較整行文字。兩條規則可能比對條件相同卻指向不同策略，這代表衝突而不是重複；同一網域的精確規則與後綴規則也不是重複。合理做法是先依規則類型與比對內容識別衝突，再依本地優先級決定保留位置。自動刪除前應輸出可檢查的結果。規模較小的自訂規則，保持明確易讀通常優於過度自動化。

裝置差異應放在最外層

跨平台共用設定時，節點、策略組與大部分網域規則可以共用；TUN、程序路徑、網路介面、區域網路監聽與系統 DNS 接管則具有明顯的裝置差異。建議維護一個與平台無關的基礎層，再為 Windows、macOS、Android 與 Linux 分別套用輕量的裝置覆寫。如此不必為了相容某個平台，將其他平台不認識或不需要的欄位塞進同一個檔案。

例如桌面端可能需要程序規則，Android 更適合依應用程式能力處理；Linux 路由器可能使用透明代理連接埠，一般 Windows 桌面則只需要 mixed-port 或 TUN；macOS 網路延伸功能需要系統授權，設定欄位本身無法取代權限核准。涉及平台安裝與權限時，應回到快速入門與macOS 網路延伸功能設定說明，不要試圖只靠 YAML 繞過系統要求。

訂閱更新後的驗證清單

更新完成後先確認訂閱抓取成功，再檢查節點數量與名稱結構是否出現預期變化；接著確認覆寫執行沒有報錯，最終設定中的 DNS、策略組與規則仍然存在；最後啟動核心，觀察監聽、DNS 初始化、規則提供者與代理提供者的載入狀態。設定成功載入後，再檢查策略組目前的選擇，因為上游刪除節點時，已儲存的舊選擇可能失效或回退。

自動更新失敗不應透過不斷縮短間隔來解決。應檢查訂閱位址是否有效、網路是否需要經過代理、DNS 是否能解析訂閱伺服器、更新請求是否形成代理迴圈，以及用戶端是否在背景執行時受到系統限制。相關分支可查閱Clash 訂閱更新失敗與自動更新設定。若用戶端專案停止維護而需要遷移，可參考設定匯出與用戶端遷移清單。

可回退的維護方式

每次只修改一個職責明確的設定區段，並保留上一份可用檔案。命名可以表達用途與平台，例如基礎層、DNS 層、規則層與裝置層，但不要將動態日期或暫時狀態寫進策略名稱，否則規則引用會頻繁變動。更新前記錄目前的策略選擇，更新後驗證關鍵網域、區域網路存取、DNS 路徑與一個代理目標。測試範圍應包含直連與代理兩類流量，避免只驗證網頁能否開啟。

當覆寫逐漸變得難以解釋時，表示應該整理，而不是繼續追加修補。刪除失效的規則來源，合併職責重複的策略組，將裝置專屬欄位移出基礎層，並為每個外部提供者記錄用途。設定手冊的目標不是塞滿所有可用欄位，而是讓每次請求都能沿著「入口、DNS、規則、策略組、節點」的鏈路得到明確解釋。完成基礎設定後，可回到快速入門執行連線驗證，或前往常見問題依症狀繼續排查。