vps-management-bot/memory/2026-03-07.md

Pixel 6 恢复与启动链修复 (00:14)

• Pixel 6 SSH 凭据确认更新为 192.168.1.138:8022 root/fJ7#vP9s@tL2qX!d（旧的 root/root 作废）
• 现象：手机重启后 Telegram Bot 不回复；实测并非配置丢失，而是 OpenClaw 启动链失效
• 检查结论：~/.openclaw/openclaw.json、workspace、cron、memory、拍照/语音相关文件都还在，坏的是自启动/守护链路
• 根因1：旧启动方式失效，日志出现 ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL / spawn gateway ENOENT
• 根因2：默认模型仍指向失效的 gptclub/claude-sonnet-4-6，即使启动成功也会在回复时报 HTTP 401: API key not found
• 修复：重建 ~/watchdog.sh 与 ~/.termux/boot/start-openclaw，恢复 watchdog + 开机自启
• 修复：把 Pixel 6 默认模型改为 cliproxy/claude-sonnet-4-6，fallbacks 设为 qianfan/glm-5、cliproxy/gemini-2.5-flash、newcli/claude-opus-4-6
• 验证：进程已恢复为 watchdog.sh + openclaw-gateway，Telegram provider @dstatus123_bot 正常启动
• 教训：Termux/Android 上 OpenClaw 升级后，旧 openclaw gateway / 错误 pnpm 启动链可能失效；排障时先看 gateway.log 是否有 ENOENT: gateway

Pixel 6 Root 前置条件 (00:14)

• Pixel 6 目前 Bootloader 仍锁定，无法纯远程完成 root
• 关键卡点仍是 USB/fastboot 链路：需要可用 USB-C 数据线 + Mac 能识别设备
• Root 流程可协助，但不能跳过物理插线、进入 bootloader、解锁确认等步骤

Mac + Surge 网关限速排障结论 (00:14)

• 用户反馈：Surge 做网关时速度掉到约 80M；曾怀疑浏览器扩展/Chrome 接管
• 预检发现：系统代理指向 127.0.0.1:6152，存在 utun4 / 198.18.0.1 等 TUN/增强模式痕迹，Surge 出流量较大
• 已协助关闭 Google Chrome 以排除浏览器扩展干扰，但用户反馈问题最终是"重启光猫恢复"，不是重启 Mac 恢复
• 结论：本次更偏向光猫/上游链路状态异常（如 NAT 表/连接跟踪/拨号状态/硬件转发异常），而不是 Mac 本机或我打开了什么程序
• 经验：若"猫重启恢复、Mac 不一定恢复"，优先判断为上游设备状态问题，而非单纯 Chrome 扩展锅

News Bot 位置信息 (00:14)

• News Bot 部署在 netcup 159.195.41.188
• 目录：/opt/news-bot
• 运行方式：systemd
• Bot：@bookooobot_bot
• Mac 本地源码备份：~/.openclaw/workspace/projects/news-bot/

flux-panel 安装脚本初判 (00:14)

• 脚本地址：https://raw.githubusercontent.com/bqlpfy/flux-panel/refs/heads/main/panel_install.sh
• 初步结构：通过 Docker Compose + MySQL + Spring Boot 后端 + 前端 面板方式部署，默认前端端口 6366、后端端口 6365
• 脚本会拉 release 中的 docker-compose-v4.yml / docker-compose-v6.yml / gost.sql，并自动生成 .env
• 结论：大概率可复刻"同款可用面板"，但若要完全掌控并长期二开，还需继续确认仓库是否提供完整前后端源码，而非仅依赖预构建镜像/发布文件
• 风险：脚本会尝试自动改 Docker IPv6 配置；默认管理员账号固定，装完必须立刻改密码；整体偏黑盒部署

测试机记忆纠偏 (00:28)

• 旧记忆中的 Tarek / 155.103.66.237 只代表历史上的测试机状态，不能再默认当作当前测试机
• 本次对话中因直接引用旧记忆把 155.103.66.237 说成现测试机，用户已明确纠正：测试机已经不在这上面了
• 教训：涉及"当前在哪台机器/现在部署在哪"的信息时，旧 MEMORY 命中只能当历史线索，回答前要先确认现状，避免把历史状态说成当前状态

TG User Monitor 修复与坑点 (14:24)

• xianyu 机器 185.218.6.38 上的 tg-user-monitor 曾出现长期运行后 Telegram 连接断开但进程不退出，日志特征为 Connection lost / socket.send() raised exception
• 已添加 watchdog：/opt/tg-user-monitor/watchdog.sh，通过 cron 每分钟检查近30秒日志；若错误数过多则自动 systemctl restart tg-user-monitor
• 监控程序已修复：* 规则现在可匹配纯媒体消息（图片/视频/贴纸/语音等），无文字时会以 [图片] / [视频] 等占位内容发送提醒
• RFCHOST官方群 https://t.me/RFCHOSTOfficial 的真实群 ID 确认是 -1002699516772；需要先用用户名/链接访问一次，才能把 peer 信息预热进 pyrogram session 缓存，否则会报 CHAT_ID_INVALID / Peer id invalid
• 经验：TG userbot 监控若某个群单独失效，先区分是"连接断了"还是"peer 未缓存/未预热"；公开群可先用用户名 get_chat 预热

远程排障凭据纠偏 (14:24)

• 用户提供 23.249.27.161:2222 机器需要调优 TCP 和修复软件源，但当次连接失败；用户口头说"密码也是root"时不能推断为默认密码 fJ7#vP9s@tL2qX!d，需按字面理解为密码可能是 root 或再次确认

