我之前也踩过这个SSL证书的坑！尤其是在聊天应用、多人浏览器游戏这类需要多节点部署的场景下，用IP直接访问服务器就触发证书错误，换成域名就正常，本质是浏览器的SSL校验逻辑在起作用。

为什么会出现这个错误？ #

SSL证书是和域名/特定IP绑定的，证书里的Subject Alternative Name（SAN）（现在主流浏览器主要看这个字段，旧的Common Name已经逐渐被替代）会记录证书合法的访问地址。当你用IP访问时，浏览器会对比当前访问的IP和证书里的SAN/Common Name是否匹配——如果IP不在证书的合法列表里，就会抛出ERR_CERT_COMMON_NAME_INVALID错误，其他浏览器的类似错误也是同一个原因。

可行的解决办法 #

1. 给SSL证书添加服务器IP到SAN字段 #

如果你的应用必须让用户通过IP访问，可以把服务器IP加入证书的SAN列表：

• 自签名证书：生成证书时用openssl命令指定IP，示例：

  openssl req -x509 -newkey rsa:4096 -keyout server-key.pem -out server-cert.pem -days 365 -nodes -addext "subjectAltName=IP:192.168.1.10,IP:10.0.0.20"
  

  把命令里的IP替换成你的实际服务器IP即可，多个IP用逗号分隔。
• 商业证书：联系证书服务商，申请将服务器IP添加到证书的SAN字段中，现在大部分主流证书支持添加多个IP或域名。

2. 用子域名映射每个服务器IP #

这是更推荐的方案，比直接用IP更灵活友好：

• 给每个服务器分配一个子域名，比如server1.yourdomain.com、server2.yourdomain.com，然后将这些子域名解析到对应的服务器IP。
• 申请包含所有子域名的SSL证书：可以用通配符证书（比如*.yourdomain.com，适配所有子域名），或者多域名证书（指定具体的子域名列表）。
• 用户通过子域名访问服务器，浏览器会校验子域名和证书匹配，不会出现错误，后续服务器IP变更也只需要修改DNS解析，不用调整客户端配置。

3. 用反向代理统一访问入口 #

如果你的应用不需要用户直接访问单个服务器（比如聊天应用的消息转发由代理统一处理），可以用反向代理做统一入口：

• 部署Nginx、Cloudflare等反向代理服务，用户只通过主域名（比如yourdomain.com）访问代理。
• 代理服务器配置好域名对应的SSL证书，后端服务器和代理之间的通信可以用内网证书甚至HTTP（仅限内网环境），不用暴露给用户。
• 这种方式不仅解决了证书问题，还能做负载均衡、流量控制等额外优化。

注意事项 #

• 自签名证书需要用户手动在浏览器中信任，适合测试环境；生产环境建议使用受信任的商业证书。
• 现在Chrome等主流浏览器优先校验SAN字段，即使证书的Common Name填了IP，如果SAN里没有，还是会报错，所以一定要确保SAN字段包含所有合法的访问地址。

内容的提问来源于stack exchange，提问作者Ronnie Goodrich