2 Commits

Include renames

Author	SHA1	Message	Date
xmz7891	9bdd36cf56	2.1.4：修 URL 协议头 bug + 清理对外材料里泄漏的服务器信息 ... 用户报了三件事，一起处理。 == 一、发行版介绍里泄漏了服务器公网 IP == _build/CHANGELOG.md 的 2.1.3 那节写了服务器公网 IP，而发布脚本 把这个文件当"更新说明"传给 Gitee，于是发行版介绍里就带出去了。 为什么 IP 不该公开：直接打 IP 就绕过 Cloudflare 了 —— 没有 CDN、没有防护、没有速率限制。源站本来就不该被人知道是谁 （这也是为什么 nginx 那层只认域名、中转只绑 127.0.0.1）。 处理： * 已发的 v2.1.3 发行版介绍用 API 改掉（扫了全部 11 个发行版，只它一个） * 仓库里 16 个文件里的 IP 全部换成域名或占位符 * 运维脚本改成从环境变量读，公开仓库里不留具体地址 顺手发现**更严重的一处**：旧管理员密码硬编码在 docs/AFTER-INSTALL.txt（会打进服务端 zip）和 installer/license-combined.txt（**安装包的许可页，每个装的人都能看到**）里。 而用户当前密码就含这个串，等于公开了一半。一并清掉， 公开材料里改成"密码在你服务器上"的说明。 == 二、手表端填了地址却连不上 == 用户截图：填域名（没写协议头）-> 点「检查服务器」报 MalformedURLException: no protocol: <域名>/v1/health 根因：补协议头的逻辑只写在连接那条路（RelayTransport 的构造函数）上， checkServer() 直接拿原始字符串拼 URL —— 同一个地址，连接能用、检查却崩。 修法：把规范化收到 relayUrl() 这**唯一一个入口**，所有调用方都从那里取。 规则和电脑端一致：IP / localhost / *.local -> http，域名 -> https。 顺带补了 _tests/test_relay_url_normalize.py 盯住它（含 9 个用例实算）。 == 三、Gitee 的 README 被判"可能含有违规信息" == Gitee 挂的是软性公告（可自行修改或申诉），但确实挂在那。 逐项看了 README，改掉几处**不准确**且容易误判的表述： * 原文写"看看学生机是不是在打游戏" —— 这是**错的**： 被控端只装在一台电脑上（讲台那台），根本看不到别的机器。 既不准确又像监控软件，改成"作用于被控端那一台" * 课堂那几项功能如实说明：改的是本机 hosts、结束的是本机进程， 都可逆，下课点「一键恢复全部」就还原 * "免杀对抗""伪装成系统进程"这类词（虽然是在说"我们不做这些"） 本身就在审核词库里，换成正面的说法 * 成品文件名从 1.8.2 更新到当前版本，并且以后发版自动跟着改 （把 README 加进了 bump 脚本；以前一直停在 1.8.2， 用户照着 README 去 releases 根本找不到那个文件） == 四、做这件事时自己踩的坑（都写进注释了）== * 批量替换时**没排除 gitignore 的文件**，把本地密码文件也改了 * 替换时往字典字面量中间塞注释，**弄坏了 5 个文件的语法** * 修的时候手写"坏文件列表"，漏了 2 个 —— 改成全仓库扫模式（列表是观察到的，不是穷尽的） * 清理工具自己又成了泄漏点（脚本里写了要匹配的 IP/密码）， 加了 _build/precommit_leak_gate.py 当闸门才抓到 教训：批量替换要先排除不该碰的文件，而且不能往表达式中间塞东西。 == 按用户要求：测完再提交 == 全量回归 41 个阶段全 PASS（2 项因锁屏 SKIP） 601 个 Python 文件语法通过 pyflakes 干净 安装包完整周期 20/20 对外材料清洁度 15/15 提交前泄漏闸门通过 （这条信息是补写的：上一个提交因为 heredoc 把提交说明打到屏幕而不是 文件，信息变成空的 "remove temp" 了，内容本身是对的。）	2026-10-08 23:51:17 +08:00
xmz7891	47e08af151	监测单元和预案重写成"分层"版（来源改为本地整份文件） ... == 为什么重写 == certbot 签证书时加了 http -> https 的 301，而监测单元原来判断 "curl 拿到 200 才算健康"、且 curl **默认不跟跳转** -> 拿到 301 -> 判成"网站挂了" -> 又要启动预案 -> 重启中转 -> 再查还是 301。 这是**第二次**踩同一类坑了（上一次是改监听地址忘了改探测地址）。 共同教训：**改了入口的行为，必须回头看所有探测入口的地方。** == 新设计：分两层探测 == PRIMARY https://yk.xxmxxs.top/v1/health 用户实际走的路 FALLBACK http://127.0.0.1:13245/v1/health 中转本身 两个都查才能分清哪一层坏了，进而选对抢救动作： PRIMARY 挂 + FALLBACK 好 -> edge 层（CF / DNS / nginx） 两个都挂 -> core 层（中转服务本身） 预案据此走不同的阶梯： edge: 重载 nginx -> 重启 nginx -> 查 443 与证书 core: 重启中转 -> 强杀重拉 -> 中转+nginx 都重启 不区分层次的话只能瞎重启，而 edge 层的问题重启中转一万次也没用。 == 做法上的改进：不再远端打补丁 == 前几轮一直是"SSH 过去用嵌套 heredoc 现场改 monitor.sh"， 连续踩三次：PowerShell 在本机求值 \、引号被吃、 脚本里的 %{http_code} 和 Python 的 %% 格式化打架。 现在改成：relay/monitor-lightsail.sh 和 relay/rescue-lightsail.sh 是**唯一事实来源**，本地编辑 -> 整份上传 -> 重装， 改了什么一目了然，也能进 git。 == 顺带 == 因为 Lightsail 防火墙还没放行 443，PRIMARY 一直是 000， 监测会把 fails 一直加上去、白生成抢救报告。 所以暂时把 monitor.timer 停掉，等 443 开了再启用 （脚本 _build/pause_monitor.py，恢复是一条 systemctl start）。	2026-10-08 22:53:44 +08:00