接口排查不能靠猜：实战中如何用抓包工具精准定位问题（含 Charles 使用示例）
几乎每个写代码的开发者都经历过这样的时刻：接口突然返回空、请求超时、前端数据没更新……你试过重启服务、翻查日志、改代码打印，最后还是无解。
我想说，其实很多问题的答案都藏在“网络请求”里，只是你没有去看。
这篇文章，我不打算“测评工具功能”，而是结合自己的开发经验，聊聊在不同场景下，我是如何通过抓包一步步排查问题的。
场景一：前端接口报错但后端没日志
这是最常见的“扯皮现场”。
前端同事反馈某个功能点突然 500 报错，但后端服务中却查无此请求。我们用 Charles 给前端代理了一下网络，发现接口其实根本没有发出请求，而是被浏览器 CORS 拦截了。
问题根源是接口新增了鉴权头，但后端配置中漏加跨域允许头，浏览器预检请求失败导致真正的请求根本没被发出。
工具选择：Charles
→ 通过抓包看到 OPTIONS 请求 403，找到源头。
场景二：移动 App 偶发网络异常
有一次测试安卓客户端在某些 Wi-Fi 网络下总是“加载中”。抓包后才发现是 App 连接第三方服务的 TLS 握手失败，部分运营商会在中间插入证书，而客户端没正确处理异常，导致请求挂死。
我们切换到 Charles，设置代理 + 安装证书后，完整重现了异常过程，并截取错误数据上报给 SDK 提供方。
工具选择：Charles + Wireshark（验证 TLS 握手）
→ 移动端 HTTPS 问题必备工具组合。
场景三：一个接口在 A 地区正常，在 B 地区失败
这属于经典的“网络分区”问题。
接口在某地访问正常，另一个地方却提示超时。我们用 mitmproxy 写了个自动抓取脚本，部署在两台不同地理位置的服务器上并发请求，抓取到 DNS 解析差异——B 地区请求被解析到了旧 CDN 节点，导致请求慢甚至失败。
后来才发现是 CDN 厂商节点未同步变更。
工具选择：mitmproxy + curl + diff
→ 自动比对请求时间、状态、响应结构。
抓包中常用技巧合集
| 任务场景 | 建议工具 | 说明 |
|---|---|---|
| HTTPS 移动端抓包 | Charles | 配证书，安装简单，UI清晰 |
| 多地对比请求效果 | mitmproxy | 命令行自动化，适合脚本 |
| 请求重放验证 | Charles/Fiddler | 改参数测试返回逻辑 |
| 查看 TLS 协议细节 | Wireshark | 支持查看握手包和证书链 |
| 模拟网络异常 | Charles | 限制带宽、断点修改响应 |
关于 Charles 中文资源
Charles 虽然是国外工具，但中文社区很完善。特别是这个站点，不仅有详细的安装和证书配置指南，还提供了抓包案例、操作视频等内容，推荐给还没用过或刚上手的开发者：
https://www.charlesproxy.net
最后的话：工具只是辅助，思维才是核心
无论你用 Charles、Fiddler、Wireshark 还是其他工具，重点不是会不会点，而是能不能用它解构问题、验证假设、佐证判断。
抓包不光是“能抓包”，而是“会读包”。
你开始读了吗？