UCloud香港VPS双源实测：六个测试IP延迟对照

UCloud 香港 VPS 能用官方测试 IP 直接验。UCloud 在《UCloud数据中心测试IP》里给了六个境外测试地址，香港那一个是 101.36.113.110，官方标注「回内地加速线路」。这篇以它为主体，两个探测源各打 20 包，广东源与北京源各测四次（一次首测加三次复跑），再补 tracepath 逐跳与五个海外节点对照。

官方口径里能核对到什么

UHost 产品页写的是平台级承诺：30 多个可用区覆盖五大洲、99.95% 的可用性、最高支持 Intel Cascade Lake、自研网络增强 2.0、最高 120 万 IOPS 与 1000 万 PPS。这几句都在页面上，但整页没有出现香港两个字，也没有任何香港地域的带宽档位。

香港专属的可核对信息只有一条：测试 IP 页把 101.36.113.110 标成香港，括号里写「回内地加速线路」。这是 UCloud 自己给出的线路定性，也是这次唯一能引用的香港线路说法。

不能核对的部分要说清楚。香港地域的 CPU、内存、系统盘档位，带宽怎么给，是不是不限流量，月付年付多少钱，这些都在下单页按配置实时计算。本次抓取时，香港活动页和 EIP 产品页返回的都是 6.9 KB 的前端外壳，价格文档返回 8.3 KB 外壳，没有静态数字可查。所以这篇不给任何价格与带宽档位，也不写「不限流量」这类定性话。

UCloud 香港有国际与精品 BGP 两种售卖档，本篇测的这个测试 IP 不对应其中某一档，只代表这一条路径。站内另一篇按两种售卖档做过对照，也记了 CN2 GIA 下线后国际线路与精品 BGP 的差别，见 UCloud 香港云服务器线路优化。那一篇写精品 BGP 在 30 毫秒左右，本篇四次落在 18.632 到 49.214，两个数字不冲突：前者是某次单点，后者是四次横截面，探测源和时段都不同。

香港节点双源实测：广东 18.632，北京 48.472

香港这个地址在两个源上的表现差得很远，先看数字。

单位毫秒，命令为 ping -c 20 -W 2，2026-10-29 实测。这八行就是 UCloud 香港 VPS 本次的全部延迟数据，没有做任何平滑处理。广东源是电信 AS4816 单线，北京源是阿里云 AS37963 BGP 多线，两组数字不能互相替代。

UCloud 香港 VPS 在广东源四次均值落在 18.632 到 27.124 之间，极差 8.492；北京源四次落在 48.472 到 49.214 之间，极差 0.742。北京源慢 29.840 左右，但几乎不动；广东源均值低得多，却一次一个样。

拆开看更清楚。UCloud 香港 VPS 在广东源四次的 min 都在 13.7 上下，从 13.676 到 13.828，说明空载时的物理延迟就在这个位置；max 从 62.666 一路到 110.918，单次跨度最大 97.242。北京源四次 min 都在 48.3 附近，max 最高只有 56.019。

这张是广东源第 3 次的逐包回显。第 1 包 62.7 毫秒，是冷启动的首包代价；第 2 包起掉到 14 毫秒附近；第 6 包又跳到 36.1，第 14 包 21.2。mdev 11.202 就是这些尖刺堆出来的。北京源同一时段的 mdev 只有 0.174 到 1.892，两种表现放在一起，UCloud 香港 VPS 的稳定性问题就清楚了：不是平均值不好，是偶尔会抖。

延迟、抖动、丢包，该按什么顺序看

UCloud 香港 VPS 的数字摆在一起，很容易只看均值。均值是最不该单独看的一项。

先看丢包。八次香港测试全部 0%，这一点没问题；但海外节点里日本 20% 到 30%、新加坡 5%、洛杉矶 5%，同样是 UCloud 的机器，差别全在链路上。丢包一旦出现，TCP 会退避重传，延迟数字再漂亮也没意义。

再看抖动。广东源四次 mdev 从 11.202 到 29.975，北京源从 0.174 到 1.892，相差一个数量级。抖动决定的是体验的一致性，做网页浏览感觉不到，做长连接和实时传输立刻能感觉到。

最后才看均值。广东源 18.632 比北京源 48.472 低了 29.840，但广东源的极差 8.492 是北京源 0.742 的十一倍。如果你的业务在广东、又能接受偶尔卡一下，选广东路径没问题；如果业务要的是「一直这个速度」，北京那条路反而更合适。

顺序搞反了会怎样？只看均值，会觉得香港节点 18 毫秒很漂亮，买回来发现晚高峰抖到 110 毫秒。只看丢包，会觉得八次都 0% 很稳，换到日本节点就踩坑。三项一起看，UCloud 香港 VPS 的画像才算完整：均值不错，稳定性看时段，跨地域差异极大。

