企业官网建设流程全解析

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

ProxyPin 的请求屏蔽功能能把恶意追踪、广告弹窗、隐私上传请求在发出前拦掉，不让它们刷爆你的抓包列表。我们直接上手，把一条规则配出来。

三分钟配出第一条请求屏蔽规则 🎯

按下面三步走，目标是让规则尽快生效：

1. 打开 ProxyPin 进入「设置」页，点「请求屏蔽」入口（桌面版在左侧菜单，移动版在设置列表里）。
2. 点「添加」填一条规则：URL 写*.doubleclick.net*，类型选「屏蔽请求」。
3. 把顶部的「启用」开关打开，然后随便打开一个带 doubleclick 广告页面，这条请求就从列表里消失，日志里能看到「屏蔽请求」，说明规则生效了。

这里有两个类型要分清。「屏蔽请求」是请求还没发出去就被掐断，列表里根本看不到这条请求；「屏蔽响应」是请求照常发出收到，但把响应体丢掉，列表里还留着这条记录，只是没有响应内容。广告、追踪这类噪音，一般选前者就够了。

请求屏蔽规则怎么写才准 📐

先记住一个事实：规则匹配的是「域名 + 路径」，协议头不带。所以你写规则时不用写https://，写了也不会命中。下面这些是常用写法：

规则本质是被换成一条正则：*直接替换成.*，于是*.example.com*就变成.*\.example\.com.*。匹配用的是无锚点的hasMatch，也就是「只要中间有一段能对上就算中」，这既是它好写的原因，也是它容易误伤的原因——后面踩坑部分会展开。拿不准要不要加*时，习惯是先写最小匹配范围，再逐步放宽，宁可先漏拦也别先误拦。

匹配的核心逻辑其实就一行，在 request_block.dart 里：enabled && type == blockType && urlReg!.hasMatch(matchUrl)，翻译过来就是「开关开、类型对、正则命中」三者同时满足才拦。

三个真实场景的请求屏蔽配置

广告拦截

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

广告域基本是固定的，直接通配子域名再屏蔽请求即可，不用去纠结具体路径。

隐私保护

{ "enabled": true, "list": [ { "enabled": true, "url": "*sentry.io*", "type": "blockRequest" }, { "enabled": true, "url": "*amplitude.com*", "type": "blockRequest" } ] }

报错上报和行为分析 SDK 是隐私外泄的主要来源，请求阶段直接拦掉，设备信息就不会被发出去。

调试期屏蔽特定接口

{ "enabled": true, "list": [ { "enabled": true, "url": "/health*", "type": "blockRequest" }, { "enabled": true, "url": "/api/ping*", "type": "blockRequest" } ] }

健康检查、心跳这类接口几秒一次，不挡的话会把真正关心的业务请求刷屏，调试时优先清掉它们。

请求屏蔽和其他功能怎么组合 🔗

配合「请求重写」：屏蔽是「不让它出去」，而 请求重写 能做的是「换个地方去」。有些请求你没法简单掐断，一断业务流程就崩，这时可以把它改写到安全地址或本地模拟响应。屏蔽管硬拦，重写管软改，两个一起用，既能挡住真恶意，又能保住假阳性。

配合「Hosts 配置」：对某些域名你压根不想让它出现，用 Hosts 把域名指向一个无效地址，连接在 DNS 层就失败了；而请求屏蔽工作在 HTTP 层，能精细到路径。前者更彻底、更早，后者更细、更灵活，按你要拦的粒度二选一，或两者叠加。

请求屏蔽踩坑记录 🕳️

• *.example.com没挡住 example.com 主域：*换完是.*\.example\.com，点前必须还有一个字符，所以只命中子域名 → 想连主域一起挡，就改成*example.com*，或单独再加一条规则。
• 规则写了却不生效：多半是「请求屏蔽」总开关或这条规则自己的开关有一个没开 → 两级开关都查一遍，最容易被忽略的是顶部总开关。
• 误伤：把不相干的接口也拦了：正则是无锚点的，*sentry.io*会连带命中sentry.io.bak、notsentry.io这种串 → 给模式补上域名、路径上下文，越具体越安全。
• 桌面生效、手机不生效（或反过来）：每个端把规则存在各自的本地request_block.json，不跨端同步 → 在需要生效的那台设备上重新加一遍，别默认「一处配、处处通」。
• 屏蔽后 App 报错或疯狂重试：对关键业务接口用了「屏蔽请求」，App 拿不到响应就异常 → 换成「屏蔽响应」，或先确认这个接口确实可以拦。

请求重写还能给请求「改道」，想深入看它怎么配，可再读请求重写的配套文章。觉得有用就点赞、收藏、关注一下。

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