Cursor で Clash プロキシを設定する方法：ログイン、モデル接続、MCP、ターミナルのタイムアウトを修正する

Cursor を Clash 経由に設定するときは、ブラウザでWebページが開くことだけを証拠にできません。アカウントのサインイン、モデルのストリーミングリクエスト、MCP サブプロセス、統合ターミナルは、それぞれ別に接続します。ある経路はシステムプロキシを参照し、別の経路は自身の環境変数だけを見る場合があります。

以降は、現在失敗している経路だけに対処してください。結果を比較できるよう、Clash の Proxies でノードを固定し、Rule モードを維持します。自動グループがリクエスト途中で送信経路を変えると、サインイン、ダウンロード、長い応答の判断が難しくなります。

この手順は、Cursor に明確なシステムプロキシの開始点を与えるだけです。続いて組み込み診断を実行し、その結果を Clash Connections と照合して初めて、入口、ノード、アカウント、MCP 自体のどこに問題があるか判断できます。

Run Diagnostics を実行するときは、失敗した項目と時刻を記録し、その直後に Connections で同時刻のリクエストを探します。この対応関係は、赤いアイコンだけを保存するより役立ちます。その後のサインインとモデルのテストでも、同じ固定ノードを使ってください。

Sign in をクリックした後にページが開かない、元のサインイン画面へ戻る、または待機し続ける場合は、固定ノードを維持してもう一度クリックし、同時に Connections を確認します。サインインリクエストがなければ、Cursor アプリは現在のシステムプロキシに入っていません。リクエストが表示されたら、timeout、401、403 を分けて対処してください。

401 はサインイン状態に近い問題です。403 ではページに表示されるアカウントまたは地域の案内を確認し、timeout の場合にノードとネットワークを比較します。サインイン中に自動ポリシーで送信経路を変えないでください。認証ページとコールバックが異なるアドレスから届き、リダイレクトを繰り返すことがあります。

サインイン成功から分かるのは、認証ページへの経路が少なくとも動作したことです。モデルが Connecting のまま、Network Error が出る、または応答が途中で止まる場合は、モデルリクエストを別に再現してください。短い質問で応答開始を確認し、次に少し長い質問でストリーミング接続が続くかを確認します。その間はノードを切り替えないでください。

Cursor の開発者ツールでは、リクエスト状態を確認できます。コマンドパレットを開き、Developer: Toggle Developer Tools を実行してください。より完全な記録が必要な場合は、Developer: Open Logs Folder を実行します。

Request ID、発生時刻、Cursor のバージョンを記録します。ログを共有する前に、token、コード内容、個人パスを削除してください。

システムプロキシを有効にしてから Network Diagnostics を再実行してください。ブラウザの記録はあるのに Cursor がまだ表示されない場合、現在のバージョンまたは一部のサブプロセスがシステムプロキシを使っていない可能性があります。TUN と比較し、より多くのプロセストラフィックを Mihomo へ取り込んでください。TUN が解決するのは入口の問題だけであり、401、403、MCP の設定エラーは修正できません。

TUN を有効にした後、同じ診断をもう一度実行します。Connections に Cursor のリクエストが新しく表示されて成功した場合、それまではシステムプロキシを迂回していました。記録は表示されても timeout のままなら、ノードとネットワーク経路へ戻ってください。この前後比較は、複数のプロキシ方式を常時有効にするより確実です。

Cursor は、ローカル stdio、SSE、Streamable HTTP などの MCP 転送方式に対応しています。stdio サービスは Cursor が起動するローカルコマンドです。最初に実行ファイル、引数、環境が正しいか確認してください。リモート URL、認証、プロキシ経路の確認が必要なのは、SSE または Streamable HTTP の場合です。

プロジェクト設定は通常 .cursor/mcp.json、グローバル設定は ~/.cursor/mcp.json にあります。編集前にどちらが有効かを確認し、プロジェクトファイルとグローバルファイルで同名の server を定義しないでください。JSON の解析に成功しても、構文が正しいことしか分かりません。サービスプロセスが起動したかは MCP ログで確認します。

修正後、Cursor の MCP パネルでサービスを再読み込みします。緑の表示だけでは利用可能とはいえません。最小限のツール呼び出しを一度完了し、ログでリクエストと応答を確認してください。ツール自体が外部へアクセスする場合は、そのツールにも独自のプロキシ環境が必要です。

統合ターミナルは shell 環境を継承するため、Cursor 画面のネットワーク設定に従うとは限りません。まず HTTP_PROXY、HTTPS_PROXY、NO_PROXY を表示し、curl でテストアドレスへアクセスしてください。Clash Connections に記録がなければ、変数が反映されていないか、ポートが誤っています。

Windows PowerShell、Git、npm、各言語のパッケージマネージャーでは、プロキシの読み取り方が異なる場合があります。各ツールのドキュメントに従って設定してください。プロジェクトのソースコードやコミット履歴にプロキシ認証情報をハードコードしないでください。ポートは現在 Clash に表示される値を使い、7890 は例にすぎません。

サインインの問題はアカウントへ入れた時点、モデルの問題は応答が一つ最後まで完了した時点、MCP は実際にツールを一つ呼び出した時点が完了です。ターミナルでは、以前失敗した git、npm、curl が結果を返す必要があります。四項目を同時にテストする必要はありませんが、それぞれに対応する Connections またはログの証拠を残してください。

モデルが安定していても特定の MCP が spawn ENOENT を返す場合、この記事の手順で問題は MCP のローカルコマンド階層まで絞られています。command とファイルパスだけを確認し、すでに動作する Cursor のネットワーク設定は変更しないでください。