NasWorks 部署记录

系统

ImmortalWrt 18.06-k5.4-SNAPSHOT r12339 (x86/64)

管理地址

192.168.4.200 · SSH root(本机已放密钥，可直接连)

LAN 口

eth0 · 静态 192.168.4.200/24 · 网关 192.168.4.1

角色

全屋默认网关 + DNS 下发;光猫 192.168.4.1 仅做出口 NAT

关键进程

AdGuardHome(192.168.4.200:53,本地 DNS + 去广告);dnsmasq(OpenWrt 内置，原兼 DHCP;2026-10-31 起 DHCP 已关、仅留 DNS 转发);DHCP 现由 NAS 主机上的 nas-dhcp 容器接管(macvlan 容器收不到客户端 DHCP 广播，详见改动/踩坑);OpenClash / Clash Meta(PID 常驻,7892=redir 入口、7890=http、9090=API)——只代理 TCP，UDP 在 mangle 链里被全部 RETURN 掉，不走代理

其他接口

vpn0(tun0)、zerotier(dhcp 获取地址)

1. dnsmasq 拒绝启动：检测到同网段已有 DHCP 真坑

光猫 DHCP 还没关时，旁路由 /etc/init.d/dnsmasq restart 后，日志报:

found already running DHCP-server on interface 'eth0' refusing to start, use 'option force 1' to override

这是 dnsmasq 的安全保护:启动时探听到网里已有别的 DHCP 服务器，拒绝抢答 (避免双 DHCP 打架)。正确做法：先关光猫 DHCP,再 restart 旁路由 dnsmasq。 不要图省事加 option force 1——那会强制双 DHCP 并存。

2. 双 DHCP 同时开 = 客户端网关随机 必踩

两个 DHCP 服务器同时响应时，客户端拿到哪个全看谁先答：网关可能是 .1 也可能是 .200,表现为间歇性断流、部分设备上不了网。全网只能有一个 DHCP 服务器。

2.1 地址池重叠 + dhcp-authoritative 的 NAK 死循环 真坑

地址池重叠（2026-10-31 实测）：光猫池 192.168.4.2 – .254，nas-dhcp 池 .100–.199 —— 完全被覆盖。两个 DHCP 并存时会把同一个 IP 真的发给两台设备，形成 IP 冲突，两边都时通时断。

NAK 死循环：dnsmasq.conf 里原来有 dhcp-authoritative，它会对"不属于自己池子"的续租请求一律回 NAK。拿到光猫地址的设备每次续租都被打回，陷入 DISCOVER→NAK 循环，永远拿不到稳定地址 —— 表现是全屋同时失去网络，而一停 nas-dhcp 立刻恢复。

已修：删除 dhcp-authoritative（dnsmasq --test 通过）。但池重叠本身没法靠改配置解决——要么只开一个 DHCP，要么先把光猫池收窄到 .2–.99，.100–.199 才能安全交给 nas-dhcp。

2.2 「切了 DHCP 就恢复」是假因果 认知坑

现象：全屋断网时，停掉 nas-dhcp + 打开光猫 DHCP → 立刻恢复。很容易得出"是 DHCP 配置搞坏了网络"。

为什么这个推断不成立：切换 DHCP 这个动作发生在光猫上。光猫的 DHCP / DNS 代理 / NAT / Web 管理通常是同一个固件进程在管，改一次设置会重启它的 LAN 服务栈——这本身就能把卡死的状态清掉。恢复可能来自"重启了光猫的服务"，而不是"换了哪个 DHCP"。

更强的判据：故障时把本机网关和 DNS 都手动改成光猫 192.168.4.1（等于完全绕开旁路由）。如果仍然不通，说明问题不在旁路由这条链路、也不在 DHCP 分配，而在光猫或更上游——因为旁路由默认路由就是 via 192.168.4.1，全屋只有一个出口，改网关改变不了出口。

该判据来自 2026-10-31 用户实测：改到 .1 依然阻塞，且全屋所有设备同时断——共同节点只有光猫。

