Cursor が遅い・API タイムアウト？開発者ドメインを Clash で分流してコード補完を安定させる（2026）

1. なぜ Cursor だけ「たまに」不安定に見えるか

第一に、トラフィックが一つのドメインに収まっていないことです。エディタ本体の更新確認、拡張の取得、組み込みチャットやモデル呼び出しは、それぞれ別ホストへ振り分けられることがあります。ルールで cursor.com だけをプロキシに載せても、別名の API や CDN が直結のまま残ると、画面は開いているのに補完や課金まわりだけ失敗するといった症状が出ます。

第二に、越境アクセスや事業者ポリシーの影響です。利用地域やアカウント種別によって、到達できるエンドポイントが異なる場合があります。技術的な経路の話と、サービス利用規約の順守は別問題です。本稿は前者の「名前と出口を揃える」観点に限定し、特定の回避手段を推奨するものではありません。

第三に、開発者ツール全般に共通する「遅延のばらつき」です。url-test や fallbackで策略を組んでいても、Cursor 向けドメインだけ別ルールで上書きされていないと、意図しないノードへ落ちることがあります。まずはコアのログでどのホストがどの策略にマッチしたかを確認するのが近道です。

2. ChatGPT / Gemini 記事との違い（IDE・npm エコシステム）

当サイトでは、ChatGPT 向けの固定 IP・fallbackや、Gemini / Google AI と QUIC（HTTP/3）を別稿で扱っています。いずれも「特定クラウドのフロントと API を、意図した経路に乗せる」点では共通しますが、Cursor はデスクトップ IDE と npm・VS Code 互換エコシステムが絡むため、Google 一辺倒のドメインセットでは足りません。

本稿の焦点は、Cursor 公式・関連 API・パッケージ取得（npm）・拡張マーケットなど、開発者が毎日触る名前空間をルールで束ね、同一の低遅延または信頼できる出口に揃えることです。Gemini 記事で詳しく扱う Google 系ドメインの広がりと QUIC 無効化は、必要に応じてそちらを参照し、IDE 固有のホストは本稿で補完するイメージです。

購読の取り込みは サブスクリプション導入ガイドを参照しつつ、以下ではルールの追記位置と評価順に注意します。

3. まず押さえるドメインと npm・拡張の経路

ドメインはサービス改修で変わり得るため、次の一覧は切り分けの出発点として読み、開発者ツールのネットワークタブやコアログで実際のホスト名を確認してください。代表的には、公式サイトやアカウントまわりで cursor.com、一部の配布や更新で cursor.sh が登場することがあります。API 名は世代や機能で異なるため、失敗している URL のホスト部分をその都度メモする運用が安全です。

拡張機能やテーマの取得では、marketplace.visualstudio.com や vscode.blob.core.windows.net、オープンソース側では open-vsx.org などが混ざります。プロジェクトの依存関係インストールでは registry.npmjs.org やミラー、GitHub の github.com / objects.githubusercontent.com が絡みます。Cursor 専用の策略に「全部のインターネット」を載せると、かえって国内向けサービスまで巻き込むので、ログに出た名前から足すのが実務的です。

ルールの評価順は ルールルーティング解説のとおり、細かい DOMAIN 行を、広い MATCH や GEOIP より上に置きます。購読ルールの末尾に追記するだけでは効かないことがある点に注意してください。

4. mihomo ルール例：DOMAIN-SUFFIX と PROCESS-NAME

実務では 「開発者ツール用」の策略グループを一つ用意し、Cursor 関連のドメインと、必要なら npm / マーケットプレイスをそこへ送る形が扱いやすいです。TUN モードや OS 全体プロキシでは、プロセス名で IDE 本体だけを分ける手もあります（クライアントが対応している場合）。

以下は構造の例です。プロキシ名や実在するドメインは環境に合わせて置き換えてください。コメントは英語表記としています。

# proxy-groups: dedicated group for Cursor + dev tooling
proxy-groups:
  - name: DEV_IDE
    type: select
    proxies:
      - LOW_LATENCY
      - NODE_STABLE
      - DIRECT

# rules: place specific DOMAIN rules above broad MATCH / GEOIP
rules:
  - DOMAIN-SUFFIX,cursor.com,DEV_IDE
  - DOMAIN-SUFFIX,cursor.sh,DEV_IDE
  - DOMAIN-SUFFIX,registry.npmjs.org,DEV_IDE
  - DOMAIN-SUFFIX,open-vsx.org,DEV_IDE
  - DOMAIN-SUFFIX,marketplace.visualstudio.com,DEV_IDE
  - PROCESS-NAME,Cursor,DEV_IDE
  - MATCH,PROXY

