Chatbox 团队共享：用 Docker + Caddy 反向代理部署 OpenAI API 共享服务器-171主机测评

Chatbox 团队共享：用 Docker + Caddy 反向代理部署 OpenAI API 共享服务器

【免费下载链接】chatbox Powerful AI Client 项目地址: https://gitcode.com/GitHub_Trending/ch/chatbox

Chatbox 的 Team Sharing 方案让团队成员共享同一个 OpenAI API 账号的资源，同时 API KEY 只保存在服务端、从不下发给客户端。本文基于仓库内的 team-sharing/README.md 完整讲解部署流程，并结合 Dockerfile、Caddyfile 与客户端源码，说明“成员无需填写 API KEY”这一核心能力背后的实现原理。

Chatbox 设置中填入 HTTP 共享地址的截图

Chatbox 设置中填入 HTTPS 共享域名的截图

一、Team Sharing 要解决的问题

OpenAI API KEY 是计费与鉴权的唯一凭证，如果把 KEY 直接分发给团队成员，会带来两个风险：

KEY 泄露：任何一台客户端都可能被复制、截屏或转发；

用量不可控：无法统一收敛调用入口。

Chatbox 的解法是在服务端运行一个轻量反向代理（即 bensdocker/chatbox-team 镜像）：服务端持有唯一的 API KEY，团队成员的 Chatbox 客户端只需把 API Host 指向该服务器地址即可，本地无需填写任何 KEY。所有请求先到达共享服务器，再由服务器带上真实 KEY 转发给 api.openai.com。

二、工作原理：一个 Caddy 反向代理 + 两个环境变量

共享服务器的全部实现就在 team-sharing 目录下的三个文件里，先读源码再看部署命令，整个方案会更清晰。

2.1 Caddyfile：代理规则的核心

Caddyfile 全文仅 6 行：

<HOST> {
reverse_proxy https://api.openai.com {
header_up Host {http.reverse_proxy.upstream.hostport}
header_up Authorization "Bearer <KEY>"
}
}

它做了三件事：

监听 <HOST> 占位符指定的地址（HTTP 模式下为 :80，HTTPS 模式下为 <你的域名>）；
把所有请求原样反向代理到 https://api.openai.com；
重写上游请求头：
- header_up Host {http.reverse_proxy.upstream.hostport} —— 让转发到 OpenAI 的请求携带正确的 Host（即 api.openai.com），避免虚拟主机路由失败；
- header_up Authorization "Bearer <KEY>" —— 覆盖客户端发来的 Authorization 头，替换为服务端环境变量 KEY 注入的真实 API KEY。这是“客户端不填 KEY 也能调用”的关键：无论客户端发什么（甚至空值），最终到达 OpenAI 的鉴权头都由服务端决定。

2.2 main.sh：启动脚本与环境变量注入

main.sh 是容器的入口脚本，逻辑非常直白：

set -ex

if [ -z "$HOST" ]
then
HOST=":80"
fi

sed "s/<HOST>/$HOST/g" /etc/caddy/Caddyfile > /etc/caddy/Caddyfile.tmp
mv /etc/caddy/Caddyfile.tmp /etc/caddy/Caddyfile

sed "s/<KEY>/$KEY/g" /etc/caddy/Caddyfile > /etc/caddy/Caddyfile.tmp
mv /etc/caddy/Caddyfile.tmp /etc/caddy/Caddyfile

caddy run –config /etc/caddy/Caddyfile –adapter caddyfile

要点：

HOST 可选：未设置时默认为 :80，即监听 80 端口的 HTTP 模式；
KEY 必填：用 sed 把 Caddyfile 中的 <KEY> 占位符替换为真实 KEY，再交给 Caddy；
最终通过 caddy run –adapter caddyfile 启动。

2.3 Dockerfile：镜像构成

Dockerfile 基于 Caddy 官方镜像构建：

FROM caddy:2.4.6

COPY ./Caddyfile /etc/caddy/Caddyfile
COPY ./main.sh /usr/src/www/main.sh

RUN chmod +x /usr/src/www/main.sh

ENTRYPOINT ["sh", "-c", "/usr/src/www/main.sh"]

也就是说 bensdocker/chatbox-team 镜像 = Caddy 2.4.6 + 上面的 Caddyfile 与启动脚本，不含任何其他业务代码，代理行为完全透明。

三、部署实战

以下操作步骤完整继承自 team-sharing/README.md（中文版见 team-sharing/README-CN.md）。

3.1 准备一台服务器

在 AWS、Google Cloud、Digital Ocean、Vultr、Oracle Cloud 等任意云平台启动一台云服务器。

硬性前提：服务器的网络必须能正常访问 openai.com（代理的本质是转发流量，服务器不通则共享不通）。

3.2 安装 Docker 环境

登录服务器后执行官方安装脚本：

curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh

3.3 启动共享服务器（HTTP 模式）

将 <YOUR_OPENAI_KEY> 替换为你的 OpenAI API KEY，然后执行：

docker run -p 80:80 -p 443:443 \\
-v ./caddy_config:/config -v ./caddy_data:/data \\
-e KEY=<YOUR_OPENAI_KEY> \\
bensdocker/chatbox-team

示例：

docker run -p 80:80 -p 443:443 \\
-v ./caddy_config:/config -v ./caddy_data:/data \\
-e KEY=sk-xxxxxxxxxxxxxxxxxxx \\
bensdocker/chatbox-team

各参数含义：

参数说明

