域名、DNS、HTTPS配置实战：从解析到加密的完整排坑指南

先讲个真实案例。前阵子有个朋友做个人博客，程序装好了，后台也能打开，结果访客反馈“你的网站打不开”，我一问，域名还没做解析。等他配好解析，又发现地址栏没有小锁，浏览器直接提示不安全。这两个问题拆开看都不难，但合在一起，就成了新手部署站点时最容易卡住的“7.2 域名DNSHTTPS到底怎么配”。

域名、DNS、HTTPS这三件事，说穿了就是“起名字、查地址、上加密锁”。单拎出来每个都有堆文档，但真正动手做的时候，细节问题一个接一个：CNAME和A记录到底选哪个？证书配好了怎么还是红锁？HTTP自动跳HTTPS为什么变成死循环？这篇我就按自己实际部署的经验，把最容易出错的环节完整捋一遍，能帮读者省下的时间，至少是半天起步。

1. 域名、DNS、HTTPS的关系，一张图讲透

很多人一上来就急着操作控制台，结果越配越乱。动手之前，先花两分钟把这三层关系理清，后面所有操作就都顺了。

1.1 域名是门牌号，DNS是门牌查询系统，HTTPS是防盗锁

域名本身不承载任何内容，它只是一串方便人记的名字，比如 example.com。真正提供服务的是服务器IP，比如 203.0.113.10。用户访问网站时，浏览器需要知道 example.com 对应哪个IP，这个“翻译”工作就是DNS干的。HTTPS则是给浏览器和服务器之间的通道加了一把锁，保证传输的内容不被第三方偷看或篡改。

这三者缺一个，网站就没法正常访问：

• 只有域名，没有DNS解析，浏览器找不到服务器。
• 有域名和DNS，但没有HTTPS证书，浏览器会提示“不安全”，部分功能（比如某些小程序回调、敏感接口）无法使用。
• 有证书但配错位置，配到别的端口或别的域名上，照样报错。

新手最容易犯的认知错误，是把域名控制台里的“域名解析”当成“域名转发”。解析只是把域名指到某台服务器的IP，并不是让这个域名自动打开某个其他网页。还有一部分人以为买完域名就等于网站上线了，其实域名只是一张“门牌号”，房子还得自己盖。

1.2 访问一个HTTPS网站的完整链路

我习惯把整个访问流程拆成五步，每次排查问题就按这个顺序来：

1. 用户在浏览器输入 https://example.com。
2. 浏览器先向本地DNS服务器发起解析请求，查 example.com 对应的IP。
3. 本地DNS逐级查询，最终拿到记录值（比如 203.0.113.10）。
4. 浏览器与 203.0.113.10 的443端口建立TCP连接，然后进行SSL/TLS握手，校验证书是否有效、是否匹配当前域名。
5. 握手成功，浏览器展示页面内容，地址栏出现小锁。

任何一个环节出错，都会表现为“网站打不开”或“不安全”。关键是把问题定位到具体环节，再针对性处理，而不是盲目重装或重启。

2. 域名DNS解析配置完整实操

DNS解析是在域名服务商的控制台完成的，常见的有阿里云、腾讯云、华为云，还有独立的DNS平台。无论哪家，核心配置项都差不多，下面以最常见的配置为例展开。

2.1 先搞清楚A记录和CNAME的区别

这是新手第一个容易纠结的点。A记录的作用是把域名直接指向一个IPv4地址，比如：

• 主机记录：www
• 记录类型：A
• 记录值：203.0.113.10

CNAME的作用是把域名指向另一个域名，再由那个域名去解析出IP。比如你的网站原本是 server.example.net，想让 www.example.com 也能访问，就可以把 www.example.com 设置成CNAME指向 server.example.net。

什么时候用哪个？我个人的判断标准很简单：如果目标是一个固定IP，用A记录；如果目标是一个域名（比如云负载均衡、对象存储、CDN提供的CNAME地址），用CNAME。CNAME的好处是源站IP变了，只需要改指向目标，不需要改所有解析记录；缺点是解析链路多一跳，理论上DNS解析会慢一丁点，实际使用中几乎感受不到差异。

一个容易踩的坑：大部分DNS服务商不允许同一个主机记录同时存在A记录和CNAME记录，因为两者在语义上冲突。有的平台会自动互斥，有的平台会提示“冲突”，但新手容易忽略提示直接保存，结果解析不生效。

2.2 常用的解析记录类型，一张表搞清楚

对于普通网站部署，绝大多数时候只用A记录或CNAME记录。其他记录可以等需要时再了解，不用一开始全背下来。

2.3 添加解析记录的具体步骤

在控制台找到域名列表，点击“解析”或“DNS管理”，进入解析设置页面。添加两条记录：

第一条，让根域名能访问：

