uBlock Origin 网络过滤流程：一次请求如何穿过五道关卡

uBlock Origin 网络过滤流程一次请求如何穿过五道关卡【免费下载链接】uBlockuBlock Origin - An efficient blocker for Chromium and Firefox. Fast and lean.项目地址: https://gitcode.com/GitHub_Trending/ub/uBlock在浏览器里一条script类型的请求从发起到落定中间要经历什么uBlock Origin 是 Chromium 与 Firefox 平台上的高效内容拦截器它的静态网络过滤引擎会在毫秒内给出放行、拦截或改道的裁决。本文带你沿 src/js/static-net-filtering.js 的matchRequest源码走一遍这条流水线理解动态防火墙、三域匹配与修饰规则分别在哪个环节接管。问题规模为什么不能逐条比对规则打开 uBlock Origin 的默认配置EasyList、EasyPrivacy 等列表合计约一万条过滤规则而一个普通页面加载时会触发数百个网络请求。若对每个请求做逐条规则字符串比对就是数万次正则运算浏览器会明显卡住。uBO 的答案是预处理列表在加载时就被编译成 HNTrie 等紧凑数据结构源码见 src/js/hntrie.js 及其 WASM 版 src/js/wasm/hntrie.wasm请求到来时按域名、类型做树状查找而不是全文扫描。理解了这个前提后面的五道关卡就好读了——它们本质上是按命中概率从高到低排列的查询步骤。关卡一动态防火墙先行拦截在静态引擎之前请求先经过你在弹出界面里点击生成的动态主机规则dynamic host rules。引擎实例定义在 src/js/filtering-engines.js// src/js/filtering-engines.js const permanentFirewall new DynamicHostRuleFiltering(); const sessionFirewall new DynamicHostRuleFiltering();每个站点的主机规则分permanent持久与session会话两层。防火墙只关心来源域名 目标域名这一对关系判断成本极低因此放在最前面你在弹出界面把某站点的scripts按钮点成红色后续同类请求在这里就被直接否决根本轮不到静态引擎出场。关卡二到四三域匹配一次请求的裁决核心静态过滤的核心是matchRequestsrc/js/static-net-filtering.js 第 5582 行。它把每条规则划入三个域realm并按命中概率排序查询BLOCK 域——普通拦截规则ALLOW 域——放行规则$badfilter白名单语义BLOCKIMPORTANT 域——带important修饰符的强拦截。关键代码只有几行但顺序信息量很大// src/js/static-net-filtering.js, matchRequest() 摘录 const r this.realmMatchString(BLOCK_REALM, typeBits, partyBits); if ( r || (modifiers 0b0010) ! 0 ) { if ( $isBlockImportant ) { return 1; } if ( this.realmMatchString(ALLOW_REALM, typeBits, partyBits) ) { if ( this.realmMatchString(BLOCKIMPORTANT_REALM, typeBits, partyBits) ) { return 1; } return 2; } if ( r ) { return 1; } } return 0;注意BLOCK → ALLOW → BLOCKIMPORTANT的查询次序若一条普通拦截和一条放行规则同时命中请求放行但若放行命中之后又撞上important拦截则改为拦截。返回值语义是整条流水线的通用语言返回值含义典型触发条件0放行无规则命中或仅命中修饰规则1拦截命中 block 或 block-important 且未被 allow 覆盖2放行显式命中 allow 规则覆盖普通 block这里的typeBits与partyBits是请求的位图编码请求类型script、image、xhr等由typeNameToTypeValue映射为位值fctxt.is3rdPartyToDoc()判定第一方/第三方身份。位运算代替字符串比较正是高效拦截器名号的来源。关卡五修饰规则决定怎么拦判定只是第一步拦截方式由修饰规则modifier接管全部走同一个入口matchAndFetchModifiers修饰语法作用实现方法$redirect把请求改道到空资源noop 等redirectRequest按优先级排序后取最高者removeparam剔除 URL 查询参数filterQueryuritransform正则替换 URLtransformURLurlskip按模板改写 URL 以绕路urlSkip多条$redirect规则冲突时compareRedirectRequests按important 优先、allow 次之、显式优先级数字排序胜出者改写fctxt.redirectURL。请求被改道后后续修饰步骤都会检查fctxt.redirectURL ! undefined并提前返回——一次请求只改道一次。写一条规则看它从哪道关卡生效用户侧只需要会写过滤语法。在我的过滤规则标签页里/example.com^$thirdparty,script ||ads.example.com^$important第一条是普通的第三方脚本拦截落在 BLOCK 域第二条带$important落在 BLOCKIMPORTANT 域能压过任何普通 allow 规则。保存后打开 Logger 面板重新加载页面每条被处置的请求旁边都会标注命中了哪条规则——这是验证规则究竟在哪个环节生效最直接的手段。规则列表的增删持久化逻辑在 src/js/whitelist.js 与 src/js/settings.js 中。容易踩的三个坑误判 important 的语义方向$important不是加强拦截力度而是优先级提升——allow 规则加 important 后反而更强。把 allow 当成全局白名单allow 只能覆盖普通 block若两条important规则冲突结果由规则列表顺序等细节决定建议用 Logger 实际验证而不是心算。以为防火墙和静态规则是二选一它们是串联关系动态防火墙先判、静态引擎后判站点被防火墙放行不代表静态列表里没有拦截规则。五道关卡按命中概率递进排列、用位图代替字符串比较这就是 uBO 能把上万条规则压缩进毫秒级判定的全部秘密。想继续深入直接读 src/js/static-net-filtering.js 里matchRequest上方的位域注释第 50 行起的二进制布局图会非常值回票价。【免费下载链接】uBlockuBlock Origin - An efficient blocker for Chromium and Firefox. Fast and lean.项目地址: https://gitcode.com/GitHub_Trending/ub/uBlock创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考