AI 開発スタックが「急に遅い」とき、最初に疑う層

Cursor のような AI 統合型エディタや、従来の Visual Studio Code 系ワークフローは、単一アプリに見えても裏側では複数の通信が重なります。本体の更新チェック、拡張機能マーケット（Microsoft 側のマーケットプレイスや Open VSX などの取得元）、GitHub 上のリポジトリや Git LFS、認証まわりの OAuth、企業ポリシー下では社内プロキシとの二重化、さらに AI 補完やチャット系機能が追加のホストへ飛ぶ、といった具合です。

ここで問題になりやすいのが、家庭やモバイル回線では「とりあえず全部プロキシ」「職場では全部直結」など、経路が粗いまま固定されている状態です。海外 CDN が遅い回線では直結がタイムアウトし、逆に国内向けに最適化されたノード経由だと TLS の終端や SNI の扱い、あるいは単純な RTT の積み上げで API が失敗する、という両極が起きます。Clash／Mihomo の強みは、これをルールエンジンで細かく切り替えられる点にあります。

本稿は正当な開発用途と、利用規約・職場ポリシー・各国の法令を順守する前提で書いています。ルール例のドメインは一般的な公開情報に基づくものであり、サービス側の変更で入れ替わり得るため、実運用ではログとドキュメントで都度確認してください。ルールセットの外部取り込みや更新間隔の設計は Rule Provider の上級ガイド と相性がよく、併読すると保守性まで含めて設計しやすくなります。

よくある症状：タイムアウト、拡張が入らない、Git 操作だけ不安定

典型的には次のような「部分不通」です。ブラウザでは一般サイトが速いのに、IDE の拡張検索だけぐるぐる回る。git push や GitHub の API ベース操作だけが稀に失敗する。Copilot や同等の補完がオンライン確認でコケる。Cursor の更新通知は出るのに、ダウンロードが途中で切れる。これらは単一の原因ではなく、ホストごとに最適経路が違うことが多い、というサインです。

切り分けの第一歩は、同じマシンでブラウザから該当ドメインへ直接アクセスできるか、社内 DNS が特定レコードを書き換えていないか、別セキュリティ製品が HTTPS を検査しているか、を確認することです。そのうえで Clash 側では、どのルール行にマッチしたかをログで追い、意図しない DIRECT や遅い Proxy に落ちていないかを見ます。DNS モードが fake-ip のときは、ドメインルールと IP ルールの見え方が変わる点に注意が必要で、DNS まわりの高速化記事 とセットで読むと整理が速いです。

分流設計の骨格：直結・本線プロキシ・開発専用グループを分ける

実務で破綻しにくいのは、プロキシグループを用途別に分けるパターンです。例えば PROXY を一般ブラウジング用、DEV_PROXY を低遅延かつ安定した出口に固定、AUTO を url-test／fallback による自動選択、といった具合です。GitHub の API や大きな成果物取得は DEV_PROXY、社内イントラや銀行サイトは DIRECT、というように失敗時の影響範囲が読める割り当てにします。

同時に、ルールの評価順が本体です。Clash 系は上から順に見て、最初にヒットした行で確定します。巨大なサードパーティ RULE-SET を先頭に置くと、そこで吸い尽くされて細かい例外が永遠に評価されない、という事故が起きがちです。現実的な並べ方は、（1）LAN／ローカル／社内ドメインの直結、（2）開発ツール向けに明示したドメインサフィックス、（3）プロセス名ルール（利用可能な場合）、（4）カテゴリ別 RULE-SET、（5）GEOIP や MATCH のフォールバック、の順が考えやすいです。詳しい RULE-SET の扱いは先述の Rule Provider 記事を参照ください。

まず押さえたいドメインの束（GitHub／マーケット／取得元）

開発者が毎日さわる層として、次のようなホスト名がよく登場します（完全な網羅ではありません）。github.com 本体、api.github.com、raw.githubusercontent.com、objects.githubusercontent.com、認証や付帯で githubusercontent.com 系。VS Code 互換エディタの拡張取得では marketplace.visualstudio.com や関連 CDN、Open VSX を使う構成なら open-vsx.org とその配下。パッケージレジストリや言語エコシステムのホストは言語ごとに増えるため、失敗した URL をログから拾ってルールに足す運用が現実的です。

Cursor 本体に特有のホスト名はプロダクトの更新サイクルで変わり得ます。設定のコツは、「公式ドキュメントやリリースノートで明示されたドメイン」を優先し、未知のホストはいったん広めのサフィックスで DEV_PROXY に寄せ、ログで過剰マッチがないかを後から絞り込むことです。いきなり過度に広いワイルドカードを増やすと、意図しないトラフィックまで海外出口に流れ、逆に遅くなることがあります。

設定イメージ：DOMAIN-SUFFIX と専用プロキシグループ