Kwrt/OpenWrt 软件源修复全流程 (14:53)

• 机器: 23.249.27.161:2222 root/root, Kwrt 25.12.0-rc3 (rockchip/armv8), 不是 Debian
• 根因1: 软件源被改错，指向 mirrors.cernet.edu.cn / mirrors.tuna.tsinghua.edu.cn 的 OpenWrt 25.12 路径，但这些镜像上 25.12 路径不完整/404
• 根因2: turboacc 把 BBR 关了，bbr_cca='0' 导致实际跑 cubic
• 根因3: wget 优先走 IPv6，连 cernet 镜像时 IPv6 每次超时 12 秒，多个源叠加后像卡死
• 修复步骤:
  1. 恢复 Kwrt 默认官方源: https://dl.openwrt.ai/releases/25.12/...
  2. 锁定配置文件: chmod 444 /etc/opkg/distfeeds.conf 防止被自动改回
  3. 强制 wget 走 IPv4: 创建 /usr/bin/wget wrapper 调用 wget.real -4
  4. 打开 BBR: uci set turboacc.config.bbr_cca='1'; uci commit turboacc; /etc/init.d/turboacc restart
  5. 清除 LuCI 缓存: rm -f /tmp/luci-* 让面板重新检测
• 验证: opkg update 7个源全部成功, sysctl net.ipv4.tcp_congestion_control 显示 bbr
• 教训: Kwrt/OpenWrt 定制版不能直接用标准 OpenWrt 镜像源，版本号对不上会 404；面板"软件源错误"可能是缓存/时间戳状态，后台修好后需清 /tmp/luci-* 并刷新浏览器

Mac DDNS 切换到 9929.hk (17:54)

• 原域名: mac.xmg.hk / macmini.xmg.hk (xmg.hk Zone)
• 新域名: home.9929.hk / mac.9929.hk (9929.hk Zone)
• Zone ID: b24362e71134dc220e4a29723e1fe77f
• 原因: 旧 API Token 只能管理 xmg.hk，无法管理其他域名
• 解决: 创建新 API Token (Edit zone DNS 模板 + All zones 权限)
• 脚本: /Users/jianzhang/cf_ddns_update.sh
• 清理: 删除 xmg.hk 下所有旧 DDNS 记录 (mac/macmini/home/desktop)
• 状态: 每 5 分钟自动更新，当前 IP 153.101.163.157
• 教训: Cloudflare API Token 权限是按 Zone 分配的，跨域名操作需要 All zones 权限

Koipy 迁移完整流程 (18:56)

• 源机器: Tarek (155.103.66.237) → 目标: dpnet (82.22.99.61, 通过 38.76.204.161 跳板)
• 关键文件（三个缺一不可）:
  1. 二进制文件: 从容器提取 /app/koipy (6.3MB, 2月14日版本)，不要用 Docker 镜像
  2. 配置文件: config.yaml + builtin/ 脚本目录
  3. i18n 文件: /app/resources/i18n/zh-CN.yml (自定义菜单文字，包含排序选项定义)
• 关键配置: runtime.sort: 订阅原序 (在 config.yaml 中)
• Sub-Store: 数据目录 /root/sub-store-data/ + 镜像 xream/sub-store:latest
• 部署步骤:
  1. 停止源容器，打包配置和数据
  2. 导出 Docker 镜像 (docker save)
  3. 传输到目标机器 (通过跳板机)
  4. 目标机器安装 Docker (apt install docker.io)
  5. 导入镜像，启动容器
  6. 替换二进制文件: docker cp koipy-binary 到容器 /app/koipy
  7. 复制 i18n 文件: 创建 /app/resources/i18n/ 目录，复制 zh-CN.yml
  8. 重启容器验证
• 教训:
  • Docker 镜像可能是旧版本，必须用实际运行的二进制文件
  • i18n 文件控制菜单显示，缺失会导致排序选项出现
  • 配置文件中的 sort: 订阅原序 需要配合 i18n 文件才能生效
• 最终状态: Koipy (端口 8000) + Sub-Store (端口 3001) 在 dpnet 正常运行，Bot: @speedbot01_bot

dpnet 千帆 Coding Plan 排障与配置精简 (23:41)

• dpnet (82.22.99.61) 上原来的 qianfan/glm-5 报错 401 Coding Plan API key is not allowed for non-Coding Plan requests，根因是 把 Coding Plan 专用 API Key 填到了普通千帆 /v2 provider 上
• 查文档确认：Coding Plan 正确接法必须使用 baseUrl: https://qianfan.baidubce.com/v2/coding，OpenClaw 侧模型名固定为 qianfan-code-latest；实际切到 GLM-5 需要在百度千帆控制台“订阅管理/系统配置”里切换，不是直接在 OpenClaw 里配 glm-5
• dpnet 已新增并保留 baiduqianfancodingplan provider，使用新的 Coding Plan API Key；旧 qianfan provider 已从 ~/.openclaw/openclaw.json 删除
• 进一步精简了 dpnet 的 provider，只保留：baiduqianfancodingplan、cliproxy、gptclub、siliconflow
• 已删除未继续使用的 provider：bookapi、newcli
• 精简后已强制重启 dpnet 上的 OpenClaw 进程
• 教训：Coding Plan key 只能 走 /v2/coding（或 anthropic/coding）接口，不能拿去兼容普通千帆 provider；如果模型列表里出现历史 provider，先查 ~/.openclaw/openclaw.json 的 models.providers 实际键集合再决定是否精简