先分清楚檔案類型：設定檔、訂閱與用戶端設定

Clash 設定檔通常是 YAML 文字檔，常見檔名為 config.yaml。檔案會描述本機監聽埠、DNS、代理節點、策略組與分流規則；用戶端讀取檔案後，再由所使用的核心解讀這些欄位。訂閱連結則是取得設定檔的其中一種方式：用戶端向連結發出請求、儲存回傳內容，並依設定週期更新。訂閱網址本身不是 proxies 節點，也不能直接寫進 rules 當成規則。

先在用戶端確認目前選取的是哪個 Profile，再決定是否編輯。用戶端可以同時儲存多份設定，但執行時通常只會啟用選取的那一份。手動修改由訂閱產生的檔案，可能在下次更新時被覆蓋；若要長期保留調整，應使用用戶端提供的覆寫功能，或維護可自行編輯的本機設定檔。各用戶端支援的覆寫入口不盡相同，儲存前請確認修改套用的是原始檔案還是訂閱副本。

開始修改前，先複製一份原始設定檔備份。修改後先確認用戶端能否載入 YAML，再檢查策略組與規則是否如預期運作；「匯入成功」和「連線走對出口」是兩回事。

基礎欄位：port、mixed-port 與運作模式

頂層欄位要從行首開始寫。port 是本機 HTTP 代理的監聽埠，socks-port 是本機 SOCKS5 代理的監聽埠；mixed-port 則是在同一個埠接受 HTTP 與 SOCKS5 代理連線。以下範例使用混合埠 7890，方便在支援手動設定代理的 App 中填入 127.0.0.1:7890。這是本機入口，不是遠端節點的埠。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

allow-lan: false 表示不打算讓區域網路中的其他裝置使用這台裝置的代理入口。若確實需要共用，還要檢查用戶端監聽位址、系統權限與所在網路，不應只修改一個開關。mode: rule 會依據 rules 決定出口；global 通常會將請求統一交由選取的策略處理，direct 則以直連方式處理。切換模式有助於排查問題，但不能取代正確的規則與節點設定。

在 iPhone 上，還要區分「本機代理埠」和「系統流量接管」。用戶端建立 VPN 設定或啟用 TUN 後，部分流量可透過系統網路延伸功能進入核心，不必要求每個 App 手動填入 7890。實際接管哪些請求，取決於用戶端、系統權限及網路設定。設定檔中的 tun 欄位也不是所有 iOS 用戶端都支援；不要直接把桌面版的 TUN 範例貼進手機設定檔。

DNS 區段：解析結果如何參與規則判斷

dns 是一個巢狀物件。enable 用來控制核心的 DNS 功能，nameserver 則列出上游解析伺服器。使用 fake-ip 時，核心會對符合條件的網域回傳保留位址，並記錄網域與該位址的對應關係；後續連線符合對應資料時，核心仍能得知原始網域，以供網域規則比對。這並不是永久把網站的真實位址改成保留位址。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fake-ip-filter:
    - "*.lan"

198.18.0.1/16 是範例中的 Fake-IP 位址範圍，不是可以直接連線的網站位址。fake-ip-filter 可設定特定網域不使用 Fake-IP 對應；若區域網路裝置名稱或依賴真實解析結果的服務發生異常，可以先針對個別網域測試，再決定是否加入排除清單。排除範圍越大，就越難判斷是哪項設定改變了結果。選擇上游 DNS 也應考量實際網路環境：若上游無法連線，網頁可能在連上代理節點之前就卡在 DNS 解析階段。

遇到「網域規則沒有生效」時，先確認請求是否仍保留可供比對的網域資訊，以及用戶端是否使用這份設定檔的 DNS。有些 App 會直接連線到 IP，或自行使用其他解析方式；只調整 nameserver，無法保證它們都會符合 DOMAIN-SUFFIX。若要進一步比較 Fake-IP 與 redir-host 的適用情境，可參閱技術參考，確認目前用戶端支援的欄位。

proxies 與 proxy-groups：分開設定節點與選擇器

