Fiddler抓包实战：HTTP/HTTPS接口调试与证书配置

接口联调的时候，最让人头疼的往往不是写代码，而是“请求到底发了什么”。前端说参数传了，后端说没收到；测试环境正常，线上偶发失败；第三方回调明明触发了，本地却复现不出来。这类问题的共同点是：链路上有一环是黑盒。抓包工具的价值，就是把这个黑盒打开，让每一次请求和响应都变成可以逐字检查的文本。

本文围绕 Fiddler 这款 HTTP/HTTPS 调试工具展开，从工作原理、环境安装、证书配置，讲到过滤定位、请求重放、异常模拟和脚本扩展，最后给出一份可直接对照的排错清单。内容面向刚接触抓包的新手，也照顾已经会看请求但不太会用高级功能的后端和测试同学。读完之后，你应该能独立完成一次完整的接口抓包分析，并且知道哪些操作属于调试、哪些操作越过了合规边界。

需要提前说明一点：抓包工具只应该用于你自己拥有或已获得明确授权的系统。抓取他人账号数据、绕过鉴权、伪造请求攻击服务，都不属于本文讨论范围。下面所有示例都基于本地自己搭建的演示服务。

1. Fiddler 是什么：把不可见的 HTTP 会话变成可读文本

1.1 抓包工具到底在解决什么问题

浏览器按下 F12 能看到 Network 面板，为什么还需要 Fiddler？原因在于浏览器开发者工具只能看到“这个浏览器标签页发出的请求”。一旦请求来自桌面客户端、移动 App、小程序、命令行脚本、后端服务之间的调用，浏览器就完全无能为力了。

抓包工具站在操作系统网络层和应用层之间，把流经本机的 HTTP 流量截获下来，按会话（Session）为单位展示。一个会话就是一次完整的请求加一次对应的响应。你能看到请求行、请求头、Cookie、请求体，也能看到状态码、响应头、响应体和耗时。这正是排查“参数对不对”“返回是什么”“慢在哪一步”所需要的最小信息集合。

它的典型使用场景包括：接口联调时核对参数结构、定位线上问题的真实请求、分析第三方回调的报文格式、验证签名和加密逻辑是否正确、模拟服务端异常来测试前端兜底逻辑、统计某个页面的接口数量和总耗时。

1.2 工作原理：本地代理与中间人解密

Fiddler 本质上是一个运行在本机的 HTTP 代理服务器。启动后它会在本地监听一个端口（默认 8888），然后把系统或应用的流量引导到这个端口上。请求先到 Fiddler，Fiddler 记录一份，再转发给真实服务器；响应回来时同样先经过 Fiddler，记录之后再交还给客户端。

对于明文 HTTP，这个过程没有任何障碍。但对于 HTTPS，客户端和服务器之间本来是加密通道，Fiddler 站在中间是看不懂内容的。所以 Fiddler 采用了一种被称为“中间人解密”的做法：它自己扮演服务器，向客户端出示一张由 Fiddler 根证书签发的证书；同时它又扮演客户端，去和真实服务器建立真正的 TLS 连接。这样客户端以为在和服务器说话，服务器以为在和客户端说话，而 Fiddler 在中间完成了两次解密和再加密。

这套机制能够成立的前提是：客户端必须信任 Fiddler 的根证书。浏览器和操作系统会校验证书链，如果根证书不在受信任列表里，就会直接报证书错误并中断连接。这也是新手最容易卡住的一步，第 4 节会专门拆解。

需要理解的是，这种解密只在你自己控制的设备上、对你自己有权调试的流量才有意义。在生产环境或者他人设备上做同样的操作，性质就完全不同了。

1.3 Fiddler Classic 与 Fiddler Everywhere 的区别

目前市面上有两个同名产品，很多人一开始会混淆：

本文的示例以 Fiddler Classic 为主，因为它免费、资料多、脚本扩展灵活，也最适合用来理解抓包的底层机制。如果你用的是 Everywhere，大部分概念是通用的，只是菜单名称和位置会有差异，需要按实际界面调整。

1.4 和其他调试工具的边界

浏览器 DevTools 的 Network 面板足够日常前端调试使用，缺点是作用域局限在浏览器内，且不方便做请求改写和响应模拟。Wireshark 抓的是网卡层面的原始数据包，能力更强但门槛高得多，分析 HTTP 需要手动重组 TCP 流，不适合快速定位接口问题。Postman 侧重请求构造和接口测试，不具备被动监听能力。

