抓包与网络请求分析实战教程

同一个“提交失败”，可能来自完全不同的位置

用户点击“提交订单”后页面没有成功跳转，原因可能是按钮没有发出请求、请求参数错误、登录失效、库存不足、服务端报错或网络超时。只记录页面提示，研发仍然需要重新排查；抓到关键请求，才能缩小问题范围。

四类工具看到的内容不同

快速选择

• 网页功能异常：先打开浏览器 Network。
• App 或桌面客户端接口：使用 Charles、Fiddler 或 mitmproxy。
• 连接建立、DNS、TCP、TLS 或丢包问题：使用 Wireshark。
• 请求已经进入服务端：使用 request_id 继续查日志和链路追踪。

下单请求的六个观察位置

一次可靠的浏览器抓包流程

1. 打开开发者工具并进入 Network。
2. 勾选 Preserve log，避免页面跳转后记录消失。
3. 点击清空，只保留本轮复现产生的请求。
4. 选择 Fetch/XHR，减少图片、字体和脚本干扰。
5. 在页面执行一次完整的提交订单操作。
6. 按路径、方法或业务关键字找到 /api/orders。
7. 依次检查 Headers、Payload、Response 和 Timing。

下单页面常见的筛选顺序

1. 先选 Fetch/XHR，只看接口请求。
2. 输入 orders、checkout 或业务接口路径关键字。
3. 按 Method 检查 POST，按 Status 检查失败或异常响应。
4. 通过 Initiator 确认是哪段前端代码发起。
5. 使用 request_id、order_id 或 case_id 串联后续请求。

根据抓包结果判断下一步

重放前必须确认

• 目标仍是测试环境，不是生产环境。
• 令牌属于专用测试账号，分享前已经替换。
• 订单创建、支付、短信等操作不会产生真实副作用。
• 幂等键和测试数据允许重复执行。
• 对比原请求与重放请求，避免浏览器自动补充的头部被遗漏。

移动端代理抓包步骤

1. 让手机和电脑进入可以互相访问的测试网络。
2. 在电脑启动 Charles、Fiddler 或 mitmproxy 并确认监听端口。
3. 在手机 Wi-Fi 中配置电脑 IP 和代理端口。
4. 仅在专用测试设备安装并信任代理证书。
5. 打开 App 复现下单，按域名和路径筛选请求。
6. 结束后关闭代理、移除证书并恢复网络设置。

抓包文件中的敏感内容

缺陷单建议保留

• 复现环境、账号类型和发生时间。
• 请求方法、脱敏后的 URL 与关键参数。
• 状态码、业务码、响应摘要和实际耗时。
• request_id、trace_id 或测试 case_id。
• 期望结果、实际结果和最小复现步骤。
• 必要时附脱敏 HAR，不要只贴一张看不清的截图。

练习：定位“提交订单后提示失败”

1. 清空 Network 并开启 Preserve log，复现一次失败。
2. 找到创建订单请求，记录方法、路径、耗时和 request_id。
3. 检查 quantity、coupon_id 和地址 ID 是否符合页面选择。
4. 判断是没有请求、HTTP 失败、业务失败还是响应超时。
5. 复制为 cURL，脱敏后在测试环境重放。
6. 根据响应和 Timing 选择前端、网关、服务端或数据层继续定位。
7. 编写一条标题为“当库存充足并提交订单时，系统返回成功订单”的正常用例。
8. 编写一条标题为“当登录令牌失效时，系统拒绝创建订单并提示重新登录”的异常用例。
9. 整理脱敏证据，确保其他人能够独立复现。