yuanzhe1999/openwrt-build-helper
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
55c69e63edf59f3e4c5ec3badc8ccf750c70c85b
openwrt-build-helper/reports/2026-10-30-cudy-tr3000-adguardhome-memory.md

15 KiB
Raw Blame History

Cudy TR3000：AdGuard Home 内存与限流问题、DHCP 不下发 DNS 导致 iPad 无网络

  • 日期：2026-10-30
  • 设备：Cudy TR3000 256MB v1（cudy-tr3000.tail694d4.ts.net，远程）；另检查了 Linksys MX8500（linksys-mx8500.tail694d4.ts.net）
  • 系统：OpenWrt 25.12.6 r33311-981c978eff，mediatek/filogic
  • AdGuard Home：0.107.79
  • 相关报告：2026-10-28-cudy-tr3000-wwan-watchdog.md

摘要

# 问题 处理
1 AdGuard Home 查询日志写在 tmpfs，6.5 小时涨到 122 MB，可用内存只剩 20 MB 改为 6 小时轮转，并忽略 EasyTier 对端域名（MX8500 同样处理）
2 ratelimit: 20 按网段计算，整个局域网共用一个额度 改为 ratelimit: 0（MX8500 同样处理）
3 dnsmasq 改到 54 端口后，DHCP 不再下发 DNS 服务器，iPad 显示无网络 增加 dhcp_option '6,192.168.156.65'
4 排查时逐包写内核日志，导致 Wi-Fi 固件超时重置，两条上联和两个热点断开约 80 秒；之后 5G 热点没有恢复 执行 wifi 后恢复
5 Wi-Fi 重启后，iPad 用原来的私有 MAC 仍收发不通（真实 MAC 可以） 重启路由器后恢复

背景

反馈“AdGuard DNS 好像崩溃了”。排查时 AdGuard Home 进程正常运行，路由器上解析也正常，但发现两个会导致 DNS 不稳定甚至整机卡死的问题：

  1. 查询日志写在内存里（tmpfs），6.5 小时涨到 112 MB，可用内存只剩约 20 MB。
  2. 限流 ratelimit: 20 按网段计算，所有局域网设备共用一个额度，高峰期已超过上限。

同时 iPad 连上 Wi-Fi 后一直显示“无互联网连接”，后来查明是另一个问题（第 3 项）。

现象

时间 可用内存 querylog.json 说明
17:31 86 MB 112 MB 开机 6.5 小时，负载约 2.9
17:53 20 MB 121 MB
17:54 – 17:56 — 122 MB SSH 和 Tailscale ping 均超时约 1 分钟，负载升到 9.9；没有重启
17:57（修复后） 234 MB 0.2 MB /tmp 从 135 MB 降到 5.4 MB

上述内存数据证明查询日志占用较大，但不能据此认定此前重启由内存耗尽引起。

17:54 的卡顿还有一个人为因素：排查时一条 tail -20000 querylog.json 命令超时被中断，但路由器上的 tail 进程没有退出，一直以 R 状态占用 CPU。它还持有已删除的 querylog.json，导致删除后约 112 MB 内存迟迟没有释放。手动 kill 后内存才回来。以后在路由器上分析大文件，要先复制一小段出来再处理，并确认远端进程已退出。

原因

1. 查询日志：几乎都是 EasyTier 解析对端域名

开机至 17:30 共 166000 条查询：

域名 次数
cloud.zhe-yuan.top 119301
home.zhe-yuan.top 18438
backup.zhe-yuan.top 16155
其他所有域名 约 12100
客户端 次数 设备
fd84:1963:e466::7c3 100529 intel-nuc8i5beh
127.0.0.1 / ::1 29596 / 29520 路由器自身
fd84:…:ec56:… 6148 Windows-Dev-Kit
fd84:…:ed94:… 207 Galaxy-Z-Fold8

这三个域名正是 EasyTier 的对端地址（/etc/easytier/config.toml 的 [[peer]]）。easytier-cli connector 显示这些连接器一直处于 Connecting，每次重试都会重新解析域名。NUC 上的 EasyTier 应该也是同样情况。

上游 TTL 正常（cloud 约 300 s，home 约 250 s），AdGuard 都是从缓存回答，所以对上游没有压力。问题在于每条查询都写进了日志：

  • querylog.interval: 90d：查询日志保留 90 天，实际上不会轮转。
  • 日志目录在 /var/lib/adguardhome，也就是 tmpfs（内存）。
  • 每条记录约 700 字节（包含完整的 base64 应答）。

