直接监控 /sys/class/net/ 并联动更新 /etc/resolv.conf 不是标准做法，也不推荐——因为该路径仅暴露内核网络设备只读状态，不触发 DNS 配置写入；真正导致覆盖的是 systemd-networkd、NetworkManager、dhcpcd 等上层服务对热插拔事件的响应行为。
直接监控 /sys/class/net/ 并联动更新 /etc/resolv.conf 不是标准做法，也不推荐——因为 /sys/class/net/ 只暴露内核网络设备的只读状态（如 up/down、carrier 等），它本身不触发 DNS 配置写入，更不参与 resolv.conf 的生成逻辑。真正导致 resolv.conf 被非预期覆盖的，是上层服务对网卡热插拔事件的响应行为，比如 systemd-networkd、NetworkManager、dhcpcd 或某些定制脚本。
先确认谁在管理 resolv.conf
多数现代 Linux 系统中，/etc/resolv.conf 是一个符号链接，指向动态生成路径（如 /run/systemd/resolve/stub-resolv.conf 或 /run/NetworkManager/resolv.conf）。运行以下命令可快速定位：
- ls -l /etc/resolv.conf —— 查看是否为软链接及目标位置
- systemctl status systemd-resolved NetworkManager —— 看哪个服务处于 active 状态
- cat /run/systemd/resolve/resolv.conf 2>/dev/null || cat /run/NetworkManager/resolv.conf 2>/dev/null —— 检查实际生效的配置源
捕获网卡热插拔事件的真实来源
物理网卡热插拔会触发 udev 事件，进而可能调用 network manager 的 reload 流程。要验证是否由此引发覆盖，可实时监听：
IntoDNS.ai
下载
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
-
udevadm monitor --subsystem-match=net --property —— 观察插拔时是否发出
INTERFACE=eth0、ACTION=add/remove等事件 - journalctl -u systemd-networkd -u NetworkManager -f —— 过滤服务日志，查找 “reconfigure”, “updating resolv.conf”, “DHCP lease acquired” 等关键词
- inotifywait -m -e modify /etc/resolv.conf（需安装 inotify-tools）—— 监控文件被改写瞬间，再立刻 journalctl -n 20 查前因
锁定并约束非预期覆盖行为
若确认是 NetworkManager 或 systemd-networkd 在每次网卡重连后强制写入默认 DNS（如 127.0.0.53 或运营商 DNS），可通过配置阻止：
-
NetworkManager：编辑
/etc/NetworkManager/conf.d/99-dns-keep.conf，添加：
[main]
dns=none
rc-manager=unmanaged
然后 systemctl restart NetworkManager -
systemd-networkd：在对应
.network文件（如/etc/systemd/network/10-eth0.network）中加入：
[Network]
DNS=114.114.114.114 223.6.6.6
Domains=~.
并设resolv.conf=off或禁用systemd-resolved - 若使用 dhcpcd：编辑
/etc/dhcpcd.conf，取消注释或添加nohook resolv.conf
让 resolv.conf 真正“静态”且抗覆盖
适用于嵌入式或工业场景，需彻底规避自动管理：
- 将
/etc/resolv.conf改为普通文件（rm /etc/resolv.conf && touch /etc/resolv.conf） - 设置不可修改属性：chattr +i /etc/resolv.conf（需 root；卸载前用 chattr -i）
- 或通过 tmpfiles.d 固化：
echo "w /etc/resolv.conf - - - - nameserver 114.114.114.114" > /etc/tmpfiles.d/resolv.conf.conf，重启后自动还原
本质不是监控 sysfs 路径，而是厘清“谁响应热插拔 → 谁写 resolv.conf → 如何禁用该行为”。物理网卡变动只是诱因，根因永远在用户空间服务的配置策略里。
