Linux下修改`/etc/hosts`后DNS解析为何仍不生效？

Question

Linux下修改`/etc/hosts`后DNS解析仍不生效，常见原因有四：一是应用层缓存未刷新（如Chrome、Firefox内置DNS缓存，需手动清除或禁用）；二是系统级nscd或systemd-resolved服务缓存了旧记录，需执行`sudo systemctl restart nscd`或`sudo systemd-resolve --flush-caches`；三是`/etc/nsswitch.conf`中`hosts:`行未包含`files`（如误配为`hosts: dns`），导致跳过hosts文件查找；四是容器或Docker环境使用独立网络命名空间，宿主机的`/etc/hosts`对其无效，需通过`--add-host`参数注入或修改容器内文件。此外，注意检查hosts格式是否规范（IP与域名间须用空格或制表符分隔，无多余符号，且无重复条目覆盖）。验证可使用`getent hosts example.com`（绕过应用缓存）而非仅依赖`ping`或`curl`。

Answer 1

```html

一、现象层：修改 /etc/hosts 后解析未生效 —— 表象与直觉陷阱

开发者执行 sudo echo "127.0.0.1 dev.example.com" >> /etc/hosts 后，ping dev.example.com 仍解析为旧IP或超时。此时第一反应常是“文件写入失败”或“权限问题”，但实际90%的案例中文件已正确落盘（可用 cat /etc/hosts | grep example 验证）。根本矛盾在于：Linux DNS解析非单一线性流程，而是由多级缓存、策略配置与命名空间隔离共同构成的**分层决策链**。

二、应用层缓存：浏览器与运行时环境的“私有DNS”

• Chrome/Edge：内置DNS缓存（默认300秒），需访问 chrome://net-internals/#dns → 点击 Clear host cache；或启动时加参数 --dns-cache-size=0
• Firefox：在 about:config 中设置 network.dnsCacheExpiration = 0，并重启
• Java应用：JVM默认永久缓存成功解析（sun.net.InetAddressCachePolicy），需显式设置 -Dnetworkaddress.cache.ttl=0
• Node.js：v18+ 默认启用DNS缓存，可通过 require('dns').setServers([]) 或环境变量 NODE_OPTIONS="--dns-result-order=ipv4first" 干预

⚠️ 关键验证：使用 curl -v http://dev.example.com 时观察 * Connected to dev.example.com (10.10.10.10) 中的IP是否为 hosts 所设值——若非预期IP，说明应用层缓存或HTTP重定向干扰了判断。

三、系统级服务缓存：nscd 与 systemd-resolved 的隐式拦截

现代Linux发行版普遍启用名称服务缓存守护进程（NSS Cache Daemon）或systemd的解析器服务，它们会劫持 gethostbyname() 等glibc调用，绕过原始 /etc/hosts 文件读取。

服务	检测命令	刷新命令	典型影响范围
nscd	sudo systemctl is-active nscd	sudo systemctl restart nscd	所有调用glibc NSS接口的程序（包括ssh、curl、python -c "import socket; print(socket.gethostbyname('dev.example.com'))"）
systemd-resolved	systemctl is-active systemd-resolved	sudo systemd-resolve --flush-caches 或 sudo resolvectl flush-caches（v245+）	使用systemd-resolved作为/etc/resolv.conf目标的系统（如Ubuntu 20.04+/Fedora/RHEL 8+）

四、NSS策略层：/etc/nsswitch.conf 决定“谁先说话”

/etc/nsswitch.conf 是Linux名称服务的“宪法文件”。其 hosts: 行定义了解析顺序。常见错误配置如下：

# ❌ 错误：仅走DNS，完全忽略files（即/etc/hosts）
hosts: dns

# ✅ 正确：优先查files，再fallback到dns
hosts: files dns

# ⚠️ 进阶：支持mymachines（容器）、mdns4_minimal（Zeroconf）等
hosts: files mymachines resolve [!UNAVAIL=return] dns

验证该配置是否生效：执行 getent hosts dev.example.com —— 此命令直接调用glibc的NSS接口，严格遵循 nsswitch.conf 策略，且不经过任何应用层缓存，是诊断黄金标准。

五、命名空间层：容器化环境中的“hosts 文件失语症”

Docker/Kubernetes容器拥有独立的网络命名空间（network namespace），其 /etc/hosts 是挂载自建副本（非宿主机bind-mount），因此宿主机修改对其零影响。解决方案分三级：

1. 运行时注入：docker run --add-host=dev.example.com:127.0.0.1 ...
2. 构建时固化：在Dockerfile中 RUN echo "127.0.0.1 dev.example.com" >> /etc/hosts
3. K8s场景：通过 hostAliases 字段声明：
   

   spec:
     hostAliases:
     - ip: "127.0.0.1"
       hostnames:
       - "dev.example.com"

六、格式与冲突校验：被忽视的语法雷区

以下任一情况均会导致整行失效或被后行覆盖：

• IP与域名间使用 =、: 或中文空格（U+3000）而非ASCII空格/Tab
• 行尾存在不可见控制字符（如^M，Windows换行符）——用 file /etc/hosts 和 hexdump -C /etc/hosts | head 排查
• 同一域名出现多次，仅首行生效（glibc按顺序匹配，遇第一个即返回）
• IPv6地址未用方括号包裹（如 fe80::1%lo dev.example.com 应写作 fe80::1%lo dev.example.com，但更推荐 ::1 dev.example.com）

七、终极验证链：构建可信诊断流水线

请严格按此顺序执行，任一环节失败即定位根因：

graph LR A[修改 /etc/hosts] --> B[getent hosts dev.example.com] B --> C{返回预期IP？} C -->|是| D[检查应用层缓存] C -->|否| E[检查 nsswitch.conf hosts 行] E --> F[重启 nscd 或 flush systemd-resolved] F --> G[再次 getent 验证] G --> H{仍失败？} H -->|是| I[检查 hosts 文件格式 & 重复条目] H -->|否| J[进入容器环境专项排查]

八、生产环境加固建议（面向5年+工程师）

在CI/CD或Ansible自动化中，应将hosts管理纳入版本控制并附加校验任务：

• 使用 validate_hosts.py 脚本自动检测语法、重复域名、非法字符
• 在systemd service中添加 ExecStartPre=/usr/local/bin/validate-hosts.sh 实现变更守门
• 对关键服务（如API网关、Service Mesh sidecar），强制禁用DNS缓存并显式指定解析策略（如Envoy的 dns_lookup_family: V4_ONLY）
• 监控告警：部署Prometheus exporter采集 systemd-resolved 缓存命中率、nscd统计信息，异常突增即触发告警

```