我第一次认真用抓包工具的拦截器功能，并不是想篡改接口，而是想确认一件事：

这个请求，客户端到底有没有按我理解的方式处理返回结果？

当日志和代码都无法完全解释行为时，拦截器反而成了最快的验证手段。

拦截器在整个抓包流程中的位置

在 iOS / Web 调试里，我一般会把工具分成几层：

  • 代理抓包：看请求是否发出、参数是否正确
  • 拦截器：在不改代码的情况下验证客户端逻辑
  • 日志和断点：最终定位问题

拦截器并不是每次都用，但一旦用上，往往能快速缩小问题范围。

进入抓包大师的拦截器入口

在使用拦截器之前，需要先处在代理抓包模式下。

在抓包大师的代理抓包界面右侧，有一个类似插头形状的图标。
双击这个图标，会打开拦截器日志界面。

这个界面主要用来做三件事：

  • 打开或关闭拦截器
  • 查看拦截过程中输出的日志
  • 进入拦截器代码编辑界面

拦截器日志

打开拦截器编辑界面

在拦截器日志界面中，点击“编辑拦截器”，就可以进入代码编辑界面。

拦截器里面有一段默认的代码，是演示拦截器的整体框架的例子，需要根据自己的需要进行修改。

有一个非常重要的约束：

  • 函数名不能改
  • 函数参数不能改
  • 只能修改函数内部逻辑

拦截器页面

拦截器的最小可运行结构

拦截器至少包含下面这个代码，这个是一个空的拦截器，什么都不拦截，什么都不做。

 1function handleRequest(request) {
 2    return request
 3}
 4
 5function handleResponse(response) {
 6    return response
 7}
 8
 9function filterUrl() {
10    return []
11}

如果缺少其中任何一个，拦截器都无法正常工作。

filterUrl 决定了“拦谁”

在实际使用中，我会优先从 filterUrl 下手。

这里返回的是一个 URL 列表，支持通配符。
只有命中这些地址的请求，才会进入 handleRequest 和 handleResponse。

例如，只拦截 Google 的请求：

1function filterUrl() {
2    return ["https://www.google.com/*"]
3}

如果这里没写对，后面的逻辑写得再复杂，也不会生效。

在 handleRequest 里验证“请求阶段”的判断

handleRequest 拿到的是即将发往服务器的请求。

我常用它来做几件事：

  • 打印请求是否真的发出
  • 临时修改请求参数，验证客户端分支
  • 重定向请求地址

例如，只打印请求 URL：

1function handleRequest(request) {
2    console.log("准备发送请求：" + request.URL);
3    return request
4}

如果日志出现了，但服务端行为没变，说明请求确实发出了。

request 对象里真正常用的字段

在实际调试中，我最常用的是这几个属性：

  • URL：可以直接修改来做重定向
  • Header：对象形式，适合加或删头
  • Body：请求体内容
  • IsBase64Body：判断是否是二进制数据

一个容易踩的坑是：
修改 Body 时，必须保证 IsBase64Body 的状态是匹配的。

handleResponse 更适合验证“客户端反应”

handleResponse 拿到的是服务器返回、即将交给客户端的数据。

这里特别适合做验证型修改，比如：

  • 改一个字段，看 UI 是否变化
  • 模拟异常返回
  • 强制返回某种状态码
1function handleResponse(response) {
2    console.log("收到响应：" + response.URL);
3    return response
4}

很多时候，不用真的改数据，只打印日志，就已经能确认执行路径。

response 比 request 多了一个关键字段

response 对象比 request 多了一个：

  • StatusCode：HTTP 状态码

这在验证错误处理逻辑时非常有用。

拦截器的开关

在拦截器日志界面里，有一个明显的拦截开关。

我习惯在以下时刻关闭拦截器：

  • 已经验证完假设
  • 需要抓“真实请求”
  • 不希望影响后续分析

否则很容易忘记拦截器还在生效，导致误判。

拦截器不是用来“长期修改”的

在我的使用经验里，拦截器更像一个临时实验工具。

它最适合的场景是：

  • 验证猜测
  • 复现异常
  • 辅助定位

一旦结论明确，就应该回到代码层解决问题。

多工具组合下，拦截器的真实价值

在完整流程中，我更倾向于这样用：

  • 代理抓包：确认请求结构
  • 拦截器：验证客户端行为
  • 数据流或日志：补充证据

参考教程：https://www.sniffmaster.net/tutorial/zh/6/6.html