この記事で分かること
検索では「Cursor」「アプリが読み込めない」「AI が応答しない」「拡張機能 インストール できない」といった語がよく並びますが、実際の現場ではネットワークそのものは生きているのに、エディタ内の特定機能だけがぐるつくというパターンが目立ちます。本稿はその典型として Cursor を取り上げ、背面で動く Clash/Mihomo 系クライアントの代理分流(ルール)とシステムプロキシ/TUN の整合をそろえて切り分ける手順をまとめます。
万能のドメイン一覧はエディタのアップデートで変わりうるため、「ログと開発者ツールで実際に叩かれているホスト名を確かめる」ことを前提にします。ここでは再現しやすい症状と、それに対して効きやすいルールの書き方の型を中心に述べます。デスクトップのグラフィカル UI を使う場合は、Clash Verge Rev のチュートリアルで触れたポリシーやログの見方と思考はそのまま転用できます。
よくある症状と検索意図の対応
ユーザーがググりやすい言い回しと、画面で見える挙動はだいたい次のように対応します。
- AI チャットがタイムアウト:送信後ずっとローディングのまま、数分後に失敗する。ターミナルや出力パネルには接続エラーが出ないこともある。
- 拡張機能マーケットが開けない/検索結果が空:Visual Studio Code 互換のギャラリーへ依存するため、CDN・認証・メタデータ取得のどこかがブロックされていると一覧が出ない。
- 本体アップデートだけ失敗:コード署名サーバや配布 CDN が別ドメインになっていると、通常ブラウジングは問題でもここだけ DIRECT のまま残ることがある。
これらはすべて「HTTP(S) の経路がエディタから見て期待とずれている」サインです。単にノードが遅い場合もありますが、まずはプロキシを通すべきホストが DIRECT で落ちているかをログで確認するのが早道です。
なぜ Clash の分流が効くのか
Cursor のような Electron ベースの開発ツールは、以下のような複数の外向き通信を短時間にばらまきます。
- 製品本体とサーバ間の API(認証、機能フラグ、課金状態の参照など)
- モデル推論や補助サービスへ向けた HTTPS/WebSocket
- 拡張機能マーケットのメタデータ、
.vsixの実体ファイル、整合性チェック用リソース - 第三者 CDN・オブジェクトストレージ・サンドボックス用ドメイン
いわゆる「ブラウザだけプロキシ指定」の運用では、環境変数 HTTP_PROXY を設定しても Electron が参照しないケースがあります。OS のシステムプロキシと一致しているか、あるいはTUN でトラフィックを内核側からキャプチャするかがポイントになります。そのうえで Clash の rules: が「どのホストをどのポリシーへ送るか」を決めるので、ドメイン単位でズレを直すという意味で分流設定が効いてきます。
ルールを書く前のチェックリスト
- Clash が実際に稼働しているか:ダッシュボードでノードに赤バツが付いていないか、プロファイルが最新か。
- モード:
Ruleで意図どおり動かす前提なら、誤ってDirectになっていないか。 - システムプロキシ:Windows/macOS の設定と Clash が提示するポート(混合ポートや HTTP ポート)が一致しているか。
- TUN/ドライバ:管理者権限やセキュリティソフトにより仮想インタフェースが塞がれていないか。
- DNS:
fake-ipとドメインルールの組み合わせで、マッチしない名前解決になっていないか。
ここが崩れたままルールだけ増やしても期待どおりに見えません。まずはブラウザで同一ノード・同一プロファイルを使ったときに海外サイトが開けるかを確認し、問題が Cursor に限定されることをはっきりさせます。
分流で最初に押さえたいドメインの型
実際のホスト名はバージョンと地域で変わるため、以下は出発点の例です。更新後に動かなくなったら、Clash のログに出た DOMAIN をそのままルールに追加してください。
- プロダクト/アカウント周り:
cursor.com、cursor.sh、www.cursor.comなど証明書と一致するホスト - マーケット・ビルド済み拡張機能の取得:
marketplace.visualstudio.com、*.vscode-unpkg.net、*.gallerycdn.vsassets.ioなど公式ギャラリー依存ドメイン - OpenAI など外部モデル API:設定で選択しているプロバイダに応じて
api.openai.comほか(プライバシーポリシーと社内規程を確認のうえ利用)
中国語圏のユーザー向け記事では地理ブロックや輻輳対策として「海外 CDN を明示的にプロキシへ」の書き方が多いですが、日本語圏でもキャリアや大学キャンパス網で特定パスだけ劣化することは珍しくありません。検索意図としては「開発ツールのタイムアウトをプロキシで回避したい」というニーズが共通しています。
動作確認済みの書き方の例(Mihomo/Clash Meta 互換イメージ)
実環境のプロファイルに合わせてインデントとポリシー名(例:PROXY)は読み替えてください。既存の MATCH より上に置くのが鉄則です。
# Example rules snippet — adjust policy names to your profile
rules:
- DOMAIN-SUFFIX,cursor.com,PROXY
- DOMAIN-SUFFIX,cursor.sh,PROXY
- DOMAIN-SUFFIX,openai.com,PROXY
- DOMAIN-SUFFIX,microsoft.com,PROXY
- DOMAIN-SUFFIX,visualstudio.com,PROXY
- DOMAIN-SUFFIX,vscode-unpkg.net,PROXY
- DOMAIN-SUFFIX,gallerycdn.vsassets.io,PROXY
GEOSITE やルールセットをお使いの場合は、既存の「微软服务」「CDN」カテゴリがDIRECT に落ちていないかをログで確認してください。会社 LAN で Split DNS をしているときは、社内ドメインだけ DIRECT のままにしておき、上記のホストだけを明示的に PROXY へ送る二段構えが安定しやすいです。
ステップ・バイ・ステップで直す
- 症状がブラウザでも再現するかを切り分ける。
- Clash でシステムプロキシをオンにするか、TUN を有効にしてエディタを再起動する。
- ログを
info以上にして Cursor で AI とマーケットを再試行し、表示されたホストをメモする。 - メモしたホストを
DOMAIN-SUFFIXまたはDOMAIN-KEYWORDで PROXY 側へ(順序は既存ルールより上位)。 - プロファイルを再読み込みし、接続が期待ポリシーに変わったかログで確認する。
- それでもダメならノードを別リージョンへ切り替え、TLS インタセプト製品を一時オフにして再検証する。
検証のコツ
開発者向けツールでは、「プロキシ環境変数は設定しているつもり」でも実際には効いていないことがあります。次のような実測ベースの確認が確実です。
- Clash の「最近の接続」やログで、問題のホストが
tcpとしてどのチェーンに載ったかを見る - 同じマシンから
curlでヘッダだけ取得し、タイムアウトする経路がエディタと一致するか比較する(証明書検証エラーは別問題) - VPN を完全オフにした状態と比べ、ルール変更の前後で応答時間がどう変わったかを記録する
これらは検索結果に出やすい「Cursor つながらない」「Clash 設定」のクエリに対して、再現手順つきのノウハウとしてそのままブログや社内 Wiki に転記できる粒度です。
それでも直らないとき
症状:特定 Wi‑Fi だけダメ
想定原因:キャプティブポータル、UDP 制限、IPv6 の経路齟齬など。
対処:IPv4 のみに固定して試す、別 DNS にする、ルータの DPI を疑って HTTPS の SNI が剥がれていないか確認する。
症状:ログでは PROXY なのに UI は固まる
想定原因:WebSocket が途中プロキシで切断されている、ウイルス対策がコンテンツを検査しているなど。
対処:別ノード、別プロトコル、または検査対象からエディタ実行ファイルを除外(許可ポリシーの範囲で)を試す。
症状:マーケットだけ証明書エラー
想定原因:企業ルート証明書による TLS ミドルウェアと、エディタ側のピンニングの競合。
対処:IT 部門のガイドラインに沿って信頼ストアを整備する。無暗な「証明書検証オフ」は避ける。
よくある質問
ブラウザは速いのに Cursor だけ遅いのはなぜですか?
ブラウザとエディタとで参照しているプロキシ設定が異なるか、呼び出しているホスト集合が別だからです。TUN で揃えるか、ログに出たホストへ明示ルールを書いてください。
ルールを書いたのにログでは DIRECT のままです。
rules の順序とインポート構造を疑ってください。サブプロファイルに同名キーがあり後勝ちしている、MATCH が先に効いている、といったケースが典型です。
会社のプロキシと Clash を両方使えますか?
技術的にはチェーン可能ですが、セキュリティポリシーと競合しやすいです。許可された構成か必ず確認してください。
閉じに:単一ベンダ VPN との比較視点
ワンクリックの商用 VPN は初期セットアップは楽ですが、ドメイン単位の細かな例外や複数プロファイルの切り替えには向きません。すべてのトラフィックを一律で海外へ流すと、銀行アプリや社内 Git が同時に不安定になることも珍しくありません。一方で Clash 系は本文で触れたようにルールとログで経路を説明可能なので、「Cursor の AI だけ海外」「マーケット CDN だけ別チェーン」といった開発者特有のチューニングが現実的です。クラシックな単一構成アプリに比べて学習コストはありますが、詰まったときにログ一行で次の手が決まるのは長期的にはリスクが低い運用になりやすいです。
自分の OS に合う GUI を選び、プロファイルをバージョン管理しておけば、チーム内で「このルールを足せば直った」という再現可能なナレッジも溜まります。