本文目录
浏览器能用、Cursor 超时，要分开看四条网络路径
给 Cursor 配置 Clash，不能只证明浏览器能打开网页。账号登录、模型流式请求、MCP 子进程和集成终端分别发起连接，其中某一条可能读取系统代理，另一条只看自己的环境变量。
先定位失败动作
| 失败位置 | 应该观察什么 |
|---|---|
| 登录或账号页面 | 跳转后的 HTTP 状态、应用诊断与 Clash Connections |
| 模型一直 Connecting / 请求超时 | Cursor Network Diagnostics、固定节点、流式连接 |
| MCP 工具红色或启动失败 | 传输类型、进程日志、mcp.json 与环境变量 |
| 集成终端 git / npm 超时 | shell 的 HTTP_PROXY / HTTPS_PROXY 和实际端口 |
后面只处理正在失败的那一条。为了让结果可比，在 Clash 的 Proxies 中固定节点并保留 Rule 模式；自动组在请求过程中换出口，会让登录、下载和长回复更难判断。
用系统代理建立 Cursor 的基础连接
Cursor 的基础代理配置
在 Clash 的 Proxies 固定节点
选择一条已确认可用的具体节点，模式保持 Rule。
开启 Clash 的 System Proxy
确认系统代理指向当前 mixed-port，并退出其他代理客户端。
完全退出后重开 Cursor
让 Cursor 新进程重新读取操作系统代理设置。
打开 Cursor 的 Network 页面
进入 Cursor Settings > Network，准备运行应用自带诊断。
这一步只负责给 Cursor 一个清楚的系统代理起点。接下来运行应用自带诊断，并把结果与 Clash Connections 对上，才能决定是入口、节点、账号，还是 MCP 自己的问题。
Network Diagnostics 的结果决定下一条排查线
诊断结果怎么接着查
| 结果 | 接下来的位置 |
|---|---|
| 诊断通过，登录和模型也正常 | 基础连接已经完成，只处理仍失败的 MCP 或终端 |
| 诊断失败，Connections 没有新请求 | Cursor 没有进入系统代理，转到 TUN 对照 |
| 诊断失败，请求已走固定节点并 timeout | 比较节点、接入网络和连接持续性 |
| 诊断或登录返回 401 / 403 / 429 | 读取账号、权限或用量提示，不继续改代理端口 |
运行 Run Diagnostics 时记下失败项目和时间，随后在 Connections 查找同一时刻的请求。这个对应关系比单独保存一个红色图标更有用，后面的登录和模型测试都沿用同一固定节点。
Cursor 登录失败，盯着登录按钮后的那次跳转
点击 Sign in 后页面打不开、回到原登录页或一直等待，先保持固定节点，重新点击一次，同时查看 Connections。没有任何登录请求，说明 Cursor 应用没有进入当前系统代理；请求已经出现，再按 timeout、401 或 403 分开处理。
401 更靠近登录状态，403 要看页面给出的账号或地区提示，timeout 才需要比较节点和网络。登录过程中不要让自动策略切换出口，否则授权页和回调可能来自不同地址，结果会表现为反复跳转。
Cursor 登录修复后的结果
- Sign in 跳转请求出现在 Connections
- 授权页面和回调使用同一固定出口
- Cursor 账号区域显示已登录
- 重新启动 Cursor 后登录状态仍然保留
能登录但模型超时，别反复清账号
登录成功说明认证页面至少走通；模型仍停在 Connecting、Network Error 或回复中断，应单独重现模型请求。用短问题验证能否开始返回，再用稍长问题观察流式连接是否持续，期间不要切换节点。
Cursor 的开发者工具可以显示请求状态。打开命令面板运行 Developer: Toggle Developer Tools；需要更完整记录时，运行 Developer: Open Logs Folder。
记录 Request ID、发生时间和 Cursor 版本。分享日志前删去 token、代码内容和个人路径。
短回复成功，长回复反复中断
固定出口，比较另一节点与另一网络，检查流式连接稳定性。
模型请求返回 401
查看 Cursor 登录状态或相关凭据，网络已经到达服务。
诊断和模型请求同时 timeout
对照 Clash 是否有记录，再决定处理入口还是节点。
页面返回 429
检查账号用量或频率限制，不用继续改代理端口。
Connections 里没有 Cursor，请求还没进 Clash
开启系统代理后再次运行 Network Diagnostics。若浏览器有记录、Cursor 仍没有，当前版本或某条子进程可能没有使用系统代理。此时可以用 TUN 做对照，让更多进程流量进入 Mihomo；TUN 只解决入口问题，不能修复 401、403 或 MCP 配置错误。
TUN 打开后，重新运行同一诊断。Connections 新出现 Cursor 请求并成功，说明之前确实绕过了系统代理；记录出现但仍 timeout，则回到节点和网络路径。这个前后对照比长期同时打开多套代理更可靠。
入口切换后的判断
- 系统代理下 Cursor 请求是否出现在 Connections
- 开启 TUN 后是否新增相同目标连接
- 新增连接命中 DIRECT 还是代理策略
- 错误从无记录变成 timeout，还是已经消失
MCP 先看 transport：stdio 和远程 HTTP 是两种连接方式
Cursor 支持本地 stdio、SSE 和 Streamable HTTP 等 MCP 传输。stdio 服务由 Cursor 启动本地命令，第一步是看可执行文件、参数和环境是否正确；SSE 或 Streamable HTTP 才需要检查远程 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"
}
}
}
}MCP “启动失败”和“工具调用超时”要分开
- spawn ENOENT
- Cursor 找不到 command；使用可执行文件的正确路径，并在相同环境里手动运行。
- JSON parse error
- mcp.json 语法错误；检查逗号、引号和对象层级。
- server exited
- 本地进程启动后退出；查看 stderr、依赖和工作目录。
- HTTP 401 / 403
- 远程 MCP 已收到请求，检查认证与服务权限。
- tool call timeout
- 服务已连接但调用没有按时完成，查看服务端日志和外部依赖。
修复后在 Cursor 的 MCP 面板里重新加载服务。可用状态不仅是绿点，还要完成一次最小工具调用，并在日志里看到请求与返回；若工具内部还会访问外网，它也需要自己的代理环境。
Cursor 终端超时，要在终端里验证环境变量
集成终端继承 shell 环境，不一定跟随 Cursor 界面的网络设置。先打印 HTTP_PROXY、HTTPS_PROXY 和 NO_PROXY，再用 curl 访问一个测试地址；如果 Clash 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 或日志证据。
如果模型已经稳定，而某个 MCP 仍报 spawn ENOENT，这篇文章的主路径已经把问题留在 MCP 的本地命令层。此时检查 command 和文件路径即可，不必再动已经可用的 Cursor 网络设置。