查询顺序由谁决定
在 Linux 上，程序通过系统名称服务接口解析名字，顺序由 nsswitch.conf 中 hosts 那一行决定。常见配置是先查 hosts 文件、再查 DNS，所以 hosts 里的条目可以覆盖 DNS 返回的结果。
为什么会出现「命令能解析、程序不能」
并不是所有程序都走系统接口：带自有解析实现的运行时可能绕过这套顺序，行为与系统工具不一致。排查这类差异时，要用系统工具和实际程序各测一次，否则很容易把问题归到错误的一侧。
基本信息
| 配置位置 | /etc/nsswitch.conf 的 hosts 行 |
|---|---|
| 常见顺序 | 先查文件（files），再查域名服务（dns） |
| hosts 文件 | /etc/hosts，可覆盖解析结果 |
| 验证工具 | getent 走系统顺序，dig 直接查域名服务 |
典型使用场景
- 上线前把域名临时指向测试地址，做小范围灰度验证
- 容器与边缘环境缺少内部域名服务时用 hosts 兜底
- 排查「命令能解析、程序不能解析」的差异
- 清理 hosts 文件里遗留的历史条目
查看与验证
查看与验证
# /etc/nsswitch.conf
hosts: files dns myhostname
# /etc/hosts
127.0.0.1 local.api.example.com
getent hosts local.api.example.com # 走系统顺序，命中 hosts 条目
dig +short local.api.example.com # 绕开系统顺序，直接看域名服务工具行为对照
| 工具 | 是否走系统顺序 | 用途 |
|---|---|---|
| getent | 是 | 验证应用实际会得到什么结果 |
| dig 与 nslookup | 否 | 只反映域名服务侧的数据 |
| ping 与 curl | 多数走系统顺序 | 日常验证 |
| 自研程序 | 取决于实现 | 需单独确认所用运行时的行为 |
应用自带解析库时可能绕过系统顺序，表现为系统工具与程序结果不一致：排查时先确认程序实际用的是哪一套解析路径。
hosts 文件里的历史条目很容易被遗忘：临时灰度用的覆盖如果没清理，会在很久以后以「某台机器行为和其他机器不一样」的形式暴露出来。
修改名称服务配置后，程序可能仍持有自己的解析缓存：验证行为时要重启相关进程或等待其缓存到期。