抓包三件套怎么分工：Fiddler、Wireshark、mitmproxy 各管一段

一句话总结：三个工具管的是数据链路的不同层——Wireshark 看最底层的包、Fiddler 调试应用层请求、mitmproxy 用脚本改流量，选错工具就会出现「抓到了全是乱码」或者「看不到想看的东西」。

抓包这件事，新手最容易犯的错是拿 Wireshark 去看 HTTPS 请求内容。抓是抓到了，一屏幕 TCP 重传和 TLS 握手，一个明文都看不到，然后怀疑是不是软件坏了。

问题不在软件，在层的选择。这篇把三个工具的边界划清楚。

一张图看清分工

• Wireshark：工作在链路层到传输层，看到的是原始数据包。不解决 HTTPS 加密，优势是能看到 TCP 重传、握手时延、DNS 解析这些底层细节。
• Fiddler：工作在应用层，作为系统代理拦截 HTTP/HTTPS，靠自签证书解密。能看请求头、响应体、JSON，是 API 调试的主力。
• MITmproxy：同样工作在应用层，但支持用 Python 脚本实时修改请求和响应。适合批量改包、自动化测试、构造异常场景。

一句话记法：想看网络怎么走，用 Wireshark；想看接口要什么，用 Fiddler；想改流量做实验，用 mitmproxy。

图 1：W 覆盖全栈，F/M 只到应用层；右侧是选型口诀和解密前提

HTTPS 解密原理：三者里只有两个能解密

Wireshark 解不了 HTTPS，原因很实在：TLS 是端到端加密，中间人没有会话密钥。理论上给它配 SSLKEYLOGFILE 能解密浏览器流量，但配置麻烦、只对部分客户端有效，不在日常范围内。

Fiddler 和 mitmproxy 走的是同一套中间人机制：客户端连的是工具的证书，工具再跟服务器建立真正的 TLS 连接，两边解密后中继。所以第一步永远是把工具的根证书装进系统信任区。

这里有个平台差异必须知道：

• Windows 浏览器大多走系统证书，装完即生效
• 火狐、部分 Java 程序用自带证书库，要单独导
• Android 7 以后，用户安装的证书不再被应用信任（只信任系统证书），要么刷系统证书（需 root），要么只能抓那些明确允许用户证书的调试版 App
• iOS 装完证书还要在「关于本机 → 证书信任设置」里手动打开开关

「装完证书还是抓不到」，八成都是这几条里的某一条。

各自的实际用法

Wireshark 的典型场景：接口请求很慢，Fiddler 显示服务器 200ms 返回，但用户体感是 3 秒。这时候上 Wireshark，能看到 TCP 三次握手的 RTT、有没有丢包重传、TLS 握手花了多久。这类问题应用层工具看不出来。

Fiddler 的典型场景：调接口。它的 Composer 能重放请求、断点能改参数、AutoResponder 能本地替换响应——前端等后端接口时，用 AutoResponder 造假数据可以并行开发。这些功能 mitmproxy 也能做，但 Fiddler 的图形界面顺手得多。

mitmproxy 的典型场景：需要按规则批量处理流量。比如给所有请求自动加上鉴权头、把某个接口的响应全部改成 500 测异常处理、录制一整套流量做回放。写十几行 Python 就能做到，用图形工具反而绕。

常见坑清单

抓不到本地请求。很多工具默认只抓系统代理，localhost 和 127.0.0.1 不走代理。Fiddler 可以抓本机回环，Wireshark 要用 Npcap 的 loopback 适配器，mitmproxy 走直连。

手机连不上。手机和电脑必须在同一网段，代理填电脑的局域网 IP 而不是 127.0.0.1，防火墙放行对应端口。这三条里漏一条就连不上。

证书装了还是红的。检查证书是不是装到了「受信任的根证书颁发机构」，很多人装到了「个人」里。

只看 HTTPS 不看 QUIC。现在不少 App 走 HTTP/3（QUIC），UDP 443 端口，代理工具默认抓不到。排查时先看 Wireshark 里的协议分布，确认流量是不是压根没走 TCP。

一句边界

抓包只抓自己的流量。抓别人 App、抓公司内网、抓第三方服务，性质从「调试」变成「未授权访问」，法律风险完全不同。调试自己的应用、分析自己购买的设备流量，才是这类工具的正当用法。

Wireshark 开源免费，Fiddler 有免费版（Classic）和商业版，mitmproxy 完全开源。三个配合用，覆盖从网络层到应用层的全部调试需求。