系统留在悉尼服务新西兰用户：跨塔斯曼延迟到底差在哪一层

悉尼机房的监控面板一整周都是绿的：CPU 曲线平稳，出口带宽远没跑满，丢包计数维持在个位数，应用侧的接口耗时分布和澳大利亚本地用户几乎重合。可新西兰那边的客服工单里，同一句话反复出现——点一下要等一下。运维把慢查询日志翻了两遍，没找到可疑语句；把应用版本回滚了一版，抱怨没有减少。这种"一边指标正常、一边用户说慢"的错位，通常说明问题不在服务器能力上，而在用户到机房这一段路径，与页面上请求之间的依赖关系叠加之后，在用户侧呈现出的结果。两地看到的是同一套系统，但走的是完全不同的两段路程。

于是真正要盯的变量，不是地图上奥克兰到悉尼那条直线有多长，而是"一次交互被切成几次串行往返"。地图上两小时航程的距离，换算成光纤里的传播时间可能只有几十毫秒量级，这个数字单独拿出来并不惊人；但如果一个页面或一个操作流程要连续发起十几次不可并行的请求，每一次都要完整走一遍跨海往返，那么用户感受到的就是这个数字被乘了十几次之后的结果。与此同时，把负载往奥克兰搬，换来的是用户侧本地往返，交出去的是国际出口的集中度风险——后者同样是变量，而且往往在评估阶段被忽略。所以判断要同时看两个数：用户侧的往返乘法，以及出口依赖。

监控全绿却还是慢：这类现象先怀疑路径而不是配置

排查这类问题最容易走偏的方向，是从配置下手。因为配置是可控的、可回滚的，团队会本能地先怀疑最近一次发布、某条索引、某个连接池参数。但从现象本身看，有一个特征可以帮你在五分钟内做出方向判断：如果慢的感受只在某一类用户身上出现，而机房侧的聚合指标完全正常，那么服务端吞吐和单机性能基本可以排除——因为如果服务端真的扛不住，澳大利亚本地用户的耗时会先抬起来。

第二个特征是"慢"的分布形态。配置问题通常表现为耗时整体右移，或者某个接口的长尾变长；路径问题则表现为所有跨海请求都被加上了一个相对固定的底噪，而且这个底噪和业务复杂度无关——哪怕是一个什么都不做的健康检查接口，跨海调用也要付出同样的基础往返。把这两件事放在一起看，就能把排查方向从"服务器哪里配错了"转到"这一段路程由什么构成、被用了几次"。

还有一个常被忽略的观察点：同一套系统，新西兰用户里也会出现差异。使用不同本地运营商的用户，走到国际出口的路径不同，出海之后走哪条海缆系统也不同，这些差异不会体现在你的机房监控里，但会体现在用户侧的实测里。这也是为什么这类问题最终要靠用户侧或靠近用户的测量点来确认，而不是靠机房侧的面板。

新西兰用户到悉尼机房这一程由哪几段构成

把"新西兰用户访问悉尼机房"拆开来看，它至少由五段拼接而成，每一段的量级和可变性都不同。第一段是接入段，即用户终端到本地运营商网络的过程，家庭网关、移动网络信号、本地 DNS 解析都可能在这里贡献波动，这一段对跨海问题而言是共有的底噪，不是差异来源。

第二段是新西兰国内的汇聚段。无论用户在惠灵顿、基督城还是皇后镇，国际流量大概率要先向奥克兰方向汇聚，才能进入国际出口。这一段对新西兰本地用户来说，都会发生，但它意味着南岛用户的跨海总时长里，还额外叠加了国内南北向的一段。

第三段是跨塔斯曼海的海缆段，也就是光在光纤中的传播时延构成的物理下限。这一段与距离成正比，几乎不随业务量变化，也无法通过优化代码压缩——它是这条路径上最"硬"的部分。第四段是悉尼侧落地之后的城域与机房接入段，包括落地站到机房的传输、机房内部网络。第五段是回程：请求到达服务器、处理完成之后，响应还要原路再走一遍，也就是说你看到的"一次访问"，实际付出的往返是去程加回程。

把这几段分开的意义在于：你能优化的部分主要在请求次数和缓存命中率上，而不在第三段的物理传播时延上。如果你的优化方案是"想办法让光跑快一点"，那方向就错了；真正能动的变量是"这段固定成本被付了几次"。

国际出口为什么集中在奥克兰附近的少数登陆点