Fiddler 的定位介于两者之间：它能被动监听全系统的 HTTP 流量，又能主动构造请求、修改响应、打断点。这个组合让它在接口调试场景里性价比很高。

2. 环境准备与安装配置

2.1 运行环境与前置依赖

Fiddler Classic 是 Windows 平台上的 .NET 应用，安装包会自动检测并引导安装所需的 .NET Framework 运行时。如果你的机器是较新的 Windows 版本，通常已经自带；如果是较旧系统，安装过程中可能会提示下载运行时，按提示操作即可。

版本方面，官方会持续发布更新，本文不锁定具体版本号。建议从官方渠道获取安装包，避免使用来源不明的第三方打包版本——抓包工具本身会接触明文流量，来源可信是底线要求。

如果开发机是 macOS 或 Linux，可以直接选择 Fiddler Everywhere，或者改用同类的跨平台调试代理工具。本文的操作步骤以 Windows 版 Classic 为例，重点在于讲清配置思路，具体菜单名称请以你实际安装的版本为准。

2.2 安装与首次启动

安装过程基本是下一步到底。首次启动后，你会看到一个信息密度很高的多面板界面，左边是会话列表，右边是各种详情和工具标签。此时默认状态下 Fiddler 已经在监听本机流量了，左下角状态栏会显示 “Capturing” 字样。

先做一件小事验证它是否真的在工作：随便打开一个网页，回到 Fiddler，看左侧会话列表是否出现了对应的请求记录。如果列表有数据滚动，说明基础代理链路是通的。如果一条都没有，先检查左下角是否是 Capturing 状态，再检查系统代理设置是否被其他软件抢占。

首次启动时，Fiddler 还会弹出一个证书安装提示。这个提示先可以关掉，我们在第 4 节统一处理，因为证书配置涉及信任链的确认，值得单独讲清楚。

2.3 基础配置：端口、远程连接与 HTTPS

打开 Tools > Options，有三个地方需要重点关注。

第一个是 Connections 标签页。这里可以设置 Fiddler 监听的端口，默认 8888。如果这个端口已经被别的程序占用，需要改成其他值，比如 8889。同一页面还有一个 “Allow remote computers to connect” 选项，勾选后其他设备才能连到这台机器的 Fiddler，移动端调试时会用到，日常桌面调试建议保持关闭。

第二个是 HTTPS 标签页。默认情况下 Fiddler 只解密部分 HTTPS 流量，需要手动勾选 Capture HTTPS CONNECTs 和 Decrypt HTTPS traffic。这两个选项开启之后，Fiddler 才会对 HTTPS 请求做中间人解密，你才能在详情面板里看到明文。

第三个是 Gateway 标签页。绝大多数调试场景不需要改动这里，保持默认的系统代理转发即可。如果你所在环境有统一的出口网关配置，需要按实际网络环境填写，本文不展开。

配置完成后记得点 OK，部分选项需要重启 Fiddler 才会生效。

2.4 目录结构与配置文件位置

Fiddler 的脚本、证书、会话存档都放在用户目录下。在 Fiddler 里点击 Help > About 或者查看 %USERPROFILE%\Documents\Fiddler2 目录，可以看到主要文件：

text复制%USERPROFILE%\Documents\Fiddler2\
├── Scripts\
│   ├── CustomRules.js        # 你自定义的 FiddlerScript 规则
│   └── SampleRules.js        # 官方示例，修改前建议先备份对照
├── Captures\                 # 会话存档默认目录
│   └── *.saz                 # 保存的会话包，可回放
└── Certificates\             # 根证书相关文件

改动 CustomRules.js 是 Fiddler 高级用法的核心入口，后文第 7 节会给出具体示例。修改前务必先把 SampleRules.js 备份一份，一旦脚本写错导致 Fiddler 行为异常，可以用它快速还原。

3. 界面结构与核心概念拆解

3.1 主界面分区

Fiddler 的界面可以粗分为四块：顶部是工具栏，左侧是会话列表（Web Sessions），右侧是多标签详情区（Inspectors、AutoResponder、Composer、Filters 等），底部是命令行输入框（QuickExec）和状态栏。

