本站域名配置
这一课你将能做到
- 对照
coderoadmap.cn 的真实记录集，说清 Cloudflare 面板里每条记录的用途与 TTL 取舍
- 写出与 DNS 配套的 Nginx 配置：
server_name、裸域 301、HTTPS 跳转、证书路径，并通过 nginx -t 验证
- 独立完成一次「新子域上线」全流程：配解析 → 配 Nginx → 多解析器验收 → 留回滚方案
为什么要学
前 5 课的知识是散件：记录类型、解析链路、工具。从本课开始装成整机。本站 coderoadmap.cn 的真实形态是：域名在注册商处注册 → NS 委派给 Cloudflare → Cloudflare 做权威解析（橙云代理 + 部分灰云直连）→ 源站云主机跑 Nginx → Nginx 反代静态站与后端服务。
初学者常把几层混着调：证书报错改 DNS、解析不通改 Nginx。本课按「权威侧 → 源站侧 → 验收」走一遍真实配置，建立上线流水线，第 12 课直接复用。
先建立图像
注册商（域名所有权）
│ NS 委派
▼
Cloudflare（权威 + 代理）
│ A/AAAA/CNAME/MX/TXT
▼
橙云记录：用户 ──► CF 边缘 IP（104.21.x / 172.67.x）──回源──► 源站 203.0.113.10
灰云记录：用户 ───────────────────────────────────────► 源站 203.0.113.10
│
▼
Nginx :80/:443
├─ 静态站（/usr/share/nginx/html）
└─ proxy_pass → 127.0.0.1:8080（API）
本站记录规划（示例，运维时以面板实际为准）：
| 主机记录 | 类型 | 值 | 代理 | TTL | 用途 |
|---|
| @ | A | 203.0.113.10 | 橙云 | 300 | 裸域入口 |
| www | A | 203.0.113.10 | 橙云 | 300 | 主站入口 |
| api | A | 203.0.113.10 | 灰云 | 300 | API 直连（调试用） |
| origin | A | 203.0.113.10 | 灰云 | 300 | 回源/排障专用 |
| mail | A | 203.0.113.10 | 灰云 | 300 | 邮件主机 |
| @ | MX | 10 mail.coderoadmap.cn | — | 3600 | 收信 |
| @ | TXT | v=spf1 -all | — | 3600 | SPF（第 8 课） |
| @ | CAA | 0 issue "letsencrypt.org" | — | 3600 |
橙云与灰云的取舍：面向用户的网站走橙云（隐藏源 IP、抗攻击、CDN 加速）；API 调试、回源验证、邮件这类需要直连或 Cloudflare 不代理的协议走灰云。注意 Cloudflare 只代理 HTTP/HTTPS，邮件流量不经代理。
跟着做
步骤 1：确认委派已生效
dig coderoadmap.cn NS +short
dig +trace www.coderoadmap.cn A | tail -5
应看到 NS 为 ns1.cloudflare.com / ns2.cloudflare.com，trace 最后一跳来自 Cloudflare。若注册商处 NS 仍旧值，所有面板配置都不会对公网生效——先等 NS 变更传播（通常 1～24 小时）。
步骤 2：在 Cloudflare 添加记录
面板路径：DNS → Records → Add record。以 www 为例：
Type: A
Name: www
IPv4 address: 203.0.113.10
Proxy status: Proxied（橙云）
TTL: Auto（即 300）
dig @ns1.cloudflare.com www.coderoadmap.cn A +short
橙云返回的是 Cloudflare 边缘 IP（如 104.21.5.10），这是正常的，不代表你填错了源站 IP。想看源站是否被正确记录，用灰云记录（如 origin）验证。
步骤 3：写源站 Nginx 配置
新建 /etc/nginx/conf.d/coderoadmap.conf：
# 80 端口：全部跳转到 HTTPS（ACME 验证路径放行）
server {
listen 80;
listen [::]:80;
server_name coderoadmap.cn www.coderoadmap.cn;
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}
location / {
return 301 https://www.coderoadmap.cn$request_uri;
}
}
# 443：主站
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name www.coderoadmap.cn;
ssl_certificate /etc/letsencrypt/live/www.coderoadmap.cn/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.coderoadmap.cn/privkey.pem;
root /usr/share/nginx/html;
index index.html;
location /api/ {
proxy_pass http://127.0.0.1:8080/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
# 裸域 HTTPS：301 到 www，保证只有一个 canonical 域名
server {
listen 443 ssl http2;
server_name coderoadmap.cn;
ssl_certificate /etc/letsencrypt/live/www.coderoadmap.cn/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.coderoadmap.cn/privkey.pem;
return 301 https://www.coderoadmap.cn$request_uri;
}
sudo nginx -t && sudo systemctl reload nginx
步骤 4：证书与 Cloudflare SSL 模式对齐
# 源站证书（certbot，webroot 方式；需先放行 80 的验证路径）
sudo certbot certonly --webroot -w /var/www/certbot \
-d www.coderoadmap.cn -d coderoadmap.cn
Cloudflare 的 SSL/TLS 模式必须与源站一致，这是本站上线最容易踩的坑：
| CF 模式 | 回源协议 | 适用 |
|---|
| Flexible | HTTP 80 | 不推荐：源站与 CF 间明文，且易产生重定向循环 |
| Full | HTTPS（不校验源证书） | 过渡可用 |
| Full (strict) | HTTPS 且校验证书 | 推荐，配 Let's Encrypt 或 CF Origin 证书 |
若源站 Nginx 做了 80→443 跳转而 CF 选 Flexible，会出现「CF 用 HTTP 回源 → Nginx 301 到 HTTPS → CF 再回源」的死循环，报 ERR_TOO_MANY_REDIRECTS。直接改 Full (strict) 解决。
步骤 5：上线一个新子域的完整流程
以 status.coderoadmap.cn（状态页）为例：
# 1) Cloudflare 加记录：A → 203.0.113.10，橙云，TTL Auto
# 2) Nginx 增加 server 块（server_name status.coderoadmap.cn;）
# 3) 证书加域名
sudo certbot certonly --webroot -w /var/www/certbot -d status.coderoadmap.cn
sudo nginx -t && sudo systemctl reload nginx
# 4) 多解析器验收
dig @8.8.8.8 status.coderoadmap.cn +short
dig @223.5.5.5 status.coderoadmap.cn +short
curl -I https://status.coderoadmap.cn/
步骤 6：绕过 Cloudflare 直连源站验收
# 用灰云主机名 origin（不经过 CF），验证源站自身服务
curl -I https://origin.coderoadmap.cn/
# 或用 --resolve 把 www 强制指向源站 IP（证书需覆盖 www）
curl -I --resolve www.coderoadmap.cn:443:203.0.113.10 https://www.coderoadmap.cn/
这一步是「分清锅在哪」的关键：直连源站失败 → 源站配置问题；直连成功、走域名失败 → Cloudflare 配置或网络层问题。
步骤 7：留下回滚方案
变更前截图/导出记录，记下旧 IP、证书路径和 TTL。回滚两步：Cloudflare 改回旧值（TTL 300 时 5 分钟内回流）、Nginx 配置 cp 回备份后 reload。严禁无备份直接修改。
讲清楚要点
- DNS 与 Nginx 通过「主机名」握手：DNS 负责把名字变成 IP，Nginx 的
server_name 负责在同一 IP 上按名字分流；两边名字必须逐字一致。
- 橙云隐藏源 IP，灰云暴露源 IP：安全敏感场景默认橙云；origin 这类灰云记录等于公开源站地址，如非必要不要长期保留。
- 证书主机名集合 = 所有会访问该 Nginx 的名字：加子域必须同步签发证书，否则该子域 TLS 告警。
- 裸域要明确归宿：要么提供内容，要么 301 到 www；什么都不配会有用户因直接访问
coderoadmap.cn 而失败。
- TTL 在变更期是安全绳：平时 Auto/300 即可；频繁迁移的记录不要超过 600。
- Cloudflare 规则与 Nginx 规则是两层：边缘规则在 CF 生效，rewrite 在源站生效；排障先看请求有没有到源站。
- SPF/MX 等邮件记录不受橙灰云影响：Cloudflare 不代理 SMTP，这些记录始终按 DNS 原样返回。
你可能会懵的地方
-
橙云之后，源站看到的访问 IP 都是 Cloudflare 的，怎么办？
正常。源站应从 CF-Connecting-IP 或 X-Forwarded-For 头取真实访客 IP；Nginx 可用 ngx_http_realip_module 配置 Cloudflare 官方 IP 段为可信代理后自动还原。
-
为什么面板里记录值写的是源 IP，dig 出来却是别的 IP？
橙云（Proxied）的本质：权威对该名字返回 Cloudflare 边缘 IP，回源关系由 Cloudflare 内部保存。切灰云（DNS only）后 dig 立刻返回真实源 IP。
-
certbot 申请超时，和 DNS 有关系吗？
有。HTTP-01 验证要求域名解析到这台机器、80 端口可从公网访问。橙云 + 严格模式下 HTTP-01 可能走边缘不稳，可改用 DNS-01（Cloudflare API 自动写 TXT），不受代理影响。
-
api 灰云直连没有 CDN，为什么还这样设计？
API 多为动态数据、缓存价值低，直连减少一层故障点，也便于用 wireshark/tcpdump 抓真实链路排查；正式对外 API 需要加速防护时再单独走橙云。
错法对照
| 错法 | 后果 | 正确做法 |
|---|
| CF 用 Flexible + 源站强制 HTTPS | 重定向循环 | Full (strict)，源站配有效证书 |
| 加子域只改 DNS，不改 Nginx/证书 | 走到默认 server 块或 TLS 告警 | DNS、Nginx、证书三处同步 |
| 把完整域名填在 Name 栏 | 实际变成域名重复拼接 | Name 只填 www |
| 橙云后用源站日志里的 IP 做限流 | 把所有用户当成一个 CF IP 封掉 | 用 realip 还原真实 IP 后再限流 |
| 裸域既无 A 也无跳转 | 直接访问根域失败 | 配 A + Nginx 301，或用 CF 规则跳转 |
卡点急救
ERR_TOO_MANY_REDIRECTS：99% 是 Flexible 与源站 HTTPS 跳转冲突。改 Full (strict)；若仍循环，curl -I 跟随看每一跳 Location，定位是 CF 规则还是 Nginx rewrite。- 新子域公网查不到：先
dig @ns1.cloudflare.com 子域 确认权威有记录；权威有则等缓存，没有就是保存失败或 Name 拼错。
- 上线后源站收不到请求：橙云下先看 CF 控制台的 Analytics/Events 是否有拦截（WAF、防火墙规则）；再确认回源端口与 SSL 模式；用 origin 灰云直连区分边缘与源站。
面试常问
-
一个新域名要部署上线，请说完整步骤。
注册商处确认 NS 已委派到 DNS 托管商；在权威侧添加 A/AAAA（或 CNAME）记录并设合理 TTL；源站 Nginx 配置 server_name、站点目录/反代和 80→443 跳转；申请覆盖所有域名的证书并配置 HTTPS；若有 CDN 代理，对齐回源协议（Full strict）与源站证书；最后用多个公共解析器和 curl 验收，保留旧配置用于回滚。
-
接入 Cloudflare 这类 CDN 代理后，DNS 记录层面有什么变化？
橙云记录在权威上返回的是 CDN 边缘 IP 而非源站 IP，源站地址只保存在 CDN 内部；灰云记录原样返回。邮件（MX）等非 HTTP 记录不受代理影响。好处是隐藏源 IP、就近接入和边缘防护；代价是排障要分清边缘与源站，且源站必须从代理协议头取真实客户端 IP。
-
Nginx 一台机器服务多个域名的原理是什么？
基于 HTTP/1.1 的 Host 头（HTTPS 下基于 SNI）做虚拟主机分流：Nginx 收到请求后按 server_name 匹配对应 server 块，匹配不到则走默认块。前提是这些域名都解析到这台机器 IP。
自测三问
- 画出本站从注册商到 Nginx 应用的完整链路，并标注橙云/灰云在每一跳的差异。
- 用户报
ERR_TOO_MANY_REDIRECTS，你按什么顺序查哪两个配置？
- 为什么加子域时 DNS、Nginx、证书三处必须一起改？漏一处各是什么现象？
小结一句话
本站运维 = 注册商委派 NS、Cloudflare 管权威与代理、Nginx 按 server_name 接客、证书覆盖全部名字；四层各司其职，按「权威→源站→多解析器验收」流水线推进。
延伸