一、为什么HTTPS握手会失败？一个被忽视的环节：SNI
验证与回滚
如果你正在处理CDN HTTPS，先别急着照搬网上的参数。当你为网站部署了CDN并开启全站HTTPS后，绝大多数情况下访问是正常的。但有时你会收到报错——“ERR_SSL_UNRECOGNIZED_NAME_ALERT”或“SSL handshake failed”。第一反应往往是证书问题，可证书明明配置正确。问题很可能出在SNI（Server Name Indication，服务器名称指示）上。
简单说，SNI是TLS协议的一个扩展，它允许客户端（比如浏览器）在握手的第一步就告诉服务器：“我要访问的是 www.example.com，请给我对应的证书。” 如果没有SNI，服务器（尤其是共享IP的服务器）就不知道应该展示哪个站点的证书。
在CDN全站HTTPS场景下，流量经过CDN节点，而CDN节点通常用同一个IP承载成百上千个域名。这时，SNI的正确传递就成了握手成功的必要条件。一旦SNI不匹配，握手就会失败。
二、SNI不匹配的典型场景
1. 客户端不支持SNI（老系统或特殊库）
SNI从2003年提出，至今几乎所有现代浏览器（Chrome、Firefox、Safari等）都支持。但仍有少数陈旧环境——例如Windows XP上的IE6、某些嵌入式设备、过时的HTTP库——不支持SNI。它们发起TLS连接时不会携带SNI字段。CDN节点收到这样的ClientHello，无法确定该返回哪个证书，于是默认可能返回默认证书（不匹配），或者直接拒绝连接。
2. CDN回源时SNI丢失或错误
用户请求到达CDN节点后，CDN需要回源站获取数据。如果CDN配置了回源SNI，但填写的域名错误（例如写成了源站IP或泛域名未匹配），源站服务器收到TLS握手请求时，会因SNI不匹配而拒绝连接。此外，某些CDN默认不开启回源SNI，或者源站未正确配置支持SNI的证书，也会导致回源握手失败。
3. 多域名共用IP且证书配置遗漏
你购买了CDN服务，配置了www.example.com和m.example.com两个域名，但只给前者绑定了证书。当用户通过HTTPS访问m.example.com时，CDN节点根据SNI查询不到匹配的证书，就会返回默认证书或报错。
4. 中间设备（代理、防火墙）篡改SNI
企业内部网络或某些ISP的透明代理，可能在TCP层拦截HTTPS流量并修改SNI字段。如果修改后的SNI与真实域名不一致，CDN节点收到的SNI是伪造的，自然无法完成证书匹配。
相关阅读：此处可内链到“CDN HTTPS常见问题”专题。
三、如何诊断SNI不匹配造成的握手失败？
诊断需要工具和步骤，下面提供几个小白也能操作的方法。
方法1：使用浏览器开发者工具
- 打开Chrome浏览器，按F12进入开发者工具，切换到“Security”标签页。
- 在地址栏输入你的HTTPS网址，观察安全连接详情。
- 如果显示“Certificate error”或“Connection refused”，可以点击“View certificate”查看证书是否匹配域名。
- 在“Network”标签页，找到第一个请求，查看Headers，如果出现“ERR_SSL_UNRECOGNIZED_NAME_ALERT”，基本可以判定是SNI问题。
方法2：使用OpenSSL命令行（更精确）
如果你有服务器或本地终端，可以用OpenSSL模拟TLS握手并指定SNI：
openssl s_client -connect your-domain.com:443 -servername your-domain.com如果握手成功，你会看到“SSL handshake has read …”以及服务器证书链。如果出现“unrecognized name”或“SSL3_GET_SERVER_CERTIFICATE:certificate verify failed”，说明SNI不匹配。
你可以修改-servername参数，填写不同的域名（比如把www.example.com改成example.com），观察是否能正常握手。若修改后成功，则证明原SNI配置错误。
方法3：使用curl命令（推荐）
curl支持通过--resolve和--cacert参数模拟指定IP的SNI请求：
curl -v --resolve your-domain.com:443:CDN-IP https://your-domain.com/观察输出中的“Trying …”“Connected to …”“SSL connection using …”以及“Server certificate”信息。如果curl报“SSL certificate problem: unable to get local issuer certificate”但证书实际有效，往往也是SNI引起的。
关联教程：此处可内链到“CDN HTTPS部署与验证”内容。
CDN HTTPS：四、常见解决方案
1. 确认CDN节点已正确配置域名与证书绑定
登录你的CDN控制台，检查每个加速域名是否都关联了对应的SSL证书。不要依赖“默认证书”或“泛域名证书”，最好为每个确切域名（包括www和根域名）单独绑定证书，或者使用支持多SAN（Subject Alternative Name）的证书。如果你使用的是GoEdge等支持SNI管理的CDN系统，确保SNI与回源Host一致。
2. 正确配置CDN回源SNI
CDN回源阶段也需要SNI。在CDN控制台找到“回源配置”，找到“回源SNI”或“回源HOST”字段，将其设置为你的源站域名（而非IP）。例如源站是origin.example.com，则回源SNI应填origin.example.com，源站服务器必须持有匹配的证书。如果不确定，可以查看CDN文档或联系技术支持。
3. 为老旧客户端提供降级方案
如果确认是客户端不支持SNI（例如某些智能家居设备），可尝试以下方式：
- 为这些设备分配独立的CDN节点或边缘服务器，且该节点上只托管一个域名（避免SNI冲突）。
- 使用IP-based的HTTPS，即为该域名分配独立IP（需要额外付费）。
- 考虑在老旧设备上更新HTTP库或系统。
4. 检查中间设备是否修改SNI
在企业网络环境下，可以尝试使用4G手机热点，排除公司代理干扰。如果热点下访问正常，而公司网络下失败，那么问题很可能出在中间设备。请联系网络管理员，检查防火墙或代理是否启用了SSL拦截并错误地修改了SNI。建议在白名单中放过你的域名，或关闭不必要的深度包检测。
5. 验证证书链的完整性与证书颁发机构
虽然SNI不匹配与证书本身无直接关系，但有时服务器配置了错误的证书链也会导致握手阶段拒绝。使用上述openssl命令检查完整证书链，确保CDN节点返回的证书链正确。如果CDN节点缓存了旧证书，可尝试清除CDN缓存或刷新证书。
五、预防：建立SNI最佳实践——CDN HTTPS
验证与回滚
- 证书管理规范化：为每个CDN域名单独申请证书（可使用ACM或自动续签工具），避免混用。
- 配置CDN回源SNI映射表：如果源站有多个虚拟主机，确保回源SNI与源站上的ServerName一一对应。
- 监控TLS握手错误率：在CDN监控面板中关注“SSL握手失败”指标，设置告警。
- 定期测试：每次修改CDN配置后，使用openssl或curl从不同地理位置测试，确保所有域名都能正常握手。
补充参考：此处可内链到“CDN HTTPS故障排查实例”。
六、总结
我的处理经验
SNI不匹配是CDN全站HTTPS部署中常见但容易被忽视的问题。它的本质是TLS握手时域名信息没有正确传递给服务器。只要理解SNI的工作原理，并掌握openssl、curl等诊断工具，你可以在几分钟内定位问题。大多数场景下，通过正确绑定证书、配置回源SNI、升级老旧客户端，即可彻底解决。
如果你在排查中遇到复杂情况（例如CDN节点间不一致、多个CDN提供商叠加），欢迎参考我们的CDN故障排查系列文章，或直接与技术支持沟通。记住：SNI不是深奥的黑盒，它只是HTTPS握手时的那一句“你是谁”。把这些步骤跑通后，CDN HTTPS基本就能稳定落地。
延伸阅读