• 主机记录：@（有些平台填留空或者@）
• 记录类型：A
• 记录值：你的服务器公网IP
• TTL：600（默认即可）

第二条，让 www 子域名能访问：

• 主机记录：www
• 记录类型：A（或者CNAME指向根域名）
• 记录值：你的服务器公网IP

注意主机记录这里填的是“前缀”，不是完整域名。填 www.example.com 是错的，填 www 才是对的。这个细节我在不下十次排障中遇到过。

添加完记录后，等生效。TTL是600秒，意味着最长10分钟范围内，全球DNS服务器会陆续更新缓存。但实际上有时候几秒就生效了，有时候要半小时，取决于链路上各级DNS的刷新策略。

2.4 修改解析前，把TTL临时调小

这是个非常实用的技巧。如果你要变更服务器IP，提前一天把TTL从600调成60，这样解析记录在全球的过期时间缩短，等到真正切换IP时，旧记录会在1分钟内失效，而不是最长10分钟。切换完成后再把TTL调回600或更高。

我见过一个生产事故，就是没调TTL直接改IP，结果部分地区用户一整天都在访问旧服务器，数据不一致，用户工单刷屏。这个教训后来成了我上线流程里的固定检查项。

2.5 判断解析是否生效，别只看本机

配置完解析，有人用浏览器打开网站，发现还是打不开，就开始着急。实际上，本地电脑有DNS缓存，很可能还在用旧记录。在命令行里执行：

bash复制nslookup example.com

或者用dig命令：

bash复制dig example.com

返回结果里的 Answer 字段如果已经是你新填的IP，说明解析链路已经通了。如果本机结果不对，可以换一个网络再测，或者直接用在线的全国DNS检测工具，能看到不同地区的解析结果。我一般会同时用两个工具交叉验证，确认是“全球生效”而不是“只有本地生效”。

3. HTTPS证书申请与部署

解析通了，下一步就是给网站加上HTTPS。这里要补一个概念：HTTPS不是直接在服务器上“打开”的一个开关，而是要安装一张数字证书，证书由受信任的CA机构签发。

3.1 证书类型怎么选

常见证书按验证级别分三种：

• DV（域名型）：只验证域名所有权，几分钟就能签发，适合个人博客、中小企业官网。
• OV（企业型）：需要验证企业资质，地址栏会显示企业名称，适合电商、政务类站点。
• EV（增强型）：验证最严格，浏览器地址栏显示绿色机构名，适合银行、金融等对信任度要求高的场景。

普通部署，DV完全够用。免费证书基本都是DV级别，安全性上和数据加密能力没有任何缩水，只是不包含组织机构信息，用户看到的信任背书弱一些。免费证书和收费证书在加密强度上同样都是TLS，加密算法也一致，区别只在于验证深度和签发行情。

免费证书的第一选择是Let's Encrypt，用 certbot 工具能自动化申请和续期。国内云厂商也提供免费证书服务，比如阿里云、腾讯云的免费版DV证书，一般是一年有效期，但续期要手动操作或写脚本。对自建Nginx服务器，我推荐Let's Encrypt加自动续期，省心。

3.2 申请证书前，域名所有权验证要注意

以Let's Encrypt为例，certbot申请证书时默认会校验你对这个域名的控制权。常用方式有两种：

• DNS验证：给你一个TXT记录值，让你去DNS控制台添加。证书签发后可以删掉那条TXT记录，但要注意观察平台提示，有的平台要求保留，不同CA策略不一样。
• HTTP文件验证：给你一个token和文件内容，要求放到网站根目录下的指定路径，CA会请求这个URL来确认域名归属。

用certbot时，如果你已经安装了Nginx，可以直接跑：

bash复制certbot --nginx -d example.com -d www.example.com

它会自动检测Nginx配置，申请证书并修改配置文件。注意-d参数要带完整域名，同时把根域名和www子域名都列进去，合并到同一张证书里，这样才能两个地址访问都显示安全。

3.3 Nginx配置HTTPS的关键代码块

证书申请完成后，把证书部署到Nginx。我这里给一份基于实际生产环境最小化的配置示例：

nginx复制server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    root /var/www/example;
    index index.html;
}

其中：

• ssl_certificate 指向证书链文件 fullchain.pem，里面包含你的服务器证书和中间证书。新手如果只拿到一个 cert.pem 而没配置中间证书，会出现部分浏览器可信、部分设备（尤其手机）报错的问题。
• ssl_certificate_key 指向私钥文件，这个文件的权限要严格限制，通常设为600，只能root读取，千万不要放到公开目录。
• ssl_protocols 我直接限制为TLSv1.2和TLSv1.3，老旧的TLSv1.0和1.1存在安全漏洞，建议不再开放。

3.4 HTTP自动跳转HTTPS，注意301缓存坑