平均每秒约 7 条，每小时约 17 MB。

2. 限流：所有局域网客户端共用一个额度

ratelimit: 20
ratelimit_subnet_len_ipv4: 24
ratelimit_subnet_len_ipv6: 56

限流按 IPv4 /24 或 IPv6 /56 计算，整个局域网（192.168.156.0/24、fd84:1963:e466::/48 内的 /56）只有每秒 20 次的共用额度。抽样的 3000 条记录里，局域网客户端的高峰是每秒 24 次，主要来自 NUC 的 EasyTier 解析。被限流的查询直接丢弃且不写日志，其他设备会偶尔解析失败而查不到记录。

修改内容

备份：/root/adguardhome.yaml.bak

/etc/adguardhome/adguardhome.yaml：

 dns:
-  ratelimit: 20
+  ratelimit: 0
 querylog:
-  ignored: []
-  interval: 90d
+  ignored:
+    - cloud.zhe-yuan.top
+    - home.zhe-yuan.top
+    - backup.zhe-yuan.top
+  interval: 6h
-  ignored_enabled: false
+  ignored_enabled: true

另外停止 AdGuard Home 后删除了旧的 querylog.json，然后重启服务。

  • interval: 6h：AdGuard Home 轮转时保留 querylog.json 和 querylog.json.1 两个文件，最多约 12 小时的记录。去掉 EasyTier 的查询后，每 6.5 小时约 12000 条、约 9 MB，最坏情况约 20 MB。
  • 忽略三个 EasyTier 对端域名：只是不写入查询日志，统计和解析不受影响。
  • ratelimit: 0：关闭限流。防火墙 wan 区（wan、wan6、wwan2、wwan5、wwan26、wwan56）的入站是 REJECT，外网访问不到 53 端口；能访问的只有 lan 和 meshvpn（Tailscale、ZeroTier），都是自己的设备。

/etc/adguardhome/adguardhome.yaml 在软件包的 conffiles 里，sysupgrade 会保留，不需要加进 /etc/sysupgrade.conf。

验证

$ nslookup example.com 127.0.0.1
Address: 104.20.23.154

$ nslookup google.com 192.168.156.65
Address: 2607:f8b0:4009:812::200e

$ df -h /tmp
tmpfs   242.7M   5.4M   237.3M   2% /tmp

$ free
Mem:  total 497044  used 207988  free 216488  shared 5568  available 233988

AdGuard Home 重启后约 15 秒才开始监听 53 端口（当时负载较高），这期间 DNS 不可用。

问题 3：DHCP 不下发 DNS，iPad 显示“无互联网连接”

现象

两台 iPad（iPad 7a:ca:e0:6d:f3:3f、iPad-Pro 80:a9:97:a6:b8:61）连上 Wi-Fi 后显示“无互联网连接”，浏览器报 ERR_INTERNET_DISCONNECTED。切换私有 Wi-Fi 地址也不管用。iPad 上的地址、子网掩码、路由器都正常：192.168.156.123 / 255.255.255.192 / 192.168.156.65。

排查过程

检查 结果
无线 关联正常，-44 dBm，HE-MCS 11
DHCP 正常拿到 192.168.156.123
路由器 ping iPad 通
conntrack 没有任何从 iPad 发起的连接
AdGuard 查询日志 开机以来没有这台 iPad 的记录
nft 计数（只计数，不写日志），3 分钟 只有 mDNS、IGMP/MLD 和 1 个查询网关的 ARP，没有 DNS，没有 TCP
重新入网时双向抓包 DHCP、ARP、RS/RA 都正常；之后 iPad 不发 DHCPv6、不发 DNS，完全静默
临时关闭局域网 RA 和 DHCPv6 没有变化，已恢复
打开 dnsmasq logdhcp DHCPACK 里没有 option 6（DNS 服务器）

logdhcp 记录的 DHCPACK 内容（iPad 请求了 option 6，但没有收到）：

requested options: 1:netmask, 121:classless-static-route, 3:router,
requested options: 6:dns-server, 15:domain-name, 108:ipv6-only,
requested options: 114:captive-portal, 119:domain-search, 162, 252
sent option: 53 message-type 5
sent option: 54 server-identifier 192.168.156.65
sent option: 51 lease-time 12h
sent option:  1 netmask 255.255.255.192
sent option: 28 broadcast 192.168.156.127
sent option:  3 router 192.168.156.65
sent option: 15 domain-name lan

