Nginx 全站 HTTPS 上线用 Certbot 签发证书，一次切换对外域名到 443

STEP 01域名清单：对外与内部的边界

先把域名按「是否对外公开」分成两类。只有对外公开的域名才需要证书与 443 块；内部管理域名继续走 80，避免把管理面板暴露到公网 HTTPS 的证书与端口管理里。

对外公开（启用 HTTPS，80 → 301 跳转 443）

内部管理（保持 80，不上 HTTPS）

分类原则：能公开访问的域名才需要加密与证书；内部运维面板走内网或由 IP 白名单保护，不必占用 Let's Encrypt 的证书名额。

STEP 02本次配置改动

改动集中在五点：对外域名加 443 块、反代透传协议、修复语法 bug、清理无效写法、移除废弃的 juejin 配置。

1. 新增 443 ssl 块 + 80→301：每个对外域名新增 listen 443 ssl 块，原 80 块改为 return 301 https://$host$request_uri;。
2. 透传协议头：反向代理新增 proxy_set_header X-Forwarded-Proto $scheme;，后端据此判断协议，用于生成 https 链接与 secure cookie。
3. 修复语法 bug：原配置 server_name api.sparrowzoo.com 缺少分号，会让 nginx -t 直接失败。
4. 清理无效写法：index /; → index index.html;、charset utf_8; → charset utf-8;、移除对 proxy_pass 无意义的 fastcgi_intercept_errors on;。
5. 移除 juejin 配置：删除 juejin 相关的 upstream 与 server 块。

静态站点：80→301 + 443 ssl

# 80：统一重定向到 HTTPS
server {
    listen 80;
    server_name passport.sparrowzoo.com;
    return 301 https://$host$request_uri;
}

# 443：静态站点
server {
    listen 443 ssl;
    server_name passport.sparrowzoo.com;

    ssl_certificate     /etc/letsencrypt/live/passport.sparrowzoo.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/passport.sparrowzoo.com/privkey.pem;

    root /path/to/passport;
    index index.html;
    charset utf-8;

    location / {
        try_files $uri $uri/ /index.html;
    }
}

反向代理 + WebSocket：透传协议头

server {
    listen 80;
    server_name api.sparrowzoo.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name api.sparrowzoo.com;

    ssl_certificate     /etc/letsencrypt/live/api.sparrowzoo.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.sparrowzoo.com/privkey.pem;

    location / {
        proxy_pass http://api;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    # WebSocket 升级
    location /websocket {
        proxy_pass http://websocket;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

证书路径由 Certbot 统一放在 /etc/letsencrypt/live/<域名>/ 下，fullchain.pem 是证书链、privkey.pem 是私钥。覆盖配置前要确认这些路径与实际签发目录一致。

STEP 03上线步骤：先签证书，再覆盖配置

整个过程七步，核心原则是证书在前、配置在后，每一步都有明确的验证点。

第 1 步 · 备份现网配置

sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak-$(date +%F)

备份带日期后缀，出问题可以一键还原。

第 2 步 · 确认 DNS 与 80 端口

所有待签发域名的 A 记录需指向本服务器，且 80 端口对外可达（Certbot 的 HTTP-01 校验依赖）。这一步不通过，后面签发会失败。

第 3 步 · 先用 certbot 签发证书

此时服务器仍是旧配置，80 块正常。需新签发的 8 个域名：r.sparrowzoo.net、img.im.sparrowzoo.net、u.r.sparrowzoo.net、passport/admin/im/lottery/api.sparrowzoo.com。

for d in r.sparrowzoo.net img.im.sparrowzoo.net u.r.sparrowzoo.net \
         passport.sparrowzoo.com admin.sparrowzoo.com im.sparrowzoo.com \
         lottery.sparrowzoo.com api.sparrowzoo.com; do
  sudo certbot certonly --nginx -d "$d"
done

第 4 步 · 覆盖新配置到服务器

将仓库中的 nginx.conf 覆盖到服务器 /etc/nginx/nginx.conf，并核对 pid 路径、各 root 路径与服务器实际目录一致。

第 5 步 · 校验并平滑重载

sudo nginx -t          # 必须先通过
sudo nginx -s reload

nginx -t 是必须通过的前置校验；失败说明配置有语法错误或证书路径缺失，此时不要 reload。

第 6 步 · 验证

curl -I https://api.sparrowzoo.com        # 应 200
curl -I http://passport.sparrowzoo.com    # 应 301 跳到 https

并人工确认 im 聊天（wss）、图片加载、文件上传等正常——HTTPS 下这些走 wss:// 与加密上传，要实测链路。

第 7 步 · 确认自动续期

sudo certbot renew --dry-run

Let's Encrypt 证书有效期 90 天，Certbot 会自动续期。--dry-run 做一次模拟续期，确认定时任务与校验链路都正常。

STEP 04注意事项

• 顺序不能反：443 块引用了证书路径，证书不存在时 nginx -t 会失败、nginx 无法启动。必须先签发证书，再覆盖新配置。
• 证书与配置解耦：用 certonly 只签证书，配置完全由仓库文件控制，避免 Certbot 自动改写引入差异。
• 内部域名不上 HTTPS：nacos、monitor 等管理面板保持 80，不暴露到公网 HTTPS。
• WebSocket 要单独验证：HTTPS 下客户端用 wss://，升级头要正确透传，im 聊天才能正常工作。

Q1HTTPS 没生效，浏览器报「无法访问此网站 / ERR_CONNECTION_CLOSED」

现象

访问 https://www.sparrowzoo.com 时，浏览器提示「无法访问此网站…ERR_CONNECTION_CLOSED」或长时间无响应。

排查：本机自测三步法

依次执行下面三条命令。每条「通过」都代表 nginx 的某一层是好的，通过后往下走，直到找出断在哪一层。

第 1 步 · 校验配置与证书

sudo nginx -t

输出 syntax is ok / test is successful 说明配置语法正确、证书路径都能加载。若失败，多半是证书没签好或路径写错。

第 2 步 · 确认监听端口

sudo ss -tlnp | grep -E ':(80|443)\b'

同时出现 0.0.0.0:80 和 0.0.0.0:443 说明 reload 已生效、nginx 正在监听两个端口。只有 80 没有 443，说明还在跑旧配置，先执行 sudo nginx -s reload。

第 3 步 · 本机直连 443

curl -kv https://127.0.0.1 -H "Host: www.sparrowzoo.com"

本机能完成 TLS 握手并返回内容，说明 nginx 的 HTTPS 本身完全正常。此时问题一定出在服务器之外：云安全组、防火墙或 DNS。

解决：在阿里云安全组放行 80 / 443

1. 进入安全组：登录 阿里云 ECS 控制台 → 网络与安全 → 安全组 ↗，找到实例绑定的安全组（如 sg-2zea8r0aht2wpup5yc90）。
2. 添加入方向规则：点「手动添加」，分别加两条——端口 80（TCP）、授权对象 0.0.0.0/0；端口 443（TCP）、授权对象 0.0.0.0/0。
3. 保存后重试：安全组规则即时生效、无需重启，直接刷新 https://www.sparrowzoo.com 验证。