# 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 的服务器上可以显著改善。

---

## 下载

**https://relay.xxmxxs.top**