很多支持 OpenAI 接口格式的聊天前端、机器人和自动化脚本，都默认连接 /v1/chat/completions。但 ChatGPT 网页版使用的是产品会话、账号令牌和内部接口，两者的授权体系、请求协议与稳定性并不相同。Chat2API 尝试在两者之间加入一层协议适配：接收接近 OpenAI Chat Completions 的请求，转换成 ChatGPT Web 会话请求，再把响应整理为下游熟悉的格式。
它不是 OpenAI 官方 API 的自托管实现，也不会把 ChatGPT 订阅自动变成获得官方许可的 API 配额。项目使用 ChatGPT Web 的非公开接口和 AccessToken、RefreshToken 等会话凭据，可能随上游页面、验证机制、模型权限或服务条款变化而失效。部署前应确认账号与数据的使用授权，并接受封号、限流、服务中断和兼容性变化的风险。
截至 2026 年 8 月 13 日，GitHub API 快照显示该仓库约有 3776 个 Star、727 个 Fork 和 41 个未关闭 Issue，主要语言为 Python，采用 MIT 许可证。仓库没有 GitHub Release；主分支文件 version.txt 标记为 1.8.8-beta2，本文核对的提交为 a63a90c。这些数据只是写作时快照，不代表项目仍与当前 ChatGPT Web 完全兼容。
Chat2API 是什么？
Chat2API 是一个基于 FastAPI 的 ChatGPT Web 反向代理与协议转换服务。默认核心入口是 POST /v1/chat/completions；如果设置 API_PREFIX，路径会变成 /{prefix}/v1/chat/completions。客户端通过 Bearer Token 提交模型、消息、流式开关等参数，服务端选择账号凭据，调用 ChatGPT Web 的 /backend-api 或匿名 /backend-anon 会话接口，然后把网页端事件流转换为 Chat Completions 风格响应。
项目还可以启用“官网镜像”网关。此模式代理 ChatGPT 网页所需的登录、会话、GPTs 和部分后台路由，并使用 SeedToken 将不同访问者绑定到后台账号。它与单纯的 API 转换是两种功能面：只需要兼容接口时没有必要开启网页镜像；开启后路由和敏感数据暴露面都会明显扩大。
它与官方 OpenAI API 的区别
OpenAI 官方 API 使用平台 API Key、官方公开端点、API 账单和对应服务条款。Chat2API 则复用 ChatGPT 产品账号的网页会话能力。即使请求和响应看起来相似，下列差异仍然存在：
- 凭据不同：输入可能是 ChatGPT AccessToken、RefreshToken、Team 工作区 ID，或由部署者自定义的池化授权码，而不是官方 API Key。
- 上游不同：请求最终进入 ChatGPT Web 的内部接口，并依赖网页端工作量证明、Sentinel、Turnstile、浏览器指纹和模型命名。
- 计费与配额不同：可用模型和次数由 ChatGPT 账号、套餐、地区和动态风控决定，不等同于 API 平台额度。
- 兼容并非等价：项目主要实现 Chat Completions 形态；错误结构、Token 统计、工具行为、文件生命周期和模型细节可能与官方 API 不一致。
- 稳定性边界不同：网页内部协议可以在没有版本承诺的情况下变化，导致突然出现 401、403、429 或解析失败。
因此，更准确的表述是“OpenAI 格式兼容层”，而不是“免费官方 API”或“ChatGPT 订阅转官方 API”。技术可调用不代表 OpenAI 授权自动化、共享、转售或绕过限制。
一次请求如何流转
- 接收请求：FastAPI 读取 Bearer Token 和 JSON 请求体，支持流式与非流式结果。
- 选择凭据：如果 Bearer 值匹配部署者配置的
AUTHORIZATION，服务从本地 Token 池随机或顺序选择账号；否则把传入值视为上游凭据。 - 刷新令牌：源码用长度和前缀判断凭据类型，必要时把 RefreshToken 换成 AccessToken，并把刷新结果缓存在数据目录。
- 确定模型：模型名被映射到网页端模型标识；GPTs 模型名还会转换为 Gizmo 会话模式。
- 完成网页校验：服务获取 ChatGPT 的 chat requirements，计算工作量证明，并处理可能出现的验证 Token。
- 转换消息：OpenAI 风格 messages 被整理为网页会话消息；图片或文件会先拉取并上传到上游文件服务。
- 转发与格式化：服务请求 ChatGPT 的 conversation 端点，将事件流整理为下游流式分片，或聚合成非流式 JSON。
- 失败重试：达到配置的重试次数前可重新执行请求；使用池化授权码时，重试可能选到另一个 Token。
这条链路比普通反向代理更复杂。只要指纹、工作量证明、模型映射、上传协议或响应事件任一环节变化，兼容性就可能受到影响。
主要功能
流式与非流式 Chat Completions
客户端可以通过 stream 控制 SSE 流式输出或等待完整 JSON。项目会把网页端会话事件转换为接近 OpenAI 的分片，并在非流式模式下聚合内容、结束原因和估算 Token。由于 Token 数量由本地 tiktoken 估算，不能把它当作官方 API 账单。
模型映射与 GPTs
当前快照包含 GPT-3.5、GPT-4、GPT-4o、GPT-4o-mini、o1 和 o3-mini 等名称映射，并可通过包含 gizmo 或 g- 的模型名进入 GPTs 模式。源码对无法识别的名称可能回退到 gpt-4o，因此客户端模型名拼错时未必立即报错。实际可用模型最终取决于账号权限和上游当前行为，README 中的历史型号不能视为长期清单。
多账号池、轮询与重试
Token 可以保存在 data/token.txt。当客户端使用 AUTHORIZATION 中的自定义授权码时，服务会从可用 Token 集合随机选择；关闭 RANDOM_TOKEN 后则顺序轮询。刷新失败的凭据被记录到错误列表，后续选择时排除。该实现适合小规模实验，但本地文本与 JSON 文件没有数据库事务、细粒度权限和成熟的多实例一致性，不应直接等同于生产账号管理平台。
AccessToken、RefreshToken 与 Team 工作区
请求可携带 AccessToken 或 RefreshToken。Team 场景可以额外传入 ChatGPT-Account-ID 请求头，也可以把工作区 ID 与 Token 组合传入。项目还可定时刷新池中的 RefreshToken，刷新缓存写入 data/refresh_map.json。这些文件相当于账号控制权，必须加密备份、最小化读权限，并避免被容器日志、监控或支持工单收集。
图片、文件和 URL 输入
消息转换支持图片与多种文档类型。内容可以来自 URL 或 Data URL，服务判断 MIME 类型、读取图片尺寸，再获取上游上传地址。配置 UPLOAD_BY_URL 后还会从提示词中解析 URL。此能力会让服务器主动访问外部地址，生产使用必须增加域名白名单、DNS 与重定向复核、私有地址拦截、大小限制和超时，否则可能形成 SSRF、内网探测或大文件资源耗尽。
ChatGPT 网页镜像
设置 ENABLE_GATEWAY=true 后，服务加载登录、GPTs、会话、后台 API 和静态页面相关路由。AUTO_SEED 可为 SeedToken 随机绑定后台账号，并保存会话映射。镜像模式能保留部分 Web 独有能力，但也会代理更广的敏感接口；README 明确提醒开启后别人可通过域名访问网关，因此它不应直接暴露在无认证公网。
技术架构与数据存储
项目运行在 Python 3.11，Web 层使用 FastAPI 和 Uvicorn，HTTP 客户端依赖 curl_cffi 模拟浏览器特征，流式连接使用 WebSockets/SSE 相关组件。Jinja2 提供 Token 管理和登录页面，APScheduler 负责定时刷新，Pillow 处理图片信息，DiskCache 与若干 JSON 文件保存运行状态。
默认数据目录挂载为 /app/data，其中可能包含 Token、RefreshToken 到 AccessToken 的映射、错误 Token、指纹、SeedToken 和会话 ID。部署迁移时要备份这些数据，但不能把它们提交到 Git 或放进公开对象存储。多容器同时写同一目录也可能产生竞争，项目的文件式状态更适合单实例。
Docker 部署
最简单的验证方式是运行官方镜像并持久化数据目录。下面示例只绑定本机回环地址，避免在完成认证和反向代理配置前直接开放 5005 端口：
mkdir -p chat2api/data
cd chat2api
docker run -d \
--name chat2api \
--restart unless-stopped \
-p 127.0.0.1:5005:5005 \
-v "$PWD/data:/app/data" \
-e TZ=Asia/Shanghai \
-e API_PREFIX=replace-with-a-long-random-prefix \
-e AUTHORIZATION=replace-with-a-long-random-client-secret \
lanqian528/chat2api:latest
docker logs --tail=100 chat2api生产环境不宜永久追随 latest，因为上游适配变化可能引入回归。应固定经过验证的镜像摘要或自行从审核过的提交构建，并保留可回滚版本。官方 Compose 还包含 Watchtower 自动更新和可选 WARP 容器；自动更新会绕过变更审批，而 WARP 容器需要 TUN 设备及 NET_ADMIN 等额外权限，采用前必须单独评估。
源码部署则执行 pip install -r requirements.txt 后运行 python app.py。依赖文件并未全部固定版本，重复构建可能得到不同依赖组合，较严谨的环境应生成锁文件、扫描依赖并在预发布环境回归。
接口调用示例
在已经合法配置账号池，并把自定义授权码保存到客户端密钥系统后，可以这样调用：
curl http://127.0.0.1:5005/replace-with-a-long-random-prefix/v1/chat/completions \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer YOUR_PRIVATE_GATEWAY_KEY' \
-d '{
"model": "gpt-4o-mini",
"messages": [
{"role": "user", "content": "用三句话解释事件流。"}
],
"stream": true
}'不要把真实 AccessToken、RefreshToken 或池化授权码写进脚本仓库、命令历史、截图和浏览器前端。对于普通客户端，优先只发放部署者自定义的网关凭据，让上游账号 Token 留在服务器端。
关键环境变量
API_PREFIX：给 API 与 Token 管理路由增加路径前缀。它只能减少路径被扫描的概率，不是成熟鉴权机制。AUTHORIZATION：逗号分隔的自定义网关授权码。客户端使用其中一个值时，服务从后台 Token 池选择账号。CHATGPT_BASE_URL：ChatGPT 上游或自建兼容网关地址，支持多个值。PROXY_URL：上游请求代理列表；代理经营者可能看到连接元数据，必须可信。EXPORT_PROXY_URL：下载用户提供的图片或文件时使用的出口代理。HISTORY_DISABLED：控制网页端历史记录，默认关闭历史保存。RETRY_TIMES：失败重试次数。非幂等对话可能被重复提交，应保持克制。ENABLE_LIMIT：遵守项目维护的账号次数限制，默认开启。SCHEDULED_REFRESH：启用池中 RefreshToken 的定时刷新。RANDOM_TOKEN：随机选择账号；关闭后顺序轮询。ENABLE_GATEWAY：启用 ChatGPT 网页镜像，默认关闭。
必须注意的安全问题
Token 管理端点需要额外保护
在本文核对的 1.8.8-beta2 源码中，/tokens、/tokens/upload、/tokens/clear、/tokens/error 和 /tokens/add/{token} 没有独立的 Bearer 鉴权依赖。API_PREFIX 只是路径组成部分，而且 tokens/add 还把 Token 放在 URL 中，可能进入访问日志和代理记录。部署者应在应用外层使用 VPN、反向代理认证、IP 白名单或防火墙完全限制这些路径；更稳妥的做法是修改源码，为管理操作增加强认证和 CSRF 防护。
当前日志可能泄露凭据
配置模块会打印 AUTHORIZATION、AUTH_KEY 和代理列表，聊天服务会记录请求 Token，RefreshToken 刷新逻辑甚至会记录获得的 AccessToken。这意味着默认日志不能进入普通可检索平台。上线前应删除或脱敏这些日志语句，轮换曾经暴露的凭据，并限制容器日志、错误采集和备份的访问者。
CORS 与公网暴露
应用默认允许任意来源、方法和请求头。宽松 CORS 不会替代服务器鉴权，而且会扩大浏览器环境中的误用面。生产环境应限制可信 Origin，将服务放在 TLS 反向代理之后，对 API、管理页和网关镜像分别设置认证、速率限制、请求体大小与访问日志脱敏。
重试、账号关联与风控
多账号轮询不能消除上游限制。频繁切换账号、代理和浏览器指纹，或集中发送高度相似请求，仍可能触发关联风控。重试还可能让同一用户消息重复生成，产生多个网页会话。应限制单用户并发、设置总超时与熔断，在响应开始后避免自动重放。
合规、隐私与授权边界
Chat2API 的 MIT 许可证允许使用、修改和分发项目代码，但只覆盖仓库代码版权，不授予 ChatGPT 账号、模型、商标或上游内部接口的使用权。部署者仍需遵守 OpenAI 的服务条款、账号套餐规则和所在地法律。不要以项目开源为依据运营未获授权的共享、代充、转售或绕限服务。
经过服务的提示词、附件和返回内容会发送给实际上游，也可能被代理、服务器日志和本地会话文件接触。涉及源代码、客户资料、个人信息或商业秘密时，应完成数据流梳理、告知与授权，设置保留期限并提供删除机制。不要向不可信的公共 Chat2API 实例提交任何敏感内容或账号 Token。
优势与局限
优势：项目规模较小，FastAPI 结构直接；提供常见 Chat Completions 入口、流式输出、多账号选择、令牌刷新、文件上传和可选网页镜像；Docker 单容器便于研究 ChatGPT Web 协议适配，也容易接入已有兼容客户端。
局限：核心依赖非公开网页接口和反自动化校验；主分支标记为 beta 且没有正式 Release；模型清单容易过时；文件式凭据存储不适合复杂多实例；默认管理路由和日志存在明显安全隐患；格式兼容不能保证行为、计费和 SLA 与官方 API 一致。
适合谁使用？
Chat2API 更适合在隔离测试环境中研究网页会话协议、验证 OpenAI 兼容客户端，或由有能力持续审计源码的开发者进行小规模内部实验。推荐从单个专用测试账号、回环地址和短期数据开始，先观察上游错误、日志和凭据生命周期。
需要长期稳定 SLA、企业数据保护、清晰费用归属、官方支持或公开商业服务时，优先使用 OpenAI 官方 API 或经过正式授权的供应商。没有能力维护上游适配、日志脱敏、凭据轮换和网络安全的团队，也不适合直接部署该项目。
总结
Chat2API 的核心价值是把 ChatGPT Web 会话协议转换成许多现有工具能够调用的 Chat Completions 形态，并围绕它补充 Token 池、重试、文件上传和网页镜像。作为学习项目，它清楚展示了兼容层需要处理的模型映射、消息格式、工作量证明和事件流转换。
但真正的部署门槛不在于启动容器，而在于授权和安全。它不是官方 API，不能创造官方配额，也不能消除服务条款与封号风险。若要测试，应固定源码快照、限制在受控网络、修复管理鉴权与日志泄露、只使用有权使用的账号，并随时准备在上游协议变化后停用或回滚。
