用 Mihomo 規則集整理 AI 與開發流量

rule-providers 適合解決什麼問題

ChatGPT 登入頁面能開啟，對話卻載入失敗；GitHub 網頁正常，Git 操作或檔案下載卻逾時；npm 套件安裝時，登錄站台連線忽快忽慢。這些情況不一定是同一個節點故障，也可能是相關網域命中了不合適的規則，或服務所需的網域分散在多條規則中，難以逐一維護。

mihomo 的 rule-providers 可以把一組規則存放在獨立清單，再由主設定檔引用。比起把所有網域都直接寫進 rules，這種方式較容易分開管理 AI 服務、程式碼平台與套件登錄站，也能設定遠端清單的更新週期。要留意的是，規則提供者只負責提供比對條目；它不會自動替使用者挑選最快節點，也不會保證網站的所有功能都只使用同一批網域。

下方範例把 ChatGPT、GitHub 與 npm 分成三個提供者，並將連線交給各自的策略群組。示範中的網址使用保留用的 example.net 網域，不能直接下載規則；正式使用時，必須換成可信任且可連線的規則檔網址，或改用本機檔案。策略名稱也要配合現有設定，不可照抄後假設核心會自動建立相應群組。

建立分流策略與規則提供者

先確認設定檔中已有可用的節點，並為 AI 和開發工具建立策略入口。以下是 YAML 片段，不是完整設定檔；請將 Proxy 換成現有的節點或策略群組名稱。若現有設定已有相同名稱的群組，應沿用原群組或調整名稱，避免重複定義造成載入錯誤。

proxy-groups:
  - name: AI-Proxy
    type: select
    proxies:
      - Proxy
      - DIRECT
  - name: Dev-Proxy
    type: select
    proxies:
      - Proxy
      - DIRECT

select 群組由使用者在客戶端切換選項。若需要把 GitHub 與 npm 分開選擇，可再建立 GitHub-Proxy 和 npm-Proxy 群組；若兩者可共用同一出口，使用 Dev-Proxy 會比較精簡。群組中的每個候選名稱都必須已在設定中定義，DIRECT 則是核心提供的直連出口。

接著在頂層新增規則提供者。behavior: domain 適用於網域類型條目；format: yaml 表示提供者檔案採用 YAML 格式。interval 的單位是秒，例子中的 86400 代表每日檢查更新一次。遠端提供者會由核心下載並保存到 path 指定的位置；不同用戶端的工作目錄可能不同，請確認該路徑位於可寫入的設定資料目錄，必要時使用用戶端文件建議的完整路徑。

rule-providers:
  chatgpt:
    type: http
    behavior: domain
    format: yaml
    url: https://rules.example.net/chatgpt.yaml
    path: ./rules/chatgpt.yaml
    interval: 86400
  github:
    type: http
    behavior: domain
    format: yaml
    url: https://rules.example.net/github.yaml
    path: ./rules/github.yaml
    interval: 86400
  npm:
    type: http
    behavior: domain
    format: yaml
    url: https://rules.example.net/npm.yaml
    path: ./rules/npm.yaml
    interval: 86400

每個 YAML 規則檔需符合相應的提供者格式。例如網域清單可用 payload 包住規則：

payload:
  - DOMAIN-SUFFIX,chatgpt.com
  - DOMAIN-SUFFIX,openai.com
  - DOMAIN-SUFFIX,oaistatic.com

以上網域只作為規則結構示例，不代表列出後便涵蓋 ChatGPT 的所有登入、靜態資源或 API 網域。GitHub 可依實際需求整理 github.com、githubusercontent.com 等網域；npm 常見登錄網域包括 registry.npmjs.org，而套件下載也可能涉及其他主機。先從連線記錄確認實際目的網域，再決定是否加入；避免把不相關的通用 CDN 網域整批代理，造成額外流量或誤分流。

規則順序與策略選擇

規則模式會依 rules 的排列順序逐條比對，符合後便交給該條指定的策略處理。因此，自訂提供者應放在可能先攔截相同流量的寬泛規則之前。若前面已有某個網域的直連規則，後面的 RULE-SET 就不會再接手該連線；若一般代理清單排在自訂清單前面，也可能先由一般清單選定出口。

