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

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;
    }
}

注意：该配置虽然也存在优化空间，但在实际场景中运行完全正常。

3. 为 bugfix.wiki 复制一份配置后 —— 访问异常

为新域名复制后：

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

server {
    listen 443 ssl;
    server_name bugfix.wiki;   # ← 问题所在

    ssl_certificate     /etc/nginx/conf.d/cert/bugfix.wiki.pem;
    ssl_certificate_key /etc/nginx/conf.d/cert/bugfix.wiki.key;

    if ($host = 'bugfix.wiki') {
        return 301 https://www.bugfix.wiki$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;
    }
}

访问现象：

http://bugfix.wiki → 正常跳到 https://www.bugfix.wiki
https://bugfix.wiki → 正常跳到 https://www.bugfix.wiki
https://www.bugfix.wiki → 报错「该网页无法正常运作」

表面上跳转逻辑没问题，但最终 HTTPS 访问失败。

4. 问题定位：未将 www.bugfix.wiki 写入 HTTPS server_name

导致报错的关键配置问题：

server_name bugfix.wiki;

缺少了：

www.bugfix.wiki

为什么这是致命错误？

Nginx 在处理 HTTPS 时，会根据 SNI（Server Name Indication） 判断应该使用哪个 server 块及对应的 SSL 证书。

当访问 https://www.bugfix.wiki 时：

浏览器会发送 TLS ClientHello，附带 SNI：www.bugfix.wiki
Nginx 根据 server_name 匹配 server 块
此时配置中没有匹配 www.bugfix.wiki 的 443 server
Nginx fallback 到默认的 443 server（通常是第一个匹配到的）
返回了不匹配的 SSL 证书 → 浏览器报错

现象表现为“网页无法正常运作”，实际是 SSL 证书不匹配导致连接被拒绝。

5. 修复后的正确配置

server {
    listen 443 ssl;
    server_name bugfix.wiki www.bugfix.wiki;

    ssl_certificate     /etc/nginx/conf.d/cert/bugfix.wiki.pem;
    ssl_certificate_key /etc/nginx/conf.d/cert/bugfix.wiki.key;

    if ($host = 'bugfix.wiki') {
        return 301 https://www.bugfix.wiki$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;
    }
}

重启 Nginx：

nginx -s reload

问题即刻解决，所有访问路径完全正常。

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. 强烈建议使用统一跳转逻辑的最佳实践：

server_name bugfix.wiki www.bugfix.wiki;

避免遗漏。

甚至可以进一步做：

server_name .bugfix.wiki;

但需要根据实际情况决定。

7. 后记

整个问题看似隐蔽，其实本质是：

HTTPS server_name 少写了一个域名，导致 SNI 匹配失败。

属于 Nginx 配置中非常常见但又不容易第一时间想到的坑。

像这种“复制配置”场景，非常容易疏忽，提醒自己与大家：

复制配置永远不能无脑复制，尤其是 SSL 相关的 server 块。检查、检查、再检查。

BugShare

粗心大意必酿大祸，记录nginx配置文件的一次闹剧

一次域名配置引发的 Nginx 配置问题：HTTPS 与 server_name 的踩坑记录

1. 预期目标

2. 初始配置（bugshare.cn）——正常工作