Cursor で OpenAI Base URL に localhost が使えない理由と代替3案

Cursor（AIコーディング支援機能を持つコードエディタ）で、Ollama や LM Studio などローカルLLM（自分のPC上で動かす大規模言語モデル）を接続しようとして詰まった経験がある方に向けた記事です。

Cursor の設定画面には「Override OpenAI Base URL」という項目があります。ここに http://localhost:8082/v1 のようなローカルプロキシのURLを入れると、チャットが永久に「Reconnecting...」のまま止まります。プロキシのログも空のままです。

この現象は多くの人が「自分のプロキシ実装のバグ」だと誤解しがちですが、原因はCursorのアーキテクチャ側にあります。ここでは、なぜlocalhostが使えないのか、どの代替手段を選ぶべきかを整理します。

なぜ localhost が届かないのか

VS Code拡張のAiderやContinue.devは、ローカルのNodeプロセスから直接LLMのAPIにリクエストを送ります。この方式ならlocalhostは自分のPCを指すので、そのまま動きます。

Cursorの設計は異なります。チャットやエージェントの処理は、Cursor社が運用するクラウドバックエンド（api2.cursor.sh）を経由します。リクエストの流れは次の通りです。

Cursor UI
  ↓
Cursorのクラウドバックエンド
  ↓
Override OpenAI Base URL 宛のリクエスト
  ↓
LLMプロバイダー

つまり「Override OpenAI Base URL」への接続は、あなたのPCからではなく、Cursorのクラウドサーバーから発生します。そのサーバーにとってのlocalhostは自分自身のことなので、あなたのPCの8082番ポートには一切届きません。TCP接続すら発生しないため、プロキシのログが空欄のままになるのも当然の結果です。

判断軸1: リクエストの発信元はどこか

ツールを選ぶ際にまず確認すべきは「LLMへのリクエストがどこから発信されるか」です。

Cursorのようにクラウドバックエンド経由で処理するエディタは、ローカルのURLを直接受け付けられません。一方、AiderやContinue.devのようにローカルプロセスから直接APIを呼ぶツールは、localhostの指定がそのまま機能します。

手元の環境で切り分けるには、ローカルプロキシを起動した状態でtcpdumpやcurlでヘルスチェックを実行し、Cursor側からアクセスがあるか確認するのが確実です。

curl http://localhost:8082/health
# → 200 OK が返ればローカルサーバー自体は正常

この応答があるにもかかわらずCursorのチャットが固まる場合、原因はネットワーク到達性であり、プロキシの実装ではないと判断できます。

判断軸2: 公開URLをどう用意するか

Cursorのクラウドから届く経路を作るには、ローカルのポートを公開URLとして露出させる必要があります。ここでの選択肢は主に3つです。

方式	特徴	向いている場面
Cloudflare Tunnel	アウトバウンド接続のみで公開URL発行。無料・即席利用可	検証・個人利用・短時間の動作確認
Ungate拡張	Cloudflare Tunnelの構築を自動化するCursor拡張	毎回の手動設定を省きたい継続利用者
ngrok等の常設トンネル	固定サブドメインや認証機能を持つ有料プラン中心	チームで共有・運用体制を整えたい場合

Cloudflare Tunnelは、cloudflaredコマンド一つでローカルポートを一時的な公開URLに変換できます。

cloudflared tunnel \
  --config /dev/null \
  --url http://localhost:8082

実行するとhttps://<ランダム文字列>.trycloudflare.comというURLが表示されます。これをスマートフォンなど別ネットワークからcurlで叩いて200が返れば、外部到達性が確認できたことになります。

curl https://<random>.trycloudflare.com/health
# → 200 OK なら公開URLとして機能している

このURLをCursorの「Override OpenAI Base URL」に貼り替えるだけで、プロキシのログにリクエストが記録されるようになります。設定をhttp://localhost:8082/v1に戻すと、再び固まる現象が確認できるはずです。この再現性こそが、原因がネットワーク到達性にあることの証拠になります。

判断軸3: 運用の継続性とセキュリティ許容度

検証だけで終わるなら、cloudflaredのアドホックトンネルで十分です。ただし毎回起動し直すとURLが変わるため、Cursorの設定を都度書き換える手間が発生します。

継続的に使うなら、Ungateのようにトンネル発行と設定反映を自動化する拡張の利用が候補になります。ただし拡張を導入する場合は、通信内容がどこを経由するか、公式リポジトリのドキュメントで確認しておくのが安全です。

チームで共有するプロキシであれば、認証やアクセス制限を持つ有料トンネルサービスの検討が必要になります。無認証のtrycloudflare.comのURLは推測困難ではあるものの、発行者以外がアクセスできる可能性がある点は把握しておくべきです。

ケース別の推奨

「まず動くか試したい」だけなら、cloudflaredのアドホックトンネルで検証するのが最短です。
日常的にOllamaやLiteLLM経由でCursorを使うなら、Ungateのような自動化拡張で設定の手間を減らす選択が合います。
チームでプロキシを共有する予定があるなら、認証機能を持つ常設トンネルサービスの導入を先に検討すべきです。

あえて見送るべき条件

社内ネットワークにセキュリティポリシー上、外部トンネルの利用制限がある場合は、Cloudflare Tunnelの採用を見送るべきです。この場合はAiderやContinue.devのように、ローカルプロセスから直接APIを呼ぶ設計のツールへの切り替えを検討する方が筋が通ります。

また、単発の動作確認であれば、わざわざ拡張やサービスを導入せずcloudflaredの一時トンネルだけで済ませた方がシンプルです。恒常的な仕組みを先に整えるのは、利用頻度が見えてからでも遅くありません。

まとめ

CursorでlocalhostのBase URLが機能しないのは、実装のバグではなくアーキテクチャ上の制約です。リクエストがCursorのクラウドバックエンドから発信される以上、ローカルのURLは原理的に届きません。

まずcurlでローカルサーバーの健全性を確認し、次にcloudflaredで外部到達性を検証する、という2段階のチェックが切り分けの基本になります。継続利用するかどうかは、トンネルの運用コストとセキュリティポリシーを軸に判断してみてください。