この記事で分かること

2026 年時点で、エディタ内のチャットに加えて、クラウド側で実行される Agentやブラウザツール、拡張された API 呼び出しが一体となったワークフローが増えています。検索クエリとしては「Cursor 3」「クラウド Agent」「ブラウザツール」「MCP」「落ちる」「タイムアウト」「HTTPS_PROXY」「プロキシ分流」といった語が並び、現場の体感はアップグレード直後だけ接続が細かく途切れる／長いジョブだけ失敗するという形で現れやすいです。

本稿はデスクトップ向け Mihomo／Clash Meta 系 GUI のひとつである Clash Verge Rev を前提に、(1) ルール分流（Rule）で Cursor 関連ドメインやモデル API を意図したアウトバウンドへ送る、(2) エディタに埋め込まれた実行環境と OS のプロキシ設定のズレを減らす、(3) 統合ターミナルやサブプロセスへ HTTPS_PROXY／HTTP_PROXY／NO_PROXY をどう渡すか——を、ログと curl を軸にした実測の流れでまとめます。スクリプトや SDK から Agent を叩く構成が主役の場合は、手順の粒度が異なるためCursor SDK 向けの分流・環境変数ガイドとあわせて読むと隙間が埋まりやすいです。エディタ UI と拡張機能マーケット中心の切り分けはマーケット向けの記事、Verge Rev の基本操作はチュートリアルへリンクします。

検索意図と症状：クラウド Agent・ブラウザツール・MCP

Cursor 3 の利用シーンでは、次のようなクリティカルパスが隠れやすく、ユーザーが入力しがちなキーワードと対応させて整理できます。

  • クラウド Agent のステップが途中で止まる：API への長めのストリームや再接続が、DIRECT のまま残っているルール、途中機器での SNI 取り扱い、Keep-Alive の張り付き先の不齐など、TLS 以前または途中ホップの問題が混じります。
  • ブラウザツールだけ不安定：埋め込みビューが参照するプロキシチェーンが、OS のシステムプロキシと一致していない、あるいは別プロセスが環境変数を読まずに直結している——といった経路の二重化が典型です。
  • MCP やツール呼び出しだけが落ちる：MCP はローカルの待受と外向き HTTPS が短時間に交互に走るため、片方だけ プロキシ 設定が欠けると「一部のツールだけ失敗」に見えます。
  • 成功と失敗が交互に出る（フラッピング）：複数ターミナルプロファイル、タスクランナー、コンテナ、VPN クライアントが別々のネットワーク名前空間や DNS を掴んでいるときに起きやすいです。

いずれも「回線全体が死んだ」より、HTTPS クライアントが期待したプロキシ列に乗っていない比率が高いです。Clash Verge Rev のログで一行ずつ追えることは、説明責任のある運用では大きな利点になります。

Cursor 3 の表示層とバックエンド呼び出しのズレ

同じマシンでも、Electron ベースの UI、埋め込みブラウザ、バックグラウンドで動くジョブは、参照するプロキシ設定が完全一致しないことがあります。GUI は OS のシステムプロキシや独自チャネルを先に見る一方、Node や他ランタイムの HTTP スタックは HTTPS_PROXY と NO_PROXY に強く依存します。

このズレは「Cursor 3 にしたあとだけクラウド Agent が細かく切断される」という体感として現れやすいです。ブラウザ単体の検証では問題ないのに、エディタ内だけ ETIMEDOUT や読み込みの中断が出るパターンは、Shell で env | grep -i proxy を確認し、API 分流のログと突き合わせるのが早いです。

ブラウザツールと MCP を同じ頭で扱うときの注意

ブラウザツールと MCP は、どちらも「ローカルで完結する通信」と「外向きのメタデータ取得や認可フロー」が短い時間で交互に走ります。ルール分流では次の二層に分けると事故が減ります。

  • 内向き（そのマシン上）：127.0.0.1／localhost は意図的に DIRECT。NO_PROXY に明示し、誤ってプロキシへ流すと往復が増えてレイテンシだけが跳ね上がります。
  • 外向き（プロバイダ側）：ログに出たドメインを DOMAIN または妥当な DOMAIN-SUFFIX で PROXY に寄せ、MATCH より上へ置きます。

