接口调试新姿势
源站证书与域名不匹配？DevPeek 为什么仍能正常抓包
开着 SSL 代理访问一个网站，页面可以正常打开，请求头、请求体和响应内容也都能看到。
但 DevPeek 在请求列表中标记了这条请求，请求详情顶部还显示：
源站证书与主机名不符
点开源站证书后，可能会发现当前访问的是：
admin.shop-example.com
证书的 SAN（Subject Alternative Name）却只有：
*.cdn-host.cn
cdn-host.cn
这不是误报，也不代表 DevPeek CA 没有安装好。真正的问题是：源站返回的证书无法证明它就是当前访问的域名。
DevPeek 的选择不是静默忽略，也不是阻止你继续查看，而是：
- 继续完成到源站的 TLS 连接；
- 保留 HTTPS 解密和抓包能力；
- 检查并记录源站证书异常；
- 在请求列表和详情中明确提示风险；
- 允许查看当时保存的源站证书。
因为在调试场景里，证书问题本身也是需要观察和排查的信息。
先看懂 ERR_TLS_CERT_ALTNAME_INVALID
一张 HTTPS 证书会在 SAN 中列出它可以代表哪些域名。
例如：
访问 Host：admin.shop-example.com
证书 SAN：*.cdn-host.cn, cdn-host.cn
admin.shop-example.com 不在证书允许的域名范围内，因此标准的 TLS 主机名校验会得到：
ERR_TLS_CERT_ALTNAME_INVALID
它表达的不是“证书文件损坏”，而是：
我连接的是 A，但对方拿出了一张只属于 B 的证书，所以我无法确认对方身份。
这类问题常见于：
- CDN 或 WAF 绑定了错误证书
- 反向代理的 SNI 配置不正确
- DNS 指向了错误的服务
- 测试环境复用了其它环境的证书
- Map Route 或内部网络把请求导向了另一台服务器
- 源站直接使用了不覆盖当前域名的证书
如果 Host 末尾带有一个点，例如 admin.shop-example.com.，也值得一并检查。它是合法的 FQDN 写法，但少数代理、网关或 CDN 对这种形式处理不一致。
这和 DevPeek CA 不受信任不是一回事
SSL 代理会建立两段 TLS：
浏览器 / App
│
│ TLS：DevPeek 动态证书
▼
DevPeek
│
│ TLS：源站证书
▼
源站
第一段是客户端到 DevPeek。客户端需要信任 DevPeek CA，才能接受 DevPeek 动态签发的调试证书。
第二段是 DevPeek 到源站。这里看到的是源站真实返回的证书，也是本文讨论的问题所在。
如果第一段不受信任，浏览器通常会提示：
NET::ERR_CERT_AUTHORITY_INVALID
如果第二段的证书与访问 Host 不匹配，DevPeek 会标记：
源站证书与主机名不符
所以，看到源站证书不匹配时，反复重装 DevPeek CA 通常没有意义。两者处在不同的 TLS 连接上。
如果你还没有成功抓到第一个 HTTPS 请求，可以先看快速上手和代理与 SSL 证书。
为什么 DevPeek 没有直接中断请求？
浏览器、Node.js 或普通 HTTP 客户端在严格验证模式下，通常会把证书校验失败当成硬错误，并终止 TLS 连接。
这对日常上网是合理的默认行为，因为客户端无法确认连接的是否是真实服务。
但抓包工具面对的是调试场景。如果 DevPeek 也在发现异常后立即中断，会同时失去：
- 页面或接口的实际响应
- 请求与响应明文
- 源站返回的证书
- CDN、SNI、DNS 和转发结果
- 定位测试环境证书配置问题所需的上下文
因此 DevPeek 不把源站证书校验失败作为硬阻断，而是在完成连接后继续检查证书，并把异常与请求记录关联起来。
更准确地说，这不是“不校验证书”，而是：
执行检查，但不让检查失败直接打断调试；同时把风险明确暴露给开发者。
网站能打开，只能说明 TLS 连接和 HTTP 请求仍然完成了，并不代表源站证书是正确的。
在请求详情里能看到什么？
当 DevPeek 检测到源站证书异常时，请求详情顶部会显示对应提示，例如：
- 源站证书与主机名不符
- 源站证书已过期
- 源站证书不受信任
- 源站证书校验未通过
点击 查看源站证书，可以继续检查：
- Subject
- Issuer
- SAN
- 有效期
- 序列号
- SHA-1 / SHA-256 指纹
- PEM 原文
排查域名不匹配时，优先对照请求 Host 与 SAN。
例如请求 Host 是：
api.test.example.com
SAN 只有：
*.example.com
它们同样不匹配。通配符 *.example.com 只覆盖一层子域，例如 api.example.com，不能覆盖 api.test.example.com。
抓包列表中的证书标记可以帮助你先定位异常请求，再进入请求详情查看具体证书。
证书告警该怎么处理？
证书异常是否需要修复，取决于你正在调试什么。
场景一：测试环境证书配错了
DevPeek 可以让联调继续进行，但证书告警仍然说明配置存在问题。
建议检查：
- DNS 是否指向预期地址
- CDN / WAF 是否绑定了正确证书
- SNI 是否传递正确
- 证书 SAN 是否覆盖当前域名
- 反向代理是否返回了默认站点证书
- Map Route 是否把请求转到了另一套环境
DevPeek 的“继续查看”是为了保留调试现场，不是替源站证明安全。
场景二：你正在排查证书或网关问题
这正是保留请求和证书信息的价值。
可以同时对照：
- 请求里的 Host
- 实际连接的远端地址
- 源站证书 Subject 与 SAN
- 证书颁发者和有效期
- 转发规则是否生效
- 同一域名在不同网络下返回的证书是否一致
证书错误不再只是一个让请求消失的报错，而是完整调试链路的一部分。
场景三：这是生产环境或敏感数据
此时不要把“页面能打开”理解成“可以放心使用”。
证书校验异常意味着 DevPeek 无法确认真实对端身份。它可能只是测试环境配置错误，也可能是 DNS、代理链或网络中的异常节点。
在原因确认前，应避免提交密码、Token、支付信息等敏感数据。
这时需要加入「跳过 SSL 代理」吗？
源站证书与域名不匹配时，不需要为了让网站继续打开而自动加入排除名单。DevPeek 会保留明文并显示告警，方便继续排查。
如果改成 CONNECT 隧道，证书验证会重新交给浏览器或 App。源站证书确实不匹配时，严格校验的客户端很可能会自行阻止访问。
Exclude 更适合这些情况：
- 开启 HTTPS 解密后请求失败，改走隧道才恢复；
- 客户端使用证书固定，无法接受调试证书；
- 某些流量不需要查看明文；
- 希望让客户端直接执行端到端证书验证。
这种“解密后打不开”的情况，详见：开了 SSL 抓包，有些网站反而打不开？把域名加进「跳过 SSL 代理」。
不要把 TLS 与应用层加密混在一起
HTTPS 已经成功解密后，JSON 里仍可能是：
{
"data": "7a3f..."
}
这不是证书或 SSL 代理问题，而是业务在 HTTPS 之上又做了一层 AES、RSA、Base64 或自定义编码。
这类内容可以继续使用参数转换处理。TLS 解决传输层加密，参数转换处理应用层数据，两者不是同一层问题。
最终可以记住这三点
第一，源站证书与 Host 不匹配，说明 DevPeek 无法确认对端身份，告警本身是真实有效的。
第二，DevPeek 不会静默吞掉这个问题，也不会默认中断调试；网站和 HTTPS 明文仍可查看，请求详情会保留证书异常。
第三，Exclude 是控制哪些域名不解密的工具，不是遇到证书错误后的必选修复。真正需要解决的，仍然是源站证书、DNS、SNI、CDN 或转发配置。
下一篇
这是「接口调试新姿势」系列当前最后一篇。你可以继续查看博客列表，或回到抓包界面与请求详情了解请求分析功能。
如果你正在排查测试环境证书、CDN 或 SNI 问题，可以下载 DevPeek保留完整请求与源站证书现场；遇到特殊案例，也欢迎到 GitHub Discussions 交流。