企业官网建设流程全解析

ProxyPin 请求重写完整指南：5 种规则类型与端到端配置方法

【免费下载链接】network_proxy_flutterOpen source free capture HTTP(S) traffic software ProxyPin, supporting full platform systems项目地址: https://gitcode.com/GitHub_Trending/ne/network_proxy_flutter

ProxyPin 是一款开源免费的抓包工具，基于 Flutter 开发，覆盖 iOS、Android、macOS、Windows、Linux 各端。它的"请求重写"功能，可以在不改动后端代码的前提下，对抓到的 HTTP(S) 流量做拦截和修改——模拟接口返回、批量调整请求头、把线上域名切到本地服务，是前后端联调时最常用的调试手段之一。

从一个真实的联调痛点说起

后端还没排期，产品页面却要先看"下单失败"长什么样；后端返回的列表有 50 条数据，前端只想要一条空数据验证边界展示；测试环境的接口地址要临时切到本地 mock 服务。这些场景的共同点是：问题不在抓不到包，而在拿到包之后，没法按前端需要的样子去改它。

请求重写就是为这一步设计的：你在设置里配置好一组"规则 + 重写项"，之后所有命中的请求或响应都会被自动改写。下面按"拦截层 → 规则层 → 配置写法 → 验证与协作"的顺序，把这条链路一次讲完。

请求重写在抓包流程中的位置：先拦截，再改写

打开抓包页面后，每条 HTTP 请求会经过一个拦截器处理。请求发出前，先拿完整 URL 去匹配"请求侧"规则（替换请求、修改请求）；响应返回前，再匹配"响应侧"规则（替换响应、修改响应）。命中后按该规则挂载的重写项逐条执行，改完的报文才交给客户端或发往服务器。

这套逻辑集中在 lib/network/components/request_rewrite.dart，规则与重写项的数据结构定义在 lib/network/components/manager/rewrite_rule.dart。

有两点直接影响你的使用习惯：

• 匹配只看 URL，不看域名和路径的拆分。规则里的 URL 支持*（匹配任意多个字符）和?（匹配单个字符）通配符，内部统一转换成正则来匹配。
• 规则按顺序、首条命中生效。列表里靠前的规则一旦命中就不会再往下找，所以全局规则要放在具体规则后面（后文排坑部分会再讲一次）。

规则层：5 种规则类型与各自的重写项

新建规则时（桌面端入口在 lib/ui/desktop/setting/request_rewrite.dart，移动端在 lib/ui/mobile/setting/request_rewrite.dart），你需要填三样东西：URL 匹配条件、可选的 HTTP 方法、规则类型。规则一共五种，前两种是"整体替换"，中间两种是"精准修改"，最后一种是"改道"。

几个细节值得注意：

• 请求体和响应体既可以用文本，也可以用本地文件。选文件时，工具读取文件内容整体替换 Body，并自动修正 Content-Length 与 Content-Encoding。
• 修改型重写项的 key 支持正则。在"修改 Body"里，key 位置填匹配模式、value 位置填替换内容，替换串里可以用$1引用第一个捕获组，例如把"price": \d+整体替换成"price": 999。
• 重定向支持通配映射。规则 URL 和目标地址里都有*时，命中 URL 中*对应的部分会被自动替换进目标地址，这是做"线上域名 → 本地服务"映射的基础。
• 每条规则和每个重写项都有独立开关，加上页面顶部的总开关，三层开关都能控制是否生效。

配置写法：环境变量让一套规则复用给所有人

重写项的值（Body、请求头值、重定向地址等）支持{{变量名}}环境变量语法。规则加载执行前，工具会先用当前生效的环境变量把{{...}}渲染成实际值再写入报文；环境变量没启用时按原字符串处理。

