认证失败时应先检查settings.json是否保存、Base URL末尾斜杠、Model ID是否与/v1/models返回一致、Bearer头是否发出；需通过Verify按钮或curl验证URL，核对模型ID大小写及连字符，并用抓包确认Authorization头存在。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
Cursor配置自己的API后提示认证失败，说明请求已发出但服务端拒绝了身份校验，不是网络不通也不是模型不存在，而是凭证或路径在某个环节没对上。这时候别急着换Key或重装Cursor，先盯住四个关键点：settings.json是否真被保存、Base URL末尾有没有多加斜杠、Model ID是不是和服务端/models接口返回的一致、Bearer头有没有发出去。
确认当前版本的配置入口和持久化状态
打开Cursor → Settings → Models，找“Edit in settings.json”按钮并点击；如果没有这个按钮，就留在图形界面配置页操作，不要手动去~/.cursor找文件——不同版本路径不统一，强行编辑可能白改。
进入JSON编辑器后，先复制整段内容备份到文本文件，再只修改一个模型条目的字段；改完点保存，立刻回到Settings → Models页面，看刚填的值是否回显。如果回显的是旧值，说明配置根本没写入，【此时任何后续排查都无效，必须先解决配置无法持久化的问题】。
检查Base URL格式是否踩坑
方法一：直接验证URL拼接逻辑
把Base URL设为 http://127.0.0.1:8000/v1（注意结尾是/v1，不能是/v1/，也不能是/v1/chat/completions）；然后在终端执行：curl -v http://127.0.0.1:8000/v1/models，看是否返回200和JSON数组。
方法二：用Verify按钮交叉验证
填完Base URL后，点右侧Verify按钮；显示绿色对勾才算通过，红色叉或无反应都代表URL不可达或路径错误。很多用户填成 https://api.xxx.com/v1/（多了斜杠），导致Cursor实际请求地址变成 https://api.xxx.com/v1//chat/completions，服务端直接404。
核对Model ID是否真实存在
第一步：用curl调用/models接口curl -H "Authorization: Bearer fixture-key-not-real" http://127.0.0.1:8000/v1/models
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
第二步：从返回JSON中提取data数组第一个对象的id字段，例如"id": "deepseek-r1"；这个值才是真正的Model ID。
第三步：把提取出的id填进Cursor设置里的Model字段；注意大小写和连字符，比如deepseek-r1不能写成DeepSeek-R1或deepseek_r1。Cursor不会自动修正拼写，错一个字符就报model not found。
这一步最容易被忽略：界面上显示的模型名（如“DeepSeek R1”）只是别名，不是服务端认的ID。填错ID时，有些中转服务返回404，有些返回401，容易误判为Key问题。
验证Bearer认证头是否发出
方法一：用浏览器开发者工具抓包
在Cursor里触发一次AI请求（比如输入“你好”发送），同时打开Chrome或Edge的DevTools → Network标签页，筛选XHR请求，找到/chat/completions接口，点开Headers，检查Request Headers里是否有 Authorization: Bearer xxxxx。
方法二：本地夹具验证法
启动一个最简HTTP服务（如Python的http.server），监听/v1/chat/completions路径，打印所有收到的headers；把Base URL指向该服务，观察是否收到Bearer头。如果没收到，说明Cursor根本没发认证信息——这时候要检查settings.json里apiKey字段名是否拼错（比如写成api_key或APIKEY）。
注意：某些企业环境会剥离Authorization头，即使你填对了Key，请求发出去时头已经被代理或防火墙删掉。这种情况curl本地能通，但Cursor走不出去。