海缆登陆点的选择不是均匀的。一条国际海缆要在哪里上岸，取决于一系列硬性条件：合适的近岸海床地形与登陆窗口、能承接落地站的陆上设施、与既有骨干网络的衔接距离，以及长期运维的可达性。这些条件同时满足的位置并不多，而新西兰最大的城市与网络枢纽在奥克兰，因此已建成的国际海缆系统登陆点高度集中在这一带——包括奥克兰周边的 Takapuna 一侧，以及向西海岸延伸至 Raglan 的登陆点。

依据已核验的公开资料：新西兰周边除上述系统外，还存在 Southern Cross Tasman Express、Tasman Ring Network 等系统，其登陆点同样集中在奥克兰周边区域。这个集中度带来一个直接结论：奥克兰事实上成为新西兰国际出口的关键节点。也就是说，新西兰用户访问澳大利亚、访问北美，绝大多数流量的物理出海点都在这一小片区域。

这件事有两面。好的一面是，如果你要在新西兰一侧布置服务，选在奥克兰附近意味着离国际出口最近，跨海之后的接入段最短；不好的一面是，集中度本身就是故障域——登陆点周边的一次物理事件、一次施工、一次设备故障，影响范围都可能超出单点。做部署取舍时，这两面必须一起看：你既在争取"离出口近"的收益，也在承接"依赖同一片登陆区域"的风险。

单次往返不大，会被串行请求乘成体感差距

公开估算口径给出的奥克兰到悉尼往返在 30 毫秒量级，不同来源给出的区间大约落在 25–40 毫秒。请注意，这是估算或第三方观测口径的参考值，不是本文的实测结果，实际往返需你以自己的用户分布和运营商路径自行实测确认。单看这个数字，它对绝大多数交互来说都不值得大动干戈——人对几十毫秒的差异通常没有明确感知。

问题出在乘数上。一个页面或一次操作，通常不是"发一个请求、收一个响应"这么简单：DNS 解析、连接建立、安全握手、首字节、主文档、若干资源、若干接口调用，其中有一部分是可以并行发出的，另有一部分必须等前一个结果回来才能决定下一步——后者就是串行请求。对于串行部分，用户感知到的等待时间大致等于串行次数乘以单次往返，再加上服务端的处理时间。

把数量级摆出来：单次往返按 30 毫秒量级估算，串行 10 次就是 300 毫秒量级，串行 20 次就接近 600 毫秒量级。这些数字是依据上述估算口径做的算术推演，用于说明结构关系，不是实测值，也不构成任何性能承诺。关键点在于，同样的单次往返，在请求模型简洁的系统上几乎不可感知，在串行依赖多的系统上会被放大成明确的用户体验差距——这就是为什么"要不要加一层"这个问题，答案往往取决于你的请求模型，而不是取决于那个往返数字本身。

由此也可以推出一条实用的判断顺序：在讨论搬不搬之前，先把新西兰用户典型路径的串行请求次数统计出来。如果串行次数只有两三次，那么加一层带来的收益可能远小于它引入的运维复杂度；如果串行次数在十次以上，且其中大部分无法并行化，那么加一层的收益就有讨论空间。

哪几类交互最容易把这个乘法放大：登录、列表分页、表单提交

并非所有交互对往返的敏感度都相同。最敏感的是那些"用户盯着屏幕等、且步骤之间必须串行"的操作。登录是典型：客户端要完成会话建立，服务端可能要做凭据校验、风险控制判断、跳转回传，其中每一步都可能依赖上一步的返回；如果还叠加了重定向或二次跳转，跨海往返的次数就会成倍增加。而登录恰恰是用户对等待最敏感的场景之一，因为它发生在用户还没进入系统、注意力最集中的时刻。

列表分页是第二类。翻页本身每次是一次请求，但如果列表要按权限过滤、要取排序字段、要合并用户维度的个性化数据，一次翻页可能被拆成几次串行调用。更麻烦的是，分页是重复动作——用户会连着翻好几页，每一次都在为同一段跨海往返付费，累积起来的体感损失比单次大得多。

表单提交是第三类，也是最容易被低估的一类。提交往往不是一次写操作就结束：先校验、再写库、再返回结果，某些业务还会触发二次确认或页面刷新。更关键的是，表单提交通常伴随重试——用户在等待期间如果点了第二次，服务端可能收到重复请求，这在跨海场景下因为往返长、用户更容易等待焦虑而变得更常见。所以这类交互的优化重点不只是减少往返次数，还包括让提交具备幂等性。

