2026 年版：Clash で Cursor IDE の拡張マーケットと AI モデルリクエストを分流する実務手順

なぜ「ブラウザは速いのに Cursor だけ不安定」になりやすいのか

2026 年も、Cursor IDE は VS Code 系の体験を土台にしつつ、組み込みの生成 AI・エージェント・タブ補完など、エディタ外のバックエンドへ継続的に接続します。開発者コミュニティでは、拡張機能マーケットの検索やインストール、クライアント本体の更新取得が遅い・失敗する一方で、普通のブラウジングは問題ない——といった切り分け相談がよく見られます。原因の多くは「単一ノードの品質」だけではなく、API ドメインとCDN／マーケットプレイスが別経路・別要件（ストリーミングや HTTP/2）を持つこと、そしてローカルの DNS やルール評価順が噛み合っていないことにあります。

本稿は、単一プロダクト（ChatGPT や Claude など）に絞った既存の分流記事とは役割を分け、開発ツールチェーン全体として Cursor を安定させる観点でまとめます。具体的には、Cursor の公式ドキュメントやセキュリティページで案内されている接続先（*.cursor.sh、*.cursorapi.com、*.cursor-cdn.com など）を、拡張・更新まわりとモデル／チャット API まわりの二系統に分け、Clash の分流（用途別プロキシグループ）へ落とし込む手順です。ドメイン構成は変更され得るため、最終判断は必ず公式のネットワーク設定ドキュメントと、ご自身の環境でキャプチャしたホスト名を優先してください。

ChatGPT 単体の分流記事との違い（ツールチェーン視点）

当サイトではすでに ChatGPT／Claude 向けの分流ガイドや、Google・xAI 系の記事を公開しています。それらが「特定の生成 AI サービスへのアクセス」を主題にするのに対し、Cursor IDE は次のような複数役割が同時に走るアプリです。(1) エディタ本体と拡張の取得・更新、(2) 認証まわり、(3) コードベース索引やタブ補完など低遅延が求められる API、(4) エージェントや長めのストリーム。いずれも別ホストに分散しやすく、1 本の「AI 用プロキシ」ルールだけでは片方だけタイムアウトという形に偏りがちです。

そこで本稿では、まずマーケット／CDN／ダウンロード系を CURSOR_EXT（仮称）のような独立プロキシグループへ、続いて api2.cursor.sh などのモデルリクエスト系を CURSOR_AI へ、という二段構成を推奨します。実務では名前は既存のグループと衝突しない任意のラベルで構いません。ポイントは「帯域を食う更新トラフィック」と「細かく張り直すストリーム」を同じ出口に無理に載せないことです。

公式情報を起点にしたドメインの束ね方

Cursor のトラブルシューティングおよびエンタープライズ向けネットワーク資料では、ファイアウォールやプロキシの許可リストとして、少なくとも *.cursor.sh、*.cursor-cdn.com、*.cursorapi.com（marketplace.cursorapi.com を含む）が挙げられています。セキュリティ／インフラの説明では、api2.cursor.sh をはじめとする API ホスト、repo42.cursor.sh のような索引系、地域別のタブ用ホストなど、用途別の名前も確認できます。また拡張マーケットや更新には downloads.cursor.com や CDN 名が絡むことがあります。

Clash 側では、まず DOMAIN-SUFFIX,cursor.sh や DOMAIN-SUFFIX,cursorapi.com、DOMAIN-SUFFIX,cursor-cdn.com をルールに載せられるか検討します。ただし cursor.sh を丸ごと一つの遅いノードに固定すると、マーケットの静的取得まで同じ出口に乗り、体感が重くなることがあります。そこで実務では、(A) marketplace.cursorapi.com、downloads.cursor.com、cursor-cdn.com を「拡張・更新グループ」へ、(B) api2.cursor.sh、api3.cursor.sh、api5.cursor.sh などストリーム主体を「AI 会話グループ」へ、と細かく始めてログで調整するのが扱いやすいです。ホスト名はバージョンで増減し得るため、開発者ツールのネットワークタブや Cursor 設定内の接続診断と突き合わせてください。

