接口调试新姿势
开了 SSL 抓包，有些网站反而打不开？把域名加进「跳过 SSL 代理」
系统代理已经设置好，DevPeek CA 也已经信任。
大部分 HTTPS 请求都能正常抓到明文，但偏偏有一个网站加载失败，或者某个 App 一直提示网络异常。
你做了一个对照：
- 系统代理开着、SSL 代理开着：失败
- 系统代理开着、SSL 代理关掉：恢复
- 只把这个 Host 排除出 SSL 代理：同样恢复
这说明问题不一定出在“代理”本身，更可能出在 HTTPS 中间人解密这一步。
这时不必关闭全部 SSL 抓包。把不兼容的 Host 加进 跳过 SSL 代理（Exclude），让它继续经过 DevPeek 的 CONNECT 隧道，但不拆开 TLS；其它域名仍然可以照常查看 HTTPS 明文。
先确认是不是本文讨论的情况
适合使用 Exclude 的典型现象是：
- 系统代理和 DevPeek CA 已正确配置；
- 大部分 HTTPS 请求可以正常解密；
- 只有少数网站或 App 开启 SSL 代理后失败；
- 关闭 SSL 代理，或者排除对应 Host 后立即恢复。
最后一条最关键。
如果关闭 SSL 代理后仍然失败，问题可能在系统代理、网络、DNS、客户端代理支持或源站本身，单纯添加 Exclude 未必有用。
如果你还没成功抓到第一个 HTTPS 请求，先看快速上手和代理与 SSL 证书。
「跳过 SSL 代理」不是完全直连
这里容易混淆两个概念。
CONNECT 隧道
浏览器 / App
│
│ TLS 原始数据
▼
DevPeek
│
│ TCP 转发
▼
源站
流量仍经过 DevPeek，但 DevPeek 不解密 HTTPS。TLS 握手直接发生在客户端和源站之间，DevPeek 只能看到 CONNECT、Host、流量大小等连接级信息，看不到请求头、Body 和响应明文。
Exclude 选择的是这种模式。
完全绕过代理
客户端不连接 DevPeek，直接访问源站。这需要系统代理绕过规则或 PAC，不是 SSL 代理里的 Exclude。
因此，本文所说的“跳过”是跳过 HTTPS 解密，不是忽略请求，也不是让流量完全绕过 DevPeek。
为什么中间人解密可能让少数请求失败？
开启 SSL 代理后，原本的一段 TLS 被拆成两段：
浏览器 / App
│
│ TLS：DevPeek 调试证书
▼
DevPeek
│
│ TLS：源站证书
▼
源站
多数浏览器和 App 在信任 DevPeek CA 后可以正常工作，但有些客户端或服务依赖更特殊的 TLS 行为。
1. 客户端做了证书固定
Certificate Pinning 不只检查系统是否信任证书，还会比对预置的证书、公钥或指纹。
即使 DevPeek CA 已加入系统信任，DevPeek 动态生成的调试证书也不会等于 App 内置的证书，因此客户端会主动拒绝连接。
这种情况在原生 App、支付 SDK、登录 SDK 和部分安全组件中更常见。把 Host 加入 Exclude 后，客户端重新直接与源站完成 TLS 握手，但对应流量也就无法解密。
2. 服务使用双向 TLS
普通 HTTPS 主要由服务器向客户端出示证书；mTLS 还要求客户端向服务器出示证书。
中间人解密会改变原始 TLS 会话边界，客户端证书挑战未必能按原方式完成。若当前任务不需要查看这部分明文，可以让相关 Host 走隧道。
3. 客户端或服务对 TLS 行为有特殊要求
少数实现会依赖特定 TLS 扩展、握手特征、连接复用方式或协议细节。经过中间人代理后，这些特征发生变化，客户端或服务器可能直接断开连接。
这种问题不一定有统一错误码。最可靠的判断仍然是对照测试：解密失败，隧道恢复。
4. 这部分流量本来就不需要明文
统计、广告、更新检查、静态 CDN 等背景流量即使可以解密，也可能只会增加列表噪声。
把它们排除既能减少干扰，也能避免不必要的 TLS 兼容问题。
在 DevPeek 中排除问题 Host
打开 DevPeek 的 SSL 代理配置。
左侧是 SSL 代理这些主机（Include），右侧是 跳过 SSL 代理（Exclude）。
假设 Include 是：
*
只有 secure-api.example.com 开启解密后失败，就在 Exclude 中加入：
secure-api.example.com
如果同一组子域都不需要解密，也可以写：
*.example.com
保存后，DevPeek 会断开相关旧连接。刷新页面或重新触发 App 请求，让客户端建立新的 CONNECT。
完成标准：
- 原来失败的网站或功能恢复；
- 请求显示为已跳过 SSL 代理；
- 该 Host 看不到 HTTPS 明文；
- 其它未排除的 Host 仍能正常解密。
Include / Exclude 的判断顺序
最终规则是：
做 SSL 代理
= SSL 已开启
&& 命中 Include
&& 未命中 Exclude
Include 和 Exclude 同时命中时，Exclude 优先。
例如 Include 是 *，Exclude 是 secure-api.example.com：
secure-api.example.com：CONNECT 隧道api.example.com：SSL 代理，可以查看明文static.other.com：SSL 代理，可以查看明文
排除名单写 *，相当于所有 HTTPS 都走隧道。DevPeek 会在保存前确认，避免误操作后整个抓包列表突然没有 HTTPS 明文。
规则只能写 Host，不能写 URL Path
下面这些可以匹配：
api.example.com
*.example.com
*api*
*
下面这些不可以：
https://api.example.com/login
api.example.com/v1/*
是否进行 SSL 代理，要在 HTTPS CONNECT 阶段决定。此时 /login、/v1/orders 等 URL Path 仍在 TLS 里面，DevPeek 还看不到，所以只能按 Host 等连接级信息选择解密或隧道。
不要把几种现象混在一起
DevPeek CA 不受信任
如果大量 HTTPS 都失败，浏览器提示 NET::ERR_CERT_AUTHORITY_INVALID，更可能是 CA 没有正确安装或信任。先检查证书，不要把所有域名逐个加入 Exclude。
源站证书异常，但网站和明文仍然可看
如果请求详情提示“源站证书与主机名不符”“源站证书已过期”或“源站证书不受信任”，但页面和 HTTPS 明文仍可查看，这是 DevPeek 主动保留的证书调试信息，并不属于本文的“解密后打不开”。
详见：源站证书与域名不匹配？DevPeek 为什么仍能正常抓包。
关闭 SSL 代理后仍然打不开
这说明故障不只发生在 HTTPS 解密阶段。继续检查系统代理、DNS、网络可达性、客户端是否支持 HTTP 代理，以及源站是否正常。
HTTPS 已经解密，但 JSON 还是密文
这属于应用层参数加密，可以使用参数转换处理，与 Exclude 无关。
为什么不自动在失败后改走隧道？
建立连接前，DevPeek 必须先决定是中间人解密还是 CONNECT 隧道。
一旦客户端已经和 DevPeek 开始 TLS 握手，原来的 ClientHello 就不能无损“倒带”并交回源站。更重要的是，仅凭连接失败无法准确判断用户是否愿意放弃明文：失败也可能来自临时网络波动、源站故障或正在调试的问题。
因此，DevPeek 不会把所有失败请求静默降级成隧道。是否跳过解密，由用户通过 Exclude 明确配置。
最终可以记住一句话
如果某个 Host 满足：
开启 SSL 代理 → 失败
跳过 SSL 代理 → 恢复
就把它加入 Exclude，让这部分流量走 CONNECT 隧道。不要为了少数不兼容请求关闭全部 HTTPS 解密。
下一篇
源站证书与域名不匹配？DevPeek 为什么仍能正常抓包——证书异常不一定要中断调试；看看 DevPeek 如何继续保留明文，同时把无法确认对端身份的风险明确展示出来。
如果你也遇到过“一开 SSL 代理，个别网站或 App 就失败”，可以下载 DevPeek为对应 Host 添加 Exclude；遇到难判断的代理兼容问题，也欢迎到 GitHub Discussions 交流。