在移動 App 的開發中，中斷網絡環境（如切換到飛行模式再回網）后，App 在重連過程中有時會出現請求未重新發送或丟包的情況。這類問題難重現、難定位，尤其在 iOS 平臺上更容易被忽視。我們最近就遇到一個用戶反饋“切換網絡后，App 丟失第一次登錄請求”問題，通過一套抓包流程還原了真實問題路徑。

---

問題背景：飛行模式恢復后請求丟失

用戶反饋，在 iOS App 使用過程中，如果啟用了飛行模式后再關閉，隨后嘗試登錄，App 表面上顯示登錄失敗，但后端未收到任何請求。安卓上測試流程正常，且登錄請求始終能發到服務端。

我們決定從抓包層面確認：iOS 是否在恢復網絡后丟棄第一次登錄請求？

---

任務拆解：需要回答的關鍵問題

1. 網絡恢復后是否觸發了登錄請求？
2. 登錄請求是否被系統網絡層吞掉？
3. 請求內容是否被構造正確？
4. 換用其他工具環境條件是否有所不同？

---

工具使用 & 職責分工

工具	作用
Charles	抓取桌面端和 Web 登錄流程，對比行為差異
Sniffmaster	獲取 iOS 真機的登錄請求是否發出與結構
mitmproxy	模擬網絡恢復條件，驗證登錄補發機制
Wireshark	輔助分析底層 TCP 重試或丟包情況
Postman	重放請求驗證參數是否完整、結構是否一致

---

步驟一：桌面與 Web 登錄行為對比

我們首先在桌面端和瀏覽器中模擬“斷網—恢復—登錄”流程，用 Charles 抓包：

• 登錄請求始終能發到接口；
• 請求響應時間略有延遲，但不會被丟棄；
• 登錄參數字段、簽名與 Header 均正常；

因此排除參數或服務端問題，懷疑是 iOS 網絡層或 App 中請求發送流程存在問題。

---

步驟二：使用 Sniffmaster 確認 iOS 發包行為

我們連接 iPhone，通過 Sniffmaster 重新跑同樣流程：

1. 打開 App，飛行模式開啟；
2. 點擊登錄按鈕（UI 有提示“登錄中…”）；
3. 關閉飛行模式；
4. 觀察 Sniffmaster 捕捉結果；

抓包結果顯示：

• iOS 并未在恢復網絡時再次發送登錄請求；
• 僅在首次點擊后 App 內啟動登錄流程，但隨后沒有重新觸發；
• Sniffmaster 能解密 HTTPS 內容，確認請求未發出；

這一步證實問題存在于 App 請求邏輯層，而非系統層隱式丟棄。

---

步驟三：用 mitmproxy 模擬網絡中斷與恢復

我們通過 mitmproxy 腳本模擬網絡恢復后延遲發送，并添加日志:

def request(flow):if "/login" in flow.request.path:print("捕捉登錄請求，時間:", flow.request.headers.get("Client-Time"))

結果表明，登錄請求只在按鈕首次點擊時生成一次，不論網絡是否恢復，App 都沒有再次嘗試。確認 App 內無補發/重試機制。

---

步驟四：用 Wireshark 驗證 TCP 底層行為

通過 Wireshark 抓包，檢查 iPhone 恢復網絡后，是否有 TCP 握手或嘗試連接：

• 飛行模式切換時，僅能看到 DNS 查詢恢復；
• 并無 SYN-ACK 握手嘗試后續登錄請求；
• 無 TCP 重傳或因丟包而觸發的自動重試行為；

進一步確認：App 真沒發出登錄請求，不是網絡丟包導致。

---

步驟五：在 Postman 還原登錄重放驗證參數正確性

最后，我們提取 Sniffmaster 中正常邏輯下的登錄字段，在 Postman 中重放。無論網絡環境如何，Postman 都能成功發出請求并收到響應，參數字段完整。這一步消除了參數構造或簽名機制的干擾因素。

---

問題定位：App 缺乏重試機制導致請求丟失

整個調試過程表明，iOS App 在網絡恢復后的登錄流程中：

• 登錄請求只觸發一次；
• 若第一次因無網絡而失敗，App 內沒有同步觸發重新登錄；
• 導致登錄“界面完成”，后端無響應；
• 安卓端有重試機制，用戶多次點擊后登錄成功，行為一致性更好；

---

執行改進建議

我們建議：

• 登錄按鈕點擊后，加入網絡可用性監聽并自動補發一定次數請求；
• 在請求超時或失敗時，新增用戶提示與重試邏輯；
• 增加退出重試機制，以防用戶關閉后再次進入為空狀態；
• 將這一流程記錄為“網絡異常補償流程”，寫入產品規范。

---

工具協作價值總結

通過以下工具組合，我們才完整還原了問題鏈：

• Charles：驗證跨平臺行為差異；
• Sniffmaster：捕獲 iOS 真機是否發包；
• mitmproxy：模擬網絡切換，構建測試路徑；
• Wireshark：驗證是否為網絡層問題；
• Postman：排除參數構造影響；

每個工具只做它擅長的事情，最終拼出“請求丟失”真相，避免下結論前只看界面或單平臺行為。

---

小結

iOS 抓包不僅是拿到包這么簡單，它關乎你對 App 網絡邏輯、系統機制、異常處理的完整理解。今天分享的調試過程并不復雜，但卻是定位調試中的關鍵能力。

如果你也在排查 “請求不穩定”“登錄無響應” 或“斷網后行為不一致”問題，不妨參考這套流程還原真相。