ykxmz/_build/RELEASE-1.8.0.md

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。