下記は理解を助けるためのスケルトン例です。グループ名やノード名は自分の購読に合わせて置き換えてください。実機ではコアのバージョンとクライアントの互換性を確認し、未対応の行は削ってください。

proxy-groups:
  - name: DEV_PROXY
    type: select
    proxies:
      - あなたの低遅延ノード
      - PROXY

rules:
  # High-priority: intranet and localhost stay direct
  - IP-CIDR,127.0.0.0/8,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT

  # Developer SaaS: send to dedicated group
  - DOMAIN-SUFFIX,github.com,DEV_PROXY
  - DOMAIN-SUFFIX,githubusercontent.com,DEV_PROXY
  - DOMAIN-SUFFIX,githubassets.com,DEV_PROXY
  - DOMAIN-SUFFIX,marketplace.visualstudio.com,DEV_PROXY
  - DOMAIN-SUFFIX,open-vsx.org,DEV_PROXY

  # Fallback to your subscription rulesets below ...
  - MATCH,PROXY

この例のポイントは、GitHub 系をまとめて DEV_PROXY に寄せ、一般トラフィック用の PROXY や巨大 RULE-SET より上に置くことです。国内から直結が速いホストを無理にプロキシに送ると遅くなるため、自宅／職場ごとに DIRECT 行を差し込むか、別リストに分けて A／B テストするのが安全です。

PROCESS-NAME（プロセス指定）は「追い風」であり銀の弾ではない

Mihomo／Clash Meta 系では、OS によって PROCESS-NAME や類似のプロセスベース条件が使える場合があります。例えば Windows では実行ファイル名、macOS ではバイナリ名の表記に注意が必要で、GUI ラッパ経由だと想定と異なる名前になることもあります。プロセスルールは「特定アプリの通信をまとめて開発用出口に流す」用途に便利ですが、すべての接続に名前が付くわけではない、権限やサンドボックスで取れない場合がある、という制約も併記しておきます。

運用上は、まずドメインルールで八割決め、残りの取りこぼしだけをプロセス側で補うほうがデバッグしやすいです。プロセス行を先頭に大量配置すると、意図しないアプリまで開発出口に吸い込むリスクが上がるため、範囲を狭く保ち、変更は一つずつ試すのがよいでしょう。

TUN／システムプロキシと IDE の取り合い

IDE によっては独自にプロキシ設定を持ち、OS のシステムプロキシとは別ルートを歩みます。Clash 側を TUN で全体捕捉している場合は、その差が表面化しにくい反面、ルートや DNS の競合で「他は動くのに IDE だけおかしい」ことが起きます。Windows での TUN と Wintun の典型的なつまずきは Windows TUN のトラブルシュート記事 にまとめています。

GUI 利用者は、アプリ内の YAML エディタとログビューアの導線が重要です。画面操作の全体像は Clash Verge Rev ガイド が参考になります。用語の一次情報は 公式ドキュメント を当たり、設定名のズレを減らすのが近道です。

まだタイムアウトするときの短いチェックリスト

  • 失敗したホスト名をログから特定し、想定グループにマッチしているか
  • 上位ルールに吸われていないか（巨大 RULE-SET の位置を疑う）
  • DNS が社内 DNS／DoH の二重指定になっていないか
  • セキュリティ製品の HTTPS 検査で証明書エラーが紛れ込んでいないか
  • IPv6 だけ別経路になっていないか
  • 同一ホストでもパスによって別ドメインへリダイレクトされていないか
覚えておきたいこと：開発ツールのタイムアウトは「プロキシが弱い」だけでなく、ルール順・DNS・IPv6・HTTPS 検査の複合現象であることが多いです。一度に全部を変更せず、ログでマッチ行を確定させてから手を入れるのが安全です。

まとめ

Cursor／GitHub を中心とした AI 開発スタックは、更新・拡張・API・付帯サービスが短い時間に多数のホストへ散らばるため、一律の経路固定ではタイムアウトが残りやすいタイプのワークロードです。Mihomo（Clash Meta）世代のルールでは、ドメイン単位の明示行を適切な高さに置き、必要ならプロセス条件で補強し、DNS や TUN といった下位層の競合を別枠で潰す、という段階的なほうが安定します。

ルールは増やしすぎると評価コストや人的ミスも増えるため、外部 RULE-SET と自作の短い「開発用リスト」を組み合わせ、ログで継続的に薄く保つのが長期運用のコツです。一覧の他記事は 技術ブログ から辿れます。→ Clash を無料ダウンロードし、開発者向けの分流ルールを試す

コアのソースや議論は各プロジェクトの GitHub で追えますが、日々のクライアント入手は検証済みパッケージへ誘導されている公式ダウンロード導線の方が、構成ファイルとバイナリの組み合わせを取り違えにくいです。