/etc/resolv.conf 是传统 dns 配置文件位置，但现代系统多由 systemd-resolved 或 networkmanager 动态管理，直接修改易被覆盖；应先检查软链接指向，再通过对应服务配置 dns。
resolv.conf 文件在哪，能不能直接改
/etc/resolv.conf 是 Linux 系统里传统存放 DNS 解析配置的位置，但现代发行版（如 Ubuntu 20.04+、Fedora 33+、RHEL 8+）大多由 systemd-resolved、NetworkManager 或 dhcpcd 动态管理，直接编辑该文件可能被下次网络重连或服务重启覆盖。
判断是否被接管：运行 ls -l /etc/resolv.conf。如果输出显示是软链接（比如指向 /run/systemd/resolve/stub-resolv.conf 或 /var/run/NetworkManager/resolv.conf），就别硬改原文件。
- 手动修改前先查管理方：
systemctl is-active systemd-resolved或nmcli dev show | grep DNS - 若用
systemd-resolved，应改/etc/systemd/resolved.conf并执行sudo systemctl restart systemd-resolved - 若用
NetworkManager，优先在连接配置里设 DNS：nmcli connection modify "Wired connection 1" ipv4.dns "8.8.8.8 1.1.1.1"，再nmcli connection down && up
resolv.conf 里哪些行真正生效
只有以 nameserver、search、domain、options 开头的行会被解析器读取；其他注释或空行忽略。常见误区是以为写多条 nameserver 就能负载均衡——实际只按顺序用，第一个超时才 fallback 到第二个。
关键行为：
-
nameserver最多支持 3 个 IPv4 地址（内核限制），第 4 个起被静默丢弃 -
search和domain互斥，同时存在时search优先；search可接多个域名，用空格分隔，用于短主机名补全 -
options timeout:1 attempts:2这类设置影响 libc 的解析行为，但不被systemd-resolved或dnsmasq使用
为什么 nslookup 正常但 curl 失败
因为 curl、wget 等工具默认走系统 glibc 的 getaddrinfo()，而 nslookup 直连指定 DNS 服务器（默认用 /etc/resolv.conf 第一个 nameserver）。两者路径不同，容易掩盖配置问题。
排查步骤：
- 用
getent hosts example.com模拟真实应用调用，看是否解析成功 - 检查
cat /etc/nsswitch.conf | grep hosts，确认hosts:行含dns（而非仅files） - 若用
systemd-resolved，resolv.conf可能只指向127.0.0.53，这时要查resolvectl status看实际上游 DNS
容器或 chroot 环境里 DNS 不通怎么办
Docker 默认会把宿主机的 /etc/resolv.conf 复制进容器，但如果宿主用的是 127.0.0.53（systemd-resolved stub），容器里通常没 systemd-resolved 服务，导致解析失败。
解决方式取决于场景：
- 启动容器时加
--dns=8.8.8.8覆盖 DNS - 构建镜像时在
Dockerfile写RUN echo "nameserver 8.8.8.8" > /etc/resolv.conf（注意：仅适用于无外部 DNS 管理的静态环境） - chroot 环境需手动同步 DNS 配置，并确保
/etc/nsswitch.conf存在且正确
最易被忽略的是：某些精简镜像（如 alpine）用的是 musl libc，它不读 options 行，也不支持 search 的多域展开，遇到短名解析失败得换完整域名或改用 glibc 基础镜像。
