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

2026 年現在、Cursor のような AI 統合型エディタは、単なるローカルアプリではありません。VS Code 拡張マーケットプレイス相当の取得、エディタ本体や拡張の更新、そしてクラウド側のモデルや補完用 API への HTTPS 接続が常時発生します。ここで Clash 利用者がつまずく典型は、Chrome では快適なのに、IDE 内だけマーケットが開かない・ログインが完了しない・補完リクエストだけタイムアウトするというパターンです。

理由の多くは、アプリごとにシステムプロキシの尊重度が違うこと、接続先ホスト名がブラウザ利用時と別セットになること、そして DNS がコアの外で先に解決されてルールに届かないことの三つに集約できます。ブラウザを拡張プロキシで回している一方で、Electron アプリが直結しようとしている、といったズレも起こり得ます。根本からトラフィックを握りたい場合は TUN モードの解説 も参照してくださいが、本稿ではまずルール分流とDNSで大半をカバーする前提で進めます。

VS Code 系と Cursor で押さえたい代表的ドメイン

実際のホスト名はアップデートで増減しますが、切り分けの出発点として次を覚えておくとよいです。拡張の検索・取得では marketplace.visualstudio.com や *.gallery.vsassets.io、配信用 CDN として *.vscode-cdn.net などがよく現れます。Visual Studio Code 本体の更新では update.code.visualstudio.com や Microsoft のストレージ系ホストが絡むことがあります。

Cursor 本体の認証・AI 機能では cursor.com や *.cursor.sh、コミュニティで報告の多い api2.cursor.sh などへの HTTPS が目立ちます（サービス側の変更でホストが入れ替わるため、症状が出たら接続ログで実測し、ルールに追記する運用が現実的です）。GitHub 上の拡張リポジトリや Release を直接読みに行くケースでは github.com や *.githubusercontent.com も同時に必要になることがあります。

HTTPS トラフィックの「見え方」とルール設計

いまどきの IDE 通信の大半は TLS（HTTPS） です。Clash 側では、多くの場合 クライアントが接続しようとしているドメイン名（SNI）や、コアが握っている DNS 情報を手がかりにルールマッチが行われます。暗号化ペイロードの中身まで見る必要は通常なく、どのホスト名として出口を選ぶかが設計の中心です。

そのため「拡張が動かない」ときでも、まずは失敗している URL やホストを特定し、それがルール表のどこに吸われているかを確認します。広い GEOIP や最終 MATCH で意図せず DIRECT に落ちると、いわゆる漏れ代理としてタイムアウトや証明書まわりのエラーが出やすくなります。逆に、国内向け CDN まですべて海外ノードに流すと遅延だけが増えるので、IDE 用のドメイン集合だけを先段に置くのがバランス良いです。ルールタイプの詳細は ルール分流の詳解記事 と併読してください。

ポリシーグループとルール順（select / url-test）

ドメインがどのノードに行くかはルールで決まりますが、実際に選ばれる出口の集合はポリシーグループで定義されます。補完やチャットのように長めのストリーミング応答が絡む用途では、安定しているノードを手動固定する select が分かりやすいです。自動切替の url-test は便利ですが、間隔が短すぎると頻繁に張り直しが発生し、かえって IDE 側が「接続が切れた」ように感じることがあります。

運用上のコツは、「IDE／開発ツール」専用のポリシーグループ名を一つ決め、上記ドメイン系ルールをそこに束ねることです。ブラウザ用グループと名前を分けると、切り分け時に「Chrome だけ別ノード」といった状態を明示的に避けられます。いずれにせよ、ルールが参照しているグループ名が YAML 上で実在するかは、設定を触るたびに確認してください。

「IDE だけプロキシ」とグローバルモードの違い

スプリットトンネリング（国内は DIRECT、必要な海外ドメインだけ PROXY）に寄せる構成では、Cursor／VS Code 関連のサフィックスをルール前半にまとめ、最終ルールで全体を DIRECT に戻す、という形が一般的です。これがいわゆる「IDE スタックだけ意図的にプロキシ」に近い運用で、他アプリへの副作用を抑えられます。