2.3 容器 exit 0 + --restart = 无限重启，而 docker ps 看着像在跑 真坑

现象：重建 nas-dhcp 后 docker ps 显示 Up 2 seconds，看起来正常。实际 RestartCount=10 一路涨，ExitCode=0，DHCP 一秒都没服务过。

根因：镜像自带的 CMD 是 sh -c "apk add --no-cache dnsmasq; echo rc=0" —— 只装包，不启动 dnsmasq。装完 exit 0，而 --restart unless-stopped 对 任何退出码都重启（不只是异常退出），于是无限循环。

判据：看 docker inspect 的 RestartCount 和 State.StartedAt，不要只看 docker ps 的 Up xx —— 重启循环时它永远显示刚启动。另一招是 docker exec <name> ps aux，看 PID 1 到底是不是目标进程。

修法：docker run 末尾显式传启动命令。本服务的：

sh -c 'command -v dnsmasq >/dev/null 2>&1 || apk add --no-cache dnsmasq >/tmp/apk_dns.log 2>&1; exec dnsmasq -k --conf-file=/etc/dnsmasq.conf'

exec 让 dnsmasq 顶替 shell 成为 PID 1，信号才能正确送达；command -v 命中就跳过 apk（dnsmasq 2.92rel2 本就在镜像 /usr/sbin/ 里）。

2.4 docker start 不会应用新挂载 脚本坑

改完 -v 挂载后 docker start，容器照旧起来、进程照旧跑，但挂载还是旧的。本服务实测：三个挂载只剩 dnsmasq.conf，log/ 与 leases/ 在 NAS 上全空，日志和租约仍写在容器可写层 —— 容器一重建就全丢。

判据：docker inspect <name> --format '{{range .Mounts}}{{.Source}} -> {{.Destination}}{{println}}{{end}}' 逐条对；再对一眼 NAS 侧目录里是否真的有文件（目录存在 ≠ 有文件）。

修法：改挂载必须 docker rm -f + docker run 重建。重建前先把容器内的日志和租约 docker exec ... cat 导出来，否则 rm 一执行就没了。

2.5 挂载日志目录后，NAS 上的普通用户读不了日志 权限坑

dnsmasq 在容器内以 uid 100 打开 /var/log/dnsmasq.log，创建出来是 0660、属主 uid 100。/volume2 的目录虽是 777，但文件本身 qinchao 读不了 —— tail 直接 Permission denied，日志落盘却等于没法看。

修法：启动前预建文件并放开到 666：

[ -f "$DIR/log/dnsmasq.log" ] || : > "$DIR/log/dnsmasq.log"
chmod 666 "$DIR/log/dnsmasq.log"

dnsmasq 不会 chmod 既有文件，权限得以保留（实测重启后仍是 666）。租约文件不用管：dnsmasq 重写时用的是 0644，全局可读。

3. uci -q delete 不存在的 option 返回 rc=1 脚本坑

想"清空旧 option 再 add_list"时，如果原本没有这个 option,uci -q delete dhcp.lan.dhcp_option 会返回 1。脚本里若用了 set -e,会在这里直接中断，后面的 commit/restart 全没执行。去掉 set -e,或单独忽略这步的返回值。

4. 旁路由作网关不需要 MASQUERADE 认知坑

一度以为要开 NAT 客户端才能出网。其实客户端与光猫同二层，旁路由只做路由转发就行;光猫回程能直接送回客户端真实 IP。开 MASQUERADE 也能用，但会掩盖客户端真实 IP，非必要不开。

5. macvlan 容器收不到外部 DHCP 广播 真坑

把 DHCP 服务器放在macvlan 容器里时，客户端发的 DHCP 广播 DISCOVER 到不了容器——macvlan bridge 模式不会把外部广播转发给容器端口(单播正常，所以"已连设备能用、新设备不行")。在容器 netns 内抓包 0 个包，宿主机 eth0 却能抓到真实客户端的广播，根因坐实。

