香港数据中心入驻前的网络测试项目，不能只靠一次测速判断。主动探测适合先看路径与稳定性；真实业务压测则要验证应用在预期流量下能否正常工作。两者应先后搭配：先建立基线、定位异常，再逐级加压并检查业务结果。
先分清两类测试能回答什么
主动探测：检查网络路径和日常波动
主动探测由测试端定时发送少量探测流量，记录往返时延（RTT）、丢包、抖动、路由变化及 DNS 解析情况。它适合观察香港机房到公司办公室、云服务区域或合作方网络的连通性，也可比较不同运营商接入或跨接线路的差异。若路径经过香港互联网交换中心 HKIX，也应记住：经过交换中心不代表到任一目的地都必然走同一路径。
业务压测：检查负载下的实际表现
业务压测模拟应用的真实请求与数据量，观察吞吐、响应时间、错误率及服务器资源。它能暴露带宽拥塞、连接数上限或应用处理能力不足，但不能单独证明故障在网络层。压测工具、数据接收端或应用服务器本身也可能成为瓶颈。
按顺序执行，避免把结果混在一起
先整理流量画像：列明测试源和目标、使用的协议、典型请求大小、并发连接及高峰持续时间。优先挑选能代表实际通信的接口和数据，不把单一大文件传输当作全部业务。
取得测试许可并划定边界：确认机房、网络服务商和目标系统允许的测试方式、地址范围与时间窗口。使用自有或获准的目标端，避免对公共网站、共享服务或其他租户施压。
建立主动探测基线：从计划接入的网络发起持续探测，分别记录不同时段的 RTT、丢包与路由。可用 mtr 或 traceroute 辅助观察路径；这些工具的中间节点响应可能受限，不能仅凭某一跳不回应就认定链路故障。
逐级进行负载测试：先以较低并发运行，再按计划提升至预期峰值。每一档维持数分钟并记录网络、应用和主机指标；若已接近预定上限或错误明显增加，应暂停，而非继续冲高。具体档位和持续时间要依服务容量、测试许可与风险确定。
对照结果并复测：在相同源、目标和业务请求下比较低负载与高负载数据。若空闲时稳定、负载上升后 RTT 和丢包同步恶化，可优先排查网络拥塞；若网络指标稳定但应用响应变慢，则检查服务器、存储或程序处理能力。
判断时看组合指标，不设通用门槛
香港到深圳、东京或新加坡的路径可能因运营商、接入方式和时段不同而表现不同，不能把某个固定 RTT 当作所有业务的合格线。互动操作通常更敏感于时延和抖动；批量传输更关注持续吞吐与中断后的恢复；实时音视频还需关注连续丢包对质量的影响。用同一业务要求比较不同线路，比套用单一数值更可靠。
建议保存测试时间、源与目标、路由、并发、发送量和应用错误记录。压测前后分别留存数据，才能判断变差发生在哪一层。若用 iperf3 测吞吐，应在自有接收端执行，并考虑 TCP 窗口、加密开销、磁盘读写及共享网络竞争等因素；测试结果不等于生产环境可持续容量。
搭配原则：先发现，再验证，最后复核
主动探测负责长时间、低影响地观察网络基线；业务压测负责在受控窗口验证目标负载下的实际体验。前者不能替代应用测试，后者也不适合取代日常监控。完成香港数据中心入驻前的网络测试项目后，应把发现的问题对应到线路、设备或应用层，并在调整后用相同方法复测。
常见问题
主动探测能代替压测吗？
不能。探测流量轻，适合看路径与稳定性，无法代表并发业务的资源消耗。
压测一定要使用生产数据吗？
不必。可使用脱敏数据或结构相近的测试数据，并确保请求模式与数据大小具有代表性。
测试时发现丢包，就能判定机房线路有问题吗？
不能直接判定。需结合端到端探测、路由信息、负载状态及服务端记录，排除中间节点限速和目标端过载等因素。
入驻前应测试多久？
没有适用于所有场景的固定时长。至少覆盖低负载、预期峰值和不同业务时段；若网络波动明显，应延长观察并重复测试。