一方、グローバルプロキシや「すべて PROXY に寄せる」モードは単純で切り分けは速い反面、国内サービスまで遅延したり、企業 VPN や銀行アプリと競合したりします。Cursor の不調が続くときにいきなりグローバルへ切り替えるのは有効な試し方ですが、長期運用ではルールの明示化の方がトラブルの再現性が高いです。システムプロキシを IDE にだけ効かせる GUI オプションを併用するクライアントもありますが、Electron アプリがそれを無視するケースがある点は頭に置いておいてください。

DNS・fake-ip と名前解決の取りこぼし

mihomo 系を含む多くの構成で、DNS モードはルールマッチの前提になります。fake-ip を使う場合、コアが名前解決と接続を対応付けやすくなりますが、OS やアプリが先に別のリゾルバで解決してしまうと、意図した DOMAIN-SUFFIX ルールに届かず実 IP へ直行する現象が起き得ます。IDE はブラウザよりキャッシュや独自 DNS の影響を受けにくい反面、プロキシ未使用の直結経路に落ちると症状だけが突出することがあります。

対策の方向性は、Clash の DNS 設定と OS の DNS の役割分担をはっきりさせること、TUN と併用するなら名前解決もコア側に寄せる設計を検討すること、そして fake-ip-filter の調整で国内ドメインだけ実 IP を維持するなど、用途に応じて漸進的に試すことです。ブラウザと IDE で挙動が違うときは、まず DNS の経路を疑うと時間を短縮しやすいです。

汎用 AI サイト向け記事との使い分け

ChatGPT や Claude のようにブラウザや単体アプリから直接 API を叩く構成は、別ホスト集合と別ポリシーの切り口になります。本サイトの ChatGPT・Claude を Clash で安定接続する記事 では、生成 AI 全般のドメイン設計とスプリットトンネリングの考え方を扱っているので、「IDE 内の Cursor」＋「ブラウザの AI」の両方を使う方は、ルールファイルを用途別に分割しておくとメンテナンスが楽になります。

切り分けチェックリスト（2026 年版）

まず IDE とブラウザが同じシステムプロキシ設定を見ているか、Cursor 設定に独自のプロキシ指定がないかを確認します。次に Clash のログで失敗ホスト名を拾い、ルール表で DIRECT／PROXY のどちらに落ちているかを追います。三つ目に DNS がどこで解決されているか を整理します。四つ目に、セキュリティソフト・別 VPN・企業プロキシがトラフィックを横取りしていないかです。

それでも改善しない場合は、一時的に TUN やグローバルモードで再現性を確認し、問題が消えるならルール順・DNS・漏れ代理のどこかに原因が残っていると判断できます。用語の対応関係を俯瞰したいときは ドキュメントページ も参照してください。Clash 本体のソースやライセンスは公式リポジトリで公開されていますが、実行ファイルの入手は下記のサイト導線を優先すると説明とバージョンの対応が取りやすいです。

まとめ

Cursor をはじめとする VS Code 互換スタックでは、拡張マーケット・更新・クラウド AI APIが別々のホストに分散しやすく、ブラウザだけ見ていても経路が追えません。Clash では ドメイン単位のルールを前半に置くこと、IDE 用ポリシーグループを明示すること、DNS／fake-ip の取りこぼしを疑うこと、そして IDE 限定のスプリットトンネリングとグローバルモードの役割を混同しないこと、この四点が安定運用の鍵になります。

同種のプロキシツールをいくつか試した方なら、ルール表現の柔軟さとコミュニティ知見の豊富さから、Clash エコシステムの扱いやすさを実感しやすいはずです。クライアントの入手は ダウンロードページ から各 OS 向けパッケージを確認できます。

Clash を無料ダウンロードして、IDE 向けルールを試す → 画面の案内に沿えば短時間で初期設定まで進められます。