原因

为了让 AdGuard Home 使用 53 端口，dnsmasq 被改到了 port=54。dnsmasq 不在 53 端口提供 DNS 时，不会自动把自己作为 DNS 服务器（option 6）写进 DHCP 应答。

其他设备没受影响，是因为它们走 IPv6：odhcpd 的 RA 里带了 DNS（fd84:1963:e466::1），它们也有 ULA 地址。AdGuard 查询日志里的局域网客户端全是 fd84: 地址，正好印证了这一点。iPad 没有拿到 ULA 地址（原因见“附带发现”），用不了这个 IPv6 DNS，IPv4 又没有 DNS，iOS 就判定这个网络不能上网，连 DNS 查询和联网检测都不发。

MX8500 上本来就配了 dhcp_option '3,192.168.156.1' '6,192.168.156.1' '15,lan'，所以没有这个问题。TR3000 是漏配了。

修改

uci add_list dhcp.lan.dhcp_option='6,192.168.156.65'
uci commit dhcp
/etc/init.d/dnsmasq restart

修改后 iPad 重新入网，立刻开始正常解析，并发起大量连接（iCloud、Google 等）。conntrack 里能看到它到 192.168.156.65:53 的查询都有应答，一度建立了 112 条连接。

问题 4：排查导致 Wi-Fi 固件重置（我的操作引起）

经过

排查 iPad 时，在 phy1-ap0 入方向（netdev ingress）和 bridge output/forward 上加了 nft 规则，把进出 iPad 的每个包都写进内核日志。iPad 拿到 DNS 后流量突增，每个包要记录好几次（bridge 泛洪时 eth0、eth1、phy*-ap0 各记一次），CPU 被打满（负载 11.6）：

时间 事件
18:14:28 iPad 开始大量收发；phy1-sta0（wwan5）因不活动断开
18:14:30 eth0: NETDEV WATCHDOG: transmit queue 0 timed out 5020 ms
18:14:32 phy1-ap0 link down
18:14:34 – 18:15:24 mt798x-wmac: Retry message ...（Wi-Fi 固件 MCU 消息超时）
18:14:43 phy0-sta0（wwan2）断开
18:15:35、18:15:42 ieee80211 phy0/phy1: Hardware restart was requested，固件重新加载
18:15:50 wwan5、wwan2 重新上线
18:16:23 调试规则按计划自动删除

两条上联和两个热点断开约 80 秒，这期间 iPad 报 ERR_NAME_NOT_RESOLVED。

教训：在这台 MT7981 上不要用 nft log 逐包记录，哪怕只针对一台设备。只用 counter 计数（开销可以忽略），或者限速记录（limit rate 10/second）。

后遗症与恢复

  • 5G 热点没有恢复：固件重置期间，wwan5 从信道 52 漫游到了信道 165。phy1-ap0 一直处于 down 状态，hostapd 也没有再启用它。推测是 165 只支持 20 MHz，而热点设的是 HE80，但没有确证。
  • iPad 在 2.4G 上收发不通：见问题 5。

18:20:17 执行 wifi（后台运行，避免 SSH 断开时被中断），两个射频都重新配置。5G 热点在 18:21:32 恢复（wwan5 此时在信道 112，热点 HE80，中心 5530 MHz，等 DFS 检测约 60 秒），两条上联在约 10 秒内恢复。

问题 5：iPad 无线链路不通（重启路由器后解决）

执行 wifi 后，Galaxy 重新连上并正常工作，但 iPad（7a:ca:e0:6d:f3:3f）在两个频段都连不通。iPad 自分配了 169.254.237.114。

项目 iPad Galaxy（同一个 phy0-ap0）
authorized / MFP yes / yes yes / yes
信号 -40 dBm -39 dBm
rx packets 239 14695
tx packets / tx failed 6 / 30 32392 / —
rx 速率 1.0 Mbit/s（只有最低速率的管理帧） 正常
phy0-ap0 netdev ingress 计数（25 秒） 0 —

驱动收到了 iPad 的帧，但没有一个送到网络接口。路由器发给 iPad 的帧大多也没有得到确认。信号很强，不是距离问题。Galaxy 在同样的重置之后工作正常。

