Fiddler 使用：从 HTTP 抓包到接口调试

在开发 Web、API、移动端应用时，经常会遇到：

前端请求到底发送了什么？
Token 和 Cookie 有没有正确携带？
接口为什么返回 401、403 或 500？
浏览器能访问，程序却访问失败？
如何修改请求参数重新测试？
后端接口还没开发好，前端怎么继续联调？

这类问题可以使用 Fiddler 快速定位。

Fiddler 是一款 HTTP/HTTPS 调试代理工具，可以捕获客户端与服务器之间的网络请求，并查看、修改、重放请求和响应。

目前主要有 Fiddler Classic 和 Fiddler Everywhere。Classic 主要面向 Windows，并已经进入维护阶段；Everywhere 是当前的跨平台版本。

1. Fiddler 是什么？

正常情况下：

浏览器
   ↓
Web Server
   ↓
服务器

启用 Fiddler 后：

浏览器
   ↓
Fiddler
   ↓
Web Server

Fiddler 作为代理，可以看到：

Request
├── URL
├── Method
├── Headers
├── Cookie
└── Body

Response
├── Status Code
├── Headers
└── Body

例如：

POST /api/login HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer xxx

以及：

{
    "username": "admin",
    "password": "123456"
}

因此，Fiddler 最核心的价值就是：

把客户端和服务器之间的 HTTP 通信过程直接展示出来。

2. 安装与基本配置

如果只是学习和日常开发，目前更推荐使用 Fiddler Everywhere。

安装完成后启动 Fiddler，首先确认系统代理捕获已经开启。

然后打开浏览器访问一个网站，例如：

https://example.com

如果配置正常，Fiddler 中就会出现对应的 Session。

基本操作流程就是：

启动 Fiddler
    ↓
开启 Capture
    ↓
浏览器访问网站
    ↓
Fiddler 出现请求
    ↓
点击请求查看详情

如果请求很多，可以使用过滤功能，只保留需要关注的域名或 URL。

例如只关注：

api.example.com

或者：

/api/user

实际开发中建议养成习惯：

先过滤，再分析。

否则一个页面几十甚至几百个请求，很容易找到眼花。

3. HTTPS 抓包

现在绝大多数网站都是 HTTPS。

如果只抓 HTTP：

Client
   ↓
Fiddler
   ↓
Server

内容本身就是明文。

HTTPS 则是：

Client
   ↓
TLS 加密
   ↓
Server

Fiddler 如果需要查看 HTTPS 内容，需要安装并信任 Fiddler 的根证书。

通常在 Fiddler 中开启 HTTPS 捕获，然后安装对应证书。

配置完成后重新访问 HTTPS 网站，就可以看到：

Request Headers
Request Body
Response Headers
Response Body

这里需要特别注意：

Fiddler 不是破解 HTTPS。

它实际上是在客户端信任 Fiddler CA 的情况下，建立代理两端的 TLS 连接，从而能够查看经过代理的 HTTPS 内容。

因此不要在不可信设备上随意安装代理 CA，因为这样会让代理具备查看 HTTPS 流量的能力。

4. 如何分析一个请求？

抓到请求后，最重要的是学会看 Request 和 Response。

例如：

POST https://api.example.com/api/login

先看：

URL

确认：

Host
Path
Query

Method

确认：

GET
POST
PUT
PATCH
DELETE

Headers

重点关注：

Authorization
Content-Type
Cookie
Accept
User-Agent
Origin

例如：

Authorization: Bearer eyJ...
Content-Type: application/json

Body

例如：

{
    "username": "admin",
    "password": "123456"
}

Response

最后看：

Status Code
Response Headers
Response Body

例如：

200 OK

或者：

401 Unauthorized
403 Forbidden
500 Internal Server Error

这样一个接口问题基本就可以按照：

URL
 ↓
Method
 ↓
Headers
 ↓
Body
 ↓
Status
 ↓
Response

的顺序排查。

5. Composer：手动发送和重放 API

Fiddler 中非常实用的功能是 Composer。

它可以手动构造 HTTP 请求。

例如：

POST https://api.example.com/api/users

Headers：

Content-Type: application/json
Authorization: Bearer xxx

Body：

{
    "name": "Leanku",
    "age": 30
}

点击发送后，就可以直接看到服务器响应。

更实用的是：

把已经抓到的请求直接复制到 Composer，然后修改后重新发送。

例如原请求：

{
    "product_id": 1001,
    "quantity": 1
}

修改成：

{
    "product_id": 1001,
    "quantity": 999
}

然后重新发送。

这对于：

API 调试
参数测试
Bug 复现
边界测试
权限测试

