离用户更近的海外服务器节点，为什么遇到路由绕行仍可能更慢？

离用户更近的海外服务器节点，确实可能比更远的节点访问更慢。例如，用户与某个机房的地理距离较短，但流量没有沿较短的网络路径抵达，而是先经过其他地区的转接网络再返回；另一个距离更远的节点，却拥有更直接、拥塞更少的连接。此时，地图上的“近”并没有转化为访问时的“快”。

这不是说地理位置不重要，而是说它只决定了网络时延的一部分。“距离越近，访问越快”成立的前提，是实际路由没有明显绕行、往返路径质量相近，而且应用处理与带宽条件没有成为主要瓶颈。判断海外服务器是否适合某批用户，需要验证用户到服务器的实际往返路径和业务表现，而不能只比较城市之间的距离。

常见结论为什么通常有道理

数据在网络中传输需要时间。距离越长，传播时延的下限通常越高，因此把服务部署在靠近用户的地区，是降低访问时延的一种合理方法。

按光信号在光纤中约每秒传播20万公里的简化估算，增加1000公里单程线路长度，对应约5毫秒单程传播时间；若往返都增加同样的长度，往返传播时间约增加10毫秒。这只是物理传播的估算，没有计入设备处理、排队、线路实际铺设长度和服务器响应时间。

这个估算也解释了为什么地理距离具有参考价值：在其他条件相近时，较短的线路更容易获得较低的往返时延。

但这里必须区分三种“距离”：

地图上的两座城市相邻，不意味着两个网络之间一定存在直接、充足且适合该用户线路的互联。反过来，跨越更远距离的节点，也可能因为接入了更直接的网络路径而表现更好。

因此，“近”首先意味着较低传播时延的潜力，而不是已经兑现的访问性能。

哪些条件下，靠近用户通常更有优势

要把地理优势转化成体验优势，至少需要满足几个条件。

实际往返路径没有抵消地理优势

用户侧网络与机房网络之间，最好存在相对直接的互联或转接路径。如果到近距离节点需要经过较远地区，而到远距离节点反而可以直接抵达，前者的地理优势就可能被抵消。

这里强调“往返”，因为客户端发出的请求和服务器返回的数据，不一定经过相同的网络。

一次访问的往返时延，可以粗略理解为：

往返时延 = 去程传播与排队时间 + 回程传播与排队时间 + 沿途设备处理时间。

即使去程很短，只要回程明显绕行，用户测到的往返时延仍然会升高。对于返回数据较多的网页、文件和接口响应，回程链路的容量与拥塞情况也尤其重要。

网络质量与资源条件可以相互比较

距离对性能的影响，需要在其他主要条件没有明显失衡时讨论。如果近距离节点带宽不足，而远距离节点带宽充足，直接比较下载完成时间，并不能单独说明距离的作用。

合理的对照条件包括：

• 两个节点使用相同或相近的应用版本、页面内容与缓存策略。
• 服务器CPU、内存和磁盘没有明显负载差异。
• 接口依赖的数据库与外部服务位置已知，且不会主导响应时间。
• 测试时段、客户端网络、连接方式和请求规模相近。
• 没有把CDN命中结果与源站直连结果混在一起比较。

这些条件不必做到实验室级别的完全一致，但明显的差异必须记录下来。否则，一个“更远但更快”的结果，可能来自缓存命中，而不是网络路径更好。

业务确实对时延敏感

需要多次交互的登录、查询、实时协作和API请求，通常更容易从较低的往返时延中受益。新连接建立、安全握手以及部分应用交互，都可能增加往返等待。

而大文件下载更依赖持续有效吞吐；复杂报表可能主要受服务器计算影响；已经由CDN缓存的静态资源，主要受用户到边缘节点的连接影响。

所以，靠近用户的优势并非对所有业务等量生效。要先确认用户实际在等待什么，才能判断缩短距离是否能解决主要问题。

一个反例：邻近节点绕行，更远节点直达

考虑一个面向华南用户的网站，在两个海外地区部署了相同的测试页面：

• 节点A位于中国香港，与用户地理距离较近。
• 节点B位于日本东京，与用户地理距离较远。

在这个构造场景中，某接入网络到节点A的流量先经新加坡转接，再抵达香港；到节点B则采用较直接的跨境路径。下面的数据仅用于说明机制，不代表具体机房、运营商或线路的实际表现。

这里的P95表示：在这组观测中，约95%的结果不超过该数值。它能够反映较慢的一部分请求，而不是只看最顺畅的访问。

这个反例推翻的不是“距离影响传播时间”，而是“服务器所在地可以直接代表数据传输距离”。节点A虽然在地图上更近，实际流量却走了更长的路径；如果转接链路还存在拥塞，差距会进一步扩大。

