企业官网建设流程全解析

ProxyPin 请求阻塞完整教程：拦截恶意请求与广告流量

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

抓包记录里总混着一堆分析、广告请求——google-analytics、doubleclick，再加上各种行为收集接口。看着碍眼，还会干扰你调主接口。用 ProxyPin 的请求阻塞功能，可以把这类流量直接掐掉。ProxyPin 是一款开源免费、全平台支持的抓包工具，这份请求拦截教程带你走完从配好第一条拦截规则，到搭出多层防护的完整流程。

一、拦截请求，到底在拦什么？

一句话：请求阻塞就是在抓包链路上设了一道闸门，每个请求/响应经过时先核对你的规则，命中就拦下。

拦截逻辑在 RequestBlockInterceptor 里，它在链路两个位置把关：

App 网络请求 │ ▼ 【拦截点1：blockRequest】── 命中规则？── 是 ──▶ 直接拦截，请求发不出去，记日志"屏蔽请求" │ 否 ▼ 代理到目标服务器 ▲ 【拦截点2：blockResponse】── 命中规则？── 是 ──▶ 响应回来后丢弃

• 屏蔽请求（blockRequest）：请求发出前就被拦下，服务器根本收不到。适合砍掉广告、埋点这类"压根不想让它存在"的流量。
• 屏蔽响应（blockResponse）：请求放行，响应回来后丢弃。适合只想挡掉某类返回内容、但请求本身要正常走通的场景。

规则本身由 RequestBlockManager 管着。你在界面上增删改，它立刻把规则写进应用支持目录下的request_block.json，下次启动再读回来。文件结构很直白：顶层一个enabled总开关，加一个list规则数组，每条规则含enabled、url、type三个字段。

二、5 分钟配好第一条拦截规则

🖥️ 桌面版和移动版各有一套规则管理界面，但操作路径一致：

1. 进设置页。桌面版从左侧菜单打开请求阻塞设置面板（实现在 lib/ui/desktop/setting/）；移动版在设置菜单进入请求阻塞页（实现在 lib/ui/mobile/setting/request_block.dart）。
2. 打开总开关。enabled为关时，所有规则一律不生效，先确认它开着。
3. 点"添加"，填三个参数：
   • URL 模式：要拦的域名或路径，支持通配符*；
   • 拦截类型：选"屏蔽请求"或"屏蔽响应"；
   • 启用状态：每条规则有独立开关，单独控制。
4. 保存即生效，规则同步写入request_block.json。移动版还能直接拨每条规则右侧的开关，长按规则可以编辑或删除。

正则通配符写法先记一条：系统会把规则里的*自动转成正则.*（转换逻辑在 lib/network/util/url_pattern.dart）。所以写规则时，把*理解成"任意字符串"就行：

三、高频场景配方

📢场景 1：广告拦截。最常见的广告/统计域名就是 google-analytics 和 doubleclick，加两条"屏蔽请求"规则即可整体清掉：

{ "enabled": true, "list": [ { "enabled": true, "url": "*google-analytics.com/*", "type": "blockRequest" }, { "enabled": true, "url": "*doubleclick.net/*", "type": "blockRequest" } ] }

🕵️场景 2：隐私保护。很多 App 会往 analytics 类接口上报行为数据，这类接口名没法穷举，就用宽一点的通配符兜底：

{ "enabled": true, "url": "*analytics/*", "type": "blockRequest" }

万一误伤了正常接口，单独关掉这一条就行，其他规则不受影响。

四、拦截不生效？先查这 3 个坑

1. 总开关没开。request_block.json顶层的enabled是 false 时，整套规则等于不存在。先看界面顶部的总开关。
2. 拦截类型和实际方向对不上。一条规则要么是"屏蔽请求"、要么是"屏蔽响应"，两套判定分开走。你配了"屏蔽响应"，请求其实已经发到服务器了，只是回来后丢弃；想拦发送就选"屏蔽请求"。
3. URL 模式写多了。匹配用的是"域名 + 路径"，不带协议头和端口，写https://xxx反而命不中。另外*只是通配符，不是正则，规则里不要写^、$这类正则符号。

三处都对还不生效，就翻日志找"屏蔽请求"/"屏蔽响应"的记录，确认规则到底有没有被命中。

五、进阶：组合出你的防护体系

单靠拦截只是第一层。把 ProxyPin 的其他功能搭起来，防护才完整：

• 配合请求重写：不想硬拦的恶意请求，改成重定向到安全地址再放行，业务无感知；
• 结合 Hosts 配置：把整个域名映射到无效 IP，一刀切掉一类域名；
• 联动脚本功能：通配符写不出的复杂判断，用自定义脚本决定拦不拦。

实际组合建议分层：Hosts 管"整个域名拉黑"，请求阻塞管"高频垃圾流量"，重写和脚本留给需要精细处理的特例。规则数量别堆太多，复杂模式多了会拖慢抓包链路，定期清理不用的规则。

把这几条规则和组合用起来，流量日志会干净不少。接下来可以看看怎么用请求重写把接口"调包"，做出更逼真的模拟环境。

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