Open WebUI作为OpenAI API网关的中转鉴权配置：自定义密钥与用户隔离实现

Open WebUI 要承担 OpenAI API 的中转鉴权，其实分两层：一层是登录用户的身份鉴权，另一层是转发到上游时携带的 API 密钥。大多数部署把这两层混在一起，结果只看 Web 界面能进、能发消息，没有真正验证自定义密钥和用户隔离是否生效。

如果目标只是“不同用户登录 Open WebUI 后用各自的 API Key 发请求”，Open WebUI 可以通过用户设置和全局环境变量配合实现；如果目标是“多用户共享同一个上游密钥，但需要单独计费、配额或审计”，Open WebUI 默认满足不了，需要在上游平台开通子密钥，或在前面加反向代理做请求分发。下面先解释边界，再给配置步骤。

先判断你属于哪种隔离

用户隔离可以分成两种：账号隔离和密钥隔离。账号隔离解决“谁能用这个网关”，密钥隔离解决“请求以谁的名义发出、按谁计费”。Open WebUI 的账号体系只解决前者，后者的实际下发通常依赖上游 API 平台的子账号能力。

如果你的管理员为每个用户配置一个独立的上游 API Key，Open WebUI 就可能让请求走各自密钥；如果管理员只给全局设一个上游 Key，所有人共用，那就只有账号隔离，没有密钥隔离。此决定应该先做，否则后面配置容易绕弯。

把 Open WebUI 配置成纯转发网关

作为网关，至少要让 Open WebUI 知道该往哪里转、用什么主密钥。容器部署可在环境变量里设置：

Open WebUI作为OpenAI API网关的中转鉴权配置：自定义密钥与用户隔离实现

version: '3'
services:
  open-webui:
    image: ghcr.io/open-webui/open-webui
    environment:
      OPENAI_API_BASE_URL: https://api.openai.com/v1
      OPENAI_API_KEY: sk-your-primary-key
      DEFAULT_USER_ROLE: user
    ports:
      - 3000:8080
    volumes:
      - open-webui:/app/backend/data

OPENAI_API_BASE_URL 可以换成任何 OpenAI 兼容端点；OPENAI_API_KEY 建议使用服务账号或专用主密钥，不要直接使用个人账号。DEFAULT_USER_ROLE 可视情况设置：默认新建用户是 user 而非 admin，能减少误改全局配置的可能。

自定义密钥的两种落地方式

第一种是让每个用户在登录后自己填入 OpenAI API Key。这类界面通常在“设置”或“个人中心”里，填完后请求会用该用户自己的密钥。这种方式灵活，但管理员无法强制限定用户填哪个密钥，也无法保证用户不填错。

第二种是管理员预先为每个用户在系统里配置专属密钥。这依赖具体版本的 Open WebUI 是否提供管理员修改用户密钥的能力：不同版本入口不一样，有的可能在“用户管理”里直接设定，有的需要直接把值写入数据库。如果界面没有现成入口，可以先为每个用户建立独立浏览器环境，再登录该账号填入各自密钥，后续由用户自己维护。

理解了这个约束，再谈隔离。真正需要按用户计费或限制用量时，最稳妥的是给每一个用户创建上游子账号，把子 API Key 配到对应 Open WebUI 账号里。Open WebUI 本身不管理配额，配额仍由上游平台执行。

验证：不要只看聊天是否成功

配置完成的判断标准不是“能发聊天”，而是“每个请求是否按预期携带密钥”。可以先用两种方式验证：

用普通用户账号登录 Open WebUI，在模型列表能看到模型，发送一条消息，然后在上游服务的请求日志中确认该次的消耗归属。如果你用的是 OpenAI，至少检查登录用户的身份是否出现在日志中。
如果 Open WebUI 暴露兼容 API，直接调用该接口测试鉴权链路是否稳定：

curl http://localhost:3000/api/openai/chat/completions -H 'Authorization: Bearer <用户从设置里拿到的访问 Token>' -H 'Content-Type: application/json' -d '{"model":"gpt-4o-mini","messages":[{"role":"user","content":"你好"}]}'

如果返回 401，说明 Token 校验没走对；返回 404，则可能是当前版本的兼容端点路径不同，用浏览器请求 Open WebUI 的 /api 根地址查看暴露路由，再调整路径。这个命令只能验证“请求能通过 Open WebUI”，要验证“上了正确密钥”仍需在上游日志里比对。

风险边界

把 Web 界面做成 API 网关时，用户可以通过聊天界面消耗你的 API 额度。不要对“用户隔离”做过度承诺：Open WebUI 默认不会为每个用户生成独立预算，也不会在上游平台建立子账户。它更像一个可多人登录的转发层。

如果你需要严格隔离，建议在 Open WebUI 前放置反向代理，按请求头中的用户身份或 key 前缀，把请求分流到不同上游地址或插入不同 Authorization 头。这个做法比依赖 Open WebUI 自身更可控，也更容易审计。

最后，管理员要定期检查日志里是否有异常高频调用，以及是否有用户把访问 Token 泄漏给无权使用的人。Token 一旦泄漏，等于把上游 API Key 的使用权交给了别人，这一点需要提醒用户注意。