Files
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

194 lines
7.2 KiB
Bash
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
#!/bin/bash
# 看门狗第三版:两个信号都查。
#
# 为什么还要改:
# 第二版只看 cloudflared 的 ha_connections 指标。
# 但"僵死连接"会把指标维持在 1 —— 计数还在,实际早断了。
# 这种时候看门狗以为一切正常,一直不管。
# (今早就遇到一次:浏览器 1033,指标却说有 1 条连接)
#
# 这一版:
# 信号 A:ha_connections == 0 -> 记一次"零连接"
# 信号 B:公网 /v1/health 打不通 -> 记一次"公网不通"
# 任一信号连续 2 次 -> 重启隧道
# 另外:隧道日志超过 10 分钟没新行 + 公网不通 -> 判定进程卡死,重启
set -u
RELAY_DIR=/root/lanremote-relay
URL_FILE="$RELAY_DIR/public_url.txt"
STATE_FILE="$RELAY_DIR/watchdog.state"
TUNNEL_LOG="$RELAY_DIR/tunnel.log"
METRICS=http://127.0.0.1:20241/metrics
LOG_TAG=lanremote-watchdog
# 连续几次公网不通才重启。
# 设 3(约 60 秒)而不是 2:短抖动让 cloudflared 自己重连就好,
# 频繁重启反而让它一直停在"正在重连"的状态。
THRESHOLD=3
STALE_MINUTES=10 # 日志多久没动静算卡死
# 两次重启之间至少隔这么久(秒)。
# 实测隧道重建只要 30~40 秒,原来设 120 秒太保守 ——
# 真断的时候会干等(日志里出现过"距上次重启才 118 秒,先不重启",
# 结果多断了 2 分钟)。
# 设 45 秒:既够 cloudflared 把连接建起来,又不会干等太久。
# 两次重启至少隔这么久。
# 150 秒不是拍脑袋:隧道在差的 4G 上重建 4 条连接要 30~60 秒,
# 原来设 45 秒会导致**隧道还没建齐就被下一次重启打断**,
# 永远停在只剩 1 条连接的状态(实测死循环,每 50 秒重启一次)。
# 给足宽限期,让它有机会稳定下来。
MIN_RESTART_GAP=150
GRACE=150
log() {
logger -t "$LOG_TAG" "$1"
echo "[$(date '+%m-%d %H:%M:%S')] $1"
}
read_state() {
local key="$1" default="$2" value=""
if [ -f "$STATE_FILE" ]; then
value=$(grep "^$key=" "$STATE_FILE" 2>/dev/null | cut -d= -f2)
fi
[ -n "$value" ] && echo "$value" || echo "$default"
}
# 状态文件现在存三样:
# zero —— 连续降级次数
# fail —— 连续失败次数
# built —— 本次重启后有没有建齐过(1=建齐过)
write_state() {
printf 'zero=%s\nfail=%s\nbuilt=%s\n' "$1" "$2" "${3:-0}" > "$STATE_FILE"
}
LAST_RESTART_FILE="$RELAY_DIR/watchdog.last_restart"
restart_tunnel() {
local why="$1"
local now last gap
now=$(date +%s)
last=0
[ -f "$LAST_RESTART_FILE" ] && last=$(cat "$LAST_RESTART_FILE" 2>/dev/null || echo 0)
gap=$((now - last))
# 连接数归零 = 真的断了,不是抖动 —— 这种不受间隔限制
local conns_now
conns_now=$(timeout 5 curl -s --max-time 4 "$METRICS" 2>/dev/null \
| grep '^cloudflared_tunnel_ha_connections' | awk '{print $2}')
if [ "${conns_now:-1}" != "0" ] && [ "$gap" -lt "$MIN_RESTART_GAP" ]; then
# 刚重启过还没到间隔:这次先不重启,
# 让 cloudflared 自己把连接建起来(它本来就在重试)。
log "$why —— 但距上次重启才 ${gap} 秒(下限 ${MIN_RESTART_GAP} 秒),先不重启"
write_state 0 0 "${BUILT:-0}"
exit 0
fi
log "$why —— 重启隧道(距上次 ${gap} 秒)"
echo "$now" > "$LAST_RESTART_FILE"
systemctl restart lanremote-tunnel
write_state 0 0 0
sleep 25
log "重启后地址: $(cat "$URL_FILE" 2>/dev/null || echo '(还没拿到)')"
exit 0
}
ZERO=$(read_state zero 0)
FAIL=$(read_state fail 0)
BUILT=$(read_state built 0)
# ---------- 信号 A:cloudflared 自报的连接数 ----------
CONNS=$(timeout 5 curl -s --max-time 4 "$METRICS" 2>/dev/null \
| grep '^cloudflared_tunnel_ha_connections' | awk '{print $2}')
[ -z "$CONNS" ] && CONNS=""
# 连接数达到 3 条以上就算"建齐过"。
# 记在状态文件里,跨多次检查保留 —— 这样即使后面掉到 1 条,
# 我们也知道"它本来是能建齐的"。
if [ -n "$CONNS" ] && [ "$CONNS" -ge 3 ] 2>/dev/null; then
if [ "$BUILT" != "1" ]; then
log "本次已建齐 ${CONNS} 条连接"
fi
BUILT=1
fi
# ---------- 信号 B:公网真的通吗 ----------
URL=$(cat "$URL_FILE" 2>/dev/null | tr -d '\r\n')
CODE="000"
if [ -n "$URL" ]; then
CODE=$(timeout 20 curl -4 -s -o /dev/null -w '%{http_code}' \
-H 'User-Agent: LanRemote/1.4.0' "$URL/v1/health" 2>/dev/null)
CODE=${CODE:-000}
fi
PUBLIC_OK=0
[ "$CODE" = "200" ] && PUBLIC_OK=1
# ---------- 信号 C:日志僵死了吗 ----------
LOG_STALE=0
if [ -f "$TUNNEL_LOG" ]; then
LAST=$(stat -c %Y "$TUNNEL_LOG" 2>/dev/null || echo 0)
NOW=$(date +%s)
if [ "$LAST" -gt 0 ] && [ $((NOW - LAST)) -gt $((STALE_MINUTES * 60)) ]; then
LOG_STALE=1
fi
fi
# ---------- 判断 ----------
if [ "$PUBLIC_OK" = "1" ]; then
# 公网通就是真的通,计数器清零
if [ "$ZERO" != "0" ] || [ "$FAIL" != "0" ]; then
log "公网恢复(HTTP 200),计数清零(之前 zero=$ZERO fail=$FAIL)"
fi
write_state 0 0 "${BUILT:-0}"
exit 0
fi
# 公网不通 —— 看是哪种原因
DETAIL="HTTP $CODE"
[ -n "$CONNS" ] && DETAIL="$DETAIL,ha_connections=$CONNS"
if [ "$LOG_STALE" = "1" ] && [ "$FAIL" -ge 1 ]; then
restart_tunnel "日志 ${STALE_MINUTES} 分钟没动静加上公网不通(进程卡死)"
fi
FAIL=$((FAIL + 1))
# 连接数 <= 1 也算"降级"。
#
# 原来是 == 0 才算,但实测**只剩 1 条连接时跨机房回源就会失败**
# (用户撞上的 530 就是这种:请求落 SEA,隧道只剩 LAX 一条)。
# 所以 1 和 0 一样危险,都计入降级计数。
DEGRADED=0
if [ -n "$CONNS" ] && [ "$CONNS" -le 1 ] 2>/dev/null; then
ZERO=$((ZERO + 1))
DEGRADED=1
fi
log "公网不通($DETAIL),连续第 $FAIL 次(降级 $ZERO 次)"
# 公网不通 + 连接数已经降到危险区 = **确认的故障**,不是短抖动。
# 这种情况立刻重启,不等攒够 3 次 —— 每次检查间隔 20 秒,
# 等 3 次就是白断 40 秒。
if [ "$DEGRADED" = "1" ]; then
# 宽限期内不重启 —— 让上一次重启有机会把连接建齐。
# (不加这条会死循环:隧道还没建齐就被再次打断。)
LAST_R=$(cat "$LAST_RESTART_FILE" 2>/dev/null || echo 0)
SINCE=$(( $(date +%s) - LAST_R ))
# 但要看「这次重启后建齐过没有」:
# 建齐过(>=3 条)又垮下来 = 链路本来能撑住,现在是真故障
# -> 不用再等宽限期,立刻重启
# 从没建齐过 = 它还在努力建
# -> 继续等,别打断它
if [ "${BUILT:-0}" = "1" ]; then
restart_tunnel "公网不通,且本次重启后曾建齐过连接(确认故障,立即重启)"
elif [ "$SINCE" -lt "$GRACE" ]; then
log "公网不通且只剩 ${CONNS} 条连接,但本次重启还没建齐过(${SINCE}/${GRACE} 秒)—— 继续等它建"
else
restart_tunnel "公网不通且 ${SINCE} 秒都没建齐(链路或边缘有问题,重启试试)"
fi
fi
if [ "$FAIL" -ge "$THRESHOLD" ] || [ "$ZERO" -ge "$THRESHOLD" ]; then
restart_tunnel "连续 $FAIL 次公网不通(含 $ZERO 次降级)"
fi
write_state "$ZERO" "$FAIL" "$BUILT"