通常先保留既有的區域網路或必要直連規則，再放入需要優先控制的自訂清單，接著才是其他較廣泛的規則，最後以 MATCH 作為兜底。下方只示範順序；其中的 Existing-Proxy 代表原設定中確實存在的群組名稱，請勿原樣加入不存在的策略。

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - RULE-SET,chatgpt,AI-Proxy
  - RULE-SET,github,Dev-Proxy
  - RULE-SET,npm,Dev-Proxy
  # 在此保留原有的其他規則
  - MATCH,Existing-Proxy

RULE-SET 後面的第一個參數必須與 rule-providers 下的名稱完全一致；第二個參數則是規則命中後使用的策略。這裡的 chatgpt、github 和 npm 是提供者名稱，AI-Proxy 與 Dev-Proxy 是策略群組名稱，兩者用途不同。網域規則提供者使用 behavior: domain，不要因為看到其他清單含有 IP 網段，就直接把它設成相同類型；提供者行為必須符合清單內條目的類型。

策略群組決定的是出口，不是規則是否命中。若 github 規則已命中，但 Dev-Proxy 目前選擇 DIRECT，連線仍會直連。反過來說，切換至全域模式也會改變一般規則的處理方式，不適合用來判定某一條自訂規則是否正確。測試時請保持規則模式，並確認群組當前選項。

想要的結果	規則與群組配置	注意事項
ChatGPT 使用指定代理	ChatGPT 提供者指向 `AI-Proxy`	確認登入與資源網域是否也有命中
GitHub 和 npm 共用出口	兩個提供者都指向 `Dev-Proxy`	群組選擇會同時影響兩類連線
npm 保持直連	將 npm 規則指向 `DIRECT` 或可選擇直連的群組	確認目前網路可連線至實際套件登錄站
特定網域不套用自訂分流	在提供者規則前加入更精確的規則	前置規則會先命中，後面的提供者不再決定該連線

更新清單與核對實際命中

遠端提供者的更新由核心依 interval 檢查；用戶端的「更新設定檔」與「更新規則提供者」可能是不同操作。更改規則檔或網址後，可在用戶端的設定檔、覆寫或規則提供者頁面尋找更新功能，選單名稱會因版本而異。不要把節點延遲測試當成規則清單更新，也不要在尚未確認核心已載入新設定時，就以舊連線結果判定修改無效。

檢查 YAML 結構：確認縮排使用一致的空格，rule-providers、proxy-groups 與 rules 都位於正確層級，欄位名稱沒有拼錯。
檢查提供者內容：確認遠端網址可取得規則檔，而非登入頁、錯誤頁或空白回應；檔案內容需符合設定的格式與行為類型。
檢查核心載入結果：使用用戶端提供的設定檢查或重載功能，並查看日誌是否出現提供者下載、解析或策略名稱錯誤。
建立新連線再測試：關閉原有網站連線或重新執行命令，避免既有連線仍沿用舊的出口。可在客戶端「連線」頁查看網域、匹配規則及出站策略。

如果客戶端提供 Mihomo 核心的設定檢查功能，優先使用它確認目前實際載入的設定。也可在安裝了相容核心的命令列環境中使用測試模式，例如 mihomo -t -f config.yaml；執行前請先確認命令所指向的檔案，就是準備套用的設定檔。不同版本或封裝方式的參數可能略有差異，若指令不被接受，請以該版本的說明為準。

驗證時不要只看「網站打得開」。一個網頁可能同時載入多個網域，建議分別測試 ChatGPT 登入與對話、GitHub 網頁與所需的 Git 操作，以及 npm 套件下載。若某一項失敗，查看該次連線實際命中的規則和策略，再把缺少的網域加入對應清單。若提供者下載失敗，先確認核心是否能連至規則檔主機、快取檔是否存在，以及更新錯誤的完整日誌；把更新間隔縮短並不能修復錯誤網址或無法連線的來源。

當分流結果穩定後，再調整清單內容或策略選項，一次只改一個條件。這樣能分辨問題是規則未命中、群組選錯、提供者未更新，還是服務本身所需的其他網域尚未納入。更新前也要確認客戶端是否會覆寫本機檔案，避免下一次訂閱更新後，自訂規則消失或位置改變。