GitHub・npm・Dockerの接続遅延を改善するClash開発者向けルール設定

まず通信の種類を分ける：Clashのルールは遅延そのものを短縮しない

GitHub、npm、Docker Hubへの接続が遅いときは、最初に「どの通信を、どの経路へ送るか」を決め、ログで実際の振り分けを確認しましょう。Clashのルールは、通信先に応じて既存のプロキシグループや DIRECT を選択する仕組みです。ルールを追加しても、利用するノードの品質や相手側サーバーの応答時間が改善するわけではありません。対象サービスの通信が意図せず直接接続されている場合や、別のグループに振り分けられている場合に、原因を切り分ける助けになります。

開発ツールの通信は、ブラウザーでウェブページを開く通信だけではありません。GitHubではリポジトリ、API、リリースファイルなど、npmではレジストリやパッケージ配布元、Dockerでは認証、イメージマニフェスト、レイヤーの取得が別々のホスト名を使うことがあります。トップページだけをルール対象にしても、ダウンロードの一部が直接接続に残る可能性があります。実際の接続ログに表示されたホスト名を確認し、必要な範囲だけを追加してください。

ドメインルール：接続先のホスト名に基づいて振り分けます。IPアドレスが変わるサービスにも対応しやすく、開発ツールの通信先を管理する基本になります。
ルールセット：複数のドメインを別ファイルで管理し、設定本体から参照します。サービスごとの一覧を更新しやすくなります。
プロキシグループ：ルールが一致した通信の送り先です。選択中のノードが利用できるか、グループ名が設定と一致しているかも確認が必要です。

GitHub・npm・Docker Hubを振り分けるルールの考え方

最初はドメイン単位のルールから始めると、ルールセットの取得元やキャッシュを考えずに動作を確認できます。たとえば DOMAIN-SUFFIX,github.com,開発用 は github.com とそのサブドメインに一致します。GitHubのリリース配布や静的ファイルが別のホスト名を使う場合は、接続ログを見て必要なドメインだけを追加します。無関係な広いドメインを一括で対象にすると、意図しないサービスまで振り分ける可能性があります。

npmでは、パッケージの取得先として registry.npmjs.org が使われる構成が一般的です。利用しているnpm設定でレジストリを変更している場合は、そのホスト名も確認してください。Docker Hubでは docker.io や registry-1.docker.io に加え、認証やイメージレイヤーの取得で別のホスト名がログに現れることがあります。環境やイメージによって通信先は異なるため、ここに挙げたドメインだけで全てのダウンロードを網羅できるとは限りません。

小規模な設定では、ルールを直接書いて試す

以下は既存設定に追加するルールの例です。開発用 は設定内に実在するプロキシグループ名に置き換えてください。ルールは上から評価されるため、広い条件のルールより前に置く必要があります。すでに同じホストに一致するルールが先にある場合、後から追加したルールには到達しません。

rules:
  - DOMAIN-SUFFIX,github.com,開発用
  - DOMAIN-SUFFIX,githubusercontent.com,開発用
  - DOMAIN-SUFFIX,githubassets.com,開発用
  - DOMAIN,registry.npmjs.org,開発用
  - DOMAIN-SUFFIX,npmjs.org,開発用
  - DOMAIN-SUFFIX,docker.io,開発用
  - DOMAIN,auth.docker.io,開発用
  - MATCH,DIRECT

この例の最後にある MATCH,DIRECT は、他のルールに一致しない通信を直接接続する設定です。既存の設定にある末尾ルールを置き換える必要はありません。まず既存の rules の順序と最終ルールを確認し、該当するサービスのルールを適切な位置に追加してください。ノードの利用を制限する環境では、未一致通信のポリシーを DIRECT にすることが適切でない場合もあります。

ルールセットは対象が増えてから導入する

ルールが少ないうちは、設定内に直接記述した方が変更内容を追いやすくなります。サービスごとのドメイン一覧を別ファイルに分けたい場合は、mihomoの rule-providers を使えます。設定本体から一覧を参照できるため、ルールの数が増えたときや、用途別に更新したいときに便利です。一方で、取得URL、ファイル形式、参照名、更新状態という確認項目も増えます。コアが rule-providers に対応していることを先に確認してください。

動作確認の手順：小さなルールから追加し、ログで通信先を照合する

設定を一度に大きく変更すると、YAMLの解析エラー、参照名の不一致、接続先の見落としのどれが原因か判別しにくくなります。既存ファイルを複製して戻せる状態にし、まずGitHubなど一つのサービスから確認しましょう。以下の例はmihomo向けの構成例です。rules.example.invalid は説明用の予約ドメインであり、実際のルールファイル配布元ではありません。利用する場合は、信頼できる配布元のHTTPS URLと、対応するルールファイルに置き換えてください。

クライアントの設定管理画面で現在有効な設定を確認し、編集前のYAMLを別名で保存します。サブスクリプション管理型のクライアントでは、購読元の更新で直接編集した内容が上書きされることがあります。上書き設定やマージ機能がある場合は、その仕組みも確認してください。
まず 開発用 グループが存在するか調べます。ルールのポリシー名は大文字・小文字を含め、定義済みの名前と一致している必要があります。グループの選択先も確認し、利用するノードが応答することを先に確かめます。
GitHubのドメインルールを一つ追加して設定を再読み込みします。YAMLの解析エラーが出たら、インデント、カンマ、グループ名を確認します。タブを使わず、既存の rules: の配下に同じ階層で追加してください。
クライアントの接続ログを開き、対象ホストへの新しい接続を発生させます。ログに表示されたホスト名、適用ルール、選択されたポリシーを照合します。ルール名が一致していても、実際の接続が別のホストに向かっていれば、そのホストのルールは別途検討が必要です。
GitHubで経路が確認できたら、npmのパッケージ取得、Dockerイメージの取得を個別に試します。各コマンドの成功・失敗時刻と、同じ時刻の接続ログを記録し、必要なドメインだけを追加します。最後に設定を保存し、ルールセットを使う場合は取得状態も確認します。

