Clash Verge + OneDrive 连接异常问题排查总结

在校园网里，我遇到了一个奇怪的问题：电脑明明开着 Clash Verge，其他网站也能访问，OneDrive 却一直连接异常。

最初我怀疑是节点或者分流规则出了问题。同样的校园网、相同的节点与配置，在另一台电脑上曾经可以正常登录、同步 OneDrive，而这台电脑的表现却不一样。手动改过规则后，连接一度恢复；恢复配置后，问题又出现了。

为了弄清楚问题在哪，我没有继续反复换节点，而是把整个连接过程拆开：先看系统代理，再查 DNS，然后分别测试直连和代理，最后比较 TLS 与 HTTP 的结果。除了 OneDrive，我还测试了 23 个网站和服务入口作为对照。

一、先确认电脑当前的配置

排查前，我先记录了当前状态：

• 系统代理已开启，地址为 127.0.0.1:7897。
• Clash Verge 使用 rule 模式，TUN 关闭。
• DNS 覆写及 Fake-IP 配置开启。
• 网卡通过 DHCP 获取 DNS，服务器为 221.11.1.67、221.11.1.68。

这里有两个区别需要先弄清楚。

第一，系统代理开启，不等于每个程序的每个请求都走代理。应用是否使用系统代理，需要实际验证；不能只凭浏览器能访问外网，就认为 OneDrive 的全部请求也采用相同路径。

第二，请求进入 Clash，不等于一定经过海外节点。当前是规则模式，部分域名可能匹配 DIRECT。后面表格中的“经 Clash”，表示请求先交给 Clash，再由现有规则决定出口。

为了避免影响正常使用，我通过每条测试请求单独指定连接方式，没有先关闭系统代理，也没有修改网卡 DNS、节点或规则。

二、查 DNS 时发现了异常

我先查询 onedrive.live.com，分别使用网卡当前的 DNS、Google DNS 和 Cloudflare DNS。普通 UDP 查询得到的结果如下：

这些结果看起来很不寻常，而且指定外部 DNS 后，异常也没有消失。

不过，不同 DNS 返回不同 IP，本身不能证明污染。网站可能使用 CDN，正常解析也会随地区、时间和解析服务变化。于是，我又通过当前 Clash 分别查询 Cloudflare DoH 和 Google DoH。

两家加密解析服务为 OneDrive 返回了同样的一组地址：

13.107.137.11
13.107.139.11

接着，我把对照范围扩展到其他域名：

前五个域名还用 Google DoH 做了交叉查询，结果与 Cloudflare DoH 相符或处于相同地址集合。百度等对照域名则能够正常解析和访问。

结合重复查询和后续连接结果，我判断：这条网络路径下，部分域名的普通 DNS 解析存在异常；只把 DNS 地址换成 8.8.8.8 或 1.1.1.1，不足以避开问题。

但我没有抓包，不能准确判断干扰发生在校园出口、运营商还是更上游的位置，也不能把它扩大成“所有 DNS 查询都被劫持”。

三、为什么换 DNS 地址仍然没用？

换解析服务器地址和换传输方式是两件事。

向 8.8.8.8:53 或 1.1.1.1:53 发起普通查询，通常仍使用明文 DNS。如果异常来自解析服务本身或查询路径，换一个服务器地址未必能够避开。

DoH 把 DNS 查询放进 HTTPS；DoT 使用 TLS 传输 DNS。它们能够保护客户端到解析服务这一段的通信，但还要分别确认：连接是否可用，以及服务返回的答案是否可靠。

我测试直连阿里 DoH 时，HTTPS 请求可以完成，部分受影响域名却仍然得到异常地址。这个现象让我意识到：DNS 传输加密成功，不代表解析服务的上游数据一定正确。

我也做了 TCP DNS 和对照查询。外部 TCP DNS 对百度能返回结果，对 OneDrive、Google 则出现连接重置。向两组文档保留地址发送 DNS 查询时，全部超时，没有观察到“任意目标都被透明代答”的现象。

因此，目前能确认的是受影响域名存在解析异常，而不是所有域名、所有 DNS 传输都受同一种方式的干扰。

四、Fake-IP 开启，不等于系统 DNS 已经被接管

检查 Clash 配置时，我看到 DNS 覆写和 Fake-IP 已经开启。但向 127.0.0.1:53 发起 UDP/TCP 查询，结果都是被拒绝；运行配置中也没有设置 dns.listen。

这说明，dns.enable: true 并不意味着电脑一定在本地 53 端口提供 DNS 服务，也不意味着系统 DNS 查询已经自动交给 Clash。

Fake-IP 的含义也容易理解错。在这个模式下，Clash 可以为域名分配 198.18.x.x 一类虚拟地址，保留域名与虚拟地址的对应关系，再处理后续连接。这个地址不是网站真实服务器的地址。

所以，拿到 Fake-IP 只能说明进入了对应的解析流程，不能单独证明 OneDrive 已恢复。后续连接必须继续由 Clash 正确处理。系统代理、DNS 监听和 TUN 是不同环节，需要分别检查。