promisc 无效:给父接口 eth0 开混杂模式不能解决这个广播转发问题 (实测)。

修法:DHCP 服务改跑在宿主机 host-network 容器上，或把 macvlan 父接口改成 Linux 桥。本项目选前者 (不动 Synology 网络栈、可一键回退):nas-dhcp 容器 --network=host 接管 DHCP，网关/DNS 仍下发 192.168.4.200。

6. 去广告"手机上还有广告"≠ 没走对 DNS 认知坑

⚠️ 后续更正：手机/iPad 实际连的是光猫自带 Wi-Fi(192.168.2.x 独立网段)，压根没走 AGH——见下方卡片 7。本卡片结论仅适用于"设备确实在 192.168.4.x 网络"的情形。

先证伪"客户端绕过"假设:AGH 查询日志里，手机 (iPhone,租约 192.168.4.125) 的查询确实打到了 192.168.4.200(日志命中 246 条),且 ad.doubleclick.net、pvs.sohu.com、auth.wosms.cn 等都被 IsFiltered:true 拦掉。即手机 DHCP 拿到的 DNS=192.168.4.200,且 AGH 在工作、在拦。

那为什么还看到广告？这是 DNS 去广告的固有局限,不是配置坏了：① 视频 / App 内广告 (YouTube、抖音、腾讯视频、游戏 SDK)常与正文同域名、走 HTTPS,没有独立广告域名可拉黑;② 个别 App 内置 DoH/DoT 或硬编码 IP 会绕过 AGH(日志显示手机主流流量仍走 AGH，属部分绕过，非整体失效)。

定位办法:AGH 后台 → Query Log,按客户端 192.168.4.125 过滤，看哪些"允许"的域名像广告 → 把具体域名告诉我加自定义规则;或在手机上关"私人 DNS / iCloud 私人中继"排除加密 DNS 绕过。想进一步防 DoT 绕过，可在 OpenWrt 加封 853 与常见 DoH 域名 (你已选"只开明文 53 重定向",暂未做)。

7. 光猫自带 Wi-Fi 的网段行为:三次实测结论不一致 待确认

三次实测(动作相同、结果不同):

已能确定:手机所连的 Wi-Fi 是桥接到 LAN 的——关掉光猫 DHCP 后，只要启动 nas-dhcp，手机就能拿到 192.168.4.x，说明 DHCP 广播确实能到达 nas-dhcp(host-network，跑在 NAS 宿主 eth0 上)。这也解释了为什么 169.254.x.x 会出现：那一刻网里一个 DHCP 服务器都没有。

尚不能解释:早上那次 192.168.2.x 从哪来。若 Wi-Fi 桥接 LAN、且当时 nas-dhcp 确在运行(已由 restarts=0 证明)，手机不该拿到 .2.x。可能是：当时连的是光猫的另一个 SSID / 频段(2.4G 与 5G 可能分属不同 VLAN)，或光猫在特定状态下启用了兜底 DHCP。下次复现请记录「手机连的是哪个 SSID」。

⚠️ 本卡片不解释"断网"本身。早上断网的根因已定位为 Clash 的 TCP REDIRECT 路径失效(见"改动记录"与下方卡片 8)，与 Wi-Fi 网段无关。

8. "有 IP、能解析、打不开网页" = 先查 TCP REDIRECT，别查 DHCP/DNS 真坑

现象模板:设备拿到正常内网 IP，dig 能解析域名，ping 192.168.4.1 正常，但所有网页 / App 打不开。

为什么容易误判:直觉上"上不了网"第一反应查 DHCP 和 DNS。但在本架构下这两条都是独立旁路，它们好着的时候 TCP 仍然可以全断。

复现时按顺序抓这 5 项(缺一项就无法定论):

# ① TCP 是否还在被 REDIRECT 进 Clash(计数应持续增长)
docker exec openwrt iptables -t nat -L openclash -n -v

