企業換用新 ISP 專線後，內網多台電腦同時出現 QQ 客戶端頻繁掉線（約 1 秒自動重連），但網頁瀏覽、其他應用正常。初步懷疑 ISP 線路故障，實際透過 Colasoft Capsa 網路分析系統深度抓包分析，鎖定根因為 騰訊 QQ 伺服器主動發送 TCP RST 封包斷開連線，與 ISP 無關。完整排查邏輯如下。

環境拓撲

• 50 Mbps 裸光纖專線 → 防火牆 (NAT) → 核心交換機 → 各樓層接入交換機 → 終端 PC
• 分析機器：筆記本部署 Colasoft Capsa，接入辦公區域交換機鏡像埠 (SPAN) 抓包。

關鍵觀測與排除過程

1. 頻寬排查： 防火牆出口雙向流量 < 20 Mbps，遠低於 50 Mbps 上限，排除頻寬飽和導致丟包。
2. 連通性基線： Ping ISP 互聯介面 IP 無丟包；Ping QQ 伺服器 (183.60.48.247) 僅少量丟包但不掉線，證明少量丟包非直接原因。
3. 掉線行為特徵： 客戶端掉線後約 1 秒即自動重連成功。典型網路擁塞/丟包導致的掉線，重連通常需數秒至數十秒（TCP 重傳超時、退避機制）。極快重連提示應用層主動斷開而非傳輸層超時。
4. 封包級證據： Colasoft 捕獲到 QQ 伺服器發送 TCP RST (Reset) 旗標封包，客戶端收到後立即釋放連線並發起新連線（SYN → SYN/ACK → ACK）。
5. 排除偽造 RST： 比對 RST 封包 TTL 值與前序正常封包 TTL 一致（均為 50），排除中間設備（防火牆/IDS/IPS）偽造 RST 干擾。

根因結論

QQ 掉線與 ISP 線路品質無關，係騰訊伺服器端因某種邏輯（如負載均衡切換、會話超時策略、風控判定、版本協商失敗）主動發送 TCP RST 終止客戶端會話。 客戶端自動重連機制掩蓋了斷連感知，表現為「閃斷」。

建議應對措施

• 升級 QQ 客戶端至最新版本，修復已知協商/心跳邏輯缺陷。
• 聯繫騰訊企業版/客服支援，提供抓包檔案 (PCAP) 要求伺服器端排查日誌。
• 若為企業內部自建 IM，檢查伺服器端心跳間隔、空閒超時、最大連線數、負載均衡會話保持 設定。
• 網路層面可部署 TCP 連線保活 (Keepalive) 偵測異常斷連，但無法阻止伺服器主動 RST。

方法論啟示

1. 症狀 ≠ 根因：「掉線」現象相同，原因可能是物理層、傳輸層、應用層、安全設備誤攔截。
2. 抓包是鐵證： 應用層日誌不可靠/不完整，唯有完整封包捕獲（含旗標、序號、TTL、時間戳）能還原真相。
3. TTL 驗證偽造： 判斷 RST/ICMP 差錯封包來源的關鍵指標。
4. 跨層協同分析： 網路層流量正常 + 應用層異常 RST = 定位至應用伺服器端邏輯。

本案例展示專業網路分析儀在複雜故障定位中的不可替代價值：從現象穿透到封包真相，避免無效的線路投訴與設備更換，直指問題核心。