实际用法：把环境相关的部分（域名、token、测试账号）抽成变量，规则和配置整体共享给同事，每个人在自己的环境里填不同取值即可，规则本身不用改。变量渲染的实现见 lib/network/components/request_rewrite.dart 里的_renderItem，环境变量的管理在 lib/network/components/manager/environment_manager.dart。

端到端示例：给商品接口改价格，再测一遍失败分支

用一个完整场景把流程走通。假设要调试商品详情页：接口是https://api.example.com/api/goods/detail，想让页面显示的价格变成 9.9，之后再验证"接口报错"时前端的兜底展示。

第一步，创建主规则。在请求重写设置页添加规则：

1. URL 填api.example.com/api/goods/detail*，方法不限；
2. 规则类型选"修改响应"；
3. 添加一个"修改 Body"重写项，key 填"price": \d+（默认启用正则），value 填"price": 9.9，保存。

第二步，触发并验证。在 App 里重新打开商品详情页。此时链路是：请求命中该 URL → 拦截器匹配到这条"修改响应"规则 → 响应体里的价格字段被替换 → 工具自动重算 Content-Length → 页面显示 9.9。打开抓包列表对比该请求的响应，能看到改过之后的完整报文，确认改动确实发生在这条请求上。

第三步，加一条失败分支规则。再添加一条规则：URL 相同，类型选"替换响应"，添加两个重写项——"状态码"设为500、"响应体"填一段固定的{"code":500,"msg":"mock error"}。启用它并把它拖到上一条规则之前（首条命中生效），页面就会走错误兜底分支。

第四步，收尾。调试结束把规则停用或删掉即可，总开关关闭后所有规则都不再执行。

排坑与注意事项

第一次用请求重写时，以下问题最容易出现：

• 先分清"替换"和"修改"。"替换响应"是整体覆盖：状态码、头、Body 以你配的为准；"修改响应"是在原始响应上做正则替换。只想改一个字段时选修改，想模拟完整假数据时选替换，选错类型规则不会报错但行为完全不符合预期。
• 正则写错不会抛错，会静默回退。替换规则里的 key 正则是按"启用正则"开关处理的：未启用时自动转义成字面量匹配，模式不合法时会回退为字面量匹配。如果规则"不生效"，先检查 key 是否把正则开关打开了、模式是否合法。
• 顺序即优先级。匹配是首条命中生效，把.*这类全局规则放前面，会抢走所有具体规则的命中。全局规则放列表末尾，调试规则放最前。
• 不需要手动维护 Content-Length。无论整体替换还是正则修改 Body，工具都会重算 Content-Length 并移除 Content-Encoding，避免改了 Body 但头部长度对不上导致客户端解析异常。
• 规则与重写项分开落盘。总配置保存在~/.config/request_rewrite.json，每条规则的重写项单独存在rewrite/目录下的文件里（见 lib/network/components/manager/request_rewrite_manager.dart）。团队协作时，把配置文件拷给同事再导入即可；重写项文件较多时建议整体打包传递，配合环境变量切换不同环境。
• 想模拟延迟、弱网，请找另一个功能。请求重写模块只负责内容改写，不提供"延迟响应"选项；测超时和弱网场景请用 ProxyPin 的"弱网模拟"功能，两者配合覆盖异常流程。

小结

请求重写把"改流量"拆成了三层可组合的能力：拦截器负责在正确的时机找到报文，规则类型负责决定改到什么粒度，重写项负责具体怎么改。理解了这三层，绝大多数接口调试场景——假数据、请求头注入、域名映射、异常分支——都能用同一套配置完成。

源码可以从git clone https://gitcode.com/GitHub_Trending/ne/network_proxy_flutter获取。建议先从一条"修改响应 + 正则替换 Body"的小规则开始，跑通一次端到端验证，再逐步叠加全局规则和重定向。

【免费下载链接】network_proxy_flutterOpen source free capture HTTP(S) traffic software ProxyPin, supporting full platform systems项目地址: https://gitcode.com/GitHub_Trending/ne/network_proxy_flutter