ykxmz

36 Commits 1 Branch 18 Tags

2 Commits

Include renames

Author	SHA1	Message	Date
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	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

Author

SHA1

Message

Date

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

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