证书配好之后，还要让用户访问http时自动跳到https。Nginx配置里加一段：

nginx复制server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

这里我用的 return 301 是永久重定向。好处是一劳永逸，坑在于浏览器会缓存301状态，之后你如果想临时改回HTTP测试，会发现浏览器一直强制跳HTTPS，清缓存也没用。所以开发环境建议用302（临时重定向），线上确认没问题了再切301。

另外一个常见错误是跳转配置里写死了域名：

nginx复制return 301 https://example.com$request_uri;

如果用户访问的是 www.example.com，会被跳到 example.com，虽然最终也能打开，但会丢一次请求，而且如果你后续要维护多个域名，写死一个域名会让其他域名全部跳到主域名，行为不可控。用 $host 变量则会自动保留用户输入的那个域名，更灵活。

3.5 证书自动续期，别让网站半夜悄悄废掉

Let's Encrypt证书有效期是90天，certbot安装时会自动添加续期定时任务。建议部署完后手动测试一遍续期流程：

bash复制certbot renew --dry-run

如果输出显示续期模拟成功，说明定时任务配置正确。再检查一下crontab：

bash复制crontab -l

里面应该有一条certbot的定时任务，通常每天执行两次，任务会自动判断证书剩余时间，少于30天才真正续期。

证书过期这件事有个迷惑性：Nginx不会报错，只是握手时返回的有效期是过去的，用户浏览器直接显示“您的连接不是私密连接”，很多人会误以为是DNS问题或服务器问题，反复重启Nginx、重启服务器，最后检查证书才恍然大悟。

4. 新手最容易忽略的错误细节清单

这一部分是我最想写的内容。很多问题不是你不会，而是根本没意识到它是一个“可以掉进去的坑”。

4.1 端口放行：安全组和防火墙是两套系统

服务器上的Nginx配置再好，如果云平台的安全组没有放行443端口，外部流量根本到不了Nginx。现在云服务器普遍有安全组概念，很多新手放行了22和80端口，唯独漏了443。这是一种很尴尬的状态：http能访问，https一直超时，但你自己在服务器本地curl 443是通的，因为本地回环不经过安全组。

所以，配置HTTPS后第一件事，去云控制台确认安全组出方向、入方向都放行了TCP 443端口，源地址按需限制（通常0.0.0.0/0即可）。同时确认服务器内部的防火墙（firewalld或ufw）也放行了443。

检查命令：

bash复制curl -I https://example.com

如果一直卡住没有响应，而http是通的，那90%的概率是443端口没放行。这时候用 telnet 检测一下端口：

bash复制telnet example.com 443

输出显示 Connected 说明端口通，显示 timeout 就是没放行。

4.2 混合内容：页面是HTTPS，但里面引用了HTTP资源

证书配置没问题，浏览器显示小锁了，但页面里如果引用了 http:// 开头的图片、JS、CSS，浏览器会拦截这些不安全资源。表现就是：有的图片加载不出来，或者页面交互功能异常，控制台有一堆“Mixed Content”报错。

排查方法是打开浏览器开发者工具的Console面板，找“Mixed Content”或“blocked by”关键词。修复时最好把所有资源引用改成相对路径或协议相对路径（//cdn.example.com/lib.js），这样自动跟随当前页面的协议。另一个方案是全站强制HTTPS后，把代码里所有 http:// 统一改成 https://，但要注意第三方接口是否支持HTTPS，有些旧接口只支持HTTP，强行改成https会调用失败，这类接口只能走白名单或服务端代理。

4.3 证书域名不匹配，IP访问当然会报错

如果你直接用 https://IP地址 访问，一定会看到证书警告，因为证书绑定的域名是 example.com，不是IP地址。这是正常现象，不是配置错误。

但有一种情况需要警惕：你配置了 example.com 的证书，然后访问 www.example.com 时也报错。如果证书是分开签的，或者只签了 example.com 没签 www.example.com，那 www 域名会提示不匹配。解决办法是申请证书时用 -d 参数把两个域名都包含进去，或者申请通配符证书 *.example.com。

4.4 301缓存导致的“改了没反应”

前面提到过301会被浏览器缓存，这里再扩展说一下。很多新手上线时先配了跳转，后来因为某些原因要撤销跳转，改完配置文件发现浏览器还是跳。这不是Nginx配置有问题，而是浏览器把老301存在本地了。

粗暴的解决办法是开无痕窗口测试，或者换个浏览器。如果用户那边已经缓存了，在响应头里加Cache-Control也不能完全覆盖浏览器对301的缓存策略，只能等缓存过期。所以我的习惯是：正式发布前用302测试，确认无误后再切成301。

4.5 DNS解析缓存导致配置了但没生效

