# 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`](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 |

开机后的 6.5 小时里路由器重启过一次，原因查不到：没有 pstore，当前日志中也没有 OOM 记录。按查询日志的增长速度，内存迟早会被耗尽，那次重启很可能就是这个原因，但没有证据。

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. 限流：所有局域网客户端共用一个额度

```yaml
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`：

```diff
 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 是漏配了。

### 修改

```sh
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`。约 2.5 分钟后路由器**又重启了一次**，原因不明：`/sys/fs/pstore` 为空，没有 panic 记录；日志从新的一次开机开始，前一次开机的日志已丢失。可能是手动重启，也可能是硬件看门狗（`mtk-wdt`，31 秒）复位。如果以后再出现无故重启，需要先把日志写到持久存储再查。

第二次开机后（18:35:40 左右）：

| 项目 | 结果 |
|---|---|
| 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://home…`、`wss://cloud…`、`wss://backup…`；配置里还保留着两条 `wss://…:0` | 未改，需要用户确认后重启 |

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

## 回滚

```sh
# 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
```