应先判断dns控制服务：运行cat /etc/resolv.conf看是否含“generated by networkmanager”，systemctl is-active systemd-resolved查服务状态，再结合网卡配置文件确认；之后按对应服务（nm或resolved）规范配置，而非直接改resolv.conf。
/etc/resolv.conf 里写 nameserver 最快，但几乎从不持久——它大概率被 NetworkManager 或 systemd-resolved 覆盖，改完几分钟就回滚。真要生效，必须先搞清谁在管 DNS。
怎么判断谁在控制 DNS？
别跳过这步。运行这三条命令，结果直接决定你该走哪条路：
-
cat /etc/resolv.conf—— 如果开头有# Generated by NetworkManager，说明NetworkManager在写 -
systemctl is-active systemd-resolved—— 返回active表示systemd-resolved已启用且优先级更高 -
ls /etc/sysconfig/network-scripts/ifcfg-*（RHEL/CentOS）或cat /etc/network/interfaces（Debian/Ubuntu 传统方式）—— 存在且含DNS1=或dns-nameservers，说明走底层网卡配置
NetworkManager 管 DNS 时怎么改？
这是桌面版 Ubuntu、Fedora 和多数云服务器默认方式。用 nmcli 最稳，图形界面容易漏掉“禁用自动获取”这步。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 查连接名：
nmcli connection show，记下当前激活的连接名（比如Wired connection 1或System eth0） - 设 DNS 并关自动获取：
sudo nmcli connection modify "Wired connection 1" ipv4.dns "223.5.5.5 119.29.29.29"，再执行sudo nmcli connection modify "Wired connection 1" ipv4.ignore-auto-dns yes - 重启连接生效：
sudo nmcli connection down "Wired connection 1" && sudo nmcli connection up "Wired connection 1" - 验证别只看
/etc/resolv.conf：用nmcli device show | grep DNS或resolvectl dns（若systemd-resolved启用）
systemd-resolved 启用了该怎么配？
Ubuntu 20.04+、Debian 11+、Arch 默认走这条路。/etc/resolv.conf 往往只是个软链，指向 /run/systemd/resolve/stub-resolv.conf，直接编辑它没用。
- 编辑主配置：
sudo nano /etc/systemd/resolved.conf - 取消注释并填值：
DNS=223.5.5.5 119.29.29.29；如需 fallback，加FallbackDNS=114.114.114.114 - 重启服务：
sudo systemctl restart systemd-resolved - 确认软链正确：
ls -l /etc/resolv.conf应指向/run/systemd/resolve/stub-resolv.conf
临时测试 DNS 怎么做？
不写配置、不重启服务，只验证某个 DNS 是否可用，适合排查连通性或响应延迟。
- 单次查询指定 DNS：
nslookup google.com 8.8.8.8 - 清 DNS 缓存（若启用
systemd-resolved）：sudo systemd-resolve --flush-caches - 临时替换接口 DNS（仅当前会话）：
sudo resolvectl dns eth0 223.5.5.5（eth0换成实际网卡名）
真正容易被忽略的是：/etc/resolv.conf 的内容 ≠ 当前生效的 DNS。很多用户改完文件后跑 nslookup 成功了，以为万事大吉，结果一重启、一重连网络，解析又断了——因为系统根本没读那个文件，而是从 NetworkManager 连接配置或 systemd-resolved 的缓存里取的。验证必须用对应服务的原生命令，不是看文件内容。
