Dell 离线恢复 Runbook（frpc 隧道断 → 全站 502）

触发场景：ssh dell 报 channel 0: open failed: connect failed: Connection refused， 且公网 /api/r/health、/api/py/health 返回 502，但 biof3.com 静态站正常。

根因：Dell 侧 frpc 客户端掉线 → ECS 上 frps 失去所有隧道（ssh 6022 + r-compute 3001 + py-compute 3002）→ 算力面整体对公网不可用，且 ssh 走同一隧道所以远程进不去 Dell。

首次记录：2026-06-07。本 runbook 按当次实测诊断写成。

---

0. 一句话恢复路径

让 Dell 的 frpc 重新连上 ECS frps，隧道一回来，502 消失 / Copilot 周边路由恢复 / /api/r /api/py 全部自动复原——一个动作解决全部。

难点是 frpc 断了 ssh 也进不去，必须用带外通道接触 Dell。

---

1. 先确认故障范围（本机，30 秒）

# 静态站应 200，算力面应 502
curl -sI https://biof3.com/ | head -1
curl -s -o /dev/null -w "r:%{http_code}\n"  --max-time 8 https://biof3.com/api/r/health
curl -s -o /dev/null -w "py:%{http_code}\n" --max-time 8 https://biof3.com/api/py/health

# ECS 跳板可达？frps 活着但隧道端口没了？
ssh -o ConnectTimeout=8 aliyun 'ss -tlnp | grep -E ":7000|:6022|:3001|:3002"'

判读：

• 只看到 :7000（frps 本体）、没有 6022/3001/3002 → 确认 Dell frpc 断了（本 runbook 适用）。
• 6022/3001/3002 在但仍 502 → 不是 frpc 问题，是 Dell 上 r-server/py-server 进程挂了 → 跳到 §4。

---

2. 接触 Dell（带外，按可行性从快到慢）

方式	命令 / 操作	前提
A. 物理 / VNC / 向日葵	直接在 Dell 上开终端	人在机器旁 or 有远程桌面
B. 局域网直连	ssh dell_local（192.168.1.12:22）	你在 Dell 同一局域网
C. 公网应急	ssh dell-direct（47.110.228.168:6022）	ECS 防火墙白名单开放了 6022（当前默认关）

实测（2026-06-07）：B 报 kex_exchange_identification: Connection closed（多半当时不在 Dell 局域网），C 被 ECS 防火墙挡。当时只有 A 可行。

---

3. 在 Dell 上重启 frpc（接触到之后）

# 先确认身份，别连错机器
hostname && uptime

# frpc 由 systemd 管理（见 infrastructure.md）
systemctl status frpc --no-pager
systemctl restart frpc
systemctl status frpc --no-pager | head -15

# 看 frpc 日志确认隧道建立（connect to server success / start proxy success）
journalctl -u frpc -n 30 --no-pager

如果 frpc 起不来：

• 配置在 /etc/frp/frpc.toml（token 见 .biof3-secrets 的 FRP_TOKEN）。
• 确认 frps 端（ECS）token 一致、7000 端口可达：在 Dell 上 curl -v telnet://47.110.228.168:7000 看能否连通。

---

4. 确认 Dell 上算力进程在跑（frpc 起来后顺手查）

pm2 list | grep -E "biof3"            # 期望 r-server:3001 / r-worker / py-server:3002 / py-worker 都 online
ss -tlnp | grep -E ":3001|:3002"
docker ps --format '{{.Names}}\t{{.Status}}' | grep -E "omichub|biof3"  # R/Py 容器

# 本机直测（不经隧道）
curl -s --max-time 5 http://127.0.0.1:3001/api/health
curl -s --max-time 5 http://127.0.0.1:3002/api/health

进程没起就：pm2 restart biof3-r-server biof3-py-server biof3-r-worker biof3-py-worker （或仓库脚本 scripts/start-dell-r-compute.sh）。

---

5. 隧道回来后，从本机验证全站恢复

# ECS 上隧道端口应重新出现
ssh aliyun 'ss -tlnp | grep -E ":6022|:3001|:3002"'
# ECS 经隧道测 Dell
ssh aliyun 'curl -sf --max-time 3 http://127.0.0.1:3001/api/health && echo dell-frp-ok || echo dell-frp-fail'

# ssh dell 应恢复
ssh -o ConnectTimeout=8 dell 'hostname'

# 公网全绿
curl -s https://biof3.com/api/r/health;  echo
curl -s https://biof3.com/api/py/health; echo
curl -s -o /dev/null -w "%{http_code}\n" -X POST https://biof3.com/api/r/run \
  -H 'Content-Type: application/json' -H 'X-API-Token: biof3-figcode-2026' \
  -d '{"code":"1+1"}'   # 期望 200 + stdout，非 compute_on_dell

# Copilot 周边（这次 502 的几条，应恢复）
curl -s https://biof3.com/api/platform/public/guest-permissions | head -c 120; echo

若 /api/r/run 返回 compute_on_dell 或 503 → 跑 scripts/fix-r-compute-upstream.sh（Dell 健康则把 /api/r/ 指回 frp）。

---

6. 恢复稳定后：回到 P1 收尾（本次主线）

生产稳定 + Dell 在线后，继续"控制面迁回 ECS"的 P1，目的就是让下次 Dell 挂掉时 Copilot 能独立存活：

1. 部署本地已改的 6 个路由（ai-memory/misc/review/plans/report/progress，已本地验证 PG 兼容）
   • 走 ..r-server-remote/ 镜像合并流程，不直接 cp（见 lessons-learned 2026-05-24 server-side patch 教训）
2. ECS 上 smoke：test/smoke-platform-split.mjs（带 BIOF3_SMOKE_USER/PASS），确认登录用户调 facts/plans/progress/memory 拿到真实数据
3. 迁 admin/analytics/public 路由：把 analytics.js/ai-admin.js 也改成 getSqliteForLegacyModules() 句柄（当前仍用原始连接），然后把 nginx 这 3 条从 3001(Dell) 切到 3011(ECS)
4. 删 nginx 的 Dell 例外（D6）+ Dell 降 worker（D7）：见 PLATFORM-ECS-CUTover-CHECKLIST.md
5. 全绿后更新 progress.md + 推飞书里程碑

---

7. 防复发（事后改进，非紧急）

• frpc 掉线告警：ECS 上加 cron 探活 127.0.0.1:3001，连续失败 N 次推飞书（现在是用户/你发现才知道）。
• frpc 自愈：确认 Dell 的 frpc systemd unit 有 Restart=always + RestartSec；若进程在但隧道断，加 watchdog 脚本定期 systemctl restart frpc。
• 带外通道常备：确保 dell_local（局域网）或某种远程桌面长期可用——本次故障暴露了"frpc 断 = ssh 也断"的单点。
• 把本 runbook 链接进 infrastructure.md 的"灾难恢复"段。