把服务部署在AWS的EC2实例上，然后让中国大陆的用户直接通过公网访问，延迟表现到底如何？这个问题看似简单，实际答案却因区域、线路、时段不同差异巨大。本文基于真实环境的多次测试，给出各主要区域到国内不同运营商的延迟数据，并分析背后的线路原因，最后提供几套可行的优化方案，供选型参考。
一、各区域到中国大陆的实测延迟数据
测试方法很简单：在不同区域的EC2实例上开放ICMP响应，然后分别从中国电信、联通、移动三家的家宽和办公网络环境执行 ping 测试，每组测试持续五分钟，取平均值和丢包率。测试时间覆盖了白天工作时段和晚间二十点到二十三点的流量高峰，这样能更真实地反映用户全天访问的体验。
先看结果的大致分布。美国西部区域（-us-west-2，俄勒冈）到国内电信网络的平均延迟在160毫秒到190毫秒之间，晚高峰偶尔飙升到250毫秒以上，丢包率在1%到3%浮动。新加坡区域（ap-southeast-1）表现相对好一些，电信到新加坡平均约90毫秒到120毫秒，但走普通163骨干网时晚高峰丢包可能超过5%，体验明显劣化。东京区域（ap-northeast-1）到国内北方联通线路平均约80毫秒到100毫秒，是地理位置较近的选项之一。法兰克福区域到国内延迟普遍在200毫秒以上，除非业务面向欧洲，否则不建议国内用户直连。
# 在EC2实例上临时允许ICMP（Amazon Linux 2） # EC2安全组需放行 ICMP Echo Request（类型8） sudo iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT # 本地Windows环境执行持续性测试，观察丢包与抖动 # ping -t x.x.x.x # 或者用更精细的方式观察路由路径 # tracert x.x.x.x # Linux下推荐mtr，能同时看到每一跳的延迟和丢包 mtr -rwzc 100 x.x.x.x
需要强调的是，这些数字只能作为参考。AWS的公网路由并不保证固定，跨境出口的拥塞状况每天都在变化。同一个区域，电信用户 ping 出120毫秒，移动用户可能只有70毫秒，这取决于运营商国际出口的对接情况，而不是AWS单方面的性能问题。
二、延迟为什么这么高：线路层面的原因分析
理解延迟数据，必须先理解国内三大运营商的国际出口线路。国内访问海外服务器，传统上走的是163骨干网，也就是中国电信的普通国际线路。这条线路承载了绝大部分普通用户的跨境流量，晚高峰严重拥塞，丢包和延迟波动是常态。这就是为什么很多用户反馈白天访问海外EC2还算流畅，一到晚上就卡顿明显——流量本身没有变化，变的是出口线路的拥挤程度。
另一种是CN2线路，电信的精品网络，全程走相对独立的通道，晚高峰也能保持较低丢包。但AWS的EC2公网IP默认并不保证走CN2。新加坡、东京等亚太区域在某些时段、某些运营商方向上可能经过较好的路由，但这属于运气而非承诺。AWS官方文档明确说明公网互联网路由不可控，这也是为什么AWS推出了 Global Accelerator 这类产品来提供更优的边缘接入。
除了线路，物理距离造成的传播延迟是绕不过去的下限。光在光纤中的传播速度约为真空的三分之二，从上海到俄勒冈往返一次的物理延迟就有约120毫秒，再加上路由器转发、协议处理等开销，中美之间150毫秒左右的延迟基本是物理规律决定的极限。因此如果你的业务对实时性要求极高，比如实时语音、竞技类游戏，把服务器放在美国区域无论怎么优化都难以达到理想体验，选近距离区域加优质线路才是正确思路。
三、如何降低延迟：从架构到产品的优化方案
第一优先级永远是选对区域。面向中国大陆用户，可选择的海外区域按延迟从优到劣大致排序为：香港区域（ap-east-1）、东京、新加坡、首尔，然后再考虑美西。香港区域到广东电信的延迟可以低至30毫秒到50毫秒，是目前无需备案就能获得的最佳延迟表现。但要注意香港区域的EC2价格比新加坡高，且热门规格可能存在库存紧张的情况。
第二是叠加加速类产品。CloudFront作为CDN，适合缓存静态资源，其边缘节点在国内外的分布能让静态内容就近返回，但对动态请求帮助有限。Global Accelerator则利用AWS全球骨干网传输流量，用户就近接入AWS边缘节点后，流量走AWS内部专线到目标区域，绕开拥塞的公网路由，实测对跨洋动态请求的延迟和稳定性都有明显改善。代价是成本增加，适合对稳定性要求高的商业业务。
# 简单的延迟对比脚本：分别测直连与经Global Accelerator的响应时间
import time
import requests
TARGETS = {
"direct": "http://ec2-x-x-x-x.ap-northeast-1.compute.amazonaws.com/api/health",
"via_ga": "https://your-agl-alias.awsglobalaccelerator.com/api/health",
}
def measure(url, times=20):
total = 0.0
for _ in range(times):
start = time.perf_counter()
requests.get(url, timeout=5)
total += (time.perf_counter() - start) * 1000
return total / times
for name, url in TARGETS.items():
print(f"{name} average latency: {measure(url):.1f} ms")
第三是自建中转方案。在国内或香港拥有一台带优质线路的服务器（比如CN2 GIA的VPS），用 nginx stream 模块或者 HAProxy 做TCP转发，把国内用户的流量先接到中转机，再由中转机通过较好线路回源到EC2。这种方案灵活且成本可控，缺点是需要自己维护、自己保障中转节点的可用性，且要留意跨境数据传输的合规要求。
最后是协议和业务层面的优化。启用HTTP/2或HTTP/3能减少连接建立次数，配合TLS会话复用可以把高延迟链路下首次请求的耗时显著压缩。对前端资源做合理缓存、接口响应做精简、把一次大请求拆成多个并行小请求，这些手段在150毫秒以上的链路上效果尤其明显。说到底，跨境业务的体验是网络延迟和请求往返次数共同决定的，降不了延迟的时候，减少往返次数同样有效。
四、总结与选型建议
综合实测数据，可以给出这样几个结论：其一，AWS EC2公网直连国内，延迟由区域选择和线路质量共同决定，亚太区域是基础门槛，美西及更远区域仅适合非实时的后端任务。其二，晚高峰丢包是普通公网线路的通病，如果业务对稳定性敏感，要么选择香港区域，要么上Global Accelerator，要么自建优质中转，指望裸EC2公网IP走CN2属于碰运气。其三，协议优化和缓存策略是免费的加分项，任何跨境架构都值得做一遍。
如果是个人项目或内部工具，香港或东京区域直连通常已经够用，月成本也最低。如果是面向国内用户的正式商业服务，建议直接把网络加速成本算进预算，同时评估国内云厂商跨境加速产品作为对比方案，毕竟同样的钱在国内云的生态里可能买到更省心的效果。先小流量灰度实测，再决定全量架构，是应对跨境网络不确定性的最稳妥策略。