クラウド Agent と MCP を同じワークフローで使う場合、「外向きドメインのリスト」と「ローカル例外のリスト」を分けてメモに残すと、チーム共有やインシデント後の振り返りが楽になります。

Rule を軸に、TUN は補助として使う

ルール分流は、社内 Git や決済ドメインを DIRECT に残しつつ、Cursor やモデル API を PROXY へ送る第一選択です。YAML の順序とログを突き合わせれば、「どのホストがどのポリシーへ落ちたか」をテキストで説明できます。

TUN はカーネル近傍でトラフィックをキャプチャし、プロキシ変数を無視するバイナリでも一度 Mihomo 側へ引き込める強力な手段ですが、ゼロトラスト VPN や別製品の仮想 NIC と競合しやすいです。実務的には、(1) Rule とシステムプロキシで足りるか試す、(2) 特定プロセスだけの問題なら限定的に TUN、(3) 常時フル TUN は最後の手段、の順が安全です。

Clash Verge Rev では「システムプロキシをセット」「TUN を開始」が別操作のため、ブラウザだけ整備されターミナルが裸、という分岐に注意してください。

HTTPS_PROXY を中心にしたターミナル向け環境変数

Cursor 3 の統合ターミナルやタスクランナーから外向き API を叩く場合、GUI よりも環境変数の比重が大きくなります。典型的には次を揃えます。

  • HTTPS_PROXY：HTTPS への CONNECT が主用途なら最優先。
  • HTTP_PROXY：リダイレクト先行の HTTP フェーズで参照されます。
  • ALL_PROXY：単一変数しか読まないツールへの保険（無視されることもあります）。
  • NO_PROXY：localhost、127.0.0.1、社内 SSO を除外し、MCP のローカル待受とのループを防ぎます。

値は多くの場合 http://127.0.0.1:<mixed-port> で足り、TLS は CONNECT でトンネルします。書き場所の例は ~/.zshrc、~/.bashrc、リポジトリの .envrc、あるいは検証時のみのコマンド前置きです（ポートは各自のプロファイルに合わせて読み替え）。非ログインシェルだけが読む設定ファイルに書いてしまい、統合ターミナルに届かない、という落とし穴には注意してください。

ルールへ載せるホストはログ実測を優先

固定リストは保守コストが高く、サービス側変更で簡単に陳腐化します。検索で繰り返し見かける型としては次を出発点にし、実名はログで上書きしてください。

  • Cursor 系プロダクト：cursor.com／cursor.sh 周辺のサブドメイン。証明書名とホストが一致していることをログで確認します。
  • モデルや外部 API：設定で選んだプロバイダに応じたホスト（利用規約と社内規程を確認のうえ）。
  • 認証・CDN・補助サービス：クラウド Agent や ブラウザツール が内部的に追加するホストは、エラー直後の一行ログから拾うのが最短です。

エラーメッセージに出るホスト名は、ブログ本文の一般的な列挙よりログに出た実名のほうが信頼できます。API 分流をチームで共有する際も、スクリーンショットよりログ行を貼るほうが再現性が高いです。

TIP：一度だけGlobal に近いプリセットで同じ操作を試し、症状が消えるかを見てください。消えるなら DIRECT 落ちのルール順が本命で、MATCH より上へ個別 DOMAIN を挿入しやすいです。

ルール記述例（ポリシー名は各プロファイルに合わせる）

以下は Mihomo／Clash Meta 互換の説明用スニペットです。PROXY を利用中のポリシーグループ名へ置換し、既存の MATCH より上に置いてください。

# Example rules snippet — replace PROXY with your policy group name
rules:
  - DOMAIN-SUFFIX,cursor.com,PROXY
  - DOMAIN-SUFFIX,cursor.sh,PROXY
  # Add hosts Verge Rev logs show for cloud agents / APIs above MATCH

広すぎる DOMAIN-KEYWORD は誤爆しやすいので、ログに出た実名を DOMAIN で足す運用を推奨します。