工具栏上最常用的几个按钮是：Capturing 控制是否监听、Remove all 清空当前会话、Decode 开关是否自动解码压缩响应、Keep all sessions 控制会话保留条数。会话列表上方还有一个输入框，用来做搜索和高亮。

很多人一开始会被右侧那一排标签吓到，其实日常高频使用的只有四个：Inspectors 看请求响应详情、AutoResponder 做响应模拟、Composer 构造请求、Filters 做过滤。其余标签可以等需要时再了解。

3.2 会话列表字段的含义

会话列表的每一行代表一次请求，主要列含义如下：

Process 这一列特别有价值。当你的机器上同时跑着浏览器、桌面客户端、后端服务时，它能直接告诉你这条请求是谁发出的，避免在一堆流量里瞎猜。

3.3 Inspectors 面板：请求与响应的完整视图

Inspectors 分上下两部分，上半部分是请求，下半部分是响应。每一部分都有多个子标签，分别用不同视角展示同一条报文。

请求侧的 Headers 展示请求行和请求头，WebForms 把表单参数解析成键值对，Raw 展示原始报文文本，JSON / XML 会对结构化请求体做格式化。

响应侧的 Headers 展示状态行和响应头，TextView 展示纯文本响应体，JSON / XML 做结构化展示，ImageView 可以直接预览图片响应。

排错时的推荐顺序是：先看 Headers 确认状态码和关键头（Content-Type、Content-Length、Set-Cookie），再看响应体的格式化视图确认业务数据，最后如果还是对不上，切到 Raw 看原始报文，检查有没有隐藏字符、编码问题或者被截断的内容。

3.4 常用快捷键与操作习惯

几个能显著提升效率的操作：

• Ctrl + X 清空所有会话，开始一次干净的抓取。
• Ctrl + F 打开搜索框，可以按关键字过滤会话列表。
• 双击某条会话的 Result 列，可以直接给这条会话加断点。
• 右键会话选择 Save > Selected Sessions > in ArchiveZIP，可以把选中的会话存成 .saz 文件，方便发给同事复现。
• 按住 Ctrl 点击多条会话，可以批量操作。

养成“先清空再抓取”的习惯很重要。会话列表积累了几千条之后再找目标接口，效率会直线下降，而 Filters 和 QuickExec 正是为此准备的，第 5 节会详细讲。

4. HTTPS 解密原理与证书配置

4.1 为什么默认看不到 HTTPS 明文

HTTPS 在传输层之上加了一层 TLS，客户端和服务器协商出会话密钥之后，中间经过的任何节点只能看到密文。Fiddler 如果不做特殊处理，抓到的 HTTPS 会话在 Inspectors 里只会显示 Tunnel to xxx:443，看不到任何请求头和响应体。

这正是很多人第一次用 Fiddler 时的困惑：“为什么我抓到的全是 Tunnel to？”答案就是解密开关没开，或者证书没被信任。

4.2 Fiddler 签发证书的完整流程

开启 HTTPS 解密后，Fiddler 会做这几件事：

第一，生成一张自签名的根证书，安装在系统的受信任根证书存储区。这张证书是 Fiddler 所有签发行为的基础。

第二，当客户端发起 HTTPS 请求时，Fiddler 拦截 TLS 握手，用根证书现场签发一张针对目标域名的证书，出示给客户端。

第三，客户端校验这张证书，发现签发者是受信任的 Fiddler 根证书，校验通过，握手继续。此时客户端和 Fiddler 之间形成了第一条加密通道。

第四，Fiddler 作为客户端，去和真实服务器完成一次正常的 TLS 握手，形成第二条加密通道。两条通道在 Fiddler 内部完成明文的转换。

理解了这四步，就能明白为什么证书信任是绕不过去的一环。根证书不被信任，第二步之后的整条链路都会断掉。

4.3 Windows 下的证书安装步骤

在 Tools > Options > HTTPS 页面，点击 Actions 按钮，可以看到几个选项。选择 Trust Root Certificate，系统会弹出安全警告，确认即可。如果这一步成功，你会看到 Fiddler 提示证书已经安装到受信任根证书存储区。

