プラットフォーム別ガイド 読了時間の目安：10分

macOS版Clashの権限設定｜ネットワーク拡張の許可とキーチェーンのパスワード要求への対処

ChatGPTがつながらない、GitHubやnpmのダウンロードが遅いときは、ルールの適用先を見直してみましょう。Mihomoのrule-providersを使ったYAMLルールセットの作り方から、ルール順序、プロキシグループとの連携、リモート更新、マッチ確認まで解説。DNSや意図しない直結の調査方法も紹介します。

rule-providersで用途別ルールを管理する

Mihomoのrule-providersは、ドメインやIPアドレスなどのルールを設定本体から分けて管理する仕組みです。プロバイダーにルールを定義し、rulesからRULE-SETで呼び出すと、AIサービス、GitHub、npmの通信をそれぞれ異なるポリシーグループへ振り分けられます。対象ドメインの追加や削除も、分割したルールファイルだけを編集すればよく、長いルール一覧を設定本体に直接並べるより見通しを保ちやすくなります。

まずは既存設定をバックアップしてください。GUIクライアントの設定画面でサブスクリプションを直接編集すると、更新時に変更が上書きされることがあります。設定のマージ機能やオーバーライド機能を使う場合は、クライアントが対応する方法に合わせてください。同じYAML階層にrule-providersやproxy-groupsを重複して書くと、後の定義で前の内容が置き換わったり、読み込みに失敗したりする場合があります。

以下は、設定ファイルのあるディレクトリにrulesフォルダーを作り、ローカルファイルから読み込む例です。既存の設定にあるプロキシ名やグループ名に合わせて、Proxyなどの名称は変更してください。

rule-providers:
  ai-tools:
    type: file
    behavior: classical
    path: ./rules/ai-tools.yaml
  github:
    type: file
    behavior: classical
    path: ./rules/github.yaml
  npm:
    type: file
    behavior: classical
    path: ./rules/npm.yaml

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

rules:
  - RULE-SET,ai-tools,AI
  - RULE-SET,github,Development
  - RULE-SET,npm,Development
  - MATCH,Proxy

type: fileはローカルのルールファイルを読み込みます。behavior: classicalでは、各項目にDOMAIN-SUFFIXなどのルールタイプを付けて記述します。pathは設定ファイルからの相対パスとして扱われる構成が一般的ですが、GUIクライアントによって設定の保存先や作業ディレクトリが異なることがあります。ファイルが見つからないエラーが出た場合は、クライアントの設定ディレクトリと実際の配置場所を確認してください。

AI・GitHub・npmのルールを用意する

プロバイダーファイルは、先頭にpayload:を置き、その下にルールを並べるYAML形式です。次の内容を、それぞれ指定したファイル名で保存します。ここに挙げたドメインは設定例であり、サービスの全機能に必要な通信先を網羅するものではありません。実際に使うサービスや組織内の追加ドメインに応じて調整してください。

AIサービス用：rules/ai-tools.yaml

payload:
  - DOMAIN-SUFFIX,openai.com
  - DOMAIN-SUFFIX,chatgpt.com
  - DOMAIN-SUFFIX,oaistatic.com
  - DOMAIN-SUFFIX,anthropic.com
  - DOMAIN-SUFFIX,claude.ai

この例では、OpenAI関連のドメインとClaude関連のドメインを同じAIグループに渡します。サービスのログイン、画面表示、API通信は異なるドメインを使う場合があります。画面が開くのにログインや応答だけ失敗するときは、接続ログで実際に使われたドメインを確認し、必要なものだけ追加してください。無関係なドメインを広く登録すると、意図しないサービスまで同じ経路を通る可能性があります。

GitHub用：rules/github.yaml

payload:
  - DOMAIN-SUFFIX,github.com
  - DOMAIN-SUFFIX,githubusercontent.com
  - DOMAIN-SUFFIX,githubassets.com
  - DOMAIN-SUFFIX,github.io

github.comだけを振り分けても、リリースファイル、画像、静的コンテンツなどが別ドメインから配信される場合があります。ページの一部だけ表示されない、ダウンロードが止まるといった場合は、失敗した接続の宛先ドメインをログで調べてから追加します。プロジェクトごとの独自ドメインを一律に開発用プロキシへ含めるのではなく、必要性を確認して登録するのが安全です。

npm用：rules/npm.yaml

payload:
  - DOMAIN-SUFFIX,npmjs.com
  - DOMAIN-SUFFIX,npmjs.org

npmクライアントのレジストリ通信では、標準のregistry.npmjs.orgが利用されます。このドメインはnpmjs.orgのサブドメインなので、上のサフィックスルールに一致します。ただし、プロジェクトの.npmrcや社内ネットワークで別のレジストリを指定している場合は、そのホスト名を別途確認してください。YAMLファイルはUTF-8で保存し、タブではなく半角スペースでインデントします。

