阿里云 ESA 翻车实录：内网 IP 竟能刷穿流量计费？

最近折腾云服务的圈子炸锅了，有个哥们儿吐槽说自己阿里云 ESA（边缘加速服务）的账单突然暴涨，一查日志好家伙，竟然全是内网 IP 在疯狂请求。

这事儿听着就很离谱。咱们平时理解的内网 IP，比如 192.168.x.x 或者 10.x.x.x，根本不应该出现在公网加速服务的访问日志里，更别提计费了。结果这次不仅出现了，还把主人的钱包给干瘪了。这到底是配置问题，还是云厂商的计费机制有漏洞？今天咱们就来扒一扒这背后的技术逻辑，顺便聊聊怎么防坑。

图：典型的云服务计费异常与网络拓扑关系示意图，帮助理解内网 IP 如何参与流量计费。

一、 离谱的现场：内网 IP 是怎么混进来的？

正常情况下，CDN 或者 ESA 这类的边缘加速服务，回源的流量通常是经过公网的。但是，有些架构比较特殊的场景，可能会出现例外。

1. 混淆的代理层 有些用户为了省钱或者特定需求，会在源站前面再套一层反代，而且这个反代和 ESA 节点之间可能通过某种隧道或者专线连接。如果中间的代理配置不当，没有正确传递 X-Forwarded-For 这类头信息，或者 ESA 在读取客户端 IP 时取了错误的变量，就有可能把中间代理机的内网 IP 当成真实访客 IP。

2. 负载均衡器的锅 如果你源站前面挂着阿里云自家的 SLB（负载均衡），而 SLB 又配置了某些内网转发策略，ESA 回源请求到达 SLB 时，SLB 看到的“客户端 IP”可能是 ESA 节点的内网地址（具体看网络拓扑）。如果 ESA 的计费逻辑判断依据是回源日志里的 IP，那确实有可能产生误判。

图：分析服务器访问日志（Nginx/Apache）以定位异常流量的操作界面。

3. 恶意刷流量的新姿势？ 还有一种比较阴谋论的说法，就是有人利用协议漏洞或者反射攻击，通过伪造请求包，让 ESA 记录到大量看起来像内网 IP 的数据。虽然 RFC 1918 定义的内网地址不应该在公网路由，但在应用层日志里，这完全是可控的字符串。

二、 计费机制的迷之操作

大家最关心的点其实是：为什么内网 IP 流量还要钱？

云厂商的边缘加速服务，通常分为“下行流量”和“回源流量”收费。如果是内网 IP 在刷，说明请求要么是 ESA 节点发出的，要么是 ESA 节点接收的。

• 如果是回源流量计费爆了：那说明 ESA 疯狂去请求你的源站，而源站日志显示来源是内网。这很可能是因为 ESA 和源站在同一个 VPC 或者通过专线互通，虽然物理上没走公网，但在逻辑计费上，厂商依然把它算作了“回源流量”。很多厂商的专线/VPC 流量虽然便宜，但不是免费，甚至计费规则比公网还复杂。

• 如果是请求次数/下行流量爆了：那问题更严重。这意味着 ESA 把某些内网请求当成正常业务处理了。这通常涉及到边缘脚本（Edge Script）或者规则配置的疏忽，可能把某种健康检查或者内部握手流量也纳入了计费范围。

三、 遇到这种事儿该怎么办？

如果你发现自己账单不对，千万别急着付钱，先按下面这几步排查：

1. 下载全量日志：去 ESA 控制台把访问日志 Down 下来，别只看控制台那个简略的统计。重点看 client_ip 和 remote_addr 这两个字段。

2. 交叉对比源站日志：看你源站（Nginx/Apache 等）的日志，看看对应时间段的请求是什么情况。如果两边 IP 对不上，那就是头信息传递丢了，得去改 ESA 的回源配置。

3. 检查计费项目：看清楚是“下行流量费”贵了，还是“请求次数费”炸了，或者是“回源流量”的问题。不同的问题对应不同的解决方案。

4. 立刻工单找阿里云：这绝对是典型的计费争议。把日志截图整理好，直接提交工单申诉。只要证明是异常的内网循环请求或者是厂商的节点问题，一般都能退款。

四、 避坑指南：如何防止被刷？

吃一堑长一智，咱们在用这类边缘服务时，还是得加上几把锁：

• 设置带宽/流量上限：在 ESA 或者云账号层面，设置一个日消费阈值。一旦超出，直接熔断，别心疼服务中断，总比背债强。

• 开启 IP 黑白名单：如果你业务只针对特定地区，直接在 ESA 的边缘防护里把其他地区的 IP 拦了。虽然这次是内网 IP 搞鬼，但大多数时候防刷还得靠这个。

• 配置 Referer 防盗链：简单粗暴，防止别人盗用你的链接去当中转站，尤其能防住一些恶意的脚本刷量。

这次事件也给咱们提了个醒，云上的“内网”和“公网”界限有时候在计费层面是很模糊的。大家以后配置服务时，尤其是涉及回源、VPC 互通这些高级功能时，一定要多看一眼计费说明，不然那个“羊毛”没薅到，反被厂商薅了秃皮。