Charles如何设置黑名单屏蔽特定域名的HTTP/HTTPS请求？

Question

**常见问题：** 在使用Charles Proxy进行移动端或Web端网络调试时，大量第三方SDK（如广告、统计、推送服务）的域名请求（如 `ads.example.com`、`metrics.xxx.net`）频繁出现，干扰关键接口分析。虽然Charles支持“Block List”（黑名单）功能，但用户常遇到：勾选启用后仍无法拦截HTTPS请求、部分域名匹配失效、或误拦了本应放行的子域名。根本原因在于——Charles的黑名单仅作用于HTTP明文请求；对HTTPS请求，需先完成SSL代理配置（安装并信任Charles根证书），且黑名单规则默认不自动解密HTTPS流量，必须配合“SSL Proxying”设置将目标域名显式加入SSL代理列表，否则仍以CONNECT隧道形式透传，无法识别和拦截。此外，通配符（如 `*.adtech.com`）和正则匹配的支持有限，易因格式错误导致失效。如何正确配置黑名单，确保HTTP/HTTPS双协议下精准屏蔽指定域名（如 `api.analyticsservice.io`），同时避免影响调试主站通信？

Answer 1

```html

一、现象层：为什么“勾选了Block List却拦不住广告请求？”

这是最表层的困惑：用户在 Proxy → Block List... 中添加 ads.example.com 并启用，但移动端App仍持续发出该域名的HTTPS请求，Charles日志中仅显示 CONNECT ads.example.com:443（灰色隧道），无后续HTTP方法与响应体。根本原因在于——Block List对HTTPS CONNECT隧道完全无效，它仅能拦截已解密的HTTP明文流量。未配置SSL Proxying前，所有HTTPS请求均以加密隧道形式直通，Charles连SNI都不可见，更遑论匹配域名。

二、机制层：Charles黑名单的协议边界与SSL代理耦合原理

Charles的流量处理遵循严格分层模型：

• HTTP明文流：直接解析Host头 → 可被Block List实时匹配 → 立即返回403/502
• HTTPS加密流：先建立CONNECT隧道 → 若未配置SSL Proxying → 不解密 → 无法读取URL路径或Host → Block List规则永不触发
• HTTPS解密流：需同时满足①设备安装并信任Charles根证书；②目标域名显式加入 SSL Proxying Settings → Enable SSL Proxying 列表 → 此时才降级为类HTTP流 → Block List方可生效

三、配置层：双协议精准屏蔽的四步黄金配置法

1. 全局启用Block List：Proxy → Block List → ✅ Enable Block List
2. 注入SSL根证书：iOS/macOS/Android各端完成证书安装与系统级信任（关键！否则SSL Proxying将失败）
3. 显式声明SSL代理域名：Proxy → SSL Proxying Settings → Add → api.analyticsservice.io:443（⚠️必须带端口，不可写*.analyticsservice.io）
4. Block List精确填写格式：api.analyticsservice.io（不加协议、不加端口、不加通配符前缀）

四、避坑层：通配符失效与子域误拦的根源分析

错误写法	后果	正确写法
*.adtech.com	Charles不识别通配符语法，完全不匹配	adtech.com（自动覆盖所有子域）
https://metrics.xxx.net	协议头导致匹配失败	metrics.xxx.net
api.analyticsservice.io:443	Block List不支持端口，导致漏拦	api.analyticsservice.io

五、验证层：三重断言确保配置闭环

执行以下验证动作：

1. 发起 curl -x localhost:8888 https://api.analyticsservice.io/v1/track → 应返回 403 Forbidden 且Charles显示红色Blocked条目
2. 发起 curl -x localhost:8888 http://api.analyticsservice.io/v1/track → 同样被拦截（验证HTTP路径）
3. 访问主站 https://myapp.com → 确保其域名（避免不必要的解密开销与证书警告）

六、进阶层：自动化维护与企业级扩展方案

针对大型项目SDK域名动态变更场景，推荐：

• 脚本化同步：使用Charles REST API（需开启Help → SSL Proxying → Enable SSL Proxying for all hosts后配合白名单）批量导入域名列表
• 条件式拦截：结合 Tools → Breakpoints 对特定Host设置断点，实现“仅当含utm_source=admob时拦截”等业务逻辑过滤
• 环境隔离：通过 Proxy → Recording Settings → Include/Exclude Locations 限定仅录制指定域名，从源头减少干扰流量

七、架构层：对比Fiddler / mitmproxy 的设计哲学差异

Charles采用“显式SSL代理白名单”设计，本质是安全优先策略——默认不触碰HTTPS，需开发者主动声明风险域；而mitmproxy默认解密全部HTTPS（需手动exclude），Fiddler则依赖Windows证书链自动注入。这种差异导致：

graph LR
A[Charles] -->|必须显式Add SSL Proxying| B(精准可控)
A -->|配置遗漏即失效| C(学习曲线陡峭)
D[mitmproxy] -->|--set ssl_insecure=True| E(高自由度)
D -->|易引发证书校验崩溃| F(移动端兼容性差)

```