用户测试：iPad 用“固定”私有地址（7a:ca:e0:6d:f3:3f）连不通，改用真实 MAC 可以连通。说明问题跟这个 MAC 绑定在一起，最可能是 Wi-Fi 固件里这个 MAC 的站点表项在固件重置后坏了。wifi 只重建接口和 hostapd，不会重新加载 MT7981 固件，所以没能清掉。

解决：重启路由器

18:33 执行 reboot，用户随后确认恢复正常。

重启后检查结果（启动早期墙上时钟会校准，以下以状态和日志事件为准）：

项目 结果
wwan5 / wwan2 开机约 50 秒后上线
5G 热点 信道 112（DFS），18:36:57 CAC 完成后启用，HE80
iPad（7a:ca:e0:6d:f3:3f，固定私有地址） 先连 2.4G、后连 5G，DHCP 正常；5G 上 tx HE-MCS 8（206.5 Mbit/s）、rx HE-MCS 9，conntrack 71 条连接
设置 dhcp_option '6,192.168.156.65'、AdGuard ratelimit: 0 与 interval: 6h、看门狗 crontab 都在

用户确认 iPad 恢复正常。

附带发现

  • odhcpd 通告 /60 前缀，RA 生存期为 0：局域网是 ip6assign='60'，ubus call dhcp ipv6ra 显示通告的前缀是 fd84:1963:e466::1/60。SLAAC 需要 /64，这很可能就是 iPad 没有 ULA 地址的原因。odhcpd 还在反复报 no public prefix on lan thus we announce no default route by setting ra_lifetime to 0。局域网没有 NAT66，IPv6 本来就上不了外网，所以没有改。如果以后要让局域网的 ULA 更可靠，可以改成 ip6assign='64'。
  • DHCP 地址池只有 27 个：局域网是 /26，start=100 limit=150 实际只能用 .100–.126。iPad 使用私有 Wi-Fi 地址时，每次换地址都会多占一个租约，iPad-Pro 已经拿到了最后一个地址 .126。
  • EasyTier：用户删掉了无效的对端。TR3000 重启 EasyTier 后，现在是 tcp://cloud…:11010 和 tcp://backup…:11010。之前的 wss://…:0/easytier/ 一直处于 Connecting，用 curl 测试服务器可达（返回 HTTP 400），推测问题出在端口写成了 :0。easytier-core 约 30% 的 CPU 主要用于给 intel-nuc8i5beh 转发流量（112 MB）。

Linksys MX8500 检查

项目 MX8500 处理
DHCP option 6 已配置 6,192.168.156.1，生成的 dnsmasq 配置里也有 dhcp-option=lan,6,192.168.156.1；iPhone（.43、.46）在 AdGuard 里有 IPv4 查询记录；日志中没有 DHCPNAK 或地址耗尽 无需修改
DHCP 地址池 同样只有 27 个（.36–.62） 未改
RA 前缀 同样是 /60（fd22:5891:d9c2::1/60） 未改
ratelimit 20 改为 0（wan 区入站同样是 REJECT）
查询日志 90 天，11.5 小时 59 MB（/tmp/lib/adguardhome/data），绝大部分是本机 EasyTier 的解析 改为 6 小时轮转，并忽略三个 EasyTier 对端域名
内存 887 MB 总量，修改前可用 243 MB；/tmp 61 MB → 5 MB —
EasyTier 初查时配置 17:48 改过但未重启；配置仍有两条 wss://…:0 18:43 按用户要求重启，cloud、backup 两条 TCP 均为 Connected，旧 home 连接器消失；两条 WSS 仍为 Connecting，保留待办

MX8500 备份：/root/adguardhome.yaml.bak。修改后 DNS 正常，53 端口在 20 秒内恢复监听。

EasyTier 收尾验证：执行 /etc/init.d/easytier restart，启动初期 CLI 的 RPC 端口尚未就绪，随后查询成功。核心进程 PID 从 5950 变为 5638；easytier-cli peer 能列出 CloudCone、Mac mini、TR3000 等节点。本次重启加载现有配置，没有修改 peer 地址。

回滚

# AdGuard Home（两台路由器相同）
/etc/init.d/adguardhome stop
cp /root/adguardhome.yaml.bak /etc/adguardhome/adguardhome.yaml
/etc/init.d/adguardhome start

# TR3000 DHCP DNS（不建议回滚，否则只有 IPv6 DNS 可用）
uci del_list dhcp.lan.dhcp_option='6,192.168.156.65'
uci commit dhcp && /etc/init.d/dnsmasq restart