企业官网建设流程全解析

抓包调试这件事，很多人卡在第一步不是不会配代理，而是被海量请求淹没。一个页面刷出来，图片、脚本、样式、埋点、广告、心跳包全在列表里滚，真正想看的那条接口请求夹在中间，翻半天找不到。Charles 里的 Block List 和 Allow List 就是专门治这个毛病的两个功能，说白了就是给请求列表装两道闸门：一道负责把不想看的挡在外面，一道负责只放想看的进来。这两个功能看着简单，但实际用起来门道不少，配错了会出现"明明加了规则却还是抓不到"或者"整个列表空空如也"的情况。这篇内容适合刚上手 Charles 做接口调试的朋友，也适合用了一段时间但一直没系统整理过过滤规则的老手，我会把这两个功能的原理、配置细节、实操流程和踩过的坑一次讲透，让你看完就能直接照着配。

1. 先搞清楚这两个功能到底在干什么

1.1 从"请求洪水"说起：为什么需要过滤

做接口调试的人都有体会，现代一个网页或者 App 页面发起的网络请求数量远超想象。随便打开一个内容型页面，主文档之外还有几十个静态资源请求，再加上各种统计上报、性能监控、A/B 实验分流、推送长连接，列表里几百条记录是常态。你要找的登录接口可能排在第 87 条，要看的订单列表接口被一堆图片请求夹在中间。手动滚动查找不仅慢，还容易看漏。

Charles 的过滤能力分两个层次。第一层是抓取层面的过滤，也就是 Recording Settings 里的 Include/Exclude，它决定哪些请求被记录进 Charles，不满足条件的请求压根不会出现在会话列表里。第二层是展示层面的过滤，就是这篇要讲的 Block List 和 Allow List，它作用于已经抓到的请求，决定哪些显示、哪些隐藏。这两层的区别很关键：抓取过滤是"不记录"，展示过滤是"记录了但不显示"。理解这一点，后面很多疑惑就通了。

Block List 和 Allow List 在 Charles 的菜单位置是 Tools 下面的 Block List 和 Allow List，两个功能共用一套规则引擎，逻辑正好相反。Block List 是黑名单思路，列进去的请求被隐藏；Allow List 是白名单思路，只有列进去的请求才显示。它们作用于当前会话的展示层，不会影响实际抓取，也不会修改请求本身，关掉规则或者清空列表，被隐藏的请求立刻回来。

1.2 黑名单与白名单的本质差异

这两个功能的差异不只是"挡"和"放"的方向相反，更在于适用场景完全不同。Block List 适合"我知道不要什么"的场景，比如你只想屏蔽某个图片 CDN 域名下的所有请求，或者屏蔽某个统计上报域名，其他都保留。Allow List 适合"我只关心什么"的场景，比如你正在调一个特定接口，只想看这个域名下的请求，其他全部隐藏。

从操作成本上看，Block List 在请求种类繁杂但干扰源集中的时候更省事，你只需要列出几个要屏蔽的域名。Allow List 在目标明确的时候更高效，你只需要写一条规则，列表立刻清爽。但从风险角度看，Allow List 更"危险"一些，因为规则写错或者写得太窄，会导致列表一片空白，新手容易以为 Charles 坏了。Block List 相对安全，最坏情况是屏蔽多了，但至少还能看到东西。

我个人的习惯是：日常调试用 Allow List 锁定目标域名，快速定位；做全量分析或者排查"到底有哪些请求"的时候用 Block List 清掉已知噪音。两种模式切换着用，比死守一种效率高得多。

1.3 规则匹配的基本单位：主机名与路径

这两个功能的规则匹配对象是请求的 URL，具体拆成主机名（host）和路径（path）两部分。你在配置界面里填的每一条规则，本质上是在描述"什么样的 URL 命中这条规则"。匹配逻辑是从 URL 里提取主机和路径，然后跟规则做比对。

这里有个容易忽略的点：规则匹配默认是按主机名整体匹配的，不是模糊包含。也就是说你填example.com，它匹配的是主机名恰好为example.com的请求，api.example.com这种子域名默认不命中，除非你显式写成*.example.com这种通配形式。路径部分同理，填/api/user匹配的是路径以这个开头的请求。这个匹配粒度设计得很合理，因为实际调试中我们往往就是按域名和接口前缀来划分请求的。

提示：规则里的通配符写法要留意，*可以匹配任意字符序列，但不同位置的语义不一样。主机名开头的*.表示任意子域名，路径里的*表示任意后缀。写规则前先在脑子里过一遍目标 URL 的结构，能省掉很多"为什么没生效"的困惑。

2. 配置界面的结构与逐项拆解

2.1 打开配置面板与界面布局

从菜单栏 Tools 进入 Block List 或 Allow List，弹出的窗口结构基本一致。上半部分是规则列表，显示当前已经添加的所有规则；下半部分是添加和编辑区域，包含几个输入框和按钮。窗口底部通常有启用开关和确定、取消按钮。

