一、事故背景：全站HTTPS改造的标准化需求

在Web服务安全加固过程中，全站HTTPS改造已成为行业标配。某技术团队在为两个业务域名实施改造时，采用复制粘贴的配置方式导致服务异常，暴露出配置管理中的典型风险。本次改造的核心需求包含：

协议强制升级：所有HTTP请求自动跳转至HTTPS
域名标准化：统一添加www前缀（如example.com→www.example.com）
证书合规性：确保证书链完整且与域名匹配
静态资源优化：对HTML文件设置缓存控制策略

二、成功配置模板解析：bugshare.cn的规范实现

首个域名的配置采用分层设计，包含HTTP重定向和HTTPS服务两个核心模块：

1. HTTP强制跳转配置

server {
    listen 80;
    listen [::]:80;
    server_name bugshare.cn www.bugshare.cn;
    return 301 https://www.bugshare.cn$request_uri;
}

该配置实现：

双栈监听（IPv4+IPv6）
覆盖主域名和带www子域名
永久重定向（301状态码）
保留原始请求路径

2. HTTPS服务配置

server {
    listen 443 ssl;
    server_name bugshare.cn;  # 关键配置点
    ssl_certificate /etc/nginx/conf.d/cert/bugshare.cn.pem;
    ssl_certificate_key /etc/nginx/conf.d/cert/bugshare.cn.key;
    if ($host = 'bugshare.cn') {
        return 301 https://www.bugshare.cn$request_uri;
    }
    location / {
        root /usr/local/nginx/html/dist;
        if ($uri = '/index.html') {
            add_header Cache-Control "no-cache, no-store, must-revalidate";
        }
        try_files $uri $uri/ /index.html;
    }
}

关键设计要素：

证书路径管理：采用绝对路径避免解析错误
主机头校验：通过$host变量实现精确匹配
缓存策略：对动态生成的index.html禁用缓存
路由回退：try_files实现SPA应用的路由支持

三、事故复现：配置复制引发的连锁反应

当为第二个域名bugfix.wiki复制配置时，技术人员直接修改了证书路径和域名信息，但遗漏了server_name指令的同步更新：

1. 错误配置片段

server {
    listen 443 ssl;
    server_name bugfix.wiki;  # ← 问题根源
    # 其余配置正确...
}

2. 异常现象分析

证书不匹配警告：浏览器显示ERR_SSL_VERSION_OR_CIPHER_MISMATCH
重定向循环：部分请求陷入HTTP→HTTPS→HTTP的无限跳转
服务不可用：约30%的请求返回502错误

3. 根本原因定位

通过抓包分析发现：

当访问https://bugfix.wiki时，服务器返回的证书是针对www.bugfix.wiki签发的
由于server_name未包含www.bugfix.wiki，Nginx无法正确匹配证书
浏览器检测到证书与域名不匹配，主动终止连接

四、系统化解决方案：配置检查清单

为避免类似问题，建议建立三级验证机制：

1. 语法检查层

nginx -t -c /etc/nginx/nginx.conf

必须确认输出包含：

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

2. 逻辑验证层

检查项	验证方法	预期结果
证书匹配	`openssl x509 -in cert.pem -noout -subject`	包含目标域名
重定向链	`curl -v http://domain`	最终URL为https://www.domain
主机头处理	`curl -H "Host: domain" https://server_ip`	返回301重定向

3. 生产环境验证

灰度发布：先对10%流量开放新配置
监控告警：设置SSL证书过期、重定向失败等关键指标
日志分析：实时监控error.log中的SSL相关错误

五、最佳实践建议

1. 配置模板化

建议采用包含变量替换的模板文件：

# config_template.conf
server {
    listen 443 ssl;
    server_name ${DOMAIN} www.${DOMAIN};
    ssl_certificate /etc/nginx/certs/${DOMAIN}.pem;
    ssl_certificate_key /etc/nginx/certs/${DOMAIN}.key;
    # 其余配置...
}

通过脚本实现批量部署：

DOMAIN=bugfix.wiki envsubst < config_template.conf > /etc/nginx/conf.d/bugfix.wiki.conf

2. 自动化测试

构建包含以下场景的测试套件：

裸域名访问（HTTP/HTTPS）
带www子域名访问
非法域名访问
证书过期模拟测试

3. 变更管理流程

配置修改必须通过Git进行版本控制
每次变更需附带影响范围评估
建立回滚预案，确保可在5分钟内恢复服务

六、总结与启示

本次事故暴露出三个典型问题：

配置复制风险：机械复制导致关键参数遗漏
测试覆盖不足：缺乏对证书匹配性的专项验证
监控盲区：未及时发现SSL握手失败事件

建议运维团队建立：

配置项清单管理制度
自动化验证流水线
故障演练机制

通过系统化的配置管理，可将类似事故的发生概率降低90%以上。在实施全站HTTPS改造时，务必重视每个域名的证书-域名映射关系，这是保障服务可用性的基础前提。

Nginx配置疏忽引发的生产事故：一次全站HTTPS改造的深度复盘