本站域名配置

这一课你将能做到

1. 对照 coderoadmap.cn 的真实记录集，说清 Cloudflare 面板里每条记录的用途与 TTL 取舍
2. 写出与 DNS 配套的 Nginx 配置：server_name、裸域 301、HTTPS 跳转、证书路径，并通过 nginx -t 验证
3. 独立完成一次「新子域上线」全流程：配解析 → 配 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	CA 白名单

橙云与灰云的取舍：面向用户的网站走橙云（隐藏源 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。严禁无备份直接修改。

讲清楚要点

1. DNS 与 Nginx 通过「主机名」握手：DNS 负责把名字变成 IP，Nginx 的 server_name 负责在同一 IP 上按名字分流；两边名字必须逐字一致。
2. 橙云隐藏源 IP，灰云暴露源 IP：安全敏感场景默认橙云；origin 这类灰云记录等于公开源站地址，如非必要不要长期保留。
3. 证书主机名集合 = 所有会访问该 Nginx 的名字：加子域必须同步签发证书，否则该子域 TLS 告警。
4. 裸域要明确归宿：要么提供内容，要么 301 到 www；什么都不配会有用户因直接访问 coderoadmap.cn 而失败。
5. TTL 在变更期是安全绳：平时 Auto/300 即可；频繁迁移的记录不要超过 600。
6. Cloudflare 规则与 Nginx 规则是两层：边缘规则在 CF 生效，rewrite 在源站生效；排障先看请求有没有到源站。
7. 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 规则跳转

卡点急救

1. ERR_TOO_MANY_REDIRECTS：99% 是 Flexible 与源站 HTTPS 跳转冲突。改 Full (strict)；若仍循环，curl -I 跟随看每一跳 Location，定位是 CF 规则还是 Nginx rewrite。
2. 新子域公网查不到：先 dig @ns1.cloudflare.com 子域 确认权威有记录；权威有则等缓存，没有就是保存失败或 Name 拼错。
3. 上线后源站收不到请求：橙云下先看 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。

自测三问

1. 画出本站从注册商到 Nginx 应用的完整链路，并标注橙云/灰云在每一跳的差异。
2. 用户报 ERR_TOO_MANY_REDIRECTS，你按什么顺序查哪两个配置？
3. 为什么加子域时 DNS、Nginx、证书三处必须一起改？漏一处各是什么现象？

小结一句话

本站运维 = 注册商委派 NS、Cloudflare 管权威与代理、Nginx 按 server_name 接客、证书覆盖全部名字；四层各司其职，按「权威→源站→多解析器验收」流水线推进。

延伸

• Cloudflare：DNS 记录官方文档
• Cloudflare：SSL/TLS 模式说明
• Nginx 官方文档：基于名字的虚拟主机
• certbot 官方文档
• 下一课预告：DNS 与 HTTPS——DoH/DoT 加密 DNS、CAA 与证书申请验证的协作机制。