表中的路径是预先设定的示意，不是仅根据某个IP地址的地理库位置得出的结论。在真实测试中，单个中间跳显示“新加坡”，并不足以证明流量一定绕行新加坡：地址注册信息、路由器命名和实际设备位置可能不一致。

同一个近距离节点，也可能只对部分用户更慢

继续沿用这个场景，如果另一家接入网络与节点A之间有较直接的互联，节点A可能重新获得优势。

这意味着，一个节点的表现不能被简单归纳成“香港快”或“东京快”。更准确的比较对象应当是：

某地区、某接入网络、某时间段的用户，到某个服务器IP或服务入口的访问表现。

同城不同运营商、同一运营商的不同省份，甚至固定宽带与移动网络，都可能使用不同路径。对某批用户成立的结论，不一定能推广到全部用户。

还有一种反例：时延更低，完整访问却更慢

绕行并不是近距离节点失去优势的唯一原因。即便节点A的往返时延更低，如果可用吞吐明显不足，大响应仍然可能更慢。

例如，一个1 MB的文件，按十进制口径计算为100万字节，即800万比特。若持续有效吞吐分别为8 Mbps和40 Mbps，仅数据传输所需时间约为：

• 8 Mbps：800万比特 ÷ 每秒800万比特，约1秒。
• 40 Mbps：800万比特 ÷ 每秒4000万比特，约0.2秒。

这个估算不包含连接建立、服务器处理及其他等待，也假定传输期间有效吞吐维持在对应水平。它说明的是：对于较大的响应，几十毫秒的时延优势，可能抵不过数百毫秒的传输差距。

因此，需要把“绕行导致时延增加”和“容量不足导致传输变慢”分开判断，不能把所有慢访问都归因于距离。

网络为什么没有按照地图上的短路走

BGP选择的是符合策略的路径，不是地理最短路径

互联网由大量自治系统相互连接。BGP传播的是IP前缀的可达信息及相关路径属性，网络运营者再结合自己的路由策略决定采用哪条路径。

这种选择可能受到商业互联关系、上游接入、路由优先级、容量安排和故障处理等因素影响。它不是把全球光纤画在地图上，然后自动寻找距离最短、时延最低的一条线。

即使某条路径的自治系统数量较少，也不能据此断定它更快。一个自治系统内部可能跨越较远地区，而多个自治系统之间也可能在同一城市完成互联。

因此：

地理距离、AS路径长度和实际访问时延，是三个相关但不能相互替代的指标。

机房拥有到某地区的连接，也不意味着所有用户都会使用该连接。接入网络是否接收相关路由、采用怎样的优先级，以及返回用户时选择什么出口，都会影响最终路径。

去程和回程可能不对称

用户侧网络主要决定请求如何送向服务器，服务器侧及其上游网络则影响返回用户的路径。两端的路由决策并不必然对称。

这会出现一种容易误判的情况：从用户侧看，去程经过的网络似乎较直接，但往返时延依然偏高。原因可能在回程，也可能在链路排队，并不能仅凭去程中间跳就确定。

从服务器反向测试用户网络，可以补充判断，但它也不一定完整复现业务流量的回程。探测协议、目标地址和负载均衡方式不同，都可能造成路径差异。

所以，双向观测的价值是提供更多线索，而不是保证还原每一个请求经过的全部链路。

路由绕行和链路拥塞可能叠加

绕行主要增加传播距离及经过的网络环节；拥塞主要增加排队时间、丢包和重传风险。两者可以同时出现，但不能混为一谈。

如果一个节点全天都有相对稳定的较高时延，可能存在长期路径差异；如果白天正常、晚间显著恶化，则更需要检查容量与排队情况。当然，日间和晚间也可能采用不同路由，仍应结合路径记录验证。

TCP在丢包或持续拥塞下会调整发送速率。于是，某条线路即使基础往返时延不算高，也可能因频繁重传而降低有效吞吐。对于用户而言，这种影响表现为页面资源加载变慢、下载速度不稳，或者请求偶发超时。

“绕行”是路径层面的解释，“慢”是业务层面的结果。只有两者能够相互印证时，才适合建立较强的因果判断。

怎样验证“近节点反而更慢”

验证的目标不是寻找一次漂亮的测速结果，而是确认三个问题：近节点是否持续更慢、差异出现在哪个阶段，以及路由是否足以解释差异。

先固定比较对象，避免测到不同服务

两个节点应提供相同的小响应和相同的测试文件。小响应用于观察连接与首字节等待，固定大小文件用于观察传输表现。

如果测试域名使用CDN，首先确认请求是否到达预期的源站；如果DNS返回多个地址，也要记录实际连接的IP。IPv4与IPv6应分别测试，因为它们可能采用不同互联和出口，结果不能直接混合。

