亚太出海CDN实测，七家混战，谁在假装可扩展？

上个月,我帮一家东南亚电商做全球加速测试，选了三家号称“亚太全覆盖”的CDN，结果一跑流量——新加坡节点TTFB（首字节时间）直接飙到800毫秒，曼谷用户刷个图片库等了3秒才加载完第一行，客户当场拍桌子：“这破速度，海外用户早把App卸载了！”

这事儿让我下定决心：必须把市面上主流出海CDN拉出来溜溜，重点测“亚太可扩展”这个虚头巴脑的词到底有几斤几两，测试标准就一条——别跟我扯“节点多”，我要真实数据，谁在裸泳，扒干净。

先交代测试环境,工具：站长之家全国多节点ping工具、HTTPing（带延迟和下载速度）、自写脚本跑缓存命中率，测试对象：七家支持亚太的CDN，代号A到G，A是国际巨头，B是国产出海老炮，C、D、E是中小厂，F是新兴云厂商CDN，G主打东南亚本地，测试文件：1MB静态图片（防动态污染）、10MB压缩包（模拟真实下载）、100KB API响应（压缓存），测试时段：当地时间下午3点到5点（业务高峰期），连续跑48小时取平均值，放弃夜间“作弊数据”。

先看延迟,在东京节点表现最稳的是A和B，都压在28ms以内；E和F直接翻车，分别飙到62ms和55ms——多走了一层NTT公网路由，雷打不动，测到雅加达就精彩了：G号称“本地部署”，延迟58ms确实好；B稍微高一点点，61ms；A开始露怯，冲到89ms——绕了个新加坡做中心转发，曼谷更惨，A延迟103ms，用户加载感像便秘，而B和G都控制在72ms以内，这组数据说明：亚太“可扩展”第一条，得看有没有物理落点，别只靠公有云拉专线充数。

下载速度更刺激,10MB文件在孟买测，A掉到1.2MB/s，B、C、G都在4MB/s以上，原因很简单：A的东南亚边缘节点长期被大客户占满带宽，小用户跑测试就得“让路”，但你买服务时他可不会说，吉隆坡节点，F直接断流失败两次，技术人员去日志查，回了一句“节点过载自动熔断”，我直说了吧：节点多不等于能扩展，带宽池不够，高峰期就是废的。

综合下载速度排名：G > B > A（但后期疲软） > C > D > F > E，G和B在第一梯队，A中游偏上但有些节点“高级跛脚”。

缓存命中率是隐藏的雷点,100KB API响应文件，C家居然在多个节点跑到32%命中率——意味着68%请求都回源拉数据了，等于每三次请求就要去新加坡服务器打一趟，延迟直接翻倍，F家好一点，但回源带宽限制切得极低，测了10分钟就报529状态码，这个问题很要命：卖你套餐时都吹“99%命中率”，实际大都是只针对主流静态文件（图片、CSS）优化的，动态或低频请求回源一概不管，亚太可扩展，就必须扛得住混跑流量。

最后说两件小事,第一，台北节点测试中，看到D和E的缓存策略是“不分区域全量缓存”，导致小型文件在边缘存成几十份副本，命中率虚高但CDN费用翻倍，第二，G的曼谷节点IP被反查发现挂的是家庭宽带——虽然速度快，但稳定性存疑，掉包率0.7%，比别家高了零点几个点。

总结推荐：别迷信巨头，如果你的主战场在东南亚（印尼、泰国、越南），选G或B最稳——扩展性是真的拿节点堆出来的，不是玩路由绕路那一套，如果兼顾日本和印度，B综合最好，A得配合自家云产品用才能榨出价值，单独卖CDN就别冲了，预算有限选C，但要接受某些区域缓存命中率不如狗，至于F和E，建议直接放弃：一个超卖成性，一个节点少到像在“假装出海”。

亚太出海,可扩展不是PPT上的词汇，是每个节点静默扛住的并发量，实测完这七家，我只想说：卖CDN就像卖桶装水，标称10升不够，得打开嘴倒一倒，看能不能真装满20个杯子而不漏。