抓包抓久了一定会遇到这两类场面：给一个银行类 App 抓包，证书装得好好的，App 一开就闪退或者报网络错误；或者反过来——只想看某个接口的流量，代理一开，几百条无关请求全涌进来，里面还夹着几个"一解密就出事"的站点。
两件事看着不挨着，背后的原因其实是同一个：抓包不是"全都解密"就完事。 有的流量要精确地解，有的要客气地放行，有的干脆得拦掉。这篇就讲这三档策略——白名单、放行名单、阻断名单——分别在什么时候用、怎么配吧。
先说清楚：为什么有的站点一解密就翻脸
中间人解密的原理，说穿了是"冒充"：工具自己签一张证书，冒充目标服务器和你的客户端握手，于是流量在你眼里就成了明文。这个把戏对常规站点基本通吃，因为客户端默认只看"证书是不是可信机构签的"。
但有两类不买账：一类是做了 证书绑定（Pinning） 的 App，它只认自己服务器的那张证书，中间人一出现就直接拒连——上面那个闪退的银行 App 就是这类；另一类是对代理敏感的服务，检测到连接特征不对就拒绝服务。碰上这两种，继续硬解只会一直报错，正确的动作是：别解它。
所以思路就出来了——不是"抓或不抓"的二选一，而是对每条流量分别定策略。三张名单就是三档策略：
| 你的情况 | 用哪张名单 | 效果 |
|---|---|---|
| 只想解密某几个域名的流量 | 白名单 | 只解指定域名，其余原样放行 |
| 某些站点、App 一解密就报错闪退 | 放行名单 | 对它们不解密、原样透传，不打扰 |
| 有些域名压根不想让它通 | 阻断名单 | 直接拦掉 |
白名单：只想解几个域名，怎么设？
适合"心里有数"的场景：你明确知道这轮要看哪些域名——比如自家 API 的域名、某个第三方服务的域名——那就把它们加进白名单，解密范围就框在这几个域名里，其余流量原样流过，一条都不碰。
这个用法有个隐形好处：噪音少了。不用在几百条列表里捞自己关心的请求，列表里出现的就都是你要看的；顺便也不用担心解密一堆无关站点带来的副作用——毕竟每多解一个站点，就多一分"被对方察觉"的机会。
放行名单：一解密就报错的站点，怎么绕开？
这是三张名单里最常用、也最"救命"的一张。银行、政务、支付类 App，还有那些对代理敏感的网站，全交给它：加进放行名单之后，这些域名的流量原样透传、不解密、不干扰——App 该正常跑还正常跑，你该抓别的还接着抓。
这里有个容易混淆的点值得展开说说：处理"抓不了的 App"，其实有两个相反的方向。
- 让它信你：对做了证书绑定的应用，一键解除它的证书校验，让它接受抓包证书——然后流量就归你解密了。适用于你想看这个 App 到底发了什么呢。
- 别碰它：把域名加进放行名单，完全不干预它的通信。适用于你不需要看它、只是不想让它捣乱（比如它一直报错拖累其余请求的排查）。
一个是"拿下"，一个是"绕开"。别一看到报错就去解 Pin——如果是无关紧要的 App，放行才是更省事的答案嘛。
阻断名单：什么时候需要直接拦掉？
前两张是"放"的学问，这张是"拦"的学问。常见的用法大概就这么几种：验证 App 在断网/接口不可用时的降级表现（把某个接口拦掉，看它怎么处理）；排查某个域名到底在流程里起什么作用（拦了它，看哪一步先崩）；或者单纯不想让某些请求发出去。
阻断和放行的区别值得记一下：放行是"让流量正常走、只是我不看"，阻断是"流量根本到不了对面"。测试降级逻辑的时候，只有后者能模拟出"请求失败"的效果。
三张名单怎么配合
实际用起来，配置思路反正就这几种：
默认全解 + 例外放行：先让工具解密所有流量，碰上报错的（银行 App、敏感站点）就往放行名单里加。适合探索型的排查——你不知道会遇到什么，就让例外一个个冒出来、一个个登记。
白名单保守解：只解自己关心的那几个域名，其余一概不碰。适合目标明确的排查——看自家 API 的联调、查某个第三方服务的对接，列表干净，心理也踏实。这几种思路，在 TraceEagle 里就是几张名单的开关组合。
两种可以混着来：白名单圈出重点，放行名单兜住"惹不起的"，剩下的按需处理。
解密是默认动作，名单才是精细活——把"碰不了"的和"不想碰"的分出去，剩下的才是你真正要看的。
列表里混着无关流量的烦躁，和 App 一抓就闪退的抓瞎，本质上都是"没有分层"。分完层你会发现，抓包体验的差距，很多时候就在这几张名单上。
这套名单不只是出问题了才去加，更适合当成日常配置习惯：开工前把项目相关的域名圈进白名单，把已知会闹脾气的第三方放进放行名单——两分钟的准备工作，省掉的是排查到一半突然被干扰的恼火啊。在 TraceEagle 里，解密范围设置就是这几张名单的入口：白名单、放行名单、阻断名单各管一摊，改完即时生效，不用重开会话。
