Pi-hole 报 Maximum number of concurrent DNS queries reached：关闭 RATE_LIMIT 仍无效

Pi-hole 出现 Maximum number of concurrent DNS queries reached (max: 150)，网页解析开始失败，CPU 和内存却不高。即使已经关闭 RATE_LIMIT，这条警告仍可能出现：它针对等待处理的并发 DNS 查询，与按客户端统计一定时间内的请求数量是两套限制。

应先检查查询是否一直等不到上游回答，以及转发链是否绕回 Pi-hole。数字 150 是当时配置的并发上限，不能由它单独断定某个电视、手机或域名就是根因。

确认报的是哪一种限制

FTL 的客户端限速记录会说明某个客户端被 rate-limiting，其他未被限速的客户端仍可使用服务。并发查询警告则来自 DNS 转发处理：当前处理容量被占用，新查询无法照常进入。

Pi-hole 5 的旧配置常见 RATE_LIMIT=0/0；Pi-hole 6 使用 /etc/pihole/pihole.toml 与 dns.rateLimit.count、dns.rateLimit.interval 等配置。这些值不控制 dnsmasq 的转发并发上限，反复编辑旧文件也不能修复等待上游的查询。

当前配置还可能由容器环境变量管理。检查实际版本和生效入口，避免在面板里修改一个已被环境变量锁定的值。这里不需要为了诊断就关闭原有客户端限速。

找到警告发生前，哪些请求没有收到回答

记录警告时间，在 Pi-hole 的 Query Log 和现有 DNS 日志中对照域名、查询类型、客户端、实际上游及响应结果。重点看已经转发的请求是否迟迟没有 reply，或只在某些域名上超时。

请求总量高不等于转发中的查询多。被本地拦截、缓存命中、请求合并以及上游响应速度都会影响等待数量。不能仅从“某设备一天查了几千次”推断它用尽了 150 个并发位置。

若所有域名都受影响，核对上游服务存活、网络连通性、实际端口和防火墙。只有某组域名受影响时，查看是否有专用转发规则、对应上游或权威服务器不回答；不要先把所有失败域名加进允许列表。

Pi-hole 与本机 Unbound 要区分端口

假设 Pi-hole 和 Unbound 运行在同一主机网络中，Unbound 实际监听 127.0.0.1:5335，可由管理员做下面的少量只读查询；这是检查结构示例，不是安装配置：

dig @127.0.0.1 -p 5335 example.com A +time=3 +tries=1
dig @127.0.0.1 -p 5335 example.com A +tcp +time=3 +tries=1

将查询名替换为当时失败的业务域名，并对照一个允许查询且原本正常的域名。UDP 和 TCP 的结果有助于检查是否只阻断了一类 DNS 传输；一次正常结果不能排除间歇性丢包或故障时的上游延迟。

这里的回环地址和端口必须与实际部署一致。Pi-hole、Unbound 分属容器时，127.0.0.1 指向发起命令的网络空间，不能据此判断另一容器是否工作。转发到端口 53 与 5335 也不是同一入口。

如果直接查询 Unbound 也失败，继续在 Unbound 与它的上游路径检查日志、实际递归或转发模式及网络。缓存命中的域名能够回答，并不足以证明它还能完成新的递归查询。

排除转发链绕回自己

列出 Pi-hole 的上游、路由器 DNS、Unbound 的转发设置，以及针对本地域名或反向解析的转发规则。顺着同一次查询看它下一跳到哪里，确认没有从 Pi-hole 到路由器，再由路由器回到 Pi-hole 的循环。

递归模式的 Unbound 应按配置访问所需 DNS 服务器；转发模式则依赖指定的上游。把主机系统 DNS、Pi-hole 上游和 Unbound 转发目标统一填成同一个地址，可能形成相互依赖。更改前保存原配置，只修正确认错误的一条链，同时保留内部域名解析要求。

不要用 HTTP 访问某个解析出来的 IP，再从网页错误推断 DNS 上游无响应。那是另一次、另一种协议的请求，不能证明此前的 DNS 查询处于什么状态。

修复等待原因后，再评估容量

确认上游不响应、链路阻断或转发循环时，先修对应问题。确实需要切换上游，应选符合隐私、过滤与内部域名要求的服务，并评估失去本地解析规则的影响；不能只换成一个公共地址便算完成。

只有上游工作正常、实际合法负载仍超出当前容量时，才按版本支持的方式评估 dnsmasq 并发配置与资源。增大限制会允许更多查询同时等待，不能使故障上游恢复。dnsmasq 的并发限制还与 server group 有关，不应把一个警告机械理解为所有上游共享一个固定的全局数字。

重启可能暂时清掉等待状态，也会中断 DNS 服务；没有修复根因时警告仍会回来。保留故障时日志，避免把定时重启变成排查的替代。

调整后，在原故障时间段和原客户端上确认目标域名得到预期答案、上游回答及时、并发警告不再持续出现，其他客户端与内部域名也能使用。回退时恢复保存的转发与过滤设置，再核对实际 DNS 路径；只看到管理页面可打开，不足以证明全网解析已经恢复。