20 天，170 万次请求——我的阿里云 ESA 数据复盘

上篇我说接入 ESA 之后，访问速度“肉眼可见”地变快了。现在快 20 天过去，我把控制台导出的真实数据翻出来看了一遍——这篇就用这些数据，把“肉眼可见”再验证一次。毕竟要推荐给你用，光说“好用”不算数，得拿数字说话。

一、为什么写这篇：数据从哪来

上篇写的是接入体验——为什么接、怎么配、体感如何。但体感是自己的，你要真跟着做，光有“我觉得快”不够。这篇我想换个目标：认真推荐一次。推荐就得有依据，把控制台里能导出来的真实数据摆出来，比什么都实在。

数据从哪来？ESA 控制台支持导出站点的访问统计，我导了一份：区间 2026-08-01 到 2026-08-25 16:40，时区 +08:00，站点 liuhangyv.top。这份数据谁都能导，操作不难，你也可以自己核对。

这 25 天里，累计请求约 169.9 万次，四舍五入就是约 170 万。口径得先说清楚，别误导你：25 天只是区间长度，实际有流量的约 20 天——头 5 天（08-01 到 08-05）基本没流量。所以后文里的“约 170 万”，是约数，也是 20 天跑出来的数，不是 25 天均摊的。

二、总量与趋势：170 万次请求是怎么涨上来的

先交代总账。把每天的数据加起来，累计约 170 万次请求。头 5 天没有流量，真正有请求的 20 天，平均每天 8 万多——对个人站点来说，这个量级不算小。

把按日曲线拉出来，能明显看到量级变化，从 1 万出头到 27 万，不到一个月。08-06 才开始有流量，1.3 万，算是个起步；中旬基本稳定在 2~6 万，属于日常水平，每天的内容更新、仓库拉取差不多就是这个量。

转折点在 08-13，突然冲到 13.6 万，比日常高出一大截；08-14 到 08-17 又回到 5 万多、6 万多的水平，像是喘了口气。接着 08-18、08-19 连续两天爆发，分别到 20.9 万和 27.9 万，后者是这段时间的单日峰值。到了下旬，回落到 5~16 万，节奏基本恢复正常。

至于那几天为什么爆，我没细查具体是哪些天被转发、被拉取，但曲线确实明显高出一截。流量从来不是匀速的，它像公交车的早晚高峰，平时一两分钟一班，高峰挤成一团——对应到请求上，就是大多数日子平平淡淡、偶尔来几天尖峰。峰值哪天来、为什么来，往往要等事后复盘才有答案。把 170 万拆成“每天 8 万多”和“偶尔 20 多万”，才算真正看懂它。以后看监控，我会先盯日均和峰值这两条线，而不是被一个总量唬住。

三、缓存命中率约 66%：动态为主的站点，够不够用

先看缓存状态的分布：DYNAMIC 134.45 万，NONE/UNKNOWN 12.25 万，HIT 11.57 万，MISS 5.89 万，BYPASS 5.05 万。DYNAMIC 占了绝大部分，说明我的站点请求里，动态请求是主力。剩下 NONE/UNKNOWN 和 BYPASS 量级都不大，对整体影响有限。

66.3% 这个数怎么来的，得先说清楚口径：它只对可缓存请求算，也就是 HIT 加 MISS 这两类，11.57 万除以 11.57 + 5.89，约等于 66.3%。换句话说，66% 是对能缓存的那部分请求说的，那些直接判成 DYNAMIC 的请求，根本没进这个分母。这个口径很重要，不然看到“命中率 66%”会觉得偏低，其实是计算范围不同，不是站点不行。

DYNAMIC 占大头，听着像“没缓存到”，其实不是坏事。我的站点主体是 Git 仓库加博客，Git 拉取、API 调用都是动态请求，本来就不该被缓存。ESA 对这类请求做的是就近接入和回源优化，不等于“没加速”；真正走缓存的，是图片、CSS、JS、封面图这些静态资源。这就像食堂两个窗口分工，套餐窗口提前打好菜，对应静态资源直接出餐；现炒窗口按单现做，对应动态请求现场回源——两个窗口都有人在忙，不代表没在干活。

落到我这种以动态为主的站点，66% 的意思是：静态资源基本被边缘节点扛住了，源站轻松很多。判断有没有用，先看自己的站点是静态多还是动态多，别拿别人的命中率标准往自己头上套。真要比较，得拿同类站点、同一口径放在一起看才有意义。对我这种动态为主的站点，够用。

四、流量都从哪来：仓库才是大头，还有约 50 万 Bot

看完总量，我特别好奇：这约 170 万次请求到底打在哪。导出来的 Host 分布先把我自己吓了一跳——排在前面的居然不是博客。

占大头的是 lhy-git.liuhangyv.top——我个人的 Gitea 仓库，100.93 万。博客 blog.liuhangyv.top 只有 22.45 万，协会的 gitea.liuhangyv.top 16.26 万，www.liuhangyv.top 3.6 万，根域 liuhangyv.top 3.51 万。我一直以为博客才是流量主角，结果仓库把博客甩开一大截。五个加起来约 147 万，剩下约 20 多万散在其它子域和直连请求上，不影响结论。

原来我流量大头是 Git 仓库，不是博客。

这个发现挺实用。很多人（包括我）觉得边缘加速是给网站准备的，可 Git 仓库的 clone、push、网页浏览都是高频请求，一次 clone 就要拉一堆对象，接上 ESA 一样吃得到缓存和就近节点。所以别只盯着博客，给仓库接也值。

再看运营商。口径先说清楚：Other 有 144.21 万，占大头，能被识别出运营商的部分反而少。但就在这部分里，移动 9.98 万、电信 6.74 万、联通 3.21 万、阿里 4.4 万——三大运营商都有真实访问，说明国内节点就近接入不是噱头，不同网络的访客都能在离自己近的节点拿到数据。

设备那边扫一眼就好：Desktop 85.28 万、Windows 56.09 万、Chrome 71.87 万。一句话总结，主流就是桌面端 + Windows + Chrome，跟我的使用场景基本对得上。

Bot 单独说。浏览器统计口径里，约 50.47 万次请求被识别为 Bot，在浏览器统计里占了近三成，真的从防护层走过一遍。别把它理解成攻击，它就是个统计分类；但换个角度想，这么大比例的自动化请求都被接住，这套防护不是摆设，替我省了不少源站压力。

五、20 天下来，值不值得用

账在前面都算过了：累计约 170 万次请求、单日峰值 27.9 万、可缓存请求命中率约 66%，移动、电信、联通都有真实访问。直接说结论。

我的答案是：对我这种个人站，值。

一是国内节点就近接入。移动、电信、联通的真实访问在前面都看到了，对国内访客这条是实打实的。跟 Cloudflare 比，对国内访客更贴合，我不用再纠结海外节点绕一圈的问题。

二是加速和防护一体化。命中率和 Bot 那两笔账算完，源站压力是实打实省出来了。加速不用单独配，防护也在干活，省心也省带宽。

三是接入门槛低。域名解析改一下、等节点生效就完事，没折腾多久。你手上有博客或者仓库，接入就三步，不妨先接一个月，月底导一份数据出来看看，比我空口说一百句都管用。

接下来我会继续盯着月底的曲线，看命中率和 Bot 占比还会不会变。这次不是靠体感，是数据：约 170 万次请求、单日峰值 27.9 万、约 66% 的可缓存命中率，都说明这套加速是真在干活。阿里云 ESA 的边缘安全加速值不值得用，数据替我说完了。# 阿里云 ESA #边缘安全加速