yophon这篇文章不是教程，更像一份当前状态的整理。
最近我把这台服务器上的几个东西重新捋顺了一遍：把 new-api 放进了 1Panel 管理，把一些公网入口整理到了统一状态板里，又补了一个基于 key 的查询页，用来查额度、用量和调用明细。折腾完之后，整个结构终于从“能跑”变成了“自己过一阵子回来还能看懂”。
如果只用一句话概括现在的分工，大概就是：
-
1Panel管应用和容器 -
new-api管模型接口聚合 - 状态板管公网入口总览
这三者的关系非常清楚，但如果不单独写下来，过几周之后还是很容易忘记哪一层在负责什么。
先说 1Panel：它现在是我的运维入口
我以前更习惯直接 SSH 上来手动改配置、看容器、调 Nginx、查端口。这样做当然没问题，但有一个现实麻烦：当一台服务器上的东西逐渐变多之后，很多“本来你知道”的信息会开始分散。
比如：
- 某个容器到底是怎么起的
- 某个应用的数据目录在哪
- 某个端口是宿主机映射，还是进程直接监听
- 某个服务是 systemd 起的，还是 Docker 起的
1Panel 对我来说最直接的价值，不是“更高级”，而是它把这些信息重新放回了一个统一入口里。
现在这台机器上，new-api 就是通过 1Panel 部署和管理的。它的应用目录在 /opt/1panel/apps/new-api/new-api，生成的 docker-compose.yml、.env、数据目录和日志目录都在这一层里，路径关系非常直观。
这比“我记得当时是在某个目录里 docker run 起来的”强得多。
new-api 的位置：它是接口层，不是管理层
把 new-api 放在 1Panel 下面之后，角色划分反而更清楚了。
new-api 负责的是模型接口聚合，也就是对外提供一个 OpenAI 兼容的 API 层。它不负责“管理整台服务器”，也不负责“展示所有项目状态”，它只负责把上游模型能力统一收口成一个稳定接口。
对我来说，这种分层很重要。
因为很多时候一台服务器里的系统容易开始串味：面板想做应用管理，应用又顺手长出一点运维功能，最后任何东西都能看一点状态，也任何东西都不是最适合看状态的地方。
new-api 在这套结构里应该保持克制，它负责：
- 提供 OpenAI 兼容接口
- 处理 key、额度、调用记录这些和 API 使用直接相关的数据
- 作为模型聚合层稳定对外
但它不应该变成我的“整机首页”。
状态板为什么还要单独存在
既然已经有 1Panel，为什么我还要保留一个单独的状态板？
因为 1Panel 更像“管理后台”，而不是“公网入口地图”。
我现在的状态板更像一张整理过的公开视图，它做的不是深度运维，而是把这台机器上真正对外有意义的入口列出来。比如：
- 博客
-
Ops Console -
1Panel -
new-api - API Key Tool
- SSH / Mosh
这类页面的价值在于，它让“这台机器现在外面能看到什么”这件事，变成一眼可读的信息。
也就是说，状态板回答的问题是：
这台服务器现在到底公开了哪些东西？它们各自在哪个端口？入口是什么？大致是干什么的？
而不是：
这个容器的环境变量细节是什么？卷挂载到哪？我该怎么重建它？
后一个问题适合去 1Panel 里看，前一个问题适合放在状态板里。
现在这三层是怎么协作的
如果把当前结构画得再直白一点，大概是这样：
第一层：运维管理层
这一层是 1Panel。
它负责：
- 管理 Docker 应用
- 保存应用配置和部署信息
- 提供统一的可视化运维入口
第二层：业务接口层
这一层是 new-api。
它负责：
- 暴露 OpenAI 兼容接口
- 处理 key、用量、日志等 API 维度的数据
- 作为 AI 接口网关对外提供能力
第三层：展示与入口层
这一层是我自己的状态板和查询页。
它们负责：
- 把公网项目整理成一个总览
- 给使用者一个更轻的访问入口
- 在不暴露过多内部细节的前提下，展示当前服务状态
这个分层让我很舒服的一点是：每一层都知道自己不该做什么。
1Panel 不用负责当博客首页，new-api 不用负责当服务器目录，状态板也不去承担完整运维后台的角色。
顺手补出来的 API Key Tool，其实正好说明了这个结构是有效的
这次一起补出来的还有一个 API Key Tool，它本质上是个很轻的查询页。
它的作用很简单：
-
输入一个
key - 查询余额和用量
- 查询对应的调用明细
这里有个有意思的地方。
new-api 的文档里把某个日志接口写成了“可直接通过 key 查询”，但实际跑起来的版本里，这个接口仍然要求 Authorization 头。最后我的处理方式不是去把整个系统重新设计一遍，而是在入口层做了一个兼容。
也就是说：
-
new-api继续保持原本的接口逻辑 - 查询页继续保持“用户只输入 key”的使用体验
- 中间通过同源反代把请求补齐
这就是我越来越喜欢“分层清楚”的原因。一个问题不一定要在最底层解决，只要边界足够清楚，你可以在合适的层做最小代价修正。
我现在对这台服务器的要求，其实已经不是“功能越多越好”
折腾到这个阶段之后，我对服务器的期待反而变简单了。
我不太需要一个什么都想做的大一统系统，我更需要：
- 每个服务职责清楚
- 公网入口容易回忆
- 出问题时知道先去哪一层排查
- 过一个月回来还能快速恢复上下文
所以现在这套结构里，我最满意的不是某个单点功能，而是它终于开始有秩序了。
1Panel 负责管理，new-api 负责接口，状态板负责总览，查询页负责具体使用场景。这种组织方式未必最花哨，但足够稳，也足够适合一台长期运行、会持续加东西的私人服务器。
最后
很多自托管项目最容易出现的问题，不是装不上，也不是跑不起来，而是半年后你已经不记得它为什么要以现在这个样子存在。
所以写这篇文章，本质上也是给未来的自己留一个说明书：
这台服务器不是随便堆起来的。
至少在现在这个时间点，它已经有了比较明确的结构：
-
1Panel是运维入口 -
new-api是 AI 接口层 - 状态板是公网项目目录
-
查询页是围绕
new-api补出来的具体工具
以后再往里面继续加东西，最好也尽量别把这个边界重新搞乱。