ProxyPin 请求屏蔽完整实战:一行规则拦住不想要的请求【免费下载链接】network_proxy_flutterOpen source free capture HTTP(S) traffic software ProxyPin, supporting full platform systems项目地址: https://gitcode.com/GitHub_Trending/ne/network_proxy_flutterApp 里有个统计 SDK 每晚都在往某个上报域名发埋点,你只想让它闭嘴。打开 ProxyPin 的请求屏蔽设置,写一行规则,从此这个域名的流量原地消失,连网络层都走不出去。规则长什么样?先看结果。一条拦截规则实际长这样:{ enabled: true, url: *stats.cloudmail.cn/*, type: blockRequest }url是要拦的地址,直接写*通配符,不用手敲正则;type指定拦截类型;enabled管这一条是否生效。所有规则存在应用支持目录的request_block.json里,整个文件外面还套着一个全局的enabled总开关。原理一句话就能说清:ProxyPin 在请求链路里插了一道检查关卡,每个 HTTP 请求发出前都会经过这个拦截器,命中规则就直接返回空,对端根本收不到。拦截类型分两种:请求拦截是发出去之前掐断,响应拦截是放行请求、回来时把响应丢掉。匹配与持久化的完整逻辑在规则管理实现里。三步配好你的第一条规则会看形状了,直接上手,一共五个小动作:打开请求屏蔽设置面板(两个平台的入口见下面列表)确认顶部的启用开关是打开的点添加,把要拦的 URL 填进去,比如*stats.cloudmail.cn/*选拦截类型:屏蔽请求,或者屏蔽响应保存,下一条命中的请求就会被静默拦掉两个平台的入口路径不一样:桌面端:工具栏打开设置面板,点请求屏蔽按钮,弹窗里直接管理规则移动端:设置页进入请求屏蔽入口,是独立的规则列表页规则怎么写才准:通配符 正则速查URL 这行是最容易写错的。其实你不用学正则:系统会把规则里所有*原样替换成.*(正则里表示任意多个任意字符),再拿它对域名路径做局部匹配。所以写法可以松一点,但位置写错就命中不了。规则写法匹配什么等价正则*stats.cloudmail.cn/*stats.cloudmail.cn 子域下的所有路径.*stats.cloudmail.cn/.**/msg/push/*以 /msg/push/ 片段开头的所有路径.*msg/push/.**cdn.imgcache.net/*.jpgcdn.imgcache.net 域下的所有 jpg 图片.*cdn.imgcache.net/.*.jpg⚠️ 两个最高频的坑:一是把完整 URL 连查询参数都写进去,那只会拦到那一次请求;二是以为域名里的点号要转义,其实不会,.本来就能匹配任意字符,a.b.cn也会命中a1b1cn。三个高频场景的开箱配置写法上手了,看看日常最常见的三个场景,配方可以直接抄。广告与埋点屏蔽。App 启动慢,十次有八次不是业务请求的锅,而是广告和统计流量在排队。上报域名摸清楚之后,直接掐断最省事。{ enabled: true, list: [ { enabled: true, url: *stats.cloudmail.cn/*, type: blockRequest }, { enabled: true, url: *ads.bannermaster.cn/*, type: blockRequest } ] }隐私保护。第三方 SDK 总爱把用户行为数据往采集平台送,内容再无害也不该裸奔,掐断上报通道是最直接的一道闸。{ enabled: true, list: [ { enabled: true, url: */profile/upload/*, type: blockRequest } ] }调试时临时屏蔽特定接口。调试流程总被某个慢得离谱的第三方接口卡住,先把它挡掉,单独观察主链路;只想藏掉响应又想让请求正常发出,这里换成响应拦截即可。{ enabled: true, list: [ { enabled: true, url: *gateway.slowapi.io/*, type: blockResponse } ] }桌面端 vs 移动端:操作路径对比同一套规则,两个平台的入口不太一样:桌面端适合批量管理,移动端适合随手改一改。平台进入方式操作特点桌面端设置面板 → 请求屏蔽按钮弹窗式规则表格,双击行编辑,右键呼出更多操作移动端设置页 → 请求屏蔽入口独立页面,规则行上直接带启用开关移动端的开关做得更顺手:每条规则行上的启用开关点一下就能单独停用,点行进入编辑框,长按呼出删除菜单,不用来回找按钮。让拦截更聪明:三个联动技巧只看 URL 匹配能覆盖的场景有限,搭配其他功能才见效果。与请求重写配合。场景:被拦的接口 App 还得用,只是不想走线上。组合方式:不拦截,改用请求重写把线上接口指到你本地的模拟服务。效果:App 正常跑,返回什么由你说了算。纯拦截单独做不到这点——拦掉之后接口直接报错,重写才能把挡掉变成替换。与 Hosts 域名映射配合。场景:想封掉整个域,又不想为每条路径写规则。组合方式:在 Hosts 功能里把该域名直接映射到 127.0.0.1。效果:域名在解析层就废了,请求连网络层都出不去。拦截规则单独用是作用在请求层的,流量先走出去再被拦;hosts 映射是断在源头,更彻底。与自定义脚本配合。场景:只想在请求体带某个参数时拦、或只在某段时间拦,这类条件 URL 匹配表达不了。组合方式:写一段小脚本,检查请求内容后再决定是否丢弃。效果:拦截条件从看 URL升级到看内容,规则从静态变动态,这是单独一条屏蔽规则永远做不到的。规则不生效?按这张清单排查遇到不生效,多半 30 秒能定位,按顺序来:检查项怎么确认常见原因全局开关看设置面板顶部启用开关总开关关着,所有规则一起失效规则自身开关看规则行的启用列开关规则建了但单独被关掉URL 写法把实际请求的域名路径贴出来逐字对比通配符漏写,或把整个 URL 写死拦截类型看 type 是 blockRequest 还是 blockResponse选了响应拦截,请求其实照常发出匹配对象确认匹配用的是域名路径,不含协议和查询参数规则里写了参数,永远匹配不上请求时机看请求是不是发生在规则保存之前旧请求不走新规则,再触发一次试试以上都排除时,去日志里找屏蔽请求的记录——有记录说明其实已经拦住了,问题不在规则上。规则多了会不会拖慢?性能要点规则堆多了不用太担心,但有几个点值得留意:规则数量控制在 50 条以内,十几条最清爽通配符优先:*够用的场景,别手搓复杂正则每换一个项目就回头清一次过期规则,昨天的域名别一直留着高频拦截的域名写具体,避免宽匹配误伤正常流量写在最后这套功能解决的核心问题就一件:App 不想发的流量发不出去,不想收的响应回不来;再配合重写、hosts 和脚本,基本能覆盖网络流量外科手术的大部分需求。下一篇聊请求重写与 API 模拟,教你怎么让接口返回你想要的数据。觉得有用,可以转给正被垃圾请求折磨的同事。【免费下载链接】network_proxy_flutterOpen source free capture HTTP(S) traffic software ProxyPin, supporting full platform systems项目地址: https://gitcode.com/GitHub_Trending/ne/network_proxy_flutter创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考