DNS + HTTPS 证书 + Nginx：网站上线前真正需要理解的链路

这个主题和你接下来很可能会用到的事情直接相关：你已经准备好了 Nginx、UFW、Certbot，之后只要有域名和后端服务，就会进入“域名解析 → Nginx 反代 → HTTPS 证书”的阶段。

如果只记一句话：

域名负责把用户带到你的服务器，Nginx 负责接住请求并转发给后端，HTTPS 证书负责证明“这个域名确实是你控制的”并加密连接。

1. DNS：把名字指向服务器

用户访问的是：

text

api.example.com

但服务器真正识别的是 IP，比如你现在的新服务器公网 IP。

DNS 的作用就是把：

text

api.example.com

解析到：

text

服务器公网 IP

最常见的是 A 记录：

text

api.example.com -> 服务器公网 IP

如果以后用 IPv6，则会有 AAAA 记录。

DNS 有一个很重要的现实特性：缓存。
你改了 DNS，不一定全球立即生效。不同运营商、不同 DNS 服务器可能需要几分钟到数小时。这个时间通常由 TTL 影响。

所以部署网站时，常见顺序是：

先准备服务器
配好 Nginx
把域名 A 记录指向服务器 IP
等 DNS 生效
申请 HTTPS 证书

2. Nginx：公网入口和反向代理

你现在服务器上 Nginx 已经监听 80 端口。
以后后端服务最好不要直接暴露公网，而是这样：

text

用户浏览器
  ↓ HTTPS
Nginx :443
  ↓ 本机转发
后端服务 127.0.0.1:8080

这样做的好处是：

后端端口不直接暴露公网
HTTPS 统一在 Nginx 层处理
可以后续挂多个服务/多个域名
可以做访问日志、限流、压缩、缓存
后端崩了，Nginx 还能返回统一错误页
以后迁移后端端口，不影响用户访问域名

对你来说，这就是之前我们定的原则：

text

公网只开放 22/80/443
后端监听 127.0.0.1
不要直接开放 8080 之类应用端口

3. HTTPS 证书：为什么不是“开了 443 就安全”

UFW 放行 443，只是允许外部访问 HTTPS 端口。
但真正的 HTTPS 还需要证书。

证书的作用有两个：

加密连接

防止中间人看到或篡改内容。

证明身份

浏览器要确认：

我访问的确实是 api.example.com，而不是别人冒充的服务器。

Let’s Encrypt 是免费的证书颁发机构。
Certbot 是帮你自动申请和续期证书的工具。

你的服务器上已经装好了：

text

certbot
python3-certbot-nginx

所以以后域名解析好后，就可以让 Certbot 自动帮 Nginx 配 HTTPS。

4. Let’s Encrypt 怎么确认这个域名是你的

它不会相信你口头说“这个域名归我”。
它需要做验证。

常见有两种方式。

HTTP-01 验证

Let’s Encrypt 会访问：

text

http://你的域名/.well-known/acme-challenge/...

如果它能通过域名访问到你服务器上 Certbot 放的验证文件，就说明你控制了这个域名对应的 Web 服务。

适合：

普通单域名
Nginx 已经能通过 80 被访问
最常见、最简单

你近期大概率用这个。

DNS-01 验证

Let’s Encrypt 要求你在 DNS 里添加一条 TXT 记录。
它看到 TXT 记录正确，就认为你控制这个域名。

适合：

泛域名证书，比如 *.example.com
服务器 80 端口无法公网访问
想自动化管理大量子域名

但它通常需要 DNS 服务商 API token，配置更复杂。你当前阶段不急。

5. 一个容易踩的坑：DNS、Nginx、证书三者必须对齐

很多 HTTPS 配置失败，不是 Certbot 本身的问题，而是这三者没对上。

比如：

DNS 还没指向当前服务器
域名指向旧 IP
Nginx 没有对应 server_name
80 端口被防火墙挡了
云厂商安全组没放行 80/443
当前机器有多个 Nginx server block，Certbot 找错了
域名用了 CDN，源站验证被干扰

所以以后如果你要上线一个服务，我们先确认这条链：

text

