Cursor 企業ネットワークプロキシ設定：HTTP_PROXY から証明書インポートまでの完全ガイド

Send をクリックすると、Cursor の Agent パネルに Network error が表示される。グローバルプロキシは有効なのに、なぜ接続できないのか？

答えは Electron v25+ のネットワークスタックにあります。Cursor と VS Code、OS はそれぞれ別のプロキシ設定を使い、互いに共有しません。この記事では、企業ネットワークでのプロキシ設定を最初から整理します。HTTP_PROXY 環境変数、settings.json のプロキシ設定、HTTP/2 プロトコルの互換性、SSL 証明書のインポート、Anygress 透過プロキシまで。Windows、Mac、WSL2 の 3 環境をカバーします。

なぜ Cursor はシステムプロキシを継承しないのか？

Cursor は Electron v25+ で構築されています。Electron のネットワークスタックは Chrome と同じで、OS や親プロセスのプロキシ設定を自動継承しません。VS Code はシステムプロキシを読み取れますが、Cursor は独自の設定が必要です。

環境変数の扱いも厄介です。ターミナルで export HTTP_PROXY=... しても、Dock やデスクトップアイコンから Cursor を起動すれば、その変数は渡りません。同じターミナルから cursor コマンドで起動した場合だけ有効になります。

そのため、企業ネットワークでは Cursor の settings.json を直接編集するのが最も確実です。

公式ドキュメントの見解

Cursor の Network Configuration によると、企業環境では 3 つのプロキシ設定方法があります。

1. 環境変数：HTTP_PROXY、HTTPS_PROXY、NO_PROXY（ターミナル起動時のみ有効）
2. settings.json：http.proxy、http.proxySupport、http.proxyStrictSSL
3. 起動引数：--proxy-server、--proxy-auto-detect、--disable-http2

それぞれ適した場面があり、後述で順に解説します。

HTTP_PROXY 環境変数の設定

環境変数は最も軽量な方法ですが、Cursor を設定済みのターミナルから起動する必要があります。

Windows PowerShell

# プロキシを設定（認証付き）
$env:HTTP_PROXY = "http://username:[email protected]:8080"
$env:HTTPS_PROXY = "http://username:[email protected]:8080"

# ローカルアドレスはプロキシを経由しない
$env:NO_PROXY = "localhost,127.0.0.1,.internal.corp"

# 同じターミナルから Cursor を起動
cursor

macOS / Linux

# Bash/Zsh
export HTTP_PROXY="http://username:[email protected]:8080"
export HTTPS_PROXY="http://username:[email protected]:8080"
export NO_PROXY="localhost,127.0.0.1,.internal.corp"

# Cursor を起動
cursor

WSL2 の特殊な扱い

WSL2 には独立した仮想 NIC があり、Windows ホストと同一サブネットにいません。Windows のプロキシ設定は WSL2 内に自動同期されません。

KiloClaw - 企業向けマネージド OpenClaw、AI エージェントのオーケストレーションとスマートルーティングを加速

今すぐ始める →広告

graftcp で透過 TCP プロキシを行う方法があります。

# graftcp をインストール
sudo apt install graftcp

# プロキシアドレスを設定（graftcp.conf）
proxy_addr = "192.168.1.100:7890"  # Windows ホストのプロキシアドレス

# graftcp で Cursor を起動
graftcp cursor

よくある落とし穴：

• Dock / デスクトップアイコンから起動 → 環境変数が効かない
• HTTP_PROXY だけ設定して HTTPS_PROXY を忘れる → Cursor API リクエスト（すべて HTTPS）がプロキシを通らない
• NO_PROXY に .internal.corp を入れ忘れる → イントラネット通信までプロキシ経由になり、逆に遅くなる

毎回ターミナルから起動するのが面倒なら、settings.json の方が楽です。

settings.json によるプロキシ設定（推奨）

Cursor を開き、Cmd+Shift+P（Mac）または Ctrl+Shift+P（Windows）を押して Preferences: Open User Settings (JSON) を入力します。

settings.json に次の項目を追加します。

{
  "http.proxy": "http://username:[email protected]:8080",
  "http.proxySupport": "override",
  "http.proxyStrictSSL": false,
  "http.noProxy": ["localhost", "127.0.0.1", "*.internal.corp"],
  "cursor.general.disableHttp2": true,
  "cursor.general.disableHttp1SSE": true
}

各項目の意味：

再起動が必要。

settings.json を変更したら、Cursor を完全に終了してから再度起動してください。ウィンドウの再読み込み（Cmd+R）ではネットワーク設定は再読み込みされません。

Windows ショートカットの起動引数：

settings.json を触りたくない場合、ショートカットに引数を追加できます。

cursor.exe --proxy-server="http://proxy.company.com:8080" --proxy-auto-detect --disable-http2

settings.json と同等の効果があり、起動のたびに適用されます。

HTTP/2 プロトコルの非互換と対処

Cursor の Agent 機能は HTTP/2 の双方向ストリーミングに依存しています。リアルタイムチャット、コード補完、多ターン対話は、HTTP/2 の長接続とストリーム配信が前提です。

問題は、多くの企業プロキシが HTTP/2 に対応していないことです。

Zscaler や Netskope などの SSL インスペクション系プロキシは、HTTP/1.1 のみを処理します。Cursor が送る HTTP/2 リクエストは、プロキシ側で切断されたり、文字化けしたり、タイムアウトしたりします。

