Cursor 3 の並列エージェント（Agents）がタイムアウトする？モデル API ドメインを Clash・mihomo で分流して Agents Window を安定させる（2026）

1. 並列エージェントで増える「同時 API」と典型症状

Cursor AgentsやAgents Windowのような UI では、複数のバックグラウンド処理が同時にHTTP接続を張る場面が増えます。チャット一本分の遅延を超えて、指数ではないまでも接続本数は増えるため、いままで暗黙に通っていた経路が、帯域・NAT・セッション数の限界に触れやすくなります。体感としては、単一タスクは成功するが、並列だけ途中で止まる／一定時間で切れる／再試行すると通るといった、再現性が低い挙動になりがちです。

並列そのものがバグであるとは限りません。クライアント・エッジプロキシ・ノード・上流 APIのどこでキューが溜まっているかを分ける必要があります。本稿では、まずローカルの Clash / mihomo で名前と出口を揃えることに限定して扱います。サービス利用規約・地域ポリシーは利用者側の責任で確認してください。

2. 開発者ドメイン稿との違い（IDE 全体 vs モデル API 寄り）

当サイトでは、Cursor の拡張・npm・マーケットプレイスまで含めた「開発者ドメインの束ね方」を別稿で扱っています。そちらはIDE を支える横断的な名前空間が主役です。本稿はCursor 3 で前面に出た並列エージェントに焦点を当て、モデル API やストリーミングに紐づくホストを固定策略または低遅延グループに载せることを優先します。MCP や npm が主役なら MCP・npm・GitHub 稿、ゲートウェイ直叩きなら OpenRouter 稿と分担してください。

購読の読み込み手順は サブスクリプション導入を参照しつつ、以降ではルールの優先順位（細かい DOMAIN を MATCH より上）を繰り返し確認します。

3. タイムアウトの三層：経路・DNS・サービス側

第一に経路層です。並列時はノードごとの遅延差・UDP 扱いが効きやすく、QUIC / HTTP3経路が絡むと「ブラウザでは成功・IDE 内だけ失敗」も起こり得ます。第二に DNS 層です。fake-ipと実接続の策略が食い違うと、ルールを足したつもりが別出口へ落ちます。第三にサービス側です。429 や認証エラーはプロキシを変えても再発し、レート制限・トークン・プランの線が現実的です。三つを混ぜないことが、並列だからといってプロキシのせいに決めつけないコツです。

4. まず置くドメインの種（実測で足し込む前提）

下記は切り分けの出発点であり、プロダクト改修で増減します。実際にログへ出たホストを最優先してください。公式・アカウント周りでは cursor.com や cursor.sh が現れやすい一方、選択したモデルによっては openai.com 配下、anthropic.com、googleapis.com など別クラウドの API エンドポイントへ振れます。広すぎる DOMAIN-SUFFIX は、仕事用の別経路まで巻き込むため、必要になった名前から足すのが安全です。

ルールの評価順は ルールルーティング解説のとおり、狭い DOMAIN 行を上に積みます。購読プロバイダの巨大ルールの末尾へ追記するだけでは効かないことがある点に注意してください。

5. mihomo 例：AGENTS_API 策略へ DOMAIN-SUFFIX

モデル呼び出しと公式フロントを同じ策略に乗せたい場合、専用グループを一つ用意する方法がわかりやすいです。以下は構造サンプルです。実在するプロキシ名・ドメインに置き換えてください。コメントは英語にしています。

# proxy-groups: group for parallel agents + model APIs
proxy-groups:
  - name: AGENTS_API
    type: select
    proxies:
      - LOW_LAT
      STABLE_NODE
      DIRECT

rules:
  - DOMAIN-SUFFIX,cursor.com,AGENTS_API
  - DOMAIN-SUFFIX,cursor.sh,AGENTS_API
  - DOMAIN-KEYWORD,openai,AGENTS_API
  - MATCH,PROXY

DOMAIN-KEYWORD は広くマッチするため濫用に注意してください。Windows の PROCESS-NAME,Cursor.exe のようにプロセス単位で IDE 本体だけ載せる手もありますが、CLI や補助プロセスは別名になることがあります。TUN と DNS の関係は TUN モード解説も参照ください。

6. 策略グループ：select と url-test / fallback

ノードを変えると改善するタイプは、select で出口を固定するか、url-test と fallbackを組み合わせて並列時でも安定した遅延帯を狙うのが実務的です。逆に特定ステータスや認証失敗が返る場合は、プロキシ以前の論理エラーを疑ってください。

チーム利用では、「エージェント用に採用したノード名」を README で共有し、各自のローカル選択ズレによる切り分け迷子を減らせます。

7. DNS・Fake-IP とルールの整合

fake-ip モードでは、見えている IP と実域名の対応がズレ、ルールの DOMAIN が効いていないように見えることがあります。失敗したホストがどの IP に解決されたかと、コアがどの策略へ送ったかをログで突き合わせてください。海外向けモデル API を国内直結（DIRECT）に落としていると、並列でだけタイムアウトが顕在化することもあります。

8. ログドリブンでホストを増やす運用

運用手順の骨子は次のとおりです。（1）タイムアウト時のホスト名を IDE またはコアログから控える。（2）そのホストがどの策略にマッチしたか確認する。（3）意図と異なる出口なら DOMAIN ルールを上に追加する。（4）それでもダメならノード置き換えと DNS を疑う。（5）HTTP ステータスが示すならサービス側要因を調べる。並列エージェントは試行回数が増えるほどログが貯まりやすく、結果としてルールセットの更新頻度が上がります。購読のルールプロバイダと手書きルールのバランスは rule-providers 稿も参照してください。

9. まとめ

Cursor 3の並列エージェントは、単一ツールの利用より同時接続と背後のモデル APIが増えやすいのが実情です。Clash 分流とmihomoのルールでドメインと出口を揃え、DNSと接続ログで層を切り分けると、API タイムアウトの原因が経路側かどうか判断しやすくなります。

一般的なワンタップ VPNや、ドメイン単位の細かい例外が書けない固定プロキシアプリでは、並列で張る細い API ストリームごとに出口を揃えにくく、結果として「エージェントを増やすと不安定」に見えることがあります。ルールベースのコアと購読を前提にしたMihomo 系クライアントは、ホスト名ベースの例外と策略グループを積み上げやすいので、この用途に噛み合いやすいです。まずはクライアントを揃え、 → 無料で Clash をダウンロードし、快適な接続体験を試す ところから環境を整えるのがおすすめです。