【深圳移动测试】绿云 vs AWS 新加坡节点 · 本机侧网络对比测试

【深圳移动测试】绿云 vs AWS 新加坡节点 · 本机侧网络对比测试

最近香港不怎么好用而且AI也不方便 先做为备用 叫AI测下SG 本地情况的看看

实测联通用好像也不错 有空再测联通的

绿云 vs AWS 新加坡节点 · 本机侧网络对比测试

测试端：本机（深圳移动家宽，出口 120.231.·.·）
测试时间：2026-10-12 11:45 – 12:20 (GMT+8)，共六轮
方法：ICMP PING（60 次/轮，间隔 1 秒）· TCP 握手 · HTTP 长短连接 · tracert 去程 · 第三方节点回程 traceroute
说明：所有 IP 均已脱敏（保留前两段，后两段以 · 代替）。交互式图表见 HTML 版报告。

一、核心指标对比

注：AWS 的 11.7% 丢包在第二轮未复现，详见第四节。

二、详细统计（第一轮）

三、延迟时序（60 秒）

• 绿云：曲线几乎是一条直线，全部落在 50–57 ms。
• AWS：基线 91–95 ms，但反复出现 105 / 111 / 121 ms 尖峰，另有 7 次探测超时未绘入。

四、第二轮复测验证（同日 11:53 – 11:57）

第一轮 AWS 出现 11.7% 丢包，需要确认是持续现象还是瞬时抖动。追加第二轮：再跑 60 次 ICMP，并加入 60 次 TCP 握手延迟（端口 22），同时复测去程与回程。

4.1 两轮对比

4.2 复测推翻了第一轮的丢包结论

AWS 第二轮 ICMP 丢包为 0 %，第一轮那 7 次超时没有复现 —— 属瞬时抖动而非持续性丢包。TCP 层面两轮均 0% 丢包。

→ 第一轮报告中「AWS 不适合稳定性敏感场景」的判断下调为「需持续观察」。

4.3 但延迟结论被坐实

两轮平均延迟高度一致（绿云 51.1 / 52.5 ms，AWS 94.2 / 95.3 ms），差值稳定在 42–43 ms。绿云 ICMP 分布极窄（P50 51、P90 53–54），AWS 两轮都持续出现 105–147 ms 尖峰。

→ 绿云在延迟上的优势是真实且可复现的。

4.4 TCP 握手异常：两台都有偶发尖峰，性质完全不同

绿云的 TCP 握手延迟呈双峰分布 —— P50 仅 59 ms，P90 却跳到 202 ms，且所有超过 100 ms 的样本全部超过 150 ms，中间没有任何过渡值。AWS 则是单峰分布，98–105 ms 高度集中。

四步定位实验：

1. 排除本机代理劫持 —— 本机只有 Intel Wi-Fi 6 与 Realtek 有线两张物理网卡，无任何 TUN/TAP 虚拟网卡，默认路由直连 192.168.0.1。本机代理是应用层代理（127.0.0.1:60403），不影响原始 TCP socket，握手测的是真实直连。
   （更正：tracert 第 3 跳的 172.17.0.1 是上游接入网设备，并非本机虚拟网卡。）
2. 多目标对照 —— 4 个目标各 45 次握手：绿云 5 次超 150 ms；AWS / 国内阿里 DNS / 海外 8.8.8.8 均为 0 次。若是本机问题，所有目标都会尖峰 → 排除本机。
3. 端口对照 —— 绿云 22 / 443 / 80 三个端口各 40 次，分别出现 2 / 6 / 6 次超 150 ms 尖峰。三个端口都有 → 排除单一服务（如 SSH 限流）。
4. banner 对照（分离「建连」与「已建立」） —— SSH 服务建连后立即回送 banner，可同时量出「建连耗时」与「建连后首个往返」。两次尖峰完全对应同一批连接（第 3 次：建连 199 / banner 213；第 9 次：建连 197 / banner 211）→ 建连已变慢的那几次，紧随其后的往返同样慢。（后续 keep-alive 实验证明这只是少数异常连接的表现。）

大样本定论（各 80 次握手）：

结论：两者都受偶发连接延迟影响，但性质不同 ——

• 绿云：高频、中等幅度。 约 13.8% 的连接延迟从 ~59 ms 跳到 ~200 ms（+140 ms）。200 ms 远小于 Linux SYN 重传超时（约 1 s），不是丢包重传，更像中间设备对该连接的处理延迟。
• AWS：低频、极端幅度。 99% 的连接稳定在 98–105 ms，但约 1.3% 出现 ~1.1 s 建连延迟。1111 ms 恰好符合 TCP SYN 丢包后的重传超时（初始 RTO ≈ 1 s），是典型丢包特征。
• 国内对照绝对值很低但并非毫无抖动。 P90 仅 24 ms，80 次中有 5 次出现 40–125 ms 的相对尖峰 → 本机 / 接入网侧本身也存在偶发抖动，只是幅度小。「偶发连接延迟」是端到端网络的普遍现象，绿云只是频率显著更高（13.8% vs 6.3% vs 1.3%）。