相对而言，可并行加载的资源类请求对往返不那么敏感，因为它们可以并发发出，总耗时接近单次往返加传输时间。区分这两类，是判断优化优先级的起点：先砍串行，再谈其他。

三条长期承担新西兰国际连接的海缆系统各自的角色

从公开资料看，新西兰的国际连接长期依赖少数几条海缆系统，它们各自承担的延伸方向不同。第一条是 Southern Cross Cable Network（SCCN），通往澳大利亚、斐济、夏威夷与美国西海岸，是较早承担新西兰国际连接的系统之一。

第二条是 Hawaiki，公开资料记录其于 2018 年开通，通往澳大利亚、夏威夷与美国俄勒冈州。第三条是 Tasman Global Access（TGA），通往澳大利亚，其新西兰登陆点位于 Raglan。三条系统在澳新这一段上都有承载作用，差异主要体现在跨太平洋之后延伸向哪个方向。

理解"角色差异"比记住名字更重要。对于一个把主系统放在悉尼、服务新西兰用户的团队来说，这三条系统共同决定了两件事：其一，澳新这一段并非只有一条路可选，理论上存在路径多样性；其二，具体走哪一条不由你决定，而由运营商的路由策略、容量调度与当时的链路状态决定。也就是说，路径多样性的存在，不等于你可以在故障发生时随时切换——那是运营商层面的动作，不是应用层面的动作。这一点在做应急预案时必须提前想清楚。

新系统入役之后改变了什么：容量与冗余的另一面是路径选择变复杂

公开资料记录 Southern Cross NEXT 在 2022 年进入可服务状态（RFS），全长约 13,700 公里，连接澳大利亚、新西兰、美国与部分太平洋岛屿。按其长度折算的单向光纤传播时延约 67.2 毫秒，理论往返下沿约 134.3 毫秒；第三方公开监测的实际往返高于该下沿。需要特别说明：该数值是按缆长折算的理论下沿，不是用户侧体验值，也不是澳新之间的往返，它对应的是这条缆全程尺度的量级，不能直接拿来判断奥克兰到悉尼的用户感受。

新系统入役带来的直接变化是容量与冗余的增加，这是正面的一面。但另一面常常被忽略：可用路径变多之后，"实际走哪一条"这件事变得更难预测。多系统并存意味着运营商在路由选择上有了更多组合，调度可能依据容量、成本、维护窗口或故障状态动态调整。对应用方而言，这带来一个具体后果——你在某个月测到的路径表现，未必等于下个月的表现，因为路径可能已经变了。

推论是：不要把单次测量结果当成长期结论，也不要依据一次测量结果去做不可逆的架构决策。更稳妥的做法是在一段时间内、在多个时间点、从不同用户分布位置采样，观察区间和波动范围，而不是盯一个点。依据上述已核验事实可以推断，多系统并存提高了整体韧性，但同时也让"路径表现"从一个常量变成了一个变量。

哪些层值得先搬：静态、边缘缓存、读写分离的位置感

如果最终决定在新西兰一侧加东西，那么"加什么"比"加不加"更影响结果。一个常见的顺序是按层的可缓存性和一致性要求从低到高推进。最先搬的通常是静态资源层：图片、脚本、样式、字体这类内容，一致性要求低，缓存命中后可以直接在新西兰侧返回，能把首屏的大部分请求从跨海变为本地。

第二层是边缘缓存，包括页面级缓存和可缓存的接口响应。这一层的收益通常比静态层更大，因为它覆盖的是原本需要打到悉尼的部分动态请求；代价是你要设计好失效策略与回源路径——缓存一旦失效，回源请求仍然要走跨海，所以在冷启动或大规模失效时，用户侧的表现会出现明显的"两级分化"：命中很快，未命中回到原点。

第三层才是读库的只读副本。把读副本放到应用层附近是通用部署思路示例，不指向任何具体客户，也不构成性能承诺。但这一步的代价明显上升：主从复制在跨海条件下的复制延迟会被放大，如果业务存在"写完立刻读"的场景，把读副本放近反而可能引入读到旧数据的问题。所以这一步的前提，是先摸清你的读请求里有多少比例对数据新鲜度敏感。

最后才是应用层整层迁移，而写库与主数据通常留在原地。理由不是技术偏好，而是事务一致性、运维复杂度与数据治理三方面的叠加。把顺序反过来做——先搬应用、缓存还没铺好——往往会出现"往返没减少、复杂度先上来了"的结果。

会话、幂等与数据一致性在两地部署里怎么保证

