25 lines
2.9 KiB
Markdown
25 lines
2.9 KiB
Markdown
|
||
## Koipy1 / Snell 排查
|
||
- 2026-03-12 晚间实查 `103.73.220.84:22`（Koipy1 / HKTL）：SSH、22 端口、ping 都正常，`~/.ssh/koipy_key` 可直接登录。
|
||
- 用户反馈“Snell 访问 8.8.8.8 不通”后排查确认：服务器本机 `ping 8.8.8.8` 正常，不是整机出网断。
|
||
- 该机 Snell 服务正常运行：`snell-server.service` 为 active，监听 `*:2345`（TCP/UDP），进程 `/usr/local/bin/snell-server -c /etc/snell/config.conf`。
|
||
- `/etc/resolv.conf` 已经包含 `options use-vc`，同时 nameserver 为 `1.1.1.1` / `8.8.8.8`，说明“加 use-vc”这一步早已做过，不是当前根因。
|
||
- Snell 配置 `/etc/snell/config.conf`：`listen = ::0:2345`、`ipv6 = false`、`obfs = off`、`version = 5`、`dns = 1.1.1.1, 8.8.8.8, 2001:4860:4860::8888`。
|
||
- Snell 日志持续出现 DNS 相关告警：`DNS error: ... Timeout while contacting DNS servers` / `Could not contact DNS servers`，还夹杂少量 `Outgoing socket read error ETIMEDOUT` 与目标连接超时/重置。
|
||
- 判断：Koipy1 的问题更像是 **Snell 侧 DNS 解析不稳定**，不是 `103.73.220.84` 宿主机 SSH/22 端口不通，也不是单纯没加 `options use-vc`。
|
||
|
||
## Emby / 布鲁伊定位
|
||
- 2026-03-12 晚间实查 OVH KS2 Emby（`145.239.143.92`，API `http://127.0.0.1:8096`）确认：`布鲁伊` 系列条目仍在，系列 ID 为 `1548`，不是丢失或移库。
|
||
- `1548` 的 Ancestors 返回显示其祖先库就是 `动画`（库 ID `4`，路径 `/media/动画`），对应磁盘目录仍为 `/data/media/动画/Bluey(2018)`。
|
||
- 动画库当前默认列表共 `11` 个系列，`布鲁伊` 排在第 `10` 个；用户觉得“以前这里面可以看到”，根因是海报墙当前排序/展示位置靠后，不是资源消失。
|
||
|
||
## Bero / vps-snapshot 定时规则
|
||
- 2026-03-12 晚间实查 Bero（`45.82.120.52`）root crontab 仍为：`0 3 */3 * * /root/vps-snapshot.sh snapshot-sync # vps-snapshot`。
|
||
- 该表达式在 day-of-month 位表示每月按日期 `1/4/7/10/13/...` 执行，不是“每隔 72 小时”也不是“每天一次”；因此 3 月 12 日没有跑属预期，不是备份故障。
|
||
- 当时主机 cron 服务正常、`/root/vps-snapshot.sh` 与 `/etc/vps-snapshot.conf` 存在，日志中 3 月 12 日 03:00 附近没有这条任务执行记录，与 cron 不匹配结论一致。
|
||
|
||
## N100 / Telegram 私聊不稳定
|
||
- 2026-03-12 22:51 左右用户反馈 N100 “私聊没反应”，实查 `157.254.53.55:22288` 上 OpenClaw 仍正常运行：`openclaw status` 正常，Telegram 配置为 `dmPolicy: allowlist`、`allowFrom: ["165067365"]`，不是私聊白名单丢失。
|
||
- 同时日志里可见模型侧错误：`[agent/embedded] embedded run agent end ... isError=true error=An unknown error occurred`；随后用户反馈“恢复了”。
|
||
- 综合判断：N100 私聊问题更像临时链路/模型抖动，不是永久性配置损坏；默认模型仍是 `baiduqianfancodingplan/qianfan-code-latest`，稳定性依旧可疑。
|