PROCESS-NAME の表記は OS・クライアントで異なります。Windows では Cursor.exe のように拡張子が付く場合もあるため、ログの表記に合わせてください。macOS や Linux では名前が異なることがあります。

TUN と DNS の相互作用は TUN モードの解説も参照し、名前解決結果と実接続の策略が矛盾していないかを確認してください。

5. 策略グループ：固定・低遅延・自動切替の選び方

API タイムアウトや認証エラーが「ノードを変えると直る」タイプなら、一定の出口に固定できる select 型や、遅延の小さいノードを選び直す url-testの併用が有効です。逆に、レート制限やアカウント側のメッセージが出ている場合は、経路以前の要因を疑った方が早いことがあります。

クロスボーダー環境では、同じ「低遅延」でも UDP の扱いが違うノードがあり、HTTP/3 を使うクライアントではTCP だけ試すより不安定に見えることがあります。次節の DNS とあわせ、まずドメインを策略に揃え、次にトランスポートを疑う順が扱いやすいです。

チームでノードを共有する場合は、「Cursor 用に決めたノード名」を README に書いて揃えると、個人設定の差による切り分け地獄を減らせます。

6. DNS（fake-ip）と名前解決のズレに注意

fake-ip や redir-host など、DNS のモードによっては「ブラウザでは見えている名前」と「コアが握っている名前」がずれ、ルールが意図通りに効いていないように見えることがあります。Claude 向け記事でも触れたとおり、出口 IP とドメインの見え方のセットはサービスによって重要度が変わります。

IDE からの API 呼び出しでは、OS のスタブリゾルバとプロキシコアの DNSのどちらが効いているかが環境差で大きいです。つまずいたら、失敗しているホストの名前解決がどこで行われたかをログに残し、ルールに書いたサフィックスと一致するかを確認してください。

広すぎる DOMAIN-SUFFIX,github.com は、仕事用の別用途まで同じ策略に乗る副作用があります。必要になったサフィックスだけを足す方が安全です。

7. QUIC / HTTP3 の補足（Gemini 記事との分担）

HTTP/3（QUIC）は UDP 上で動くことが多く、プロキシやノードの UDP 扱い・ファイアウォールの影響で、HTTPS（TCP）より失敗しやすい場面があります。ブラウザやランタイムによっては、補助ライブラリの取得だけ QUIC 経由になることもあります。

Google 中心の通信と QUIC 無効化の手順は、Gemini / Google AI の記事で詳しく扱っています。本稿では IDE・npm・Cursor エコシステムに絞り、症状が「ドメインは揃ったのにブラウザだけ不安定」のときは、そちらの QUIC 切り分けを参照する、という相互参照に留めます。

切り分けの基本は変わりません。（1）ルールでホストを意図した策略へ。（2）それでも揺れるなら QUIC を切って比較。（3）改善しなければ別要因をログで追う。

8. 切り分け手順：ログの見方まで

実測では次の順が扱いやすいです。（1）コアのログで、問題のホストが どの策略グループにマッチしたかを確認する。（2）意図したグループに入っているのにタイムアウトするなら、そのグループ内のノードを入れ替え、または url-test の間隔・許容遅延を調整する。（3）HTTP エラーや TLS エラーが出ていれば、経路以外（認証・課金・レート制限）の線も疑う。

開発者ツールのネットワークパネルで、失敗しているリクエストのホスト名とステータスをメモしておくと、ルールに足すべきサフィックスが明確になります。体感の「なんとなく直った」ではなく、どの名前が残っていたかを残すのがポイントです。

CLI やサンドボックス内のツールを併用する場合、IDE 本体と別プロセスになるため、PROCESS-NAME ルールの対象が変わります。スクリプトから npm を叩くときは、そのプロセス経路もログで確認してください。

9. まとめ

Cursorのような AI IDE のつながり悪さは、複数ドメインへの分散と策略のばらつきが重なると、表面だけでは原因が見えにくくなります。まず mihomo ルールで関連ドメインを同じ開発者向け策略に揃え、DNS の取り回しとログを突き合わせ、必要なら Gemini 記事の QUIC 切り分けを参照する——この流れが、ChatGPT・Claude・Google 各稿と重ならない補助線になります。

同じ Clash 系クライアントでも、コアの世代と GUI の表記は移り変わります。手元の環境を最新に近づけ、購読とルールを整理したうえでログを追うのがいちばん確実です。クライアントの入手から始めるなら、 → 無料で Clash をダウンロードし、快適な接続体験を試す ところから整えるのがおすすめです。