故障場景：
幾臺通過NAT訪問一臺服務器，服務器上開啓了tcp_tw_recycle用於TIME_WAIT的快速回收
故障現象和分析步驟：
1) 通過NAT出口的客戶端經常請求Web服務器無響應，telnet服務器端口不通，但是可以ping通。同一機房，有獨立IP地址的服務器不存在這樣的問題；
2) 在服務器抓包，發現服務端可以收到客戶端的SYN請求，但是沒有迴應SYN,ACK，也就是說內核直接將包丟棄了。
解決方法：
1) 關閉服務其端的tcp_timestamps，故障解決，但是這麼做存在安全和性能隱患；
2) 關閉tcp_tw_recycle，故障也可以解決。推薦NAT環境下的機器不要開啓該選項；
3) 也就是說這兩個參數不可能同時啓用。
後記：
1) 當tcp_tw_recycle和tcp_timestamps同時打開時會激活TCP的一種隱藏屬性：緩存連接的時間戳。60秒內，同一源IP的後續請求的時間戳小於緩存中的時間戳，內核就會丟棄該請求。NAT只改IP地址信息，但不會改變timestamp（TCP的時間戳不是系統時間，而是系統啓動的時間uptime，所以兩臺機器的的TCP時間戳一致的可能性很小），所以很容易造成連接失敗的情況。
2) TIME_WAIT狀態是用於保障連接正常關閉的，並不會消耗過多資源。在高併發環境中tcp_tw_recycle和tcp_tw_reuse經常被打開用戶快速回收和重用TIME_WAIT狀態的socket，在資源有限的情況下這麼多也無可厚非，不過也應該知道這麼做會帶來的後果。
轉載自：http://www.libertyvps.com/thread-262-1-1.html