1 Cursor が要求する通信を整理する
Cursor は VS Code 互換のシェルを載せた AI 向け IDE で、拡張マーケットからの取得・更新、言語サーバーやツールチェーンのダウンロード、そしてクラウド側のモデルや補完エンドポイントへの HTTPS セッションが短時間に何度も走ります。いわゆる「ブラウザだけプロキシすれば十分」という発想だと、Electron が別経路で直叩きするトラフィックが残り、拡張の検索が遅い・チャットがタイムアウトする・認証まわりだけ不安定、といった症状に見えます。開発者ネットワークの観点では、Cursor IDE と Clash プロキシを同じ設計図の上に載せる必要があります。
本稿の焦点は、帯域を無理に広げることではなく、どのレイヤでプロキシを効かせるかを決めることです。OS のシステムプロキシだけで十分なケース、TUN（仮想 NIC）でターミナルやコンテナまで含めて一本化した方が楽なケース、社内の出口と二重プロキシになってループするケースを切り分けます。AI プログラミングツールへのアクセス品質は、往復遅延と DNS の一貫性に敏感なので、Clash 側のルールと DNS モードもセットで見ます。
以降は Clash Verge Rev のような GUI クライアントを想定した手順が中心ですが、考え方は Mihomo コアを直接動かす構成にもそのまま移植できます。サーバー常駐のヘッドレス構成が必要な場合は、Linux に Mihomo を systemd で載せる手順と組み合わせて、ワークステーションから mixed ポートへ向ける形も取れます。
2 システムプロキシと Electron（Cursor）の関係
Cursor は Chromium 系のネットワークスタックを使うため、多くの HTTPS 要求は OS が公開しているシステムプロキシ設定を参照します。Clash Verge Rev では「システムプロキシを有効化」相当のトグルで、HTTP/HTTPS をローカルの mixed ポート（例: 127.0.0.1:7890）へ流し込めます。ここまで整うと、拡張マーケットのメタデータ取得、更新チェック、いくつかの埋め込み WebView まわりがまとめて安定しやすくなります。
ただし「システムプロキシ ON」は万能ではありません。社内の明示的プロキシ（PAC や WPAD）と Clash の自動設定が二重に掛かると、ループや認証ダイアログの連打につながります。対策の基本は、どちらか一方に役割を寄せることです。Clash を主出口にするなら、OS のプロキシ欄は Clash が書き換えた値だけにし、ブラウザ側の独自プロファイルは一時的に切る、といった順序立てが安全です。
Clash 側で先に確認すること
ノードが実際に生きているか、ルールで意図せず DIRECT に落ちていないかを、接続ログで見ます。Cursor のモデル呼び出しは長めの HTTP/2 ストリームになりがちなので、途中で RST されるノードだと UI 上は「たまに切れる」ように見えます。安定性を優先するなら、遅延よりもパケット損失の少ないアウトバウンドを選ぶ価値があります。
3 TUN で Git・npm・Docker まで同じルールに乗せる
システムプロキシだけでは、環境変数を見ない CLI や、独自ソケットを張るツールがすり抜けます。Cursor の統合ターミナルから git clone、npm install、コンテナイメージの取得を行うと、IDE 本体は速いのに CLI だけ遅い、というズレが典型です。TUN モードは仮想 NIC レベルでトラフィックを捕捉するため、同じマシン上の開発者ネットワークを一枚の布にできます。
Windows / macOS での有効化手順、YAML の tun ブロック、検証用の curl 例は、Clash Verge Rev TUN モード完全ガイドに任せます。本稿では役割分担だけ押さえます。IDE の拡張更新とモデル API はシステムプロキシで十分なことが多い一方、リポジトリとパッジストリは TUN か環境変数のどちらかが必須、という二段構えが現場では扱いやすいです。
npm と Git の環境変数（補助線）
TUN を使わない方針なら、シェルに HTTP プロキシを明示します。mixed ポートが HTTP プロキシとしても振る舞う前提で、次のように揃えるのが一般的です。
export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"
export ALL_PROXY="socks5://127.0.0.1:7890"
export NO_PROXY="localhost,127.0.0.1,::1"
Git には git config --global http.proxy で上書きすることもできますが、社内ホストを直結したい場合は NO_PROXY のリスト設計が重要です。Cursor の AI 機能はクラウド側と会話するため、誤って社内のみのプロキシに閉じ込めないよう、ルールでホワイトリストを分ける運用が安全です。
4 ルールと DNS：モデル通信を安定させるコツ
AI プログラミングツールのアクセスは、単一ドメインに固定されず、CDN・認証・テレメトリに分散します。手書きの DOMAIN ルールだけで追い切るより、信頼できる Rule Provider と地域向けの GEOIP 直行を組み合わせた方が保守コストが下がります。国内向けサービスを無駄に海外ノードへ流すと遅延が跳ね上がるので、GEOIP,CN,DIRECT のような定番パターンは IDE 利用時も有効です。
DNS は見落とされがちですが、FakeIP と DoH を整えないと「ブラウザでは開けるのに IDE だけ名前解決が変」という現象が出ます。詳細は Meta カーネルでの DNS 漏洩防止を参照し、Clash の DNS セクションと OS の DNS を二重管理しないよう揃えてください。TUN と DNS ハイジャックを併用する場合は、ローカル開発用の *.localhost や社内ゾーンを DIRECT に残すことを忘れないでください。
5 Cursor 側で見るべき設定と切り分け
設定 UI のネットワーク項目でプロキシを上書きできる場合は、OS と矛盾しない値にそろえます。VS Code 互換の http.proxy 系設定を使うチームもありますが、Clash を単一の出口にするなら「OS のシステムプロキシに従う」に寄せた方が運用が単純です。拡張だけ失敗するときは、Output パネルのログと Clash の接続一覧を同じタイムスタンプで見比べると、どのホストで詰まっているかが追いやすくなります。
モデル要求がタイムアウトする場合、帯域ではなく維持時間と再接続を疑います。不安定な UDP ベースのトランスポートを選んでいないか、ルールで意図しないリージョンに飛んでいないかを確認し、必要ならセレクタで別ノードへ切り替えて A/B します。Wi-Fi 切り替え直後は OS のルートテーブルが更新されるまで数秒空くことがあるので、Clash の TUN を一度オフにしてオンに戻すのも有効なリセット手順です。
開発用コンテナや WSL2 を併用する場合、名前空間をまたぐ DNS の扱いが別問題になります。ホストで Clash が動いていても、コンテナ内はデフォルトで別解決経路です。Docker Desktop のプロキシ設定や、WSL の resolv.conf を含め、TUN ガイドの Docker 検証節とあわせて読むと全体像がつながります。
6 トラブルシューティング
- 拡張だけインストールできない： システムプロキシが無効、または別プロファイルのブラウザだけプロキシされている可能性があります。Clash のシステムプロキシ設定を確認し、Cursor を再起動してください。
- チャットは動くがマーケットが遅い： ルールでマーケット CDN が遠回りしていないか、DNS が期待と異なる答えを返していないかを接続ログと照合します。
- ターミナルだけ失敗する： TUN がオフで環境変数も未設定だと典型的です。TUN モードをオンにするか、シェルに
http_proxyを足します。 - 無限ローディングになる： 二重プロキシやループ、もしくはノード側の長连接切断です。一旦
DIRECTで同一 URL をcurlし、Clash を経由したときだけ落ちるか切り分けます。 - 証明書エラー： 企業ゲートウェイの TLS インスペクションを疑い、OS 信頼ストアと Cursor が同じ CA を見ているか確認します。
7 まとめ
Cursor のような AI IDE は、拡張エコシステムとクラウド推論の両方に強く依存します。Clash プロキシは「ブラウザを速くする道具」ではなく、開発者ネットワーク全体の出口設計として置くと、IDE・CLI・コンテナの挙動が揃いやすくなります。システムプロキシで Electron 系を覆い、TUN か環境変数でターミナル系を拾う二層構えは、現場で再現性が高いパターンです。
ルールと DNS を軽視すると、帯域に余裕があってもストリームが途中で切れることがあります。コア設定の細部は DNS 漏洩防止の記事や TUN モードガイドに譲り、本稿では Cursor と Clash の噛み合わせに絞りました。どちらも同じ Mihomo 系コアの上で動くため、一度 YAML の考え方を揃えると他ツールにもそのまま流用できます。
単体の軽量プロキシより、ルール分流と DNS を一体で扱える Clash 互換クライアントの方が、AI プログラミングの日常運用ではトラブルが少ない場面が多いです。特にモデル要求のような長めのセッションでは、安定性の差がそのまま生産性の差になります。
