本文目录
编辑器能登录，并不代表模型回复、外部工具和终端命令都已连通。遇到卡住时，先确定你正在等待哪个结果：账号页面、完整回复、工具返回，还是一次下载。每种结果都有自己的诊断和日志，不需要把所有代理设置同时重做。
Cursor 登录、模型、MCP 和终端分别怎么排查？
在 Cursor 中只重做失败动作，并对照 Clash 的连接记录。登录、模型流式请求、MCP 子进程和集成终端各自发起连接，有的会使用系统代理，有的只读取自己的环境变量；按下表找对应的诊断位置。
按失败动作查找设置
| 失败位置 | 应该观察什么 |
|---|---|
| 登录或账号页面 | 跳转后的 HTTP 状态、应用诊断与 Clash Connections |
| 模型一直 Connecting / 请求超时 | Cursor Network Diagnostics、固定节点、流式连接 |
| MCP 工具红色或启动失败 | 传输类型、进程日志、mcp.json 与环境变量 |
| 集成终端 git / npm 超时 | shell 的 HTTP_PROXY / HTTPS_PROXY 和实际端口 |
配置系统代理并重新启动 Cursor
Cursor 的基础代理配置
在 Clash 的 Proxies 固定节点
选择一条已确认可用的具体节点，模式保持 Rule。
开启 Clash 的 System Proxy
确认系统代理指向当前 mixed-port，并退出其他代理客户端。
完全退出后重开 Cursor
让 Cursor 新进程重新读取操作系统代理设置。
打开 Cursor 的 Network 页面
进入 Cursor Settings > Network，准备运行应用自带诊断。
在 Settings > Network 运行诊断
诊断结果怎么接着查
| 结果 | 接下来的位置 |
|---|---|
| 诊断通过，登录和模型也正常 | 基础连接已经完成，只处理仍失败的 MCP 或终端 |
| 诊断失败，Connections 没有新请求 | 重新发起诊断，确认系统代理；浏览器有记录但 Cursor 仍无记录时，转到 TUN 对照 |
| 诊断失败，请求已走固定节点并 timeout | 比较节点、接入网络和连接持续性 |
| 诊断或登录返回 401 / 403 / 429 | 读取账号、权限或用量提示，不继续改代理端口 |
运行 Run Diagnostics 时记下失败项目和时间，随后在 Connections 查找同一时刻的请求。这个对应关系比单独保存一个红色图标更有用，后面的登录和模型测试都沿用同一固定节点。
Sign in 后页面打不开、反复跳转或一直等待
点击 Sign in 后页面打不开、回到登录页或一直等待，保持固定节点再试一次，记录失败位置。外部浏览器和 Cursor 分别检查；新请求没有出现在 Connections 时，先确认发起请求的程序使用了当前代理，再按 timeout、401 或 403 处理。
401 更靠近登录状态，403 要看页面给出的账号或地区提示，timeout 才需要比较节点和网络。登录期间保持固定出口，分别查看外部授权请求与返回 Cursor 的结果；返回应用的动作不一定是通过代理访问远端服务。
Cursor 登录修复后的结果
- Sign in 跳转请求出现在 Connections
- 登录授权完成后能正常返回 Cursor，外部请求使用同一固定出口
- Cursor 账号区域显示已登录
- 重新启动 Cursor 后登录状态仍然保留
Connecting 与长回复中断的排查
登录成功说明认证页面至少走通；模型仍停在 Connecting、Network Error 或回复中断，应单独重现模型请求。用短问题验证能否开始返回，再用稍长问题观察流式连接是否持续，期间不要切换节点。
Cursor 的开发者工具可以显示请求状态。打开命令面板运行 Developer: Toggle Developer Tools；需要更完整记录时，运行 Developer: Open Logs Folder。
记录 Request ID、发生时间和 Cursor 版本。分享日志前删去 token、代码内容和个人路径。
短回复成功，长回复反复中断
固定出口，比较另一节点与另一网络，检查流式连接稳定性。
模型请求返回 401
查看 Cursor 登录状态或相关凭据，网络已经到达服务。
诊断和模型请求同时 timeout
查看 Clash 是否有这次请求：没有记录就查应用代理，有记录但超时就查节点。
页面返回 429
检查账号用量或频率限制，不用继续改代理端口。
Connections 没有 Cursor 时，用 TUN 对照
开启系统代理后再次运行 Network Diagnostics。若浏览器有记录、Cursor 仍没有，当前版本或某个子进程可能没有使用系统代理。可以用 TUN 做对照，让更多进程流量进入 Mihomo；TUN 只帮助请求进入代理，不能修复 401、403 或 MCP 配置错误。
TUN 打开后重新运行同一诊断。Connections 新出现 Cursor 请求并成功，说明之前绕过了系统代理；记录出现但仍 timeout，则回到节点和接入网络。
MCP 连接方式：本地 stdio 与远程 HTTP
本地 stdio 由 Cursor 启动命令，通过标准输入输出通信；SSE 和 Streamable HTTP 通过 URL 连接 MCP 服务，服务可在本机或远端。前者检查可执行文件、参数与环境，后者检查 URL、认证与代理路径。
项目配置通常在 .cursor/mcp.json，全局配置位于 ~/.cursor/mcp.json。修改前确认正在生效的是哪一份，避免项目文件和全局文件定义同名 server。JSON 能通过解析，只说明语法正确，服务进程是否启动还要看 MCP 日志。
{
"mcpServers": {
"local-tool": {
"command": "/absolute/path/to/node",
"args": ["/absolute/path/to/server.js"],
"env": {
"HTTP_PROXY": "http://127.0.0.1:7890",
"HTTPS_PROXY": "http://127.0.0.1:7890",
"NO_PROXY": "localhost,127.0.0.1,::1"
}
}
}
}spawn ENOENT、解析错误与工具调用超时
- spawn ENOENT
- Cursor 找不到 command；使用可执行文件的正确路径，并在相同环境里手动运行。
- JSON parse error
- mcp.json 语法错误；检查逗号、引号和对象层级。
- server exited
- 本地进程启动后退出；查看 stderr、依赖和工作目录。
- HTTP 401 / 403
- 远程 MCP 已收到请求，检查认证与服务权限。
- tool call timeout
- 服务已连接但调用没有按时完成，查看服务端日志和外部依赖。
修复后在 Cursor 的 MCP 面板里重新加载服务。可用状态不仅是绿点，还要完成一次最小工具调用，并在日志里看到请求与返回；若工具内部还会访问外网，它也需要自己的代理环境。
集成终端中的环境变量与端口
集成终端继承 shell 环境，不一定跟随 Cursor 界面的网络设置。打印 HTTP_PROXY、HTTPS_PROXY 和 NO_PROXY，核对当前端口与绕过项，再用 curl 重做请求。Connections 没有新记录时，继续检查工具是否读取这些变量。
CLASH_PORT=7890
export HTTP_PROXY="http://127.0.0.1:${CLASH_PORT}"
export HTTPS_PROXY="http://127.0.0.1:${CLASH_PORT}"
export NO_PROXY="localhost,127.0.0.1,::1"
curl -I https://example.comWindows PowerShell、Git、npm 和各语言包管理器读取代理的方式可能不同，应按工具文档设置。不要在项目源码或提交记录中硬编码代理凭据。端口仍以 Clash 当前显示为准，7890 只是示例。
登录、完整回复、工具调用与终端请求的验收
登录问题以成功进入账号为准；模型问题要让一条回复完整结束；MCP 要实际调用一个工具；终端则让原来失败的 git、npm 或 curl 得到结果。四项不必一起测试，但每项都要对应自己的 Connections 或日志证据。