症状：

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

価格を見る →広告

• Agent パネルが Thinking... のまま止まる
• コード補完がたまに動き、たまにエラーになる
• Chat モードは正常、Agent モードだけエラーだらけ

対処法：HTTP/2 を無効化し、HTTP/1.1 SSE にダウングレードする。

{
  "cursor.general.disableHttp2": true
}

または起動引数：

cursor --disable-http2

無効化後、Cursor は HTTP/1.1 の Server-Sent Events（SSE）でストリーミングします。SSE は一方向で HTTP/2 双方向ほど効率的ではありませんが、互換性は高いです。

補足：--disable-http2 と settings.json の disableHttp2 が両方ある場合、起動引数が優先されます。HTTP/2 を確実に無効にしたいなら、両方設定しておくと安心です。

Cursor Forum の報告によると、この方法で多くの企業ユーザーが Agent 問題を解決しています。Cursor http/2 requests don’t go through proxy setting では、HTTP/2 を無効化したあと Agent が正常に戻った、というフィードバックがあります。

SSL 証明書のインポート（企業 MITM 検査）

企業プロキシが SSL 復号を行うと、元の証明書をプロキシ自身の証明書に差し替えます。Netskope や Zscaler にはこの機能があります。

Cursor が cursor.com や api2.cursor.sh に接続すると、Let’s Encrypt や DigiCert ではなく、企業プロキシが署名した証明書が返ります。検証に失敗して接続が切れます。

症状：

• TLS handshake timeout
• certificate signature failure
• Agent パネルに CERT_AUTHORITY_INVALID

方法 1：企業ルート証明書をシステム証明書ストアにインポート（Windows）

1. Win+R を押し、certmgr.msc を入力
2. Trusted Root Certification Authorities → Certificates を展開
3. 右クリック → All Tasks → Import
4. 企業ルート証明書ファイル（.cer または .pem）を選択
5. 完了後、Cursor を再起動

OS が企業証明書を信頼すれば、Cursor も信頼します。

方法 2：環境変数で証明書を指定（推奨）

Cursor は SSL_CERT_FILE と SSL_CERT_DIR 環境変数に対応しています。

# 単一の証明書
export SSL_CERT_FILE=/path/to/company-root-ca.pem
cursor

# 証明書ディレクトリ
export SSL_CERT_DIR=/etc/ssl/certs
cursor

システム証明書ストアを変更せず、Cursor だけに適用できる柔軟な方法です。

方法 3：SSL 厳密検証をオフにする（非推奨）

{
  "http.proxyStrictSSL": false
}

証明書検証を回避できますが、セキュリティは下がります。テスト環境向けで、本番では非推奨です。

Mac / Linux での証明書インポート：

# Debian/Ubuntu
sudo cp company-root-ca.pem /usr/local/share/ca-certificates/
sudo update-ca-certificates

# macOS
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain company-root-ca.pem

インポート後、Cursor を再起動してください。

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

今すぐ始める →広告

Anygress と cursor-api-proxy（上級設定）

企業ネットワーク、リモートサーバー、プライベートネットワークなど、標準プロキシ設定だけでは足りない場面があります。オープンソースの cursor-api-proxy（GitHub: anyrobert/cursor-api-proxy）が、このようなケース向けです。

仕組み：

cursor-api-proxy はローカルでプロキシサービスを立て、Cursor の API リクエストを実サーバーへ転送します。途中で TLS 証明書の差し替え、Tailscale による NAT 越え、API キーの注入などが可能です。

設定例：

# リポジトリをクローン
git clone https://github.com/anyrobert/cursor-api-proxy
cd cursor-api-proxy

# 環境変数を設定
export CURSOR_BRIDGE_TLS_CERT=./macbook.tail4048eb.ts.net.crt
export CURSOR_BRIDGE_TLS_KEY=./macbook.tail4048eb.ts.net.key
export CURSOR_BRIDGE_API_KEY=your-secret-key
export CURSOR_PROXY_URL=http://127.0.0.1:8765

# 起動（Tailscale TLS 付き）
npm start -- --tailscale

Cursor 側では、このサービスをプロキシ先に指定します。

{
  "http.proxy": "http://127.0.0.1:8765"
}

向いている場面：

• 社内ネットワークで cursor.com への直接接続が禁止されている
• リモートサーバーにパブリックインターネット出口がなく、Tailscale 経由が必要
• リクエストに統一 API Key を注入したい（複数ユーザー共有）
• プライベートデプロイで API を内部ゲートウェイ経由にしたい

標準プロキシより複雑ですが、柔軟性は高い。ある程度の運用スキルがあるチーム向けです。

まとめ

企業ネットワークで Cursor のプロキシを設定する際は、次の順で確認してください。

1. まず settings.json — http.proxy + http.proxySupport: "override"
2. HTTP/2 を無効化 — 企業プロキシ非対応なら disableHttp2: true
3. 証明書を確認 — TLS handshake timeout や CERT_AUTHORITY_INVALID なら企業ルート証明書をインポート
4. 複雑な場面は cursor-api-proxy — リモートサーバー、プライベートネットワーク、Tailscale 経由

よくあるエラーと対処：

設定後はウィンドウの再読み込みではなく、Cursor を完全に再起動してください。