修改hosts文件是最直接的host解析方式，服务器和客户端操作路径不同，但核心都是把域名指向固定IP并跳过远程DNS解析。
客户端hosts解析域名怎么做：三条主流系统实操
很多朋友第一次接触host解析，是在本地开发环境里把dev.example.com指向0.0.1，客户端改hosts的思路很简单：找到hosts文件，按格式加上一行映射，保存后刷新DNS缓存，但不同系统的文件位置和编辑权限差别很大,下面按系统拆开说。
Windows：记事本以管理员身份运行
Windows的hosts文件固定放在C:\Windows\System32\drivers\etc\hosts，没有扩展名,直接用记事本打开。
操作步骤：
- 按
Win + R，输入notepad，但别直接回车，右键记事本图标，选择“以管理员身份运行”。 - 在记事本里点“文件-打开”，路径填
C:\Windows\System32\drivers\etc\hosts，右下角文件类型改成“所有文件”。 - 文件末尾另起一行，写
IP地址 域名，比如168.1.10 myapp.local。 - 保存后，打开命令提示符，执行
ipconfig /flushdns。
新手最容易栽在权限上：直接双击编辑，保存时报“拒绝访问”，解决方法是提前用管理员身份打开记事本，而不是保存时才提权，Windows 10/11的hosts文件默认是UTF-8编码，保存时别选“带BOM”的格式，否则域名后面可能带隐藏字符,解析异常。
macOS和Linux：终端里用sudo改文件
macOS的hosts路径是/etc/hosts，Linux大多数发行版也是/etc/hosts，两者操作几乎一样,只是macOS刷新DNS缓存的命令略有不同。
命令行操作：
sudo vim /etc/hosts
输入密码后，按i进入编辑模式,追加一行：
0.0.5 api.test.com按Esc，输入wq保存退出。
macOS刷新缓存：
sudo dscacheutil -flushcache sudo killall -HUP mDNSResponder
Linux刷新缓存分情况：
- 使用systemd的系统：
sudo systemd-resolve --flush-caches - 使用nscd的系统：
sudo service nscd restart - 很多发行版改完立即生效,不需要额外操作。
在这里提醒一句，macOS的sudo vim进入编辑模式后，如果按错键可能弹出“E45: already set”之类的提示，不用慌，按
Esc再按q!强制退出重来。
服务器改hosts配置后，Host CPU占用不降反升？排查思路
服务器端改hosts，目的通常有两个：一是内网环境绕过公网DNS解析，把服务调用指向内网IP；二是测试环境模拟跳转，但有些运维朋友反馈，改完hosts后服务器CPU占用率反而变高了，这里需要厘清一个概念：hosts文件本身不会大幅消耗Host CPU，问题往往出在配置错误或频繁解析的进程上。
为什么会有“hosts影响CPU”的错觉
当你把域名映射到错误IP，比如把service.internal指向了一个不存在的地址，应用层会不断重试连接，每次重试都触发一次系统调用，错误堆积后，进程占用的CPU就上去了，如果hosts文件里写了大量无用条目，比如几百行注释或重复映射，虽然解析器会逐行扫描，但现代操作系统使用哈希索引，几千行内的性能损耗可以忽略不计，真正影响CPU的，是同一条映射被大量短连接请求反复触发，比如Tomcat或Nginx频繁建立连接，这时CPU消耗其实花在TCP握手和进程调度上,跟hosts本身没关系。
服务器端hosts配置的几个细节
- 格式严格区分空格或Tab：
IP和域名之间至少一个空格,多打几个也没事。 - 域名区分大小写吗？不区分,但统一小写更规范。
- 不要用通配符，hosts文件不支持
.example.com这样的写法。 - 别在hosts里配公网域名到
0.0.1来做“屏蔽”,这会导致本机服务无法访问。
服务器上验证hosts是否生效，用ping或nslookup：
ping api.test.com
如果返回的IP是你写在hosts里的那个，说明解析成功，注意ping命令可能走IPv6，如果hosts里写的是IPv4，建议加-4参数：
ping -4 api.test.com
高CPU场景下的排查顺序
当服务器CPU飙升，且你刚改过hosts,按以下顺序排查：
- 执行
top查看哪个进程占用最高。 - 如果是Java应用，用
jstack抓线程栈，看是否卡在InetAddress.getByName这类DNS查询方法上。 - 看
/etc/nsswitch.conf里hosts这一行，确认解析顺序是files dns，还是dns files，如果dns
在
files前面，系统会先查DNS，DNS超时后才读hosts，这会让请求变慢,间接拉高CPU。 - 用
strace -p 进程号跟踪系统调用，观察是否有大量connect或sendto发往错误IP。
业内专家指出，多数“改hosts后CPU升高”的案例，最终都定位到应用层重试机制和连接池配置不当,而不是hosts文件本身。
host解析的常见坑：缓存、优先级和跨平台差异
客户端和服务器都改完hosts，并不代表解析一定按预期走,下面几个坑是日常排障高频问题。
hosts文件修改后不生效怎么办
先确认文件保存位置和格式，再确认解析优先级，Windows下，hosts文件默认优先级高于DNS服务器，但不影响已缓存的DNS记录，所以必须刷新缓存，Linux下，如果/etc/nsswitch.conf里配置了dns优先于files,hosts就不会被先查询。
排查步骤：
- 用
cat /etc/hosts（或type C:\Windows\...\hosts）确认映射行存在。 - 执行
getent hosts 域名,看返回值。 - 如果
getent返回正确，但应用访问不到，检查应用自身是否使用了自定义DNS解析库，比如Java的JVM参数-Dsun.net.inetaddr.ttl=0。
hosts解析和DNS缓存是一回事吗
不是，hosts是本地静态文件，DNS缓存是系统或路由器暂存的动态查询结果。hosts文件优先级高于DNS缓存，但DNS缓存会保留一段时间，甚至覆盖hosts的修改结果，Windows的ipconfig /flushdns只能清系统缓存，清不掉应用层自己的缓存,比如浏览器内置的DNS缓存。
对比一下常见解析方式：
| 解析方式 | 生效速度 | 是否依赖网络 | 适合场景 |
|---|---|---|---|
| hosts文件 | 立即（需刷缓存） | 否 | 内网固定IP、开发测试 |
| 系统DNS缓存 | 毫秒级 | 首次查询需要 | 公网域名加速 |
| 本地DNS服务器 | 秒级 | 是 | 多服务器统一管理 |
服务器和客户端hosts统一管理：规模化场景怎么搞
单台服务器手动改hosts没问题，但几十台服务器全手工编辑，不仅累，还容易漏,这时需要配置管理工具批量下发。
用Ansible批量同步hosts
在Ansible控制机上,写一个简单的playbook：
- name: sync hosts file
hosts: all
tasks:
- name: copy hosts
copy:
src: ./files/hosts
dest: /etc/hosts
owner: root
group: root
mode: 0644
操作流程：
- 在控制机
/etc/ansible/hosts里写好服务器清单。 - 将统一维护的hosts文件放在
./files/hosts。 - 执行
ansible-playbook sync_hosts.yml,所有目标服务器自动覆盖hosts。
客户端机器数量不多，但版本差异大，比如混合了Windows和macOS，建议写脚本按系统类型分发，Windows可以用robocopy或PowerShell远程推送，macOS/Linux用scp加sudo移动。
脚本片段示例：
scp hosts user@client_server:/tmp/hosts ssh user@client_server "sudo mv /tmp/hosts /etc/hosts"
这个方案在中小团队里很实用。不需要额外部署Agent，也不用引入复杂的DNS服务,纯文件变更就能解决。
Q&A：关于host解析和Host CPU的典型问题
为什么hosts文件里的域名解析到了公网IP？
先确认hosts里是否有重复条目，后写的条目会不会覆盖前面的，多数系统解析时遵循“首次匹配”原则，但有些应用会读取所有条目，取最后一个，检查域名尾部是否有多余空格，或者文件编码被改成了UTF-16，导致解析器无法识别,重新用纯文本格式保存并刷新缓存。
服务器上改了hosts，但容器里的应用还是取不到？
容器网络模式不同，导致hosts生效范围不同。bridge模式下，容器默认使用Docker内置DNS，不会读宿主机的/etc/hosts，需要修改docker-compose.yml里的extra_hosts配置，或者直接用docker run --add-host=api.test.com:10.0.0.5。host网络模式下，容器直接共享宿主机网络栈,改动宿主机hosts即可生效。
hosts解析异常会导致CPU占用居高不下吗？
会，但间接影响占主导，当应用反复解析一个hosts中不存在的域名时，每次解析都快速失败，如果代码里没有超时退避机制，就会形成密集的循环调用，此时CPU飙升是应用逻辑引起的，不是hosts解析本身，建议在应用层加缓存或限制重试频率，同时检查/etc/resolv.conf里配置的DNS服务器是否可达。