界面里几个关键元素需要认清楚。规则列表每一行代表一条规则，通常显示主机名和路径的组合，前面可能有个勾选框控制这条规则是否启用。添加区域一般有主机名输入框、路径输入框，以及一个添加按钮。有的版本还会提供"从选中请求快速添加"的入口，这个后面会讲，是提效的关键。

第一次打开这个面板的人容易懵的地方是：不知道规则是按什么顺序生效的，也不知道多条规则之间是"或"还是"与"的关系。答案是：多条规则之间是"或"的关系，任意一条命中就生效；规则之间没有优先级顺序，不存在"后面的覆盖前面的"这种逻辑。这一点跟防火墙规则链不一样，别想复杂了。

2.2 主机名与路径的填写规范

主机名输入框填的是域名部分，不带协议头，不带端口（除非端口是非标准的且你需要精确匹配），不带路径。比如目标 URL 是https://api.example.com/v2/order/list?page=1，主机名填api.example.com，路径填/v2/order/list。

路径输入框可以留空，留空表示匹配该主机下的所有路径。这个设计很实用，当你只想按域名过滤时，路径留空就行。路径填写时要注意是否带查询参数：Charles 的路径匹配通常只比对路径部分，查询字符串不参与匹配，所以你填/v2/order/list就能命中带各种查询参数的同一接口，不用把?page=1也写进去。

