大多数工程师第一次遇到 Fiddler 抓不到包时，都会下意识地反复检查配置：代理有没有开？证书装没装？HTTPS 解密是不是忘了勾？
这些检查当然有必要，但如果问题持续存在，继续在同一个地方打转，往往只会浪费时间。
一个看似普通的失败场景
一次排查 iOS App 的网络问题，我在 Windows 上用 Fiddler 抓包，代理正常，HTTPS 解密开启，证书也已经安装并信任，但请求就是不出现。
奇怪的是，同样的接口，用 Mac 上的代理工具却能抓到部分请求，这时再纠结Fiddler 为什么不行，已经意义不大了。
先弄清楚：Fiddler 原本能抓到什么
Fiddler 的核心能力其实很明确：它是一个基于代理的抓包工具。
只要满足以下条件，它通常工作得很好：
- 请求经过系统代理
- HTTPS 证书链允许中间人解密
- 应用没有刻意绕过代理
在接口联调、Web 调试、部分 App 测试场景中，这套模型非常高效。
但问题在于，很多现代 App，尤其是 iOS App，并不完全符合这些前提。
如果开始经常抓不到包
如果出现以下情况，我通常会停止继续折腾 Fiddler 配置：
- 请求在真机上必现，但 Fiddler 完全无记录
- 只在部分接口上抓不到
- 模拟器可以，真机不行
- HTTPS 连接存在，但内容始终不可读
这些现象一般说明：问题不在 Fiddler，而在抓包路径本身。
HTTPS Pinning 是最常见的分界线
在 iOS App 中，HTTPS pin 校验是一个很常见的原因。
一旦 App 对证书做了校验，基于代理的抓包工具（包括 Fiddler）就会面临两个结果之一：
- 连接被直接拒绝
- 连接存在，但无法完成解密
在第二种情况下，你会看到一些“像是抓到了，但又什么都看不懂”的数据，这也常被误认为是 Fiddler 的问题。
这时候，通常会换一种抓包方式
当我确认问题不是配置失误，而是抓包模型不匹配时，通常会换一种抓包方式来验证假设。
比如使用 抓包大师（Sniff Master） 从设备侧直接抓取数据。
它不依赖系统代理，也不要求修改 App 或越狱，只需要连接设备，就能看到 iOS App 的真实通信情况。
在这个阶段，它解决的不是“功能多不多”，而是一个关键问题：Fiddler 抓不到的请求，究竟有没有真实发出？
只要这个问题有了答案，后续排查路径就会清晰很多。
指定 App 抓包，避免误判“没有请求”
有时 Fiddler 抓不到包，并不是请求不存在，而是被大量无关流量掩盖了。
在真机环境下，系统服务和其他 App 的请求非常多。
如果工具支持只抓取指定 App，判断会简单得多。
抓包大师在这一点上比较实用，可以把注意力完全放在目标 App 的通信上，而不是在全局请求里反复搜索。
Fiddler 看不到的，可能根本不是 HTTP
还有一种容易被忽略的情况：
你以为自己在找 HTTP 请求，但实际上问题发生在 TCP 数据流层。
比如：
- 登录完成后状态不同步
- 心跳异常导致连接被断
- 自定义协议通信失败
这些行为，在 Fiddler 里本来就不可见。
在某些排查中，我会直接抓 TCP / UDP 数据流，看连接是否建立、是否重复、是否中断。
抓包大师支持这一层的数据流抓取，并可以导出给 Wireshark 继续分析，这一步常常能解释“为什么接口看起来正常，但行为异常”。
Wireshark 并不是用来替代 Fiddler 的
在讨论“Fiddler 抓不到包怎么办”时，经常有人直接建议“用 Wireshark”。
但从工程角度看，Wireshark 更像是一个确认工具。
它能告诉你数据有没有在网络中出现，但并不适合用来理解业务层 HTTP 行为。
我更倾向于把它放在流程后段，而不是一开始就切换。
拦截与修改，用来验证判断
当我已经通过其他方式确认请求确实存在时，下一步往往是验证客户端逻辑。
通过拦截请求、修改响应，模拟异常返回，可以快速判断客户端对某些字段或状态的依赖程度。
这一步和 Fiddler 的 AutoResponder 很像，只是换了一种实现方式。
抓包大师支持用脚本修改请求和响应，在验证假设时非常直接。
对“Fiddler 抓不到包”的重新理解
经历过多次类似问题之后，我对这类情况的看法发生了变化：
- 抓不到包，并不等于没有请求
- 工具失败，往往是在提醒你换视角
- 不同抓包工具，本来就服务于不同层级
Fiddler 依然是一个非常好用的工具，只是它并不适合所有场景。
随时随地看视频
