粗心大意必酿大祸，记录 nginx 配置文件的一次闹剧
一次域名配置引发的 Nginx 配置问题：HTTPS 与 server_name 的踩坑记录
在最近的项目维护中，我新增了一个域名 bugfix.wiki，计划将其解析到现有的网站上，与之前使用的 bugshare.cn 一样，通过 Nginx 实现完整的 HTTP/HTTPS 跳转逻辑。
域名备案、DNS、SSL 证书均已配置完毕，本以为只需复制一份现有配置即可。结果上线后却发现：bugfix.wiki 无法正常访问，而 bugshare.cn 却完全正常。
问题的根源最终被定位在一个非常细微但关键的 Nginx 配置点上。这里记录整个过程，供日后参考，也供遇到相同问题的同学排查。
1. 预期目标
对两个域名（bugshare.cn、bugfix.wiki）都希望实现如下行为：
即：
全站 HTTPS
全站强制“带 WWW”
所有 HTTP 统一跳转到 HTTPS
2. 初始配置（bugshare.cn）——正常工作
bugshare.cn 的配置如下，可以正常运行：
注意：该配置虽然也存在优化空间，但在实际场景中运行完全正常。
3. 为 bugfix.wiki 复制一份配置后 —— 访问异常
为新域名复制后：
访问现象：
https://www.bugfix.wiki → 报错「该网页无法正常运作」
表面上跳转逻辑没问题，但最终 HTTPS 访问失败。
4. 问题定位：未将 www.bugfix.wiki 写入 HTTPS server_name
导致报错的关键配置问题：
缺少了：
为什么这是致命错误？
Nginx 在处理 HTTPS 时，会根据 SNI（Server Name Indication） 判断应该使用哪个 server 块及对应的 SSL 证书。
当访问 https://www.bugfix.wiki 时：
浏览器会发送 TLS ClientHello，附带 SNI：
www.bugfix.wikiNginx 根据
server_name匹配 server 块此时配置中没有匹配
www.bugfix.wiki的 443 serverNginx fallback 到默认的 443 server（通常是第一个匹配到的）
返回了不匹配的 SSL 证书 → 浏览器报错
现象表现为“网页无法正常运作”，实际是 SSL 证书不匹配导致连接被拒绝。
5. 修复后的正确配置
重启 Nginx：
问题即刻解决，所有访问路径完全正常。
6. 技术总结（关键要点）
✔ 1. server_name 必须覆盖 HTTPS 下的所有访问域名
尤其是：
主域名（Apex domain）
带 www
子域名（如有）
否则 SNI 匹配失败，证书无法正确绑定。
✔ 2. Nginx 的域名匹配与“回源域名”无关
即使使用了 Cloudflare 等代理平台，只要请求最终到达 Nginx，SNI 匹配仍完全依赖 Nginx 的 server_name。
✔ 3. HTTPS 的 server 块一定比 HTTP 更严格
HTTP 没有 SNI，匹配宽松得多；HTTPS 要求精确匹配 server_name，否则证书直接错乱。
✔ 4. 强烈建议使用统一跳转逻辑的最佳实践：
避免遗漏。
甚至可以进一步做：
但需要根据实际情况决定。
7. 后记
整个问题看似隐蔽，其实本质是：
HTTPS server_name 少写了一个域名，导致 SNI 匹配失败。
属于 Nginx 配置中非常常见但又不容易第一时间想到的坑。
像这种“复制配置”场景，非常容易疏忽，提醒自己与大家：
复制配置永远不能无脑复制，尤其是 SSL 相关的 server 块。检查、检查、再检查。
版权声明: 本文为 InfoQ 作者【BugShare】的原创文章。
原文链接:【http://xie.infoq.cn/article/3774349a5c0763ec34a707e9b】。文章转载请联系作者。
BugShare，解决问题，快乐摸鱼 2025-10-18 加入
领先的bug分享，致力于愉快开发，快乐摸鱼，决绝996。
评论