笙亿网络策划

SGLang作为中转站上游时鉴权token透传与OpenAI默认key冲突的设置

约 5 分钟读完 23 阅
文章导读
这个问题通常出现在通过 one-api、new-api 这类中转站把请求转发给自建 SGLang 时：客户端请求头里是用户 token，SGLang 启动时又设置了固定的 API key。中转站如果选透传用户鉴权信息，SGLang 校验时就会把这个 token 和自己的 key 比对，发现不一致而拒绝。另一种情况是渠道里还沿用 OpenAI 的默认 key，也会触发同样的冲突。先想清楚由谁做鉴权：
📋 目录
  1. 壹 冲突来源与判断方向
  2. 贰 方案一：关闭 SGLang 的 key 校验（推荐）
  3. 叁 方案二：保留 SGLang 校验，中转站使用固定 key
  4. 肆 方案三：必须透传时怎么办
  5. 伍 验证顺序与检查点
  6. 陆 常见问题
A A

这个问题通常出现在通过 one-api、new-api 这类中转站把请求转发给自建 SGLang 时：客户端请求头里是用户 token，SGLang 启动时又设置了固定的 API key。中转站如果选透传用户鉴权信息，SGLang 校验时就会把这个 token 和自己的 key 比对，发现不一致而拒绝。另一种情况是渠道里还沿用 OpenAI 的默认 key，也会触发同样的冲突。先想清楚由谁做鉴权：中转站做，还是 SGLang 做。

SGLang 校验用户 token 的前提是它能接受该 token；否则应关闭 SGLang 的 key 校验，让中转站统一鉴权。不要同时要求“透传用户 token”和“SGLang 固定 key 校验”。关闭 SGLang 鉴权后，必须限制只有中转站能访问它。

冲突来源与判断方向

SGLang 的 OpenAI 兼容服务通常只认启动时指定的 API key，没有指定时不校验 Authorization 头。中转站向上游发请求时会按渠道配置写请求头：用渠道 key 替换，或者原样透传用户 token。所以冲突的本质是“SGLang 只认自己的 key，不认用户 token”。

判断方向很直接：

  • 中转站已经做用户校验，就关掉 SGLang 的 key 校验，透传即可。
  • 必须由 SGLang 校验用户身份，就要让用户 token 成为 SGLang 认可的 key，或者通过中间层把 token 换成 SGLang 的 key。

方案一：关闭 SGLang 的 key 校验（推荐）

适合中转站统一管理用户、SGLang 不暴露公网的部署。启动时不带 `--api-key`，也不设置相关环境变量：

python -m sglang.launch_server \
  `--model-path` /models/your-model \
  `--port` 30000

验证方式：

curl -s http://127.0.0.1:30000/v1/models \
  -H 'Authorization: Bearer test-token-123'

只要返回模型列表，说明 SGLang 没有拒绝未知 token。风险边界是 SGLang 自身没有鉴权，必须由防火墙或安全组限制只有中转站 IP 能访问 30000 端口。

方案二：保留 SGLang 校验，中转站使用固定 key

如果必须保留 `--api-key`，就不要透传用户 token，而是在中转站渠道里填 SGLang 的 key：

SGLang作为中转站上游时鉴权token透传与OpenAI默认key冲突的设置
python -m sglang.launch_server \
  `--model-path` /models/your-model \
  `--port` 30000 \
  `--api-key` sk-sglang-local

中转站请求上游时用 sk-sglang-local，用户 token 只和中转站发生关系。验证方式：通过中转站访问成功，直接带错误 key 访问 SGLang 会被拒绝。这样把“用户到中转站”和“中转站到 SGLang”两段鉴权分开。

方案三：必须透传时怎么办

如果用户 token 需要原样到达 SGLang，并且 SGLang 也参与校验，比较现实的做法是在 SGLang 前面加一层轻量鉴权网关，它把用户 token 换算成 SGLang 认可的固定 key，再转发给 SGLang。也可以让中转站自己完成这个重写。

不要指望配置里有一个“透传但放行”的开关。先看当前 SGLang 版本是否支持额外鉴权参数：

python -m sglang.launch_server `--help` | grep -i -E 'key|token|auth|jwt'

如果没有相关参数，就按前面两个方案选择。需要结合你的 SGLang 版本和部署方式确认。

验证顺序与检查点

  1. 画一下链路：客户端 → 中转站 → SGLang，标出每段 Authorization 头的内容。
  2. 看 SGLang 日志，确认是 401 还是 403，错误信息是否提示 Invalid API key。
  3. 用不同 key 直接 curl SGLang，确认它是否校验 key，以及校验的规则。
  4. 从中转站日志看实际上游请求头，确认是透传还是固定 key。
  5. 确认 SGLang 端口只对中转站 IP 开放。

常见问题

能不能让 SGLang 同时接受多个 key？

通常不能靠启动参数直接配置多个 key。如果用户多，应该在中转站层把不同用户映射到同一个上游 key，或在前面加网关。

关闭 SGLang 鉴权后，不带 key 的请求会怎样？

不带 `--api-key` 时，多数 OpenAI 兼容服务会接受空 Authorization 或任意 key，但具体行为要看版本，最稳的办法是用空 token 和错误 token 各试一次。