-p 80:80 -p 443:443	映射 HTTP/HTTPS 端口；HTTPS 模式下 Caddy 需要 80 端口完成 ACME 证书验证
-v ./caddy_config:/config	Caddy 配置持久化目录
-v ./caddy_data:/data	Caddy 数据目录（HTTPS 模式下自动申请/续期的 TLS 证书存放于此，务必挂载，否则证书会随容器丢失）
-e KEY=…	注入真实的 OpenAI API KEY，被 main.sh 写入 Caddyfile

3.4 启动共享服务器（HTTPS 模式，推荐）

如果你有域名，推荐使用 HTTPS 启动：所有对话消息在网络传输中以密文加密，隐私上更安全。

步骤：

让你的域名解析到这台服务器（并等待约五分钟生效）；

将 <YOUR_DOMAIN> 替换为你的域名；

将 <YOUR_OPENAI_KEY> 替换为你的 OpenAI API KEY；

执行命令启动服务器：

docker run -p 80:80 -p 443:443 \\
-v ./caddy_config:/config -v ./caddy_data:/data \\
-e HOST=<YOUR_DOMAIN> \\
-e KEY=<YOUR_OPENAI_KEY> \\
bensdocker/chatbox-team

示例：

docker run -p 80:80 -p 443:443 \\
-v ./caddy_config:/config -v ./caddy_data:/data \\
-e HOST=proxy.chatbox.run \\
-e KEY=sk-xxxxxxxxxxxxxxxxxx \\
bensdocker/chatbox-team

设置了 HOST 后，main.sh 会把 Caddyfile 的监听地址替换为该域名，Caddy 会自动为域名申请并续期 TLS 证书（证书保存在挂载的 ./caddy_data 卷中）。

3.5 环境变量速查表

环境变量必填默认值作用

KEY	是	无	OpenAI API KEY，注入上游 Authorization 头
HOST	否	:80	监听地址；填域名即启用 HTTPS 模式

四、客户端接入：只填 API Host，不填 API KEY

服务器启动后，把地址分享给团队成员：

HTTP 模式地址为 http://<你的服务器IP>:80；
HTTPS 模式地址为 https://<你的域名>。

成员在 Chatbox 设置的 API Host 字段中填入该地址即可（API KEY 留空），Chatbox 会自动补全 https:// 前缀。这一交互在 OpenAISetting.tsx 中实现：输入值如果不是以 http 开头且长度大于 4，会自动加上 https://。

之所以“不填 KEY 也能用”，客户端侧有两处代码可以佐证：

设置校验放行：settingActions.ts 中的 needEditSetting() 只有在“API Key 为空且 API Host 仍为默认值”时才提示必须编辑。也就是说，只要 API Host 改成了共享服务器地址（非默认值），空 KEY 就会被接受：

if (
settings.aiProvider === 'openai' &&
settings.openaiKey === '' &&
settings.apiHost === defaults.settings().apiHost
) {
return true
}

请求按 apiHost 拼接：defaults.ts 中 apiHost 默认值为 https://api.openai.com；openai.ts 的构造函数仅在 apiHost 为空白串时回落到该默认值，用户自定义的共享地址会被原样保留。发起对话时，请求 URL 为 `${this.options.apiHost}/v1/chat/completions`（见 openai.ts L70-L76），即以共享服务器为根路径直接调用 /v1/chat/completions，与 Caddyfile 中 reverse_proxy https://api.openai.com 的“任意路径透传”规则正好吻合。

客户端本地生成的 Authorization 头在 openai.ts 的 getHeaders() 中拼装（Bearer ${this.options.openaiKey}，共享场景下为空串），但这无伤大雅——服务端 Caddy 的 header_up Authorization "Bearer <KEY>" 会整体覆盖该头，最终以服务端 KEY 完成对 OpenAI 的鉴权。

五、流式响应与容错机制

共享模式下客户端的流式体验由基类保证：base.ts 中的 handleSSE() 用 eventsource-parser 逐事件解析 text/event-stream 响应（L52-L69）；post() 内置最多 3 次重试、失败间隔 500ms 的退避逻辑（L113-L150），因此即使共享服务器偶发网络抖动，客户端也会自动重试，用户侧表现为稳定的逐字输出。

六、使用边界与注意事项

从仓库实际内容看，有几点需要在使用前确认：

仅适用于 OpenAI 提供方：Caddyfile 把上游硬编码为 https://api.openai.com，因此共享的只能是 OpenAI API 资源；客户端需将 AI 提供方选择为 OpenAI，Claude、Ollama 等其他提供方不走该代理；
HTTP 模式下流量明文：对话内容在传输中不加密，README 明确推荐有域名时使用 HTTPS 模式；
KEY 权限即共享权限：所有成员共用同一账号与额度，用量、限流、内容审核均落在同一个 OpenAI 账号上，建议仅用于可信团队；
HTTPS 模式依赖域名生效：文档提示 DNS 解析后需等待约五分钟；证书自动续期依赖 ./caddy_data 卷持久化，重建容器时不要丢失该目录；
服务器网络前提：服务器必须能直接访问 openai.com，这是 README 中的明确前提。

综上，Chatbox Team Sharing 是一个“Docker 一行命令 + Caddyfile 六行规则”即可完成的最小化 API 共享代理：服务端凭 KEY 环境变量持有唯一 API KEY，客户端凭 API Host 配置接入，两者通过 Caddy 的 reverse_proxy 与请求头重写机制解耦，兼顾了接入简便性与密钥安全。

【免费下载链接】chatbox Powerful AI Client 项目地址: https://gitcode.com/GitHub_Trending/ch/chatbox

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

Chatbox 团队共享：用 Docker + Caddy 反向代理部署 OpenAI API 共享服务器