起不来，先看是哪一种「占用」

启动 DNS 服务时报 address already in use，说明本机已经有进程占了 53。这和「外部连不上」是两回事，但报错文案经常被人混着理解。

我的分法是：先在本机用 ss 看谁在听，再从外面探测看能不能连。前者决定服务能不能起来，后者决定别人能不能用上。

本机谁占着 53

ss -lunp 看 UDP，ss -ltnp 看 TCP。DNS 主要走 UDP 53，响应包大时会切到 TCP 53，所以两个都得看。

systemd-resolved 默认监听 127.0.0.53，是最常见的占用者。dnsmasq、容器运行时内置的 DNS、某些面板自带的解析服务，也会抢这个端口。

找到进程别急着 kill。如果是系统自带的解析服务，停了可能影响本机域名解析，得先确认它有没有在给别的程序供解析。

TCP 检测：填域名和端口，多节点看连通与握手耗时

TCP 检测：填域名和端口，多节点看连通与握手耗时

三种处理方式，代价不同

让新服务绑到具体网卡 IP，而不是 0.0.0.0，可以避开 127.0.0.53 上的占用。

关掉 systemd-resolved 的 stub listener，保留它做上游转发，是另一种常见做法。

容器场景则是端口映射冲突，改宿主端口或者换容器网络模式，比停服务更合适。

哪种都行，关键是别为了启动一个服务，把本机的解析搞挂。

外面能不能连，得单独测

本机启动成功不代表外部可达。在宝塔拨测的 TCP 测速里指定 53 端口，从多个地区、多个运营商的节点发起探测，看握手能不能完成。

这一步能把安全组、系统防火墙和云厂商策略区分开。所有节点超时，基本可以确定被拦了；只有部分节点通，是线路或区域策略。

响应最快、最慢和平均响应可以一起看。握手耗时明显高于其他端口，说明链路上有限速或者质量问题。

只测 TCP 53 会误判

DNS 查询默认走 UDP。服务只开了 UDP 53、没开 TCP 53，TCP 探测会显示连不上，但实际解析是好的。

反过来，TCP 53 能连，也不代表 UDP 查询可用。所以端口探测只能算一半证据，另一半得用真实的 DNS 查询去验。

这个区别在排查「域名解析不了」时特别关键，别拿 TCP 结果直接下结论。

复测和收尾

改完配置，先在本机确认监听地址和协议都对，再从外部连测两三次，看结果稳不稳。

有条件的，同时用 DNS 查询工具验证一次真实解析，确保服务不只是「端口开着」。

该警惕的是：53 对全网开放，容易被拿去做反射攻击；日志里出现大量陌生查询；云厂商发来端口滥用的通知。开放递归解析这种事，尽量别做。