Nginx 配 HTTPS 与域名接入：个人站点从可访问到更适合长期使用

站点能通过 IP 打开，只能说明“先跑起来了”。

如果想把它真正当成长期维护的个人技术站，更推荐尽快把下面几件事补上：

域名
HTTPS
自动续期

先说结论

对当前这套知识库站点来说，更稳的一条路径通常是：

text

域名解析 -> Docker Nginx 监听 80/443 -> 挂载通配符证书 -> 80 跳 443 -> 自动续期 -> reload Nginx

如果你后面不只准备跑一个 wiki.mumuxiaojia.site，而是还会继续扩成 blog、admin、api 这些同级子域名，那直接按通配符证书来规划会更统一。

一、先把这条链路里的角色分清楚

这一条链路里通常有 4 层：

域名服务商：负责解析
腾讯云服务器：负责承载服务
Nginx：负责接收请求并处理证书
证书工具：负责申请和续期

如果一开始没分清这些职责，后面排问题会很乱。

二、为什么这里更适合直接用通配符证书

如果你后面准备把站点扩成：

wiki.mumuxiaojia.site
blog.mumuxiaojia.site
admin.mumuxiaojia.site
api.mumuxiaojia.site

那直接按一张：

text

*.mumuxiaojia.site

来规划，通常会更省心。

这样做的好处主要有 3 个：

新增同级子域名时，不用再额外补一张单独证书
Nginx 多站点配置更容易统一
续期、备份和迁移的维护成本更低

当然，通配符证书适合的是同一级子域名，它不等于所有域名场景都自动覆盖，这点要单独想清楚。

三、放到当前这套站点，域名解析最少要做什么

如果你现在主要在跑：

text

wiki.mumuxiaojia.site

那最少要确认：

wiki 这条解析已经指向服务器公网 IP
如果后面要继续扩子域名，也提前把命名规则想清楚

比较常见的规划方式是：

wiki.mumuxiaojia.site
blog.mumuxiaojia.site
admin.mumuxiaojia.site
api.mumuxiaojia.site

这样后面通配符证书才能真正发挥价值。

四、Nginx 为什么要同时保留 80 和 443

很多人装完证书后，第一反应是：

那我是不是只留 443 就行

通常不建议。

更常见的做法是：

80 端口负责接入和 HTTP 跳转
443 端口负责真正提供 HTTPS 服务

例如：

nginx

server {
    listen 80;
    server_name wiki.mumuxiaojia.site;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name wiki.mumuxiaojia.site;

    ssl_certificate /etc/nginx/ssl/mumuxiaojia.site/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/mumuxiaojia.site/privkey.pem;

    root /usr/share/nginx/html/mumu-wiki;
    index index.html;

    location / {
        try_files $uri $uri.html $uri/ =404;
    }
}

这里最关键的一点是：

访问域名是 wiki.mumuxiaojia.site
证书路径用的是通配符证书文件

也就是说，证书是通配符，不代表 server_name 要写成星号；Nginx 仍然按具体域名匹配，只是复用了同一张证书。

五、结合当前服务器，这套目录应该怎么理解

你现在这套知识库站点，本质上已经很适合按宿主机持久化目录来维护：

text

/mydata/nginx/conf.d
/mydata/nginx/html/mumu-wiki
/mydata/nginx/logs
/mydata/nginx/backups

如果再把 HTTPS 也接进去，更推荐继续保持同样思路：

text

/mydata/nginx/conf.d       Nginx 配置
/mydata/nginx/html/mumu-wiki    知识库静态文件
/mydata/nginx/logs         访问日志和错误日志
/mydata/nginx/backups      配置和站点备份
/mydata/nginx/ssl          证书挂载目录

这样做的好处是：

配置、站点、日志、证书都能在宿主机直观看到
容器重建时不容易丢核心文件
后面做备份和回滚也更顺手

六、Docker Nginx 场景下更贴近实际的挂载方式

如果当前 Nginx 是 Docker 部署，一个更贴近现在这套环境的挂载方式通常是：

yaml

services:
  nginx:
    image: nginx:1.27
    container_name: nginx-mumu-wiki
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /mydata/nginx/conf.d:/etc/nginx/conf.d:ro
      - /mydata/nginx/html:/usr/share/nginx/html
      - /mydata/nginx/logs:/var/log/nginx
      - /mydata/nginx/ssl:/etc/nginx/ssl:ro
    restart: unless-stopped

这类写法的重点不是语法本身，而是职责清楚：

conf.d 管配置
html 管站点文件
logs 管日志
ssl 管证书

这样后面无论：

重建容器
更新站点
reload Nginx
做证书续期

都不会把 HTTPS 入口这一层弄乱。

七、证书工具怎么选

对个人站点来说，常见选择有两个：

certbot
acme.sh

1. Certbot

优点：

文档多
社区成熟

2. acme.sh

优点：

更轻
shell 化程度高
做通配符证书时更灵活

