Cursor Proxy ネットワーク問題：プロキシ設定、診断、HTTP/2修正

Cursor エディタの右下で、小さなインジケーターが5分間も回り続けています。コードを書いている最中に AI が突然切断され、「Network request failed」と表示されます。ブラウザに切り替えると YouTube は快適に再生され、Google への ping も 20ms しかかかりません。

翌日、会社の社内ネットワークで試すと、IT 部門が設定した多段プロキシのせいで Cursor が起動すら拒否されました。エラーログには ERR_HTTP2_PROTOCOL_ERROR、ECONNREFUSED、certificate verify failed が並び、どれも見覚えはあるのに、組み合わさると意味が分かりません。

丸3日かけて GitHub Issues、Discord、あらゆる「決定版の解決策」を当たり歩いた結果、ようやく分かりました。Cursor のネットワーク問題は単一の原因ではなく、プロキシ、HTTP/2、証明書、DNS という4つの落とし穴が重なっているのです。

この記事は2026年6月に Cursor 公式ドキュメントをもとに更新しました。まず Cursor Settings > Network の診断を確認し、その結果に合わせてプロキシ設定、HTTP/2互換モード、証明書、DNS の順に切り分けます。

見落とされがちな点を先に挙げておきます。プロキシアドレスを正しく入れたのに Cursor が繋がらないケースです。原因は http.proxySupport の既定値が override であること。このモードでは settings.json の http.proxy しか参照せず、システムプロキシは無視されます。新規インストールではこの値が空なので、結局どのプロキシも使われません。詳細は後半で扱うので、まずは覚えておいてください。

設定をいじる前に：3ステップで問題を素早く特定

ネットワーク問題に直面すると、多くの人がいきなりプロキシを変更したり、証明書を削除したり、ソフトを再インストールしたりします。半日かけても解決せず、環境だけが複雑になります。

私のおすすめは、まず5分かけて、どこで問題が起きているかを確認することです。

ステップ 1：Cursor の問題か、ネットワーク自体の問題かを確認

ターミナルを開き、3つのコマンドを実行します。

# 基本ネットワークテスト
ping api.openai.com

# DNS 解決テスト
nslookup api.openai.com

# HTTPS 接続テスト
curl -I https://api.openai.com

ping は通るのに curl が失敗する場合、十中八九プロキシか証明書の問題です。ping すら通らないなら、問題は Cursor ではなくネットワーク層にあります。

ステップ 2：Cursor のエラーログを確認

このステップを飛ばす人が多いですが、ログには原因がはっきり書かれています。

• Windows：%APPDATA%\Cursor\logs\main.log
• macOS：~/Library/Application Support/Cursor/logs/main.log
• Linux：~/.config/Cursor/logs/main.log

メモ帳で開き、ERROR または WARN を検索します。よくあるエラーは次のとおりです。

• ECONNREFUSED → プロキシ設定ミス、またはプロキシサーバーが停止
• ERR_HTTP2_PROTOCOL_ERROR → HTTP/2 プロトコル非互換（最も厄介）
• certificate verify failed → SSL 証明書の問題
• ETIMEDOUT → タイムアウト。DNS が遅いか、通信が制限されている可能性

ステップ 3：Cursor のプロキシ設定が有効か確認

Cursor は Electron ベースのため、システムプロキシを自動では使いません。個別設定が必要です。確認手順：

1. Cursor 設定を開く（Ctrl+, または Cmd+,）
2. proxy を検索
3. http.proxy と https.proxy が空でないか確認

空欄のまま Clash、V2Ray、Shadowsocks などのプロキシソフトを起動している場合、Cursor はプロキシを通らないため当然接続できません。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

プロキシ設定の4つの方法（必ずどれかが合います）

プロキシ問題は Cursor ネットワーク障害の最大の原因です。Cursor は4種類の設定方法をサポートしており、用途がそれぞれ異なります。

プロキシを設定する前に：proxySupport が override になっていないか確認

ローカルのプロキシ（Clash / V2Ray）を起動していてブラウザは普通に通るのに、Cursor だけ繋がらない場合は、すぐにアドレスを入力しないでください。Cursor は VS Code から http.proxySupport 設定を引き継いでおり、4つのモードがあります。

• off：プロキシを使わない
• on：常にシステムプロキシを読み込む
• fallback：まず settings.json の http.proxy を見て、空ならシステムプロキシに戻す
• override：settings.json の http.proxy だけを使い、システムプロキシは無視する

落とし穴はここです。http.proxySupport の既定値は override、http.proxy の既定値は空。両者が重なると、Cursor は入力されたアドレス（存在しない）もシステムプロキシも読まず、丸裸で接続するためログインも AI リクエストも失敗します。