如果自动安装失败，可以走手动路径：在同一页面点击 Export Root Certificate to Desktop，把证书导出到桌面，然后在 Windows 的证书管理器里手动导入到“受信任的根证书颁发机构”存储区。导入时务必确认存储位置是“当前用户”还是“本地计算机”，两者影响范围不同。

安装完成后，建议关掉 Fiddler 再重新打开，让证书生效。然后随便抓一个 HTTPS 请求，看看 Inspectors 里是不是能看到明文了。

4.4 客户端侧的额外信任配置

操作系统信任了根证书，不代表所有客户端都会跟着信任。有些运行时环境有自己的证书存储，需要单独处理。

Java 应用使用自己的 cacerts 信任库，需要把 Fiddler 根证书导入进去才会信任。Node.js 在新版本中对证书校验比较严格，可能需要在启动参数里显式指定额外的 CA 证书。Python 的 requests 库默认使用 certifi 提供的证书包，同样需要单独配置。

处理这类问题的通用思路是：找到该运行时使用的证书信任库位置，把导出的 Fiddler 根证书以正确格式导入。具体命令和路径因版本而异，建议查阅对应运行时的官方文档，不要照搬网上的旧教程。

4.5 常见证书报错与处理方向

最典型的报错是浏览器提示 NET::ERR_CERT_AUTHORITY_INVALID，含义是证书签发者不被信任。处理方向就是回到 4.3 节，确认根证书确实安装在了受信任根证书存储区。

另一种是某些客户端提示 SSL handshake failed，通常是客户端做了证书固定（Certificate Pinning），也就是硬编码了只信任特定证书或公钥。这种情况下 Fiddler 的中间人证书会被拒绝，需要客户端侧配合放开调试开关，这是开发团队自己的配置项，不属于抓包工具的调整范围。

还有一种情况是证书安装了但依然报错，检查一下系统时间是否准确。证书有有效期，系统时间偏差过大也会导致校验失败，这个坑不常见但确实存在。

合规提醒：证书安装和 HTTPS 解密只应在你自己的开发设备上进行。在他人设备上安装根证书属于高风险操作，会使用户的所有 HTTPS 流量对该证书持有者可见，必须获得明确授权。

5. 过滤与定位：在几百条请求里找到目标接口

5.1 Filters 面板的配置思路

Filters 标签页的核心是勾选 Use Filters，之后所有过滤规则才会生效。配置完成后必须点击 Actions > Run Filterset now 才会立即应用，否则要等到下一条请求进来才生效。

常用的过滤维度分三组：

第一组是 Hosts，可以按主机名做包含或排除。比如只保留 api.example.com 的请求，或者排除掉大量静态资源域名。这一组是降噪效果最明显的。

第二组是 Client Process，可以只显示指定进程发出的请求。当机器上同时跑着好几个客户端时，这一组能直接把范围缩到最小。

第三组是 Request Headers 和 Response Status Code，可以按头部字段或状态码过滤。排查线上问题时，只保留 4xx 和 5xx 状态码是一个非常高效的起点。

5.2 会话列表的搜索与高亮

会话列表上方的输入框支持实时搜索，输入关键字会过滤列表。如果只想高亮不想过滤，可以使用 QuickExec 里的 ?keyword 命令，命中的行会加粗显示，列表结构保持不变。

区别在于：输入框搜索会隐藏不匹配的行，? 命令只是标记。排查“这条请求前后还发生了什么”的时候，用高亮更合适，因为上下文信息不会丢失。

5.3 QuickExec 常用命令速查

底部命令行输入框支持一批快捷命令，熟练之后效率提升很明显：

断点类命令是排查的利器。bpu 让请求停在发出之前，可以现场修改参数；bpafter 让响应停在返回之后，可以检查服务端究竟返回了什么。用完之后记得用 bpu 不带参数的空命令取消，否则后续同类请求会一直卡住。

5.4 会话的保存与共享

排查线上问题时，经常需要把请求证据发给同事。右键会话选择保存为 .saz 归档文件，对方在自己的 Fiddler 里用 File > Load Archive 打开，就能看到完全一致的请求和响应，包括所有头部和正文。这比截图或者复制粘贴文本可靠得多，也更利于复现问题。

归档文件里可能包含 Cookie 和 Token 等敏感信息，对外发送前建议先清理相关头部字段。

6. 完整实战：抓取并分析一个登录接口

6.1 场景说明与准备

