在构建 AI 集成环境的过程中，我们经常会遇到两个终极挑战：API 协议的转换与不可逾越的网络环境。最近在服务器上部署 cliproxyapi 和 newapi 时，我经历了一场从“镜像拉不动”到“链路全打通”的实战。

一、 核心组件简介

• CliProxyAPI：反向代理openai网页，是打通生态的关键桥梁。
• NewAPI：强大的 API 分发与管理面板，支持多模型集成、额度控制及渠道调度。
• Mihomo (Clash.Meta)：在网络受限环境下，为服务器提供稳定、灵活的出海流量调度。

---

二、 第一道坎：网络幽灵与 Mihomo 的救场

在尝试拉取 cliproxyapi 的 Docker 镜像时，最让人头疼的莫过于 docker pull 进度条纹丝不动。

1. 为什么选择 Mihomo？

相比于传统的代理方式，Mihomo 拥有更强的内核支持和分流策略。在服务器上，我们通过它建立一个本地代理通道，解决 Docker 镜像拉取及后续 API 访问海外节点的网络问题。

2. 实操避坑

为了让 Docker 走代理，我并没有修改全局环境，而是通过配置 Docker 服务的环境变量来实现：

Bash

# 创建 Docker 配置目录
mkdir -p /etc/systemd/system/docker.service.d

# 配置代理（假设 Mihomo 监听在 7890 端口）
cat <<EOF > /etc/systemd/system/docker.service.d/proxy.conf
[Service]
Environment="HTTP_PROXY=http://127.0.0.1:7890"
Environment="HTTPS_PROXY=http://127.0.0.1:7890"
EOF

# 重载配置并重启
systemctl daemon-reload
systemctl restart docker

---

三、 部署双子星：CliProxyAPI & NewAPI

解决网络问题后，后续的部署逻辑就非常清晰了。我建议使用 docker-compose 进行统一管理。

1. 部署 CliProxyAPI

主要负责将特定的 API 转义，配置时重点在于 API_KEY 的映射和端口的开放。

2. 部署 NewAPI

NewAPI 作为总控制台，负责接入刚才部署好的 CliProxyAPI 节点。

架构思路：

1. CliProxyAPI 负责“干活”（请求海外模型）。
2. NewAPI 负责“管钱”（渠道分发、日志记录、多用户管理）。
3. Mihomo 负责“铺路”（确保所有请求能顺利到达目标服务器）。

---

四、 避坑指南与经验总结

在整个过程中，有几个细节最值得关注：

• 端口冲突：Mihomo、NewAPI 和 CliProxyAPI 都有默认端口，部署前务必检查 netstat -tulnp，避免端口占用。
• 容器间通信：在 Docker 网络中，NewAPI 填写渠道地址时，可以直接使用 http://cliproxyapi:port（容器名），前提是它们在同一个 Docker network 下。
• 安全加固：暴露在公网的 NewAPI 务必第一时间修改默认密码，并建议配合 Nginx 反向代理开启 HTTPS。

五、 结语

技术折腾的乐趣往往就在于此：遇到网络封锁时，寻找像 Mihomo 这样的破局工具；遇到协议不通时，利用 CliProxyAPI 进行转换。最后通过 NewAPI 将一切归于秩序。

这一套组合拳打下来，不仅解决了一次部署问题，更是一次对 Linux 网络和 API 架构的深度梳理。