关键在于区分tcp 53（用于区域传输、大响应）和udp 53（标准dns查询），二者独立监听；需确认systemd-resolved是否正常运行并监听127.0.0.53:53，用ss -tulnp | grep ':53 '验证双协议监听状态，再通过dig @127.0.0.53和nc -uvz测试连通性与解析能力。
排查Linux中DNS 53端口异常，关键不是只看“53端口通不通”，而是分清TCP 53和UDP 53各自的作用，并确认本地DNS服务是否在正确地址和协议上监听、响应。
先确认systemd-resolved是否正常运行
现代Linux发行版（如Ubuntu、Fedora、CentOS 8+）默认用systemd-resolved做本地DNS缓存，它监听127.0.0.53:53，不是传统意义上的127.0.0.1:53。如果服务没起来，所有解析都会超时。
- 运行 systemctl status systemd-resolved，检查状态是否为 active (running)
- 若显示 inactive 或 failed，尝试启动：sudo systemctl start systemd-resolved
- 启用开机自启：sudo systemctl enable systemd-resolved
查清楚53端口到底被谁监听了
TCP 53 和 UDP 53 是两套独立监听，必须分开验证。常见冲突是 dnsmasq、named 或其他DNS服务抢占了端口，导致systemd-resolved无法绑定。
- 执行 ss -tulnp | grep ':53 '（注意末尾空格，避免匹配到530、531等）
- 观察输出中是否有 udp UNCONN 和 tcp LISTEN 两条记录，且都指向 127.0.0.53:53 和 systemd-resolved
- 如果看到 dnsmasq 或 named 占用，需停用它们：sudo systemctl stop dnsmasq 或 sudo systemctl disable named
验证DNS解析链路是否真正通达
即使端口监听着，也不代表能解析。要绕过本地配置干扰，直连测试。
- 用dig强制指定本地解析器：dig @127.0.0.53 google.com —— 应返回NOERROR和A记录
- 测试UDP连通性（DNS主用UDP）：nc -uvz 127.0.0.53 53 —— 显示 succeeded! 才算通
- 测试TCP备用通道：dig @127.0.0.53 google.com +tcp —— 避免因UDP包过大被截断导致失败
- 对比外部DNS：dig @8.8.8.8 google.com，确认问题是否局限在本地服务
检查resolv.conf是否指向正确地址
/etc/resolv.conf 决定了系统往哪发DNS请求。若它被硬写成 8.8.8.8，就完全绕过了127.0.0.53，此时即使systemd-resolved挂了也看不出异常；反之，若它错误指向127.0.0.1:53，而那里没服务，就会报 communications error to 127.0.0.53#53: timed out。
- 运行 cat /etc/resolv.conf，理想内容应为：
nameserver 127.0.0.53 - 检查该文件是否为软链接：ls -l /etc/resolv.conf，常见正确链接是 /run/systemd/resolve/stub-resolv.conf
- 若被NetworkManager或手动修改覆盖，可重建链接：sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
