快速结论:当 vLLM 启动时已设置 --api-key,/v1/* 请求会被拒绝(401),但 /invocations 仍会无鉴权返回 200 并真实消耗推理算力。核心问题在于 API Key 中间件只保护特定路径前缀,/invocations 不在保护范围内。优先排查对外暴露的端口与网关鉴权,而不是只依赖 --api-key。
适用环境:Issue 报告环境为 vLLM 30.0.0(正文标注);评论中的实机复现使用 quay.io/ascend/vllm-ascend:v0.30.0rc2-openeuler,Atlas 800I A2(910B4 × 8),openEuler 22.03 SP4,npu-smi 26.0.rc1;代码级分析针对镜像内 vllm 0.30.0。Issue 未提供 Python、CUDA、PyTorch 版本信息。
最快修复方案:暂无确认的一步修复方案。Issue 与复现报告均未验证可关闭或加鉴权的服务端参数;已验证有效的缓解方式是在服务前置网关层做鉴权或路径白名单,并避免将服务端口暴露到不可信网络。
注意事项:/invocations 为 SageMaker 兼容端点,按上游设计默认注册且不校验 API Key,属于有意为之的限制,不应把它当作配置错误。网关方案只降低可达性风险,并未修复 vLLM 内部鉴权缺失;长期仍需跟踪上游是否改为 opt-in 或让该端点遵循 --api-key。
问题场景
使用 vllm serve <model> --api-key my-secret-key 启动 OpenAI 兼容 API 服务后,用户预期 --api-key 能保护整个服务器。实际情况是:无 Key 访问 /v1/completions 被拒绝,但无 Key 访问 /invocations 仍被接受,可直接发起推理。复现报告还显示,即使携带 Key 访问 /invocations 也照常返回 200,说明 Key 对该端点没有任何限制作用。
报错原文
[Bug]: Security concern: `/invocations` endpoint is enabled by default and bypasses API key authentication
POST /invocations → 200 OK
GET /v1/models → 401 Unauthorized
{"error":"Unauthorized"}
原因分析
根据复现报告的代码级分析(vllm 0.30.0),可能原因如下:
- 鉴权以 ASGI 中间件按路径前缀匹配实现,
GUARDED_PREFIX = ("/v1","/v2","/inference","/cohere")不包含/invocations,因此 Bearer Token 不会被检查。 - SageMaker 路由在 API Server 启动流程中被无条件注册,其依赖仅有
validate_json_request(JSON 格式校验),不包含任何鉴权依赖。 /invocations按 OpenAI 兼容协议解析请求体,并进入与/v1相同的推理执行路径,因此具备同等的推理能力。- CLI
--api-key的帮助文本已明确说明该参数只认证/v1、/v2、/inference前缀下的端点,/invocations等其余端点不做认证。
同一报告中 /metrics 等其他非 /v1 端点同样无鉴权,可佐证保护范围仅限上述前缀。
环境排查
- 确认 vLLM 版本:复现环境为 vllm 0.30.0 / 镜像标签 v0.30.0rc2,回显版本号建议实际核对。
- 确认启动参数中是否设置了
--api-key,以及实际监听端口(如 8000)是否对外暴露。 - 确认服务前面是否有网关、Ingress 或 ACL 等额外鉴权层。
- 检查路由表日志中是否默认注册了
/invocations, Methods: POST。 - 检查
/metrics等非/v1端点是否也可无鉴权访问,以判断暴露面。 - 基于昇腾环境时,确认镜像、npu-smi 与驱动版本与生产一致,便于复现对照。
解决步骤
- 复现确认:启动带
--api-key的 vLLM 服务,分别无 Key 请求/v1/completions与/invocations,记录返回码,确认前者 401、后者 200。 - 检查服务端访问日志,确认
POST /invocations → 200 OK与GET /v1/models → 401 Unauthorized并存,并确认路由表中/invocations为默认注册。 - 立即缓解(可优先尝试):在服务前置网关层增加鉴权或路径白名单,仅放行必要的
/v1路径。 - 网络收敛(可优先尝试):将服务绑定到内网网段,避免 8000 等端口直接暴露到不可信网络;结合容器/网络层 ACL 限制来源。
- 生产排查:核对各机器上 vLLM 服务的启动脚本与端口暴露情况,确认是否存在完全无鉴权或暴露于不可信网络的服务。
- 跟踪上游 Issue,等待是否提供 opt-in 开关或让
/invocations遵循--api-key;在官方方案落地前不要仅依赖框架参数。
验证方法
在未携带 API Key 的情况下请求 /invocations,若经网关或网络收敛后返回 401/403 或直接不可达,且 /v1/* 仍按预期返回 401,则说明暴露面已被收敛;同时复查访问日志,确认不再出现无鉴权的 POST /invocations → 200 OK。
参考来源
AI 工具推荐
想把多个 AI 模型放在一个入口?
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型,适合写作、绘图、视频和日常 AI 工作流。
推广链接:通过此链接购买,我可能获得佣金,不影响你的价格。
这个方案解决了吗?
可以继续搜索完整报错,或查看同一工具的其他排查指南。


