应先用ls -l /etc/resolv.conf确认是否为软链接以判断接管服务（如指向/run/systemd/resolve/stub-resolv.conf则为systemd-resolved管理），再通过systemctl is-active等命令定位活跃服务，最后针对性修改对应配置（如/etc/systemd/resolved.conf或NetworkManager连接参数）并重启服务，避免直接编辑被覆盖。
直接改 /etc/resolv.conf 后重启或重连网络就还原，说明有服务在后台接管并重写它。关键不是反复修改文件，而是找出谁在写、为什么写、怎么让它停手。
第一步：确认 resolv.conf 是否被接管
运行命令：ls -l /etc/resolv.conf
看输出是否为软链接。常见情况包括：
- 指向
/run/systemd/resolve/stub-resolv.conf→ systemd-resolved 在管理 - 指向
/var/run/NetworkManager/private-resolv.conf或类似路径 → NetworkManager 在管理 - 没有软链接、权限为只读（如
-rw-r--r--），但内容仍被改 → 可能是 dhclient、cloud-init 或其他脚本在覆盖
第二步：查清当前活跃的 DNS 管理服务
逐个检查主流服务是否启用：
- 查 systemd-resolved：
systemctl is-active systemd-resolved - 查 NetworkManager：
systemctl is-active NetworkManager，再执行nmcli dev show | grep DNS - 查 cloud-init（云服务器常见）：
systemctl is-active cloud-init，并检查/var/log/cloud-init.log中是否有 network 配置日志 - 查 dhclient：
ps aux | grep dhclient，尤其注意 DHCP 获取 IP 后是否触发了 resolv.conf 更新
第三步：定位具体覆盖源头
如果多个服务都启用，需判断哪个是实际写入者：
- 用
sudo inotifywait -m /etc/resolv.conf监听文件变化，然后手动重启 NetworkManager 或运行sudo dhclient -r && sudo dhclient，观察哪次操作触发了写入 - 检查网卡配置文件中是否含
PEERDNS="yes"（RHEL/CentOS 系）或dhcp-send-hostname=true（NetworkManager 连接配置），这些会主动拉取并写入 DNS - 云环境务必检查
/etc/cloud/cloud.cfg，确认manage_etc_hosts和preserve_hostname设置，部分镜像会强制同步 DNS
第四步：针对性阻断覆盖行为
找到元凶后，选择对应方式止血：
- 如果是 systemd-resolved：编辑
/etc/systemd/resolved.conf，取消注释并设置DNS=114.114.114.114 8.8.8.8，再运行sudo systemctl restart systemd-resolved - 如果是 NetworkManager：在对应连接中禁用自动 DNS，例如：
nmcli connection modify "Wired connection 1" ipv4.ignore-auto-dns yes，再nmcli connection down && up - 如果是传统 network-scripts：确保网卡配置文件（如
ifcfg-eth0）中设NM_CONTROLLED="no"和PEERDNS="no"，再重启network服务 - 临时应急锁定（慎用）：
sudo chattr +i /etc/resolv.conf，但后续修改前必须先sudo chattr -i，否则所有写入都会失败
不复杂但容易忽略