# ② Clash 的 redir / tproxy 入口是否在监听
docker exec openwrt netstat -tlnp | grep -E ":7892|:7895"

# ③ 从故障客户端直接打 Clash 的 http 入口(绕过 iptables,看能否出网)
curl -x http://192.168.4.200:7890 -m 8 -s -o /dev/null -w '%{http_code}\n' \
  http://www.gstatic.com/generate_204

# ④ Clash 自身还能不能测节点延迟(能测=内核活;不能测=内核假活)
curl -s -H "Authorization: Bearer <secret>" \
  "http://192.168.4.200:9090/proxies/VPS-Reality/delay?url=http://www.gstatic.com/generate_204&timeout=5000"

# ⑤ 内核有无 conntrack 满 / 丢包
dmesg | grep -iE "conntrack|table full"
cat /proc/sys/net/netfilter/nf_conntrack_count

判读:②③④ 都正常但客户端仍不通 → 问题在 nat 规则/转发层；④ 失败 → Clash 内核假活，重启 Clash 即可(不必重启整台旁路由，更不必动 DHCP)。

应急逃生:把客户端网关 + DNS 改回 192.168.4.1 就能绕过整条 Clash 链路立即上网——这正是本次"停 nas-dhcp + 开光猫 DHCP 就恢复"的真正原因。

版本

luci-app-openclash 0.46.137 · 内核 linux-amd64

控制台

http://192.168.4.200:9090(API) / LuCI → 服务 → OpenClash

运行模式

fake-ip · fake-ip 段 198.18.0.1/16

代理模式

rule(按规则分流)

配置文件

