Cursor 3 のマルチエージェント運用で不安定になったら｜Clash Verge Rev で分流・DNS を段階実測する（2026）
Cursor 3ではワークスペースをまたいだコーディングエージェントやクラウド側の推論・インデックスなど、エディタ単体を超えた通信が増えやすくなっています。その結果、「ローカル編集は軽いのにAPI の応答だけ極端に遅い」「複数エージェントを動かした瞬間にタイムアウトが増える」といった検索で辿り着く層が増えています。本稿はClash Verge Revと背後のMihomo（Clash Meta 系）を前提に、分流ルールの順序・fake-ip／DNS・TUN とシステムプロキシの三段を、ログ主導でそろえるための実測チェックリストです。公開ホスト名は更新で変わり得るため、記載は出発点と捉え、必ず自分の接続ログを正としてください。
検索意図の整理：Cursor 3 で「ネットワークが怪しい」と感じる瞬間
アップデート後に増えやすい体感は、(1) チャットやクラウドオーケストレーションへ向かう HTTPS がTLS 確立まで長い、(2) 並列エージェントやバックグラウンドジョブが増えたときだけ429／5xxやタイムアウトが跳ねる、(3) ブラウザや別 IDE は問題ないのにCursor 系プロセスだけ経路がぶれる、の三類型です。根本原因がアプリ側の輻輳である場合もありますが、ローカル側では適用された分流と名前解決がプロセスごとに分裂しているパターンが非常に多く、まずはClash Verge Rev のログパネルとコア側の接続ログで「実際の宛先」と「どのルール行に当たったか」を一枚にそろえるのが近道になります。
GitHub や API の典型的なドメイン設計だけを追う記事としては、すでにCursor と GitHub を分流する実測稿（Cursor と GitHub の経路分担）があります。本稿の差分はCursor 3 のマルチエージェント前提で、(a) 増えた外向きホスト、(b) fake-ipや OS／ブラウザ DNS との競合、(c) TUN とシステムプロキシの選択、(d) Verge Rev のMixin／プロファイル覆写で購読を壊さず追記する運用、までを一本につないだ点です。前提の用語はチュートリアルページとカスタムルール解説で押さえておくと読み進めやすくなります。
ステップ 1：システムプロキシと TUN のどちらに寄せるか決める
システムプロキシは設定が軽く、アプリが OS のプロキシ設定を尊重していれば十分なことが多い反面、環境変数のHTTP_PROXY／HTTPS_PROXYやNO_PROXYが広く書かれていると、エディタ本体とコーディングエージェントの子プロセスでねじれが出ます。TUNはトラフィックをコア側へ寄せやすく、システムプロキシを読まない実行ファイルにも効かせやすいですが、権限・競合 VPN・企業ポリシーの影響を受けやすいです。詳細な設計判断はTUN モードの深掘りを読んだうえで、まずは「ブラウザだけ直って Cursor だけおかしい」をTUN オン／オフの単独比較で切り分けると安全です。
Windows ではUWP やループバック絡みで見え方が変わることがあり、システムプロキシ中心運用ならUWP とシステムプロキシの整理も参照してください。Verge Rev 側のログでタイムアウトを読む習慣は接続ログとタイムアウトの切り分け稿と整合的です。
ステップ 2：接続ログで「宛先」「採用ルール」「プロセス」をそろえる
Cursor 3では補完・検索・チャット・クラウドインフラが別ホストへ伸びることがあり、検索記事に載っているcursor.comやcursor.shのDOMAIN-SUFFIXだけでは足りないビルドも珍しくありません。対処は常にログファーストです。Verge Rev の接続一覧で、(i) タイムアウトした行のFQDN、(ii) マッチしたpolicy／proxy-groups名、(iii) 可能ならプロセス名をメモします。並列エージェントを動かした直後だけ増えるホストがあれば、それがクラウド側の新経路である可能性が高く、ルールの追記候補の第一候補になります。
ステップ 3：分流ルールは「狭い行を上に」積み替える
購読テンプレに巨大な RULE-SETやGEOIPが入っていると、意図せずDIRECTや別グループに吸われてタイムアウトへ進むケースがあります。分流ルールは上から先にマッチした行が勝ちなので、ログで実際に伸びているホストをDOMAINやDOMAIN-SUFFIXで明示的に先頭付近へ置き、出口となるproxy-groups名をGitHub／モデル API／エディタ本体で分裂させないように揃えます。グループ設計の骨格はproxy-groups ガイドが参照になります。
rules:
# Replace CursorCloud with your group name; grow from YOUR logs only
- DOMAIN-SUFFIX,cursor.com,CursorCloud
- DOMAIN-SUFFIX,cursor.sh,CursorCloud
# Example extra hosts seen in logs — do not copy blindly
- DOMAIN,api.cursor.com,CursorCloud上は叩き台です。PROCESS-NAMEで寄せたい場合は、Windows ならCursor.exeのような表記がログと一字一句合うかを確認してください。macOS ではバンドル配下の実行体名が出るため、コピペよりログの表記を正にします。
ステップ 4：fake-ip と DNS を「一度に一つのノブ」で実測する
fake-ipは体感レイテンシを下げる一方、特定アプリと組み合わせたときに名前と実経路の見え方がかみ合わず、長めのストリームだけ失敗する類型を作ることがあります。検証は、(A) いまのenhanced-modeでログを読む、(B)DoHとプレーンnameserverを交代する、(C)nameserver-policyでサービスドメインだけ別 resolver に寄せる、(D) IPv4／IPv6 の経路分裂を疑う、の順が追いやすいです。複数項目を同時に書き換えないのが鉄則です。嗅探まわりの整理はMeta／Mihomo の sniff と DNS、Linux でsystemd-resolvedが絡む場合はresolved と Clash の記事も併読すると安全です。
ステップ 5：Mixin で購読を壊さず DNS とルール断片だけ足す
リモート購読を直接編集すると更新で上書きされやすいです。Clash Verge RevではMixinや GUI のプロファイル覆写で、ポート・DNS・ルール断片だけを重ねる運用が現実的です。クリック順と典型パターンはWindows 11 向け Mixin 稿に詳しくあり、OS の見え方が違っても「購読はそのまま、差分だけローカルで足す」という発想は共通です。覆写後は必ず再接続とログ再確認までセットにしてください。
ワークフロー：マルチエージェント時の切り分け順（俯瞰）
-
1
ベースライン
Clash を一時停止または最小プロファイルにし、同一操作で症状が消えるかを見ます。消えなければ上流やアプリ側の要因を疑います。
-
2
ログでホスト集合を取る
エージェントを並列に動かした直後だけ増える FQDN を列挙し、policy がバラけていないか確認します。
-
3
ルール順とグループ名を一本化
狭い DOMAIN 行を上へ移し、綴り違いで別グループへ落ちていないかを潰します。
-
4
DNS を単一変数で振る
fake-ip／redir-host、DoH、nameserver-policy を順番に試し、TLS 確立までの時間変化を見ます。
このループを回すことが本稿でいう段階実測です。検索結果のドメイン表は参考にとどめ、自分のログにあるホストを資産として残す運用が長続きします。
よくある質問
Cursor 3 のクラウド機能だけ遅いのはなぜ？
ホスト集合とストリーム長が変わり、ルール順や DNS のねじれが「クラウドだけ」のように見えることが多いです。ログの実宛先と採用ポリシーをそろえてから、並列エージェント数やレート制限も視野に入れます。
fake-ip をやめるべき？
常に避けるべきとは限りません。まず現設定で再接続ログを読み、キャッシュや sniff と矛盾したときだけredir-host等へ単独で切り替えて比較してください。
コーディングエージェントの子プロセスまでルールが効く？
PROCESS-NAMEで拾える場合と、システムプロキシや TUN に載せないと抜ける場合があります。ログに出た実行体名と宛先を基準にモードとルールの両方を調整します。
まとめ
Cursor 3のマルチエージェント運用では、エディタより広い外向き通信が増え、分流ルールとDNS（fake-ip）、さらにTUN／システムプロキシの選択が組み合わさったときだけ症状が顕在化しやすくなります。Clash Verge RevとMihomoのログを軸に、モード決定→ログ取得→ルール順の再配置→ DNS の単一変数検証→ Mixinでの安全な追記、の順で進めると再現性が高くなります。
従来型の単机能プロキシツールでは、YAML での細かなポリシー表現や、購読テンプレを残したままローカルだけ差分を足す運用に弱いものもあります。一方で Clash 系はルール順とグループ設計をバージョン管理しやすく、ログで実測しながら微調整できるため、開発者のコーディングエージェント環境とも相性がよいです。クライアントの入手経路を一本化したい場合はダウンロードページから確認し、VPN 型との違いはClash と VPN の比較も参考にしてください。