1、查閱資料，查下close_wait 狀態的直接原因，期間可以再次熟悉下 tcp 三次握手，四次揮手協議的基礎知識。
2、通過查詢資料，最終可以確定的是nginx本身問題，根據網上常推薦的兩種方式分別調整系統和nginx本身的引數均無法解決此問題。
1）系統層面（快速釋放空閒的tcp連線）

net.ipv4.tcp_keepalive_time=30
net.ipv4.tcp_keepalive_probes=2
net.ipv4.tcp_keepalive_intvl=2

2）nginx（引數配置）

tcp_nodelay on  

3、查閱nginx本身配置，發現有引用lua指令碼獲取請求中的cookie id，並且相關指令碼中使用了aws redis 服務，初步懷疑是redis請求延遲導致。同時也懷疑是nginx 版本bug導致，又是一通咕咕。
4、後來其他同事提醒懷疑是lua指令碼問題，負責管理nginx的同事註釋掉對應lua指令碼並進行排查，最終定位為獲取cookie id 的lua 指令碼導致——去掉指令碼，重啟nginx問題解決。

function cookie_id()
            local cookie, err = ck:new()
            if not cookie then
                return "-"
            end
            local fields, err = cookie:get("JSESSIONID")
            if not fields then
                return "-"
            else
                return fields
            
 
end
end

總結：

根據TCP 四次揮手協議可以判斷：哪臺伺服器出現CLOSE_WAIT，就是哪臺伺服器上部署的應用程式有問題（不管是服務端還是客戶端），無論是開源服務，還是自己開發的應用程式，在此基礎上分析問題。一般為程式碼邏輯或訪問外部資源問題導致。