📖 チュートリアル ⏱ 約15分で読めます

2026 開発者必携：Clash の分流ルールで Cursor と GitHub を快適にする実測ステップ

「Cursor の補完が遅い」「GitHub の clone／API が不安定」といった開発者ネットワークの悩みは、ブラウザの全トラフィックをいっしょくたにプロキシするより、Clash の分流ルールで必要なホストだけを選ぶ方が速く整います。本稿では、どのドメインやプロセスをプロキシに回し、どこを直結（DIRECT）に残すかの考え方、最小のルール例、そしてログで実測する手順までを、再現できる形でまとめます。クライアントの画面名はビルドで多少異なりますが、Mihomo（Clash Meta）系の考え方は共通です。

なぜ「開発者向け」に分流が効くのか

日常的に触れる経路は、(1) 社内や国内向けの低遅延・直結の方がよい通信と、(2) 海外 API やレジストリ、ホスティングに向かう安定ルートが欲しい通信が混ざります。VPN のように端末全体を一本のトンネルに載せる方式だと、不要な経路まで遠回りになりがちです。一方、Clash はルールで出口を分岐できるため、「GitHub の git 操作と REST はこのプロキシグループ」「社内 Git は DIRECT」のように、目的ごとに最適な経路を選べます。

用語のつながりは チュートリアルページ で一度押さえておくと読みやすくなります。ルールの書き方の骨格は カスタムルールの解説、グループの型は proxy-groups のガイド とセットで参照してください。

前提：proxy-groups を用途別に分けておく

分流を読みやすくするコツは、まず proxy-groups に意味のある名前を付けることです。例として、(A) 普段使いの自動選択グループ、(B) 低遅延を優先する url-test、(C) 手動で地域を選ぶ select、のように分け、rules の最後の列には実ノード名ではなくグループ名を書きます。こうしておくと、「GitHub だけ (B) に送る」といった追記が短く保てます。

💡 ヒント 購読テンプレがすでに PROXY や ♻️ 自動選択 のようなグループを用意している場合は、その名前に合わせるか、自分用のグループを追加してからルール側を合わせてください。綴りの不一致は最も多いミスです。

GitHub まわり：まず押さえるドメインの考え方

GitHub の利用範囲は広く、Web の閲覧、git の HTTPS／SSH、REST／GraphQL API、リリース資産や raw の取得など、接続先ホストが分かれます。代表的には github.com、api.github.com、*.githubusercontent.com、github.io（GitHub Pages）、オブジェクトストレージ系のホスト名などが挙がります。環境によっては企業プロキシや DNS フィルタが絡むため、この記事のドメイン例は出発点と捉え、実際には後述のログで自分のマシンが向いているホスト名を確認してください。

方針として、(1) 国内 CDN や同一リージョンに近い経路の方が速いホストは DIRECT を試し、(2) 不安定な海外経路を安定ノードで吸収したいホストはプロキシグループへ、と分けるのが現実的です。すべてを「海外ノード一択」にすると、かえって遅くなるケースもあるため、計測しながら調整します。

rules:
  # Example: tune group names (DevProxy, DIRECT) to your profile
  - DOMAIN-SUFFIX,github.com,DevProxy
  - DOMAIN-SUFFIX,githubusercontent.com,DevProxy
  - DOMAIN,api.github.com,DevProxy

上記はイメージです。RULE-SET で公開リストを読み込み、自分の例外だけを短く足す運用も有効です。順序の勘所は カスタムルール記事 のとおり、上から先にマッチした行が勝ちです。

Cursor（AI エディタ）側：ドメインとプロセスで寄せる

Cursor はエディタ本体に加え、補完やチャットのためにHTTPS で外部エンドポイントへ接続します。公開ドメインはアップデートで変わり得るため、ここでは「よく見かける系統」として cursor.com や cursor.sh、証明書の都合でサブドメインが増えるケースがある、程度の粒度に留めます。確実なのは、一度通常利用をしたうえで、Clash の接続ログに出たホスト名をルールに反映することです。

