hostname does not match certificate：证书主机名不匹配的排查
hostname does not match certificate严重程度 High对方出示的证书本身有效，但它保护的域名列表里不包含你正在访问的主机名——就像出示了别人的有效证件。最可能是通过 IP 或备用域名访问了只签给主域名的证书，或服务端 SNI 配置返回了默认站点的证书；第一步是查看证书实际包含的域名列表。
结论
这条错误与"证书无效"是两回事：证书链完整、没过期、由可信机构签发——唯独名字对不上。你访问 a.example.com，证书却说自己保护的是 b.example.net。校验器拒绝是完全正确的：名字对不上意味着无法确认对面就是你想连的那个服务。而"名字为什么对不上"通常是配置层面的错位，证据一看便知。
适用环境
- 全部平台
- 高发场景：IP 直连、CDN/反代多站点共存、客户端自定义 SNI/伪装域名
一分钟快速判断
connproof tls 目标 --port 443 --insecure-test诊断模式会列出证书实际覆盖的域名（subjectAltName 列表）。对照三问：
- 你访问的名字在列表里吗？ 不在 → 继续；
- 列表里是什么？ 是同服务器上另一个站点的域名 → SNI/默认站点错位；是服务方的主域 → 你用了未覆盖的子域或 IP；是陌生名字 → 警惕替换，换网络对比；
- 你是用 IP 连的吗？ 绝大多数证书只签域名不签 IP，IP 直连必然名字不匹配——改用域名访问即可。
这条错误代表什么
TLS 校验主机名的依据是证书的 subjectAltName（SAN）列表，匹配规则严格：example.com 的证书不自动覆盖 www.example.com，通配符 *.example.com 覆盖一级子域但不覆盖 a.b.example.com，IP 地址必须以 IP 形式单独列入 SAN。因此错误的来源五花八门却都指向同一类事实——请求的名字与部署的证书没有正确配对：
- 客户端用 IP 或备用域名访问了只签主域的证书；
- 服务器上多站点共存，SNI 没送对或服务端没配对，返回了默认站点的证书；
- CDN 回源配置错误，边缘节点拿了错误的证书；
- 客户端配置里的 SNI/伪装域名与实际证书对不上（代理场景高发：
servername字段写错一个字母）。
ConnProof 如何判断
标准检测按安全默认拒绝并归类为 TLS-004；诊断模式补充关键证据：证书 SAN 列表、你请求的 servername、两者的匹配结论。把"我请求的名字"和"证书覆盖的名字"并排放在报告里，错位一目了然。
最常见原因
- IP 直连：改用域名即愈；
- 客户端 SNI/伪装域名配置错误：与服务方给的配置逐字段核对；
- 服务端 SNI 配置缺失：新加的域名没绑定证书，落到默认站点；
- 通配符覆盖不到：多级子域超出
*.的范围； - 中间人替换：证据是陌生域名的证书，换网络对比确认。
Windows / macOS / Linux 排查步骤
用户侧：
- 诊断模式取 SAN 列表；
- IP 直连场景改用域名；代理客户端场景逐字核对 SNI 字段；
- SAN 列表是陌生名字时，换网络对比证书内容——两个网络证书不同按证书替换处理。
服务维护者侧：
- 确认每个域名都绑定了覆盖它的证书（含 www 与裸域两个变体）；
- 多站点服务器检查 SNI 配置：没有匹配 server_name 的请求会拿到默认站点证书，这正是用户看到"别人家证书"的原因；
- 证书续期或迁移后，用
connproof tls 每个域名逐个回归——漏绑一个域名的事故通常发生在这时。
手机端排查步骤
- 手机客户端的"跳过证书验证"开关是这类错误的常见"临时方案"，请把它当作最后手段并尽快关回——先按上文核对 SNI 配置；
- 用桌面 ConnProof 取 SAN 证据，手机端仅做配置修正。
如何区分本地问题和节点问题
| 证据 | 更可能是 |
|---|---|
| 用 IP 访问 | 本地用法（改域名） |
| SNI 字段与服务方配置不一致 | 本地配置抄写 |
| 证书是同服务器另一站点的 | 服务端 SNI/默认站点配置 |
| 证书是陌生域名且随网络变化 | 链路替换（安全事件级别） |
| 服务方刚换过证书 | 服务端部署遗漏 |
通配符证书的覆盖范围速查
因为通配符规则引发的"以为覆盖了其实没有"占这类错误的相当比例，把规则说透很值得：*.example.com 只匹配恰好一级的子域——api.example.com 在覆盖内，example.com 本身不在（裸域需要单独列入 SAN），v2.api.example.com 也不在（两级子域超出范围）。所以一张规范的通配符证书 SAN 里通常同时列着 *.example.com 和 example.com 两条；而当业务用到 a.b.example.com 形式的多级子域时，要么为 *.b.example.com 再签一张，要么把具体域名逐条列入。用户侧的启示：看到 SAN 里有通配符不要立刻下"应该覆盖了"的结论，把你访问的完整主机名按上述规则严格比对一遍——差一级就是不匹配，校验器不讲人情。服务方新增子域层级后忘记扩证书，是这类错误在"昨天还好好的"场景下突然出现的最常见剧情。
仍未解决时收集什么信息
- ConnProof 错误码（TLS-004）与脱敏报告；
- 证书 SAN 列表与你请求的主机名（两条并列即可说明问题）；
- 客户端名称和版本、配置中 SNI 相关字段的核对结论；
- 换网络对比结果。
禁止提交：完整订阅链接、密码、验证码、私钥、Token。
重新运行检测
connproof tls 目标域名 --port 443 --format markdown --output tls-report.md修复后标准检测应通过，证书主机名匹配证据为"匹配"。
相关文档
更新记录
- 2026-07-28：规则 v1 发布，确立"请求名 vs SAN 列表"并列取证法。