为了让示例可复现，这里假设本地已经运行了一个简单的演示服务，提供 POST /api/login 接口，接收用户名和密码，返回一个 token。你可以用自己的本地服务替代，重点是流程和观察方法。

准备工作有三项：确认 Fiddler 处于 Capturing 状态；确认 HTTPS 解密已开启（如果服务走 HTTPS）；点击 Ctrl + X 清空会话列表，让抓取环境干净。

6.2 捕获登录请求

在客户端发起登录操作，然后回到 Fiddler，用 @localhost 或者接口路径关键字快速定位到这条会话。选中之后，右侧 Inspectors 面板上半部分就是请求内容。

先看 Headers 子标签，一条典型的请求长这样：

http复制POST /api/login HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0
Content-Type: application/json
Content-Length: 58
Accept: application/json

{"username":"demo_user","password":"demo_pass_123"}

这里需要重点核对三处。第一是请求行的方法和路径，确认没有写错接口。第二是 Content-Type，服务端通常按这个头决定用什么解析器处理请求体，如果客户端发的是 application/json 而服务端按表单解析，就会出现“参数收到了但是全空”的情况。第三是 Content-Length 与实际请求体长度是否一致，不一致通常意味着中间有编码或截断问题。

6.3 分析响应内容

响应侧先看 Headers：

http复制HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Set-Cookie: session_id=abc123; Path=/; HttpOnly
Cache-Control: no-store
Content-Length: 86

{"code":0,"message":"success","data":{"token":"eyJhbGciOi...","expiresIn":7200}}

状态码 200 说明 HTTP 层面成功，但业务是否成功要看响应体里的 code 字段。这种“HTTP 200 但业务失败”的设计在实际项目中非常普遍，只看状态码很容易误判。

Set-Cookie 里的 HttpOnly 标记说明这个 Cookie 不允许脚本读取，排查登录态问题时要意识到这一点，不能指望在浏览器控制台通过 document.cookie 拿到它。

6.4 用 Composer 重放与改造请求

Composer 标签页可以把一条已有请求拖进去，或者手动粘贴原始报文，然后修改参数重新发送。这个能力在排查“是不是某个参数导致的失败”时非常高效。

操作方式是把会话列表里的请求直接拖到 Composer 面板，报文会自动填充。修改请求体里的字段后点击 Execute，新请求会出现在会话列表里，和原请求并排对比。

需要提醒的是：重放会真实地打到服务端，对生产环境的接口做重放是有副作用的。涉及写操作的接口，必须先在测试环境验证。带有幂等设计的查询接口相对安全，但也要确认没有触发限流或风控。

6.5 用 AutoResponder 模拟异常响应

前端需要验证“服务端返回异常时页面怎么兜底”，但让后端同学专门造一个 500 响应成本很高。AutoResponder 可以在本地直接拦截并返回自定义内容，前端自己就能完成验证。

配置步骤是：勾选 Enable rules 和 Unmatched requests passthrough，点击 Add Rule，在规则行里填写匹配表达式和本地文件路径。匹配表达式支持几种前缀：

text复制EXACT:http://localhost:8080/api/login     // 精确匹配完整 URL
regex:.*\/api\/login.*                     // 正则匹配
METHOD:POST                                // 按方法匹配

第二列填本地响应文件的路径，或者填写 *200 这类内置动作表示直接返回指定状态码。准备一个内容如下的本地文件：

json复制{
  "code": 5001,
  "message": "服务暂时不可用",
  "data": null
}

保存后刷新页面，前端收到的就是这个模拟响应。验证完记得取消勾选规则，否则会影响后续所有调试。

6.6 用断点实时修改请求

有些参数是在请求发出瞬间才确定的，比如时间戳、签名。这时候需要在请求发出前打断点，现场改。

在 QuickExec 里输入：

bash复制bpu /api/login

下一次匹配的请求会被挂起，会话列表里该行的图标会变成红色箭头。此时在 Inspectors 的请求体里直接编辑内容，改完点击工具栏的 Break on Response 或者直接 Run to Completion，请求就会带着修改后的内容发出。

这个能力在验证“服务端是否对某个参数做了校验”时特别直接：把参数改成非法值，看服务端返回什么，比自己写测试用例快得多。同样提醒，只对测试环境使用。

7. FiddlerScript：把重复操作写成规则

