问题描述

客户反馈线上业务大量回调失败，具体报错如下。但客户反馈本地去测试向回调服务发起请求，回调服务是可以正常接收请求的，但回调服务器上找不到OSS发起的回调日志。

com.aliyun.oss.OSSException：Error status ：502

[ErrorCode]: CallbackFailed

[RequestId]: 6131E16DA8654B3338371A32

[HostId]: xxx.oss-cn-shenzhen.aliyuncs.com

问题排查

1. 初步分析

根据报错来看，502错误一种可能是回调服务直接响应了502，另一种可能是OSS向回调服务地址发起回调时候直接连不上或者会阻断，导致没有走到七层。初步判断是OSS到回调服务器之间的网络问题。

2. 基调探测

在阿里网站运维监测平台发起基调探测，探测客户的回调地址，发起有很多地区都存在连不上的请求，请求被reset （connection reset by peer）。从探测结果来看，也怀疑是回调服务器的问题。

3. 抓包确认

本地模拟测试发一个post请求到客户回调服务确实是正常的，没有复现到问题。因此尝试到基调平台上抓包，同时由于阿里网站运维检平台目前暂时不支持抓包，因此先考虑用第三方基调"听云"平台去探测抓包。因为OSS用的深圳区域，因此直接在听云上用深圳三大运营商去发起探测，发现也是存在部分请求被重置（reset）的情况。

抓包分析发现有以下几个点
（1）21、25、26三个包是三次握手包，25号是回调服务器的握手sync包，通告的win窗口居然是0。
（2）三次握手成功以后，28号包直接发了reset包，从报文看这是服务端发了reset包。
（3）从TTL看，服务端握手sync包(25号)包 的TTL是119，服务端reset包(28号)包的TTL也是119，说明这种现象不太可能是劫持行为。因为如果不是服务端发的reset包，而是被网络链路的其他节点劫持以后发的reset包，那么TTL不会刚好也是119。基于以上，基本上可以确认是回调服务器的原因造成的。

问题原因

经过确认，原因是客户自己回调服务器的EIP有自带DDoS的防护功能，防护阈值是固定的，比如200Mb（入带宽）。在客户业务量上涨后，客户扩容了带宽，但DDoS 访问阈值没有跟着调整，导致业务量上涨后触发了DDoS防护机制，开始流量清洗。这次是Sync 访问的清洗，服务端通过回Sync+Ack+Win=0来阻断这次应用链接。

适用产品

对象存储OSS