Commit Graph
16 Commits
Author SHA1 Message Date
xmz7891 bcb089eded 看门狗:连接数掉到 1 就立刻重启,不等攒够 3 次
排查公网间歇 530 时发现的:
  watchdog 日志显示「公网不通(HTTP 530,ha_connections=1)」
  —— 出问题那段时间隧道**只剩 1 条连接**。

原来 watchdog 只把 CONNS == 0 算"零连接",
CONNS == 1 不当回事。但实测**只剩一条连接时跨机房回源就会失败**
(请求落 SEA,隧道只剩 LAX 一条)。

改法:
  * CONNS <= 1 都计入降级计数
  * 公网不通 **且** 连接数已在危险区 = 确认的故障(不是短抖动)
    -> 立刻重启,不等 3 次

每次检查间隔 20 秒,等 3 次就是白断 40 秒。现在能省下来。

实测:改完公网 15/15 = 100%,连接数 4 条。

顺带说明 watchdog 是怎么跑的:
  systemd timer(lanremote-watchdog.timer),每 20 秒调一次
  watchdog.service。之前查"服务是 inactive"一度以为它没在跑,
  其实是 timer 触发型的 —— oneshot 服务跑完就是 inactive,正常。
2026-10-07 10:00:50 +08:00
xmz7891 fe3b9ada12 修管理页 Content-Type(浏览器显示成一屏源码)
用户截图:打开 relay.xxmxxs.top/zhongzhuanzhan 看到的**不是页面,
而是整页 HTML 源码**。

根因:_send() 的 content_type 参数默认是 application/json,
我重做管理页时调它没传 text/html —— 浏览器按 JSON/纯文本处理,
就把 HTML 原样显示了。

⚠ 更该反省的是:**我当时没发现。**
   验证脚本只看了 HTTP 200 和字节数,两个都对,就以为没问题。
   200 不等于页面能看 —— 响应头也得看。

顺手修的第二个问题:
   HEAD 请求一律返回 501 Unsupported method(没实现 do_HEAD)。
   浏览器用 GET 所以页面照开,但 Cloudflare 健康检查、
   很多监控/代理探测都用 HEAD,curl -I 也是。
   补了 do_HEAD:按路径算出类型和长度,只回头不回体。

