云主机上如何设置DNS，配置前先看这几个坑

很多人买了云主机，系统装好、网站传上去，最后卡在 云主机上如何设置dns 这一步。看起来只是改几个地址，实际牵扯的是两套东西：域名怎么指到你的服务器，服务器自己又怎么去解析外部域名。这里一旦混在一起排查，就很容易出现“我这边能打开，别人打不开”“记录已经改了，怎么还没生效”这类情况。

这类问题别急着上来就改配置。先确认你遇到的是哪一层，再决定去哪里动手。

“设置DNS”通常是两件事

很多人在搜 云主机上如何设置dns 的时候，说的其实不是同一个问题。

• 域名解析层：把你的域名，比如 example.com，解析到云主机公网 IP。这个动作一般在域名注册商或 DNS 服务商后台完成。
• 主机系统层：在云主机操作系统里指定 DNS 服务器，让机器自己能正常解析外部域名，比如访问 api.xxx.com、下载软件包、连接第三方服务。

别人访问你，靠域名解析；你的云主机访问别人，靠系统 DNS。只改一边，另一边的问题不会自己消失。

场景一：把域名指向云主机

记录类型别选错

如果你是给网站、管理后台或者接口绑定域名，通常是在 DNS 控制台里添加解析记录。

• A 记录：域名直接指向 IPv4 地址，最常见。
• AAAA 记录：域名指向 IPv6 地址。
• CNAME 记录：一个域名指向另一个域名，常见于 CDN 或云产品别名接入。

比如云主机公网 IP 是 123.123.123.123，要把 www.example.com 指到这台服务器，添加一条 A 记录就够了。

常见配置别漏根域名和 www

常见写法通常是这样：

• 主机记录：@，记录值：123.123.123.123，对应 example.com
• 主机记录：www，记录值：123.123.123.123，对应 www.example.com

如果你的网站需要同时支持带 www 和不带 www，这两条一般都要配。DNS 配完以后，Nginx 或 Apache 里的站点配置也要把对应域名加进去，不然解析到了服务器，Web 服务还是可能接不住请求。

TTL 会影响切换节奏

很多人研究 云主机上如何设置dns，只盯着记录值，忽略了 TTL。这个参数决定解析结果会被缓存多久。上线前、迁移期、切换期，TTL 适合先设短一点，方便改动后更快生效；业务稳定以后再适当调高，减少频繁查询。

避坑提醒：TTL 调短，不等于全网立刻同步。已经缓存了旧记录的递归 DNS，还是要等缓存过期。

场景二：在云主机系统里设置 DNS 服务器

如果你的云主机表现为 yum/apt 更新失败、curl 域名报错、程序连不上外部 API，问题未必是网络断了，也可能是系统 DNS 解析异常。这个时候，讨论的才是更狭义的 云主机上如何设置dns。

Linux 常见修改位置

不同发行版做法不完全一样，但排查思路差不多：先看当前 DNS 配置，再确认是谁在管理它，最后再改。

传统方式里，很多人会先看 /etc/resolv.conf。里面常见内容类似：

nameserver 8.8.8.8
nameserver 1.1.1.1

这表示系统会优先用这些 DNS 服务器做解析。

但这里有个很常见的坑：很多云主机环境中，/etc/resolv.conf 只是结果文件，不一定是最终配置入口。它可能被 NetworkManager、systemd-resolved 或云平台网络服务自动生成。你手动改完看着生效，重启网络或重启机器又被覆盖，这种情况很常见。

Ubuntu / Debian 常见思路

新版本 Ubuntu 很多会用 netplan 或 systemd-resolved 管理网络。做法通常是在 netplan 对应网卡配置里写 nameservers，然后执行应用命令让配置生效。

如果系统启用了 systemd-resolved，还要确认本地 stub 解析是否正常。必要时，再通过它的配置文件指定上游 DNS。只盯着 resolv.conf 改，往往改不住。

CentOS / RHEL 常见思路

CentOS 系列常见做法是在网卡配置或 NetworkManager 里指定 DNS 地址。老版本可能直接写 ifcfg 网卡文件；新一些的环境里，更多是通过 nmcli 或图形化网络管理工具管理。

如果用的是云厂商提供的系统镜像，最好先确认平台默认下发了什么 DNS。有些镜像会附带内网 DNS，用来解析云数据库、对象存储、负载均衡等内网地址。你如果一口气全换成公共 DNS，外部域名可能能解析，云内服务反而出问题。