修正は簡単です。設定（Ctrl+,）を開いて proxy support を検索し、Http: Proxy Support を override から on か fallback に変えて Cursor を再起動します。システムプロキシに追従させたいだけなら、この一項目の変更で済むことが多く、以下の4方式は細かく制御したい人向けです。

方法 1：設定画面で直接アドレスを入力（最も簡単）

適用シーン：会社提供の HTTP プロキシなど、明確なアドレスがある場合

操作手順：

1. Cursor 設定を開く
2. proxy を検索
3. http.proxy に入力：http://127.0.0.1:7890（アドレスとポートは環境に合わせて変更）

注意点：

• 認証が必要な場合：http://username:[email protected]:7890
• HTTPS も https.proxy に設定しないと、HTTP リクエストだけがプロキシ経由になる
• Clash は 7890、V2Ray は 10808 など、ソフトごとにポートが異なる

方法 2：環境変数（コマンドライン起動向け）

適用シーン：ターミナルから Cursor を起動する、または一時的にプロキシを切り替えたい場合

Windows (PowerShell)：

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
cursor

macOS/Linux：

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
cursor

グローバル設定を汚さず、ターミナルを閉じれば無効になります。

方法 3：システムプロキシ自動検出（企業ネットワーク向け）

適用シーン：IT 部門が PAC ファイルや透過プロキシを設定している場合

Cursor はシステムプロキシの読み込みに対応していますが、デフォルトはオフです。有効化手順：

1. Cursor の起動設定を開く

   • Windows：デスクトップショートカットを右クリック → プロパティ → リンク先
   • macOS：/Applications/Cursor.app/Contents/Info.plist を編集

2. 起動引数を追加：--proxy-auto-detect

これで Cursor がシステムのプロキシ設定を自動読み込みします。

方法 4：証明書エラーを強制無視（非推奨だが効く）

適用シーン：企業プロキシが HTTPS を中間者解読し、証明書検証に失敗する場合

警告：セキュリティが低下します。一時利用に留めてください。

起動引数：--ignore-certificate-errors

完全なコマンド（Windows）：

& "C:\Users\ユーザー名\AppData\Local\Programs\Cursor\Cursor.exe" --ignore-certificate-errors

SSL 証明書を検証しなくなるため、多くの企業プロキシ問題を回避できます。最後の手段であり、可能なら使わないでください。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

HTTP/2 の落とし穴：なぜブラウザは使えるのに Cursor はダメなのか

ブラウザでは OpenAI API に正常アクセスでき、curl もデータを返すのに、Cursor だけ ERR_HTTP2_PROTOCOL_ERROR を出します。

すぐに「バージョンのバグ」と決めつけず、まず Cursor の Network 診断で HTTP/2 互換性の問題かどうかを確認し、そのうえで HTTP/1.1 を試します。

優先策：Cursor 設定で HTTP/2 互換モードを切り替える

1. Cursor 設定を開く
2. Network 関連設定へ進む
3. Run Diagnostics を実行する
4. 診断やログが HTTP/2 を示す場合、Disable HTTP/2 を有効にする、または HTTP Compatibility Mode を HTTP/1.1 にする
5. ウィンドウを閉じるだけでなく、Cursor を完全終了して再起動する

パネルを毎回開きたくない場合は、settings.json に直接書けます。

{
  "cursor.general.disableHttp2": true
}

これは公式にサポートされたキーで、パネルの Disable HTTP/2 と同じ効果があり、プロキシ設定と並べて書けます。パネルのトグルもこのキーも持たない古いバージョンでだけ、起動引数 cursor --disable-http2 を最後の手段として使います。

DNS を切り替えてみる：HTTP/2 失敗は経路の問題のこともある

HTTP/2 エラーの一部は Cursor ではなく、DNS が解決した接続先ノードに原因があります。一部の DNS は Cursor の API ドメインをハンドシェイクに失敗する Cloudflare ノードへ解決し、SSL handshake エラーを起こします。公式フォーラムでは、システム DNS を Cloudflare（1.1.1.1）や Google（8.8.8.8）に変えたら HTTP/2 がそのまま回復した、という報告が複数あります。HTTP/2 を無効化すると明らかに遅くなり、HTTP/1.1 を常用したくない場合は、先に DNS を切り替えてから HTTP/2 を一度有効化して試してください。

代替策：プロキシソフトの設定変更（Clash の例）

config.yaml を開き、プロキシルールに以下を追加：

proxies:
  - name: "あなたのプロキシ名"
    type: http
    server: 127.0.0.1
    port: 7890
    http-version: "1.1"  # HTTP/1.1 を強制

