Cursorがつながらない？Clashの接続エラーを直す設定方法

まずCursor本体とClashのどちらで止まっているか確認する

CursorでAI補完が表示されない、ログイン画面が読み込み中のままになる、チャット送信後にタイムアウトするという症状が出ても、原因がCursor本体にあるとは限りません。Cursorは認証、モデルAPI、拡張機能、更新確認など複数のHTTPS通信を行います。Clashを起動している環境では、システムプロキシ、ルール、DNS、TUN、選択中のプロキシノードのどこかで通信が止まることがあります。

最初からTUNやDNSを大きく変更するのではなく、どの層で失敗しているかを分けて確認します。ブラウザーは開けるのにCursorだけが失敗する場合は、Cursorのプロキシ認識やアプリごとの通信方式を疑います。一方、Cursorだけでなく一般的なHTTPSサイトも開けない場合は、Clashのポート、ノード、DNS、またはシステムプロキシの設定が先です。

症状	優先して確認する場所	最初のテスト
ブラウザーもCursorも接続できない	Clashのカーネル、ノード、DNS	Clashのログとプロキシ遅延を確認
ブラウザーは開けるがCursorだけ失敗する	システムプロキシの継承、アプリのプロキシ設定	Cursorを完全終了して再起動
ログインはできるがAI補完だけ失敗する	特定ドメインのルール、ノードの安定性	Clashの接続一覧とルール判定を確認
TUNを有効にした後から失敗する	仮想NIC、DNS hijack、ルート競合	TUNを一時的に無効化して比較

Clashのポートとプロキシ経路を基本テストする

FlClashやClash Verge Revなどのクライアント画面が起動していても、mihomoカーネルが正常に待ち受けているとは限りません。設定を読み込めていない、ポートが別のプロセスと競合している、システムプロキシだけが古いポートを参照している、といった状態でも画面は表示されます。まず現在の設定で使われているmixed-portを確認してください。よくある例は127.0.0.1:7890ですが、実際のポート番号を優先します。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

external-controllerの9090はクライアントがカーネルを操作するための管理用ポートです。CursorやブラウザーのHTTPプロキシとして指定するポートではありません。アプリ側には通常、Clashのmixed-portを指定します。HTTPとSOCKSの両方を受け付けるmixedポートを使えば、アプリ側のプロキシ種類による違いを減らせます。

ターミナルでは、Clashを経由したHTTPS接続と、直接接続を比較できます。以下のドメインはテスト用の例なので、実際の環境で到達可能なHTTPSサイトに置き換えてください。

curl -I --connect-timeout 10 --max-time 20 \
  --proxy http://127.0.0.1:7890 \
  https://example.com

curl -I --connect-timeout 10 --max-time 20 \
  https://example.com

プロキシ指定時だけ成功するなら、Clashのノードとルールは動作している一方、システムプロキシまたはCursorがClashを利用できていない可能性があります。反対に、プロキシ指定でもタイムアウトする場合は、ノードの停止、ルールによる誤った直結、DNS解決、ファイアウォールを確認します。直接接続だけ成功する場合は、Clashのプロキシ経路またはノードが原因です。

Clashの接続ログをCursorの操作時刻と照合する

Cursorを完全に終了し、Clashのログ画面を開いた状態で再起動します。その後、ログイン、AIチャット送信、インライン補完のいずれかを実行してください。該当時刻に新しい接続が表示されないなら、Cursorがシステムプロキシを使っていない、または別のネットワーク設定を参照しています。接続は表示されるものの直後にtimeout、connection reset、tls handshake timeoutが出るなら、選択中のノードや経路が不安定です。

接続先がすぐに切断される：ノードのTLS、SNI、時刻、証明書検証を確認します。
長時間待ってから失敗する：DNS、ファイアウォール、ルール、上流プロキシのタイムアウトを確認します。
短い接続が大量に発生する：Cursorの拡張機能や認証処理が複数のサービスへアクセスしている可能性があります。
接続先がDIRECTになる：そのドメインがルールによって直結へ送られていないか確認します。

モード、ルール、DNSを順番に切り分ける

ClashのGlobalモードで一時的に安定するなら、ノードそのものよりもルール判定に問題がある可能性が高いでしょう。Ruleモードでは、ルールが上から順に評価され、最初に一致した送信先へ振り分けられます。Cursor関連のドメインがDIRECT、存在しない策略グループ、または停止中のプロキシへ送られていないか確認してください。

ただし、すべての通信を常にGlobalへ送ることを恒久対策にするのはおすすめできません。認証、更新、モデル接続、拡張機能が異なるドメインを使う場合があり、1つのドメインだけを追加すれば必ず解決するとは限りません。まずGlobalで再現しないことを確認し、その後Ruleへ戻してClashの接続一覧から実際の送信先と判定結果を比較します。

DNSが原因かを確認する

Clashのプロキシ接続が表示されない場合、ルール以前にドメイン名をIPアドレスへ変換できていない可能性があります。複数のDNSサーバーを設定していても、応答が遅い、地域によって異なるIPを返す、HTTPS接続と相性が悪いといった問題は起こります。ClashのDNSログで失敗がないか確認し、DNS設定を変更した後はキャッシュを消去してから再テストしてください。

DNSを変更するときは、次のように一度に1項目だけを変更します。まずシステムプロキシのままDNSだけを確認し、それでも改善しない場合にTUNのDNS処理を確認します。DNS設定、ルール、TUNを同時に変えると、問題の発生点を判断できません。

