加 1.8.0 发布说明

_build/RELEASE-1.8.0.md

@@ -0,0 +1,92 @@
+# ykxmz 1.8.0 发布说明
+
+**发布日期**：2026-10-07
+**产物**：
+- 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 秒，
+  **每次还没建好就被下一次重启打断**，反而永远恢复不了
+- 加了宽限期；又发现宽限期太长会在链路持续不好时干等
+- 最终逻辑：**建好过又断 = 真故障，立刻重启；一直没建好 = 它在努力，继续等**
+
+## 四、中转管理后台完全重做
+
+界面重新排成：
+
+```
+顶栏（运行状态 / 版本 / 内存）
+  ↓
+公网地址（最重要，给你最大的一块）
+  ↓
+四个数字（登记设备 / 在线 / 手表会话 / 配对码占用）
+  ↓
+设备表（状态圆点、等宽配对码、一键删除）
+  ↓
+工具卡（网络体检 + 下载区）
+```
+
+窄屏下表格自动变成卡片布局，手机上也能看。
+
+顺带修的：
+- 管理页有时候显示成**一屏源码**（响应头类型写错）
+- 顶栏**标题被切掉**、状态标签压在文字上
+- 下载文件用 HEAD 探测时长度报 0（下载器会误判成空文件）
+
+## 五、其它
+
+- **清理僵尸设备记录**：设备列表原来只增不减，实测一天攒了 75 条
+  无效记录，拖慢手表和网页。现在超过 6 小时没上报的自动清掉，
+  它占用的配对码一起释放
+- **官网新增产品展示**：手表界面预览、电脑端真实截图、
+  两种连接方式对比
+- 支持 `HEAD` 请求
+
+---
+
+## 验收结果
+
+| 项目 | 结果 |
+|---|---|
+| 全量回归 | **33 个阶段全部通过** |
+| 安装包完整周期 | **20/20**（静默安装 7 秒、卸载 0.6 秒、无残留） |
+| 网页响应头 | **12/12** |
+| 公网可用率 | 26/30 = 86%（底层 4G 丢包 30%，这是链路的上限） |
+
+> 说明：可用率受限于现场 4G 网络质量。换有线网络或把中转
+> 放到有公网 IP 的服务器上可以显著改善，方案见
+> `docs/免费托管方案.md`。

_build/_c15.txt

@@ -1,73 +0,0 @@
-1.8.0：隧道稳定性大修 + 中转管理后台重做
-
-版本号 1.7.1 -> 1.8.0（8 个文件，13 处）。
-写了个 bump_180.py 统一处理 —— 版本号散落在
-Python / Java manifest / PowerShell / Inno Setup / 测试里，
-手动改必漏；而且 .ps1 必须保留 UTF-8 BOM。
-
-==================== 一、隧道稳定性（用户撞上 1033/502/530）====================
-
-1) 4G 链路会**静默断开 TCP 连接**（不发 FIN/RST，双方都以为还活着），
-   Linux 默认要 2 小时才发现 -> 改成 keepalive 30 秒 + 每 10 秒探测。
-   实测 60 秒内发现并重连。
-
-2) 隧道连接数 2 -> 4。只剩 1 条连接时跨机房回源会失败
-   （实测可用率 0/12，提到 4 条后 12/12）。
-
-3) 掉电重启后恢复慢：原来开机 2 分 10 秒公网才可用。
-   根因是 systemd-networkd-wait-online 等一个不归它管的网络
-   （wlan0 是 NetworkManager 管的），干等 2 分钟超时失败，
-   把 network-online.target 一起拖住。
-   mask 掉它之后：启动 17.3 秒，掉电重启 24 秒公网可用。
-
-4) 看门狗两次翻车都是我造成的，都修了：
-   a) 我先加了"确认故障立刻重启"，但隧道重建 4 条连接要 30~60 秒，
-      MIN_RESTART_GAP=45 导致**还没建齐就被下一次重启打断**，
-      死循环，每 50 秒重启一次 -> 加 150 秒宽限期
-   b) 宽限期又带来"链路持续差时什么都不做"的问题
-      -> 增加"本次重启后建齐过吗"的判断：
-         建齐过又垮 = 真故障，立刻重启
-         从没建齐 = 还在努力，继续等
-
-5) 顺手修：看门狗状态文件里的变量在函数定义前被引用，
-   set -u 下报 "BUILT: 未绑定的变量"。
-
-==================== 二、中转管理后台重做 ====================
-
-原来的管理页是几百行内联在 relay.py 的 f-string 里，
-改一处样式要在一堆转义花括号里翻。拆成独立模块 relay/admin.py。
-
-新设计（对齐官网那套白色简洁）：
-  吸顶顶栏 -> 公网地址（最大权重，这是用户最需要复制的）
-  -> 四个数字卡 -> 设备表 -> 工具卡（体检 + 下载）
-  空状态给图标+引导文案；窄屏表格自动变卡片。
-  relay.py 从 2089 行缩到 1500 行左右。
-
-修了三个我自己引入的 bug：
-  a) 响应头类型写错，浏览器把整页 HTML 当纯文本显示
-     （用户看到的是"一屏源码"）。教训：200 不等于页面能看，
-     当时只验了状态码和字节数。
-  b) 顶栏用了固定 height:62px，装不下"标题+副标题+版本信息"两行，
-     内容被顶出容器 -> 标题看不见、徽章压在字上。
-  c) do_HEAD 没处理 /download/ 路径，HEAD 一个 APK 返回
-     Content-Length: 0 + text/plain，下载器会误判成空文件。
-     同时发现 _head_info 里对 bytes 调 .encode() —— 加 _as_bytes() 兜住。
-
-==================== 三、其它 ====================
-
-* 设备记录只增不减：实测一天攒 75 条僵尸，/v1/health 从几 KB 涨到 20KB。
-  加 DEVICE_TTL（6 小时）自动清，占用的配对码一起释放
-  （管理页曾显示"配对码占用 131"但一台设备都没有）。
-* HEAD 请求支持（原来一律 501）。
-* 官网新增产品展示：手表界面预览（颜色/布局与真实手表一致）、
-  电脑端真实截图、两种连接方式对比图。
-* 加了一份 docs/免费托管方案.md（含一个纠错：上一版推荐的
-  ClawCloud Run 已在 2026-05-11 关停）。
-
-==================== 验收 ====================
-
-全量回归            33 个阶段全部通过
-安装包完整周期      20/20（静默装入 7 秒、卸载 0.6 秒、无残留）
-网页响应头          12/12
-公网可用率          26/30 = 86%（底层 4G 丢包 30%，是这个上限）
-发布产物            安装包 14.37MB / 服务端 0.20MB / 手表 0.19MB