プロセス単位で振り分けたい場合は、OS ごとに PROCESS-NAME の書き方が異なります。Windows では実行ファイル名（例: Cursor.exe）、macOS ではバンドル配下の実行体名がログに出ます。ログに出た表記と一字一句合わせるのがコツです。システムプロキシを無視する通信がある場合は、TUN モード とセットで検討します。

rules:
  # Verify process names in your client logs (examples only)
  - PROCESS-NAME,Cursor.exe,DevProxy
  - DOMAIN-SUFFIX,cursor.com,DevProxy
  - DOMAIN-SUFFIX,cursor.sh,DevProxy
⚠️ 注意 Copilot や他社の拡張が別ホストへ出る場合、Cursor 本体のルールだけでは足りません。症状ごとにログの宛先を足し込むのが安全です。

「全トラフィック」を避けるための最小構成の考え方

分流の目的は、必要な通信だけをプロキシに載せ、それ以外は既定の DIRECT や軽い経路に残すことです。やみくもに巨大な RULE-SET を何本も重ねると、評価コストや意図しないマッチが増えます。現実的な手順は、(1) 購読のデフォルトを土台にする、(2) GitHub／Cursor 向けの短いカスタムブロックを先頭付近に置く、(3) 動かないときはログで「どの行に当たったか」を見る、の三段です。

DNS まわりで詰まる場合、ルール以前に名前解決が失敗していることがあります。プロファイルの dns ブロックは購読テンプレの推奨に寄せ、いじりすぎない方がトラブルが少ないことが多いです。HTTPS の SNI や DoH の挙動は環境差が大きいので、変更は一つずつ試します。

実測の手順：ログで「宛先」と「採用ルール」を確認する

  1. 1

    ベースラインを取る

    Clash をオフ、または最小ルールのプロファイルで、Cursor から補完を一度走らせ、GitHub で git fetch や API 呼び出しを試します。遅延や失敗が再現するかを記録します。

  2. 2

    ログに出るホスト名をメモする

    クライアントの接続ログ／コアログで、実際に接続しようとしているドメインと、マッチしたルール名（またはポリシー）を確認します。ここで初めて「ルールが足りない」「順序が吸われている」が判明します。

  3. 3

    一行ずつ追加して再計測

    DOMAIN-SUFFIX や PROCESS-NAME を追加したら、同じ操作を繰り返し、遅延とエラー率の変化を見ます。一度に大量変更すると切り分けが難しくなります。

この繰り返しが「実測」です。検索記事に載っているドメイン表は参考程度にし、自分のログが正という姿勢で守ると、バージョンアップにも強いです。

よくある質問

SSH（[email protected]）もルールで制御できる？

多くの場合、SSH はドメインとは別の経路・ポートになり、クライアントやコアの対応するルール型が必要です。HTTPS に切り替えて試す、SSH だけ別のプロキシチェーンを使う、など運用で分けることもあります。ログに出る実接続に合わせて設計してください。

最小ルールなのに遅い

ルール枚数より、ノード品質・輻輳・DNS・TLS の往復の影響が大きいことが多いです。別ノードや別プロトコル、DNS のみ変更したときの差分を見ると原因が絞れます。

会社のセキュリティポリシーと衝突しない？

社内規程でプロキシや検査が必須の場合、クライアント側の迂回は禁止されていることがあります。技術的に可能でも、コンプライアンスを優先し、情報システム部門の案内に従ってください。

まとめ

開発者の生産性は、エディタの快適さとリポジトリ／API の安定性に直結します。Clash の分流は、その両方に対して必要最小限の経路だけを選び直すための手段です。ホスト名は時代とクライアントの更新で変わり得るため、本稿のドメイン例は出発点として捉え、ログに基づくメンテを続けるのが実用的です。

ルール設計の基礎を固めたうえで、安定したビルドを試すなら、パッケージの入手先は 本サイトのダウンロードページ を第一にすると、記事やバージョンの対応関係も追いやすくなります。トンネル型 VPN との違いを整理したい場合は Clash と VPN の比較記事 も参考になります。

→ Clash を無料ダウンロードし、開発環境向けの分流を試す