在填写 Clash（mihomo）的 DNS listen 之前，先确认这项配置到底要解决哪一类问题：是让本机或局域网把查询送到 Clash 打开的 DNS 服务，还是调整 Clash 自己向上游递归、转发时用哪一组服务器。手册把前者写成「DNS 服务监听，支持 udp, tcp」，示例形态为 0.0.0.0:1053；后者则分散在 nameserver、fallback、default-nameserver、nameserver-policy、proxy-server-nameserver、direct-nameserver 等字段。用途没对齐时，改监听不会改变解析来源，改上游也不会让客户端多出一个可连的本地入口。
适用条件：什么时候才需要谈监听地址
先看 enable。手册写明：是否启用；如为 false，则使用系统 DNS 解析。因此，只有在你明确需要 Clash 按该段配置处理 DNS 时，listen 的地址和端口才有「给谁用」的意义。若 enable 为 false，继续纠结绑定 127.0.0.1 还是 0.0.0.0、端口用 1053 还是其他值，并不能让 Clash 承担独立 DNS 服务角色。
适用场景通常包括：本机应用把 DNS 指向 Clash 监听地址；虚拟网卡或容器把解析指到该入口；同一二层网络中的其他设备把 DNS 指到运行 Clash 的主机。不适用、或应先改别的字段的情况包括：只想换 DoH/DoT 上游、只想给代理节点域名单独解析、只想让 direct 出口走另一组 DNS。这些分别对应 nameserver / fallback、proxy-server-nameserver、direct-nameserver，手册并未把它们描述为监听入口。
enhanced-mode 可选 fake-ip 或 redir-host（默认 redir-host），决定应答如何生成，不决定套接字绑在哪。fake-ip-range 是 fakeip 的 IP 段，手册还写明 TUN 的默认 IPv4 地址也使用此值作为参考。确认 listen 用途时，不要把假 IP 网段误当成监听地址。
具体操作：用三句话把用途写清楚
第一步，写出查询发起方。例如「仅本机」「本机加容器」「局域网内指定网段」。发起方决定绑定范围：只给本机时，监听应落在发起方能够访问的地址；要给其他主机时，必须绑定这些主机路由可达的接口地址或 0.0.0.0。文档示例 0.0.0.0:1053 表示在所有接口上打开服务，并不自动等于「已经适合所有客户端」，还要看防火墙与路由是否放行该端口。
第二步，写出传输与端口。手册声明监听支持 UDP 与 TCP，示例端口是 1053 而不是传统的 53。因此用途确认必须包含：客户端将向哪个端口发查询，以及是否只有 UDP。若操作系统或其他软件仍指向 53，而 listen 写的是 1053，则入口用途与客户端实际行为不一致。
第三步，把「入口」和「上游」拆开记录。入口是 listen；默认向上游问询是 nameserver；后备是 fallback；用来解析 DNS 服务器自身域名的是 default-nameserver（手册要求必须为 IP，可为加密 DNS）。nameserver-policy 用于指定域名走哪组解析服务器，优先于 nameserver/fallback。若你的真实目的是「某类域名换一组上游」，应改 policy 或 nameserver，而不是改 listen。
若还计划让 DNS 连接遵守路由规则，手册要求配置 proxy-server-nameserver，并说明 respect-rules 表示 dns 连接遵守路由规则。这影响 Clash 作为客户端出去问上游时怎么选路，属于上游路径，不是本地监听用途。手册还提示：如需经过代理查询，应配置 proxy-server-nameserver，以防出现鸡蛋问题。
判断依据与失败时下一步
判断「用途已确认」的依据有三条，需同时成立：能指出具体发起方及其将填写的 DNS IP 与端口；该 IP、端口与 listen 一致，且 enable 为 true；能指出解析结果来源由哪些 nameserver 类字段负责，而不是指望改 listen 去换上游。
若写不出发起方，停止修改 listen，先决定要不要启用内置 DNS。若启用后客户端仍走系统解析，按手册回到 enable 是否为 false。若绑定地址对发起方不可达（例如只听回环却让局域网主机来问），下一步是改绑定地址或改客户端指向，而不是增加 fallback。若监听用途已明确但节点域名解析失败，按手册检查 proxy-server-nameserver 是否应单独配置，不要把该问题算作 listen 填错。