简介：这是一款面向家长的 Windows 上网管控工具，针对儿童过度上网、访问不良网站等家庭场景，提供网址过滤、上网时段限制、密码锁屏、断网/关机及应用程序监控等功能，既适合家庭用户直接部署，也适合学习 C# 桌面应用开发的技术人员研究参考。资源包共 40 个文件，约 4.11MB，以 11 个 C# 源码文件为核心，附带可直接运行的 EXE 程序、DLL 库、ICO 图标与 RESX 界面资源，并包含项目解决方案、Manifest 清单及 xaddin 扩展配置，覆盖从界面设计到网址检测、锁屏控制和定时策略的完整模块。已有 457 人学习下载，代码结构清晰，主程序分为锁屏、主界面与配置管理等多个窗体，便于按功能点切入阅读。通过部署与源码研读，读者既能快速拥有一套可用的上网控制程序，也能理解家长控制类工具的核心实现逻辑、配置流程与常见排错思路，进而二次开发适配自身需求。
1. 上网家长控制软件：先搞清楚它拦的是流量还是终端
晚上十点半，你发现孩子还在刷游戏视频——手机上的管控 App 早就被删了，密码改了也能被猜出来。单纯装一个家长控制软件在终端上，本质上是在跟孩子争夺设备的控制权，而设备在孩子手里，这场仗你很难赢。真正可行的思路是把管控点从终端挪到网络链路上：不管孩子手里拿的是手机、平板还是电脑，只要他想上网，流量就必须经过你控制的那道闸门。这就是上网家长控制软件能做到的事。
这份资源是一套基于策略引擎和网关 DNS 过滤的家长控制实现，包含部署脚本、策略模板、日志分析工具和一份设备豁免清单模板。它解决的问题很聚焦：统一管理家庭网络里所有终端的上网行为，按人、按时间、按内容分类做放行或阻断。适合家里设备多、孩子有一定动手能力、单纯 App 限制已经失效的场景。接下来我会从控制点的选型逻辑讲起，逐步拆到配置文件和具体踩坑点。
2. 控制点选在哪：从网关侧做统一过滤的实现逻辑与选型对比
2.1 终端侧与网络侧：两种控制点的本质差别
终端侧控制，就是在孩子的手机或电脑上装 App，通过系统权限去拦截应用和网址。这种方式有一个绕不开的死穴：管控逻辑跑在被管控的设备上，权限之争永远存在。孩子可以卸载 App、关掉通知、断网重试，甚至恢复出厂设置。即便你用了设备管理器权限，也只是把对抗升级，而不是消除对抗。
网络侧控制则把决策点放到家庭网络的出口位置。终端发出的所有流量都要经过网关，网关在 DNS 解析阶段就能知道这台设备想访问哪个域名，再根据策略决定放行还是阻断。孩子可以改自己的设备设置，但改不了网关上的策略。两种方式的差异可以看这张对比表。
| 对比项 | 终端侧 App | DNS 过滤 | 透明网关过滤 |
|---|---|---|---|
| 部署位置 | 每台终端 | 路由器或旁路网关 | 链路中间 |
| 被卸载绕过的难度 | 低 | 中 | 高 |
| 覆盖设备范围 | 仅安装了 App 的设备 | 所有指向该 DNS 的设备 | 所有经过网关的设备 |
| 是否支持按设备细分策略 | 依赖于 App 实现 | 支持 | 支持 |
| 维护成本 | 每台设备单独配置 | 集中维护一份策略 | 集中维护，但需关注链路稳定性 |
这个资源选的是“旁路网关 + DNS 策略”的组合：控制网关并不强制所有流量穿越它，而是作为家庭网络的 DNS 服务器存在。这样做的好处是部署风险小，即使网关临时宕机，终端还能通过主路由自带 DNS 上网，不至于全家断网。代价是管控粒度停留在域名层，做不到内容层的关键词过滤。对家长场景来说，域名层控制已经覆盖了绝大多数需求——赌博、色情、游戏平台、短视频域名，这些本来就可以按域名分类处理。
2.2 策略引擎的判定逻辑：谁、什么时段、访问什么
一个可用的上网控制策略引擎，最终要回答三个问题：这台设备是谁的，当前时间在不在允许时段内，目标域名属于哪个分类。三个问题在一条判定链上顺序执行，优先级从高到低。我用一段简化伪代码说明核心流程：
def decide(device_mac, domain, now): # 第一步：豁免设备永远放行，比如家长的手机和电脑 if device_mac in trusted_devices: return PolicyAction.ALLOW # 第二步：找到这台设备绑定的策略 policy = binding_policy.get(device_mac) if not policy: return policy.default_action # 第三步：当前时间是否落在允许时段内 if not is_time_in_slots(now, policy.time_slots): return PolicyAction.BLOCK # 第四步：域名分类匹配 category = classify_domain(domain) if category in policy.block_categories: return PolicyAction.BLOCK if category in policy.allow_categories: return PolicyAction.ALLOW # 兜底：未命中任何分类时走策略的默认动作 return policy.default_action这段代码的顺序是刻意设计的：豁免判断在最前，因为家长设备不能被策略误伤；时段判断在分类之前，因为非学习时段所有娱乐域名直接拦掉，查询更快。classify_domain用的是后缀匹配树，*.game.com这类规则会统一归到游戏分类。这里的time_slots支持按星期区分，周一到周五和周末可以给不同时间段。
2.3 为什么默认不做 HTTPS 解密
很多人问，域名过滤遇到 HTTPS 会不会失效。答案是如果只做 DNS 层的解析阻断，HTTPS 流量根本到不了连接阶段就被拦了，因为终端解析不到正确 IP。只有当孩子使用加密 DNS 或直连 IP 时，DNS 过滤才会失效，这时需要配合 SNI 层审计来兜底。
这个资源包默认不做 HTTPS 中间人解密，原因很实际：启用解密需要在每台设备上安装根证书，孩子可以拒绝安装，家长要伺候多台设备的证书更新，运维成本高且容易翻车。域名层控制能覆盖 90% 以上场景，剩余部分交给 SNI 审计和 IP 段策略处理。这也是我认为家长控制产品一个比较理性的取舍。
3. 部署一套可用的控制网关：环境、拓扑与最小验证路径
3.1 网络拓扑：先想清楚你的网关机放哪
部署前不要急着敲命令，先确认网络拓扑。最稳的方式是旁路模式：网关机与主路由处于同一局域网，主路由的 DHCP 把 DNS 字段指向网关机的 IP。终端上网流程不变，只是每次域名解析都问一下网关机。
如果你想要更强的管控效果，可以把网关机串在主路由和交换机之间，做成透明网关。这种模式下所有流量都会经过这台机器，能在网络层拦截直连 IP 的流量，但部署复杂度明显提升——需要配置桥接或路由转发规则，一旦网关机宕机全家都会断网。我第一次做这种项目时就在这上面翻过车，所以我的建议是：先用旁路模式验证策略是否合理，确认没问题再考虑要不要升级成强制模式。
| 部署模式 | 设备改动 | 管控强度 | 网络故障风险 |
|---|---|---|---|
| 旁路 DNS | 只需改 DHCP 的 DNS 字段 | 域名级 | 低 |
| 透明网关 | 串接链路 | 域名 + 连接级 | 高 |
| 强制网关（网关故障自动放行） | 串接链路 + 脚本守护 | 域名 + 连接级 | 中 |
3.2 部署步骤：目录结构与启动脚本
资源包解压后，目录结构大概长这样：
/opt/netguard/ ├── conf/ │ ├── policy.yaml # 主策略文件 │ └── categories.yaml # 域名分类表 ├── netguard-core/ │ └── main.py # 策略服务入口 ├── netguard-dns/ │ └── dns_server.py # DNS 过滤服务 ├── scripts/ │ ├── deploy.sh # 初始化部署脚本 │ └── reload.sh # 重新加载策略 └── logs/ └── access.log # 访问日志部署脚本的核心内容大致如下：
#!/bin/bash set -euo pipefail BASE_DIR=/opt/netguard cd "$BASE_DIR" echo "==> 1/4 安装系统依赖" apt-get update apt-get install -y python3 python3-pip dnsutils curl echo "==> 2/4 安装 Python 依赖" pip3 install -r app/requirements.txt echo "==> 3/4 校验策略文件语法" python3 netguard-core/main.py --config conf/policy.yaml --check echo "==> 4/4 启动 DNS 服务与策略服务" nohup python3 netguard-dns/dns_server.py --config conf/policy.yaml \ --port 53 --log logs/access.log > logs/dns.log 2>&1 & nohup python3 netguard-core/main.py --config conf/policy.yaml \ > logs/core.log 2>&1 & echo "部署完成，DNS 服务监听端口 53"--check参数会在启动前校验 YAML 格式和策略优先级配置；--port 53指定 DNS 服务监听端口，默认 53 不用动；日志文件分流到dns.log和core.log，排查问题时能分清是策略引擎异常还是 DNS 响应异常。
3.3 最小验证路径：先不接全家的流量
部署完不要急着把主路由的 DHCP 改掉。先拿一台测试设备走最小验证路径：手动把这台设备的 DNS 改成网关机 IP，然后在设备上访问一个被分类为游戏的域名。
# 在测试设备上用命令行或图形界面把 DNS 改为： # 网关机内网 IP，例如 192.168.1.100 # 验证解析是否被阻断 nslookup game-example.com 192.168.1.100 # 预期输出：Can't find game-example.com: No answer # 验证正常网站是否可访问 curl -I https://www.example.edu.cn # 预期输出：HTTP/2 200这一步走通，说明 DNS 过滤链路是通的。然后再去改主路由 DHCP，让所有设备走网关 DNS。最小验证路径最大的价值是：出问题时影响范围只限一台设备，不会让全家网络陷入未知状态。我每次调试策略变更都会先这样隔离验证，避免规则写错导致家里所有设备上不了网。
4. 把策略文件写成可维护的规则集：分类、时段与设备绑定
4.1 策略文件的三个层级：策略、分类、设备
策略文件不建议只写一个黑名单列表，那样跟运维 hosts 文件没有区别。可维护的策略文件应该分成三层：顶层是策略（policy），中间是分类（category），底层是设备绑定（binding）。策略决定允许什么、阻断什么，分类决定哪些域名属于同一个业务类型，设备绑定决定哪些设备应用哪份策略。
这样做的好处很直接：孩子长大一点，你只需要新建一个宽松一点的策略，再把设备绑定改一行；某个游戏平台换了域名，你只要把它加进game分类，所有引用这个分类的策略会同时生效。
4.2 分类表：域名后缀匹配与优先级规则
categories.yaml是域名分类表，资源包里的示例结构如下：
version: "1" categories: game: display_name: "游戏" domains: - "game-example.com" - "*.game-center.com" ip_ranges: - "203.0.113.0/24" video_stream: display_name: "短视频与直播" domains: - "video-example.com" - "*.short-video.com" gambling: display_name: "赌博" domains: - "gambling-example.com" ip_ranges: - "198.51.100.0/24"域名匹配采用后缀最长匹配原则，*.game-center.com会匹配该域名下的所有子域名；ip_ranges用于处理那些不经过域名解析、直接通过 IP 访问的流量。分类名建议用英文小写加下划线，避免中文做键名在日志统计时出现编码问题。匹配优先级上，精确域名优于通配符，通配符优于 IP 段。
4.3 时间槽与设备绑定：把策略挂到具体设备
policy.yaml是主策略文件，它负责把策略、分类和具体设备串起来。我常用的写法是这样的：
version: "1" policies: strict_child: description: "学龄期工作日严格模式" default_action: block time_slots: - days: [1,2,3,4,5] start: "08:00" end: "22:00" allow_categories: [education, reading] block_categories: [game, video_stream, social, gambling] - days: [6,7] start: "09:00" end: "22:00" allow_categories: [education, reading] block_categories: [gambling] observe_categories: [social] relaxed_teen: description: "初高中生周末宽松模式" default_action: allow time_slots: - days: [6,7] start: "10:00" end: "23:00" block_categories: [gambling] device_bindings: "AA:BB:CC:DD:EE:FF": policy: strict_child description: "孩子卧室平板" "11:22:33:44:55:66": policy: relaxed_teen description: "孩子作业电脑"default_action: block是兜底动作：未命中任何分类的域名默认阻断，适合低龄孩子的设备；default_action: allow则相反，适合只需要屏蔽特定类型域名的场景。observe_categories是一个很实用的参数，列入该分类的域名不会真正阻断，但会被记录到日志，用于观察新规则是否误伤。
设备绑定支持用 MAC 地址精确匹配，也可以改成 IP 段匹配，后者适合 DHCP 分配不固定的网络。需要注意的是，MAC 绑定在设备开启随机 MAC 功能时会失效，这一点后面避坑章节会详细说。
加载策略使用reload.sh：
#!/bin/bash python3 netguard-core/main.py --config conf/policy.yaml --reload--reload不会重启进程，而是向运行中的策略服务发送 SIGHUP 信号，让它重新读取配置文件并重建匹配树。配置文件修改后，这个操作可以在秒级生效，不会中断正在进行的网络请求。改完配置后我一般会立刻查一下日志，确认没有因为语法错误导致策略服务进入异常状态。
5. 避坑：接入家庭网络后最容易翻车的五个环节
5.1 现象：域名在阻断列表里，HTTPS 网站还是能打开
原因：DNS 解析被拦截后，终端可能回退到系统内置的加密 DNS，或 App 内部使用自定义 DNS 解析，绕过了网关的 DNS 服务。DNS 过滤只能拦解析阶段，拦不住直连 IP。
解决：在网关机上启用 SNI 审计模块，从握手阶段读取目标域名。只要域名命中阻断分类，直接重置 TCP 连接。具体做法在netguard-dns的配置里加一行enable_sni_filter: true。同时把ip_ranges里的游戏或赌博服务器网段也加入阻断，作为第二道防线。
5.2 现象：孩子把设备 DNS 改成外部 DNS，管控立即失效
原因：策略服务只监听局域网内的 DNS 请求，一旦终端不再向网关发 DNS 查询，域名过滤就无从谈起。
解决：在主路由上配置 DNS 强制转发，把流向任何外部 IP 的 UDP 53 端口数据都重定向到网关机，并屏蔽常见公共 DNS 的 IP 地址。同时建议在策略文件里把block_encrypted_dns设为true，阻断境内常见的加密 DNS 服务。这样孩子手动改 DNS 的结果是域名解析超时，而不是换一个解析通道继续上网。
5.3 现象：家长自己也被策略挡住，网课平台被误杀
原因：策略文件里没有维护家长设备的豁免名单。很多家长在配置时只关注“阻断什么”，忽略了“放行谁”。
解决：在policy.yaml里单独维护一个白名单设备组：
trusted_devices: - mac: "AA:BB:CC:DD:EE:01" description: "家长手机" - mac: "AA:BB:CC:DD:EE:02" description: "家长电脑"判定顺序是trusted_devices优先于任何策略。另外很多网课平台用了通用的 CDN 域名，可能被归入video_stream分类。这种误杀很难提前预判，我建议对网课类域名单独建一个education分类，并在严格策略的allow_categories中显式引用。新接入的网课平台未收录时，改分类比临时加 IP 白名单要可靠得多。
5.4 现象：策略文件改了，重新加载后不生效
原因：策略服务进程没有收到重载信号，或者配置文件里的缩进格式错了，被语法检查跳过。YAML 对缩进极其敏感，block_categories下的两个空格和四个空格可能造成完全不同的解析结果。
解决：先校验再重载：
python3 netguard-core/main.py --config conf/policy.yaml --check python3 netguard-core/main.py --config conf/policy.yaml --reload--check如果没有任何输出，说明 YAML 语法和策略结构没问题。修改配置后养成习惯，把旧的策略文件备份一份，防止改乱了想回退却没有后悔药。
5.5 现象：网关机宕机或重启，全家设备无法解析域名
原因：终端把 DNS 指向网关机之后，网关机一旦不可用，所有依赖它的设备都会出现域名解析超时。轻则是网页打不开，重则是所有 App 请求全部卡住。
解决：在部署时加一个 watchdog 脚本，定时探测策略服务进程：
#!/bin/bash while true; do if ! pgrep -f "netguard-dns" > /dev/null; then echo "DNS 进程异常，临时恢复直连上游 DNS" echo "nameserver 223.5.5.5" > /tmp/resolv.conf.netguard # 通知主路由把 DHCP 的 DNS 改回默认值 /opt/netguard/scripts/critical_disable.sh fi sleep 30 done这个脚本做的事情是：探测到 DNS 进程退出后，自动执行一次全局放行，让终端回退到主路由默认 DNS。风险是短暂失去管控，但换来的是家庭网络整体可用。如果做透明网关模式，建议在网关上再加一条硬件看门狗或常态化的健康检查接口，避免人在外面无法远程处理时全家断网。
6. 验证规则是否真的生效：日志、灰度放行与自测清单
6.1 日志字段与 Top 10 命中分析
策略服务运行后，logs/access.log会按行记录每一次域名判定的结果。日志格式固定为：
timestamp | device_mac | domain_name | category | action | policy_name 2024-11-20 21:14:33 | AA:BB:CC:DD:EE:FF | game-example.com | game | block | strict_child 2024-11-20 21:15:02 | AA:BB:CC:DD:EE:FF | edu.example.com | education | allow | strict_child用一段简单的 Python 脚本就能统计出最常触达的阻断域名：
from collections import Counter block_counter = Counter() with open("logs/access.log", "r", encoding="utf-8") as f: for line in f: parts = line.strip().split(" | ") if len(parts) == 6 and parts[4] == "block": block_counter[parts[2]] += 1 for domain, count in block_counter.most_common(10): print(f"{count:5d} {domain}")统计结果的用处是反推分类表是否合理：如果某个域名频繁命中block，说明孩子确实常访问，分类配置生效；如果某个域名从来没出现在日志里，可能是设备已经绕过了网关 DNS，或者是该域名根本没被访问过。日志分析之后，顺手把高频命中的域名加进对应分类的domains列表，能有效减少后续匹配的开销。
6.2 灰度放行三步法
新策略不要直接推给全家人。我现在习惯每次改规则都走一套三步流程：
| 阶段 | 操作 | 持续时间 |
|---|---|---|
| 观察 | 把新分类加入observe_categories，只记日志不阻断 | 24 小时 |
| 小范围阻断 | 只在一台测试设备上启用阻断策略 | 2 小时 |
| 全量放行 | 确认无异常后，把策略同步到所有设备组 | 长期 |
observe_categories的价值在于它给你一份“如果真正阻断会误伤谁”的预判清单。之前某次把网课平台域名误归入video_stream，如果直接全量阻断，孩子晚上就没法上课了。观察阶段日志里的 allow 命中非常明显的暴露出这个分类归属错误，让我有机会在真正影响使用前修正。
6.3 自测清单：把自己当成孩子去试绕过手段
验证规则是否真的生效，最有效的方法是假设自己是一个想绕过管控的孩子。我每次改完配置都会过一遍这个清单：
先试改设备 DNS 到外部地址，再试直接访问被阻断域名的 IP，然后试卸载重装管控相关 App，最后试连接手机热点。前两项是网关层管控是否生效的直接检验；后两项属于终端侧行为，网关管控本身无法解决，但日志里能看到设备访问记录，方便后续约法三章。
从那以后，我每次调整策略文件都会强制走一遍同样的流程：先最小验证，再灰度观察，最后全量推送，再把自测清单完整跑一遍。这个习惯帮我挡掉过不少隐蔽的翻车事故，毕竟配置文件的语法可以通过检查，但分类归属和流量行为只有真实请求才能暴露。希望这份拆解能帮你在第一次部署时少走一点弯路，把管控做到既有效又不至于随时准备拔网线。
本文还有配套的精品资源，点击获取
