目次
エディターにログインできても、モデルの回答、外部ツール、ターミナルのコマンドがすべて接続できるとは限りません。動作が止まったら、アカウントのページ、回答全体、ツールの結果、ダウンロードのうち、何を待っているのかを確認します。それぞれに診断方法とログがあるため、プロキシ設定を一度にすべてやり直す必要はありません。
Cursor のログイン、モデル、MCP、ターミナルを別々に調べる
Cursor では失敗した操作だけをやり直し、Clash の接続記録と照らし合わせます。ログイン、モデルへのストリーミングリクエスト、MCP の子プロセス、統合ターミナルはそれぞれ接続を行い、システムプロキシを使うものも、自身の環境変数だけを読むものもあります。下の表で、その操作に対応する診断箇所を確認してください。
失敗した操作に対応する設定を探す
| 失敗する場所 | 確認する内容 |
|---|---|
| サインインまたはアカウントページ | リダイレクト後の HTTP ステータス、アプリ診断、Clash Connections |
| モデルが Connecting のまま / リクエストがタイムアウトする | Cursor Network Diagnostics、固定ノード、ストリーミング接続 |
| MCP ツールが赤く表示される、または起動に失敗する | 転送方式、プロセスログ、mcp.json、環境変数 |
| 統合ターミナルの git / npm がタイムアウトする | shell の HTTP_PROXY / HTTPS_PROXY と実際のポート |
システムプロキシを設定して Cursor を再起動する
Cursor の基本プロキシ設定
Clash の Proxies でノードを固定する
動作確認済みの特定ノードを選び、モードは Rule のままにします。
Clash の System Proxy を有効にする
システムプロキシが現在の mixed-port を参照していることを確認し、ほかのプロキシクライアントを終了します。
Cursor を完全に終了して開き直す
新しい Cursor プロセスに、OSのプロキシ設定を再度読み込ませます。
Cursor の Network ページを開く
Cursor Settings > Network へ進み、組み込み診断を実行する準備をします。
Settings > Network で診断を実行する
診断結果に応じた次の確認先
| 結果 | 次に確認する場所 |
|---|---|
| 診断に成功し、サインインとモデルも正常 | 基本接続は完了しています。まだ失敗する MCP またはターミナルだけに対処してください |
| 診断に失敗し、Connections に新しいリクエストがない | 診断をやり直し、システムプロキシを確認する。ブラウザーの記録はあるが Cursor の記録がない場合に TUN と比較する |
| 診断に失敗し、リクエストは固定ノードを使うが timeout になる | ノード、接続ネットワーク、接続の持続性を比較する |
| 診断またはサインインで 401 / 403 / 429 が返る | アカウント、権限、使用量の表示を確認し、プロキシポートを変更し続けない |
Run Diagnostics を実行するときは、失敗した項目と時刻を記録し、その直後に Connections で同時刻のリクエストを探します。この対応関係は、赤いアイコンだけを保存するより役立ちます。その後のサインインとモデルのテストでも、同じ固定ノードを使ってください。
Sign in 後にページが開かない、リダイレクトを繰り返す、待機したままになる
Sign in でページが開かない、ログイン画面に戻る、待機が続く場合は、ノードを固定して再試行し、失敗箇所を記録します。外部ブラウザーと Cursor を個別に確認してください。新しいリクエストが Connections にない場合は、発信元のプログラムが現在のプロキシを使うか確認し、timeout、401、403 に応じて対処します。
401 はログイン状態に関する問題が疑われます。403 ではページのアカウントや地域に関する案内を確認し、timeout ではノードとネットワークを比較します。ログイン中は出口を固定し、外部への認証リクエストと Cursor に戻る結果を別々に確認してください。アプリに戻る操作が、必ずプロキシ経由でリモートサービスへアクセスするとは限りません。
Cursor のサインイン修正後に確認する結果
- Sign in のリダイレクトリクエストが Connections に表示される
- ログインの認証完了後に Cursor へ戻れ、外部リクエストには同じ固定の出口が使われている
- Cursor のアカウント領域にサインイン済みと表示される
- Cursor を再起動してもサインイン状態が維持される
Connecting 表示と長い回答の中断を調べる
サインイン成功から分かるのは、認証ページへの経路が少なくとも動作したことです。モデルが Connecting のまま、Network Error が出る、または応答が途中で止まる場合は、モデルリクエストを別に再現してください。短い質問で応答開始を確認し、次に少し長い質問でストリーミング接続が続くかを確認します。その間はノードを切り替えないでください。
Cursor の開発者ツールでは、リクエスト状態を確認できます。コマンドパレットを開き、Developer: Toggle Developer Tools を実行してください。より完全な記録が必要な場合は、Developer: Open Logs Folder を実行します。
Request ID、発生時刻、Cursor のバージョンを記録します。ログを共有する前に、token、コード内容、個人パスを削除してください。
短い応答は成功するが、長い応答が繰り返し中断する
送信経路を固定し、別のノードと別のネットワークを比較して、ストリーミング接続の安定性を確認します。
モデルリクエストが 401 を返す
Cursor のサインイン状態または関連する認証情報を確認してください。通信はすでにサービスへ到達しています。
診断とモデルリクエストが両方 timeout になる
Clash に今回のリクエストが記録されているか確認します。なければアプリのプロキシを、記録されてもタイムアウトするならノードを確認します。
ページが 429 を返す
アカウントの使用量またはレート制限を確認してください。プロキシポートを変更し続ける必要はありません。
Connections に Cursor がない場合は TUN で比較する
システムプロキシを有効にして、Network Diagnostics を再実行します。ブラウザーには記録があるのに Cursor にはない場合は、現在のバージョンやサブプロセスがシステムプロキシを使っていない可能性があります。TUN で比較し、より多くのプロセスの通信を Mihomo に送れます。ただし TUN はリクエストをプロキシに通すだけで、401、403、MCP の設定ミスは修正できません。
TUN 有効化後に同じ診断を実行します。Connections に新しく Cursor の要求が出て成功するなら、以前はシステムプロキシを迂回していました。記録が出ても timeout の場合は、ノードと接続ネットワークを確認します。
MCP の接続方式：ローカル stdio とリモート HTTP
ローカル stdio では Cursor がコマンドを起動し、標準入力と標準出力で通信します。SSE と Streamable HTTP は URL で MCP サービスに接続し、サービスはローカルでもリモートでも実行できます。前者は実行ファイル、引数、環境を、後者は URL、認証、プロキシ経路を確認します。
プロジェクト設定は通常 .cursor/mcp.json、グローバル設定は ~/.cursor/mcp.json にあります。編集前にどちらが有効かを確認し、プロジェクトファイルとグローバルファイルで同名の server を定義しないでください。JSON の解析に成功しても、構文が正しいことしか分かりません。サービスプロセスが起動したかは MCP ログで確認します。
{
"mcpServers": {
"local-tool": {
"command": "/absolute/path/to/node",
"args": ["/absolute/path/to/server.js"],
"env": {
"HTTP_PROXY": "http://127.0.0.1:7890",
"HTTPS_PROXY": "http://127.0.0.1:7890",
"NO_PROXY": "localhost,127.0.0.1,::1"
}
}
}
}spawn ENOENT、解析エラー、ツール呼び出しのタイムアウト
- spawn ENOENT
- Cursor が command を見つけられません。実行ファイルの正しいパスを使い、同じ環境で手動実行してください。
- JSON parse error
- mcp.json の構文が無効です。カンマ、引用符、オブジェクトの階層を確認してください。
- server exited
- ローカルプロセスが起動後に終了しています。stderr、依存関係、作業ディレクトリを確認してください。
- HTTP 401 / 403
- リモート MCP はリクエストを受信済みです。認証とサービス権限を確認してください。
- tool call timeout
- サービスには接続しましたが、呼び出しが時間内に完了していません。サーバーログと外部依存関係を確認してください。
修正後、Cursor の MCP パネルでサービスを再読み込みします。緑の表示だけでは利用可能とはいえません。最小限のツール呼び出しを一度完了し、ログでリクエストと応答を確認してください。ツール自体が外部へアクセスする場合は、そのツールにも独自のプロキシ環境が必要です。
統合ターミナルの環境変数とポート
統合ターミナルは shell の環境を継承し、Cursor の画面のネットワーク設定とは異なる場合があります。HTTP_PROXY、HTTPS_PROXY、NO_PROXY を表示し、現在のポートと除外対象を確認して curl で再試行します。Connections に新しい記録がなければ、ツールがその変数を読み取るか調べてください。
CLASH_PORT=7890
export HTTP_PROXY="http://127.0.0.1:${CLASH_PORT}"
export HTTPS_PROXY="http://127.0.0.1:${CLASH_PORT}"
export NO_PROXY="localhost,127.0.0.1,::1"
curl -I https://example.comWindows PowerShell、Git、npm、各言語のパッケージマネージャーでは、プロキシの読み取り方が異なる場合があります。各ツールのドキュメントに従って設定してください。プロジェクトのソースコードやコミット履歴にプロキシ認証情報をハードコードしないでください。ポートは現在 Clash に表示される値を使い、7890 は例にすぎません。
ログイン、完全な回答、ツール呼び出し、ターミナル要求の検証
サインインの問題はアカウントへ入れた時点、モデルの問題は応答が一つ最後まで完了した時点、MCP は実際にツールを一つ呼び出した時点が完了です。ターミナルでは、以前失敗した git、npm、curl が結果を返す必要があります。四項目を同時にテストする必要はありませんが、それぞれに対応する Connections またはログの証拠を残してください。