概览背景有部分数据状态变更时需要通过回调地址通知客户内部系统更新数据状态。网络链路如下所示云平台-----客户nginx前置机 或其他防火墙----客户内网nginx ----java应用现象有些数据回调正常有少量数据回调异常客户本地数据无法更新状态导致查询本地库数据状态错误。拿具体的某个异常id查询相关日志发现以下现象1云平台回调客户本地服务云平台的回调服务日志中显示connection reset2客户nginx的error日志显示 connect() failed (connection refused)2024/10/12 16:59:29 [error] 87689#0: *197553200 connect() failed (111: Connection refused) while connecting to upstream, client: 47.94.142.197, server: localhost, request: POST /gateway/call/signDataSynCall HTTP/1.1, upstream: http://0.0.0.0:9999/回调接口url, host: 回调地址外网ip:端口3客户nginx打开了request_body开关但异常回调的数据看不到accesslog的请求体只能看到一个http请求 400的错误分析过程一 确认nginx配置http 400的错误搜网上大部分说请求参数的问题比如请求体太大等看nginx配置 最大500m没有超啊。二 跳过nginx直接访问java应用接口既然nginx到后台应用连接拒绝直接通过内网curl -xpost方式是否能回调成功呢直接应用是成功的说明java应用没问题。三 内网nginx访问接口直接内网访问nginx内网的ip80端口也是通的。映射出的外网访问就不通这很容易联想到是不是防火墙等其他拦截了问题到底出在哪儿里呢最终还是找到我们运维老大帮忙老大提供的建议是安全设备限制了…看nginx配置 upstream除了正常的ip:端口外还有个 0:端口 weight1是什么鬼大佬给去掉了但问题依然存在。回调不通的订单还是回调不通还是connection reset但和之前不同的是nginx的error日志里连接拒绝的没有了accesslog里的400也没有了其实error里显示了连接拒绝的ip端口 我还好奇0.0.0.0:9999怎么ip都是0原来配置的upstream问题。最终百思不得其解的我还是联系了客户的网络技术进行分析触发接口调用他进行抓包分析。四 问题大揭秘原来确实是被拦截了客户使用了Discuz这是一个门户的软件有些版本有漏洞回调的参数中字符串有的可能恰好和规则库里面Discuz!漏洞的字段吻合了导致被拦截客户添加来源ip白名单对于白名单里的回调内容排除拦截放行