通配符的使用是重点。主机名支持*通配，比如*.example.com匹配所有子域名，api.*.com这种中间通配也支持但实际很少用。路径支持*通配，比如/api/*匹配/api/下所有路径，*.js匹配所有以.js结尾的路径。我见过有人把通配符写成正则表达式的样子，比如/api/.*，这是不对的，Charles 这里不是正则引擎，.*会被当成字面的点和星号处理，匹配不上。

2.3 启用开关与规则的临时停用

规则列表里每条规则前面的勾选框控制单条规则的启用状态，窗口底部还有一个总开关控制整个列表是否生效。这个双层开关在实际调试中很有用：你可以预先配好一批规则，调试时按需勾选，不用反复删除重建。

我自己的做法是维护一份"常用屏蔽清单"，把那些常年干扰的统计域名、图片 CDN、字体服务都列进去，平时总开关关着，需要清静的时候一键打开。Allow List 那边则维护几个常用接口域名，切换项目时勾选对应的那几条。这种"规则常驻、开关控制"的用法比每次现配要省时间得多。

注意：总开关关闭时，列表里的规则全部不生效，但规则本身还在。别看到列表里有规则就以为它在起作用，先确认总开关状态。这个坑我踩过，排查了半天以为是规则写错了，结果是总开关没开。

3. 实操：从零配一套可用的过滤规则

3.1 场景设定与目标拆解

假设现在要调试一个内容类应用的接口，页面加载后会发大量请求，包括主接口、图片资源、统计上报、字体文件等。目标是让会话列表里只留下业务接口请求，把静态资源和上报请求都挡掉。这个场景用 Block List 更合适，因为干扰源是已知的几类，列出来屏蔽即可。

先明确要屏蔽的类别：图片资源通常在图片域名下，统计上报通常在专门的统计域名下，字体文件按扩展名可以识别。对应的规则大概是：屏蔽图片域名*.imgcdn.example.com，屏蔽统计域名*.track.example.com，屏蔽所有.woff和.woff2结尾的路径。这三条规则覆盖了绝大部分噪音。

为什么用域名而不是用路径来屏蔽图片？因为图片路径千变万化，按路径写规则要写很多条，按域名一条就够。这就是前面说的"干扰源集中"的判断：如果噪音集中在少数几个域名，按域名屏蔽最省事；如果噪音分散在很多域名但路径特征明显（比如都是.js结尾），那就按路径屏蔽。

3.2 逐条添加规则并验证

打开 Block List 面板，在主机名框输入*.imgcdn.example.com，路径留空，点添加。然后输入*.track.example.com，路径留空，添加。第三条主机名留空或者填*，路径填*.woff*，添加。三条规则加完后，回到会话列表看效果。

验证环节很关键，别加完规则就完事。正确的验证方法是：先在没开规则的情况下抓一轮，记下列表里有哪些请求；开启规则后再抓一轮，对比少了哪些。如果该消失的没消失，检查规则拼写；如果消失的比预期多，检查通配符是不是写宽了。我一般会保留一份"规则生效前"的会话存档，方便对比。

这里有个实操细节：Charles 的规则修改后通常需要重新触发请求才能看到效果，已经抓到的历史请求不会因为加了规则就立刻从列表消失（部分版本会实时刷新，但保险起见重新抓一轮最可靠）。所以验证时别盯着旧列表看，刷新页面重新抓。

3.3 用 Allow List 做精准锁定

换个场景：现在只想看某个特定接口的请求，其他全部不要。这时候用 Allow List。打开 Allow List 面板，主机名填api.example.com，路径填/v2/order/*，添加并启用。列表立刻只剩这个域名下这个路径前缀的请求。

Allow List 的规则要写得足够精确，否则容易"锁死"自己。比如你只填了主机名没填路径，那这个域名下所有请求都会显示，可能还是很多；如果你路径写得太窄，比如写成了完整路径带参数，可能一条都匹配不上。我的经验是路径写到接口分组那一级，比如/v2/order/，既能覆盖该分组下所有接口，又不会放进无关请求。

Allow List 还有一个容易被忽略的用法：配合断点调试。当你只想对某个接口下断点，但列表里请求太多不好定位时，先用 Allow List 把其他请求隐藏，列表里只剩目标接口，这时候再下断点、改参数、看响应，整个流程干净利落。这个组合用法比在几百条请求里翻找要高效得多。

4. 规则不生效？这些排查方向挨个过一遍

4.1 常见失效原因速查

规则配了但没效果，原因通常集中在几个地方。下面这张表是我这些年遇到过的失效情况汇总，按出现频率排序。

这张表覆盖了九成以上的问题。实际排查时按顺序过：先看总开关，再看单条勾选，再看规则写法，最后看是否重新抓取。这个顺序是从"最容易被忽略"到"最需要动脑"排列的，能帮你快速排除低级错误。

4.2 通配符写错的典型表现

通配符问题是新手最容易栽的地方，单独拎出来说。Charles 这里的通配符只有*一种，语义是"匹配任意字符序列"，不支持?单字符匹配，不支持正则的.*、\d这类语法。写规则时脑子里要切换到"通配符模式"，别带着正则思维。

典型错误一：把*.example.com写成*example.com。前者匹配所有子域名，后者匹配的是以example.com结尾的任意主机名，包括notexample.com这种，范围反而更宽了，容易误伤。典型错误二：路径里写/api/.*，以为能匹配/api/下所有路径，实际上.*被当成字面字符，匹配不上任何正常路径。正确写法是/api/*。

典型错误三：主机名里带了协议头，写成https://api.example.com。主机名框只填域名部分，协议头是 URL 的另一部分，填进去就匹配不上了。这个错误很常见，因为大家习惯复制完整 URL，粘贴时忘了去掉前缀。

4.3 Allow List 把自己锁死的自救方法

Allow List 写得太窄导致列表空白，是新手最慌的情况，以为抓包工具坏了。其实规则还在生效，只是没有请求满足条件。自救方法很简单：打开 Allow List 面板，把规则前面的勾去掉，或者直接关掉总开关，列表立刻恢复。如果连面板都打不开（极少见），可以尝试重启 Charles，规则不会丢失。

预防这种情况的办法是：加 Allow List 规则时先用宽一点的写法验证，确认能匹配上再逐步收窄。比如先只填主机名，看到请求出来了，再加路径前缀，再逐步细化。这种"由宽到窄"的调试思路比一次性写精确规则要稳，尤其在不熟悉目标 URL 结构的时候。

提示：Allow List 规则建议配合"临时停用"使用。调试不同接口时不用删规则，勾选切换即可。我习惯把常用接口的规则都留着，用勾选框控制，比反复增删省心。

5. 把这些技巧用顺手的几个心得

规则维护要有"清单意识"。Block List 和 Allow List 的规则是持久化保存的，关掉 Charles 再打开还在。这意味着你可以把它当成一个长期积累的过滤配置库。我的做法是按项目或按域名类型分组维护，比如"统计类""图片类""常用接口类"，虽然 Charles 本身不提供分组功能，但可以通过命名习惯来区分，比如规则列表里按添加顺序排列，同类规则连着加，视觉上就成组了。

规则要定期清理。用久了列表里会堆积大量过期规则，有些域名早就不用了，有些接口已经下线。这些僵尸规则不仅占地方，还可能在调试新项目时误伤。我一般每个月过一遍规则列表，把明显没用的删掉，保持清单精简。精简的清单还有个好处：出问题时容易定位是哪条规则导致的。

两个功能可以叠加使用。Block List 和 Allow List 是独立的，可以同时启用。同时启用时的逻辑是：先过 Allow List（只留白名单内的），再过 Block List（从白名单结果里再剔除黑名单内的）。这个叠加逻辑在复杂场景下有用，比如你想看某个域名下所有请求，但这个域名下有一类心跳包特别烦，就可以 Allow List 放行域名、Block List 屏蔽心跳路径，两层过滤各司其职。

最后说个提效细节：Charles 支持从会话列表里选中请求直接添加到 Block List 或 Allow List，右键菜单里通常有这个入口。这个操作比手动敲域名路径快得多，而且不会敲错。定位到一条典型请求，右键添加，规则自动填好，这是日常使用频率最高的操作路径。我现在的习惯是看到噪音请求直接右键屏蔽，看到目标接口直接右键加白名单，几乎不用打开配置面板手动输入。

实际用下来，这两个功能的价值不在于功能本身多复杂，而在于帮你把注意力集中在真正要看的请求上。抓包调试的效率瓶颈往往不是工具能力，而是信息过载，过滤规则就是对抗信息过载最直接的手段。规则配得顺，调试过程就顺；规则一团乱，工具再好也白搭。