4.5 长连接 vs 短连接：尖峰究竟出在哪个环节（决定性实验）

绿云 80 端口由 nginx 提供服务且支持 keep-alive。用同一连接连续发 100 个 HTTP 请求，与每次新建连接各发 100 个请求做对比。

结论：尖峰绝大部分来自「连接建立」环节，已建立的连接上往返是稳定的。

• 长连接极度稳定：P50 54 ms、P90 61 ms，100 次请求里只有 5 次超 100 ms，而唯一一次超 150 ms 的是第一个请求（即建立连接那一次）。此后 99 次全部落在 53–139 ms，绝大多数是 53–57 ms。
• 短连接明显劣化：P90 达 396 ms，17 次超 150 ms，尖峰在序列里呈随机分布，约 10% 的连接会命中。
• 短连接 P50 122 ms 高于长连接 54 ms，一部分是正常开销（三次握手 + 请求约 2 个 RTT，长连接只需 1 个 RTT）；但 P90 从 61 ms 跳到 396 ms，就不是正常开销能解释的了。
• 这也厘清了 banner 实验的现象：banner 变慢只发生在少数「建连已经异常」的连接上，并非所有已建立连接的通病。

实用建议：绿云上跑代理时，客户端应尽量复用连接（mux、HTTP keep-alive、长连接），可规避绝大部分尖峰；频繁新建连接的使用方式会持续吃到这个惩罚。

4.6 补充验证：尖峰是随机发生的，没有固定周期

为确认尖峰是「按次数」还是「按时间」触发，用两种不同间隔各跑一轮并记录每次请求的精确时间戳：

两轮命中率接近（8–11%），但间隔极不规律。若是固定周期，间隔应当稳定；若是按次数触发，序号间隔应当不变 —— 两者都不成立。这是典型的独立随机事件特征。

修正：前几轮报告把这一现象描述为「周期性尖峰」，实际是随机聚集造成的视觉错觉。每次新建连接约有 10% 的独立概率命中延迟，因此无法通过调整请求频率规避，只能靠复用连接绕开。

4.7 附带发现：绿云 443 端口的 TLS 证书已过期

443 同样由 nginx 提供服务，证书 CN=llyy.net，有效期 2025-07-03 至 2025-10-01，已过期约一年（当前 2026-10-12）。

• 如果这是你自己的站点，需要续期；
• 如果是刻意配置的伪装站点（如 VLESS Reality 的 dest / fallback），可忽略。

4.8 回程复测：新加坡的跳变完整复现，香港的孤立尖峰被证伪

判据：看跳变后面的跳有没有跟着一起高。 只看单个跳的数字会被误导。

五、去程路由（本机 → 目标）

绿云 172.93.·.· — 16 跳，末跳 51 ms

本地网关(192.168.·.·, 2ms)
  → 深圳移动(221.179.59.·, 9ms)
  → 移动骨干(221.183.166.·, 12ms)
  → 移动骨干(221.183.92.·, 18ms)
  → CMI 国际出口(223.120.22.·, 17ms)
  → [第 10-11 跳超时]
  → Telstra(180.87.66.·, 54ms)
  → 新加坡落地(23.106.255.·, 50ms)
  → 绿云(172.93.·.·, 51ms)

AWS 47.129.·.· — 10 跳可见，末跳 93 ms

本地网关(192.168.·.·, 2ms)
  → 深圳移动(221.179.59.·, 6ms)
  → 移动骨干(221.183.166.·, 17ms)
  → 移动骨干(221.183.92.·, 18ms)
  → CMI 国际出口(223.120.14.·, 86ms)
  → CMI 境外段(223.120.2.·, 71ms)
  → [第 11-20 跳 ICMP 被屏蔽，无响应]
  → AWS(47.129.·.·, 93ms)

去程结论：两条路径前半段完全一致 —— 都从深圳移动（221.179.59.·）上移动骨干（221.183.92.·），再由中国移动国际 CMI 出口出境。差别在出境之后：

• 绿云：CMI → Telstra（180.87.·）→ 新加坡落地（23.106.255.·），仅 16 跳、末跳 51 ms。
• AWS：CMI 境内段已涨到 86 ms，第 11 跳起 ICMP 被屏蔽无法观测，但实测 RTT 93 ms，比绿云多约 42 ms —— 说明 AWS 侧路径更长或存在绕行。