非常方便。

很多时候，它比重新修改前端代码再点击页面测试效率高得多。

6. Breakpoint：修改请求后再发送

如果想修改一个已经产生的请求，可以使用 Breakpoint。

请求流程：

Client
   ↓
Fiddler
   ↓
暂停
   ↓
修改 Request
   ↓
Server

例如客户端发送：

{
    "quantity": 1
}

Fiddler 暂停请求后，可以修改为：

{
    "quantity": -1
}

然后继续发送。

这样可以测试服务器对于异常参数的处理。

常见测试包括：

quantity = 0
quantity = -1
quantity = 999999
id = null
id = abc
token = invalid

对于后端开发来说，这个功能非常适合验证：

参数校验
权限控制
异常处理
边界条件

7. AutoResponder：接口 Mock

如果后端接口还没有开发完成，但前端已经需要联调，可以使用 AutoResponder。

例如前端请求：

GET /api/config

正常情况：

Frontend
   ↓
Backend
   ↓
接口还不存在

使用 AutoResponder 后：

Frontend
   ↓
Fiddler
   ↓
Mock Response

例如返回：

{
    "code": 0,
    "message": "success",
    "data": {
        "version": "1.0.0",
        "maintenance": false
    }
}

这样前端不需要等待后端接口完成。

AutoResponder 还可以用于模拟：

以及模拟响应延迟。

因此可以用它测试：

正常流程
错误流程
接口超时
接口异常

例如模拟接口 5 秒才返回，就可以观察前端是否正确处理 Loading 和 Timeout。

8. 实际开发中的几个典型场景

场景一：前端说“接口有问题”

不要直接开始查后端代码。

先用 Fiddler 看实际请求：

URL
Method
Headers
Cookie
Body

然后看 Response。

例如发现：

{
    "code": 10001,
    "message": "name is required"
}

同时请求 Body 是：

{
    "name": ""
}

那么问题已经非常明确：

客户端参数错误

场景二：接口返回 401

检查：

Authorization: Bearer xxx

有没有发送。

如果没有：

客户端认证信息没有携带

如果存在：

Authorization: Bearer xxx

再进入服务端检查 Token。

场景三：Cookie / Session 丢失

登录响应：

Set-Cookie: session_id=abc123

后续请求应该出现：

Cookie: session_id=abc123

如果没有：

客户端没有正确保存或发送 Cookie

如果已经发送，但服务器仍然认为未登录：

继续检查服务器 Session

场景四：浏览器正常，程序失败

例如：

浏览器：200 OK
PHP：401 Unauthorized

可以分别抓取两个请求，然后比较：

URL
Method
Authorization
Cookie
Content-Type
Accept
Request Body

通常很快就能发现差异。

场景五：测试异常参数

抓取正常请求：

{
    "amount": 100
}

复制到 Composer，然后测试：

{
    "amount": -100
}

再测试：

{
    "amount": 999999999
}

观察服务器是否正确进行参数校验。

总结

对于开发者来说，Fiddler 不需要把所有功能都学完，掌握下面这条流程就已经非常实用：

抓包
 ↓
过滤
 ↓
查看 Request
 ↓
查看 Response
 ↓
Composer 重放
 ↓
修改参数
 ↓
Breakpoint
 ↓
AutoResponder Mock

最值得掌握的几个功能就是：

功能	用途
Capture	抓取 HTTP/HTTPS 请求
Inspectors	查看 Request / Response
Filters	快速找到目标请求
Composer	手动发送、重放 API
Breakpoint	暂停并修改请求
AutoResponder	Mock 接口、模拟异常

如果你是后端开发者，Fiddler 最重要的用途并不是“看网络请求”，而是：

当客户端、服务器、API、认证、Cookie 或网络行为出现问题时，直接看到真实的 HTTP 通信内容。

掌握 Fiddler 后，很多“到底是谁的问题”的接口 Bug，都可以从猜测变成证据驱动的排查。

官方文档/资料：

Fiddler 使用：从 HTTP 抓包到接口调试#

1. Fiddler 是什么？#

2. 安装与基本配置#

3. HTTPS 抓包#

4. 如何分析一个请求？#

URL#

Method#

Headers#

Body#

Response#

5. Composer：手动发送和重放 API#

6. Breakpoint：修改请求后再发送#

7. AutoResponder：接口 Mock#

8. 实际开发中的几个典型场景#

场景一：前端说“接口有问题”#

场景二：接口返回 401#

场景三：Cookie / Session 丢失#

场景四：浏览器正常，程序失败#

场景五：测试异常参数#

总结#