如果你后面准备长期维护多个子域名，通配符证书这条线通常更适合用一套固定脚本和固定目录长期跑下去。重点不是工具名，而是：

证书路径清晰
续期流程可靠
续期后 Nginx 能正确 reload

八、最容易踩的坑

1. 证书已经换成通配符，但 Nginx 还引用着旧路径

这类问题很常见。

证书文件换了
配置里还是旧路径
最后线上加载的并不是你以为的那张证书

2. 宿主机证书目录和容器内路径对不上

这在 Docker 场景特别常见。

宿主机有证书文件
容器里实际路径不对
nginx -t 或 reload 就会失败

3. 证书续期了，但 Nginx 没 reload

这类问题也很常见。

证书文件已经更新
但线上访问看到的还是旧证书

4. 以为有了通配符证书，后面域名就不用管了

通配符证书只是让同一类子域名更好维护，不代表后续域名规划、Nginx 配置和站点拆分就都可以不看。

九、自动续期为什么一定要做

证书不是一劳永逸的。

你至少要确保：

续期任务存在
续期成功后能 reload Nginx

如果你当前容器名固定为 nginx-mumu-wiki，一个很常见的刷新方式就是：

bash

docker exec nginx-mumu-wiki nginx -s reload

无论你最后是 cron、systemd timer 还是别的方式，核心都是：

不靠人记

十、怎么验证当前 HTTPS 配置真的已经生效

不要只看浏览器能不能打开。

对现在这套站点，更推荐至少做 3 件事：

1. 先检查 Nginx 配置

bash

docker exec nginx-mumu-wiki nginx -t

2. 再 reload Nginx

bash

docker exec nginx-mumu-wiki nginx -s reload

3. 最后从服务器本机验证

bash

curl -k --resolve wiki.mumuxiaojia.site:443:127.0.0.1 https://wiki.mumuxiaojia.site/

这一步的意义是：

不依赖公网链路排查
能直接确认 443 是否正常响应
能确认当前 Nginx 配置和证书链路有没有明显问题

十一、和个人技术站搭建这条线怎么衔接

如果把整个站点搭建专题串起来看，更推荐的顺序是：

先把 VitePress 和 Docker Nginx 跑起来
再补域名和 HTTPS
如果后面准备维护多个子域名，就直接按通配符证书规划
最后再把构建和发布自动化

这样做有两个好处：

当前站点先能稳定上线
后面要继续扩博客、后台或接口时，也不用重新推翻 HTTPS 方案

如果你正沿着这条线继续往下做，可以继续看：

一句话总结

对个人知识库来说，HTTPS 这一步不只是“把证书配上”，而是把域名、Nginx、证书路径和自动续期这几层稳定串起来；如果后面会继续扩多个子域名，通配符证书会更适合长期维护。

Nginx 配 HTTPS 与域名接入：个人站点从可访问到更适合长期使用 ​

先说结论 ​

一、先把这条链路里的角色分清楚 ​

二、为什么这里更适合直接用通配符证书 ​

三、放到当前这套站点，域名解析最少要做什么 ​

四、Nginx 为什么要同时保留 80 和 443 ​

五、结合当前服务器，这套目录应该怎么理解 ​

六、Docker Nginx 场景下更贴近实际的挂载方式 ​

七、证书工具怎么选 ​

1. Certbot ​

2. acme.sh ​

八、最容易踩的坑 ​

1. 证书已经换成通配符，但 Nginx 还引用着旧路径 ​

2. 宿主机证书目录和容器内路径对不上 ​

3. 证书续期了，但 Nginx 没 reload ​

4. 以为有了通配符证书，后面域名就不用管了 ​

九、自动续期为什么一定要做 ​

十、怎么验证当前 HTTPS 配置真的已经生效 ​

1. 先检查 Nginx 配置 ​

2. 再 reload Nginx ​

3. 最后从服务器本机验证 ​

十一、和个人技术站搭建这条线怎么衔接 ​

一句话总结 ​

Nginx 配 HTTPS 与域名接入：个人站点从可访问到更适合长期使用

先说结论

一、先把这条链路里的角色分清楚

二、为什么这里更适合直接用通配符证书

三、放到当前这套站点，域名解析最少要做什么

四、Nginx 为什么要同时保留 80 和 443

五、结合当前服务器，这套目录应该怎么理解

六、Docker Nginx 场景下更贴近实际的挂载方式

七、证书工具怎么选

1. Certbot

2. acme.sh

八、最容易踩的坑

1. 证书已经换成通配符，但 Nginx 还引用着旧路径

2. 宿主机证书目录和容器内路径对不上

3. 证书续期了，但 Nginx 没 reload

4. 以为有了通配符证书，后面域名就不用管了

九、自动续期为什么一定要做

十、怎么验证当前 HTTPS 配置真的已经生效

1. 先检查 Nginx 配置

2. 再 reload Nginx

3. 最后从服务器本机验证

十一、和个人技术站搭建这条线怎么衔接

一句话总结