记一次回调失败问题

问题背景：

客户的问题是部分订单收不到回调，部分订单能正常收到回调，而回调的字段其实都是一样的，这不是很奇怪么？

分析过程：

网络拓扑大概如下图

找到一笔回调异常的订单，在阿里云日志服务器搜索相应关键字，日志显示400 bad request。

        从字面上好理解，可能是nginx等代理层因为客户端请求参数不合法返回的？那接下来需要先看下接收回调的负载nginx的日志。

        经过沟通通过远程客户的内网服务器【包括负载层，应用层（服务器上部署的java服务是我们提供的）】，但从云端发起该订单的回调时（也就是界面点击重试补偿回调，底层触发客户回调地址http请求），并未看到客户内网nginx的accesslog有请求日志，errorlog也没有；

        而其他回调正常的订单是有accesslog日志的，可以看到回调的报文json串。nginx没日志，难道nginx层上层还有其他代理或防火墙拦截了？但同事和医院网络管理员联系也没有其他代理了。那是为什么？

        我想到云端服务器上直接触发下http请求试试，拼回调字段json串，在云端的回调服务机器上curl发起请求  ，结果返回还是400 badrequest（和生产阿里云上400日志一致）

        再到客户内网的负载层直接内网ip访问试试呢，结果在对方服务器上直接内网curl  返回了正常的json，只不过是一个错误码的json，如下图所示。

        本想着内网curl如果正常，外网400的话就可以说明还是nginx上层哪儿有拦截，结果内网回调结果通是通，但结果不是success。

        为什么外网不是和内网一样返回 {"status":""}这种格式，而是返回了400？这个暂搁置，先看看内网为啥报参数不合法。这个错误码搜了下代码，是一个自定义的全局异常类，当controller层抛出异常后，由这个全局异常类将异常转换成错误码输出。

        参数为什么不合法呢，搜了下这个IllegalArgumentException异常，大概的意思就是传入的参数和controller里定义的requestbody对应的dto可能字段类型不对应，但怎么会不对应呢。难道我传的字段不对？想起了我的curl命令是这么写的

curl -XPOST -d '请求json串' http://内网nginxip/接口url，会不会是因为没有指定请求头是json的原因导致json参数没有对齐呢，本着试试看的态度，加上json的请求头，再次触发curl -XPOST -H 'Content-Type:application/json' -d '请求json串' http://内网nginxip/接口url 后确实正常了！

        再回到云端服务器，同样加上请求头再次curl也正常了。

遗留问题：

        但有个遗留问题并未想明白。不加请求头之前是400 badrequest 但这会儿我又试了下，变成和内网请求返回一样的错误码了？这才是正常的！但为什么之前是400 如上面第三个图。

        这是什么神奇操作，期间我一直都是探测接口，并未调整nginx什么配置，怎么就又是这个结果？有神力？不可能，写代码的人都是很务实和客观的，咱不相信那个，肯定还是谁动了啥？不然为啥之前一直订单重试回调（因为回调是mq消费，阶梯式间隔重试16次，11日的日志还显示一直都是400 bad request，今天怎么就好了呢，虽然问题今天最终解决了，回调都正常了，但谁解决的呢，满心疑惑...）