出向路径：广东走 CN2 加 CTGNet，北京走联通 169

同一个地址，两个源出去走的路完全不同，这是延迟差 29.840 的根本原因。

UCloud 香港 VPS 从广东出去的路径比较干净。第 12 跳 203.22.178.93 属于 AS4809，也就是 CN2，15.045 毫秒；第 13、14 跳 69.194.169.93 和 183.91.36.30 都在香港本地，12.136 和 19.331 毫秒；第 15 跳 203.34.194.210 是 AS23764，CTGNet 的香港入口，16.054 毫秒；第 21 跳到目标，14.709 毫秒。整条路径不绕，也没有跨洋。

北京源走的是另一条。第 10 跳 219.158.8.122 是 AS4837 的联通 169 骨干，在广州，36.028 毫秒；第 11 跳 219.158.4.54，45.619 毫秒；第 13 跳 202.77.23.30 已经是中国联通国际的香港节点，54.360 毫秒；第 23 跳到目标，50.240 毫秒。同一条 UCloud 香港 VPS 线路，从广东出去走 CN2，从北京出去走联通 169，出境骨干完全不同。

这一点直接影响体验判断。CN2 三个字只对电信用户成立，联通和移动宽带的用户看到的是另一条路。买之前用自己的宽带 ping 一次，比看任何测评都准。

还有一处要说明。北京源 tracepath 第 6 跳 61.49.143.5 回显 6468.872 毫秒，这是路由器对 ICMP 限速造成的伪值，不是真实延迟，这里不采用，也不计入任何统计。

海外节点：日本 125 到 151，丢包 20% 到 30%

UCloud 的测试 IP 页列了六个境外地址，除香港外还有五个，它们和 UCloud 香港 VPS 用同一个 ASN，线路却是各自独立配的。一起跑完能看出这家的境外布局，也能看出哪些节点现在不适合用。

日本东京是这批里延迟最低的，广东源 151.139、北京源 125.011，两源差 26.128。但丢包很难看：广东源 20 包丢 4 个，北京源丢 6 个，丢包率 20% 和 30%。延迟低而丢包高，说明路径本身不远，是链路拥塞或者被限速。

新加坡那个地址问题更大。广东源 345.986 毫秒、北京源 309.884 毫秒，两源差 36.102，两个源都丢 5%。按物理距离，华南到新加坡应该在几十毫秒的量级，345 毫秒只能是绕了远路。

美国两个地址分得比较开。洛杉矶 168.920 和 182.639，两源差 13.719；华盛顿 240.533 和 252.720，两源差 12.187，北京源反而更慢。德国法兰克福 259.667 和 217.122，两源差 42.545，是这批里两源差距最大的一个。

丢包这块如实写。五个海外地址里，日本、新加坡、洛杉矶三个在两个源上都有 5% 到 30% 的丢包；华盛顿在北京源丢 20%，广东源 0%；德国法兰克福两源都是 0%。香港那八次也是全 0%。做业务选节点，丢包比延迟更该先看。

标注为新加坡的地址，ipinfo 判在吉隆坡

165.154.147.137 在 UCloud 测试 IP 页上写的是新加坡。ipinfo 查出来的城市是 Kuala Lumpur，国家是马来西亚。运营商归属一致，都是 AS135377，也就是 UCloud 自己。

为什么会出现这种标注差异，本次核不到原因，也不做推测。能确认的是延迟对不上：如果真在新加坡，华南过去不该是 345.986 毫秒。地理标注和实测数字放在一起看，这个节点现在不适合承载东南亚业务。

六个地址的运营商归属全部是 AS135377，没有一个是转租别人的机房。这一点比不少小厂干净，UCloud 香港 VPS 用的也是同一个 ASN。

UCloud 香港 VPS 和另外五个境外节点怎么排

同一批测试里还有五个境外地址，用同一套标准排一下顺序，比单看一个节点有用。

按 UCloud 香港 VPS 这套标准排，延迟最低的是日本东京，125.011 到 151.139，但丢包 20% 到 30%，直接排除。延迟第二低的是美国洛杉矶，168.920 到 182.639，丢包 5%，属于可用但要监控。德国法兰克福 217.122 到 259.667，两个源都 0% 丢包，是这批里唯一干净的境外节点。美国华盛顿 240.533 到 252.720，北京源丢 20%，要看你的用户在哪。新加坡那个 309.884 到 345.986，两源都丢 5%，延迟还最高，排在最后。

UCloud 香港 VPS 的位置比较特殊。延迟 18.632 到 49.214，最好的一次只有东京 125.011 的三分之一，但抖动也最大。它适合做面向大陆用户的入口，不适合做全球分发的中转。

如果业务要同时覆盖大陆和东南亚，比较稳的做法是香港加法兰克福两台，而不是指望一个新加坡节点。这次测下来，UCloud 香港 VPS 负责大陆入口，法兰克福负责欧洲出口，两段都不丢包，剩下的交给 CDN。

