NewAPI网关(部署于vm103,多处信息待确认)

LLM API 聚合网关(newapi.bianquezhiyin.cn 的后端):家族里各应用(含 WorkBuddy/agent 体系)统一从这里拿 OpenAI 兼容接口的多模型能力。

访问方式

• 对外:https://newapi.bianquezhiyin.cn(hk-yunmai 反代)
• 内网:http://100.64.0.20:3000
• 管理后台:域名下 / 页面(账号待确认)

技术架构(待确认项较多)

• 端口:监听 *:3000,ss 未显示进程名,ps top 亦无对应宿主进程 → 高度疑似跑在容器里(vm103 有自装 docker/containerd,普通用户无 docker socket 权限,采集受限)
• 推断为 NewAPI(开源 LLM 网关 Calcium-Ion/new-api):一是 hk-yunmai.json 明确记录 newapi 域名指向 100.64.0.20:3000;二是 3000 为 NewAPI 默认端口
• 数据库:NewAPI 默认 SQLite,大用量会切 MySQL/PG(本机 postgres 只有 octop 库 → 大概率 SQLite,待确认)
• 上游渠道:MiniMax(octop-usage 盯的就是 MiniMax 计划)、博查搜索、以及其他家族 agent 的 key(待确认)

数据(存储/备份情况)

• 渠道配置、令牌、日志:容器卷内(路径待确认,推测 /opt 下某目录或 docker volume)
• 无备份记录:网关里存着全家族的渠道 key 与令牌,丢了要逐个重配

使用方法

• 应用侧:base_url 填 https://newapi.bianquezhiyin.cn/v1,api_key 填网关签发的令牌
• 管理侧:网页后台管渠道/令牌/额度

维护方式(启停/日志/配置,待确认后补充)

• 疑似容器:sudo docker ps(需 root 或 docker 组)
• 日志:docker logs <容器>;数据卷:待确认

现状与风险

• 中:服务真实形态(容器名/镜像/数据卷)未核实,本条目多处"待确认",故障时排查无从下手
• 中:数据卷无备份,渠道 key/令牌集中于此
• 低:与 OCtop/看板同机,内存 2.9G 情况下再叠服务余量小

优化建议(3-6条,给可直接执行的命令)

1. 核实容器形态:sudo docker ps --format '{{.Names}}|{{.Image}}|{{.Ports}}' | grep -i -E 'new-?api|3000'
2. 找到数据卷后纳入备份:sudo tar -czf /persistent/newapi-$(date +\\%F).tar.gz <数据卷路径>(先跑一次确认大小)
3. 若确为 SQLite 单文件:加每周 cron 拷贝并保留 4 份(参照 OCtop 文档写法)
4. 建立资产记录:把容器名/镜像/卷路径/管理账号补进本知识库,消除"待确认"
5. 监控:netwatch.sh 追加 curl -fsS -m 5 http://127.0.0.1:3000/api/status >/dev/null || echo 'newapi down' >> /var/log/netwatch.log