在安装了curl的测试设备上，可以用下面的方式把同一HTTPS域名分别解析到两个候选IP，同时保留正确的域名与证书校验：

for ip in 192.0.2.10 198.51.100.20; do
  curl --resolve "perf.example.com:443:${ip}" \
    --connect-timeout 5 \
    --max-time 20 \
    --silent --show-error \
    --output /dev/null \
    --write-out 'remote=%{remote_ip} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} bytes=%{size_download}\n' \
    'https://perf.example.com/probe.txt'
done

其中的域名和IP均为示例，应替换成自己的测试域名与服务器地址；两个服务器都需要正确承载该域名，并配置有效证书。不要为了让测试通过而关闭证书校验，否则可能掩盖入口配置差异。

这些时间单位是秒，且大多是从请求开始累计到相应阶段的时间，不是每个阶段独立耗时。例如，time_appconnect包含之前建立连接所花的时间，不能再与time_connect直接相加。time_starttransfer也包含连接过程及等待响应的时间，不能直接视为服务器处理耗时。

这个命令每次建立新的连接，适合比较冷连接请求，不代表浏览器复用连接后的全部表现。

再观察路径，寻找能够解释差异的线索

在已安装MTR、支持TCP探测且具备所需权限的Linux环境中，可以对服务端口进行低频探测，例如：

mtr -n -T -P 443 -r -c 30 192.0.2.10

将示例IP替换为目标地址，并用相同参数测试另一个节点。TCP 443探测比默认ICMP探测更接近HTTPS业务的目标端口，但探测包和实际连接仍可能受到不同处理。

读取结果时，以下边界尤其重要：

• 某一中间跳不响应，不等于业务流量无法通过。
• 某一中间跳丢包较高，而后续与终点正常，可能只是设备限制了探测响应。
• 中间跳时延很高、后续却恢复正常，不能直接把该跳判为转发瓶颈。
• 中间跳的往返时间也包含其探测响应的回程，不能简单用相邻两跳相减，得出对应链路的单程时延。
• 跳数少不等于路径短，跳数多也不必然意味着访问慢。

更有价值的线索，是路径变化与终点时延、应用响应变化同时出现。例如，某时段可见网络路径发生变化，随后终点往返时延和小响应首字节时间一起升高。这比单独看到一个疑似远方的中间IP更有解释力。

用重复观测区分偶发波动与稳定差异

一次测试可能碰上临时排队、冷缓存或服务器后台任务。初步验证可以重复几十次，但判断稳定性时，应覆盖不同时间段及目标用户网络，而不是把短时间内的结果包装成长期表现。

适合记录的内容包括测试时间、用户地区与接入网络、目标IP、IP版本、连接方式、响应大小，以及是否命中缓存。结果至少同时保留：

样本量较小时，P95容易受少量结果影响，应保留原始样本，不宜只展示一个分位数。对照测试也不应占满服务器出口，否则测试自身可能制造拥塞。

把现象和原因分开下判断

下面这些结果，分别支持不同程度的判断：

判断应停留在证据能够支持的位置。没有回程和互联资料时，可以说“近节点在这些用户网络上表现更慢”，不必强行把原因写成已经确认的某段海缆绕行。

近距离节点仍然值得优先考虑，但要保留这些边界

反例说明的是：地理距离适合作为初筛条件，不适合作为最终性能承诺。

如果主要用户到近距离节点拥有直接、稳定且容量充足的往返路径，服务器资源和应用依赖也与业务相匹配，那么就近部署通常仍有明显价值。尤其对高频交互、小响应和时延敏感业务，较低往返时延更容易转化为可感知的体验改善。

但这种优势应限定到具体用户群体。若华南某接入网络访问表现良好，而其他地区或移动网络表现一般，不能用前者代表全部用户；若IPv6表现良好而IPv4存在绕行，也应按实际用户协议占比评估，而不是只展示较好的一组结果。

CDN场景还需要分清两个距离：用户到边缘节点，以及边缘节点到源站。缓存命中的静态资源主要受第一段影响；动态请求、缓存未命中和回源更新仍会受到第二段影响。源站更靠近用户，并不自动意味着用户当前访问的边缘路径也更好。

对海外服务器节点的合理判断，可以保留为一句有条件的结论：

当实际往返路径较直接、网络质量与资源条件相近、业务确实对时延敏感时，离用户更近的节点通常更有优势；一旦出现路由绕行、回程不对称或链路拥塞，更远但连接更直接的节点就可能更快。

因此，应先用地理位置缩小候选范围，再用目标用户网络中的持续观测确认优势。真正需要靠近的，不只是地图上的用户位置，还有用户实际能够稳定到达的网络路径。