ルールの順番とプロキシグループを整える

rulesは上から順に照合され、最初に一致したルールのポリシーが適用されます。そのため、ルールプロバイダーの呼び出しは、広い条件のルールや最後のMATCHより前に置きます。上の例では、AI、GitHub、npmの各ルールセットに一致した通信を用途別のグループへ渡し、それ以外の通信をProxyへ渡しています。

AIとDevelopmentは、この例で新しく定義したセレクター型のプロキシグループです。候補のProxyは、実際の設定に存在するノードまたはグループ名に置き換えてください。表示名の大文字・小文字、空白、記号も含めて一致させます。既存設定に似たグループがある場合は、同じ機能のグループを重複作成するより、既存の定義を利用する方が管理しやすくなります。

設定箇所役割確認ポイント
rule-providersルールセットの種類とファイルの場所を定義するプロバイダー名とファイル名、相対パスが一致しているか
プロバイダーファイル用途別のドメインルールを列挙するpayload:の下に有効なルールがあるか
RULE-SETルールセットをポリシーグループへ接続するプロバイダー名と指定先のグループ名が定義済みか
MATCHそれ以前のルールに一致しない通信を処理する通常はルール一覧の末尾にあるか

同じドメインが複数のプロバイダーに含まれる場合、先に一致するルールのグループが使われます。たとえば、あるAIサービスのドメインをai-toolsと別の広い開発用ルールセットの両方に登録した場合、順序によって結果が変わります。特定用途のルールを先に置き、より包括的なルールを後に置くと、判断しやすくなります。

更新・動作確認と、意図した経路にならない場合の対処

ローカルのtype: fileは、ファイルを編集しても自動で外部から更新される方式ではありません。変更後はクライアントの設定再読み込み、プロファイル更新、またはコアの再起動を行い、設定が正常に読み込まれたことをログで確認します。リモート配布のルールセットを使う場合は、Mihomoが対応するHTTPプロバイダー形式を利用し、実際に管理されているURL、ローカル保存先のpath、更新間隔のintervalを指定します。公開元や更新頻度を確認できないURLを設定にコピーしないでください。ルールファイルを取得できても、形式やルール内容が正しくなければ読み込みに失敗することがあります。

  1. YAMLを保存した後、クライアントで設定を再読み込みし、プロバイダーファイルの読み込みエラーがないか確認します。
  2. プロキシグループ画面で、AIまたはDevelopmentに利用可能な選択肢が表示され、意図した出口が選択されていることを確認します。
  3. ブラウザーや開発ツールで対象サービスへ新しい接続を発生させ、クライアントの「接続」画面またはログを開きます。既存の接続は以前の経路を使い続ける場合があるため、必要に応じて対象アプリを再接続します。
  4. 対象ドメイン、照合されたルールまたはルールセット、選択されたポリシーを順に確認します。接続先が期待と違う場合は、設定を一度に一か所だけ変更して再テストします。

接続画面に別のルールが表示される場合は、ルールの順序、より前にある広いルール、プロキシモードがruleになっているかを確認します。プロバイダーが見つからない場合は、名前の綴り、ファイル名、設定ディレクトリからの相対パスを確認してください。YAML解析エラーなら、インデント、コロン、ハイフン、ファイルの保存形式を見直します。グループ名のエラーでは、RULE-SETの転送先が実在するか、候補に指定したProxyが設定内にあるかを調べます。

ルールが一致しているのに通信が失敗する場合、必ずしもプロバイダーが原因とは限りません。グループで選ばれたノードが利用可能か、DNS解決が成功しているか、アプリがシステムプロキシやTUNを通じてMihomoへ通信を渡しているかを確認します。逆に、ブラウザーだけ期待した経路にならない場合は、ブラウザー独自のプロキシ設定、既存セッション、接続の再利用も確認対象です。ドメインルールはドメイン情報を利用するため、宛先がIPアドレスだけで見えている通信や、アプリが独自のDNS・暗号化通信を使う場合は、期待どおり照合されないことがあります。

動作確認では、対象の接続ログに出た実際のホスト名をもとにルールを調整してください。スクリーンショットやログを共有する場合は、サブスクリプションURL、認証情報、個人用の接続先を伏せます。複数の設定を同時に変更すると、どの変更が結果に影響したか分からなくなるため、バックアップを保ち、プロバイダー、ルール順、グループ選択を一項目ずつ確認するのが確実です。

ルールプロバイダーを利用すると、用途別の通信先を分離しながら、通常通信の既定ルートも維持できます。最初は対象を少数のドメインに絞り、接続ログで一致結果を確認してから拡張してください。設定の読み込み、ルールの照合、グループの選択、通信の取り込みをそれぞれ分けて検証すれば、意図しない経路の原因を特定しやすくなります。

Clashをダウンロード