在移动 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 网络逻辑、系统机制、异常处理的完整理解。今天分享的调试过程并不复杂，但却是定位调试中的关键能力。

如果你也在排查 “请求不稳定”“登录无响应” 或“断网后行为不一致”问题，不妨参考这套流程还原真相。