Cursor BYOK with "Override OpenAI Base URL" hangs on "Planning next moves" (`No first token received`) while the same endpoint works in curl: Cursor's servers can't reach the endpoint

发生场景

Source(s): https://forum.cursor.com/t/openai-byok-custom-base-url-hangs-on-windows-3-22-12-endpoint-works-in-other-clients/173471 Signal: 84 views; staff answer accepted, and the original poster confirmed the fix the next day (October 2026). Status: reported working by source, not reproduced by us.

问题

With "Use OpenAI API Key" and "Override OpenAI Base URL" turned on, every OpenAI-routed model (a custom model, a server-side alias, and built-in GPT-5.5) hangs at "Planning Next Moves" or "Taking longer than expected". After a long wait Cursor sometimes shows a user-provided-key / rate-limit style error (the original poster did not capture its exact wording). The endpoint's reverse-proxy access log shows no request from Cursor. The same endpoint works from curl and another desktop client (GET /v1/models, POST /v1/responses with streaming, POST /v1/chat/completions), and built-in Claude models in Cursor answer normally.

报错原文（已脱敏/规范化）

[composer] No first token received within 2s / 4s / 6s / …

适用环境

Cursor 3.22.12 (Windows x64, stable, user setup); a self-hosted OpenAI-compatible proxy behind an HTTPS Nginx reverse proxy on a non-standard port.

如何确认是这个问题

1. Send a minimal prompt in a new Agent chat with the custom model selected, and watch your reverse proxy's access log. → expect: no request from Cursor arrives, even though Cursor keeps waiting.
2. Open the Cursor developer console. → expect: repeated [composer] No first token received within … warnings.

不是这个问题时 / 边界

The endpoint answers from a cloud-hosted server and Cursor's requests do show up in your access log; then the hang has another cause (our inference).

根因

Per Cursor staff: Cursor did use the override base URL and port, but the requests are sent from Cursor's servers, not from your machine, and those servers could not open a connection to the endpoint. That is why curl works locally but nothing reaches Nginx; the final rate-limit style error is misleading. The original poster then found their firewall (QuFirewall) was dropping incoming TCP connections on that port from cloud-hosted sources.

修复步骤

1. Test the endpoint from a cloud-hosted server outside your own network, for example curl -sS https://<your-host>:<port>/v1/models -H "Authorization: Bearer <KEY>" (staff said to test with curl from a cloud-hosted server; the exact command is our inference). → expect: if it times out or is refused there, Cursor's servers can't reach it either.
2. Allow inbound HTTPS from cloud networks to the endpoint: check port forwarding, the firewall, and any geo-IP or IP allowlist rules (staff). → expect: the original poster fixed the firewall rule and Cursor then worked with the existing key and base URL; no change to the API key, certificate or model alias was needed.
3. Optional, to use the built-in OpenAI models normally in the meantime: switch off "Use OpenAI API Key" in Cursor Settings > Models (staff: the key plus the override sends all OpenAI models to your endpoint; the key and base URL stay saved). → expect: built-in GPT models answer again (workaround only).

如何验证

The request now appears in the reverse-proxy access log, and the Cursor chat streams a reply instead of hanging.

试过没用的办法

none reported.

风险提示

Opening a self-hosted endpoint to inbound internet traffic exposes it: keep key authentication and HTTPS on, open only the API port, and don't expose admin ports (our inference). Don't post your real hostname or key in public threads; the original poster redacted the hostname and offered it to staff privately.

验证范围

Cursor 3.22.12 on Windows with a self-hosted OpenAI-compatible endpoint, October 2026. Staff described the server-side request path as general BYOK behaviour, so other versions are likely affected the same way (our inference).

何时失效

Cursor sends BYOK override requests from the user's machine, or shows a clear "endpoint unreachable" error instead of hanging.