两地部署里最先暴露问题的往往不是性能，而是状态。会话是第一个：如果两侧都有应用层，而会话存储只在一侧，那么另一侧每次校验会话都要跨海读一次，等于把往返从用户侧转移到了服务之间，乘法效应以另一种形式回来了。常见的处理思路是让会话具备可共享的存储，或者让会话绑定在一侧并通过路由保证同一用户落到同一侧，两种做法各有代价，需要按你的流量切换频率来选。

幂等是第二个。跨海往返变长会提高用户重复点击的概率，也会提高客户端超时重试的概率，两者都会造成同一笔业务被提交多次。让写操作具备幂等键、让重试可识别、让重复提交在业务层被折叠，是两地部署前的必要准备，而不是可选优化。这一项不需要等你决定加哪一层就该做——它在单地部署下同样有价值。

数据一致性是第三个，也是最难被简化的一项。要点在于先分清哪些读要求"写完立刻读到最新"，哪些读可以容忍短暂滞后。前者应当继续走主库所在的一侧，后者才适合放到靠近用户的副本上。复制延迟在跨海场景下会被放大，但放大的程度取决于链路状况、写入量与复制机制，无法凭经验给出，需要你按自己的写入模型实测确认。

突发流量与活动窗口：路径选择要提前排，不要当天排

跨海链路的容量安排和本地机房不一样：它涉及的不只是你自己这一侧的机器，还包括落地之后的传输、运营商侧的调度，以及可能的临时容量安排。这意味着在大促、内容首发、版本大范围灰度这类活动之前，路径与容量需要提前规划，而不是在活动当天临时调整。

具体要提前排的有三类。第一类是缓存预热：如果新西兰一侧有缓存层，活动开始前要确保热点内容已经命中，否则第一波用户的请求会集中回源，把跨海往返的成本一次性付掉，还会对源站造成额外压力。第二类是灰度窗口：把新西兰流量逐步放开，观察用户侧表现，而不要一次性全量切换。第三类是降级预案：明确当链路表现恶化时，先降级哪一部分——通常是先牺牲个性化与实时性，保住可完成的主流程。

还要考虑活动窗口与维护窗口的重叠。海缆系统与落地设施会有计划内的维护安排，这类信息通常由运营商侧掌握，应用方未必能提前获知，但它会直接影响活动当天的路径表现。因此在大活动之前，向你的链路提供方确认该窗口内是否有已知的计划性工作，是应当列入清单的一项。

故障域怎么画：登陆点与海缆中断时的应急预案顺序

画故障域要从物理层往上画。最底层是登陆点及其周边区域，前面提到登陆点高度集中在奥克兰周边，这意味着一次局部事件的影响边界可能覆盖多个系统。往上一层是单条海缆系统，再往上是运营商的路由域，最后才是你的应用层。把这张图先画出来，才能判断某一类故障会影响多少用户、有没有替代路径。

关于地震这类事件，第三方公开监测记录了一个可供参考的样本：2026 年 10 月 15 日新西兰 Otorohanga 附近发生 M5.3 地震期间，TGA（登陆点距震中约 94 公里）平均往返约 29 毫秒，Southern Cross NEXT（登陆点距震中约 203 公里）基线往返约 159 毫秒，期间未见中断报告。这是第三方公开监测口径的记录，不是本文的实测结果，也不代表任何常态表现或性能承诺；它能说明的只是：在该次事件中，不同系统登陆点与震中的距离差异很大，且该事件未造成可观测的中断。请把它当作"故障域要按登陆点逐个画"的一个例证，而不是当作对某条链路优劣的判断。

应急预案的顺序建议按这个序列排：先确认影响范围，判断是单条系统、单个登陆点，还是更上层的路由问题；再判断是否存在可切换的路径，以及切换由谁执行——这一步要提前确认，因为路径切换通常是运营商侧的动作，不是你在机房里能直接完成的；然后是应用侧降级，包括只读模式、静态兜底、把非关键写操作转为异步队列；接着才是流量调度或灾备切换；最后是回切与复盘。很多团队把顺序写反了：一发现异常就切换，结果切换动作本身成为第二故障源。

数据留在哪一侧：法域与交付/乙方要求的影响

性能之外的另一类约束来自数据本身。公开信息显示，新西兰为五眼成员之一；部分业务在决定数据存放地点时，会把这一法域因素纳入考虑范围。此处仅作客观陈述，不作价值判断，也不展开相关内容。对技术团队而言，这条约束的实际含义是：数据存放地点有时不是性能优化题，而是合规与客户交付题。

