whistle 如何捕获请求并快速过滤定位问题？

whistle 捕获请求的核心流程是：启动本地代理，让浏览器、App 或命令行流量经过它，然后在 Network 面板查看请求、响应、耗时、头信息和匹配规则。它不像浏览器 DevTools 只看当前页面，而是能统一观察多端流量，尤其适合排查 H5、客户端内嵌页、Node 服务请求和第三方 SDK 调用。使用前要明确边界：whistle 只能看到走代理的流量，系统代理没配好、App 不信任证书、命令行绕过代理时，Network 面板自然不会出现请求。

先启动服务并打开管理页：

bash
npm i -g whistle
w2 start -p 8899
open http://127.0.0.1:8899/

浏览器可以直接配置 HTTP/HTTPS 代理为 127.0.0.1:8899，命令行请求可以这样验证：

bash
export HTTP_PROXY=http://127.0.0.1:8899
export HTTPS_PROXY=http://127.0.0.1:8899
curl -I https://example.com

如果要看 HTTPS 明文内容，需要安装并信任 whistle 根证书。证书只用于本机调试，别在公共设备或不可信网络里随便安装；调试结束后可以关闭代理，避免正常访问也继续经过 whistle。

Network 面板里最常用的是域名、路径、方法、状态码和关键字过滤。排查接口失败时，先用域名缩小范围，再用 status:500、method:POST、接口路径片段继续收窄。遇到请求太多的页面，直接清空列表后复现一次，比在几千条历史记录里搜索更可靠。

追问

为什么已经配置代理却抓不到请求？

先确认流量来源是否真的走了 127.0.0.1:8899，浏览器、系统、App 模拟器和命令行各有自己的代理设置。取舍上，浏览器调试最简单，移动端调试更接近真实场景但证书和网络环境更容易出问题。常见坑是 App 使用了证书锁定、系统代理被 VPN 覆盖，或者 Node 请求库显式禁用了代理。可以先用 curl 走代理验证 whistle 正常，再回到具体客户端排查。

Network 里请求太多，怎么快速定位目标接口？

不要一上来搜索很短的词，比如 api 或 user，这会把噪音也带进来。更稳的做法是按域名、路径片段、请求方法、状态码逐层过滤，最后再看请求体或响应体。边界是过滤条件越多，越可能把真正的异常请求排除掉，所以每次收窄都要确认列表数量是否合理。踩坑时可以先清屏，再触发一次具体操作，让目标请求出现在最新的几条里。

HTTPS 请求显示 CONNECT 或看不到响应体怎么办？

这通常是证书没有安装、没有被系统信任，或者客户端不接受用户证书。浏览器调试时安装 whistle 证书一般就够了，Android 7 之后的 App 可能还需要应用允许用户证书，部分金融或安全类 App 会做证书锁定。取舍是：普通业务调试可以信任本机证书，涉及敏感账号和生产数据时应尽量用测试环境。不要为了抓包去关闭应用安全校验并提交到正式包，这是非常典型的安全事故源头。

如何用 whistle 判断问题在前端还是后端？

先看请求是否发出、URL 和参数是否正确，再看后端返回的状态码、响应体和耗时。若请求没发出，多半是前端逻辑、跨域预检或网络配置问题；若请求正确但响应错误，就要看服务端日志或网关链路。一个实用取舍是临时用规则 mock 一个成功响应，如果页面恢复正常，说明前端渲染链路大概率没问题。反过来，如果 mock 成功响应页面仍异常，就要查前端数据解析或状态管理。

过滤和搜索有什么踩坑点？

过滤是为了缩小列表，搜索是为了在已有列表里找内容，两者不要混用。很多人只搜响应关键字，却忘了请求还没被捕获或已经被过滤条件排除，结果误以为接口没返回。另一个坑是缓存，请求可能直接走浏览器缓存，Network 里看不到你期待的接口变化。排查时可以禁用缓存、加随机参数，或者在 whistle 里观察状态码和响应头是否真的来自服务端。