在一次版本更新后，我们的后端监控发现 iOS 端某接口 QPS 突然飙升数倍，甚至超过安卓端。没有异常崩溃、也没有大规模新增用户，唯一现象是服务端同一用户会在一分钟内多次重复请求该接口。

这是最难排查的异常：既不像崩溃能看到日志堆栈，也没有用户主观反馈问题，只有冷冰冰的接口流量激增数据。我们依靠抓包和流量复现，完整地还原了问题触发链。

背景：接口 QPS 大幅提升，无用户感知

问题接口为首页刷新数据接口，按逻辑只需每次进入首页请求一次。但后端日志显示同一用户在短时间内重复调用同一接口，每次请求参数完全相同。

分析团队初步怀疑：

• App循环重试导致重复请求；
• 网络环境引发意外重发；
• iOS端 SDK 更新后行为改变。

调试目标拆解

为了还原真实行为链，我们将问题拆解为四步：

1. 确认 App 是否重复发出请求
2. 判断请求是否由于网络中断自动重发
3. 验证请求间隔及参数是否存在规律
4. 重现问题环境并复现异常

工具组合与分工

抓包过程详解

步骤一：用 Charles 验证桌面请求行为

在 Electron 客户端上通过 Charles 抓包：

• 进入首页只触发一次请求；
• 请求体、参数、Header 与文档一致；
• 无重复或意外请求。

桌面端没有问题，锁定问题只在 iOS 端。

步骤二：用 Sniffmaster 捕获 iOS 真机真实请求

连接 iPhone，通过 Sniffmaster 抓包进入首页后的真实行为，抓到如下情况：

• 每隔约 5 秒，App 会重复发起一次首页刷新接口请求；
• 请求内容完全一致，无新的 token 或时间戳；
• 当页面停留时间越长，请求次数越多。

这一步确认了：重复请求确实是客户端行为，而非网络问题。

步骤三：用 mitmproxy 模拟网络波动

为了排除网络原因导致重试，我们通过 mitmproxy 编写脚本，将响应延迟 3 秒：

def response(flow):
    if "/home/refresh" in flow.request.path:
        import time
        time.sleep(3)

结果 App 依旧在 5 秒后发出下一次请求，无论网络是否稳定。这表明重复请求与网络状态无关，而是 App 内部定时触发。

步骤四：用 Wireshark 验证是否 TCP 层重发

通过 Wireshark 抓包 iPhone 的流量，检查是否存在 TCP 层意外重传：

• 每次请求都是新的 TCP 连接；
• 未出现重复 ACK 或 RST 引发的连接中断；
• 表明 App 在应用层主动发起新请求。

步骤五：通过 Postman 验证接口是否具幂等性

用 Sniffmaster 抓到的请求体在 Postman 中多次重放，确认后端对相同内容的请求并未合并或去重，确实每次都完整处理。也就是说，后端并未做幂等控制。

问题定位与成因

结合抓包结果可确定：

• iOS 端 App 在进入首页后，因定时器逻辑未清理，在页面停留时继续周期性触发接口请求；
• 此问题在页面退出后才能停止请求；
• 该定时器行为仅在 iOS 5.3 版本引入，安卓端未出现。

根因是一次优化首页“数据实时性”的改动，将自动刷新频率硬编码为 5 秒，但未结合页面离开或进入状态进行控制。

修复方案

1. 为首页自动刷新定时器增加生命周期监听，页面离开即销毁；
2. 添加网络状态检测，仅在网络可用时执行刷新请求；
3. 在请求参数中引入唯一请求 ID，后端可做幂等处理；
4. 加入首页停留时长上限，避免用户长时间停留导致流量激增；

工具组合带来的全链路视角

这套组合让我们排除掉“网络问题”“后端异常”等干扰，将问题准确定位到 App 行为逻辑，并快速制定修复方案。

小结

流量异常激增不一定是外部攻击或后端故障，很多时候只是客户端行为的非预期后果。iOS 平台抓包更要依赖物理连接型工具（如 Sniffmaster）配合其他工具，让你清楚每次请求的来源、规律和触发条件。