Hugging Face's logo

Spaces:
ohmyapi
/
c2api
Paused

App Files Community
c2api / README.md
ohmyapi's picture
ohmyapi
Redirect Space root to admin login and refresh README
52dad07 verified
preview code
|
raw
history blame
7.3 kB
metadata 
title: Claude2API
emoji: 🔁
colorFrom: purple
colorTo: indigo
sdk: docker
app_port: 7860
pinned: false

Claude2API — Hugging Face Space 说明

当前 Space：https://ohmyapi-c2api.hf.space

这是一个基于 pushzx/claude2api:latest 的 Hugging Face Docker Space 包装层。它的目标很克制：

  • 让根路径 / 直接进入管理登录页 /admin/login
  • 保持 /admin、/health、/v1/* 等能力继续由上游 claude2api 提供
  • 不在 wrapper 层伪造持久化配置语义

当前访问行为

当前 Space 是 public Space，不是 private Space。

这意味着：

  • Hugging Face 本身不会先拦住外部访问者
  • 任何人都可以直接访问 https://ohmyapi-c2api.hf.space/
  • 当前根路径会被 wrapper 直接 302 到 /admin/login
  • API 是否需要鉴权，取决于上游 claude2api 是否读取到了 CLAUDE_API_KEY

当前线上已验证：

  • / → 302 /admin/login
  • /admin/login 可正常打开
  • /health 返回 200
  • /v1/models 可正常访问
  • /v1/messages 未带正确 token 时返回 401 Invalid API key
  • 带正确 app token 时，claude-sonnet-4-6 已成功完成一次实际调用

为什么 Hugging Face 环境变量能直接生效

因为当前 Space 使用的是 Docker SDK。

Hugging Face 对 Docker Space 的处理方式不是“把变量写进仓库文件”，而是在容器启动时把 Space Settings 里的：

  • Variables
  • Secrets

作为真实的运行时环境变量注入到容器进程里。

对这个仓库来说，等价于容器启动时直接拿到了例如：

ADMIN_USER=admin
LISTEN_ADDR=:7860
CLAUDE_API_KEY=...
ADMIN_PASS=...
CLAUDE_SESSION_KEYS=...

所以只要上游 claude2api 在启动时是通过 os.Getenv(...) 之类的方式读配置，它就会直接生效，不需要额外写入 .env、config.yaml 或别的文件。

当前已确认的 Space Variables

当前公开可读到的 Variables 是：

LISTEN_ADDR=:7860
ADMIN_USER=admin

Secrets 不会被 Hugging Face API 直接回显，但从线上行为可以确认至少存在并已生效：

  • CLAUDE_API_KEY：因为未带 token 调用 /v1/messages 会返回 401 Invalid API key
  • CLAUDE_SESSION_KEYS：因为模型已能实际完成调用
  • ADMIN_PASS：因为管理页已处于登录保护下

当前 wrapper 做了什么

当前 Dockerfile 不是直接把上游镜像原样暴露到 :7860，而是：

  • 前置一个很薄的 nginx
  • nginx 监听 :7860
  • 上游 claude2api 在容器内监听 127.0.0.1:8080
  • / 与 /index.html 直接跳转到 /admin/login
  • 其余路径继续透传到上游

这样做的原因很简单：

  • 旧版 root path 会显示 404 page not found
  • 现在用户访问根路径时，会直接进入真实可用的登录入口
  • 同时不需要去改上游镜像源码

当前是否配置了 PostgreSQL 持久化存储

结论

按当前已验证状态，不能认为这个 Space 已经配置并启用了 PostgreSQL 持久化存储。

虽然你提供了这个 Neon 连接串：

postgresql://neondb_owner:npg_EhvAUwfT1Q0s@ep-late-sun-a4w4w406-pooler.us-east-1.aws.neon.tech/neondb?sslmode=require&channel_binding=require

但就目前线上可确认的信息来看，还不能据此得出“当前 Space 正在用 PostgreSQL 持久化”的结论。

原因

  1. 当前 wrapper 仓库本身并没有把这个连接串写入任何被跟踪文件。
  2. Hugging Face 公开可读到的 Variables 里没有 DB_HOST / DB_PORT / DB_USER / DB_PASS / DB_NAME。
  3. Secrets 无法通过公开 API 直接读出，所以我不能仅靠外部观察断言你已经把 Neon 连接串拆分后放进了 Space Secrets。
  4. 当前线上已观察到的配置行为更像是：
    • 上游成功读取了 CLAUDE_SESSION_KEYS
    • 并使用 simple mode 就能完成调用
  5. 之前的运行时验证还显示：
    • admin UI 中修改的 api_key 只在当前进程有效
    • 重启后回退到启动环境变量值 这也不支持“当前已经有稳定的持久化配置优先层”这一判断。

如果要真正启用 PostgreSQL

需要满足两个条件：

  1. 上游 claude2api 本身支持通过环境变量连接外部 PostgreSQL
  2. 你把对应数据库配置真实放进了 Hugging Face Space Secrets / Variables

按这个仓库现有文档，通常是：

DB_HOST=ep-late-sun-a4w4w406-pooler.us-east-1.aws.neon.tech
DB_PORT=5432
DB_USER=neondb_owner
DB_PASS=...实际密码...
DB_NAME=neondb

注意：

  • 不能直接把完整连接串当成 DB_HOST
  • 当前 .env.example / README 的接口更偏向拆分字段，而不是单个 DATABASE_URL
  • 如果上游源码实际上不支持 Neon 这种外部 PG 持久化路径，或者虽然支持 PG 但启动优先级仍是 env 覆盖 runtime state，那么依然达不到你想要的“persisted-first”语义

关于 admin password / auth token 持久化的当前结论

目前已做过的验证结论是：

  • api_key 可以在当前运行期通过管理接口更新，并立即影响鉴权结果
  • 但容器重启后，会回退到启动时环境变量 / HF Secrets 的值
  • admin_pass 目前看不能通过现有 settings 路径真正更新生效

所以当前更准确的理解是：

  • Hugging Face Secrets / Variables = 启动配置源
  • 上游 admin UI 的部分设置 = 运行期状态修改
  • 两者目前不是一个可自动回写、可稳定持久继承的统一配置层

当前推荐的线上配置思路

如果你只是想把 Space 稳定跑起来：

必要 Secrets

  • CLAUDE_SESSION_KEYS
  • CLAUDE_API_KEY
  • ADMIN_PASS

当前 Variables 

LISTEN_ADDR=:7860
ADMIN_USER=admin

如果后续要尝试 PostgreSQL 持久化

请单独把它当成一次上游运行时验证任务，而不是继续在 wrapper 层假设它已经存在。

建议验证顺序：

  1. 在 Space Secrets / Variables 中补齐真实 DB 配置
  2. 重启 Space
  3. 通过 admin UI 修改一个可观测配置
  4. 再次重启 Space
  5. 验证该配置是否仍然生效
  6. 验证生效值到底来自：
    • PostgreSQL 持久化层
    • 还是 HF Secrets / env

只有这组验证跑通后，才能把“已启用 PostgreSQL 持久化”写成正式能力。

当前仓库文件职责

  • Dockerfile：构建 HF Space 容器
  • nginx.conf：把根路径重定向到 /admin/login，并透传其他请求
  • entrypoint.sh：同时启动前置 nginx 和上游 claude2api
  • .env.example：本地 / VPS 运行示例，不代表 HF Secrets 会被运行时回写
  • docker-compose.yml：本地 / VPS 参考，不会直接在 HF Space 中运行

最小验收命令 

curl -I https://ohmyapi-c2api.hf.space/
curl https://ohmyapi-c2api.hf.space/health
curl https://ohmyapi-c2api.hf.space/v1/models

curl https://ohmyapi-c2api.hf.space/v1/messages \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $CLAUDE_API_KEY" \
  -d '{
    "model": "claude-sonnet-4-6",
    "max_tokens": 32,
    "messages": [{"role": "user", "content": "Reply with exactly: ok"}]
  }'

如果最后一条返回正常消息体，就说明当前公开 Space、app token、以及 Claude session 这三层链路都已经打通。