7.1 脚本结构与执行时机

点击 Rules > Customize Rules，会打开 CustomRules.js。这个文件基于 JScript.NET 语法，Fiddler 在每次请求和响应经过时都会调用其中的钩子函数。最常用的两个是 OnBeforeRequest 和 OnBeforeResponse，分别在请求发出前和响应返回后触发。

脚本改完按 Ctrl + S 保存，Fiddler 会自动重新加载，不需要重启。如果脚本有语法错误，Fiddler 会弹出提示并停用自定义规则，此时界面上的 Rules > Customize Rules 会变成灰色，说明规则未生效。

7.2 一个给特定接口打标记的示例

假设你想把所有返回 5xx 且耗时超过 1 秒的请求标红，方便快速扫视。可以在 OnBeforeResponse 里加这样一段：

javascript复制// 文件路径：%USERPROFILE%\Documents\Fiddler2\Scripts\CustomRules.js
static function OnBeforeResponse(oSession: Session) {
    // 只处理目标接口，避免干扰其他流量
    if (oSession.uriContains("/api/")) {
        // 标记慢请求
        if (oSession.responseCode >= 500) {
            oSession["ui-color"] = "red";
            oSession["ui-bold"] = "true";
        }
        // 给响应耗时较长的会话加备注
        if (oSession.Timers != null) {
            oSession["ui-customcolumn"] = "slow";
        }
    }
}

这段代码里，uriContains 用来做路径匹配，responseCode 是响应状态码，ui-color 和 ui-bold 是 Fiddler 提供的特殊会话标记，设置后会直接反映在会话列表的视觉样式上。改完之后刷新页面，匹配的会话会立刻变红加粗。

7.3 自动提取并记录关键字段

另一个高频需求是把所有请求里的某个业务字段（比如链路追踪 ID）自动收集起来，方便串联分布式调用。可以在 OnBeforeRequest 里做：

javascript复制// 文件路径：%USERPROFILE%\Documents\Fiddler2\Scripts\CustomRules.js
static function OnBeforeRequest(oSession: Session) {
    // 从请求头里读取链路追踪 ID
    var traceId = oSession.oRequest["X-Trace-Id"];
    if (traceId != null && traceId.Length > 0) {
        // 写到 Fiddler 的日志面板，便于集中查看
        FiddlerObject.log("[TRACE] " + oSession.fullUrl + " -> " + traceId);
        // 同时作为自定义列展示在会话列表中
        oSession["ui-customcolumn"] = traceId;
    }
}

oRequest 是请求头集合，按头名称取值；fullUrl 是完整请求地址；FiddlerObject.log 会把内容输出到 Fiddler 的日志标签页。ui-customcolumn 则会在会话列表里多出一列，适合做人工核对。

7.4 脚本调试与还原

脚本出问题时，最直接的排查方式是看 Fiddler 底部的日志区，语法错误和运行时异常都会在那里输出。如果错误导致 Fiddler 行为异常，直接把 CustomRules.js 替换成备份的 SampleRules.js，然后保存即可恢复默认状态。

这也是为什么第 2.4 节强调要先备份。脚本能力很强，但改坏之后影响的是所有流量，先备份是最低成本的风险控制。

8. 移动端调试的合规操作要点

8.1 局域网代理与证书配置

当需要调试自己开发的移动端应用时，可以让手机和电脑连在同一个局域网内，在手机的 Wi-Fi 设置里把 HTTP 代理指向电脑的局域网 IP 和 Fiddler 端口。同时在 Fiddler 的 Connections 页面勾选允许远程连接，并确认系统防火墙放行了对应端口。

配置完成后，用手机浏览器访问 http://电脑IP:8888，页面会提供根证书下载入口。下载后需要在手机的证书管理里手动安装并信任，不同系统的入口位置差异较大，需要按设备实际菜单操作。

iOS 较新版本对证书信任做了额外要求，只下载安装还不够，还需要在证书信任设置里手动为根证书开启完全信任开关。这一步经常被遗漏，导致证书装了但依然抓不到明文。

8.2 必须遵守的边界

移动端调试涉及设备层面的证书信任变更，一旦完成，该设备上所有 HTTPS 流量对证书持有者都是可见的。因此必须满足三个前提：设备是你自己的或者已明确授权使用的；调试的是你自己开发的、需要调试的应用；调试结束后及时移除代理配置和根证书。