适合谁

适合的场景：需要一家资质正规、控制台成熟、能开票的境外云主机，对单包抖动有一定容忍度。UCloud 香港 VPS 在这类需求上不掉链子。广东源四次均值落在 18.632 到 27.124，按中间值 22 毫秒左右算，对建站、跑接口、做后台够用。

不太适合的场景：要求延迟稳定在 15 毫秒上下的实时业务，UCloud 香港 VPS 给不了这种一致性。广东源四次极差 8.492，单次 max 最高 110.918，这种抖动放到实时音视频上会很明显。要稳定，得接受北京源那种 48 毫秒起步但极差 0.742 的表现，或者换一条线路。

还有一个现实问题。价格和带宽档位这次没核对到，所以值不值得买这个问题不给结论。能给的只有网络层的事实，价格判断请自己在下单页核对。

真要下单，UCloud 官网产品页在 UCloud 云主机 UHost，测试地址的出处是 UCloud 数据中心测试 IP。想横向对比其他境外机房，可以看 主机商汇总，当前在售的优惠整理在 优惠码页面，已经做过的同类实测收在 VPS 测评汇总。

测试方法

方法写出来，读者才能判断数字的可信度。

两个探测源各在一台独立机器上。cn-probe-1 在广东，电信 AS4816 单线；cn-probe-2 在北京，阿里云 AS37963 BGP 多线。两台机器只做只读操作，ping 和 tracepath 都是系统自带命令，没有装任何加速或者代理。

延迟测试统一用 ping -c 20 -W 2，默认 1 秒间隔，跑满 20 包才算一次。香港地址每个源跑四次，取 min、avg、max、mdev 四项，用极差判断抖动。海外五个地址每个源只跑一次，作为横向对照，不参与抖动判断。

路由测试用 tracepath -n -m 30，每个地址跑两次，取第一次的跳点做图。tracepath 在 cn-probe-2 上可用，cn-probe-2 没有 mtr 和 traceroute。

归属复核用 ipinfo，逐个查测试地址和关键跳点的 ASN 与城市。这一步是为了排除「标着香港、实际在别处」的情况，165.154.147.137 就是这么查出来的。

本次没测的部分

说清楚边界比堆结论重要。

机器性能层没测。CPU、磁盘 IO、内网带宽这些都需要商家真机才能跑，本次没有开机器，所以不给任何跑分数字，也不拿别家的数据代替。

带宽上限没测。20 包 ICMP 只能反映路径延迟和丢包，反映不了端口能跑多快。UCloud 香港 VPS 的带宽档位和计费方式也没核对到，这一块完全留白。

长时间稳定性没测。四次 20 包是十分钟内的横截面，晚高峰、跨月结算前后的表现都可能不同。要看长期曲线，得自己挂一个持续 ping 的脚本跑一周。

另外，本次两个探测源都在中国大陆，测出来的数字只代表国内访问。海外用户访问 UCloud 香港 VPS 的体验，一个数字都给不了。

常见问题

UCloud 香港 VPS 的测试 IP 是多少

101.36.113.110。出处是 UCloud《UCloud数据中心测试IP》，发布 2026-04-15，页面把它标为香港，括号里写回内地加速线路。

UCloud 香港节点延迟多少

UCloud 香港 VPS 在 2026-10-29 双源各测四次 20 包：广东电信源均值在 18.632 到 27.124 之间，北京阿里云源在 48.472 到 49.214 之间，八次全部 0% 丢包。北京源更慢但更稳，极差 0.742 对 8.492。

UCloud 香港为什么广东源抖动这么大

看逐包回显就清楚。空载时 14 毫秒左右，但首包要 62.7 毫秒，中间还会跳到 36.1，单次 max 到过 110.918。mdev 11.202 到 29.975，是这些尖刺堆出来的。北京源同一时段 mdev 只有 0.174 到 1.892。

日本东京延迟低为什么不能用

因为丢包。广东源 20 包丢 4 个、北京源丢 6 个，丢包率 20% 和 30%。东京这条线延迟 125 到 151 毫秒本身不错，但三成丢包会让 TCP 反复重传，实际体验比 250 毫秒无丢包还差。

UCloud 香港节点多少钱一个月

这个数字不给。香港地域的配置、带宽和价格都在下单页按配置实时计算，本次抓取时活动页和价格文档都只返回前端外壳，没有可核对的静态价目，因此不列具体数字。要算成本，只能拿配置去下单页实时出价。

UCloud 香港 VPS 能不能用来建站

能，但要接受抖动。UCloud 香港 VPS 在广东源四次均值 18.632 到 27.124，中间值 22 毫秒左右，对普通站点够用；北京源 48.472 起步更慢但更稳。日活高、对首字节敏感站点，建议先用测试 IP 自己跑一轮再决定。