五、不只看 OneDrive：24 个入口的连接结果

只测一个服务，很难判断问题范围。我把国内网站、海外网站和微软相关入口放在一起，分别测试直连与经当前 Clash 的访问结果。

表中的 200 表示测试 URL 能返回页面；403、417 表示已收到 HTTP 回应，但服务拒绝了请求，不能当成业务正常。出现工具相关异常的站点，使用另一套 TLS 实现交叉验证后再记录结果。

这些结果缩小了问题范围：国内网站和部分微软入口能够正常连接，几个海外网站在直连时失败、交给 Clash 后可访问；OneDrive 则仍存在额外障碍。

尤其是微软登录入口返回 200，不能代表 OneDrive 网页和同步服务也正常。一个应用可能依赖多个域名，登录、下载和同步需要分别验证。

这次测试没有操作 OneDrive 登录、真实文件同步或个人浏览器会话，因此我没有把首页的连接结果写成“同步已经恢复”。

六、绕过 DNS 后，OneDrive 直连还是失败

发现解析异常后，我又做了一组测试：给 OneDrive 指定两家加密 DNS 返回的地址，绕过系统解析，但保留原 URL 主机名和 TLS 验证。

命令的核心写法是：

curl.exe -q --noproxy "*" `
  --resolve "onedrive.live.com:443:13.107.137.11" `
  --connect-timeout 6 --max-time 22 `
  -o NUL -v https://onedrive.live.com/

分别指定 13.107.137.11 和 13.107.139.11 后，两次实际对照测试都在约 0.1 秒发生 TLS/连接重置。

这个结果很关键：即使绕过 DNS，OneDrive 直连也没有恢复，因此不能把整个问题都归结为 DNS。 至于重置来自哪里，还需要抓包或其他路径测试才能判断。

经当前代理访问 OneDrive 时，另一套 TLS 实现能够完成 HTTPS 并收到 403。这已经进入 HTTP 阶段，与 DNS 失败或无法建立连接不同。403 的原因本次没有确定，不能直接归因为校园 DNS、代理节点风控或账号问题。

七、别把测试工具的失败当成网站断网

首轮使用 Windows curl 时，Google、Cloudflare、ChatGPT 出现了 CRYPT_E_REVOCATION_OFFLINE。这个错误涉及证书吊销信息无法获取，不能据此直接认定网站断网。

我使用 Python OpenSSL 的默认证书链和主机名验证做了交叉测试：Google、Cloudflare 经代理返回 200，ChatGPT 返回 403。这让我把吊销检查问题与真正的连接问题分开了。

腾讯网也有一个类似例子：curl 请求返回 501，带浏览器 User-Agent 的另一组请求返回 200。请求方式会影响服务端回应，不能把所有非 200 状态都理解成网络断开。

测试中没有使用 -k 跳过证书链和主机名验证，也没有修改系统 TLS 设置。部分诊断请求使用了 --ssl-revoke-best-effort，仅让该次 curl 进程容忍吊销服务离线，最终判断结合了另一套 TLS 实现的结果。

八、最终判断，以及尚未解决的部分

经过这些检查，我把问题分成了三个层次：

1. 解析层： 部分域名的普通 DNS 查询存在异常，改成外部明文 DNS 也未避开；代理内的加密解析可以提供对照结果。
2. 连接层： OneDrive 即使指定加密解析返回的地址，直连仍被重置，说明还有 DNS 以外的连接障碍。
3. HTTP 与业务层： OneDrive 和 ChatGPT 经代理返回 403，Outlook 首页返回 417；这些需要继续结合浏览器或应用请求排查，不能宣称业务已经恢复。

对于能通过 Clash 正常访问的网站，当前代理路径已经绕过直连障碍。对于 OneDrive，我只能确认 DNS 异常是线索之一，暂时不能给出“只开 Fake-IP 就彻底解决”的结论。

这次排查让我不再把所有失败都统称为“连不上”。先确认 DNS，再看 TCP/TLS，最后看 HTTP 和真实业务，才能判断下一步应该查解析、连接路径，还是应用请求。

九、测试结束后，核对电脑原状

测试前记录的系统代理、网卡 DNS/DHCP/IP/网关配置，测试后都进行了核对。Clash 的主要配置文件、hosts，以及 Obsidian 笔记的文件哈希，也与测试前一致。

本次没有切换节点或规则，没有开启 TUN，没有修改网卡 DNS，没有清空 DNS 缓存，也没有重启 OneDrive 或改动同步文件。连接方式只对单条测试请求生效，不需要在结束后重新设置全局代理。

测试产生的连接、流量统计、自然缓存更新和日志没有清理。核对结果是：电脑配置保持原状，排查过程没有改动原来的文件和设置。

参考资料

• Mihomo：DNS 配置
• Microsoft：OneDrive 个人版所需 URL 与端口

文中的具体 IP 和 HTTP 状态是此次排查时的记录，不是其他网络环境下可以直接套用的固定配置。