受信任的代理身份验证
⚠️ 安全敏感功能。 此模式将身份验证完全委派给您的反向代理。配置错误可能会使您的 Gateway(网关) 暴露于未经授权的访问。在启用之前,请仔细阅读此页面。
何时使用
在以下情况下使用trusted-proxy 身份验证模式:
- 您在 身份感知代理(Pomerium、Caddy + OAuth、nginx + oauth2-proxy、Traefik + forward auth)后面运行 OpenClaw
- 您的代理处理所有身份验证并通过标头传递用户身份
- 您处于 Kubernetes 或容器环境中,且代理是通往 Gateway(网关) 的唯一路径
- 您遇到了 WebSocket
1008 unauthorized错误,因为浏览器无法在 WS 载荷中传递令牌
何时不使用
- 如果您的代理不对用户进行身份验证(仅作为 TLS 终结器或负载均衡器)
- 如果存在任何绕过代理通往 Gateway(网关) 的路径(防火墙漏洞、内部网络访问)
- 如果您不确定您的代理是否正确剥离/覆盖转发的标头
- 如果您只需要个人单用户访问(考虑使用 Tailscale Serve + 环回以进行更简单的设置)
工作原理
- 您的反向代理对用户进行身份验证(OAuth、OIDC、SAML 等)
- 代理添加一个包含已验证用户身份的标头(例如
x-forwarded-user: nick@example.com) - OpenClaw 检查请求是否来自 受信任的代理 IP(在
gateway.trustedProxies中配置) - OpenClaw 从配置的标头中提取用户身份
- 如果一切检查通过,则请求获得授权
控制 UI 配对行为
当gateway.auth.mode = "trusted-proxy" 处于活动状态且请求通过
受信任代理检查时,控制 UI WebSocket 会话无需设备
配对身份即可连接。
影响:
- 在此模式下,配对不再是控制 UI 访问的主要关卡。
- 您的反向代理身份验证策略和
allowUsers成为有效的访问控制。 - 保持网关入口仅限于受信任的代理 IP(
gateway.trustedProxies+ 防火墙)。
配置
gateway.bind 是 loopback,请在
gateway.trustedProxies 中包含一个回环代理地址(127.0.0.1、::1 或等效的回环 CIDR)。
配置参考
| 字段 | 必需 | 描述 |
|---|---|---|
gateway.trustedProxies | 是 | 要信任的代理 IP 地址数组。来自其他 IP 的请求将被拒绝。 |
gateway.auth.mode | 是 | 必须是 "trusted-proxy" |
gateway.auth.trustedProxy.userHeader | 是 | 包含已认证用户身份的 Header 名称 |
gateway.auth.trustedProxy.requiredHeaders | 否 | 请求受信任时必须存在的其他 Header |
gateway.auth.trustedProxy.allowUsers | 否 | 用户身份白名单。留空表示允许所有已认证用户。 |
TLS 终止和 HSTS
使用一个 TLS 终止点并在那里应用 HSTS。推荐模式:代理 TLS 终止
当您的反向代理为https://control.example.com 处理 HTTPS 时,请在代理上为该域设置
Strict-Transport-Security。
- 适合面向互联网的部署。
- 将证书 + HTTP 加固策略集中在一处。
- OpenClaw 可以在代理后的回环 HTTP 上运行。
Gateway TLS 终止
如果 OpenClaw 本身直接提供 HTTPS(无 TLS 终止代理),请设置:strictTransportSecurity 接受字符串 Header 值,或使用 false 显式禁用。
部署指南
- 验证流量时,首先使用较短的 max age(例如
max-age=300)。 - 只有在确定无误后,才增加为长期有效的值(例如
max-age=31536000)。 - 仅当每个子域名都准备好使用 HTTPS 时,才添加
includeSubDomains。 - 仅当您有意为整个域名集满足预加载要求时,才使用预加载。
- 仅限回环的本地开发无法从 HSTS 中受益。
代理设置示例
Pomerium
Pomerium 在x-pomerium-claim-email(或其他声明 Header)中传递身份,并在 x-pomerium-jwt-assertion 中传递 JWT。
使用 OAuth 的 Caddy
带有caddy-security 插件的 Caddy 可以认证用户并传递身份 Header。
nginx + oauth2-proxy
oauth2-proxy 对用户进行认证并在x-auth-request-email 中传递身份信息。
Traefik 搭配 Forward Auth
安全检查清单
启用 trusted-proxy 认证前,请验证:- 代理是唯一路径:Gateway(网关) 端口已设置防火墙,仅允许您的代理访问
- trustedProxies 配置极简:仅包含您实际的代理 IP,而不是整个子网
- 代理剥离标头:您的代理覆盖(而不是追加)来自客户端的
x-forwarded-*标头 - TLS 终止:您的代理处理 TLS;用户通过 HTTPS 连接
- 已设置 allowUsers(推荐):限制为已知用户,而不是允许任何经过身份验证的人
安全审计
openclaw security audit 将标记 trusted-proxy 认证,并给出 严重(critical) 级别的发现。这是有意为之——旨在提醒您正在将安全委托给您的代理设置。
审计检查内容:
- 缺少
trustedProxies配置 - 缺少
userHeader配置 allowUsers为空(允许任何经过身份验证的用户)
故障排查
”trusted_proxy_untrusted_source”
请求未来自gateway.trustedProxies 中的 IP。请检查:
- 代理 IP 是否正确?(Docker 容器 IP 可能会变化)
- 您的代理前面是否有负载均衡器?
- 使用
docker inspect或kubectl get pods -o wide查找实际 IP
”trusted_proxy_user_missing”
用户标头为空或缺失。请检查:- 您的代理是否配置为传递身份标头?
- 标头名称是否正确?(不区分大小写,但拼写必须正确)
- 用户是否确实在代理处通过了身份验证?
“trustedproxy_missing_header*”
缺少必需的标头。请检查:- 您的代理针对这些特定标头的配置
- 标头是否在链路中的某处被剥离
”trusted_proxy_user_not_allowed”
用户已通过身份验证但不在allowUsers 中。请将其添加或移除允许列表。
WebSocket 仍然失败
确保您的代理:- 支持 WebSocket 升级(
Upgrade: websocket,Connection: upgrade) - 在 WebSocket 升级请求上传递身份标头(而不仅仅是 HTTP)
- 没有为 WebSocket 连接提供单独的身份验证路径
从 Token Auth 迁移
如果您正在从 token auth 迁移到 trusted-proxy:- 配置您的代理以验证用户并传递标头
- 独立测试代理设置(使用带标头的 curl)
- 使用 trusted-proxy auth 更新 OpenClaw 配置
- 重启 Gateway(网关)
- 从控制 UI 测试 WebSocket 连接
- 运行
openclaw security audit并检查结果
相关
本页面源自 openclaw/openclaw,由 BeaversLab 翻译,遵循 MIT 协议 发布。