第二类是交付与乙方要求。如果你的客户是企业或机构，合同中可能已经写明数据存储地域、审计权限、访问日志留存等条款；这类条款一旦存在，就是硬约束，应当先于任何性能讨论被满足。把硬约束识别出来的顺序应该是：先列合同条款与行业要求，再列法域因素，最后才轮到往返与体感这类优化项。

一个实用的处理办法是把数据分类后再谈位置：身份与凭据类、交易与账务类、行为与日志类、内容与静态类，它们对位置和新鲜度的要求完全不同。分类之后你会发现，真正被硬约束锁住的往往是其中一两类，其余部分仍有按性能取舍的空间。这样处理，比"整个系统留这边还是搬那边"的二元提问更容易得出可执行的结论。

澳新两地的三种组合与适用边界

把前面各节的变量收拢起来，落地选择大致可以归纳为几类。需要说明的是，下表列出的是方案特征与适用边界，用于辅助判断结构，不指向任何具体客户，也不构成性能承诺。每类方案的真正差异不在"快多少"，而在它把哪一种成本留在了用户侧、哪一种成本转移到了运维与国际出口依赖上。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。在两地取舍这类问题上，把不同节点的线路构成与路由选择放到同一张表里比较，比只看单点位置更接近真实效果。

需要提醒的是，这张表里的"适用情况"是按结构特征归纳的边界，不是按用户占比划的硬线。同样是三成新西兰用户，一个以静态浏览为主的媒体站和一个以表单交互为主的 SaaS，落点可能完全不同——决定因素是请求模型，不是比例本身。

搬还是不搬：两地方案绕不开的六个问号

新西兰用户占到多少比例，才值得考虑在奥克兰加一层？比例只是参考值，更重要的是这三类指标：新西兰用户的典型路径上串行请求有几次、他们的访问集中在哪个时段、他们使用的是否为高频交互功能。三成用户如果都是浏览型访问，加一层的收益可能低于运维成本；两成用户如果集中在表单提交与登录这类串行交互上，收益反而更明确。建议先统计请求模型，再回头看比例。

先搬静态资源，还是先搬读库？顺序怎么定？通用思路是先静态与缓存，后读库。原因是前者一致性要求低、可逆性强，出了问题可以快速回退；后者会引入复制延迟与"写完立刻读"的一致性问题，一旦处理不当，影响的是业务正确性而不是快慢。把可逆性强的动作排在前面，是这类改造的通用原则。

奥克兰附近的海缆如果发生中断，业务会立刻不可用吗？取决于你的方案是否具备替代路径与降级能力。如果全部留在悉尼，那么影响表现为新西兰用户侧的往返质量下降甚至连接困难，服务端本身仍在运行；如果应用已搬到奥克兰，则要面对出口集中度问题。因此应急预案的重点不是"保证不中断"，而是明确中断时的降级顺序与切换责任人，并且提前演练。

开启压缩与连接复用，能不能把跨塔斯曼的往返成本抵消掉？能减少一部分，但减少的部分与往返不是同一个量纲。压缩主要削减传输字节数，对大体积响应有帮助，对多次小请求帮助有限；连接复用能省掉重复的连接建立与安全握手，对"串行多次请求"的场景有实际收益。但两者都无法改变物理传播时延，也无法把串行改成并行。所以顺序是：先做连接复用与请求合并，减少串行次数，再谈压缩。

应用搬到奥克兰、数据库留在悉尼，是不是等于把往返换到了内层？正是如此，而且可能变得更严重。原本用户侧的一次往返，可能变成应用与数据库之间的多次往返——一次页面渲染如果需要十几次查询，那么跨海查询的次数就是十几次。这也是为什么"应用层整层搬"通常要与读副本或缓存层一起考虑，单独搬应用层往往得不到预期的体感改善。

两地部署之后，故障排查要按什么顺序看？建议从外向内：先确认是单侧用户受影响还是双侧都受影响；再看受影响的运营商范围，判断是否为接入或汇聚段问题；然后看国际段是否有已知事件或计划性工作；最后才回到应用与数据库。反过来的顺序容易让人在应用日志里耗费大量时间，而问题其实在更外层。

数据放在新西兰一侧还是澳大利亚一侧，需要额外确认什么？先确认合同条款与行业要求里是否写明了存储地域，再确认是否存在法域层面的考虑，最后确认你的数据分类中哪些属于硬约束范围。这三项明确之后，剩下的部分才适合按性能取舍。需要自行核实的部分请以你所在机构的法务与合同约定为准。

