Linux主机名解析顺序由/etc/nsswitch.conf的hosts行决定，默认为files dns，即先查/etc/hosts再查DNS；若改为dns files则优先DNS，但可能导致localhost解析失败；修改后无需重启服务，但需注意glibc模块加载和程序是否遵循NSS机制。
Linux主机名解析顺序由nsswitch.conf控制
系统查一个域名或主机名时，不是直接走DNS，而是按nsswitch.conf里hosts行定义的顺序依次尝试不同源。默认通常是files dns，即先查/etc/hosts，再查DNS；如果写成dns files，就会跳过本地文件直连DNS——这在某些容器或内网环境会导致localhost解析失败。
修改/etc/nsswitch.conf中的hosts行
编辑该文件后，所有后续的getaddrinfo()调用（包括ping、curl、ssh等）都会按新顺序执行。注意：改完无需重启服务，但已有进程的DNS缓存（如systemd-resolved或应用层缓存）可能仍沿用旧行为。
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 用
sudo vi /etc/nsswitch.conf打开，找到形如hosts: files dns的行 - 想优先走DNS？改成
hosts: dns files；想强制只读/etc/hosts？写成hosts: files - 支持的源还有
mdns4（mDNS）、resolve（systemd-resolved）、myhostname（仅匹配本机名），但并非所有系统都启用对应模块 - 顺序中重复项会被忽略，比如
files dns files等价于files dns
常见错误：改了nsswitch.conf却没生效
最常被忽略的是glibc的NSS模块实际是否加载。例如你写了hosts: resolve，但系统没装libnss-systemd包，或systemd-resolved没运行，那这一项就静默失效，自动 fallback 到下一项。
- 检查
ls /lib/x86_64-linux-gnu/libnss_*.so*（路径依架构和发行版而异），确认所需模块存在 - 运行
getent hosts example.com验证当前生效的解析链，它会按nsswitch.conf顺序输出首个匹配结果 -
strace -e trace=connect,openat ping example.com 2>&1 | grep -E "(etc/hosts|resolv.conf|nss)"可观察实际打开的文件和连接目标 - 某些程序（如Go 1.19+二进制）绕过glibc NSS，直接读
/etc/resolv.conf，此时nsswitch.conf对它们完全无效
与/etc/hosts和/etc/resolv.conf的关系
nsswitch.conf不决定DNS服务器地址，也不决定/etc/hosts内容；它只是调度器。真正干活的是：/etc/hosts提供静态映射，/etc/resolv.conf告诉DNS客户端连哪台服务器，而nsswitch.conf决定“先问谁、再问谁”。三者缺一不可，但职责截然不同。
- 删掉
/etc/resolv.conf后，dns源会失败，但如果files在前，ping localhost仍能通 -
myhostname源能让gethostbyname("myhost")返回本机IP，哪怕/etc/hosts里没写，也不依赖网络 - 在Kubernetes Pod里，
files通常指向ConfigMap挂载的/etc/hosts，而dns指向CoreDNS，顺序错可能导致服务发现异常
nsswitch.conf看着简单，但涉及glibc模块加载、程序是否遵循NSS、以及底层网络栈是否介入，稍不注意就会出现“明明改了却像没改”的情况。尤其在混合使用systemd-resolved、dnsmasq或自建DNS代理的环境中，resolve和dns的行为差异比表面看起来更微妙。 