对企业内部设备做类似操作，通常需要走安全审批流程。未经授权在他人设备上安装根证书并解密流量，属于严重的合规问题，不在技术讨论的范围内。

调试完成后，记得把手机的 Wi-Fi 代理关闭，否则离开局域网后手机会因为找不到代理而无法上网，这是一个很常见的“配置完忘了还原”的后遗症。

9. 常见问题与排查清单

9.1 问题对照表

9.2 一套可复用的排查顺序

遇到“抓不到”这类问题，建议按下面顺序排查，能覆盖绝大多数情况：

第一步，确认 Fiddler 本身在监听。看左下角状态，看 Connections 端口，用浏览器访问一个已知 HTTP 站点做最小验证。

第二步，确认流量确实经过了 Fiddler。如果浏览器能抓到而目标应用抓不到，说明应用没有走系统代理，问题出在客户端侧的网络配置。

第三步，确认解密链路。如果能看到请求但看不到明文，问题出在证书信任，回到第 4 节逐条检查。

第四步，确认过滤规则。如果确认抓到了但列表里看不到，检查 Filters 是否在过滤，QuickExec 是否残留了高亮或断点命令。

第五步，确认是不是客户端做了额外限制。证书固定、双向认证、私有协议这几种情况，抓包工具本身无法绕过，需要开发方配合。

把这几步固化成习惯，比每次遇到问题到处搜索要快得多。

10. 工程实践建议与进阶方向

10.1 调试操作的几条硬规矩

抓包工具直连真实数据，用得不当会造成实际损失。以下几条建议值得写进团队规范。

第一，生产环境的写接口不做重放。Composer 重放一个下单、支付的请求，可能产生真实的业务数据。验证逻辑请一律在测试环境完成。

第二，归档文件脱敏后再外发。.saz 文件里包含完整的 Cookie、Token、手机号等字段。发给同事前，用文本编辑器打开清理敏感头，或者只截取必要的请求片段。

第三，调试结束及时还原环境。关闭系统代理、移除手机代理配置、卸载临时安装的根证书、取消 AutoResponder 规则和断点。这三件事没做，后续排查会陷入“明明代码没问题但就是不对”的困境。

第四，脚本改动先备份。CustomRules.js 的影响面是所有流量，改之前备份 SampleRules.js 是最省事的保险。

10.2 让抓包结果更有价值的几个习惯

会话列表默认不显示耗时分解，但 Statistics 标签页可以给出 DNS 解析、TCP 连接、TLS 握手、等待响应、内容下载各阶段的耗时。排查“接口慢”时，先看这个分解，能快速判断慢在网络层还是服务端处理，避免一上来就怀疑业务代码。

给关键会话加备注是个好习惯。右键会话选 Comment，写上“登录成功”“重试第二次”，导出归档后别人一看就懂，省去大量沟通成本。

如果团队里多人协作排查同一个问题，可以把 .saz 文件放到共享位置，约定好命名规则，比如“日期-环境-问题简述.saz”。这比在群里截图对线高效太多。

10.3 继续深入的方向

掌握基础抓包之后，可以往三个方向继续。

一是脚本能力。FiddlerScript 能做的不只是打标记，还可以做请求改写、响应注入、自动鉴权、批量断言。把这部分用熟，很多重复的联调工作可以自动化。

二是性能分析。结合 Timeline 标签页看请求的并发关系和瀑布图，能发现串行请求、资源阻塞这类前端性能问题，这是单纯看接口返回值发现不了的。

三是和自动化测试结合。把典型请求保存成 .saz，在回归测试时作为基线对比，响应结构发生变化时能第一时间发现。这个做法在有稳定接口契约的项目里收益很明显。

最后补充一点容易被忽略的：抓包看到的是“实际发生了什么”，而不是“应该发生什么”。它擅长定位问题，不擅长证明正确性。真正的质量保障还是要靠单元测试、接口测试和契约校验。把抓包当作排查工具而不是验证手段，这个定位会更准确。

如果你在配置证书或者过滤规则时卡住了，建议先把 Fiddler 完全退出再重新打开，很多“配置不生效”的问题其实是进程没重启导致的。这类小经验积累多了，排查速度自然会提上来。