whistle 支持哪些协议？HTTP、HTTPS、WebSocket 怎么代理？
Whistle 常用于 HTTP 调试，但它能处理的并不只有普通 HTTP 请求。前端和移动端排查里，常见的是 HTTP、HTTPS、WebSocket、HTTP/2 以及 SOCKS 或上游代理。理解这些协议的差异，比背规则更重要：HTTP 明文好改，HTTPS 需要证书信任，WebSocket 建连后是长连接，HTTP/2 可能在代理链路里被降级。协议边界没弄清，规则看似正确，请求也可能不按预期走。
HTTP 最直接，可以替换 host、改请求头和响应体，适合本地联调和 Mock。
www.example.com host 127.0.0.1:8080 http://www.example.com/api/user resBody://{"code":0} http://www.example.com/api/user reqHeaders://{"x-debug":"1"}
HTTPS 多了一层证书。浏览器先和代理建立 CONNECT，再由 whistle 解密转发；没有信任根证书时，只能看到隧道，看不到路径和响应。调试前先启动服务并按页面提示安装证书：
w2 start -p 8899 # 浏览器访问 http://127.0.0.1:8899，下载并信任根证书
HTTPS 的坑主要有三个：移动端证书信任策略不同；部分 App 做了证书固定；生产登录、支付链路不该随便关闭校验。调试时可以只匹配目标域名，不要用过宽规则影响全部流量。
WebSocket 也是 whistle 很有价值的场景。它先通过 HTTP Upgrade 建立连接，之后变成双向消息流，因此排查时既要看握手，也要看消息内容。
ws://socket.example.com host 127.0.0.1:7001 wss://socket.example.com host 127.0.0.1:7001
HTTP/2 和 SOCKS 更像链路兼容问题。很多代理工具会把 HTTP/2 在中间链路降到 HTTP/1.1，这通常不影响接口语义，但会影响多路复用、头压缩和性能判断。SOCKS 适合把流量再转给公司代理、远程调试机或特定网络出口，改包能力仍然发生在 whistle 这一层。
api.example.com socks://127.0.0.1:1080 api.example.com proxy://http://127.0.0.1:8888
追问
HTTP 和 HTTPS 代理规则写法一样吗？
大部分匹配和改写规则看起来一样，但 HTTPS 能否生效取决于证书信任和解密权限。HTTP 请求是明文，whistle 可以直接看到路径、header 和 body；HTTPS 如果只建立了 CONNECT 隧道，就只能看到域名和连接信息。取舍是安全性和可调试性：本地排查可以信任证书，生产或敏感链路不要随意解密。遇到规则不生效，先确认是不是根本没拿到 HTTPS 明文。
WebSocket 代理为什么有时只能看到连接，看不到消息？
可能是规则只命中了握手域名，没有命中实际的 wss 地址，也可能是客户端走了不同端口或备用域名。WebSocket 建连成功后是长连接，页面刷新、重连和心跳都会影响观察结果。另一个常见坑是消息被业务层压缩或加密，代理能看到帧，但看不懂业务内容。排查时先验证 Upgrade 状态，再看消息方向和重连次数。
HTTP/2 被代理后降级会不会影响测试结论？
如果只是验证接口返回、Mock 数据和 header，通常影响不大。若你在排查性能、连接复用、服务端推送或 gRPC 类场景，降级就可能改变结论。whistle 更适合做功能调试和流量改写，不适合替代专门的协议性能分析工具。边界看测试目标：测业务语义可以接受，测协议特性就要谨慎。
SOCKS、proxy 和 host 规则怎么选？
host 适合把目标域名指到本地或测试机，最直观也最常用。proxy 适合把请求交给另一个 HTTP 代理，socks 适合走公司网络、远程环境或特定出口。不要把三者叠太多层，否则失败时很难判断是哪一层断了。建议先用 host 跑通，再按网络限制加上游代理。
多协议混合项目应该怎么写规则？
不要用一个大规则覆盖所有域名，应该按协议和业务域名拆开。HTTP API、HTTPS 登录、WebSocket 推送、静态资源最好分别写，必要时加注释说明用途。这样做的成本是规则文件稍长，但排查时能快速关闭某一段，不会影响其他流量。尤其是移动端项目，登录和长连接经常共享域名，规则过宽很容易制造假故障。