DNS生效慢的原理和301缓存类似，只是缓存节点更多。本地操作系统会缓存DNS结果，路由器会缓存，本地DNS服务器会缓存，运营商递归DNS会缓存。改解析后的“一直不生效”，大概率是某一级缓存在作怪。

排查方法是分步验证：先用 dig @223.5.5.5 example.com 查询公共DNS服务器的结果，如果新IP已经出现，说明域名服务商侧的解析没问题，问题出在本地或中间链路。这时候耐心等，或者清一下本地缓存。Windows下命令是：

bash复制ipconfig /flushdns

macOS下：

bash复制sudo dscacheutil -flushcache

4.6 HSTS头设置的影响

HSTS是一种让浏览器强制执行HTTPS的安全机制。配置了HSTS后，浏览器在有效期内的任何时候都强制访问HTTPS，不给你回退HTTP的机会。好处是非常安全，坏处是如果未来某个时间你还没配HTTPS，用户就完全访问不了你的网站，连提示都没有。

所以新手阶段，我不建议一上来就开HSTS。等HTTPS稳定运行一段时间，确认不会频繁回退HTTP后，再逐步添加：

nginx复制add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

注意如果开了 includeSubDomains，那子域名的HTTP访问也会被强制跳HTTPS，万一某个子域名还没有证书，直接废掉。

4.7 证书私钥权限和备份

私钥文件需要严格控制权限。Nginx运行时一般以root启动，worker进程可能以nginx用户运行，但私钥文件读取只需要master进程有权限。我习惯把私钥设为600：

bash复制chmod 600 /etc/letsencrypt/live/example.com/privkey.pem

另外，证书和私钥要每月备份一次。Let's Encrypt自动续期后，live目录里的文件会更新，如果哪天误删了，恢复起来很麻烦。备份整个 /etc/letsencrypt 目录是最稳妥的做法。

5. 常见问题排查工具与命令速查

这部分是帮你在出问题时快速定位环节，不靠猜，靠证据说话。

5.1 按顺序排查的四个命令

遇到“网站打不开”，我建议依次跑下面四个命令：

bash复制# 第一步：确认解析
dig example.com +short
nslookup example.com

# 第二步：确认端口通不通
curl -I https://example.com

# 第三步：确认证书链是否完整
openssl s_client -connect example.com:443 -servername example.com -brief

# 第四步：确认Nginx是否在运行
systemctl status nginx

第一行看解析结果是否指向预期IP；第二行看HTTP响应头，如果是301跳转，说明Nginx在正常工作，问题在跳转配置或SSL握手；第三行看证书状态，重点看验证链和证书有效期；第四行确认Web服务进程状态。

5.2 常见故障现象与解决方案速查表

5.3 一个比较隐蔽的细节：证书链顺序问题

如果你不是用certbot生成的证书，而是手动拼接证书链，很容易把证书顺序搞错。正确顺序是：服务器证书在最上面，然后是中间证书，最后才可能是根证书（通常根证书不需要放在文件里，因为客户端已内置）。如果把根证书放在最前面，或者把中间证书放在服务器证书前面，Nginx会自动调整，但某些一致性要求严格的客户端会报错。

我建议直接用certbot生成的 fullchain.pem，不要手动拼接。如果确实需要自己拼，用下面的命令检查：

bash复制openssl crl2pkcs7 -nocrl -certfile fullchain.pem | openssl pkcs7 -print_certs -noout

输出列表里第一行应该是你的站点域名，后面是中间证书，顺序不对就调整文件内容。

6. 最后的实操体会

讲几个我个人踩过多次的小技巧。第一，修改任何DNS或HTTPS相关配置前，先在本地记录当前状态，比如执行一次 openssl s_client -brief，保留输出，改完再对比。这样出了问题能快速判断是改动导致的还是本来就有的问题。

第二，测试HTTPS最好用隐身模式，前面反复提到301缓存和HSTS缓存，这两个东西平时悄无声息，一旦你改配置，它们就能让你怀疑人生。

第三，Nginx配置任何SSL相关修改后，记得先检测再重载：

bash复制nginx -t
systemctl reload nginx

nginx -t 能帮你提前发现语法错误，避免线上服务直接挂掉。这是我见过新手（也包括以前的我）最常犯的操作顺序错误。

第四，如果你同时管理多个域名，建议统一在同一个服务器目录里放证书，比如 /etc/certs/，文件名用域名区分。目录层级不要套太深，不然后面找文件找到崩溃。

域名、DNS、HTTPS的配置没有高深的技术含量，但细节密度非常高。把这篇文章里提到的这些坑都过一遍，再按流程逐步配置，基本上就能做到一次上线、稳定运行。真遇到奇怪问题也不要慌，按第5节的四步排查顺序走，问题一定出在解析、端口、证书、服务这四个环节的某一个里。