ステップ：Cursor 3 のクラウド経路を安定させるまで

  1. Clash Verge Rev が期待するプロファイルで起動済みであり、mihomo が待ち受けていることを確認します。
  2. 通常のブラウザで同じノードを用いた外向きサイト疎通を見て、問題がエディタ／クラウド Agent 限定かを切り分けます。
  3. 切断やタイムアウトの再現直後にログからホスト名を拾い、プロキシ分流ルールを追加します。fake-ip とルール種別の組み合わせでマッチがズレていないかも見ます。
  4. OS のシステムプロキシと Verge Rev の設定が矛盾していないか確認し、必要なら「システムプロキシをセット」をやり直します。
  5. 統合ターミナルで動くツール向けに、新しいシェルセッションで HTTPS_PROXY と HTTP_PROXY を export してから同じ操作を繰り返します。
  6. 問題の URL へ curl -vI を送り、Clash 側で意図したチェーンに乗ったかを確認します。
  7. 個別バイナリが依然として直結する場合は TUN を試す前に、HTTPS インスペクションや別 VPN のスタック競合を疑います。

検証のコツ：MCP 込みで状態を一元化する

「設定した HTTPS_PROXY」が統合ターミナルに届かないときは、非ログインシェル、タスクランナーのサンドボックス、コンテナのネット命名空間などを疑います。

  • 同一ホストで curl とエディタが別結果：curl は変数が効いており IDE 内だけ無視しているなら、そのランタイムのドキュメントで代理関連の環境名やフラグを確認します。
  • IPv6 と IPv4 の分裂：curl -4 でのみ通るときは DNS か経路が二系統化しています。
  • 社内 Split DNS：機密系は NO_PROXY に残し、外部 API だけ PROXY —— の二段にすると開発者端末での事故が減ります。
注意：コードやログをクラウド Agentへ送る操作は、利用規約と会社の情報セキュリティポリシーに触れることがあります。ネットワークが安定しても、アップロード可否は別判断です。
ダウンロードページへ

トラブルシューティング

症状：エディタ UI は動くがクラウド Agent だけ途切れる

想定原因：長めのストリームや再接続が特定ホストに張り付いており、そのホストだけ DIRECT または不安定なノードに落ちている。

対処：ログでホスト名を特定し DOMAIN ルールで固定。ノードを差し替え、DNS と fake-ip の組み合わせを確認します。

症状：curl は成功するがブラウザツールだけ失敗

想定原因：埋め込みビューがシステムプロキシと異なる経路を見ている、証明書検証まわりでプロキシが介入している。

対処：OS プロキシと Verge Rev の設定を再適用。社内検査プロキシと Clash の二重構成になっていないか確認します。

症状：MCP だけローカル接続が不安定

想定原因：ローカル待受が NO_PROXY に入っていない、または誤ってプロキシへ流している。

対処：127.0.0.1 系を除外し、外向きだけルールを厚くする。セキュリティソフトのローカルループ制限も確認します。

よくある質問

Cursor 3 のクラウド Agent だけがタイムアウトするのはなぜですか？

UI 層と長時間ジョブ層で参照するプロキシ設定や DNS が一致しないためです。Clash Verge Rev のログで DIRECT 漏れを潔し、Shell に HTTPS_PROXY を揃えてください。

ブラウザツールの外向き通信も同じルールで足りますか？

外向きドメインはログの実名を載せ、ローカル待受は除外する二段構成が安全です。固定リスト任せにしないでください。

HTTPS_PROXY はどこに書けばよいですか？

常時ならログインシェル設定や direnv、単発検証ならコマンド前置きのみ。副作用を限定するのがポイントです。

単一製品 VPN との比較で見える Clash の利点

ワンタップ型の商用 VPN は初期導入が楽でも、ドメイン単位の細かな例外やログでの逆引きには向きにくいことがあります。開発者ワークステーションでは、Git だけ直結できない、クラウド Agent だけ別経路で詰まる、ブラウザツール だけ証明書まわりで失敗する——といった摩擦が出やすいです。Clash 系は本文のとおりルール分流とログで API 分流を説明できるため、Cursor 3 と社内サービスを同じ端末上で両立させるほうが現実的になります。

フロントエンドは好みで選べますが、Verge Rev はプロファイル編集とログ監視が近接しており、エディタとターミナルを行き来する検証とも相性がよいです。大手 VPN の「すべて同じ出口」に比べ、詰まった場所をドメイン粒度でほどける点が長期的な運用リスクを下げやすいです。

無料で Clash を入手し、Cursor 3 向けの分流と検証を試す →