xmz7891/ykxmz
1
0
Fork 0
mirror of https://gitee.com/xmz7891/ykxmz.git synced 2026-10-18 13:40:45 +00:00
Code Issues Packages Projects Releases Wiki Activity
57 Commits 1 Branch 18 Tags
facb156acafaf995a0a703b32a00ce91c0f8d965
Commit Graph
7 Commits
Author SHA1 Message Date
xmz7891 facb156aca 服务端 zip 加一键部署脚本（cloudflared 安装 + 部署 + 公网，全自动） 
用户要求：服务器端文件里放一个 .sh，双击就能检查 cloudflared 装没装、
自动部署、配好公网，以后全自动。

== 新增 ==

relay/deploy.sh        一键部署主脚本，7 步全自动：
                       环境检查 -> 装 cloudflared -> 部署程序 -> 网络调优
                       -> 写 4 个 systemd 服务 -> 配隧道 -> 启动自检打公网地址
relay/deploy-tune.sh   网络调优，可单独重跑：
                       keepalive 30/10/3 + 路径 MTU 探测 + MSS 1360
                       + 接口 MTU 1400 + mask networkd-wait-online
                       每一项都写明了实测依据

用法：
    bash deploy.sh                           复用已有凭据，全自动
    TUNNEL_TOKEN=eyJh... bash deploy.sh      Token 模式
    bash deploy.sh --hostname relay.你的域名  换域名
    bash deploy.sh --skip-tunnel             只装中转
    bash deploy.sh --help                    全部参数

重跑 = 升级；已有数据/配对码/管理密码/凭据/手改过的 config.yml 都不动。

== 自动化到什么程度 ==

* cloudflared 不在就自动下载装上（并校验能执行）
* 隧道支持两种模式：已有凭据文件、或 TUNNEL_TOKEN
* **不传 --hostname 且没有 Token 时明确提示要填**，不会静默用一个写死的值
  （用户明确说过：这个中转站是他自己用的，不对外开放，
   绝不能把私人域名烧成默认值）
* deploy-tune.sh 的 MTU 取 1400：路径 MTU 实测 1472，
  而 MSS 钳制只管 TCP、QUIC 走 UDP 完全不受保护；
  接口 MTU 降到 1400 后 QUIC 建齐 10 条连接从 28 秒缩到 12 秒

== 顺带修掉两个真 bug ==

1. write_tunnel_unit 写的文件名漏了 .service 后缀 ——
   文件写下去了但 systemd 完全看不见，enable 还会安静地失败。
2. 发布包一直缺 site_shots/（老 bug）：
   package_remote.py 用 iterdir() + is_file() 收文件，目录进不去。
   新机器装完官网截图全是 404。只有从 zip 解压真跑一遍才暴露。
   同时把 deploy.sh 里 site_shots 的检查降级成警告（缺截图不该让部署失败）。

另外给 deploy-tune.sh 清旧 MSS 规则的循环加了 10 次上限 ——
原写法在 -D 报成功但规则仍在时会死循环把整个部署卡死。

== 验证 ==

* _build/test_deploy_sh.sh        沙箱 65 项，全通过
* _build/test_zip_deploy.sh       从发布 zip 解压再跑，30 项，全通过
* _build/test_deploy_real.sh      **真机 Debian 上实测**（新增）：
    zip 解出 17 个文件 -> 语法/LF/无 BOM 通过
    --help 退出码 0 且无副作用、未知参数退出码 2
    沙箱安装成功、幂等重跑哨兵不被冲
    现有三个中转服务全程 active，自检 200
 2026-10-07 17:28:09 +08:00
xmz7891 46196c3618 CHANGELOG 加 1.8.1 2026-10-07 14:24:06 +08: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 个阶段全部通过（含新的清洁度守卫）。
 2026-10-07 12:15:32 +08:00
xmz7891 49fdec1da8 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
 2026-10-07 11:47:12 +08:00
xmz7891 2b40968d23 CHANGELOG 补上安装/卸载卡死的修复说明 2026-10-07 03:14:21 +08:00
xmz7891 e29b741ddf 收尾：CHANGELOG 补 1.7.1 + 清历史产物 + 修验证脚本路径 
- _build/CHANGELOG.md 补上 1.7.1 条目（发版说明的唯一来源）
- 两个验证脚本还在用旧的管理页路径 zhingzhuanzhan，
  跑起来会误报失败，改成 zhongzhuanzhan
- dist 里清掉 1.6.x 的历史产物（Gitee 发行版里有，删了能下回来）
 2026-10-07 00:17:55 +08:00
xmz7891 ce87ec1650 1.7.0：常规发布 
- 版本号 1.7.0 -> 1.7.0
- 重建三端并打包
- 关键测试全过
 2026-10-06 23:08:07 +08:00