注：云厂商（AWS/Azure/GCP）常在若干跳后屏蔽 ICMP，出现连续「请求超时」但 ping 仍通属正常策略，不代表丢包。

六、回程路由（目标侧 → 本机）

方法说明：本机无法登录这两台服务器，因此回程由第三方节点（新加坡 AS141995 / 香港 AS207713）发起 traceroute 到本机公网出口。本机为家庭宽带 NAT，最后一跳不回 ICMP，故路径止于运营商侧。

新加坡侧 → 本机：20 跳未达，末段 428 ms

新加坡节点(103.164.54.·, 2ms)
  → HE 骨干(184.104.194.·, 155ms)
  → CMI 入境(223.120.11.·, 153ms)
  → CMI 拥塞段(223.120.22.·, 428ms)   ← 跳变点
  → 移动骨干(221.183.137.·, 385ms)
  → 深圳移动(221.179.59.·, 394ms)
  → 本机（NAT 不回 ICMP）

香港侧 → 本机：13 跳未达，末段 165 ms

香港节点(141.98.234.·, 4ms)
  → HE 骨干(184.105.64.·, 52ms)
  → CMI 入境(223.121.6.·, 131ms)
  → 移动骨干(221.183.92.·, 156ms)
  → 移动骨干(221.183.137.·, 165ms)
  → 本机（NAT 不回 ICMP）

回程关键发现：新加坡方向在 CMI 段 223.120.22.· 出现 153 ms → 428 ms 的剧烈跳变（+275 ms），之后一路维持在 385–397 ms。而香港方向同为中国移动入境，全程只有 131–165 ms，没有这个跳变。

→ 这说明新加坡方向回中国移动的回程在该段存在拥塞或绕行，不是全局性的中国移动问题。

七、结论

• 延迟：绿云明确占优，且两轮可复现。 平均延迟低 42–43 ms（51.1/52.5 vs 94.2/95.3），P90 低 43 ms（53–54 vs 96–97）。绿云曲线几乎是一条直线，AWS 两轮都持续出现 105–147 ms 尖峰。
• 丢包：AWS 的 11.7% 未能复现，属瞬时抖动。 第二轮 0%，TCP 层面两轮均 0%。「不适合稳定性敏感场景」的判断已下调为「需持续观察」，不必据此排除 AWS。
• 去程：两者同源。 都走「深圳移动 → 移动骨干 → CMI 出境」，差别只在出境之后 —— 绿云经 Telstra 直达新加坡（16 跳 / 51 ms），AWS 后段 ICMP 被屏蔽且明显绕行（93 ms）。
• 回程：新加坡方向是真实短板，两次测试均复现。 中国移动 CMI 段（223.120.22.·）存在 153 → 400–422 ms 的跳变，且后续跳维持高位不回落。香港方向同为中国移动入境却只有 131–165 ms，排除了「中国移动整体不行」的可能。
• 两台的 TCP 新建连接都有偶发尖峰，但性质不同。 绿云约 13.8% 的连接延迟从 ~59 ms 跳到 ~200 ms（双峰分布，非丢包重传）；AWS 99% 稳定在 98–105 ms，但约 1.3% 出现 ~1.1 s 建连延迟（符合 SYN 丢包重传特征）。国内对照绝对值很低但并非毫无抖动，已排除本机为主因。
• 尖峰集中在「连接建立」环节，已建立的连接是稳定的。 绿云 80 端口同一连接连续 100 个请求：P90 仅 61 ms，只有 1 次超 150 ms（且是首个请求）；而每次新建连接 100 次：P90 高达 396 ms，17 次超 150 ms。尖峰为随机事件（每次建连约 10% 概率命中，无固定周期）。
  → 实用结论：客户端尽量复用连接（mux / HTTP keep-alive / 长连接），可规避绝大部分尖峰。
• 附带发现： 绿云 443 端口的 TLS 证书（CN=llyy.net）已于 2025-10-01 过期约一年，若是自有站点需续期；若为伪装站点配置可忽略。
• 建议： 对新加坡方向有延迟要求的业务优先绿云；AWS 的延迟劣势是结构性的（绕行），若必须使用，考虑更换区域或走 CN2/优化线路中转。两者都不必担心持续性丢包。

附：原始数据与测试轮次

数据来源：本机 Windows PING / TCP 握手 / tracert 实测 + check-host.net 新加坡(AS141995)、香港(AS207713) 节点回程 traceroute。
报告更新于 2026-10-12 12:22 (GMT+8)。所有 IP 均已脱敏处理。