引言
問題往往出現在意想不到的地方；問題分析時，我們需要更多的資料作為支撐。
問題現象
某天晚上使用者回報業務經過高防産品後間接性的無法擷取到資料；判斷是高防的問題導緻的，由于是線上業務需要我們緊急處理。
第一優先級恢複業務
使用者回報由于源站證書問題，無法進行域名解析回源的。當時萌了，還有這種操作；随後的排查：
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 ；開啟後問題現象消失。