プロキシグループの切り方（概念）

CURSOR_EXT は、拡張の検索結果やアイコン画像、更新パッケージの取得など、比較的大きなオブジェクトや CDN 経由が多いトラフィック向けです。ここは「帯域が太く安定しているノード」や、地理的に CDN エッジに近い地域を選ぶと失敗が減りやすいです。一方 CURSOR_AI は、チャットやエージェントのストリーミング、タブ補完など、遅延と切断耐性が重要なトラフィック向けです。公式文書でも、一部の企業プロキシが HTTP/2 の双方向ストリームをバッファしてしまい、応答が遅れる事例が説明されています。Clash の外側に別の HTTPS インスペクションがある場合は、まずそちらの例外設定や HTTP/1.1 フォールバックの可否を確認する価値があります。

どちらのグループも url-test や fallback を併用し、ダッシュボードから遅延テストを定期的に叩く運用にすると、長期利用で出口が劣化したときの切り替えが速くなります。国内直結と海外プロキシが混在するプロファイルでは、誤って国内ルールに飲み込まれていないかもあわせて確認してください。

ルール評価順序：巨大 RULE-SET に埋もれないようにする

Clash の rules: は上から順に評価され、最初の一致で終わります。Cursor 向けの行を末尾に追記したつもりが、上段の GEOIP やサードパーティの RULE-SET に先にマッチしている——というのは典型的なミスです。分流を効かせるには、より具体的な DOMAIN 行を、大雑把な締め行より上に置きます。GUI でルールを追加するときは、挿入位置が先頭か末尾かで結果が変わるため、保存後に必ず順序を目視してください。

ルールの書き方の共通枠組みは、ルール分岐の詳解ガイドと同じです。外部プロバイダーのルールを大量に読み込んでいる場合は、Cursor 用の明示ルールが「十分に上」にあるかを重点的に確認するとよいでしょう。

YAML の骨格例（サンプル）

実際のキーやインデントは、利用中のコアと GUI のスキーマに合わせてください。ここでは二つのグループを定義し、代表的なサフィックスを振り分けるイメージだけ示します。

proxy-groups:
  - name: CURSOR_EXT
    type: select
    proxies:
      - 🇯🇵 CDN 近傍
      - 🇸🇬 安定
      - 🌐 自動選択
  - name: CURSOR_AI
    type: select
    proxies:
      - 🇺🇸 低遅延
      - 🇯🇵 低遅延
      - 🌐 自動選択

rules:
  - DOMAIN-SUFFIX,marketplace.cursorapi.com,CURSOR_EXT
  - DOMAIN-SUFFIX,cursor-cdn.com,CURSOR_EXT
  - DOMAIN-SUFFIX,downloads.cursor.com,CURSOR_EXT
  - DOMAIN-SUFFIX,cursor.sh,CURSOR_AI
  - DOMAIN-SUFFIX,cursorapi.com,CURSOR_EXT

上記はあくまで出発点です。cursorapi.com を拡張側に寄せるか、一部を AI 側へ分離するかは、実際の接続ログを見ながら調整してください。サフィックスを広げすぎると他サービスまで巻き込むため、まずは公式リストとキャプログで必要最小限から始めるのが安全です。

DNS と Fake-IP：名前解決の経路を一本化する

ルールはドメイン行と IP 行が混在します。DNS が Clash の想定とズレていると、YAML は正しそうでも実接続は別経路に落ちます。OS やブラウザの Secure DNS が Clash の外で先に解決したり、Fake-IP と一部アプリのシステム DNS が混在したりすると、ダッシュボード上のマッチと体感が一致しにくくなります。Cursor IDE は Electron 系の通信が多く、VPN 切断後に DNS が残像のように残る事例も公式トラブルシューティングで言及されています。

対策の方向性は、(1) 名前解決の経路をできるだけ一本化する、(2) TUN やシステムプロキシを併用するなら、その前提でルールを読む、(3) 変更後は OS の DNS キャッシュとアプリの完全再起動をセットで行う、の三点です。手順の全体像は TUN モード完全ガイドの DNS の節が参考になります。

遅延テストと切り分けの実務手順

