为什么北京联通直连我 VPS 的反代域名会比走 Surge 节点更慢

Question（问题）

为什么在北京联通家宽环境下，直连访问我 VPS 上那些反代域名时常感觉很慢；而把这些域名在 Surge 里改成走某个代理节点后，体感速度反而明显变快？

Short Answer（简答）

按当前已知信息，这更像是“访问路径差异”问题，而不是 VPS 本机算力不够。

现阶段最值得优先怀疑的是：

• 北京联通直连到这些域名当前命中的网络路径较差
• Cloudflare 小黄云参与后，直连与代理出口可能走到了不同的边缘节点或不同的回程路径
• IPv6 开启后，直连路径与代理路径可能使用了不同的协议栈或解析结果

也就是说，1.05M 这种“大上下文是否够用”的问题和这里无关；这里更像是 DNS / IPv6 / Cloudflare / 运营商路由共同作用下的网络路径问题。

Facts（事实）

• 当前关注的对象，主要是 VPS 服务记录里那批已经做了反代的域名。
• 除 floo 外，这些域名大多开启了 Cloudflare 小黄云（orange-cloud）。
• floo 是 S-UI 节点使用的域名；因为体感较慢，已关闭小黄云，但仍偶尔感觉慢。
• 主要使用设备是 16 寸 M2 Max MacBook 和 iPhone 12 Pro。
• 主要代理客户端是 Surge。
• 当前地理环境是北京，家庭宽带为联通。
• 路由器和 Surge 都开启了 IPv6，而且这是希望保留的配置。
• 在 Surge 中把这些域名从“直连”改成走某个代理节点后，访问速度会明显变快。
• 当前问题主要是在 Mac 上更明显，因为大多数观察都发生在电脑前。
• 用户当前还不能稳定给出每个域名的逐项量化评分，更偏向整体体感结论。

Interpretation（解释）

这个现象的关键不是“同一域名有时快有时慢”，而是“改了出口路径后明显变快”。

这会把怀疑重点从 VPS 本机性能，转向更靠前的链路层：

• 本地运营商到目标边缘节点的路径
• Cloudflare 代理层是否让不同出口命中了不同边缘节点
• IPv6 开启后是否优先走了一条更差的路径
• Surge 规则把请求改走节点后，等于换了一条去往目标域名的网络入口

由于多数受影响域名都在 Cloudflare 小黄云后面，这让 Cloudflare 成为本问题里的重要变量；但 floo 在关闭小黄云后有时仍慢，说明问题也不一定只在 Cloudflare，本地运营商路径或 IPv6 表现仍值得继续核查。

这个问题可能波及 AxonHub 等 VPS 反代站点，但当前证据还不足以说是某一个具体应用自身慢。

Related Pages（相关页面）

• AxonHub

Open Questions（待解问题）

• 具体最慢的是哪些域名，是否可以分成“总是慢”和“偶发慢”两类？
• Mac 和 iPhone 的体感是否一致？
• 直连与走 Surge 节点时，各域名解析出来的 IP 是否一致？
• 这些域名是否优先命中了 AAAA 记录，从而让 IPv6 成为关键变量？
• floo 作为关闭 Cloudflare 小黄云的对照组，是否与其他站点表现出不同的慢法？

Next Checks（后续核查）

• 补全具体域名清单，并记录每个域名当前是否开启 Cloudflare 小黄云。
• 对同一域名比较直连与走节点时的 DNS 解析结果。
• 比较 IPv4 与 IPv6 的体感差异，确认 IPv6 是否是主要变量。
• 记录 Mac 与 iPhone 是否都稳定复现同样问题。
• 把 VPS service hub 中每个服务的 DNS 记录类型与 Cloudflare proxied 状态补全。