哪些判断必须你自己实测或向运营商确认

需要明确划界：本文不提供任何实测延迟数据；文中引用的数值均为公开资料或第三方公开监测口径的参考值，实际往返以你自己的用户分布、运营商路径与实测结果为准，需自行实测确认。本文也不比较任何服务商的报价、不讨论具体带宽单价。

必须由你自行实测确认的有四项。其一，新西兰用户到悉尼机房的实际往返区间——注意要测区间而不是单点，且要在多个时段、多个本地运营商下采样，因为路径可能随时间变化。其二，典型交互路径上的串行请求次数，这个数字决定乘数，也决定加一层值不值。其三，缓存命中率与回源比例，它决定"搬缓存"这一方案的真实收益，也决定冷启动时的用户侧表现。其四，应用与数据库之间的查询次数，它决定"只搬应用层"是否会适得其反。

需要向运营商或链路提供方确认的有三项：当前实际承载你流量的路径是哪一条；是否存在计划内的维护窗口与活动期安排；故障发生时的路径切换由谁执行、流程与时效如何。这三项都不在你的控制范围内，但它们直接决定方案的可行性与应急预案的有效性，因此必须提前确认，而不是等出问题再问。

还有一类判断需要按业务自身来定，无法从通用结论推导：你的读请求里有多少比例要求"写完立刻读到最新"；你的用户能否容忍短暂的功能降级；你的团队是否具备两地运维的常态化投入。这些问题的答案不同，同一张取舍矩阵的落点就会不同。

关于澳新两地部署取舍的几条判断线

把全文收拢成几条可直接使用的判断线。第一条：跨塔斯曼的单次往返本身不算大，真正决定体感的是它被串行请求乘了几次；所以在讨论搬不搬之前，先把串行请求次数统计出来，这个数字比用户占比更能决定答案。

第二条：搬到奥克兰换来的是用户侧的本地往返，交出去的是国际出口的集中度依赖——奥克兰周边集中了新西兰主要的国际海缆登陆点，这既是"离出口近"的收益，也是一个需要画进故障图的故障域。两个变量必须同时看，只看其中一个都会得出偏颇的结论。

第三条：改造顺序按可逆性排，静态与缓存先于读库，读库先于应用层，写库与主数据通常最后动。这个顺序的依据不是技术难度，而是出错后的影响面与回退成本。

第四条：路径表现是变量而不是常量。新系统入役增加了容量与冗余，同时也让实际路径的选择变得更复杂，因此不要把单次测量结果当成长期结论，也不要依据一次测量做不可逆决策。

第五条：性能是优化项，合同与法域要求是硬约束。先列硬约束，再谈往返与体感，顺序反了会做出表面合理、实际不可交付的方案。

本文的信息来源与奥克兰节点延迟说明

本文引用的地区与链路事实，全部来自公开资料或第三方公开监测口径，具体包括：新西兰国际连接长期依赖 Southern Cross Cable Network（通往澳大利亚、斐济、夏威夷与美国西海岸）、Hawaiki（2018 年开通，通往澳大利亚、夏威夷、美国俄勒冈州）、Tasman Global Access（通往澳大利亚，登陆点在新西兰 Raglan）等系统；Southern Cross NEXT 于 2022 年被记录为可服务状态，全长约 13,700 公里，按其长度折算的单向光纤传播时延约 67.2 毫秒、理论往返下沿约 134.3 毫秒，第三方公开监测的实际往返高于该下沿；2026 年 10 月 15 日 Otorohanga 附近 M5.3 地震期间 TGA 与 Southern Cross NEXT 的监测记录；以及奥克兰周边还存在 Southern Cross Tasman Express、Tasman Ring Network 等系统、登陆点同样集中在奥克兰周边区域这一事实。奥克兰到悉尼往返 30 毫秒量级（不同来源约 25–40 毫秒）为公开估算或第三方观测口径。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。方案大致确定之后，机型、带宽、线路可达性与报价仍要以官方实时信息或咨询确认为准。

再次说明：以上事实与数值均不代表任何服务商的产品、节点或报价；文中出现的延迟相关数字均为公开资料或第三方公开监测口径的参考值，其中按缆长折算的理论往返下沿并非用户侧体验值，澳新之间的实际往返需你以自己的用户分布与运营商路径自行实测确认。任何部署决策，都建议以实测结果与链路提供方的确认为准。