VPN 会破坏家庭设备上的家长控制吗？
有些规则落在路由上，有些落在账户上。先做基线测量，再加上隧道，然后比较每个过滤器实际在哪里起作用。
家长控制不是单一产品。一条规则可能落在路由器上、DNS 服务里、操作系统账户里、某个浏览器里，或每个应用里。VPN 改变的是网络路径能看到什么，它不会改变账户层面的时间限制。在加上隧道前后跑同一套检查，分界就会变得可见，而不必争论。
写下哪条规则落在哪里
先做清单：设备、账户、浏览器和应用，然后是执行每项要求的机制。时间限制通常落在平台账户上。安装和购买限制也在那里。内容过滤是最含糊的一项，因为它可能是路由器规则、DNS 应答、浏览器策略或应用级功能。一旦流量被封装，这些机制的表现各不相同。
| Mechanism | Where it operates | What a tunnel changes |
|---|---|---|
| Router or DNS filter | The network path or the resolver | Hides destinations and queries inside the tunnel |
| OS account limits | The device and the signed-in account | Nothing about the internet exit |
| Browser policy | A specific browser under a managed account | Depends on whether that browser uses the tunnel |
| App-level restriction | The application itself | Usually independent of routing |
改动之前的清单，是区分退步和从来没工作过的唯一办法。
安装任何东西之前先做基线测量
记录哪个解析器在应答、普通目的地走哪条路径、已知被封锁的页面是否真的被封锁。之后按同样顺序、在同一台设备上重复这三项观察。
resolvectl status | head -20
ip route get 203.0.113.10
dig +short example.com解析器的输出显示出设备用的是路由器的 DNS，还是设备上配置的私人解析器。这一个细节就能解释大多数意外，因为使用自带加密解析器的设备根本不会去问家庭过滤器。把家庭真正的要求用平实的话写在每条结果旁边。“九点以后不许上社交媒体”和“这台路由器封锁一份域名清单”是两项不同的要求，负责人也不同，而隧道只影响其中一项。
在隧道开启的状态下重跑同一套检查
隧道连上之后，重跑解析器和路径检查。如果解析器换成了私人解析器，即使设备还在家庭网络里，路由器的过滤也已经不在路径上了。
resolvectl status | head -20
ip route get 203.0.113.10
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com现在走隧道的路径解释了路由器过滤为何失效，但这并不意味着账户限制停止工作。账户限制要单独查：去平台自己的设置里读，而不是从被封锁的页面倒推。浏览器结果同样需要这份小心。只对某个浏览器里已登录的儿童账户生效的过滤器，说明不了另一个浏览器，也说明不了在它之外打开的桌面应用。
解决冲突，而不是把东西关掉
两个都想占有设备网络扩展的产品可能会冲突，常见症状是其中一个拒绝连接。为了让隧道工作而卸掉防护，是错误的方向。读两家的兼容性说明，选一种能保住要求的安排。有时这意味着把过滤器移到另一层，比如受管理的设备描述文件，而不是让两个应用抢同一个钩子。
如果有正当的学校或工作资源被封锁，给家庭管理员一条有记录的审批路径。带理由和复核日期的例外可以维持；一堆临时改网络的做法不行。
把记录做小并保持更新
一页就够：设备、账户、哪条规则由哪个机制执行，以及上次检查的日期。大的应用更新之后要重跑检查，因为网络扩展和浏览器策略会在版本之间挪位置。
这份记录是写给半年后来排查的人看的，那个人可能就是忘光了一切细节的你。写机制而不是产品，改名之后笔记仍然说得通。