引言

问题往往出现在意想不到的地方；问题分析时，我们需要更多的数据作为支撑。

问题现象

某天晚上用户反馈业务经过高防产品后间接性的无法获取到数据；判断是高防的问题导致的，由于是线上业务需要我们紧急处理。

第一优先级恢复业务

用户反馈由于源站证书问题，无法进行域名解析回源的。当时萌了，还有这种操作；随后的排查：
1、请用户处理源站证书，全部处理正确；随后全部域名解析回源。
2、分析高防4层&7层日志 是否有拦截情况。

分析高防日志

在高防的4层和7层日志上，没有任何的异常返回码以及拦截记录。即高防没有啥问题

源站处理

用户将源站证书处理正常；将域名全部解析回源，但是依然发现有问题。
反馈的业务架构为：Client->cms..cn(slb-ECS)->content.x.cn
其中b.com是在高防上的。但是均已经解析回源负载均衡了依然有问题，苦于联系不到用户的开发同学；与客户达成共识暂定白天继续分析。

深入分析

业务恢复
白天开发操作，由原来的请求访问b.com 修改为内网负载均衡之后，问题现象消失。需要我们配合查询原因，同时不认可是应用问题；判断的依据是真正的通信域名一直在高防上

Review业务结构

针对这个情况拉上用户的运维，开发，我们的同学与用户对齐信息；了解到如下信息
用户的运维和开发是2个部门，操作完全是分开的。晚上操作的b.com回源其实没有效果，因为当时cms.x.cn(slb-ECS)访问的域名是content.x.com；content.x.com这个域名一直解析在高防上没有解析走过。
Review分析过程
根据用户的数据
cms.x.cn(slb-ECS)这5个ECS的公网地址是需要大量的访问 content.x.com 这个域名的。

分析高防7层日志

分析过程中发现共5台ECS的公网IP，但是在高防的7层日志里只有3台的数据量是正常的；其他1台没有日志，1台非常少。这个数据是符合间接性的失败的情况。

分析高防4层日志

分析过程中发现用户的5台ECS的公网IP，在4层日志都是有的，且量还不小。

分析初步结论

开始认为可能为高防的VIP到7层代理之间，或者7层代理的问题。但是经过与开发同学的讨论
1、LB 流的日志是正常的。所以当时的网络以及Tengine不太可能有问题。
2、用户是走的https协议，那么三次握手完成之后，应该是要进行ssl握手。
最终判断比较大的可能是由于当时ssl握手的时候，出现了问题。

验证问题

将其中一台请求基本没有的ECS的链接地址修改为高防/SLB，然后在该ECS上进行抓包分析。看到的抓包如下，肯定完成三次握手后，没有进行ssl握手的动作直接断开了链接；这个行为是不符合预期的。

随后用户对比正常与不正常的服务配置。
定位到是由于php的配置文件中，没有开启模块extension=php_openssl.dll ；开启后问题现象消失。