ルールセットを試す場合は、次のような構造になります。path はルールセットの保存先を指定する例で、実際の相対パスの解決方法はクライアントの設定配置に依存することがあります。format: yaml と behavior: domain は、取得するファイルの形式・ルール種別に合わせて指定します。例のポリシー名は前節と同じく、既存のグループに合わせてください。

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

rules:
  - RULE-SET,github,開発用
  - MATCH,DIRECT

この例ではルールプロバイダーを1日ごとに更新する指定にしています。これは例示の間隔であり、全てのルール配布元に適した値ではありません。プロバイダー側の更新頻度や運用条件を確認してください。参照するルールファイルがYAML形式なら、domain型の例として payload にドメインを並べます。

payload:
  - '+.github.com'
  - '+.githubusercontent.com'
  - '+.githubassets.com'

RULE-SET,github,開発用 は、プロバイダー名 github に一致するルールを使って、通信を 開発用 に送る指定です。プロバイダー宣言の名前とルール内の参照名が一致しないと、意図したセットを利用できません。設定を読み込んだ後は、コアやクライアントのログでルールファイルの取得・解析に失敗していないかも確認しましょう。

遅延や失敗を切り分ける：ルール、プロキシ、DNSを別々に見る

「接続が遅い」という症状だけでは、Clashのルールが原因とは限りません。ログで対象通信がどのルールに一致したかを見て、次に選択されたグループとノードを確認してください。想定したルールに一致しているのに遅い場合は、別ノードで比較し、プロキシサーバーまでの到達性やサーバー側の状態を調べます。想定外のポリシーが選ばれている場合は、先行するルール、ルールの順序、グループ名を点検します。

ルールが表示されない：接続先が別のホスト名か、アプリがキャッシュ済み接続を再利用していないかを確認します。アプリを再起動してから再試行し、ログの時刻と操作を合わせてください。
想定と異なるグループになる：より上にあるルールが先に一致している可能性があります。ドメインルールを後方の広いルールより前へ移動し、重複するルールを整理します。
ルールセットを読み込めない：URLへのアクセス、HTTPレスポンス、YAMLの構造、保存先の書き込み権限、参照名を順に確認します。取得元が認証を必要とする場合、コアがその方式で取得できるかも確認が必要です。
ホスト名では一致するが接続に失敗する：選択したノードの状態、DNS解決、証明書や認証、対象サービス側の応答を調べます。ルールが正しく選ばれたことは、接続先まで到達したことを意味しません。
Dockerだけ失敗する：イメージ取得時のログを追い、認証、レジストリ、レイヤー配布それぞれの接続先を確認します。Dockerデーモンは、ターミナルのシェル環境変数をそのまま引き継ぐとは限りません。

コマンドラインツールがClashのローカルHTTPプロキシを直接使う場合、例えばローカルポートが 7890 の構成では、ツール側に HTTP_PROXY や HTTPS_PROXY を設定する方法があります。ただし、ポート番号は設定例にすぎず、実際のクライアント設定に合わせてください。ターミナルのcurlで成功しても、DockerデーモンやGUIアプリが同じ経路を使っているとは限りません。各プロセスがどのプロキシ設定を参照するかを分けて確認します。

TUNモードは、システムプロキシ設定を参照しないアプリの通信を取り込む選択肢です。しかし、TUNを有効にしても誤ったルールや到達不能なノードが自動で修正されるわけではありません。まず、コマンドラインツールが利用できるローカルプロキシ設定で切り分け、それでも対象アプリの通信がログに現れない場合に、クライアント、OS、ネットワーク権限に応じてTUNを検討してください。

ルールセットを安全に保つ：更新、範囲、ロールバックを管理する

ルールセットを使う場合、URLの安定性とルールファイルの内容を継続して確認します。配布元が停止したり、ファイル形式が変わったりすると、更新に失敗して古いルールが残る可能性があります。設定を変更した後は、少なくともプロバイダーの取得結果、ルール数、対象サービスの接続ログを確認してください。更新時刻だけでなく、最後に正常取得できた状態が分かるように記録しておくと、問題発生時に比較しやすくなります。

公開ルールセットを使うときは、内容を確認せずに広い範囲を適用しないでください。意図しないドメインが追加されると、社内サービスやローカルネットワークまでプロキシ経由になることがあります。自分で管理するルールファイルでは、更新履歴を残し、変更後に設定の解析と代表的な接続テストを行います。サブスクリプションのYAMLを直接変更する場合は、再購読で変更が消えないよう、クライアントの上書き機能や管理方法も確認してください。

最終的な構成は、管理しやすさと必要な範囲のバランスで決めます。数個の例外なら直接記述、サービス別の一覧を継続更新するなら rule-providers が向いています。ルールを追加するたびに対象サービスで実際の接続を試し、意図したポリシーが選択されることを確認してください。遅延が残る場合は、ルールの一致、ノードの応答、DNS、アプリやDockerデーモンのプロキシ設定を分けて調べることが、遠回りに見えても確実な切り分けになります。