网站域名能正常访问，改成服务器IP却提示证书不匹配，不一定是证书失效。同一个IP可以承载多个域名，TLS握手时用哪个名称选证书、客户端拿什么名称验证证书，都影响结果。排查时要保留原本要访问的域名。

先按业务域名做SSL检测

打开SSL检测，输入实际使用的域名，点击“立即检测”。本次用公开域名 www.baidu.com 演示，不修改DNS或服务器配置。

按完整业务域名发起SSL检测
按完整业务域名发起SSL检测

本次证书信息显示通用名称为 baidu.com，信任状态为可信，“启用SNI”为是，备用名称中包括 *.baidu.com 等多个域名。访问名称是否匹配，应核对证书的SAN，也就是页面里的备用名称；不能只看通用名称和地址栏是不是逐字相同。

证书信息列出SNI状态与备用名称，匹配应结合SAN判断
证书信息列出SNI状态与备用名称，匹配应结合SAN判断

域名标识和IP标识的匹配方式不同。证书覆盖某个域名，不代表覆盖这个域名当前解析到的所有IP。直接访问IP时，需要证书中相应的 iPAddress 类型SAN与该IP匹配，不能拿一个看起来相近的DNS名称代替。

可信证书也要匹配访问名称

工具下方还展示了本次证书链，并提示完整且受信任。这回答了信任关系的一部分，但没有承诺任何人把网址换成IP后都能通过验证。信任链成立、证书未过期、访问名称匹配，需要一起满足。

本次域名报告中的信任链；链可信不能替代IP名称匹配
本次域名报告中的信任链；链可信不能替代IP名称匹配

SNI是TLS客户端在握手中发送的服务器名称信息，服务器可以用它为同一IP上的不同站点选择证书。它出现在HTTP请求之前；只修改HTTP的 Host 请求头，不能保证此前的TLS握手就使用了相同域名。SNI的host_name使用DNS主机名，不把IPv4或IPv6字面量作为这种主机名发送。

在同一IP上保留域名作对照

为补充说明，本次另外从本地解析得到一个公开地址 111.45.11.5，用curl做两次请求。下面是本地客户端视角，与平台SSL报告分别记录；这个IP只是当时解析结果，不建议把它长期写死。

第一条指定连接地址，同时保留URL里的域名：

curl --noproxy '*' --connect-timeout 10 --max-time 15 \
  --resolve www.baidu.com:443:111.45.11.5 \
  -I https://www.baidu.com/

本次返回HTTP 200，命令退出0。--resolve 改变这一主机和端口对应的连接地址，URL名称仍然用于SNI、证书名称验证和HTTP主机信息。它适合在迁移或指定入口验证时保留真实业务名称。

第二条直接把URL改成IP：

curl --noproxy '*' --connect-timeout 10 --max-time 15 \
  -I https://111.45.11.5/

本次curl退出60，明确提示没有备用证书名称与目标IPv4地址匹配，未取得HTTP响应。这组对照没有关闭证书验证，能够证实本地直接IP访问在名称匹配阶段失败。它同时改变了URL名称及SNI行为，所以不能进一步夸成“已证明服务器不带SNI就完全无法握手”。

迁移验证时保留三个条件

实际验证新服务器，先保留要服务的域名，再确认连接到的IP，最后检查返回证书是否覆盖该域名。浏览器报错时，也先区分名称不符、过期、链不受信任等具体原因，避免看到“证书错误”就反复续签。

当前SSL检测按输入域名取得对应报告；要比较指定IP入口，可在受控客户端用保留验证的方式补查。不要为了让直接IP的页面打开就跳过证书验证，也不要把本地一次200扩展为所有地区都已切到新IP。修改配置后仍应按原业务域名复测，确认名称、连接目标和实际部署版本都对应得上。