简介面向家长和教育工作者定制的上网管理工具用于过滤不良网站、限制上网时段、监控应用使用并支持锁屏、断网等强制管控帮助家庭落实儿童网络保护。资源为完整的Visual Studio解决方案压缩包共40个文件、约4.11MB包含C#源码、窗体设计文件与界面资源resx/ico/bmp、配置文件及可执行程序既可直接编译运行也能作为桌面端应用的教学示例。压缩包内还含有主窗体、锁定界面、操作逻辑等多个功能模块目录结构清晰便于按文件查找对应逻辑。已有457人学习/下载适合具备C#基础的开发者或需要快速获得现成家长控制工具的普通用户。从中可了解该类软件的模块划分、界面资源组织方式与关键控制逻辑可在此基础上扩展二次开发或调整部署。1. 上网家长控制软件从装好到真正拦得住需要跨过哪些坑一个常见场景平板电脑交给孩子上网课家长转身去忙十分钟后回来浏览器停在游戏视频页夜里起来看孩子房间还亮着被窝里刷短视频。路由器限速、口头约定都失效之后大多数人开始搜家长控制软件。市面上商业方案按月收费数据还要传到对方的服务器很多家长不放心。这份资源解决的是这件事基于 DNS 拦截 时间段策略 上网行为审计自建一套能按设备、按域名、按时段强制执行的上网家长控制软件。适合有一定动手能力、想把控制权捏在自己手里的家庭用户或网管不需要额外硬件现有电脑和路由器就能跑起来。2. 拦截方案选型与整体架构先弄懂三种实现路径再决定怎么落地2.1 为什么选 DNS 拦截而不是改 hosts 或装透明代理上网控制的本质是在“设备发起网络请求”到“服务端响应”之间插一道闸门。常见的做法有三种。第一种是改 hosts 文件把特定域名静态指向 127.0.0.1 或空地址。优点是零依赖、纯本地但它是静态的域名列表一更新就要手动维护且只对当前设备生效。多台设备都要管控时逐台维护 hosts 的运维成本会迅速膨胀孩子换一台设备规则就失效了。第二种是透明代理在网关或路由器上部署代理服务所有 HTTP/HTTPS 流量强制经过代理做内容过滤。它粒度最细可以精确到 URL 路径但 HTTPS 解密需要给每台设备安装并信任自签证书一旦证书没装好所有网页都会报错。很多家庭部署失败都栽在证书信任这一步。第三种是 DNS 拦截把设备的 DNS 请求全部引到本地或局域网内的 DNS 服务由这个服务根据规则决定“放行”还是“拦截”。它的核心优势在于无论 HTTP 还是 HTTPS客户端在发起连接之前必然先做一次域名解析。DNS 层拦住了后续连接根本建立不起来。整台设备的流量全部覆盖不用装证书不用改 hosts配置一次全局生效。我一般会推荐第三种作为主方案原因很朴素——DNS 拦截面对的是“域名”这个唯一真实的主机标识而家庭上网控制恰恰是域名级管控就足够的场景。孩子访问的是具体网站不是裸 IP 连接域名拦住了行为就拦住了。这套资源也是按照这个思路设计的。2.2 五层架构控制台、策略服务、执行引擎、数据层、被控端这套架构分五层各层职责清晰出现故障时排查路径也很直接。第一层是 Web 控制台跑在家长那台电脑或手机浏览器上负责编辑策略、查看日志、管理设备。要做的是一个轻量 Web 应用不需要独立部署跑在本机某个端口上即可。第二层是策略服务这是核心进程常驻在被控设备孩子那台电脑或平板上负责监听控制台下发的策略变更并把策略翻译成底层规则。第三层是执行引擎也就是那一层 DNS 服务。这里用 dnsmasq 做本地 DNS 转发器它根据策略服务写出的规则文件决定对某个域名返回正常解析结果还是拦截响应。第四层是数据层用 SQLite 存三类数据设备注册信息、策略规则快照、上网行为日志。SQLite 零配置、单文件断电不丢数据对家庭场景足够。第五层是被控端适配层解决的是跨平台问题。Windows 上策略服务注册成系统服务macOS 上用 launchdLinux 上用 systemd。DNS 配置则通过 DHCP 下发或者在每台设备上手动指定 DNS 为策略服务所在的主机。这个分层有一个实际好处任何一层出问题日志都能定位到具体模块而不是整片黑匣子。比如规则不生效先看策略服务有没有把规则写进 dnsmasq 的配置文件再看 dnsmasq 有没有成功重载层层排查比商业软件的“重启试试”要可操作得多。2.3 数据表设计设备、规则、日志三张表怎么建模数据层三张表的字段设计直接影响后续策略下发和日志查询的效率。设备表记录每台被控设备的唯一标识。核心字段有 device_id设备的唯一 ID、mac物理地址用于 DHCP 静态绑定、token控制台与该设备通信的身份凭证以及 policy_version该设备当前已生效的策略版本号。策略版本号是热更新的关键控制台改了策略版本号递增设备轮询发现自己版本落后就主动拉取新策略。规则表按“类别 域名”建模。字段包括 rule_id、category分类如娱乐、游戏、社交、购物、教育、domain_pattern域名模式支持精确域名、后缀域名和正则表达式、action放行还是拦截、priority优先级数值越小权重越高。优先级字段特别重要因为家长很可能既要拦截某类域名又要放行其中的个别域名。比如拦截所有短视频类域名但放行某个学习平台上内嵌的视频接口域名。优先级机制让这类“大黑名单 小白名单”的组合成为可能。日志表记录每次拦截行为。字段包括 id、device_id、domain、action、matched_rule_id、timestamp。不需要把放行的请求也全部记录那会产生噪音数据。只记拦截和被放行的特殊域名日志保留最近 30 天即可定时清理旧数据防止 SQLite 文件膨胀。3. 搭建 Web 控制台用 Flask 实现设备管理、策略下发与日志查询3.1 控制台初始化安装依赖与数据库建表Web 控制台是整个管控系统的操作入口本资源里它基于 Python 的 Flask 框架实现。你需要 Python 3.8 及以上版本依赖只有三个flask、flask-cors、sqlite3Python 自带无需额外安装。pip install flask flask-cors依赖安装完成后先初始化数据库。这一段代码会把三张表和默认策略写入 SQLite 文件。# init_db.py import sqlite3 import json DB_PATH parent_control.db def init_db(): conn sqlite3.connect(DB_PATH) cursor conn.cursor() cursor.execute( CREATE TABLE IF NOT EXISTS devices ( device_id TEXT PRIMARY KEY, mac TEXT UNIQUE, token TEXT, policy_version INTEGER DEFAULT 0, last_seen TEXT ) ) cursor.execute( CREATE TABLE IF NOT EXISTS rules ( rule_id INTEGER PRIMARY KEY AUTOINCREMENT, category TEXT, domain_pattern TEXT, action TEXT, priority INTEGER DEFAULT 100 ) ) cursor.execute( CREATE TABLE IF NOT EXISTS block_log ( id INTEGER PRIMARY KEY AUTOINCREMENT, device_id TEXT, domain TEXT, action TEXT, matched_rule_id INTEGER, timestamp TEXT ) ) # 写入默认策略拦截赌博与色情类优先级 1 default_rules [ (gambling, *.bet*.com, block, 1), (adult, *.porn*.com, block, 1), (adult, *.xxx*.com, block, 1), ] cursor.executemany( INSERT INTO rules (category, domain_pattern, action, priority) VALUES (?, ?, ?, ?), default_rules, ) conn.commit() conn.close() print(数据库初始化完成表结构和默认策略已写入) if __name__ __main__: init_db()这段代码做了三件事建三张表、写入三条默认拦截规则、提交事务。priority1 表示这些规则优先级最高即使后续有白名单规则也不会覆盖它们——除非家长显式修改。要注意的是默认策略只覆盖两类典型风险域名实际使用时要按孩子年龄段往 categories 里补充规则。3.2 策略下发接口设备端如何拿到最新规则设备端并不直接读数据库而是通过 HTTP 接口拉取规则。这样做的好处是设备不持有数据库权限只拿到最终生效的规则快照安全性和解耦性都好。# strategy_api.py from flask import Flask, jsonify, request import sqlite3 import hashlib app Flask(__name__) DB_PATH parent_control.db def generate_token(device_id): raw device_id a_salted_string_for_token return hashlib.sha256(raw.encode()).hexdigest() app.route(/api/device/register, methods[POST]) def register_device(): data request.get_json() device_id data.get(device_id) mac data.get(mac) if not device_id or not mac: return jsonify({code: 1, msg: 缺少 device_id 或 mac}), 400 token generate_token(device_id) conn sqlite3.connect(DB_PATH) conn.execute( INSERT INTO devices (device_id, mac, token, last_seen) VALUES (?, ?, ?, datetime(now)) ON CONFLICT(device_id) DO UPDATE SET macexcluded.mac, last_seendatetime(now), (device_id, mac, token), ) conn.commit() conn.close() return jsonify({code: 0, token: token, device_id: device_id}) app.route(/api/device/policy, methods[GET]) def get_policy(): device_id request.args.get(device_id) token request.args.get(token) conn sqlite3.connect(DB_PATH) row conn.execute(SELECT token FROM devices WHERE device_id ?, (device_id,)).fetchone() if not row or row[0] ! token: conn.close() return jsonify({code: 403, msg: token 校验失败}), 403 rules conn.execute( SELECT domain_pattern, action, priority FROM rules ORDER BY priority ASC ).fetchall() version conn.execute( SELECT policy_version FROM devices WHERE device_id ?, (device_id,) ).fetchone()[0] conn.close() return jsonify({ code: 0, policy_version: version, rules: [{domain: r[0], action: r[1], priority: r[2]} for r in rules] }) if __name__ __main__: app.run(host0.0.0.0, port5000, debugFalse)register_device 接口负责设备首次接入。token 由 device_id 加固定盐值做 SHA256 生成不存明文密码。设备拿到 token 后要保存到本地配置文件中后续请求带上 token 即可。get_policy 接口返回该设备当前策略快照。校验顺序是设备存在、token 匹配然后返回规则列表和策略版本号。设备端每 60 秒轮询一次配合下一步要讲的热更新机制策略变更能在两分钟内生效。3.3 时间策略时段限制、累计时长与两种模式的冲突处理上网控制不能只做域名拦截时间维度才是家长最在意的。这套资源提供两个一体化的时间策略时段模式和配额模式。时段模式表达“这台设备允许上网的时间窗口”比如周一至周五 18:00-21:00 允许娱乐类域名访问其余时段娱乐类全部拦截。配额模式表达“每天累计娱乐时长不超过 X 分钟”比如全天所有娱乐类域名累计 90 分钟。配额模式与时段模式可以在自定义规则里同时存在。我看到不少初做家长控制的人把这两个机制做成了简单的开关导致冲突时段模式说“19:00 之前允许娱乐”配额模式说“娱乐累计只有 60 分钟”——到底听谁的这台设备 18:00 开始刷短视频19:30 被断掉孩子说“你说了 19:00 前可以用”家长说“只能 60 分钟”矛盾就此产生。我这里采用的判定流程是先看域名分类再按时段决定放行或拦截最后扣减配额。如果一个时段既有放行也有拦截时段拦截优先如果将放行的域名计入配额配额耗尽后强制拦截。关键是在控制台界面给家长一个明确的提示配额模式下时段模式设置的“允许”只是前置条件最终以配额为准。代码中判定逻辑如下。# time_policy.py import datetime # 全局配额状态表device_id - {date: 2025-01-01, used_seconds: 120} quota_state {} def is_in_allowance_slot(device_id, dt: datetime.datetime): weekday dt.weekday() # 0周一, 6周日 hour dt.hour dt.minute / 60 # 规则示例周一至周五 18:00-21:00 允许娱乐周末 10:00-22:00 允许娱乐 slots { mon_fri: (18.0, 21.0), weekend: (10.0, 22.0), } if weekday 5: start, end slots[mon_fri] else: start, end slots[weekend] return start hour end def check_quota(device_id, domain_category, add_seconds1): today datetime.date.today().isoformat() entry quota_state.get(device_id) if not entry or entry[date] ! today: quota_state[device_id] {date: today, used_seconds: 0} if domain_category in (entertainment, game, video): if quota_state[device_id][used_seconds] 90 * 60: return False, quota_exceeded quota_state[device_id][used_seconds] add_seconds return True, ok def final_action(device_id, domain_category, dt: datetime.datetime): if not is_in_allowance_slot(device_id, dt): return block, time_slot_blocked allow, reason check_quota(device_id, domain_category) if not allow: return block, reason return allow, okfinal_action 的返回值最终会被策略服务合并到 dnsmasq 规则中。注意配额扣减粒度是每次 DNS 查询这会有误差因为一个视频页面会发起几十次域名查询。更合理的做法是策略服务每 5 分钟按设备当前活跃连接数预估时长脚本里保留的是基础粒度。4. 核心拦截引擎从域名匹配到行为日志的完整链路4.1 域名匹配算法精确、后缀、正则三级优先级如何排序拦截引擎收到的每一个 DNS 请求都会先过匹配器。匹配器按“精确域名 → 后缀域名 → 正则表达式”三级顺序执行命中的第一条规则就是最终规则。# rule_engine.py import re from urllib.parse import urlparse class DomainMatcher: def __init__(self): self.exact_rules {} # example.com - action self.suffix_rules [] # [(example.com, block), ...] self.regex_rules [] # [(re.compile(...), block), ...] def add_rule(self, pattern, action): # 统一去掉协议头并小写 clean pattern.strip().lower().replace(http://, ).replace(https://, ) if *. in clean or clean.startswith(*): # 后缀规则例如 *.tiktok.com - 记录 tiktok.com suffix clean.replace(*., ).lstrip(*.) self.suffix_rules.append((suffix, action)) elif * in clean: # 含通配符但不以 *. 开头按正则处理把通配符转成 [a-z0-9.-]* regex_str ^ clean.replace(., \\.).replace(*, [a-z0-9-]*) $ self.regex_rules.append((re.compile(regex_str), action)) else: self.exact_rules[clean] action # 注意这里只做了去重和类型分类排序在 build 阶段完成 def match(self, domain): domain domain.lower().strip().rstrip(.) # 第一级精确匹配 if domain in self.exact_rules: return self.exact_rules[domain] # 第二级后缀匹配 —— 父域名依次向上一级 parts domain.split(.) for i in range(0, len(parts) - 1): parent ..join(parts[i:]) for suffix, action in self.suffix_rules: if parent suffix or domain.endswith(. suffix): return action # 第三级正则匹配 for regex, action in self.regex_rules: if regex.match(domain): return action return allow def build(self): # 每次都重建正则匹配器用于规则热更新 self.suffix_rules.sort(keylambda x: len(x[0]), reverseTrue)匹配器在真实环境里最容易踩的坑是精确域名存在但子域名是独立解析的。比如精确规则是 “example.com”结果访问的是 “video.example.com”精确匹配漏掉后缀匹配如果没配置也会漏掉。所以我一般建议凡是精确拦截某个主域名同时自动生成一条后缀规则意思是“这个域名及其所有子域名”。避免家长以为拦住了主域名就等于全封了结果孩子从子域名绕进去。4.2 内置类别库与自定义规则合并权重设计与误判修正控制台界面上的规则来源有两个系统内置类别库和用户自建规则。内置类别库按域名用途做粗分类比如娱乐、游戏、社交、购物、教育。用户则根据自己的家庭情况在某个类别下追加或删除具体的域名。两类规则合并时采用“用户规则永远高于系统规则”的策略。这个细节很容易被忽略如果系统库把某个域名判为“游戏”但家长手动把它加入“教育”白名单那这条白名单的优先级必须在合并结果中更高。# rule_merger.py import sqlite3 def merge_rules(system_category_file, user_rule_file, output_file): system_rules load_system_categories(system_category_file) user_rules load_user_rules(user_rule_file) merged {} # 先放系统规则用户规则后写覆盖 for pattern, action, priority in system_rules: merged[pattern] {action: action, priority: priority, source: system} for pattern, action, priority in user_rules: merged[pattern] {action: action, priority: priority, source: user} # 输出 dnsmasq 可读的格式 with open(output_file, w, encodingutf-8) as f: for pattern, meta in merged.items(): ip 0.0.0.0 if meta[action] block else f.write(faddress/{pattern}/{ip}\n) return len(merged)整个合并过程写到一个临时文件再由策略服务通知 dnsmasq reload。这里我踩过一次坑直接修改 dnsmasq.conf 再重载如果不小心写入了非法格式dnsmasq 会启动失败所有设备的网络瞬间中断。后来改成先写入临时文件再执行dnsmasq --test验证格式通过后再加载正式配置多一道校验至少能避免整网断连的翻车事故。4.3 拦截动作与 DNS 响应构造返回空 IP、NXDOMAIN 还是自定义落地页拦截动作不只是“返回一个空值”这么简单。DNS 拦截有不小于三种响应方式各有适用场景。第一返回 0.0.0.0。客户端拿到这个 IP 后连接必然超时或失败。这种写法最直接但孩子会看到“无法访问此网站”浏览器报错信息比较笼统。第二返回 NXDOMAIN模拟“域名不存在”。优点是搜索 App 或浏览器会认为域名真的不存在减少反复重试。缺点是没法区分“家长控制了”和“网站挂了”。第三返回一个本地落地页服务器的 IP。也就是拦截后引导用户到一个提示页面上面写清楚“该网站已被家长控制策略拦截将在 X 分钟后自动打开可访问页面”。考虑到只是拦截提示不是正经 Web 服务落地页只需要一个静态 Nginx 或 Python http.server。# block_handler.py from flask import Flask, render_template_string app Flask(__name__) LANDING_PAGE !DOCTYPE html html headmeta charsetutf-8title访问受限/title/head body h2当前域名已被家长控制策略拦截/h2 p如果你认为这是误判请联系设备管理员核实。/p /body /html app.route(/) def block_page(): return render_template_string(LANDING_PAGE), 403 if __name__ __main__: # 在所有网卡上监听 8080 端口 app.run(host0.0.0.0, port8080)落地页的价值不只是提示还能减少一个常见的家庭矛盾孩子以为设备坏了家长以为策略失效了。看到落地页双方都明白发生了什么。我一般默认使用 NXDOMAIN 落地页结合的方式DNS 返回 NXDOMAIN 让请求迅速失败同时在日志里贴出落地页 URL家长打开浏览器访问落地页地址即可看到当天的拦截摘要。4.4 行为日志写入与审计记录哪些字段、保留多久、如何避免日志膨胀日志是家长控制里最容易忽略、后期价值最高的一块。它记录的不只是“拦截了什么”更是“想访问什么”。# audit_logger.py import sqlite3 import datetime def write_log(device_id, domain, action, matched_rule_id): conn sqlite3.connect(parent_control.db) conn.execute( INSERT INTO block_log (device_id, domain, action, matched_rule_id, timestamp) VALUES (?, ?, ?, ?, ?), (device_id, domain, action, matched_rule_id, datetime.datetime.now().isoformat()), ) conn.commit() conn.close() def cleanup_old_logs(days30): conn sqlite3.connect(parent_control.db) cutoff (datetime.datetime.now() - datetime.timedelta(daysdays)).isoformat() conn.execute(DELETE FROM block_log WHERE timestamp ?, (cutoff,)) conn.commit() conn.close()日志表里只记录“拦截”事件和“命中特殊白名单”事件。正常放行的请求不写日志——否则一个视频页面能产生几十条查询记录日志表很快就会膨胀到几万行。cleanup_old_logs 放在系统每天凌晨定时任务里跑一次保留 30 天足够回溯孩子一个月的上网轨迹也不会把 SQLite 文件撑大到几 GB。我见过有人把“所有 DNS 查询”都记下来做分析结果一天日志就上十万条。真实场景里家长最需要看到的是“试图访问但被拦截”的域名这些才是行为异常的线索。5. 避坑实录部署与上线后最容易栽的六个问题5.1 改 DNS 后拦截第二天全面失效现象头一天配置好验证拦截生效第二天发现所有设备都能正常访问被拦截的域名。检查 dnsmasq 进程在跑规则文件也在但设备根本没走这个 DNS。原因绝大多数家用路由器在重启后会重置 DHCP 下发的 DNS 配置恢复成运营商默认 DNS。如果路由器设置了每晚自动重启第二天 DNS 配置就被覆盖了。另一种隐蔽情况是手机和平板开启了“随机 MAC 地址”路由器 DHCP 无法把同一个设备绑定到同一个 IP策略服务识别设备身份失败。解决在路由器里给每台被控设备配置 DHCP 静态分配固定 IP 和 MAC 绑定关系同时在路由器 DHCP 的“自定义 DNS”字段把默认 DNS 修改为策略服务所在主机的局域网 IP。这样即使重启DHCP 下发的 DNS 也始终指向策略服务。这套资源里附了一个check_dns.sh脚本每天定时检查所有被控设备的 DNS 是否仍指向策略服务如果发现不一致自动向家长手机推送一条告警消息。5.2 拦截了主站点孩子从内嵌搜索接口绕过去了现象策略里拦截了某视频网站主域名但孩子打开网页面板后搜索框仍能正常播放行为日志里看不到任何主站域名命中记录。原因网站的视频播放通常走独立的 CDN 域名或接口子域名比如v1.video-cdn.example.com或search-api.example.net这些域名并不在主站的黑名单里。DNS 拦截是域名级控制不是页面级控制主站域名被拦但播放和搜索走的是另一个 CDN起到的作用就非常有限。解决启用“子域名全匹配”模式。策略服务在下发规则时对每个拦截域名同时生成一条后缀规则拦截该域名及其所有子域名。对于 CDN 域名按基础手法处理先放行然后打开落地页日志观察哪些域名频繁出现在放行记录里再手动添加针对性规则。这是一个持续的迭代过程没有一次配到位的银弹。5.3 HTTPS 跳转后完全拦截失败页面提示证书异常现象拦截规则对 HTTP 网站有效但对 HTTPS 网站部分失效。尤其是一些以 HSTS 方式强制跳转的站点即使 DNS 拦截了浏览器仍提示证书错误或者直接忽略解析结果。原因DNS 拦截只操作域名解析证书校验在 TLS 握手中独立完成。被拦截的域名如果返回了 NXDOMAIN浏览器正常报错但如果返回 0.0.0.0 而设备上缓存过期不刷新某些浏览器会走 HSTS 强制 HTTPS 连接导致证书校验步骤先于连接建立失败。解决首先接受一个边界——DNS 拦截是域名级方案拦不住“域名已解析但页面内部嵌入的第三方 HTTPS 资源”。要彻底做 URL 级拦截必须上透明代理加 CA 证书部署这超出了一般家庭维护能力。实际操作中我会把拦截动作设为 NXDOMAIN 而非 0.0.0.0减少 HSTS 干扰同时建议孩子设备尽量使用 Chrome 或其他主流浏览器方便观察证书报障与解析失败的差异。5.4 策略服务自动更新失败版本一直停留在旧规则现象在控制台更新了策略看到“下发成功”提示但目标设备仍然沿用旧规则dnsmasq 日志里没有任何变更记录。原因策略服务用于拉取策略的进程在运行时出错可能因为临时文件目录权限不足、dnsmasq reload 命令没有被正确执行或者设备端轮询流程卡死。这类问题最难排查因为它不会主动报错只有日志里留下一句忽略。解决为策略服务增加“版本比对日志”开关每次轮询不管有无变化都记录一条带时间戳的日志策略版本正常的增量变化应该很小如果有一次更新失败日志就能看到轮询接口返回超时或校验失败的记录再顺着接口错误反查是网络不通还是 token 失效。这里最有价值的教训是不要直接在后台进程里改规则文件先写临时文件测试通过后再正式替换并重载。5.5 误判把正规教育站点当成娱乐内容拦截了现象孩子的学习平台上内嵌了视频讲解功能页面加载时视频域名被拦截整个课程页面显示异常。家长看到误判后觉得这软件不行。原因内置类别库在做域名分类时把含带 “video” 或疑似流媒体特征的域名全部归类为“娱乐”没有考虑到教育平台也会使用视频组件。分类粒度粗误判在所难免。解决每台设备的管理页上提供一个“放行反馈”入口家长看到误判后一键放行并报告原因。策略服务收到的反馈会自动写入用户规则库的“覆盖记录”下次该域名直接走白名单优先级。随着使用时间变长用户规则库会逐渐覆盖掉系统库的误判偏差。我做了三年类似的系统之后发现没有哪个内置库能应付所有家庭的情况——私人规则库才是拦截准确率最终保底的手段。5.6 被控设备重启后策略服务没有自动启动现象孩子电脑重启后上网行为完全不受控DNS 查询直接跑去了运营商默认 DNS策略服务没有加载。原因策略服务没有注册成系统服务只在登录后手动启动。设备一旦断电重启进程不在了DNS 配置也被系统重置一切都回到“裸奔”状态。解决把策略服务注册为系统服务。Windows 用户用sc create注册为自启服务macOS 用户创建 launchd plistLinux 用户用 systemd unit。同时把“开机自检”做成一个入网钩子设备每次连上网络先检查本地 DNS 是否是策略服务地址不是就用脚本拉起来。这一步是自动化的关键。6. 验证拦截效果自建测试集、脚本自动化与规则导入技巧6.1 用自动化测试集跑一遍规则引擎策略改了不少拦截范围变大还是变小心里得有个谱。与其靠手敲网址挨个试不如写一个最小可验证的自动化测试集。本资源附带的规则测试脚本思路是这样的准备一组已知分类的域名清单逐个调用匹配器断言返回的动作是否符合预期。# evaluate_rules.py from rule_engine import DomainMatcher def run_evaluation(): matcher DomainMatcher() # 示例测试用例集实际资源里包含更完整的清单 test_cases [ (www.example-video.com, block, 娱乐类应被拦截), (learn.example-school.com, allow, 教育类应放行), (cdn.example-video.com, block, 视频 CDN 子域名应被拦截), (api.example-school.com, allow, 教育平台 API 不应被误拦), (unknown-site.org, allow, 未命中规则应默认放行), ] for domain, expected, desc in test_cases: result matcher.match(domain) status PASS if result expected else FAIL print(f{status}: {domain} - {result}, 期望 {expected} ({desc})) if __name__ __main__: run_evaluation()匹配器默认放行未知域名所以 “unknown-site.org” 预期结果是 allow逻辑上说得通。真正要注意的是断言里的优先级顺序我建议测试用例里至少覆盖四类已拦截主域名、主域名的子域名、已知教育平台、完全未知域名。四类覆盖住了规则引擎的基础行为就不会偏离预期。6.2 批量导入自定义规则时的格式约定手动一条条加规则太慢实际使用中要支持批量导入。这套资源里自定义规则的格式约定是每行一个域名或模式支持三类语法# 精确域名 example.com # 带通配符的后缀域名 *.video-platform.com # 正则表达式以 re: 开头 re:^.*\.game\-cdn\.(com|net)$批量导入脚本会自动解析这三种语法转换成匹配器内部结构。这里有一个实际踩过的坑文件编码。Windows 记事本默认 UTF-8 带 BOMBOM 字符会让第一行域名解析失败。导入脚本里要先做 BOM 剥离再逐行处理否则头一次导入就可能有一条规则静默丢失。6.3 上线后的灰度验证流程策略更新别一把梭直接全量下发。我现在的习惯是分三步走先在一台不重要的设备上应用新策略跑半天看日志确认没有误判和异常拦截再下发到全部设备如果发现误判用管理页的“放行反馈”快速修正等待下一次验证通过。有一次我给某视频平台加了新的子域名拦截规则灰度设备上跑了两个小时孩子用量没下去反倒是教育平台的一个页面挂掉了。查日志发现那个教育平台用了同一家 CDN 的域名前缀。从那以后我每次做批量规则更新都强制走一遍“灰度设备 → 日志确认 → 全量下发”的流程宁可慢一天也不把误判带到孩子正在用的设备上。希望这份资源里的这套流程能帮到你让家长控制这个功能真正稳定接管家里的网络。本文还有配套的精品资源点击获取