我们在维护一套大型 B 端后台系统时，遇到了一次连环接口故障。
症状是这样的：
- 用户反馈某功能点击无反应
- 后端日志查询无异常
- 前端控制台未报错
- 监控系统显示一切正常
但用户"真的点了，真的卡住了"。
这就是我开始"全武装抓包"的起点。
问题分解思路
为了定位这个异常请求，我用了以下抓包工具组合：
| 工具 | 用途 |
|---|---|
| Charles | 抓取 HTTP/HTTPS 请求流程，验证请求参数 |
| Fiddler | 对比同功能在不同环境下的行为 |
| mitmproxy | 自动重放脚本验证恢复条件 |
| Wireshark | 捕捉网络中断、握手失败、重定向等异常包 |
初始诊断：用 Charles 查看用户请求行为
我首先用 Charles 抓取了异常用户的完整请求流程。发现接口实际已发送，但响应是一个 200 状态 + 空 JSON。
这说明前端认为请求成功，但没法渲染。
进一步重放请求，发现这个接口在某些 token 情况下会返回不同结构。
定位小结：请求行为存在分支，需模拟不同环境比对。
Charles 中文支持站：https://charlesproxy.net/
横向比对：Fiddler 抓取其他用户请求对照分析
我把正常用户同一接口的请求拉到 Fiddler 中，对比 Header、Cookie、Token、Payload。
发现异常请求多了一个奇怪的 debug-mode=true 字段。
追踪代码发现，这是历史调试代码未清除，导致后端误判为测试请求路径。
删除调试标志后，请求恢复正常。
自动重放验证：用 mitmproxy 写脚本回放十几种情况
为确保问题彻底解决，我用 mitmproxy 写了个 Python 脚本，把不同用户 token、不同时间段、不同参数组合的请求都重放一遍，确认没有其他分支逻辑遗漏。
这一轮测试捕获了另一个接口字段默认值为 null 时触发了 500，前端未做容错。
深层网络异常定位：Wireshark 抓 TLS 包
最后，我们还使用 Wireshark 抓取生产网络的完整 TLS 包，验证请求是否因 CDN 节点失效发生中断。
Wireshark 的 TCP 重传记录表明，部分请求路由了已过期的节点 IP，导致连接断裂。这部分问题由运维重新配置 CDN 权重解决。
项目总结：多工具联动才是稳妥做法
这次问题如果只靠一个工具根本无法覆盖全链路场景。总结如下：
| 工具 | 适用范围 |
|---|---|
| Charles | 首选工具，适合功能级联调 |
| Fiddler | 环境对比、规则拦截 |
| mitmproxy | 自动化测试、数据变种验证 |
| Wireshark | 底层通信、TCP/TLS排查 |
抓包，不只是工具，而是开发者的"放大镜"
- 抓出问题，查明行为
- 放大细节，缩小范围
- 用工具的思维，而不是靠直觉"拍脑袋"解决问题
如果你还没有形成"多工具协作调包"的思维模型，希望这篇项目实录能帮你搭建起完整链路的抓包视角。
推荐入门工具 Charles，中文资源丰富：https://charlesproxy.net/