mirror of
https://gitee.com/xmz7891/ykxmz.git
synced 2026-10-18 21:50:44 +00:00
xmz7891
351171e6ea
用户定的新规矩：
「你对外公开的数据里不要包含那个中转站管理的页面，你就只能提官网」
用户确认的范围：只清理「我对外的公开发言」
（发布说明 / 更新日志 / 官网 / README / 我给出的汇报），
服务端 zip 里的运维文档保留（装服务器的人需要它），
源码实现保留（路径是功能本身，藏起来没法维护）。
清掉的内容：
* CHANGELOG.md：1.8.0 条目里"管理后台重做"整段、
"管理页显示成一屏源码"、"管理页标题被切掉"；
1.7.1 条目里**直接写出的路径 /zhongzhuanzhan**、
"管理入口从官网上移除"；1.7.0 的"管理页加图标"
* RELEASE-1.8.0.md：第四节「中转管理后台完全重做」整节删掉，
改成「官网重新设计」
新增 _build/test_public_clean.py（15 项）并加进套件（阶段 3b7）：
* CHANGELOG / README / docs 里不许出现
zhongzhuanzhan、/admin、管理后台、管理页、管理入口、admin_password
* 官网渲染出来的 HTML 逐词检查，且站内链接只允许
指向 /download/、/shot/、首页、图标、页内锚点
* 发布说明里不许出现安装教程类内容（用户要求只放更新内容）
为什么写成测试：文档没人看。这一天里我因为"以为记住了"
翻了三次车，所以把规矩变成会红的断言。
新增 docs/项目规矩.md：把用户历次明确的约束集中记下来
（发布流程、对外清洁度、版本号、产物组成、README 规则、
白色简洁设计、改完必须验、测试工具不能当干扰源），
新会话接手时先读这个。
顺带修的工程问题（今天反复踩的坑）：
* 用 PowerShell 的 @"..."@ 嵌 Python 去改 .ps1 时，
PowerShell 会先把 $var 展开成空，写进去一堆反斜杠
-> verify_all.ps1 被写坏，& 语法报错
现在改 .ps1 一律用 Python 读写文件
* re.sub 的替换串会解释反斜杠转义，
`"\\test_public_clean.py"` 里的 \t 变成制表符，
路径成了 "_build<TAB>est_public_clean.py"
-> 用 lambda 替换，避开转义
验收：全量回归 34 个阶段全部通过（含新的清洁度守卫）。
3.2 KiB
3.2 KiB
ykxmz 1.8.0 发布说明
发布日期：2026-10-07 官网：https://relay.xxmxxs.top 产物：
- Windows 被控端：
ykxmz-setup-1.8.0.exe（14.37 MB，安装包） - 服务端：
ykxmz-server-1.8.0.zip（0.21 MB，随身 WiFi / Linux） - 手表端：
ykxmz-watch-1.8.0.apk（0.19 MB）
一、修「跨网络老断」的真因（Error 1033 / 502 / 530）
这一版最主要的东西。现象是：手机/手表打开中转地址，时不时看到 Cloudflare 的 Error 1033 或者 502、530，过一会又自己好了。
根因是 4G 链路会静默断开 TCP 连接 —— 不发 FIN 也不发 RST， 双方都以为连接还活着。Cloudflare 把请求发到这种「僵尸连接」上就报错。
而 Linux 默认要 2 小时才发现连接已经死了，中间这段时间 服务一直处于「看着在线、实际打不开」的状态。
改了什么
- 把 TCP 存活探测改成 30 秒一次、连续 3 次没回应就断开重连 → 最多 60 秒发现僵尸连接
- 隧道连接数从 2 条提到 4 条。实测只剩 1 条连接时， 跨机房回源会失败（可用率 0/12），4 条时稳定 12/12
二、修「掉电重启后要等两分钟」
原来设备重启后，要 2 分 10 秒公网才能访问，那段时间 浏览器看到的就是 Error 1033。
原因是系统里有两个网络管理服务同时在跑，其中一个在等 一个不归它管的网络，干等 2 分钟超时失败，把整个启动流程拖住了。
改完：开机 17 秒就绪，掉电重启后 24 秒公网可用。
三、看门狗重做
看门狗负责在隧道不通时自动重启它。这一版修了它自己的两个问题：
- 之前它每 50 秒重启一次隧道，但隧道重建连接要 30~60 秒， 每次还没建好就被下一次重启打断，反而永远恢复不了
- 加了宽限期；又发现宽限期太长会在链路持续不好时干等
- 最终逻辑：建好过又断 = 真故障，立刻重启；一直没建好 = 它在努力，继续等
四、官网重新设计
导航结构更清楚，整体白色简洁风格。
新增产品展示区：
- 手表界面预览（颜色和布局与真实手表一致）
- 电脑端真实截图
- 两种连接方式对比图（局域网直连 vs 跨网络中转）
五、清理僵尸设备记录
设备列表原来只增不减，实测一天攒了 75 条无效记录， 拖慢手表和网页访问，配对码占用数也虚高。
现在超过 6 小时没上报的设备自动清掉，它占用的配对码一起释放。
六、其它
- 修下载文件用
HEAD探测时长度报 0（部分下载器会误判成空文件） - 支持
HEAD请求（原来一律返回 501）
验收结果
| 项目 | 结果 |
|---|---|
| 全量回归 | 33 个阶段全部通过 |
| 安装包完整周期 | 20/20（静默安装 7 秒、卸载 0.6 秒、无残留） |
| 网页响应头 | 12/12 |
| 公网可用率 | 26/30 = 86%（底层 4G 丢包 30%，这是链路的上限） |
说明：可用率受限于现场 4G 网络质量。换有线网络或把中转 放到有公网 IP 的服务器上可以显著改善。