症状の整理:IDE だけ「接続中」のまま進まない
2026 年現在も検索クエリに乗りやすいのが、Cursor(VS Code 系の AI コーディング IDE)を起動したあと、ステータスやチャット欄が「接続中」「Connecting」の表示のまま変わらない、あるいはエディタ本体は動くのに拡張機能の一覧取得や更新だけがタイムアウトする、といったパターンです。ブラウザで生成 AI のページは閲覧できるのに IDE だけ詰まる、逆に IDE だけ別ノードを試したい——といった切り分けは、開発者の日常のネットワークトラブルとしてもよく聞かれます。
ここで重要なのは、Cursor が単一の「AI サイト」として振る舞うわけではなく、認証・チャット背後の API、拡張マーケットプレイス(Microsoft/Open VSX 等)、アプリ更新や Electron の裏側の取得など、ホスト名と TLS の向き先が異なる通信が束になっている点です。Clash/mihomo の分流ルールは、まさにそのホスト単位で出口を変える仕組みなので、IDE プロキシとしての設計をブラウザ向けの「汎用 AI サイト」だけに寄せると、一部だけ直結や意図しないノードに落ちて部分接続のままになることがあります。
Web 版 AI の分流記事との違い(ChatGPT/Grok 等)
当ブログでは、ブラウザで ChatGPT や Grok などの Web を安定させるための分流を、別記事で扱っています。そちらは「ドメインを RULE-SET でまとめ、AI 専用プロキシグループへ流す」という骨格が中心です。一方、Cursor のようなネイティブ IDE は、チャット機能のためにブラウザと同じ AI プロバイダの API ドメインを使う場合もあれば、エディタ本体の更新・テレメトリ・拡張の CDNがまったく別のサフィックスになる場合もあります。つまり「AI 用グループを一つ足せば万事解決」とは限らず、拡張マーケット プロキシや開発者向けのマーケットプレイス出口を別に切ったほうが運用しやすいケースがあります。
併せて読む場合は、AI サイト向け分流の記事を参照してください。本稿ではWeb ブラウザではなく IDE クライアントにフォーカスし、ルールの置き場所とログの見方を補います。
まず押さえる:通信の「種類」ごとにホストが分かれる
実務では、次のようなカテゴリに分けて頭の中の地図を作ると、Clash Cursor 向けの設定が迷いにくくなります。正確なホスト名はバージョンや地域で変わるため、必ず接続ログで実名を確認してください。
- エディタ/サービス本体:
cursor.comやcursor.sh系、API サブドメインなど。認証・課金・機能フラグとチャット背後がここに寄ることが多いです。 - 拡張の検索・インストール:Visual Studio Marketplace(
marketplace.visualstudio.comや関連 CDN)、Open VSX(open-vsx.org等)を使う構成があります。企業プロキシや地域ルートでここだけ詰まると「拡張マーケットだけ遅い」になります。 - 更新・バイナリ取得:GitHub Releases、Microsoft のストレージ、あるいはアプリ独自の更新ホスト。起動直後だけ遅い・バックグラウンドで失敗する症状と相関しやすいです。
- 生成 AI の API:モデル呼び出しが
api.openai.com等へ向かう場合、ブラウザ向け AI ルールと同一のグループに寄せるか、IDE 専用に別グループを切るかは運用次第です。
いずれも「サブスクの巨大ルールセットの MATCH 前に、自分の DOMAIN-SUFFIX を足す」という基本は同じです。記法の基礎は YAML・ルール分流の解説記事と対応します。
Cursor 側に「プロキシを使う/OS の設定に従う」などのオプションがある場合、二重にプロキシが掛かるとルールが混乱します。まずは OS のシステムプロキシと Clash の関係(TUN か HTTP ポートのみか)を一本化してから、ルールの当たりを見ます。
プロキシグループを「IDE」「マーケット」「更新」に分ける
おすすめは、日常ブラウジング用とは別に、例として次のような名前付きグループを用意することです(名前は任意)。
- CURSOR_APP:エディタ本体・サービス関連ドメイン。
- EXTENSION_MARKET:マーケットプレイスと CDN。拡張マーケット プロキシとして単独でノードを切り替えたいときに効きます。
- UPDATES:更新系。安定性優先で遅いが通るノードを選ぶ、などポリシーを分けます。
いずれも select 型にしておけば、挙動を見ながらそのグループだけ手早く差し替えられます。url-test にする場合は、IDE セッションが切れないよう切り替え頻度に注意します。
# Concept only — replace RULE-SET names/URLs with ones you trust; verify hostnames in your logs.
proxy-groups:
- name: CURSOR_APP
type: select
proxies:
- node-us-west
- node-sg
- DIRECT
- name: EXTENSION_MARKET
type: select
proxies:
- node-us-west
- DIRECT
- name: UPDATES
type: select
proxies:
- node-us-west
- DIRECT
rules:
- DOMAIN-SUFFIX,cursor.sh,CURSOR_APP
- DOMAIN-SUFFIX,cursor.com,CURSOR_APP
- DOMAIN-SUFFIX,marketplace.visualstudio.com,EXTENSION_MARKET
- DOMAIN-SUFFIX,open-vsx.org,EXTENSION_MARKET
# Place these above broad GEOIP / DIRECT / MATCH ...
- MATCH,PROXY
上記のドメインは例示です。実際のクライアントが接続するホストは、クライアントのバージョンや機能のオンオフで変わります。Clash のログで Matched や接続先を確認し、足りないサフィックスを追加してください。
DNS と Fake-IP:名前解決とルールを揃える
分流が効かない原因の多くは、ルール以前にDNS の経路と Fake-IP の例外にあります。IDE は短い間隔で多数の名前解決を行うため、nameserver-policy でマーケットプレイス系サフィックスだけ信頼できるリゾルバへ寄せる、といった整理が有効なことがあります。Fake-IP を使う構成では、fake-ip-filter にマーケット関連の名前が誤って含まれていないかも確認ポイントです。DNS の仕組み全般は ドキュメントの Fake-IP/DNS 解説で補完できます。
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- https://dns.example/dns-query
nameserver-policy:
# example: verify suffixes against your resolver policy
"+.marketplace.visualstudio.com": https://dns.example/dns-query
"+.open-vsx.org": https://dns.example/dns-query
TUN とシステムプロキシ:IDE がトラフィックをどこに出すか
Windows や macOS で Clash を TUN モードにしている場合、OS 全体のルーティングが変わるため、IDE も例外なくコアにトラフィックが集まりやすいです。一方、HTTP システムプロキシのみの場合、Electron アプリが「プロキシを無視する」設定を持っていると、ルールが効きません。症状が「他のアプリは通るが Cursor だけ詰まる」のときは、IDE 側のネットワーク設定と、Clash のモード(TUN/システムプロキシ)をセットで確認してください。TUN 周りのトラブルは Windows 向け TUN の切り分け記事も参照してください。
切り分けチェックリスト
- ログでホスト名を特定:接続中のままのとき、どのドメインが失敗・タイムアウトするかを確認する。
- ルールの順序:
GEOIPや広いDIRECTが先に当たっていないか。Cursor 用の行を上に。 - 拡張だけ遅い:
EXTENSION_MARKET相当のルールにマーケットと CDN のサフィックスが揃っているか。 - DNS:クエリがコアの設定どおりか、別クライアントが上書きしていないか。
- ノードの入れ替え:同じ地域表示でも別出口が安定するか試す。
- ブラウザ AI ルールとの重複:AI API 用のルールと IDE 用ルールを混同していないか。
利用規約・法令・雇用契約・社内セキュリティポリシーは環境ごとに異なります。本稿はネットワーク設定の一般的な説明であり、特定サービスの利用を推奨・保証するものではありません。
まとめ
Cursor のような AI IDE は、ブラウザで開く生成 AIとは異なり、エディタ本体・拡張マーケット・更新・AI APIが別々のホストへ伸びることが多いです。だからこそ開発者 分流では、Clash Cursor 向けにグループを分け、ログで実ホスト名を確認しながらルールを足すのが現実的です。IDE プロキシとしての出口と、拡張マーケット プロキシとしての出口を分けておくと、「接続中」がどのホスト由来か切り分けやすくなります。
安定したクライアントからルール検証を始めたい場合は、クライアントのダウンロードページで OS に合ったビルドを選ぶと手順が短くなります。オープンソースのリポジトリは挙動の理解に役立ちますが、実行ファイルの入手は配布ページを主な入口にすると、コアと UI の対応関係が追いやすいです。→ 無料で Clash をダウンロードし、IDE 向け分流の検証を始める