域名 A 记录 → 当前服务器公网 IP
服务器 UFW → 允许 80/443
Nginx server_name → 匹配域名
后端服务 → 本机可访问
Certbot → 申请证书

6. 什么时候用子域名，什么时候用路径

假设你有多个服务：

OpenClaw 控制台
API 后端
文档
测试项目

有两种暴露方式。

子域名方式

text

api.example.com
docs.example.com
test.example.com

优点：

清晰
服务隔离好
证书和 Nginx 配置直观
后续迁移方便

缺点：

DNS 记录多一点
每个子域名都要配置

路径方式

text

example.com/api
example.com/docs
example.com/test

优点：

域名少
初期简单

缺点：

反代路径处理更容易踩坑
后端如果不支持 base path，会出问题
Cookie、静态资源、重定向更复杂

对你后续部署项目，我更建议优先用子域名。
比如：

text

api.yourdomain.com

而不是：

text

yourdomain.com/api

7. 和你当前服务器的关系

你现在已经准备好了这些基础件：

Nginx 已安装并运行
UFW 已放行 80/443
Certbot 已安装
反代模板已写好
OpenClaw Gateway 仍然只在 127.0.0.1:18789
后端端口不直接对公网开放

所以之后真正上线服务时，你缺的主要是：

一个域名
DNS A 记录指向服务器公网 IP
一个本机后端服务，比如 127.0.0.1:8080
Nginx server block
Certbot 申请 HTTPS

DNS + HTTPS 证书 + Nginx：网站上线前真正需要理解的链路

1. DNS：把名字指向服务器

2. Nginx：公网入口和反向代理

3. HTTPS 证书：为什么不是“开了 443 就安全”

加密连接

证明身份

4. Let’s Encrypt 怎么确认这个域名是你的

HTTP-01 验证

DNS-01 验证

5. 一个容易踩的坑：DNS、Nginx、证书三者必须对齐

6. 什么时候用子域名，什么时候用路径

子域名方式

路径方式

7. 和你当前服务器的关系

推荐阅读

DigitalOcean：How To Secure Nginx with Let’s Encrypt on Ubuntu

NGINX / F5：Using Free Let’s Encrypt SSL/TLS Certificates with NGINX

Let’s Encrypt：Challenge Types

Cloudflare Learning Center：What is DNS?

DNS + HTTPS 证书 + Nginx：网站上线前真正需要理解的链路 ​

1. DNS：把名字指向服务器 ​

2. Nginx：公网入口和反向代理 ​

3. HTTPS 证书：为什么不是“开了 443 就安全” ​

加密连接 ​

证明身份 ​

4. Let’s Encrypt 怎么确认这个域名是你的 ​

HTTP-01 验证 ​

DNS-01 验证 ​

5. 一个容易踩的坑：DNS、Nginx、证书三者必须对齐 ​

6. 什么时候用子域名，什么时候用路径 ​

子域名方式 ​

路径方式 ​

7. 和你当前服务器的关系 ​

推荐阅读 ​

DigitalOcean：How To Secure Nginx with Let’s Encrypt on Ubuntu ​

NGINX / F5：Using Free Let’s Encrypt SSL/TLS Certificates with NGINX ​

Let’s Encrypt：Challenge Types ​

Cloudflare Learning Center：What is DNS? ​

DNS + HTTPS 证书 + Nginx：网站上线前真正需要理解的链路

1. DNS：把名字指向服务器

2. Nginx：公网入口和反向代理

3. HTTPS 证书：为什么不是“开了 443 就安全”

加密连接

证明身份

4. Let’s Encrypt 怎么确认这个域名是你的

HTTP-01 验证

DNS-01 验证

5. 一个容易踩的坑：DNS、Nginx、证书三者必须对齐

6. 什么时候用子域名，什么时候用路径

子域名方式

路径方式

7. 和你当前服务器的关系

推荐阅读

DigitalOcean：How To Secure Nginx with Let’s Encrypt on Ubuntu

NGINX / F5：Using Free Let’s Encrypt SSL/TLS Certificates with NGINX

Let’s Encrypt：Challenge Types

Cloudflare Learning Center：What is DNS?