Cursor の設定画面で「Override OpenAI Base URL」に http://localhost:11434/v1（Ollama のデフォルト）を入力しても、チャットが「Reconnecting...」のまま止まってしまう——この現象に心当たりのある方は多いのではないでしょうか。ローカル側のプロキシやサーバーのログを確認しても、リクエストが届いた形跡すら見当たりません。
これは設定ミスではなく、Cursor のアーキテクチャに起因する問題です。原因を先に述べると、執筆時点の Cursor では、チャット処理はローカルの Node プロセスから直接 LLM を呼ぶのではなく、Cursor 社が運用するクラウドバックエンドを経由します。そのため「localhost」はあなたの PC ではなく、Cursor 側のサーバー自身を指してしまい、手元のポートには到達できません。
本記事では、この構造を踏まえたうえで、実際に接続を通すための3つの具体的な解決策を手順つきで紹介します。
なぜ localhost が届かないのか
VS Code 拡張の Aider や Continue.dev は、ローカルの Node プロセスから直接 LLM の API にリクエストを送ります。この方式では localhost は自分の PC を指すため、そのまま動作します。
一方 Cursor の設計は異なります。チャットやエージェントの処理は、Cursor 社が運用するクラウドバックエンド（api2.cursor.sh）を経由します。リクエストの流れは次の通りです。
Cursor UI
↓
Cursor のクラウドバックエンド
↓
Override OpenAI Base URL 宛のリクエスト
↓
LLM プロバイダー（Ollama など）「Override OpenAI Base URL」への接続は、あなたの PC からではなく Cursor のクラウドサーバーから発生します。そのサーバーにとっての localhost は自分自身のことなので、あなたの PC の 11434 番ポートには一切届きません。TCP 接続すら発生しないため、プロキシやサーバーのログが空のままになるのも当然の結果です。
まず、ローカル側が正常に動いているかを切り分けます。Ollama を使っている場合、以下のコマンドでモデル一覧が返るかを確認してください。
curl http://localhost:11434/api/tags
# → モデル一覧の JSON が返れば、Ollama 自体は正常に動作しているここで応答があるにもかかわらず Cursor 側が固まる場合、原因はネットワーク到達性であり、Ollama やプロキシの実装ではないと判断できます。
解決策1: Cloudflare Tunnel で公開 URL を作る（推奨）
最も手軽に外部到達性を確保できるのが Cloudflare Tunnel です。アウトバウンド接続のみでインターネットからアクセス可能な公開 URL を、無料かつ即座に発行できます。
1. cloudflared をインストールする（Windows は winget、macOS は Homebrew などで導入できます。バージョンによりインストール手順が異なる場合があります）。
2. Ollama を外部からのアクセスを受け付ける状態にする。デフォルトでは Ollama はローカルからの接続のみを受け付けるため、環境変数 OLLAMA_HOST=0.0.0.0 の設定が必要な場合があります。加えて、クロスオリジンのアクセスを許可する OLLAMA_ORIGINS の設定が必要になる場合もあります。
3. クイックトンネルを起動する。
cloudflared tunnel --url http://localhost:114344. 実行すると https://<ランダム文字列>.trycloudflare.com という URL がターミナルに表示されます。この URL に対して、モデル一覧の疎通確認をしておくと安全です。
5. Cursor の設定を書き換える。「Override OpenAI Base URL」の欄に、表示された URL の末尾に /v1 を付けた形で入力します（例: https://<ランダム文字列>.trycloudflare.com/v1）。OpenAI API Key の入力欄が必須になっている場合は、Ollama 側では実際には使われないため、ダミーの文字列を入力しておく運用が一般的です（バージョンにより表記や必須・任意の扱いが異なる場合があります）。
6. モデル名を追加する。Cursor 側のモデル一覧に、Ollama で使っているモデル名（例: qwen2.5-coder）を手動で追加します。
7. Cursor のチャットで質問を送り、応答が返ってくれば設定完了です。
cloudflared プロセスを止めておくことを推奨します。解決策2: ngrok で一時的に公開する
Cloudflare Tunnel の代わりに、ngrok を使う方法もあります。考え方は同じで、ローカルのポートを一時的な公開 URL に変換します。
ngrok http 11434実行すると、ターミナルに https://xxxx.ngrok-free.app のような URL が表示されます。この URL の末尾に /v1 を付けて、Cloudflare Tunnel の場合と同様に Cursor の「Override OpenAI Base URL」に設定します。
無料プランを使う場合は、いくつかの制限を把握しておく必要があります。まず、無料プランでは起動のたびに URL が変わるため、固定 URL が欲しい場合は有料プランの検討が必要です。また、無料プランには帯域や同時接続数の制限があり、長時間・高頻度の利用には向きません。検証目的での短時間利用であれば、無料プランでも十分に機能します。
Cloudflare Tunnel と ngrok のどちらを選ぶかは、既に使い慣れているツールがあるかどうかで決めて問題ありません。挙動としては大きな差はなく、どちらも「ローカルのポートを一時的な公開 URL に変換する」という役割を果たします。
解決策3: Cursor 側の設定を見直す・別ツールを使う
トンネルを使った公開設定は、あくまで Cursor のクラウド経由という制約を回避するための迂回策です。ローカル LLM の利用を主目的にするのであれば、そもそも Cursor に固執しない選択肢も検討する価値があります。
VS Code 拡張の Aider や Continue.dev は、ローカルのプロセスから直接 LLM の API を呼び出す設計のため、localhost の指定がそのまま機能します。トンネルの構築や URL の書き換えといった手間が一切不要になる点は、大きな利点です。
この選択肢が向いているのは、次のような場合です。
- 社内ネットワークのセキュリティポリシー上、外部トンネルサービスの利用に制限がある場合
- ローカル LLM の利用頻度が高く、トンネルの URL 管理を毎回行うのが負担になっている場合
- Cursor 固有の機能（エージェント機能や特定の UI）への依存度が低く、エディタの乗り換えに支障がない場合
逆に、Cursor の他機能を活用しつつローカル LLM も併用したい場合は、解決策1・2のトンネル方式のほうが現実的な選択になります。
ケース別の推奨
利用シーンによって、選ぶべき方式は変わります。
| 利用シーン | 推奨する方式 | 理由 |
|---|---|---|
| 一時的な動作検証 | Cloudflare Tunnel のクイックトンネル | インストールと起動だけで完結し、後片付けも `cloudflared` の停止のみで済む |
| 個人での継続利用 | ngrok の有料プラン、または固定化したトンネル運用 | URL が変わるたびに Cursor 側の設定を書き換える手間を避けられる |
| チーム・業務での利用 | 認証付きの常設トンネル、またはAider/Continue.devへの切り替え | 無認証の公開URLをチームの業務利用にそのまま使うのはセキュリティ上避けるべきで、認証機能の有無を確認する必要がある |
まとめ
CursorでlocalhostのBase URLが機能しないのは、実装のバグではなくアーキテクチャ上の制約です。リクエストがCursorのクラウドバックエンドから発信される以上、ローカルのURLは原理的に届きません。
要点は次の3つです。
1. まず curl http://localhost:11434/api/tags などでローカルのOllamaが正常に動作しているかを確認する
2. Cloudflare Tunnel やngrokで一時的な公開URLを作り、Cursorの「Override OpenAI Base URL」に設定する
3. ローカルLLMの利用頻度が高い、またはセキュリティポリシー上トンネルが使えない場合は、Aider・Continue.devなどローカル直結型のツールへの切り替えを検討する
まずは解決策1のCloudflare Tunnelから試し、動作を確認したうえで、継続利用するかどうかを運用コストとセキュリティ要件を踏まえて判断してみてください。