まず Cursor 設定のネットワーク診断（公式 UI から実行できる接続テスト）を通し、どの段で失敗するかを大枠で把握します。次に Clash クライアントの接続ログで、拡張マーケット操作時とチャット利用時にそれぞれどのホストがどのプロキシグループに乗っているかを比較します。ここで別グループに分かれていない場合は、ルール順かサフィックスの漏れを疑ってください。

ノード選定は、同じ購読内で地域だけを切り替えて A/B するのが素早いです。API ドメイン側だけ遅い場合は、ストリームに厳しい中継機器の影響も疑い、HTTP/2 を透過できる経路かを確認します。逆に CDN 側だけ失敗する場合は、別地域のエッジに切り替わるよう出口を変えると改善することがあります。

VS Code マーケットプレイスを併用する場合

コミュニティでは、拡張ギャラリーのエンドポイントを Visual Studio のマーケットプレイス側へ寄せる設定例も見かけます。運用ポリシーや利用規約に反しない範囲で試す場合でも、Cursor 本体の更新や組み込み AI は引き続き Cursor 側のホストへ向かうため、本稿の二系統分流の考え方は有効です。marketplace.visualstudio.com などを追加するなら、その行をどのプロキシグループへ載せるかを明示し、既存の巨大ルールセットより上に置いてください。

チェックリスト（そのまま試せる順）

1. 公式ドキュメントの許可リストと、Cursor の接続診断結果を突き合わせ、足りないサフィックスをメモする
2. CURSOR_EXT と CURSOR_AI（仮称）を定義し、DOMAIN-SUFFIX 行をルール上部付近へ配置する
3. 拡張の検索・インストールを実行し、ログで marketplace.cursorapi.com や CDN が意図したグループへ流れているか確認する
4. チャットやタブ補完を実行し、api2.cursor.sh 等が AI 側グループへ流れているか確認する
5. DNS（Secure DNS、Fake-IP、VPN 切断後の残り）を整理し、必要なら TUN とセットで再検証する
6. 企業ネットワークでは HTTP/2 バッファリングや SSL インスペクションを疑い、公式の互換設定や除外ポリシーを検討する

よくある誤解

すべてを一つの「海外プロキシ」に載せる

設定は簡単ですが、更新やマーケットの大きな転送がチャットのストリームと帯域を奪い合い、タイムアウトが出やすくなります。用途別グループに分けるだけで改善するケースは少なくありません。

ルールを足したのに効かない＝バグだと決めつける

多くは評価順序かDNSです。外部 RULE-SET が先に当たっていないか、ドメインルールより GEOIP が優先されていないかを再確認してください。

ChatGPT 向けルールが通れば Cursor も必ず通る

ホスト設計が異なります。OpenAI 系のルールが完璧でも、Cursor 固有の cursor.sh や cursorapi.com が抜けていれば再現します。本稿のように IDE 単体のリストを持つ価値があります。

まとめ

2026 年の開発環境では、Cursor IDE が触るホストは「拡張・更新・CDN」と「モデル／索引などの API」に分かれやすく、単一路由では片方だけ不安定になりがちです。公式が案内する *.cursor.sh、*.cursorapi.com、*.cursor-cdn.com などを起点に、Clash で独立プロキシグループへ分流し、ルール順序とDNS、必要に応じて HTTP/2 互換の観点までセットで見ると、「ブラウザは速いのにエディタだけおかしい」系の切り分けがかなり楽になります。ドメインは将来変更され得るため、キャプチャと公式資料の併用を忘れないでください。

用語や汎用手順は当サイトのチュートリアル・ドキュメントも参照できます。クライアントの入手と更新は、リリースノートや配布物がまとまっているダウンロードページから行うと取り違えが少ないです。ルールの基礎はルール分岐の詳解、OS 全体へ透過的に効かせたい場合はTUN ガイドと併読すると、本稿の設定がすぐ実装に落ちます。単純な常時 VPN より、トラフィックを用途別に制御できる点が、多くのチームにとって実用的な体験になりやすいでしょう。→ Clash クライアントを無料でダウンロードし、Cursor 向け分流を試す