如果你在 Linux 上排查网络问题打开 /etc/resolv.conf 后看到一行nameserver 127.0.1.1大概率会觉得它有点眼熟又有点说不清道不明。它不像是 192.168.x.x 那样一目了然的局域网地址也不像 127.0.0.1 那样张口就能说出“这是本机回环”按说 127.0.0.1 和 127.0.1.1 都是本机地址但实际行为却可能完全不同。这篇文章我就把这两件事一次性讲透nameserver 127.0.1.1 到底是从哪儿冒出来的以及当你需要把它改成真正的 DNS 服务器时应该改哪个文件、用哪条命令、怎么避免重启之后又被打回原形。这篇内容更适合两类读者一类是刚接触 Linux 网络配置没多久的新手被某个发行版或桌面环境的默认配置搞得云里雾里另一类是自己维护服务器、经常和 DNS 打交道的人想搞清楚系统里到底是谁在“管” DNS把配置权从某个隐藏服务手里拿回来。不管你是哪种情况下面这套排查思路和操作命令都能直接拿去用。1. nameserver 127.0.1.1 是怎么回事1.1 先分清 127.0.0.1 和 127.0.1.1 的区别在大多数人的印象里127.x.x.x 都是回环地址发到这个网段的数据包不会离开本机。这个理解没错但我得强调一点整个 127.0.0.0/8 地址段都属于本机可 Linux 内核和很多应用软件并不把它们按一个整体来处理。127.0.0.1 是标准的 localhost 地址几乎所有程序都知道它代表本机。而 127.0.1.1 则更像一个“备用本机地址”通常被某些 Linux 发行版用来解决主机名解析的冲突问题。比如在一台 Debian 系主机上/etc/hosts 里经常能看到这样的内容127.0.0.1 localhost 127.0.1.1 myhostname第一行让 localhost 指向本机第二行让本机的主机名也指向本机。因为有些程序会根据主机名反查 IP如果直接把主机名也写在127.0.0.1 localhost那一行某些老式网络服务会分不清 localhost 和真实主机名于是发行版作者引入了 127.0.1.1 这个地址来承载主机名避免踩坑。但问题在于127.0.1.1并不只是出现在 /etc/hosts 里它还可能出现在 /etc/resolv.conf 里这就是大家看到nameserver 127.0.1.1的直接场景。resolv.conf 里的 nameserver 指的是“本机发起 DNS 查询时要发往的服务器地址”它可以是局域网里的一台真实解析服务器也可以是一个本机正在监听的本地解析程序。127.0.1.1 能出现在这里说明系统里某个 DNS 服务正在这个地址上监听或者某个配置工具约定俗成地把它写成了 stub 地址。1.2 它出现在 resolv.conf 里的两种常见来历要理解这一行配置不能只盯着文件本身还得知道它背后是谁在写。resolv.conf 在绝大多数现代发行版里已经不是一个“你手动改完就结束”的静态文件了它经常是由某个网络管理服务动态生成的。出现nameserver 127.0.1.1通常有两种情况。第一种情况系统里装了一个轻量级的本地 DNS 转发器常见角色是 dnsmasq。很多桌面发行版会默认启动 dnsmasq让它监听在 127.0.1.1 或者其他回环地址上然后 resolv.conf 里的 nameserver 就指向这个本地转发器。本地转发器收到查询请求后再转发给上游 DNS。这样做的价值在于可以缓存解析结果、支持按域名分流还能让依赖“本机 53 端口”的工具正常工作。第二种情况和主机名绑定有关。有些发行版的脚本工具在检测到系统的主机名时会顺手把nameserver 127.0.1.1当成一个可用的回环解析地址写进配置里。这种情况未必会有程序真正监听在 127.0.1.1 的 53 端口如果查询真被发过去就会超时或失败。这也是为什么有些人打开网络没大毛病有些人却发现ping一个域名要卡好几秒才出结果配置改动来源不一样行为就有天壤之别。不管是哪种来历关键结论都一样nameserver 127.0.1.1 本身不是错误但你必须搞清楚它背后有没有一个真正在收包的进程。这一节先留个悬念下一节我把完整的 DNS 管理链路铺开讲。2. 设置 nameserver 前先看清系统当前的 DNS 管理链路2.1 resolv.conf 只是结果不是根源新手最容易犯的错就是拿编辑器直接改 /etc/resolv.conf。改完之后cat一看内容确实变了测试nslookup也通了结果网卡一重启、NetworkManager 一重载文件又回到原来的样子。原因很简单这个文件在大多数环境里是由服务生成的你手动改的内容会被覆盖。想真正做好“设置 nameserver”这件事得先弄清系统里是谁拥有 resolv.conf 的“最终解释权”。不同的发行版、不同的桌面环境采用的机制各有差异但核心就那几类NetworkManager、systemd-resolved、resolvconf 工具包、纯手动静态配置。我把这几种机制的典型特征整理成了一张表方便你对照自己的系统快速定位机制常见发行版resolv.conf 典型内容修改方式NetworkManager 直接接管桌面版 Ubuntu、Fedora 等nameserver 127.0.0.53或具体的上游地址用 nmcli 或图形界面改 connection 的 DNS 设置systemd-resolved 监听回环启用该服务的发行版nameserver 127.0.0.53改 netplan、resolvectl 或直接配置 systemd-resolveddnsmasq 本地转发部分桌面环境或嵌入式系统nameserver 127.0.0.1或127.0.1.1停止 dnsmasq 监听或调整上游配置resolvconf 工具管理Debian/Ubuntu 传统方案由 /etc/resolvconf/ 下的配置合并生成修改接口配置或直接配置 resolvconf纯静态文件多数服务器精简环境手动写入的 nameserver 记录直接编辑文件并关闭其他改写机制从这个表能看出来同样看到nameserver 127.0.1.1在不同系统里的修法完全不一样。不看机制就动手后面必然要反复返工。2.2 一条实用的判别命令不想猜的话直接用一条命令看 resolv.conf 的软链接指向往往能省掉大半排查时间ls -l /etc/resolv.conf如果输出里有-箭头说明文件被软链接引到了其他地方。看到/run/systemd/resolve/stub-resolv.conf那基本就是 systemd-resolved 在管理看到/run/NetworkManager/resolv.conf就是 NetworkManager 在管理看到/etc/resolvconf/run/resolv.conf就是 resolvconf 工具在管理。这些信息能直接决定你接下来动哪个服务。我自己的习惯是先执行这条命令再执行ss -lunp | grep :53看看本机 53 端口到底有谁在监听。如果 127.0.1.1 确实对应某个进程那就走本地转发器配置如果 53 端口什么都没有那 nameserver 127.0.1.1 多半是无效配置改了更踏实。2.3 理解查询流向比背命令更重要设置 nameserver 之前脑子里得先过一遍 DNS 查询的完整路径。拿一个普通的 DNS 查询举例浏览器发起解析请求系统读 resolv.conf把请求发给第一个 nameserver如果第一个超时再试第二个直到有响应。nameserver 列表不是“投票表决”而是“按顺序排队”。所以当你看到nameserver 127.0.1.1排在第一行就要追问一个问题这个地址是否存在并可用。它存在且监听 53 端口就相当于本地多了一个缓存层它不存在那每次查询都白等一个超时周期然后再跳下一个后果就是所有域名解析都慢上半拍。很多“上网时好时坏”的诡异现象最后都能追到这里。3. 如何正确设置 nameserver临时改和永久改3.1 临时调试直接写 resolv.conf 只适合测如果你想快速验证某个 DNS 能不能用临时改文件是没问题的。步骤就是下面这几行sudo cp /etc/resolv.conf /etc/resolv.conf.bak sudo sh -c echo nameserver 192.168.1.1 /etc/resolv.conf然后立刻用resolvectl query或nslookup验证。测完想恢复就把备份拷回来sudo cp /etc/resolv.conf.bak /etc/resolv.conf这种方法只能作为“探测”不能作为长期方案。因为只要系统里任何一个网络管理服务感知到网络状态变化都可能重新生成这个文件你的手工配置就会消失。那种“明明改了却一夜回到解放前”的经历十有八九就是这么来的。3.2 用 NetworkManager 管理nmcli 配置桌面系统或者用 NetworkManager 管理网络的服务器推荐走 nmcli改的是连接配置不是那个容易被覆盖的临时文件。先用命令找到当前网卡的连接名nmcli connection show比如活动连接叫有线连接 1需要给网卡设置两个 DNS同时清掉其他无用的 nameserver可以这样操作nmcli connection modify 有线连接 1 ipv4.dns 192.168.1.1 8.8.8.8 nmcli connection modify 有线连接 1 ipv4.ignore-auto-dns yes nmcli connection up 有线连接 1第一条写入 DNS 列表第二条禁止 DHCP 自动覆盖 DNS第三条重新激活连接让配置生效。这样处理之后NetworkManager 每次生成 resolv.conf 都会包含你指定的 DNS重启也不会丢。ipv4.ignore-auto-dns这个参数容易被人忽略但它是“改完不被 DHCP 覆盖”的关键。DHCP 服务端经常会下发自己的 DNS 地址如果这个选项没打开系统会根据 DHCP 重新生成配置你手动指定的值就会被替换掉。3.3 systemd-resolved 专用命令resolvectl如果系统用的是 systemd-resolved并且 resolv.conf 软链接指向 stub 文件那就不能用 nmcli 直接改 DNS至少不推荐。systemd-resolved 有它自己的控制命令。先看当前状态resolvectl status这个命令会列出每个网卡的 DNS 服务器、搜索域和当前的解析结果。需要给某个网卡手动指定 DNS 时可以这样写sudo resolvectl dns eth0 192.168.1.1 8.8.8.8 sudo resolvectl domain eth0 example.com第一条设置 DNS 列表第二条设置搜索域。如果系统里启用了 DHCP又希望在 DHCP 之下保留自己的 DNS仍然要处理“自动覆盖”问题。systemd-resolved 的覆盖逻辑比较复杂有人会选择直接把 stub 模式关掉把 DNS 设置变成传统方式sudo systemctl disable systemd-resolved sudo systemctl stop systemd-resolved sudo rm /etc/resolv.conf sudo sh -c echo nameserver 192.168.1.1 /etc/resolv.conf这是一种并不优雅但很直接的退出机制适合服务器场景。桌面环境不建议这样搞因为一旦停掉 systemd-resolved和 DHCP、域名搜索相关的联动逻辑都会失效。3.4 用 resolvconf 统一生成配置Debian/Ubuntu 这类发行版虽然默认不一定装 resolvconf 包但一旦装了它就会接管 resolv.conf 的生成权限。这种情况下改的入口不是 resolv.conf 本身而是接口配置文件。支持 resolvconf 的模板入口在/etc/network/interfaces.d/或 NetworkManager 的配置里。传统做法是在网卡配置里写上dns-nameservers 192.168.1.1 dns-search example.com之后执行sudo resolvconf -u重新生成配置。注意这种方式依赖 resolvconf 服务的正确安装。如果你在一个新系统里发现/etc/resolv.conf文件是被某进程动态覆盖的又找不到前面的几种机制就很有可能是它在远程操作。4. 实操复盘把 127.0.1.1 换成实际 DNS 的一次完整记录4.1 一次具体示例我之前在一台旧版 Debian 服务器上排查过一次类似问题。那个系统里 resolv.conf 最初是nameserver 127.0.1.1我用ss -lunp | grep :53一看没有任何进程监听 53 端口等于说所有 DNS 请求都卡死在这个无效回环地址上。原因可能是安装某个软件时残留了 dnsmasq 的配置也可能是系统自动生成的 stub 地址被错误保留下来。这台服务器的网络拓扑很简单网卡 eth0 使用静态 IP网关是 192.168.1.1局域网里有一台专门做 DNS 转发的设备地址是 192.168.1.10。于是我需要把 nameserver 从 127.0.1.1 改成 192.168.1.10。4.2 具体实施步骤记录第一步确认是谁在管理 resolv.conf。我直接查看软链接ls -l /etc/resolv.conf结果是普通文件没有箭头说明没有服务通过软链接接管它。但我不能就此以为它不会被覆盖因为 NetworkManager 在没有软链接的模式下也可能直接写文件。于是又执行了nmcli device status结果这台服务器没有运行 NetworkManager也没有 dhclient 在跑逻辑链路一下子清楚了这基本就是一个手动静态管理的网络环境。第二步备份现有配置sudo cp /etc/resolv.conf /etc/resolv.conf.bak第三步写入新的 nameserversudo sh -c printf nameserver 192.168.1.10\nsearch example.com\n /etc/resolv.conf我这里顺手把search example.com也写了。它解决的是短主机名解析问题比如你在内网有时访问gitlab而不是gitlab.example.com如果 search 域里写了 example.com系统会自动补全成gitlab.example.com再查。这个配置可按需添加很多人只改了 DNS却忘了搜索域内网短名解析仍然时灵时不灵。第四步立即验证解析nslookup example.com ping -c 4 example.com同时用resolvectl查看系统解析状态确保之前那个监听地址确实没有被跳过。验证完成之后再观察一次重启后的变化。因为这是一台手动配置的服务器重启后 resolv.conf 没有被覆盖说明机制判断正确问题真正解决。4.3 这背后有一个判断逻辑回头看这次操作真正关键的并不是执行一遍命令而是先确认了“文件不会被外部服务覆盖”。如果你跳过这一步直接改文件后续可能出现两种结果一是配置被覆盖现象复发二是配置保留下来但系统里同时存在一个 local stub 服务导致请求被本地监听程序截走nameserver 改了半天也没效果。所以我建议每个改 DNS 的场景都遵循同一套思路先看软链接、再看 53 端口监听、再确认网络管理服务是谁、最后才是改配置。顺序反了每一步都有可能是盲改。5. 常见坑与排查经验5.1 改完重启又变回 127.0.1.1如果每次重启后 nameserver 都会被重置十有八九是某个管理服务还在全权接管网络。NetworkManager 是最常见的一个它启动后会把 resolv.conf 改成自己的一份模板模板里的 nameserver 来源包括 DHCP、连接配置、系统 stub。解决方式已经很明确用nmcli connection modify修改对应连接并设置ipv4.ignore-auto-dns yes。如果是 dnsmasq 在捣乱就检查 dnsmasq 的配置文件确认它监听的地址和上游 DNS 是否正确实在不需要它就可以直接停掉。有一种特殊情况你在/etc/resolv.conf的文件属性上加过不可变标志比如用chattr i锁定文件这样服务虽然能写但会被内核拒绝。这种做法适合应急却不适合长期因为它会让系统的网络管理状态和实际配置脱节下次排查时又得额外检查属性。5.2 “主机名解析不过去”跟它有关前面提过很多发行版会在 /etc/hosts 里把主机名指到 127.0.1.1。如果你发现hostname查出来是某个名字但 ping 这个名字时解析不到 IP问题往往不在 resolv.conf而在 /etc/hosts。有人会故意把主机名从 hosts 文件里去掉指望靠 DNS 来解析主机名。这时如果 resolv.conf 又写着一个不起作用的 127.0.1.1主机名解析就会失败。遇到“某些机器之间用主机名互通有问题”的现象先去 ping IP再去 ping 主机名然后把 /etc/hosts 和 resolv.conf 放一起对照思路就清晰了。5.3 本地监听进程占住了 53 端口nameserver 127.0.1.1能正常工作的前提是有一个进程真正监听在这个地址的 53 端口。如果该进程是 dnsmasq你改 nameserver 时不能只改 resolv.conf还得改 dnsmasq 的上游配置。否则你只是让客户端不再往本地转发器发请求本地转发器怎么向上游发请求依然没变。具体来说dnsmasq 的配置文件通常在/etc/dnsmasq.conf里面可能通过server指定上游 DNS。你真正想设置 nameserver 时应该把 resolv.conf 里的本机地址保留让请求先到 dnsmasq再由 dnsmasq 按照它自己的上游配置转发。这也是很多桌面环境默认开本地转发器被吐槽的原因用户以为改一个文件就好实际上要改两层。5.4 修改后测试仍失败先清缓存改完 DNS 后用 nslookup 测试失败有很多人第一反应是配置写错了但其实系统里的解析缓存还在。systemd-resolved 自己带缓存dnsmasq 也带某些程序像 nscd 也会缓存。清 systemd-resolved 的缓存sudo resolvectl flush-caches清 dnsmasq 的缓存可以用它自带的接口触达也可以通过重启 dnsmasq 服务实现。如果不想清缓存又必须马上验证可以换一个工具或者换一个之前没查过的域名来测试。比如你刚改了 DNS就用一个冷门域名去试这样能把缓存干扰降到最低。6. 关于 nameserver 配置我留下的几个小习惯我自己处理过不少类似的 DNS 配置问题整个过程踩过很多次坑最后总结成几个习惯写在这里当个收尾。第一永远在改 resolv.conf 之前先问一句“它会被谁覆盖”。软链接、nmcli、systemd-resolved、resolvconf随便哪个在背后运行都可能让你的改动无效。先看清机制后面操作才不会被覆盖。第二nameserver 127.0.1.1 这个地址本身不用怕它就是一个“本机 DNS 监听位置”的标记。重点是你得确认那里确实有个进程在监听。没有进程它就是僵尸地址有进程它就是本地缓存层。判断速度很快ss -lunp | grep :53几秒钟就有结论。第三如果只是想临时测试某个解析服务器直接改文件没问题但别忘了备份。如果想让配置长期生效务必沿着系统自带的网络管理入口去改不要跟自动生成机制硬碰硬。第四遇到看不懂的配置先保留现场。我一般会把 /etc/resolv.conf、/etc/hosts、网卡配置文件和 service 状态分别存一份改一步记一步再验证一步。DNS 相关的坑往往都藏在“多个服务互相改写同一个文件”的纠缠里留下现场能省掉大量回头排查的时间。这次聊到这儿配置命令都给得很具体了拿着去对照自己的系统试一圈多半能把 nameserver 127.0.1.1 的来龙去脉搞清楚。如果你遇到的情况正好是那种 53 端口没有进程但文件里还留着 127.0.1.1 的僵尸配置那就按我第 4 节的步骤处理大概率能一步到位。
如果你在 Linux 上排查网络问题打开 /etc/resolv.conf 后看到一行nameserver 127.0.1.1大概率会觉得它有点眼熟又有点说不清道不明。它不像是 192.168.x.x 那样一目了然的局域网地址也不像 127.0.0.1 那样张口就能说出“这是本机回环”按说 127.0.0.1 和 127.0.1.1 都是本机地址但实际行为却可能完全不同。这篇文章我就把这两件事一次性讲透nameserver 127.0.1.1 到底是从哪儿冒出来的以及当你需要把它改成真正的 DNS 服务器时应该改哪个文件、用哪条命令、怎么避免重启之后又被打回原形。这篇内容更适合两类读者一类是刚接触 Linux 网络配置没多久的新手被某个发行版或桌面环境的默认配置搞得云里雾里另一类是自己维护服务器、经常和 DNS 打交道的人想搞清楚系统里到底是谁在“管” DNS把配置权从某个隐藏服务手里拿回来。不管你是哪种情况下面这套排查思路和操作命令都能直接拿去用。1. nameserver 127.0.1.1 是怎么回事1.1 先分清 127.0.0.1 和 127.0.1.1 的区别在大多数人的印象里127.x.x.x 都是回环地址发到这个网段的数据包不会离开本机。这个理解没错但我得强调一点整个 127.0.0.0/8 地址段都属于本机可 Linux 内核和很多应用软件并不把它们按一个整体来处理。127.0.0.1 是标准的 localhost 地址几乎所有程序都知道它代表本机。而 127.0.1.1 则更像一个“备用本机地址”通常被某些 Linux 发行版用来解决主机名解析的冲突问题。比如在一台 Debian 系主机上/etc/hosts 里经常能看到这样的内容127.0.0.1 localhost 127.0.1.1 myhostname第一行让 localhost 指向本机第二行让本机的主机名也指向本机。因为有些程序会根据主机名反查 IP如果直接把主机名也写在127.0.0.1 localhost那一行某些老式网络服务会分不清 localhost 和真实主机名于是发行版作者引入了 127.0.1.1 这个地址来承载主机名避免踩坑。但问题在于127.0.1.1并不只是出现在 /etc/hosts 里它还可能出现在 /etc/resolv.conf 里这就是大家看到nameserver 127.0.1.1的直接场景。resolv.conf 里的 nameserver 指的是“本机发起 DNS 查询时要发往的服务器地址”它可以是局域网里的一台真实解析服务器也可以是一个本机正在监听的本地解析程序。127.0.1.1 能出现在这里说明系统里某个 DNS 服务正在这个地址上监听或者某个配置工具约定俗成地把它写成了 stub 地址。1.2 它出现在 resolv.conf 里的两种常见来历要理解这一行配置不能只盯着文件本身还得知道它背后是谁在写。resolv.conf 在绝大多数现代发行版里已经不是一个“你手动改完就结束”的静态文件了它经常是由某个网络管理服务动态生成的。出现nameserver 127.0.1.1通常有两种情况。第一种情况系统里装了一个轻量级的本地 DNS 转发器常见角色是 dnsmasq。很多桌面发行版会默认启动 dnsmasq让它监听在 127.0.1.1 或者其他回环地址上然后 resolv.conf 里的 nameserver 就指向这个本地转发器。本地转发器收到查询请求后再转发给上游 DNS。这样做的价值在于可以缓存解析结果、支持按域名分流还能让依赖“本机 53 端口”的工具正常工作。第二种情况和主机名绑定有关。有些发行版的脚本工具在检测到系统的主机名时会顺手把nameserver 127.0.1.1当成一个可用的回环解析地址写进配置里。这种情况未必会有程序真正监听在 127.0.1.1 的 53 端口如果查询真被发过去就会超时或失败。这也是为什么有些人打开网络没大毛病有些人却发现ping一个域名要卡好几秒才出结果配置改动来源不一样行为就有天壤之别。不管是哪种来历关键结论都一样nameserver 127.0.1.1 本身不是错误但你必须搞清楚它背后有没有一个真正在收包的进程。这一节先留个悬念下一节我把完整的 DNS 管理链路铺开讲。2. 设置 nameserver 前先看清系统当前的 DNS 管理链路2.1 resolv.conf 只是结果不是根源新手最容易犯的错就是拿编辑器直接改 /etc/resolv.conf。改完之后cat一看内容确实变了测试nslookup也通了结果网卡一重启、NetworkManager 一重载文件又回到原来的样子。原因很简单这个文件在大多数环境里是由服务生成的你手动改的内容会被覆盖。想真正做好“设置 nameserver”这件事得先弄清系统里是谁拥有 resolv.conf 的“最终解释权”。不同的发行版、不同的桌面环境采用的机制各有差异但核心就那几类NetworkManager、systemd-resolved、resolvconf 工具包、纯手动静态配置。我把这几种机制的典型特征整理成了一张表方便你对照自己的系统快速定位机制常见发行版resolv.conf 典型内容修改方式NetworkManager 直接接管桌面版 Ubuntu、Fedora 等nameserver 127.0.0.53或具体的上游地址用 nmcli 或图形界面改 connection 的 DNS 设置systemd-resolved 监听回环启用该服务的发行版nameserver 127.0.0.53改 netplan、resolvectl 或直接配置 systemd-resolveddnsmasq 本地转发部分桌面环境或嵌入式系统nameserver 127.0.0.1或127.0.1.1停止 dnsmasq 监听或调整上游配置resolvconf 工具管理Debian/Ubuntu 传统方案由 /etc/resolvconf/ 下的配置合并生成修改接口配置或直接配置 resolvconf纯静态文件多数服务器精简环境手动写入的 nameserver 记录直接编辑文件并关闭其他改写机制从这个表能看出来同样看到nameserver 127.0.1.1在不同系统里的修法完全不一样。不看机制就动手后面必然要反复返工。2.2 一条实用的判别命令不想猜的话直接用一条命令看 resolv.conf 的软链接指向往往能省掉大半排查时间ls -l /etc/resolv.conf如果输出里有-箭头说明文件被软链接引到了其他地方。看到/run/systemd/resolve/stub-resolv.conf那基本就是 systemd-resolved 在管理看到/run/NetworkManager/resolv.conf就是 NetworkManager 在管理看到/etc/resolvconf/run/resolv.conf就是 resolvconf 工具在管理。这些信息能直接决定你接下来动哪个服务。我自己的习惯是先执行这条命令再执行ss -lunp | grep :53看看本机 53 端口到底有谁在监听。如果 127.0.1.1 确实对应某个进程那就走本地转发器配置如果 53 端口什么都没有那 nameserver 127.0.1.1 多半是无效配置改了更踏实。2.3 理解查询流向比背命令更重要设置 nameserver 之前脑子里得先过一遍 DNS 查询的完整路径。拿一个普通的 DNS 查询举例浏览器发起解析请求系统读 resolv.conf把请求发给第一个 nameserver如果第一个超时再试第二个直到有响应。nameserver 列表不是“投票表决”而是“按顺序排队”。所以当你看到nameserver 127.0.1.1排在第一行就要追问一个问题这个地址是否存在并可用。它存在且监听 53 端口就相当于本地多了一个缓存层它不存在那每次查询都白等一个超时周期然后再跳下一个后果就是所有域名解析都慢上半拍。很多“上网时好时坏”的诡异现象最后都能追到这里。3. 如何正确设置 nameserver临时改和永久改3.1 临时调试直接写 resolv.conf 只适合测如果你想快速验证某个 DNS 能不能用临时改文件是没问题的。步骤就是下面这几行sudo cp /etc/resolv.conf /etc/resolv.conf.bak sudo sh -c echo nameserver 192.168.1.1 /etc/resolv.conf然后立刻用resolvectl query或nslookup验证。测完想恢复就把备份拷回来sudo cp /etc/resolv.conf.bak /etc/resolv.conf这种方法只能作为“探测”不能作为长期方案。因为只要系统里任何一个网络管理服务感知到网络状态变化都可能重新生成这个文件你的手工配置就会消失。那种“明明改了却一夜回到解放前”的经历十有八九就是这么来的。3.2 用 NetworkManager 管理nmcli 配置桌面系统或者用 NetworkManager 管理网络的服务器推荐走 nmcli改的是连接配置不是那个容易被覆盖的临时文件。先用命令找到当前网卡的连接名nmcli connection show比如活动连接叫有线连接 1需要给网卡设置两个 DNS同时清掉其他无用的 nameserver可以这样操作nmcli connection modify 有线连接 1 ipv4.dns 192.168.1.1 8.8.8.8 nmcli connection modify 有线连接 1 ipv4.ignore-auto-dns yes nmcli connection up 有线连接 1第一条写入 DNS 列表第二条禁止 DHCP 自动覆盖 DNS第三条重新激活连接让配置生效。这样处理之后NetworkManager 每次生成 resolv.conf 都会包含你指定的 DNS重启也不会丢。ipv4.ignore-auto-dns这个参数容易被人忽略但它是“改完不被 DHCP 覆盖”的关键。DHCP 服务端经常会下发自己的 DNS 地址如果这个选项没打开系统会根据 DHCP 重新生成配置你手动指定的值就会被替换掉。3.3 systemd-resolved 专用命令resolvectl如果系统用的是 systemd-resolved并且 resolv.conf 软链接指向 stub 文件那就不能用 nmcli 直接改 DNS至少不推荐。systemd-resolved 有它自己的控制命令。先看当前状态resolvectl status这个命令会列出每个网卡的 DNS 服务器、搜索域和当前的解析结果。需要给某个网卡手动指定 DNS 时可以这样写sudo resolvectl dns eth0 192.168.1.1 8.8.8.8 sudo resolvectl domain eth0 example.com第一条设置 DNS 列表第二条设置搜索域。如果系统里启用了 DHCP又希望在 DHCP 之下保留自己的 DNS仍然要处理“自动覆盖”问题。systemd-resolved 的覆盖逻辑比较复杂有人会选择直接把 stub 模式关掉把 DNS 设置变成传统方式sudo systemctl disable systemd-resolved sudo systemctl stop systemd-resolved sudo rm /etc/resolv.conf sudo sh -c echo nameserver 192.168.1.1 /etc/resolv.conf这是一种并不优雅但很直接的退出机制适合服务器场景。桌面环境不建议这样搞因为一旦停掉 systemd-resolved和 DHCP、域名搜索相关的联动逻辑都会失效。3.4 用 resolvconf 统一生成配置Debian/Ubuntu 这类发行版虽然默认不一定装 resolvconf 包但一旦装了它就会接管 resolv.conf 的生成权限。这种情况下改的入口不是 resolv.conf 本身而是接口配置文件。支持 resolvconf 的模板入口在/etc/network/interfaces.d/或 NetworkManager 的配置里。传统做法是在网卡配置里写上dns-nameservers 192.168.1.1 dns-search example.com之后执行sudo resolvconf -u重新生成配置。注意这种方式依赖 resolvconf 服务的正确安装。如果你在一个新系统里发现/etc/resolv.conf文件是被某进程动态覆盖的又找不到前面的几种机制就很有可能是它在远程操作。4. 实操复盘把 127.0.1.1 换成实际 DNS 的一次完整记录4.1 一次具体示例我之前在一台旧版 Debian 服务器上排查过一次类似问题。那个系统里 resolv.conf 最初是nameserver 127.0.1.1我用ss -lunp | grep :53一看没有任何进程监听 53 端口等于说所有 DNS 请求都卡死在这个无效回环地址上。原因可能是安装某个软件时残留了 dnsmasq 的配置也可能是系统自动生成的 stub 地址被错误保留下来。这台服务器的网络拓扑很简单网卡 eth0 使用静态 IP网关是 192.168.1.1局域网里有一台专门做 DNS 转发的设备地址是 192.168.1.10。于是我需要把 nameserver 从 127.0.1.1 改成 192.168.1.10。4.2 具体实施步骤记录第一步确认是谁在管理 resolv.conf。我直接查看软链接ls -l /etc/resolv.conf结果是普通文件没有箭头说明没有服务通过软链接接管它。但我不能就此以为它不会被覆盖因为 NetworkManager 在没有软链接的模式下也可能直接写文件。于是又执行了nmcli device status结果这台服务器没有运行 NetworkManager也没有 dhclient 在跑逻辑链路一下子清楚了这基本就是一个手动静态管理的网络环境。第二步备份现有配置sudo cp /etc/resolv.conf /etc/resolv.conf.bak第三步写入新的 nameserversudo sh -c printf nameserver 192.168.1.10\nsearch example.com\n /etc/resolv.conf我这里顺手把search example.com也写了。它解决的是短主机名解析问题比如你在内网有时访问gitlab而不是gitlab.example.com如果 search 域里写了 example.com系统会自动补全成gitlab.example.com再查。这个配置可按需添加很多人只改了 DNS却忘了搜索域内网短名解析仍然时灵时不灵。第四步立即验证解析nslookup example.com ping -c 4 example.com同时用resolvectl查看系统解析状态确保之前那个监听地址确实没有被跳过。验证完成之后再观察一次重启后的变化。因为这是一台手动配置的服务器重启后 resolv.conf 没有被覆盖说明机制判断正确问题真正解决。4.3 这背后有一个判断逻辑回头看这次操作真正关键的并不是执行一遍命令而是先确认了“文件不会被外部服务覆盖”。如果你跳过这一步直接改文件后续可能出现两种结果一是配置被覆盖现象复发二是配置保留下来但系统里同时存在一个 local stub 服务导致请求被本地监听程序截走nameserver 改了半天也没效果。所以我建议每个改 DNS 的场景都遵循同一套思路先看软链接、再看 53 端口监听、再确认网络管理服务是谁、最后才是改配置。顺序反了每一步都有可能是盲改。5. 常见坑与排查经验5.1 改完重启又变回 127.0.1.1如果每次重启后 nameserver 都会被重置十有八九是某个管理服务还在全权接管网络。NetworkManager 是最常见的一个它启动后会把 resolv.conf 改成自己的一份模板模板里的 nameserver 来源包括 DHCP、连接配置、系统 stub。解决方式已经很明确用nmcli connection modify修改对应连接并设置ipv4.ignore-auto-dns yes。如果是 dnsmasq 在捣乱就检查 dnsmasq 的配置文件确认它监听的地址和上游 DNS 是否正确实在不需要它就可以直接停掉。有一种特殊情况你在/etc/resolv.conf的文件属性上加过不可变标志比如用chattr i锁定文件这样服务虽然能写但会被内核拒绝。这种做法适合应急却不适合长期因为它会让系统的网络管理状态和实际配置脱节下次排查时又得额外检查属性。5.2 “主机名解析不过去”跟它有关前面提过很多发行版会在 /etc/hosts 里把主机名指到 127.0.1.1。如果你发现hostname查出来是某个名字但 ping 这个名字时解析不到 IP问题往往不在 resolv.conf而在 /etc/hosts。有人会故意把主机名从 hosts 文件里去掉指望靠 DNS 来解析主机名。这时如果 resolv.conf 又写着一个不起作用的 127.0.1.1主机名解析就会失败。遇到“某些机器之间用主机名互通有问题”的现象先去 ping IP再去 ping 主机名然后把 /etc/hosts 和 resolv.conf 放一起对照思路就清晰了。5.3 本地监听进程占住了 53 端口nameserver 127.0.1.1能正常工作的前提是有一个进程真正监听在这个地址的 53 端口。如果该进程是 dnsmasq你改 nameserver 时不能只改 resolv.conf还得改 dnsmasq 的上游配置。否则你只是让客户端不再往本地转发器发请求本地转发器怎么向上游发请求依然没变。具体来说dnsmasq 的配置文件通常在/etc/dnsmasq.conf里面可能通过server指定上游 DNS。你真正想设置 nameserver 时应该把 resolv.conf 里的本机地址保留让请求先到 dnsmasq再由 dnsmasq 按照它自己的上游配置转发。这也是很多桌面环境默认开本地转发器被吐槽的原因用户以为改一个文件就好实际上要改两层。5.4 修改后测试仍失败先清缓存改完 DNS 后用 nslookup 测试失败有很多人第一反应是配置写错了但其实系统里的解析缓存还在。systemd-resolved 自己带缓存dnsmasq 也带某些程序像 nscd 也会缓存。清 systemd-resolved 的缓存sudo resolvectl flush-caches清 dnsmasq 的缓存可以用它自带的接口触达也可以通过重启 dnsmasq 服务实现。如果不想清缓存又必须马上验证可以换一个工具或者换一个之前没查过的域名来测试。比如你刚改了 DNS就用一个冷门域名去试这样能把缓存干扰降到最低。6. 关于 nameserver 配置我留下的几个小习惯我自己处理过不少类似的 DNS 配置问题整个过程踩过很多次坑最后总结成几个习惯写在这里当个收尾。第一永远在改 resolv.conf 之前先问一句“它会被谁覆盖”。软链接、nmcli、systemd-resolved、resolvconf随便哪个在背后运行都可能让你的改动无效。先看清机制后面操作才不会被覆盖。第二nameserver 127.0.1.1 这个地址本身不用怕它就是一个“本机 DNS 监听位置”的标记。重点是你得确认那里确实有个进程在监听。没有进程它就是僵尸地址有进程它就是本地缓存层。判断速度很快ss -lunp | grep :53几秒钟就有结论。第三如果只是想临时测试某个解析服务器直接改文件没问题但别忘了备份。如果想让配置长期生效务必沿着系统自带的网络管理入口去改不要跟自动生成机制硬碰硬。第四遇到看不懂的配置先保留现场。我一般会把 /etc/resolv.conf、/etc/hosts、网卡配置文件和 service 状态分别存一份改一步记一步再验证一步。DNS 相关的坑往往都藏在“多个服务互相改写同一个文件”的纠缠里留下现场能省掉大量回头排查的时间。这次聊到这儿配置命令都给得很具体了拿着去对照自己的系统试一圈多半能把 nameserver 127.0.1.1 的来龙去脉搞清楚。如果你遇到的情况正好是那种 53 端口没有进程但文件里还留着 127.0.1.1 的僵尸配置那就按我第 4 节的步骤处理大概率能一步到位。