云主机上如何设置dns，排查顺序比命令更重要

实际处理时，建议按这个顺序来，不容易绕远路：

1. 先确认目标。你是要让域名指向云主机，还是让云主机能解析外部域名。目标不同，配置入口完全不同。
2. 先看现状。用 dig、nslookup 或 ping 域名，看看当前返回了什么。别在没确认现状前就开始改。
3. 如果是域名解析问题，去 DNS 控制台检查 A 记录、CNAME 记录、TTL，以及记录是不是填到了正确的公网 IP。
4. 如果是系统解析问题，检查 /etc/resolv.conf、NetworkManager、netplan、systemd-resolved，确认究竟是谁在接管 DNS。
5. 修改后别只看配置文件。要让网络配置真正生效，必要时清理缓存、重启对应服务，再测一次。
6. 最后看业务结果。能不能解析、能不能连通、应用日志里的报错有没有消失，都比“文件里写对了”更有参考价值。

一个常见场景：网站迁移后，部分用户还是访问旧服务器

网站迁移是最容易把 DNS 问题暴露出来的场景。代码拷到新云主机，数据库恢复，Nginx 配好，再把域名 A 记录切到新 IP，流程看着没问题，但上线后经常会遇到一个现象：公司内部看到的是新站，外部部分用户却还是旧页面。

这种情况，很多人会先怀疑 Nginx 缓存或者 CDN 缓存，结果排查半天才发现问题在 DNS。

常见原因通常有两个：

• 原先 TTL 设得比较长，很多地区的递归 DNS 还在缓存旧 IP。
• 老服务器没有及时下线，旧解析一旦命中，还是会继续返回旧页面。

这种迁移更稳妥的处理方式通常是：

1. 迁移前一天先把 TTL 调低，给正式切换留缓冲。
2. 正式切换时，把 A 记录改到新云主机公网 IP。
3. 老服务器别立刻删，先保留一个过渡页，至少不要继续提供旧内容。
4. 等主要地区解析基本完成，再彻底下线旧机器。

这个场景里，卡点通常出在切换过程是否平稳。很多人问 云主机上如何设置dns，实际也是在这里反复出问题。

公共 DNS 不一定比云厂商 DNS 更合适

一些教程喜欢直接给出几个公共 DNS 地址，让人照着填。但实际要不要用，还是得看业务环境。

• 主要访问公网资源：稳定的公共 DNS 往往可以正常使用。
• 频繁访问云厂商内网服务：保留平台推荐 DNS 通常更稳，少出兼容问题。
• 业务对容灾有要求：可以考虑主备 DNS 混合配置，但要提前确认系统和应用是否兼容这种写法。

所以讨论 云主机上如何设置dns，要先看当前架构，再选不冲突的方案。单看某个 DNS 地址“名气大不大”，参考意义并不高。

改完以后，别忘了验证这几项

• 用 dig 或 nslookup 看返回结果：先确认解析结果是不是你预期的 IP。
• 用 ping 或 curl 测试访问：能解析不代表服务一定通，至少要测到应用层。
• 检查应用日志：如果之前报的是“域名无法解析”，改完后这里通常最先反映变化。
• 做多环境验证：网站业务最好换几个网络环境测试，别只在自己办公室网络里看结果。

如果你改的是域名指向，还要顺手检查安全组、防火墙、Nginx 站点配置。DNS 配对了，但 80 或 443 端口没放开，用户照样访问失败。这个误判也很多。

几个最容易踩的坑

• 只改云主机，不改域名解析：服务器本机解析正常，但域名根本没有指到这台机器。
• 只改域名解析，不管本机 DNS：用户能访问网站，服务器自己却连不上外部服务。
• 直接手改 resolv.conf：改完一时有效，重启后又被网络管理服务覆盖。
• 忽略 TTL：记录改了，就以为所有地区都会马上更新。
• 公共 DNS 换得太彻底：外网解析没问题，云平台内网域名却开始异常。

把这些坑避开，云主机上如何设置dns 这件事就会清楚很多：先分清是域名解析层，还是操作系统层；再按场景去改对应配置；最后用实际访问结果验证。这样处理，排障效率会高很多，也不容易改出新问题。