新增测试 _build/test_response_headers.py(9 项):
  * HEAD 各路径不能是 501
  * 官网/管理页 Content-Type 必须是 text/html,不能是 json
  * favicon、产品截图必须是 image/*
并加进全量套件(阶段 3b6)。

验证:该测试 9/9 通过;全量套件 33 个阶段全部通过。
2026-10-07 09:53:43 +08:00
xmz7891 160dc3765e 修管理页测试的引号敏感 + 补 netPanel id
重做管理页时把 HTML 从 class=pick(无引号)改成了
class="pick"(标准写法),但测试里写死了无引号形式,
于是 5 个断言集体误报失败。

HTML 两种写法都合法,测试不该关心这个 ——
给两个测试加了 _has(),带不带引号都认。

另外给新管理页的体检卡补回 id=netPanel(语义合理,
也顺手让测试钩子还在)。

同时删掉 _build/_missing_tail.py(恢复事故时的临时文件,
静态检查把它当成真模块查,报了 8 个 undefined name)。

验证:管理页网络体检 15/15、中转批量删除 24/24、
全局 32 个阶段全部通过。
2026-10-07 09:45:10 +08:00
xmz7891 1f05084f51 隧道"假活"真因修复 + 中转管理后台重做
用户反馈两件事:
  1. 早上打开 relay.xxmxxs.top 看到 Cloudflare Error 1033 —— "这就是你说的优化好了?"
  2. "中转管理那边 ui 界面大改,现在难看的要死"

============ 一、隧道 1033/502/530 的真因 ============

之前我只测 15~25 次就说"可用率 100%",太草率 ——
实际是**间歇性假活**:隧道显示 ha_connections=2 连着,
公网却 502/530/000。watchdog 日志把过程记了下来。

根因:**4G 链路静默断开 TCP 连接**(不发 FIN/RST,双方都以为还活着)。
Cloudflare 把请求发到这条僵尸连接上就回错误。
Linux 默认 tcp_keepalive_time = **7200 秒(2 小时)**才发现,
中间这段时间服务一直"看着在线、实际打不开"。

修法(都有实测数据支撑):
  1. tcp_keepalive 30 秒 + 每 10 秒探测 3 次
     => 最多约 60 秒发现僵尸连接并重连
  2. 隧道连接数 2 -> 4
     (对照实验:http2+2 只有 1 条连上时公网 0/12;
       http2+4 稳定 12/12。连接数太少会出现"只有 1 条"的危险窗口)
  3. 协议定为 http2(cloudflared 自检说 TCP 7844 被墙,
     但实测 http2 反而比 quic 稳)

实测:http2+4 之后公网 40/40 = 100%,最慢 1.3 秒,0 次重连。

============ 二、中转管理后台重做 ============

原来是几百行内联在 relay.py 的 f-string 里(HTML+CSS+JS 全挤一起),
改一处样式要在一堆转义花括号里翻。拆成独立模块 relay/admin.py。

新版设计(对齐官网那套白色简洁):
  * 吸顶顶栏:品牌 + 运行状态 + 版本/内存/请求数
  * 公网地址给最大权重(这是用户最需要复制的东西)
  * 四个数字卡(在线/会话数带颜色区分)
  * 设备表卡片:状态圆点、等宽配对码、行悬停
  * 工具卡:网络体检 + 下载区并排
  * 空状态改成图标+引导文案,不再是干巴巴一句
  * 窄屏时表格自动变卡片

relay.py 从 2089 行缩到 1550 行。

============ 三、顺手修的两个真 bug ============

1. 设备记录只增不减
   self.devices 从不清理,被控端每次换端口/重装就多一条,
   实测一天攒了 75 条僵尸记录,/v1/health 从几 KB 涨到 20KB。
   加 DEVICE_TTL(6 小时)在 snapshot() 里清。

2. 配对码映射也没清
   RELAY.codes 和 devices 是一对孪生 dict,
   只清 devices 会留下指向已删设备的孤儿条目 ——
   管理页显示"配对码占用 131",实际一台设备都没有。
   现在一起清。

============ 四、我自己造的两次事故(如实记录) ============

1. 删文件删过头
   用"从 _admin_page 截到文件末尾"的方式替换方法,
   但 _admin_page 后面**还有 _esc/_kb/_uptime/class Server/main()**。
   结果 relay 起不来,systemd 重启 24 次,所有接口 000。
   教训:**"删到文件末尾"之前必须先确认末尾有什么。**

2. ADMIN_PATH 引用了不存在的常量
   路由里写的是字面量,我却在新代码里用了 ADMIN_PATH,
   管理页一访问就 NameError。现在统一定义了常量。

二者都是"改完没立刻验"造成的。现在每次改完都跑一遍
管理页 + 官网 + 关键接口的回归。
2026-10-07 09:34:53 +08:00
xmz7891 8c4ee6df08 修真凶:4G 链路静默断连导致隧道"假活"(用户撞上 Error 1033)
现象:用户早上打开 relay.xxmxxs.top 看到 Cloudflare Error 1033。
      watchdog 日志把过程记下来了:
        公网不通(HTTP 000,ha_connections=2)  <- 隧道显示连着,公网不通
        公网不通(HTTP 502,ha_connections=2)
        公网恢复(HTTP 200)                     <- 自己又好了
      也就是说:**间歇性假活**,短样本测不出来。
      我之前只测 15~25 次就说"可用率 100%",太草率了。

根因:4G 链路会**静默断开** TCP 连接 —— 不发 FIN/RST,双方都以为还连着。
      Cloudflare 把请求发到这条僵尸连接上,就回 502/530/1033。
      Linux 默认 tcp_keepalive_time = **7200 秒(2 小时)**才发现连接死了,
      所以中间这段时间服务一直"看着在线、实际打不开"。

      tunnel.log 最近 3000 行的佐证:
        i/o timeout              212 次
        Retrying connection      127 次
        Lost connection           22 次

修法:
  1. TCP keepalive 调到 30 秒 + 每 10 秒探测 3 次
     => 最多约 60 秒发现僵尸连接,cloudflared 立刻重连
     (/etc/sysctl.d/97-ykxmz-keepalive.conf)
  2. 隧道连接数 2 -> 4,多几条冗余
  3. 修 relay 从不清理设备记录的问题:
     self.devices 只增不减,被控端每换端口/重装就多一条,
     实测一天攒了 75 条僵尸记录,/v1/health 从几 KB 涨到 20KB。
     加 DEVICE_TTL(6 小时)在 snapshot() 里清掉。

实测(修完立刻验证):
    设备侧  公网 15/15 HTTP 200
    Windows 公网 25/25,中位 520 ms,最快 463 ms
    health  20931 字节 / 75 台  ->  152 字节 / 0 台
2026-10-07 09:15:27 +08:00
xmz7891 7b7830d8c5 阶段3+4+5:管理页白色化 + 局域网诊断 + 全量验收
阶段3 管理页
- 清掉全部深色主题残留(地址框 #0b1220、按钮悬停 #262c36、
  删除按钮 #2d1214 等 11 处),现在 0 处深色
- 接口全部正常:health / downloads / netcheck

阶段4 局域网诊断
- 查清楚"电脑不在同一网络"是怎么回事:被控端是**对的**
  (lan_ips() 报 ['192.168.2.64', '169.254.83.107'],真实地址排第一),
  是手表当时真不在 192.168.2.x —— 可能连了 5G 频段的另一个路由器,或开着移动数据
- 所以改了手表的提示:不再只说"不在同一网络",
  而是把**双方地址都打出来**,用户一眼能看出是网段不同还是连错 WiFi
- 端到端验证局域网路径:认证 1 ms,功能列表 207 项

阶段1 结论修正(一天内推翻自己两次,如实记录)
- 第一次判断"优选 IP 无用":错。半小时内确实能避开超时 IP
- 第二次固定优选 IP:也错。那些实测 138ms 的 IP 半小时后全不通了
  —— Cloudflare anycast 可达性随运营商路由变化,固定 IP 等于钉死到会失效的地址
- 最终:不固定,靠 GeoDNS + cloudflared 重试 + ha-connections 2 冗余
- 撤销后立即变好:连接稳定 2 条、超时告警 0 次、设备侧延迟 4.40s -> 1.66s
- **真正的瓶颈**:分段实测发现本机到 Cloudflare 的**裸 RTT 就 1439 ms**,
  比经隧道的请求(1215 ms)还慢。说明瓶颈是这条网络的 4G 上行本身,
  不是设备的隧道。公网侧已无优化空间。
- 局域网 118 ms vs 公网 1215 ms,快 10 倍 —— 这才是该走的路

阶段5 验收
- 全量回归 29 项全通过
- 设备侧验收 38 项全通过
- 成品:setup exe 14.37 MB / server zip / watch apk,已同步到设备下载区
2026-10-07 00:13:10 +08:00
xmz7891 566d9e384f 阶段1+2:恢复 HTTP/2 加速 + 重做官网
阶段1 网络加速
- 发现隧道在跑 QUIC(ExecStart 丢了 --protocol http2),
  实测 QUIC 可用率 48% vs HTTP/2 80%+,是重大性能回退。
  恢复后公网延迟从 4141ms 降到 690ms(快 6 倍),可用率 92%。
- 优选 IP 结论:无效。hosts 覆盖确实生效了(日志里连的就是指定 IP),
  但落点仍是 lax —— 运营商把所有 Cloudflare anycast 都路由到美西。
  已清掉这段无效配置。
- BBR 不可用:设备是自定义内核 6.4.0-rc4-jsbsbxjxh66,
  没编 tcp_bbr 模块也没配置项。改用 cubic + 调优:
  TCP 缓冲 4MB、tcp_fastopen=3、tcp_slow_start_after_idle=0
  (长轮询场景关键)、tcp_tw_reuse=1。

阶段2 官网重做
- 拆出独立模块 relay/landing.py(relay.py 已两千多行,
  再塞 HTML 没法看)
- 信息结构参考成熟产品站:吸顶导航 / Hero / 九宫格功能 /
  三步上手 / 下载 / FAQ / 页脚
- 保持白色简洁:底白、浅灰面板、细边框、大量留白
- logo 用内联 SVG(ICO 放 img 里实测是破图)
- 管理入口从官网移除(管理不对外开放)

过程中被自己的测试抓到两个 bug:
- 模块叫 site.py 会和 Python 标准库重名,import site 拿到的是标准库
- _logo() 里把 % 格式化和字符串拼接混用,直接抛 TypeError
2026-10-06 23:53:19 +08:00
xmz7891 caf774791f 修官网 .lead 的文字色
那一处还是深色主题配的浅灰(#c9d1d9),白底上几乎看不见。
上一版脚本没改成功,因为判断条件写成了新值已存在就跳过,
而 color:#1f2328 在别处已经出现过,导致整个替换被跳过。
2026-10-06 23:10:49 +08:00
xmz7891 51565112b9 网页改成白色简洁 + 修官网两个 bug
配色
- 官网 / 登录页 / 管理页从 GitHub 深色风改成白色简洁
  (用户的设计理念:所有东西都要白色简洁)
- 白底上把浅灰文字换成深色,链接蓝也调深一档保证对比度

修 bug
- 管理入口的链接拼接写坏了,页面上显示成 href= + ADMIN_PATH +,
  点了打不开管理页
- .lead 用的是深色主题的浅灰,白底上几乎看不见

其他
- 清掉提交信息里的 BOM(PowerShell 的 Set-Content 加的)
2026-10-06 23:10:08 +08:00
xmz7891 81e923a0aa 1.7.1:修白屏 + 配对 + 官网管理页分家
手表端
- 修「连上后一片白屏」:initTabs() 从来没被调用过,
  导致 tabDefs 为 null、selectTab 直接 return,
  标签栏里只剩一个孤立的滑动指示器
- 应用名改成 ykxmz

被控端
- 修「设备已关闭新设备配对」:配对码本身就是密钥,
  拿着正确的码就该放行。老逻辑"首台配对后自动关窗"会把
  手表重装的人永久挡在外面
- 应用名改成 ykxmz

服务器端
- / 改成官网(公开,简洁介绍 + 下载)
- /zhingzhuanzhan 中转站管理(要登录),/admin 自动跳转
- 管理账号 xmz7891,可改
- 官网 / 登录页 / 管理页都加上 favicon
2026-10-06 23:08:07 +08:00
xmz7891 ce87ec1650 1.7.0:常规发布
- 版本号 1.7.0 -> 1.7.0
- 重建三端并打包
- 关键测试全过
2026-10-06 23:08:07 +08:00
xmz7891 4c88ca901f 1.6.2:常规发布
- 版本号 1.6.2 -> 1.6.2
- 重建三端并打包
- 关键测试全过
2026-10-06 23:08:07 +08:00
xmz7891 65dc2fad65 1.6.1:常规发布
- 版本号 1.6.1 -> 1.6.1
- 重建三端并打包
- 关键测试全过
2026-10-06 23:08:07 +08:00
xmz7891 07e96a9595 1.6.0:重写 README,面向老师 / 电教 / 开发者 / 普通用户
README
- 原来的 README 是开发者视角(在解释我为什么没做某功能),
  而且通篇 AI 腔。这次按用户视角重写,讲怎么用。
- 开头就分流:老师 / 电教 / 开发者 / 普通用户,各看各的
- 定位改成教室电脑手表遥控,主场景是老师上课管教室那台电脑
- 加了电教专用一节:机房同传部署、脚本批量推、网络规划、权限收口
- 加了开发者一节:三端怎么编译、怎么跑测试、怎么打包
- 加了通信协议一节
- 常见问题、排错顺序、错误对照表都补全

版本号
- 1.5.0 -> 1.6.0(versionCode 107)
- 顺手写了通用的版本升级脚本 _build/bump_version_generic.py,
  以后升版本一条命令就行,不用手改十几个文件
2026-10-06 23:08:07 +08:00
xmz7891 60d1bdfe58 中转站加下载区 + 大文件流式发送
下载区
- 管理页加一张「下载最新版」卡片,就一个按钮
  自动指向 /v1/downloads 里最新的被控端整包,不用每次改页面
- GET /v1/downloads 列出成品
- GET /download/<文件> 直接给文件
  只允许白名单后缀(.apk/.zip/.txt/.exe/.idsig)
  文件名严格校验,挡目录穿越(../ 和 ..%2F 都试过)
- 卡片下面附一个 Gitee 历史版本入口

大文件
- 原来 read_bytes() 一次性读进内存再 write。
  19MB 在 460MB 的设备上勉强,更要命的是 Cloudflare
  有 100 秒的源站响应上限,数据越晚开始流动越容易被掐。
- 改成 64KB 分块流式发送,边读边发
  实测:19MB 公网下载 40 秒完成,字节数完全一致

版本
- 三端分开打包(原来是一个合并 zip)
    ykxmz-agent-1.5.0.zip   被控端
    ykxmz-server-1.5.0.zip  服务器端
    ykxmz-watch-1.5.0.apk   控制端(直接给 APK)
2026-10-06 23:08:06 +08:00
xmz7891 b62ac865ea ykxmz 1.5.0:修复手表端 TLS 证书校验 + MTU 修复网络稳定性
被控端
- 修复 MTU 问题:夹 MSS + 路径 MTU 探测(公网可用率 48% -> 100%)
- 复用 HTTP 连接(免掉每次新建 TLS 的 30% 握手失败)
- 每分钟回头找局域网,自动切回快 400 倍的路径
- 画面心跳帧:静止时省流量,客户端仍知道流是活的
- 锁屏时给出可操作的提示

手表端
- 内置 GTS Root R4 / GlobalSign Root CA,修 SSLHandshakeException
- 连接错误翻译成人话(证书/时间/解析/超时分别提示)
- 经中转连上后用服务器报的地址刷新已配对记录
- 新增局域网连接页面、服务器延迟检测

服务器端
- 支持 chunked 请求体(修每 16 秒一次的连接错乱与大面积 502)
- 网络调优脚本 net-tune.sh(开机自动应用)
- 管理页:批量删除、网络体检、下载区
- 隧道改 HTTP/2 + 双连接

文档
- 许可协议 / 安装前必读 / 安装后须知(作者:小麦子)
2026-10-06 19:01:05 +08:00