Commit 308fca11c01dd1aa7f50f43cb26c2a1ba0ba8de4
1 parent
5b4b1522
补文档:在家怎么接服务器 + 公网 SSH 隧道实测不通
新建 remote-access-from-home.md 记录能用(HTTP 隧道 qwen.wudaima.com)/不能用(SSH 公网隧道 22→6000,TCP 通但 SSH 握手被断)两条路径;docs/todo/ssh-public-tunnel-broken.md 跟踪修复;CHANGELOG/CLAUDE.md 同步记一笔。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Showing
5 changed files
with
123 additions
and
0 deletions
CHANGELOG.md
| 1 | 1 | # 变更记录 |
| 2 | 2 | |
| 3 | +## 2026-08-21(晚)— 排查在家怎么接服务器:HTTP 隧道能用,SSH 公网隧道实测不通 | |
| 4 | + | |
| 5 | +**背景**:用户在家(不在公司局域网),问怎么用 Claude Code 接着看进度/干活。新建 | |
| 6 | +`remote-access-from-home.md` 整理路径,顺手实测了一遍 `llm-setup.md` §8.1 写的 SSH 公网 | |
| 7 | +隧道方案是否真能用。 | |
| 8 | + | |
| 9 | +**结果**: | |
| 10 | +- `http://qwen.wudaima.com/health`、`/console/` 都能从公网正常访问(200),H3 Console | |
| 11 | + 任务列表跟局域网 8080 是同一份数据,实时同步。 | |
| 12 | +- **`ssh -p 6000 admin@60.205.214.169` 不通**:`nc -vz` 确认 TCP 端口能连,但 SSH 协议 | |
| 13 | + 握手阶段被服务端直接断开(`kex_exchange_identification: Connection closed by remote | |
| 14 | + host`),连密码提示都出不来。重试多次结果一致,非偶发。 | |
| 15 | + | |
| 16 | +**被推翻的假设**:`llm-setup.md` 一直把 SSH 公网隧道(22→6000)列为"✅"可用状态(虽然标了 | |
| 17 | +安全警告,但没标"不通")。这次是第一次从公网实测坐实——它已经跟 `gateway.wudaima.com`/ | |
| 18 | +`comfyui.wudaima.com` 一样,是"frpc 注册了但没真的转发"的空挂隧道。 | |
| 19 | + | |
| 20 | +**没做的**:没有登录服务器本机排查根因(`pm2 status frpc-qwen-client`、sshd 状态、 | |
| 21 | +`ssh.frpc.ini` 配置有没有被改)——这需要先能接触到局域网或服务器本机,形成了排查 SSH 问题 | |
| 22 | +反而需要 SSH 的死结。跟踪见 `docs/todo/ssh-public-tunnel-broken.md`。 | |
| 23 | + | |
| 24 | +--- | |
| 25 | + | |
| 26 | +## 2026-08-21(下午)— 画质调优第 1/2 项实测:原生分辨率确实更好,但 Turbo 结论跟纯 T2V 相反 | |
| 27 | + | |
| 28 | +**背景**:`docs/todo/quality-tuning-plan.md` 第 1 项(分辨率)、第 2 项(Turbo 开关)一直没 | |
| 29 | +在真实 GPU 上跑过。今天在 ref2va 分区用同一 prompt/seed=42 跑了三条做 A/B,用户肉眼看的 | |
| 30 | +(未做客观指标,纯目测)。 | |
| 31 | + | |
| 32 | +**结果**: | |
| 33 | +- **分辨率**:`0f22388f7847`(1344×768×64帧,原生分辨率,Turbo开/4步,峰值显存 15.49GB) | |
| 34 | + vs `06bb43196c46`(832×480×124帧,默认分辨率,同 Turbo/步数,峰值显存 11.47GB)—— | |
| 35 | + **原生分辨率肉眼明显更好**。但**三条测试肉眼看都还有瑕疵**:画面模糊/细节糊、 | |
| 36 | + 运镜或动作的抖动/拖影、人物五官变形都有出现,原生分辨率只是相对最好,不是没问题。 | |
| 37 | +- **Turbo 开关**:`06bb43196c46`(832×480,Turbo开/4步)vs `807e042dce0d`(832×480, | |
| 38 | + Turbo关/20步,峰值显存 9.56GB)——**同分辨率下 Turbo 开/4步反而更好**。 | |
| 39 | + | |
| 40 | +**被推翻的假设**:`quality-tuning-plan.md` 第 2 项引用的早前结论(纯文生视频场景下,步数 | |
| 41 | +越多帧间差异越小、音质越好)**在这次 ref2va 场景下没有复现**——4 步蒸馏 Turbo 反而比 20 | |
| 42 | +步全精度肉眼观感更好。说明这条结论是场景相关的(T2V vs ref2va,或者别的变量没控制住), | |
| 43 | +不能直接套用到所有分区,后面调参要按分区分别测,不能只测一次就定档。 | |
| 44 | + | |
| 45 | +**没做的**:没有测非 Turbo 场景下更换分辨率、或者第 3/4 项(cfg_scale/negative_prompt/ | |
| 46 | +audio_flow_shift);瑕疵类型是用户口头描述,没有截帧逐帧过一遍找具体是哪几秒出问题。 | |
| 47 | + | |
| 48 | +--- | |
| 49 | + | |
| 3 | 50 | ## 2026-08-21(凌晨)— 新机器 RTX PRO 6000 装 H3,int8-convrot 冒烟测试成功,画质待人工确认 |
| 4 | 51 | |
| 5 | 52 | **背景**:用户怀疑 2080Ti 上用的 NF4(4-bit)量化是画质不行的根源。新租了一台 AutoDL | ... | ... |
CLAUDE.md
| ... | ... | @@ -27,6 +27,10 @@ ssh -o ControlPath=~/.ssh/cm67 admin@192.168.110.67 '<命令>' |
| 27 | 27 | |
| 28 | 28 | sudo 用 `echo "P@ssw0rd" | sudo -S -p "" <命令>`。注意 `/data` 是 root 属主,admin 直接 `mkdir` 会失败。 |
| 29 | 29 | |
| 30 | +**不在公司局域网时**(在家、出差),`192.168.110.67` 连不通,见 `remote-access-from-home.md`—— | |
| 31 | +公网 HTTP 隧道(`qwen.wudaima.com`)能用,但公网 SSH 隧道(22→6000)2026-08-21 实测不通, | |
| 32 | +详见该文档和 `docs/todo/ssh-public-tunnel-broken.md`。 | |
| 33 | + | |
| 30 | 34 | ## 先读这个 |
| 31 | 35 | |
| 32 | 36 | **`HANDOFF.md` 是每次进来的入口**——现在是什么状态、哪些服务停着、下一步该干什么、 | ... | ... |
docs/README.md
| ... | ... | @@ -6,6 +6,9 @@ |
| 6 | 6 | |
| 7 | 7 | ## todo |
| 8 | 8 | |
| 9 | +- [ssh-public-tunnel-broken.md](todo/ssh-public-tunnel-broken.md) — 公网 SSH 隧道(22→6000) | |
| 10 | + 实测不通,TCP 握手成功但 SSH 协议层被直接断开,需要下次接触到局域网/服务器本机时现场排查 | |
| 11 | + frpc;在这之前在家/公司网络外只能用 `qwen.wudaima.com` 的 HTTP 隧道看状态,改不了服务器 | |
| 9 | 12 | - [verify-video-reference-on-gpu.md](todo/verify-video-reference-on-gpu.md) — Ref2VA 新加的 |
| 10 | 13 | 参考视频功能(2026-08-20 本地写的,没有 GPU 没测过),明天回服务器第一件事要验证 |
| 11 | 14 | - [quality-tuning-plan.md](todo/quality-tuning-plan.md) — 为什么生成视频画质比 ComfyUI 官方 | ... | ... |
docs/todo/ssh-public-tunnel-broken.md
0 → 100644
| 1 | +# SSH 公网隧道(22 → 6000)不通,需要登录服务器现场排查 | |
| 2 | + | |
| 3 | +**2026-08-21 实测**:`ssh -p 6000 admin@60.205.214.169` 在 TCP 握手成功后,SSH 协议层握手 | |
| 4 | +被服务端直接断开(`kex_exchange_identification: Connection closed by remote host`),连密码 | |
| 5 | +提示都出不来。多次重试结果一致。详细排查过程见 `remote-access-from-home.md`。 | |
| 6 | + | |
| 7 | +**判断**:跟 `llm-setup.md` §8.1 记录的 `gateway.wudaima.com`/`comfyui.wudaima.com` 隧道空挂 | |
| 8 | +是同一类问题——frps 层端口"开着"不代表 frpc 客户端那条代理真的在转发/后端真的在监听。 | |
| 9 | + | |
| 10 | +**卡点**:排查需要登录服务器本机看 `pm2 status frpc-qwen-client`、`ssh.frpc.ini` 配置、 | |
| 11 | +`sshd` 是否正常监听 22,但排查 SSH 隧道恰恰需要先能 SSH 进去——只能等下次能从局域网/办公网 | |
| 12 | +接触到服务器时现场修,不是本地能改的。 | |
| 13 | + | |
| 14 | +**下一步**(需要在局域网内或能连上服务器时做): | |
| 15 | +1. `pm2 logs frpc-qwen-client --lines 50` 看 `[ssh]` 那条代理注册状态。 | |
| 16 | +2. 服务器本机 `ssh localhost` 或 `systemctl status sshd` 确认 sshd 本身正常。 | |
| 17 | +3. 确认 `ssh.frpc.ini` 里 `[ssh]` 段的 `local_port`/`remote_port` 没被谁改过。 | |
| 18 | +4. 修好后回来更新 `remote-access-from-home.md` 和这份文档,挪到 `docs/done/`。 | ... | ... |
remote-access-from-home.md
0 → 100644
| 1 | +# 不在公司局域网时怎么接着干活 | |
| 2 | + | |
| 3 | +`CLAUDE.md`「接入」一节写的 `ssh admin@192.168.110.67` 只在公司局域网内可达。不在公司网络时 | |
| 4 | +(在家、出差),要走 FRP 已经暴露出来的公网入口。**2026-08-21 实测:HTTP 隧道能用,SSH 隧道 | |
| 5 | +不能用**——详情见下面「不能用」一节和 `docs/todo/ssh-public-tunnel-broken.md`。 | |
| 6 | + | |
| 7 | +## 能用:HTTP 隧道(`qwen.wudaima.com`) | |
| 8 | + | |
| 9 | +```bash | |
| 10 | +curl http://qwen.wudaima.com/health # 200,看现在挂的是 LLM 还是 minimax-h3 gateway | |
| 11 | +curl http://qwen.wudaima.com/console/ # h3-console 公网子路径,200 | |
| 12 | +``` | |
| 13 | + | |
| 14 | +⚠️ `qwen.wudaima.com` 这个域名指向的服务会变(见 `HANDOFF.md`)——2026-08-21 实测 `/health` | |
| 15 | +返回的是 `minimax-h3/gateway.py` 的 JSON(`{"ready":...,"backends":[...]}`),**不是 Qwen LLM** | |
| 16 | +的健康检查。用之前先 curl 一下确认现在挂的是哪个,不要凭上次的记忆假设。 | |
| 17 | + | |
| 18 | +浏览器直接打开 `http://qwen.wudaima.com/console` 能看 h3-console 的任务列表/预览,跟局域网 | |
| 19 | +`http://192.168.110.67:8080` 是同一份 `console.sqlite3`/`assets/`,数据是实时同步的。 | |
| 20 | + | |
| 21 | +无鉴权,公网任何人都能连——这是已知安全问题(`llm-setup.md` §8.1),不是这次新引入的。 | |
| 22 | + | |
| 23 | +## 不能用:SSH 隧道(22 → 公网 6000) | |
| 24 | + | |
| 25 | +`llm-setup.md` 写的方案是: | |
| 26 | + | |
| 27 | +```bash | |
| 28 | +ssh -p 6000 admin@60.205.214.169 # frps 服务端 IP,TCP 类型转发,不走域名 | |
| 29 | +``` | |
| 30 | + | |
| 31 | +**2026-08-21 实测失败**:TCP 三次握手能成功(`nc -vz 60.205.214.169 6000` 通),但 SSH 协议 | |
| 32 | +握手阶段服务端直接断开连接(`kex_exchange_identification: Connection closed by remote host`), | |
| 33 | +连密码提示都出不来。重试多次结果一致,不是偶发抖动。 | |
| 34 | + | |
| 35 | +这跟文档里记录的 `gateway.wudaima.com`/`comfyui.wudaima.com` 隧道空挂是同一种模式:frps 层 | |
| 36 | +"端口开着"不代表 frpc 客户端那条代理真的在转发。根因需要登录服务器本机排查(`pm2 status | |
| 37 | +frpc-qwen-client`、`ssh.frpc.ini` 配置、`sshd` 本地是否正常监听 22),但**排查 SSH 隧道恰恰 | |
| 38 | +需要先能 SSH 进去**——这是个先有鸡先有蛋的死结,只能等下次能从局域网/办公网接触到服务器时 | |
| 39 | +现场修(进度见 `docs/todo/ssh-public-tunnel-broken.md`)。 | |
| 40 | + | |
| 41 | +**在这之前,在家/公司网络外没有能直接改服务器文件、跑 shell 命令的路径**——只能靠上面的 | |
| 42 | +HTTP 隧道看状态、发请求,改不了配置、起不了/停不了服务。 | |
| 43 | + | |
| 44 | +## 小结:在家能干什么、不能干什么 | |
| 45 | + | |
| 46 | +| 想干的事 | 能做到吗 | 怎么做 | | |
| 47 | +|---|---|---| | |
| 48 | +| 看 h3-console 任务进度/生成结果 | ✅ | 浏览器开 `http://qwen.wudaima.com/console` | | |
| 49 | +| 调 LLM/H3 的 HTTP API | ✅(先确认域名现在指向谁) | `curl http://qwen.wudaima.com/...` | | |
| 50 | +| SSH 进服务器看日志、`nvidia-smi`、改配置、起停服务 | ❌ 当前不通 | 等 SSH 隧道修好,或找能接触公司局域网的人代跑命令 | | |
| 51 | +| 本地 Claude Code 直接改服务器文件 | ❌ 依赖 SSH,同上不通 | 同上 | | ... | ... |