proxies 是實際代理節點的清單。每個項目至少要有與其協定相符的名稱、類型、伺服器位址及埠號；驗證、加密或傳輸欄位則依協定而異。下方使用文件範例網域 proxy.example.net 說明結構，這不是可用的節點位址。實際設定請以服務提供者提供的參數為準，不要只憑節點名稱猜測協定。

proxies:
  - name: "自建 SOCKS5"
    type: socks5
    server: proxy.example.net
    port: 1080

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

同名的 proxies 在這裡出現兩次，但層級不同：行首的 proxies 用來定義節點；縮排在 proxy-groups 項目底下的 proxies，則列出該策略組可選擇的出口。select 是手動選擇組，用戶端通常會在策略介面顯示其中的候選項目。DIRECT 是內建的直連目標，不必另外建立同名代理節點。組名與節點名都是引用識別名稱，規則中的名稱必須完全一致。

訂閱設定也可能使用 proxy-providers 集中取得節點，再由策略組引用 provider。這和直接將節點逐一列在頂層 proxies 是兩種不同的組織方式。排查「節點清單空白」時，請分別檢查訂閱是否已更新、策略組是否引用 provider，以及目前的 Profile 是否就是剛更新的那份。不要只因策略組的候選清單空白，就判定是 DNS 故障。

rules：由上而下比對，出口必須存在

rules 是依序排列的清單。核心通常會由上而下檢查，符合某條規則後，就使用該規則指定的出口；因此範圍較小的網域規則通常要放在範圍較大的地理位置規則之前，兜底規則則放在最後。以下範例中的 節點選擇 必須與前面策略組的名稱一致。

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

DOMAIN-SUFFIX 用來比對指定網域及其子網域；GEOIP,CN,DIRECT 則依目標 IP 的地理位置資料判斷，和「這個 App 是中國大陸的 App」並非同一條件。MATCH 用來處理前面規則都未比對成功的請求。若把 MATCH 放在第一行，後續規則通常就沒有比對機會；若先放入範圍過大的規則，也可能遮蔽更精確的網域規則。

規則命中後仍無法開啟網頁，不代表規則語法一定有誤。先在用戶端的連線記錄中查看請求符合哪條規則、交由哪個策略組處理，再檢查組內目前選取的是節點還是 DIRECT。若目標是透過 IP 直連，網域規則可能沒有可供比對的條件；若使用 REJECT，請求會遭到拒絕，而不是改走代理。這些術語的差異可參閱術語表。

縮排、順序與儲存：一次只改一處

YAML 以縮排表示層級。頂層的 dns:、proxies:、proxy-groups:、rules: 都要從行首開始；底下的物件欄位則要再縮排，清單項目以連字號加空格表示。建議統一使用空格，不要混用 Tab。名稱若含冒號、井字號或前後空格，可以加上引號，避免被當成 YAML 語法。大小寫也很重要：DIRECT 和自行命名的 Direct 並不是同一個引用名稱。

狀況優先檢查項目處理方式
無法載入設定錯誤行附近的縮排、冒號與清單連字號還原最近一次修改，再逐段新增
規則引用的目標不存在規則末尾的名稱與策略組名稱統一名稱並檢查大小寫
策略組沒有可選節點組內節點名稱或 provider 引用確認節點已載入，再檢查組內候選清單
修改後又恢復原狀目前 Profile 的來源與訂閱更新紀錄改用可持續保留的覆寫功能或本機設定檔

較穩妥的修改流程是：先備份原始檔案；一次只修改一個欄位或一條規則；儲存後讓用戶端重新載入設定；查看是否出現解析錯誤；最後用一個明確的目標網域檢查連線記錄。例如調整 DOMAIN-SUFFIX,example.org,節點選擇 時，測試目標應位於該網域範圍內，並確認記錄顯示預期的策略組。完成測試後再修改下一處，發生問題時才能迅速找出原因。

YAML 能成功解析，不代表目前使用的核心認得其中每個欄位。Clash、Clash Meta（mihomo）以及各用戶端支援的設定項目並不完全相同；從其他裝置複製設定時，請先確認用戶端使用的核心及其支援範圍。使用 iPhone 時，尤其要分開檢查系統網路延伸功能權限、Profile 選擇、設定語法與實際連線出口。依這四個面向逐一排查，比整份檔案一次替換更容易找到問題。