ドメイン解決が失敗する場合は、DNSサーバーへの到達性と応答時間を確認する。
解決は成功するがHTTPSだけ失敗する場合は、ノード、TLS、ルールを確認する。
IP直打ちでは接続できてもドメインでは失敗する場合は、DNSまたはSNIの扱いを確認する。
特定のネットワークだけで失敗する場合は、Wi-Fi、社内ネットワーク、VPN、セキュリティソフトの干渉を比較する。

TUNを使う場合の設定と、安全な動作確認

Cursorがシステムプロキシを参照しない、または一部のバックグラウンド通信だけがClashを経由しない場合、mihomoのTUNモードが有効な選択肢になります。TUNは仮想ネットワークインターフェースでシステムの通信を取り込み、アプリがHTTPプロキシ設定を持っていなくてもルール処理へ渡せる仕組みです。ただし、TUNはシステムプロキシよりも広い範囲へ影響するため、最初から有効にするのではなく、通常のプロキシモードで原因を絞ってください。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: false

上記は構造を理解するための例であり、利用中のmihomoとクライアントが対応するフィールドだけを使ってください。設定をそのまま貼り付けるのではなく、FlClashのTUN画面にある項目名とカーネルのドキュメントを確認します。OSによってはVPN構成、ネットワーク拡張、管理者権限の許可が必要です。

Clashのシステムプロキシを有効にし、Cursorを完全終了します。
Clashログを開いたままCursorを起動し、ログインとAI補完を個別にテストします。
接続が記録されない場合だけ、TUNを有効にして必要なOS権限を許可します。
TUN有効後に再テストし、接続一覧、DNSログ、CPU使用率、他のアプリの通信を確認します。
改善しない場合はTUNを無効に戻し、以前の設定との差分を1項目ずつ比較します。

TUN有効後にCursorが直っても、他のVPN、Docker、仮想マシン、企業向けセキュリティソフトが同時に仮想インターフェースを作っていると、ルーティング競合が発生することがあります。TUNを使うときは、同じポートを使用する別のClashプロセスや、別クライアントのシステムプロキシを停止してください。Windowsでは管理者権限やサービス状態、macOSではネットワーク拡張とVPN構成、LinuxではルートとDNS管理サービスの競合を確認します。

Cursor側で確認する項目と復旧手順

Clashのテストが成功しているのにCursorだけがタイムアウトする場合は、Cursorのプロセスが古いプロキシ情報を保持している可能性があります。システムプロキシを変更した後は、ウィンドウを閉じるだけでなく、タスクトレイやバックグラウンドに残ったCursorのプロセスも終了してから再起動してください。再起動後も同じ場合は、Cursorの設定にプロキシ関連項目があるか、環境変数HTTP_PROXY、HTTPS_PROXY、ALL_PROXYが設定されていないかを確認します。

環境変数に古いポート、たとえば現在使っていない127.0.0.1:7890や、停止中の別プロキシが残っていると、ブラウザーとCursorで経路が異なることがあります。Clashを終了した状態でCursorが正常に動くとは限りませんが、環境変数を一時的に外して比較すると、二重プロキシの有無を判断できます。会社や学校の管理端末では、管理ポリシーによって変更できない項目もあるため、無理に削除せず管理者へ確認してください。

Cursorを終了し、Clashのシステムプロキシを一度無効にして状態を記録する。
Clashを再起動し、混合ポートと選択中のプロキシグループを確認する。
システムプロキシを有効にしてから、Cursorを完全終了・再起動する。
ログイン、AIチャット、インライン補完を別々に実行し、Clashログを照合する。
特定の機能だけ失敗する場合は、ルール判定と該当時刻の接続先を比較する。

よくある質問

Cursorだけがタイムアウトする場合、すぐTUNを有効にすべきですか？

先にClashのmixedポート、システムプロキシ、ログ、ルール判定を確認してください。Cursorがシステムプロキシを利用していないことを確認できた場合に、TUNを一時的な比較テストとして有効にします。TUNで直った場合も、DNSやルーティングの競合がないか確認してから常用してください。

ブラウザーは使えるのにCursorのAI補完だけ失敗します。ノードが遅いのでしょうか？

ノードの速度だけが原因とは限りません。Cursorの通信がブラウザーとは異なるルールへ送られている、特定の接続先がDIRECTになっている、アプリが古いプロキシ情報を保持している可能性があります。Cursorの操作時刻とClashの接続ログを照合し、通信が記録されているか確認してください。

Globalモードなら接続できますが、そのまま使っても問題ありませんか？

原因の切り分けには役立ちますが、恒久対策として常にGlobalを使う必要はありません。Globalで成功した後、Ruleモードへ戻し、該当接続のルール判定を確認してください。必要な通信だけを適切なプロキシグループへ送るほうが、国内サービスやローカルネットワークへの影響を抑えられます。

Clashを更新した後からCursorがつながらなくなりました。何を戻せばよいですか？

まず現在のYAML、TUN設定、DNS設定、使用中のカーネル名を保存し、更新前との差分を確認します。ポート番号、ルール、プロキシグループ、DNS、TUNを同時に戻さず、1項目ずつ比較してください。設定フィールドの互換性が原因の場合は、クライアントが採用しているmihomoのバージョンと設定形式も確認します。