TL;DR: Cursor doesn't call your OpenAI Base URL from your local machine. It routes every request through its backend servers on api2.cursor.sh
, so http://localhost:8082
is unreachable — the chat hangs and your proxy logs stay empty. To connect Ollama, LM Studio, LiteLLM, or a custom subscription proxy, you must expose your local port through a public URL — a Cloudflare tunnel is the simplest way, and it is what the Ungate extension automates.
When I first wrote a local Fastify proxy to connect my Claude subscription to Cursor, the setup felt trivial: start the server on port 8082, open Cursor Settings → Models → Override OpenAI Base URL
, paste http://localhost:8082/v1
, and hit save. I typed a prompt into chat, hit Enter, and watched the status indicator spin forever.
I opened terminal logs expecting to see incoming HTTP requests. Nothing. I ran tcpdump
on my loopback interface — zero packets from Cursor.
I spent an hour double-checking port bindings and firewall rules before realizing the issue wasn't in my code. It is in how Cursor is built.
Unlike VS Code extensions, Aider, or Continue.dev — which send LLM API calls directly from your local Node process — Cursor processes chat and agent context on its own remote servers (api2.cursor.sh
).
When you select a model and send a message, the request path is:
Cursor UI
↓
Cursor's cloud backend
↓
Override OpenAI Base URL
↓
LLM Provider
Because the third step originates from Cursor's cloud backend over the public internet, http://localhost:8082/v1
resolves to the backend server's own loopback interface — not your laptop.
This breaks every local setup out of the box. Whether you are trying to route Cursor through Ollama (http://localhost:11434
), LiteLLM (http://localhost:4000
), vLLM, or a custom proxy, Cursor's backend simply cannot reach your machine's localhost
. The safe version of the same idea, cursor localhost base url not working
, is exactly the symptom this post explains.
When http://localhost:8082/v1
is configured in Cursor Settings:
api2.cursor.sh
.http://localhost:8082/v1/chat/completions
from its cloud servers.This makes debugging infuriating. The empty logs suggest your proxy isn't listening, when in reality the request died thousands of miles away before reaching your network.
You can confirm this exact behavior right now without changing your proxy code.
First, check that your local server works:
curl http://localhost:8082/health
Second, start an ad-hoc Cloudflare tunnel to expose that port publicly:
cloudflared tunnel \
--config /dev/null \
--url http://localhost:8082
Grab the generated https://<random>.trycloudflare.com
URL from terminal output and test it from outside your local network (for example, from your phone over LTE):
curl https://<random>.trycloudflare.com/health
Paste that https://...
address into Cursor Settings → Models → Override OpenAI Base URL
. Send a prompt in Cursor chat. Your local proxy logs will instantly light up with incoming requests.
Switch the setting back to http://localhost:8082/v1
, and it immediately hangs again. Same machine, same code, different origin.
To let Cursor's cloud backend talk to a local process on your laptop, you need a public endpoint that routes back to your machine.
A Cloudflare tunnel creates an outbound-only WebSocket connection from your machine to Cloudflare's edge network:
Cursor backend
↓
https://<tunnel>.trycloudflare.com
↓
Cloudflare Edge
↓
Local machine (port 8082)
↑
outbound-only connection
Because your machine initiates the connection outward, you don't need port forwarding, static IPs, or open inbound firewall ports.
Once people switch to a tunnel URL, they sometimes hit a new set of errors that look identical to the localhost issue:
cloudflared
installed locally, it may silently read ~/.cloudflared/config.yml
. If that config contains ingress rules with a catch-all http_status:404
from a previous named tunnel, your quick tunnel will return Cloudflare's 404 page. Prevent this by passing --config /dev/null
(see the command below).trycloudflare.com
quick tunnels share rate limits per IP. For permanent setups, use a named tunnel tied to a free Cloudflare account.8082
, but cloudflared
was started pointing at 8080
.curl https://<tunnel>/health
returns 404
with a server: cloudflare
header, the tunnel isn't reaching your port. If it returns a JSON error, the request reached your proxy.To force a quick tunnel to ignore ~/.cloudflared/config.yml
entirely:
cloudflared tunnel \
--config /dev/null \
--url http://localhost:8082 \
--edge-ip-version 4
If requests in Cursor chat hang or fail when using a custom Base URL:
Override OpenAI Base URL
set to https://
? Plain http://localhost
will never work.curl https://<your-tunnel-url>/health
from a non-local network (e.g., mobile hot spot).server: cloudflare
is present, fix the tunnel flags (--config /dev/null
).There is one more unrelated Cursor quirk: it silently unchecks the Override OpenAI Base URL
setting every few hours, which silently sends requests through your API tokens instead. If your proxy suddenly stops receiving requests, check that checkbox first — I explain this bug in my post about using Claude and ChatGPT subscriptions in Cursor.
Setting up cloudflared
manually every time you launch Cursor gets tedious. That's why I built Ungate — an open-source Cursor extension that connects Claude and ChatGPT subscriptions directly to native Cursor chat.
Ungate handles the entire proxy lifecycle automatically:
cloudflared
binary with --config /dev/null
to bypass local config conflicts.You can install Ungate by searching for @id:orchidfiles.ungate
in Cursor Extensions, or read the full setup guide here: How to use Claude and ChatGPT subscriptions in Cursor.
GitHub repository: https://github.com/orchidfiles/ungate
My Blog: orchidfiles.com
Telegram Channel: @orchidfiles