Clash と Cursor を再起動します。プロキシ経路上の HTTP/2 ネゴシエーションが原因なら安定しやすくなります。まだ失敗する場合は、起動引数を増やす前に診断結果とログに戻ってください。

企業ネットワーク環境の最終的な解決策

社内ネットワークは最も厄介で、強制プロキシ、SSL 中間者、ファイアウォール、社内 DNS など、前述の問題がすべて重なります。

企業環境で確実に使える設定手順をまとめました。

設定チェックリスト（順番に実行）

1. 会社のプロキシ情報を取得

IT 部門に以下を確認します。

• プロキシサーバーのアドレスとポート（例：proxy.company.com:8080）
• 認証の要否
• PAC 自動設定の有無
• SSL 復号化の有無（ある場合はルート証明書を取得）

2. Cursor のプロキシを設定

settings.json に以下を追加：

{
  "http.proxy": "http://username:[email protected]:8080",
  "https.proxy": "http://username:[email protected]:8080",
  "http.proxySupport": "override",
  "http.proxyStrictSSL": false,
  "cursor.general.disableHttp2": true
}

注意点を3つ。http.proxy を手動で入れたら、http.proxySupport は override のままが最もきれいで、Cursor をこの社内プロキシだけに通せます。SSL 中間者がある場合は http.proxyStrictSSL: false が必須です。社内プロキシは HTTP/2 を遮断することが多いので、cursor.general.disableHttp2 を true にしておくと切り分けが一手間減ります。

3. 会社のルート証明書をインポート

SSL 復号化がある場合、ルート証明書をインポートしないと certificate verify failed が続きます。

Windows：

1. ルート証明書（.crt または .cer）をダブルクリック
2. 「証明書のインストール」→「ローカル コンピューター」→「信頼されたルート証明機関」

macOS：

🔥 需要のない製品に3ヶ月も無駄にするな！少額の予算で Adsterra を使い、SaaS の訴求を今すぐ検証 ➡️

今すぐ検証 →広告

sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain 会社ルート証明書.crt

4. 起動引数を組み合わせたスクリプトを作成

Windows は .bat、macOS/Linux は .sh を作成します。

Windows (start-cursor.bat)：

@echo off
set HTTP_PROXY=http://proxy.company.com:8080
set HTTPS_PROXY=http://proxy.company.com:8080
start "" "C:\Users\ユーザー名\AppData\Local\Programs\Cursor\Cursor.exe" --proxy-auto-detect --disable-http2

macOS/Linux (start-cursor.sh)：

#!/bin/bash
export HTTP_PROXY=http://proxy.company.com:8080
export HTTPS_PROXY=http://proxy.company.com:8080
/Applications/Cursor.app/Contents/MacOS/Cursor --proxy-auto-detect --disable-http2

以後、アイコンではなくこのスクリプトから起動してください。

5. 接続テスト

起動後、開発者ツール（Ctrl+Shift+I または Cmd+Option+I）を開き、Network タブで AI に質問してリクエストが正常に返るか確認します。

まだ失敗する場合は、ログファイルの最新 ERROR を確認し、前述の手順を再度実行してください。

まとめ

Cursor のネットワーク問題は、結局次の4点に集約されます。

1. プロキシが効かない → まず http.proxySupport が override か確認し、次に http.proxy と環境変数を見る
2. HTTP/2 プロトコル競合 → Network 設定の Disable HTTP/2 / HTTP Compatibility Mode: HTTP/1.1 を先に使い、必要なら DNS を切り替える
3. SSL 証明書検証失敗 → ルート証明書をインポート、または一時的に検証を無効化
4. 企業ネットワーク制限 → プロキシ + 証明書 + 起動引数の組み合わせ

私が3日かかったのは、これらが重なって見えることを知らなかったからです。プロキシを直しても HTTP/2 でエラー、HTTP/2 を切っても証明書エラー、証明書を入れても DNS が解決しない——毎回別のエラーにすり替わりました。

最初からこの順序で切り分けていれば、30分で済んだはずです。

最後に一点：エラーログは飾りではありません。問題が起きたら最新の ERROR を確認してください。答えの90%はそこにあります。残り10%は、ログを添えて GitHub Issues や Discord で質問すれば、より早く原因を特定できます。

ネットワーク問題自体は怖くありません。怖いのは当てずっぽうの変更です。この記事が72時間を節約する助けになれば幸いです。

公式資料と次に読む記事

• Cursor 公式ネットワーク・プロキシ・トラブルシューティング
• Cursor 公式ドキュメント
• Cursor Pricing
• Cursor よくあるエラー解決ガイド
• Cursor Pro サブスクリプション完全ガイド
• Cursor 無料枠完全ガイド