当业务运行在Azure海外虚拟机时，国内用户经常反馈页面打开慢、接口请求转圈。很多人第一反应是升级虚拟机配置或增加带宽，但问题往往不在这。真正影响体验的关键因素是公网延迟，也就是数据包从Azure数据中心到国内用户终端所经过的物理路径和时间。不同Azure区域之间，这项指标可能相差数倍。本文用实际测试数据说明，选择哪个区域对国内用户最友好，以及如何量化监控这一指标。
一、测试环境与工具准备
测试选用了Azure全球版中几个常用于服务国内用户的区域：东亚（香港）、东南亚（新加坡）、日本东部和美国西部。每个区域创建一台配置相同的Windows Server 2022虚拟机，规格为Standard B2s，系统盘使用Premium SSD。虚拟机没有配置任何加速产品或自定义路由，完全走Azure默认的公网出口。国内测试端使用三台分别在电信、联通、移动宽带下的Windows 11物理机，位置位于上海、北京和深圳。由于Azure中国区由21Vianet独立运营，其公网线路与全球版不同，本次未纳入同组对比，但在优化章节会单独说明。
测试工具方面，Windows自带的ping命令使用ICMP协议，很多运营商和中间设备对ICMP的优先级较低，测出来的延迟不能完全代表真实业务。因此我们同时使用PsPing工具对TCP 443端口进行测试。PsPing是微软Sysinternals套件中的工具，下载后解压到本地目录，例如C:\Tools\PSTools，然后从命令行直接运行C:\Tools\PSTools\psping.exe。TCP测试会模拟真实HTTPS请求的握手过程，比ICMP更接近实际访问体验。以下命令表示从Azure虚拟机向国内某测试IP的443端口发起50次TCP连接测试。
# 进入工具目录 cd C:\Tools\PSTools # 向国内测试服务器发起 TCP 443 延迟测试 .\psping.exe -n 50 -w 2 203.0.113.10:443
为了让数据更全面，我们同时保留ICMP测试作为参考。在Windows命令提示符中执行ping -n 100 203.0.113.10可以将100次结果输出到C:\TestResults\ping_hk.txt，方便后续统计平均值和丢包率。测试过程中所有虚拟机均保持空闲状态，避免CPU或内存瓶颈影响网络栈处理。
二、多区域延迟数据对比
测试在非高峰时间段进行，连续3天每天3次，取平均值。下表是Azure各区域到上海电信、北京联通、深圳移动的TCP 443端口延迟，单位毫秒。
| Azure区域 | 上海电信 | 北京联通 | 深圳移动 |
|---|---|---|---|
| 东亚（香港） | 32 | 48 | 55 |
| 东南亚（新加坡） | 68 | 82 | 76 |
| 日本东部 | 46 | 72 | 65 |
| 美国西部 | 158 | 172 | 166 |
从数据可以明显看出，香港区域对国内三大运营商的整体延迟最低，上海电信可以做到32毫秒左右，接近国内同区域访问的体验。日本东部次之，但北京联通方向延迟偏高，说明该区域的回程线路可能绕行其他运营商。新加坡区域看似地理位置不远，但实际国际出口链路经常拥堵，延迟反而高于日本东部。美国西部延迟全部高于150毫秒，对于实时性要求高的业务基本不可接受。
ICMP测试结果与TCP略有不同。香港区域的ping平均延迟约为28毫秒，TCP延迟多出4到5毫秒；而美国西部的ping延迟约152毫秒，TCP延迟多出6到10毫秒。这是因为TCP需要经过三次握手，且中间设备对SYN包的处理可能比ICMP更慢。以下是在香港区域虚拟机上分别运行ping和psping的一段输出。
# ICMP 测试 ping -n 20 203.0.113.10 # 输出摘要 # 最小值 = 26ms，最大值 = 35ms，平均值 = 28ms # TCP 443 测试 psping -n 20 -w 2 203.0.113.10:443 # 输出摘要 # Minimum = 29.1ms, Maximum = 39.4ms, Average = 32.6ms
需要强调的是，延迟并不等于带宽。测试数据只反映数据包往返时间，实际业务吞吐还取决于虚拟机带宽、TCP窗口和丢包率。在同样的测试中，香港区域到上海电信的丢包率约0.2%，美国西部到上海电信为1.5%。丢包会触发TCP重传，导致更高层级的响应时间成倍增加，这也是很多跨境业务即使在延迟不高时依然卡顿的原因。
三、影响延迟的关键因素与优化方案
Azure数据中心之间的骨干网络质量非常高，但国内用户访问海外区域时，数据包必须经过国际出口和运营商互联点。这个环节往往不受Azure控制，也是延迟和丢包的主要来源。运营商之间的结算策略、路由调整、国际海缆负载都会动态影响路径。例如香港区域到上海电信的低延迟是因为两地之间有大量直连海缆，而新加坡到上海则可能经过多个中转节点。另一个容易被忽略的因素是域名解析。如果DNS服务器在海外，国内用户每次请求域名时都要先跨国查询，可能额外增加几十到上百毫秒。建议使用国内DNS服务或Azure DNS的国内分流策略。
针对国内用户，如果业务必须部署在Azure全球版，最直接的优化是选择东亚区域，也就是香港。对于延迟敏感但可以接受60毫秒左右的应用，日本东部也是可选方案。如果应用允许缓存，可以配合Azure Front Door或第三方CDN，把静态内容和API响应缓存在靠近用户的边缘节点。动态内容则可以通过边缘节点与源站之间的加速线路回源，而不是让用户直连虚拟机。下面是一个Azure CLI示例，用于创建Front Door实例并关联后端，注意命令中的参数根据实际情况修改。
az network front-door create \ --resource-group myResourceGroup \ --name myFrontDoor \ --backend-address 20.190.10.5 \ --accepted-protocols Https
如果业务合规要求数据必须存储在中国大陆，更推荐使用由21Vianet运营的Azure中国区。它的虚拟机到国内公网延迟通常可以控制在20毫秒以内，且不需要经过国际出口。但Azure中国区账号体系、服务种类和计费方式与全球版完全独立，部分新功能上线较慢，域名和内容也需要遵守国内备案规定。迁移前需要评估这些差异。对于已经部署在海外区域的应用，也可以使用ExpressRoute专线或者软件定义广域网方案，通过企业专线把国内办公室与Azure海外区域连接起来，但这适合企业级用户，成本较高。
四、持续监控延迟的自动化方案
网络延迟不是固定值，会随时间和运营商路由调整而变化。仅凭一次测试无法判断长期表现，因此建议在Azure虚拟机内部署定时任务，周期性记录到国内端点的TCP延迟和丢包率。Windows Server可以使用任务计划程序，创建一个每小时运行一次的任务，执行PowerShell脚本并把结果追加到C:\Logs\latency_log.txt。以下脚本使用Test-NetConnection命令测试到指定IP的443端口，并提取延迟信息。
$logFile = "C:\Logs\latency_log.txt"
$target = "203.0.113.10"
$port = 443
$result = Test-NetConnection -ComputerName $target -Port $port -WarningAction SilentlyContinue
$line = "{0} | {1}:{2} | Ping={3}ms | TcpSuccess={4}" -f (Get-Date).ToString("yyyy-MM-dd HH:mm:ss"), $target, $port, $result.PingReplyDetails.RoundtripTime, $result.TcpTestSucceeded
Add-Content -Path $logFile -Value $line
将上述脚本保存为C:\Scripts\TestLatency.ps1，然后在任务计划程序中创建基本任务，触发器设置为每天，间隔1小时，操作选择启动程序，程序路径填powershell.exe，参数填-ExecutionPolicy Bypass -File C:\Scripts\TestLatency.ps1。注意路径中的反斜杠必须保留。任务计划程序可以在C:\Windows\System32\taskschd.msc中打开。运行一段时间后，可以通过读取C:\Logs\latency_log.txt分析延迟趋势，当TCP成功率持续低于95%或延迟突然升高时，及时调整区域或启用备用线路。
除了自建监控，Azure Monitor中的网络性能监视器也可以提供从Azure到外部IP的丢包和延迟视图。它需要在虚拟机和本地端点安装监控代理，配置时指定源和目标，之后可以在Azure门户中查看历史图表。这种方式不需要写脚本，但会增加少量代理开销。对于没有Windows桌面环境的情况，也可以使用Linux虚拟机配合mtr命令进行路由追踪，检测具体跳点延迟。