很多人以为“抓包”就是一件很标准化的事情，只要用上 Charles 或 Fiddler，装好证书、配好代理，就能看到所有请求。

但现实中，你会发现：

• 有些请求能抓，有些完全抓不到；
• 同一个App里，部分功能能抓，部分功能不显示；
• 模拟器没问题，真机却全是空的；
• 明明发了请求，但抓包工具完全无感；

这其实不是工具失效，而是因为请求种类和传输方式的多样化，你需要根据请求类型选择匹配的抓包工具和方式。

这篇文章就来整理一下，遇到不同类型的“抓不到包”，我们该怎么选对工具、用对方式。

类型一：浏览器或WebView内的普通HTTP/HTTPS请求

常见场景：

• H5页面加载慢，排查资源路径；
• 页面接口403，确认Header结构；
• Webview加载失败，查证服务端是否正常响应；

推荐工具：

• Charles / Fiddler：直接代理浏览器或Webview；
• mitmproxy：可拦截修改返回字段用于测试；
• Proxyman（macOS用户推荐）；

常见坑点：

• WebView必须配置允许代理证书信任；
• 多标签页请求过多时注意筛选目标域名；

类型二：APP中调用SDK（如支付/认证）接口抓不到

常见场景：

• 集成SDK后功能报错，想看请求结构；
• 第三方认证流程断在某一步；
• SDK回调失败但控制台无报错；

问题本质：

• SDK使用私有封装或低层Socket调用；
• 开启HTTPS Pinning，拒绝中间人代理证书；
• 请求不走系统代理；

推荐组合：

• Sniffmaster：直接从真机物理端口读取请求流量，不依赖证书；
• Wireshark：确认请求确实发出；
• Charles/mitmproxy：用于补充模拟器测试阶段；

类型三：移动端APP真机HTTPS请求抓不到

常见表现：

• 模拟器OK，真机不显示任何请求；
• 抓到连接但握手失败；
• App提示“网络错误”，抓包工具无日志；

技术根因：

• 移动系统限制证书信任（iOS 14+/Android 7+）；
• 使用自定义网络栈绕过代理机制；
• HTTPS双向认证或SSL Pinning导致连接失败；

推荐策略：

• 尝试 mitmproxy 查看握手状态；
• 若失败 → 改用 Sniffmaster（支持Pin爆破 + 真机直连）；
• 辅助Wireshark确认网络传输行为；

类型四：App主动建立Socket或自定义协议通信

场景举例：

• IM聊天模块通信抓不到；
• IoT设备数据上传监控失败；
• 游戏数据流加密传输不明；

抓包难点：

• 非HTTP协议；
• 抓包工具无法识别协议结构；
• 加密封包，需解密才可分析；

推荐工具组合：

• Wireshark：可分析传输层结构；
• Sniffmaster：支持查看原始TCP数据流 + 协议分类识别；
• 自定义解析脚本（Wireshark plugin 或 Sniffmaster内置格式转换）；

类型五：接口使用TLS双向认证或自定义Header签名机制

常见用途：

• 金融类接口；
• 登录认证服务；
• 企业API（内网/OAuth私有集成）；

症状：

• Charles/mitmproxy完全抓不到；
• 请求返回code 0 或 handshake failed；
• 抓包工具报“证书不被信任”；

解决方案：

• 不建议“破解”协议；
• 使用 Sniffmaster 物理抓包查看加密前后的包结构；
• 分析真实请求Header及签名字段构成；
• 如果要调试参数结构，构建Postman + sniffmaster对比环境辅助测试；

总结：别让抓包方式阻碍你理解请求

每个请求的类型决定了它是否“可被抓住”，你抓不到它，不代表它不存在，而是你用错了工具。