/etc/openclash/config/*.yaml · 运行时 /etc/openclash/*.yaml

注意事项 动手前必看

• 代理端口开着认证(用户名 Clash，口令在 LuCI → OpenClash → 覆写设置)。直连 7890 不带凭据会返回 407，看起来像"代理坏了"。口令不要写进仓库或文档。
• log_level = 0(silent)，Clash 不输出连接日志，出问题只能靠现象推断。要排查时临时调高日志级别。
• Clash 会"假活"：进程在、9090 API 能响应、节点延迟能测，但 7892 不处理新连接 → 全屋网页打不开。此时重启 Clash 即可，不用重启旁路由，更不用动 DHCP。
• 旁路由是全屋流量单点：它宕机 = 全家断网。留好逃生通道(把设备网关手动改回 192.168.4.1)。

1. Clash 会"假活"：进程活着但不处理新连接 真坑

现象:全屋网页打不开，但 ps 能看到 Clash 进程、9090 API 正常响应、甚至能测出节点延迟。

根因:7892 redir 入口不再接受新连接(长跑后状态异常)。进程存在 ≠ 服务可用。

解决:重启 Clash 即可。不必重启旁路由，更不要动 DHCP —— 曾经因为误判成 DHCP 问题折腾很久。

判据:"有 IP、能解析、网页打不开" → 查 TCP REDIRECT / Clash redir 入口，别查 DHCP、别查 DNS。

2. 直连 7890 返回 407，被误判成"代理挂了" 坑

OpenClash 开着代理认证，curl -x http://192.168.4.200:7890 不带凭据一律 407。加上凭据即可:

curl -x 'http://Clash:口令@192.168.4.200:7890' https://www.google.com/generate_204

错误口令返回 403，可以据此区分"没带凭据"和"口令错"。

3. 7890 对国内 DIRECT 域名一律失败，只有境外能通 真坑

现象:用 7890 做上游时，境外站点正常，但 baidu.com / bilibili.com 这类走 DIRECT 的域名，CONNECT 返回 200 后一发明文就断(客户端看到 000)。

结论:这个环境里 HTTP 代理端口不适合当上游。正确做法是让下游程序把默认网关指向 192.168.4.200，由透明代理接管 —— mitmproxy 就是这么改的(见 mitmproxy 的「方案与决策」)。

另外：在旁路由容器内部连 127.0.0.1:7890 访问境外也失败 —— openclash_output 链把容器自己的出站绕成了环。所以容器内不要做联网测试。

4. log-level: silent 导致故障无法回溯 坑

配置里 log_level = 0(silent)，Clash 内核不输出连接日志，/tmp/openclash.log 只有脚本层的版本检查记录。出问题时只能靠现象推断。

建议:排查时临时调高日志级别并落到 /volume2(容器重建不丢)，否则下次复现仍然抓瞎。

5. fake-ip 让"容器内测网"的结论全部失真 坑

容器内解析境外域名得到 198.18.x.x，这个地址只有 Clash 认得。任何绕过 Clash 的探测(直连 curl、ping)都会失败或超时，看起来像"网络坏了"，其实只是没走代理。

所有验证都要从局域网其它设备发起，或在容器内显式走代理端口。

版本

AdGuard Home v0.107.39

监听

:::53(IPv4 + IPv6 全接管)

管理面板

http://192.168.4.200:3000

配置文件

/etc/AdGuardHome.yaml(规则在 user_rules 段)

数据目录

/usr/bin/AdGuardHome/data/(querylog.json / filters/ / stats.db)

上游 DNS

127.0.0.1:7874 —— 指向 OpenClash，不是公共 DNS

注意事项 动手前必看

• AGH 只能按域名整拦。同一个域名下混着正文和广告(第一方广告)就拦不了 —— 这是 DNS 方案的物理天花板，要治只能上 MITM(见「mitmproxy 广告改写」)。
• 改完配置要重启才稳：/etc/init.d/AdGuardHome restart。热改 user_rules 有时不立即生效。
• 改之前先备份：cp /etc/AdGuardHome.yaml /etc/AdGuardHome.yaml.bak-$(date +%Y%m%d%H%M)。误加一条规则可能让某个 App 整页打不开。
• 设备设了 HTTP 代理后，AGH 对它完全失效 —— 因为代理模式下设备只发 CONNECT host:443，不做 DNS 查询。这种情况下要在 MITM 层补一份同样的名单。

1. 拦截规则写了却不生效：放行规则优先 真坑

现象:加 ||ads.privacy.qq.com^ 后该域名仍正常解析。

根因:订阅的规则库里已经有 @@||ads.privacy.qq.com^ 放行规则，放行永远压过拦截。

解决:先查有没有 @@ 冲突，再决定是删掉自己的规则还是加 $important 提权。别急着怀疑 AGH 没启动。

2. querylog 不实时落盘，抓不到刚发生的请求 真坑

现象:刚打开 App 制造了广告请求，去 querylog.json 里找不到。

根因:AGH 的查询日志在内存里缓冲，定时刷盘，间隔可达 5 分钟以上。

应对:要么等几分钟再看，要么直接在面板的「查询日志」里实时看(内存态)。抓开屏广告时尤其容易踩 —— 素材预缓存的请求可能压根没发生。

3. 把共享网关当独立广告 CDN → 整页功能被打挂 真坑(已回滚)

现象:拦掉 igtmpg1.kuwo.cn(波点音乐)后，乐库和商场页面打不开。

根因:bd-api.kuwo.cn(波点的 API)CNAME 到 igtmpg1.kuwo.cn，同一个网关 IP 111.206.98.20。拦这个域名等于同时拦掉 API + 图片 + H5 页面。

解决:立即删规则、重启 AGH、验证恢复解析。教训:看域名像广告就拦，很可能拦掉的是整个业务网关。拦之前先 dig +trace 看 CNAME 链，确认它是不是多业务共用。

4. 第一方广告拦不住：DNS 的物理天花板 局限

汽水音乐的开屏、B 站的开屏、波点的信息流，广告内容和正文走同一个域名。DNS 只能按域名整拦，拦了正文也没了。

另一个表现:预缓存广告。App 提前把开屏素材下好，之后即使域名被拦，开屏照样播 —— 需要删掉 App 重装清缓存才能验证规则是否生效。

要治这类广告只能上 MITM(见「mitmproxy 广告改写」)。

5. 双 DHCP 导致"有的设备没去广告" 真坑

现象:部分设备有去广告、部分没有，同一台设备时快时慢。

根因:光猫 DHCP 与 nas-dhcp 同时开着，客户端随机拿到网关 .1 或 .200。拿到 .1 的设备完全绕过旁路由。

判据:设备上查网关，192.168.4.1 = 没走旁路由。

解决:同一网段只能有一个 DHCP。二选一，不要双开。

6. 规则库里的"路径级"规则 AGH 执行不了 坑

不少规则库写的是 cm.bilibili.com/cm/api/xxx 这种带路径的形式，AGH 只认域名，这类规则会被静默忽略 —— 看着"已启用 50 万条"，实际生效的没那么多。

判断方法:拦截后 nslookup 看是否返回 ::，返回真实 IP 就是没生效。

这是最容易漏的一条：

• 走 DNS 的设备 → 由 AdGuard Home 拦（按域名）。
• 手动设了 HTTP 代理 的设备 → 不再做 DNS 查询，AGH 对它完全失效，改由 mitmproxy 的 block_hosts 拦。

所以每次往 AGH 加规则，都要同步进 docker/mitmproxy/rules.json 的 block_hosts，否则一旦设了代理，那台设备的广告会全部回来。

# 拉 AGH 当前规则
ssh root@192.168.4.200 "sed -n '/^user_rules:/,/^[a-z_]*:/p' /etc/AdGuardHome.yaml"
# 同步进 rules.json 的 block_hosts / allow_hosts（热加载，不用重启）

详见 → AGH · 注意事项 · mitmproxy · 概览

服务器

腾讯云 CVM 43.159.43.10 · Ubuntu 22.04 x86_64 · 内核 5.15（已内置 WireGuard）

隧道网段

10.0.0.0/24（服务端 10.0.0.1 / 手机 10.0.0.2）

监听端口

UDP 48210（随机生成，非默认 51820，降低被扫描概率）

模式

全隧道：手机 AllowedIPs = 0.0.0.0/0, ::/0，所有流量走服务器

DNS

客户端 8.8.8.8, 1.1.1.1（随隧道走，避免 DNS 泄漏）

认证

密钥对（非密码），服务端已开机自启 wg-quick@wg0

手机在外面连不上家里的 SOCKS 根因

现象：家里用 ssh -D 127.0.0.1:1080 出网好好的，手机在外面却用不了。

根因：动态转发的 SOCKS 只监听在"家里那台机器"的 localhost，外部到不了；且代理根本没跑在公网 IP 上。

解决：改为在服务器公网侧跑 WireGuard（本服务），手机直连服务器公网 IP。

iOS 国区 App Store 搜不到 WireGuard 限制

现象：国内 App Store 搜 WireGuard / Shadowrocket 都搜不到。

根因：2017 起苹果按工信部要求下架国区所有 VPN App，它们在美区 / 港区仍可用。

解决：切到美区 / 港区 Apple ID 下载（免费），装完可切回国区，App 保留。Android 直接下 APK 无此限制。

部署完手机仍连不上 —— 漏了腾讯云安全组 最常见

现象：服务端 wg show 正常、UFW 也放行了，但手机握手失败 / 超时。

根因：UFW 只是系统内防火墙；腾讯云还有一层网络安全组，默认入站是拒绝的，没在那里放行 UDP 端口，包根本进不来。

解决：云控制台 → 安全组 → 入站规则加 UDP:48210 允许。

scp 取回二维码报 Permission denied 已修

现象：scp ...:/tmp/phone-wg.png 报 Permission denied。

根因：搭建脚本以 root 生成 PNG，文件属主 root、权限 600，普通 ubuntu 用户读不到。

解决：sudo chmod 644 /tmp/phone-wg.png 后再取；或脚本里直接 cp 一份 644 到 /tmp。