Cursor 无法连接怎么办？Clash 超时与网络错误排查

先判断是 Cursor 还是 Clash 在超时

Cursor 打不开、AI 补全一直转圈、聊天窗口提示 Network Error，并不一定说明节点失效。一次请求通常要经过 Cursor 应用、操作系统代理设置、Clash 或 mihomo 本地端口、规则匹配、代理节点以及远端 AI 服务多个环节。任何一层返回超时、连接重置或 TLS 错误，Cursor 都可能只显示一条比较笼统的网络提示。

排查前先记录三个信息：Cursor 的具体提示、Clash 日志中的连接记录，以及问题发生时使用的模式和节点。浏览器能够打开普通网页，只能证明部分域名可访问；它不能证明 Cursor 访问的所有服务都能通过当前规则和节点完成连接。反过来，如果 Clash 日志中完全没有 Cursor 发出的请求，也不能立即判断为节点故障，可能是 Cursor 没有读取系统代理，或者请求被应用自己的网络层拦截。

检查 Clash 运行状态与基础代理端口

先确认 FlClash、Clash Verge Rev 或其他客户端中的内核确实处于运行状态。客户端窗口打开并不代表 mihomo 已经成功启动；配置解析失败、端口被占用、TUN 权限不足，都可能造成界面显示正常但实际没有转发流量。检查日志中是否出现内核启动成功、监听端口和配置加载完成等信息。

常见的 HTTP、HTTPS 与 SOCKS 混合端口是 7890，但实际端口必须以当前配置为准。控制接口常见为 127.0.0.1:9090，它用于客户端读取状态和切换策略，不是给 Cursor 填写的代理端口。一个基础配置可能类似下面这样：

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

在客户端中检查系统代理开关是否已经开启，并确认系统代理地址是本机回环地址，而不是局域网地址或旧客户端留下的端口。Windows 的“设置→网络和 Internet→代理”、macOS 的“系统设置→网络→当前网络→详细信息→代理”都可以查看当前值。若系统代理仍指向已经退出的旧 Clash 进程，所有依赖系统代理的应用都会表现为无法连接。

通过日志确认请求是否进入规则系统

临时把日志级别设为 info 或 debug，重新打开 Cursor、发送一条测试消息或触发一次补全，然后立即查看 Clash 的连接记录。重点观察目标域名、使用的策略组、最终节点以及失败原因。测试结束后建议恢复为 info，避免长期使用 debug 产生大量日志。

• 没有任何相关请求：优先检查 Cursor 是否读取系统代理，或是否启用了独立的网络代理设置。
• 命中 DIRECT：规则可能把请求错误地分到直连，导致当前网络无法建立连接。
• 命中 REJECT：规则集或自定义规则主动拒绝了该域名，应检查规则顺序。
• 命中代理但连接超时：继续更换节点并测试 DNS、TCP 或 TLS 稳定性。
• 连接成功但应用仍报错：可能是证书、长连接、应用代理兼容性或服务端返回错误。

动手排查 Cursor 代理与规则分流

下面按照“确认端口、观察日志、修改规则、验证节点”的顺序操作。一次只调整一个变量，不要同时切换 TUN、DNS、模式和多个节点，否则即使问题消失，也很难知道真正生效的设置。

1. 确认本地端口。在 Clash 客户端的设置或当前配置中找到 mixed-port，记下端口号。例如端口是 7890，不要直接假设所有电脑都使用这个值。
2. 打开系统代理。先使用普通系统代理模式，不要一开始就启用 TUN。打开 Cursor 后执行一次登录、聊天或补全操作，同时查看 Clash 连接日志。
3. 固定一个稳定节点。暂时不要使用自动选择或负载均衡策略组，选择一个能够稳定打开网页和完成 HTTPS 连接的节点。自动测速低不代表长连接稳定。
4. 检查规则命中。在日志中查看相关请求是否被分到代理策略组。若明确命中直连，可在本地覆写中为服务方要求的域名设置代理规则，但不要凭猜测把所有域名都加入代理。
5. 逐项复测。每次改动后重新启动 Cursor 或重新登录，记录“是否出现请求、是否建立连接、是否仍然超时”三个结果。

如果客户端支持本地覆写，可以先使用较小范围的规则进行验证。示例中的域名只是说明规则结构，实际域名应以 Clash 日志、服务商文档或 Cursor 当前版本的请求记录为依据：

rules:
  - DOMAIN-SUFFIX,example.invalid,AI服务
  - MATCH,节点选择

规则按照从上到下的顺序匹配。把一条代理规则放在已经覆盖它的 GEOIP、DOMAIN-SUFFIX 或 MATCH 规则之后，通常不会产生预期效果。修改 YAML 时还要注意缩进使用空格，策略组名称必须与配置中真实存在的名称完全一致。如果直接写入不存在的策略组，配置可能无法加载。

检查节点稳定性与请求超时

如果日志显示请求确实进入代理，但仍出现 timeout、connection reset 或 TLS 握手失败，应依次测试其他节点。建议至少比较三个不同线路，而不是只在同一地区的节点之间切换。关注每个节点是否能持续完成 HTTPS 请求、是否在长时间等待后断开，以及是否只有某个网络环境失败。

何时启用 TUN，以及如何避免模式冲突

系统代理只能影响会读取操作系统代理设置的程序。某些编辑器组件、命令行工具、扩展进程或后台服务可能不遵循系统代理，这时即使浏览器访问正常，Cursor 仍可能无法连接。TUN 通过虚拟网卡和路由接管更多系统流量，适合需要透明代理的场景，但它也会引入权限、DNS 劫持、路由回环和 IPv6 处理等额外变量。

建议先用系统代理完成基础验证，确认节点和规则没有问题后，再开启 TUN。开启 TUN 后检查以下项目：

• 客户端是否获得管理员权限、网络扩展权限或 VPN 权限。
• auto-route、严格路由和 DNS 劫持选项是否与当前系统兼容。
• 是否同时运行了 VPN、虚拟机网络、公司安全软件或其他代理工具。
• 是否存在 IPv6 直连而 IPv4 走代理的分流差异。
• 关闭 TUN 后，系统路由和 DNS 是否恢复到原来的状态。

如果启用 TUN 后 Cursor 反而更不稳定，应先关闭 TUN，恢复系统代理，确认问题是否消失。若恢复后正常，说明排查重点应放在 TUN 的 DNS、路由或权限，而不是继续更换大量节点。不要同时开启两个 Clash 客户端的 TUN，也不要让多个程序争用相同的虚拟网卡和代理端口。

DNS 与代理环回问题

DNS 污染、错误的 fake-ip 映射和代理环回，都可能让 Cursor 表现为“偶尔能用、重启后失效”。如果配置启用了 fake-ip，检查相关域名是否被加入 fake-ip 排除列表；如果使用 redir-host，则要确认 DNS 请求本身没有被错误地直连或发送到不可达的解析器。DNS 修改后应清理应用缓存或重启 Cursor，并在 Clash 日志中确认新的解析路径。

代理环回常见于“更新订阅需要代理，但代理规则又依赖正在更新的订阅”或“节点域名被错误地再次送入代理”。订阅地址、节点服务器域名和本地控制接口应分别理解，不要把 127.0.0.1:9090 当作外部网络代理，也不要把控制接口暴露到公网。完成排查后可以关闭不需要的局域网访问，只保留 allow-lan: false 和本机监听。

常见问题与最终检查清单