为何禁用IIS中的SNI后网站恢复正常？

咱们先把事情的来龙去脉捋明白，你遇到的问题其实和SNI的工作逻辑、以及IIS的SSL站点配置规则直接相关：

• 先搞懂SNI到底是干嘛的：简单来说，SNI（Server Name Indication）是让IIS能在同一个IP+端口上托管多个带SSL证书网站的核心技术。当浏览器发起HTTPS请求时，会在SSL握手的第一步就把要访问的域名告诉服务器，服务器根据这个信息返回对应域名的Let's Encrypt证书，这样多个网站就能共用同一个IP资源了。
• 你的警告信息藏着关键原因：系统提示的“No default SSL site has been created”，意思是你的IIS里没有配置一个“兜底”的SSL站点。而当你开启了“Require Server Name Indication”选项时，IIS会严格要求每个HTTPS请求都必须携带SNI信息（也就是明确告知服务器要访问哪个域名）。如果遇到不支持SNI的老浏览器、或者某些没正确发送SNI的工具/设备，服务器就会陷入两难：不知道该返回哪个证书，直接导致SSL握手失败，网站自然就打不开了。
• 禁用SNI要求为啥能解决问题：当你关掉“Require Server Name Indication”之后，IIS就不再强制要求请求必须携带SNI信息了。这时候如果遇到没有SNI的请求，IIS会自动用当前这个站点的证书作为默认证书返回，SSL握手就能正常完成，网站也就恢复访问了。

这里额外提一句：如果你之后打算在同一个IP上部署多个SSL站点，最好还是配置一个默认SSL站点，不然可能出现证书不匹配的问题（比如用户访问A网站，却拿到了B网站的证书，浏览器会弹出安全警告）。但就你当前的场景来说，禁用SNI要求相当于让这个站点临时充当了默认站点的角色，直接解决了握手失败的核心问题。

备注：内容来源于stack exchange，提问作者Elias Robledo