109 lines
9.2 KiB
Markdown
109 lines
9.2 KiB
Markdown
## 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` 实际键集合再决定是否精简
|