1. 项目概述与核心价值如果你正在管理一个由多个内部Web应用组成的服务生态比如公司内部的Wiki、GitLab、监控面板、项目管理工具那么“如何让用户只登录一次就能畅通无阻地访问所有应用”这个问题大概率会让你头疼。传统的做法是为每个应用单独配置登录用户得记住一堆账号密码体验差安全性也难统一保障。而“Vouch Proxy与Nginx auth_request模块的完美集成”这个方案正是为了解决这个痛点而生。它本质上是一个基于Nginx反向代理和OAuth/OpenID ConnectOIDC的轻量级、无侵入的单点登录SSO网关。简单来说它的工作模式就像一个“统一的安检门”。所有需要保护的Web应用我们称之为上游应用都躲在Nginx这个“大楼管理员”后面。当用户试图访问任何一个应用时Nginx不会直接放行而是先向部署在旁边的“安检员”——Vouch Proxy——发起一个内部询问“这个人有票吗”这个询问动作就是通过Nginx的auth_request模块发起的。Vouch Proxy检查用户浏览器里的“门票”一个加密的JWT Cookie。如果票有效就告诉Nginx“放行”如果没票或票无效就返回“无权访问”。Nginx收到“无权访问”的信号后会立即把用户重定向到Vouch Proxy的登录页面引导用户去Google、GitHub、Okta等身份提供商IdP那里完成认证。认证成功后Vouch Proxy会签发一张新的“门票”存到用户浏览器并把他送回到最初想访问的应用页面。整个过程对后端应用是透明的应用本身完全不需要知道任何关于OAuth的细节它只需要信任并读取Nginx转发过来的、包含用户身份信息的HTTP头部比如X-Vouch-User这个头部里通常就是用户的邮箱即可。这套方案的核心魅力在于它的“无侵入性”和“低成本”。你不需要改造任何一个现有应用的登录逻辑只需要在流量入口的Nginx层做一次统一的配置。Vouch Proxy本身用Go语言编写资源消耗极低配置也相对简单。对于中小型团队或拥有大量遗留系统、又希望快速实现统一身份认证的场景来说这几乎是最优雅的解决方案之一。接下来我将带你从零开始拆解这套方案的每一个技术细节和配置要点。2. 核心组件深度解析与选型考量在动手之前我们必须彻底理解方案中几个核心组件的工作原理和它们之间的协作关系。这能帮助你在遇到问题时快速定位是哪个环节出了岔子。2.1 Nginx的auth_request模块流量的守门人auth_request模块是Nginx实现子请求认证的基石。它允许Nginx在处理客户端的主请求之前先向另一个内部或外部的URI发起一个认证子请求并根据这个子请求的返回状态码来决定是放行还是拒绝主请求。工作原理定义认证端点在Nginx配置中通过auth_request指令指定一个用于认证的URI例如/validate。发起子请求当客户端请求到达时Nginx会先向这个/validate端点发起一个内部请求子请求。裁决Nginx根据子请求的HTTP状态码做出裁决2xx状态码成功认证通过Nginx继续处理原始请求例如将请求代理到后端应用。401或403状态码认证失败。Nginx会停止处理原始请求并返回错误页面或执行error_page指令定义的错误处理逻辑通常是重定向到登录页。其他状态码如500Nginx默认会返回500错误给客户端。这通常意味着认证服务本身出了问题。关键配置指令解析auth_request 核心指令定义认证子请求的URI。auth_request_set 这是整个方案中信息传递的关键。它允许你将认证子请求即Vouch Proxy/validate端点返回的响应头中的值提取并保存到Nginx变量中。这些变量随后可以在proxy_set_header等指令中使用将用户信息传递给后端应用。# 将Vouch Proxy返回的 X-Vouch-User 响应头赋值给Nginx变量 $auth_resp_x_vouch_user auth_request_set $auth_resp_x_vouch_user $upstream_http_x_vouch_user;error_page 401 error401; 定义当认证子请求返回401时跳转到名为error401的命名location块进行处理通常这里就是重定向到登录页的逻辑。注意auth_request模块默认不包含在Nginx的标准发行版中。对于通过包管理器如apt、yum安装的Nginx通常需要额外安装nginx-extras或nginx-full这类包含第三方模块的包。编译安装时则需要通过--with-http_auth_request_module参数显式启用。你可以通过nginx -V 21 | grep -o with-http_auth_request_module命令来检查你的Nginx是否已包含此模块。2.2 Vouch Proxy轻量级的认证代理与票据中心Vouch Proxy是一个用Go编写的独立HTTP服务它扮演了两个核心角色OAuth/OIDC客户端和JWT票据签发/验证器。作为OAuth/OIDC客户端Vouch Proxy预先在IdP如Google Cloud Console中注册为一个OAuth应用获得client_id和client_secret。当未认证的用户被重定向到Vouch Proxy的/login端点时Vouch Proxy会生成一个随机的state参数防止CSRF攻击并将用户重定向到IdP的授权页面。用户在IdP页面完成登录授权后IdP会将授权码通过回调URL/auth端点传回给Vouch Proxy。Vouch Proxy再用这个授权码与IdP进行服务器对服务器的通信“后端通道”换取用户的身份信息ID Token、Access Token 或调用UserInfo端点。作为JWT票据签发/验证器从IdP获取到用户信息通常是邮箱后Vouch Proxy会使用一个密钥通过vouch.jwt.secret配置或自动生成签发一个JWTJSON Web Token。这个JWT包含了用户的基本信息和过期时间然后被加密后作为一个名为VouchCookie默认的HTTP-Only Cookie设置到用户的浏览器中作用域Domain通常设置为你的主域名如.yourcompany.com以便所有子域名都能共享这个Cookie。当Nginx发起/validate请求时Vouch Proxy会做以下几件事从请求的Cookie中读取JWT。验证JWT的签名是否有效是否过期。可选根据配置的规则如邮箱域名白名单进行额外的授权检查。如果一切有效则返回200状态码并在响应头中带上用户信息如X-Vouch-User: userexample.com。如果无效则返回401状态码。为什么选择Vouch Proxy而不是其他方案市面上有类似的方案比如oauth2_proxy或keycloak-gatekeeper。Vouch Proxy的优势在于与Nginx集成极度简洁专为auth_request模块设计交互协议简单明了。配置直观一个YAML配置文件搞定大部分设置环境变量覆盖也让容器化部署非常方便。对后端应用零侵入应用无需任何OAuth库只需读取HTTP头部。轻量高效Go语言编译的单一二进制文件内存占用小性能好。社区支持与生态支持的主流IdP非常广泛从Google、GitHub到企业级的Okta、Keycloak、Azure AD都涵盖且社区活跃。2.3 身份提供商IdP的选择与准备IdP是整个信任链的源头。你需要根据你的使用场景选择一个并完成前期配置。常见IdP及适用场景Google OAuth 2.0最适合个人项目、初创公司或使用G Suite/Google Workspace的团队。配置简单用户认知度高。GitHub OAuth开发者社区和开源项目首选。可以方便地基于GitHub Organization或Team进行权限控制。Okta / Azure AD (Entra ID)企业级标准提供最完善的身份管理、安全策略如MFA和生命周期管理。Keycloak开源的身份和访问管理解决方案。适合需要完全自托管、高度定制化权限模型和协议的企业。以Google OAuth为例的准备工作访问 Google Cloud Console 。创建一个新项目或选择现有项目。进入“API和服务” - “凭据”。点击“创建凭据” - “OAuth 客户端ID”。应用类型选择“Web 应用”。在“已获授权的重定向 URI”中添加你的Vouch Proxy回调地址格式为https://vouch.yourdomain.com/auth请将vouch.yourdomain.com替换为你计划部署Vouch Proxy的实际域名。创建后记录下“客户端ID”和“客户端密钥”。这两个值将用于Vouch Proxy的配置。实操心得在配置IdP的回调URI时务必确保域名和路径完全准确包括http和https。很多登录循环问题都源于回调地址不匹配。对于本地开发你可能需要配置http://localhost:9090/auth并确保在Vouch配置中设置了vouch.cookie.secure: false。3. 完整部署与配置实战理解了原理我们进入实战环节。我将以最经典的架构为例在同一台服务器上通过Docker运行Vouch Proxy并通过宿主机上的Nginx同时代理Vouch Proxy本身和需要保护的上游应用。3.1 环境与架构准备假设我们有以下设定主域名example.comVouch Proxy服务域名vouch.example.com需要保护的应用域名app1.example.com(运行在localhost:8081),app2.example.com(运行在localhost:8082)服务器已安装Docker, Docker Compose和Nginx。已为vouch.example.com、app1.example.com、app2.example.com申请并配置了有效的SSL证书例如使用Let‘s Encrypt。这是必须的因为OAuth要求HTTPS环境。我们的网络流量走向将是用户浏览器 - HTTPS请求 - Nginx (443端口) - auth_request /validate - Vouch Proxy容器 - 返回认证结果 - Nginx - (若成功)代理到上游应用3.2 Vouch Proxy配置详解首先我们创建Vouch Proxy的配置文件和Docker运行环境。1. 创建目录结构mkdir -p ~/vouch-proxy/config cd ~/vouch-proxy2. 创建核心配置文件config/config.ymlvouch: # 日志级别调试时设为debug生产环境建议info logLevel: info # 测试模式会放慢重定向速度便于调试生产环境设为false testing: false # 允许访问的域名列表支持通配符子域名 domains: - example.com - .example.com # 匹配所有子域名 cookie: # Cookie名称 name: VouchCookie # Cookie作用域设置为根域名以实现跨子域共享 domain: example.com # 是否仅通过HTTPS传输生产环境必须为true secure: true # Cookie有效期默认24小时 maxAge: 14400 # 防止客户端脚本访问增强安全性 httpOnly: true jwt: # JWT签名密钥。非常重要生产环境务必使用强随机字符串。 # 可以通过命令生成openssl rand -base64 32 secret: your_very_strong_and_long_secret_key_here_change_me # JWT的有效期应小于或等于cookie的maxAge maxAge: 14400 # 签发者标识 issuer: Vouch # OAuth/OIDC 提供商配置 oauth: # 提供商类型这里是google provider: google # 在Google Cloud Console创建的客户端ID client_id: your_google_client_id.apps.googleusercontent.com # 在Google Cloud Console创建的客户端密钥 client_secret: your_google_client_secret # 回调URL必须与IdP中配置的完全一致 callback_url: https://vouch.example.com/auth # 申请的权限范围 scopes: - openid - email - profile # Google的特定端点Vouch通常能自动发现但显式指定更可靠 auth_url: https://accounts.google.com/o/oauth2/auth token_url: https://oauth2.googleapis.com/token user_info_url: https://openidconnect.googleapis.com/v1/userinfo # 从userinfo响应中提取用户名的字段通常是email preferred_username: email # 允许的头信息传递给后端应用 headers: # 将认证成功的用户邮箱传递给后端头部名为X-Vouch-User X-Vouch-User: X-Vouch-User # 如果需要也可以传递ID Token或Access Token注意安全 # X-Vouch-IdP-IdToken: X-Vouch-IdP-IdToken # X-Vouch-IdP-AccessToken: X-Vouch-IdP-AccessToken3. 创建docker-compose.yml文件version: 3.8 services: vouch-proxy: image: quay.io/vouch/vouch-proxy:latest container_name: vouch-proxy restart: unless-stopped ports: - 9090:9090 # 映射主机9090端口到容器9090端口 volumes: - ./config:/config # 挂载配置文件目录 environment: # 可以通过环境变量覆盖配置这里设置域名 - VOUCH_DOMAINSexample.com,.example.com # 可选设置容器内用户增强安全性镜像默认用户为vouch, UID 999 # user: 999:9994. 启动Vouch Proxy服务docker-compose up -d检查日志确认服务启动无误docker-compose logs -f vouch-proxy你应该能看到类似msg:started listening on的日志表示Vouch Proxy已在容器内的9090端口就绪。3.3 Nginx核心配置解析与实现这是整个集成中最关键的一步。我们需要配置两个Nginxserver块一个用于代理Vouch Proxy本身使其可通过HTTPS访问另一个或多个用于保护我们的上游应用。1. Vouch Proxy自身的Nginx配置 (/etc/nginx/sites-available/vouch.example.com):这个配置让Vouch Proxy服务可以通过https://vouch.example.com被外部访问。server { listen 443 ssl http2; server_name vouch.example.com; # SSL证书路径请替换为你的实际路径 ssl_certificate /etc/letsencrypt/live/vouch.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/vouch.example.com/privkey.pem; # 重要传递原始Host头否则Vouch Proxy无法正确设置Cookie的domain proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; location / { # 代理到运行在本地9090端口的Vouch Proxy容器 proxy_pass http://127.0.0.1:9090; # 确保传递请求体虽然/auth等端点需要但/validate不需要 proxy_pass_request_body on; proxy_set_header Content-Length $content_length; } }2. 受保护应用的Nginx配置 (/etc/nginx/sites-available/app1.example.com):这个配置为app1.example.com添加了Vouch Proxy认证层。server { listen 443 ssl http2; server_name app1.example.com; ssl_certificate /etc/letsencrypt/live/app1.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/app1.example.com/privkey.pem; root /var/www/html/app1; # 你的应用根目录 index index.html index.htm; # 核心对所有请求启用认证子请求 auth_request /validate; # 认证端点配置 location /validate { # 内部转发到Vouch Proxy的验证接口 proxy_pass http://127.0.0.1:9090/validate; proxy_set_header Host $http_host; # 传递原始Host头至关重要 # Vouch Proxy的/validate端点不处理请求体可以关闭以提高性能 proxy_pass_request_body off; proxy_set_header Content-Length ; # 从Vouch Proxy的响应头中提取信息并存入Nginx变量 # 提取用户标识通常是邮箱 auth_request_set $auth_resp_x_vouch_user $upstream_http_x_vouch_user; # 提取错误信息用于调试 auth_request_set $auth_resp_err $upstream_http_x_vouch_err; # 提取JWT令牌可用于自定义错误页 auth_request_set $auth_resp_jwt $upstream_http_x_vouch_jwt; # 提取失败计数 auth_request_set $auth_resp_failcount $upstream_http_x_vouch_failcount; # 如果需要传递自定义声明如用户组可以这样设置 # auth_request_set $auth_resp_x_vouch_idp_claims_groups $upstream_http_x_vouch_idp_claims_groups; } # 处理401未授权错误重定向到登录页 error_page 401 error401; location error401 { # 构造重定向URL跳转到Vouch Proxy的登录页面 # $scheme://$http_host$request_uri 会拼出用户最初请求的完整URL # Vouch Proxy会在登录成功后将用户带回这个URL return 302 https://vouch.example.com/login?url$scheme://$http_host$request_urivouch-failcount$auth_resp_failcountX-Vouch-Token$auth_resp_jwterror$auth_resp_err; } # 应用本身的反向代理配置 location / { # 代理到实际的应用服务器 proxy_pass http://127.0.0.1:8081; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 将从Vouch Proxy获取的用户信息通过HTTP头传递给后端应用 proxy_set_header X-Vouch-User $auth_resp_x_vouch_user; # 如果需要也可以传递自定义声明 # proxy_set_header X-Vouch-IdP-Claims-Groups $auth_resp_x_vouch_idp_claims_groups; # 注意$auth_resp_x_vouch_user 等变量是在上面的 location /validate 块中通过 auth_request_set 设置的。 # 根据Nginx的变量作用域规则这些变量在 location / 块中是可用的。 } }3. 启用配置并重载Nginx# 创建符号链接假设使用sites-enabled/sites-available模式 sudo ln -s /etc/nginx/sites-available/vouch.example.com /etc/nginx/sites-enabled/ sudo ln -s /etc/nginx/sites-available/app1.example.com /etc/nginx/sites-enabled/ # 测试Nginx配置语法 sudo nginx -t # 确认无误后重载Nginx使配置生效 sudo systemctl reload nginx3.4 验证与测试流程配置完成后必须进行系统性的测试。直接访问受保护应用在浏览器中打开https://app1.example.com。你应该会被立即重定向到https://vouch.example.com/login并很快跳转到Google的登录页面或其他你配置的IdP。完成登录使用你的Google账号登录并授权。重定向与访问授权成功后浏览器会被重定向回https://app1.example.com此时你应该能正常访问应用。验证单点登录在同一个浏览器中打开一个新的标签页访问https://app2.example.com假设你为app2配置了相同的保护。你应该无需再次登录直接就能访问。这说明Cookie在example.com域下共享成功。检查用户信息传递你可以在你的应用如一个简单的测试PHP页面或查看应用日志中检查收到的HTTP头应该能看到X-Vouch-User: your-emailgmail.com这样的头部。4. 高级配置、优化与故障排查基础流程跑通后我们可以根据实际需求进行优化和深度定制。4.1 安全加固与最佳实践使用强JWT Secret永远不要使用示例中的默认密钥。使用openssl rand -base64 32生成一个强随机字符串并妥善保管。限制Cookie作用域vouch.cookie.domain应设置为尽可能具体的范围。如果所有应用都在.internal.example.com下就设置为.internal.example.com而不是顶级的example.com以减少攻击面。启用HTTPS和Secure Cookie生产环境必须使用HTTPS并确保vouch.cookie.secure: true。配置IdP的授权范围在IdP如Google的应用配置中限制重定向URI只允许你的Vouch Proxy域名并定期审查已授权的应用。使用白名单Vouch Proxy支持通过vouch.allowAllUsers: false和vouch.whitelist或vouch.domains来限制只有特定邮箱或邮箱域的用户可以登录。这对于内部工具至关重要。vouch: allowAllUsers: false whitelist: - your-teamexample.com - adminexample.com # 或者使用域名白名单 # domains: # - example.com # - another-allowed-domain.com4.2 性能优化为/validate端点添加缓存每次请求都触发一次对Vouch Proxy的/validate调用可能会增加延迟。Nginx的auth_request模块可以与proxy_cache结合对认证结果进行短期缓存。http { # 定义一个缓存路径和区域 proxy_cache_path /var/cache/nginx/auth_cache levels1:2 keys_zoneauth_cache:10m inactive10m max_size100m; server { server_name app1.example.com; # ... 其他ssl等配置 ... auth_request /validate; location /validate { proxy_pass http://127.0.0.1:9090/validate; proxy_set_header Host $http_host; proxy_pass_request_body off; proxy_set_header Content-Length ; # 启用缓存使用$cookie_VouchCookie作为缓存键 proxy_cache auth_cache; proxy_cache_key $cookie_VouchCookie; proxy_cache_valid 200 10m; # 认证成功的结果缓存10分钟 proxy_cache_valid 401 1m; # 认证失败的结果缓存1分钟防止暴力重试 proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504; # 如果Vouch Proxy服务不可用允许使用陈旧的缓存谨慎使用 # proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504; # ... auth_request_set 变量提取 ... } # ... 其他配置 ... } }注意缓存认证状态是一把双刃剑。它提升了性能但也意味着用户在Vouch Proxy侧登出或会话过期后在缓存有效期内可能仍被Nginx认为是已登录状态。请根据你的安全要求权衡缓存时间。4.3 传递丰富的用户信息与声明除了基本的邮箱你可能需要将用户的姓名、部门、组等信息传递给后端应用。这需要在Vouch Proxy和Nginx配置中都进行设置。1. 在Vouch Proxy配置中请求更多Scope和映射Claimoauth: provider: google client_id: ... client_secret: ... scopes: - openid - email - profile # 请求profile scope以获取姓名等信息 # 假设你的IdP如Keycloak返回了‘groups’声明 # scopes: # - openid # - email # - profile # - groups headers: X-Vouch-User: X-Vouch-User # 邮箱 # 映射IdP返回的‘name’声明到‘X-Vouch-IdP-Claims-Name’头部 X-Vouch-IdP-Claims-Name: name # 映射IdP返回的‘groups’声明到‘X-Vouch-IdP-Claims-Groups’头部 X-Vouch-IdP-Claims-Groups: groups2. 在Nginx配置中提取并传递这些头部location /validate { proxy_pass ...; # ... 其他配置 ... auth_request_set $auth_resp_x_vouch_user $upstream_http_x_vouch_user; auth_request_set $auth_resp_x_vouch_idp_claims_name $upstream_http_x_vouch_idp_claims_name; auth_request_set $auth_resp_x_vouch_idp_claims_groups $upstream_http_x_vouch_idp_claims_groups; } location / { proxy_pass ...; proxy_set_header X-Vouch-User $auth_resp_x_vouch_user; proxy_set_header X-Vouch-IdP-Claims-Name $auth_resp_x_vouch_idp_claims_name; proxy_set_header X-Vouch-IdP-Claims-Groups $auth_resp_x_vouch_idp_claims_groups; }这样你的后端应用就能收到包含完整用户信息的头部进而实现更精细的权限控制。4.4 常见故障排查实录即使按照步骤操作也难免会遇到问题。以下是几个最常见的问题及其解决方法。问题一无限重定向循环症状浏览器在IdP登录页面和你的应用之间来回跳转无法进入应用。排查步骤检查Cookie域名这是最常见的原因。确保vouch.cookie.domain设置正确并且Vouch Proxy服务vouch.example.com和受保护应用app1.example.com共享同一个父域名或子域名且Cookie域名设置为此父域如.example.com。在浏览器开发者工具的“应用”-“Cookie”选项卡中检查VouchCookie是否被正确设置在了预期的域名下。检查Host头在Nginx代理Vouch Proxy的配置中必须包含proxy_set_header Host $http_host;。缺少这个头部Vouch Proxy可能无法正确生成和验证Cookie。检查HTTPS和Secure标志如果本地开发使用HTTP确保vouch.cookie.secure设置为false。生产环境必须为true且使用HTTPS。开启调试模式在Vouch Proxy配置中设置vouch.logLevel: debug和vouch.testing: true。后者会减慢重定向速度让你有机会观察浏览器地址栏的变化。查看Vouch Proxy的日志关注/validate端点的请求和响应看JWT是否被正确识别和验证。问题二认证成功但后端应用收不到用户头信息症状可以登录并访问应用但应用的日志里看不到X-Vouch-User等头部。排查步骤检查Nginx变量作用域确保auth_request_set指令是放在location /validate块内并且proxy_set_header指令是放在location /块内。变量在Nginx中通常有确定的作用域。直接检查/validate响应使用curl命令模拟请求查看Vouch Proxy是否返回了正确的头部。# 先获取一个有效的Cookie通过浏览器登录后复制 # 然后使用curl测试 curl -v -H Cookie: VouchCookie你的JWT令牌 https://vouch.example.com/validate在响应中你应该能看到X-Vouch-User:这样的头部。如果没有说明Vouch Proxy配置中的headers映射可能有问题。检查Nginx日志在Nginx配置中增加日志记录打印出相关变量的值。location / { # ... proxy_pass 等配置 ... # 记录日志 access_log /var/log/nginx/app1.access.log main; # 在日志格式中添加变量例如在http块中定义 # log_format main $remote_addr - $remote_user [$time_local] $request # $status $body_bytes_sent $http_referer # $http_user_agent $http_x_vouch_user; # 然后在这里就能看到传递的头部值了 }问题三Docker容器中Vouch Proxy无法访问IdP回调地址症状登录IdP后页面卡住或报错Vouch Proxy日志显示无法连接到/auth端点或回调失败。排查步骤检查网络确保Docker容器可以访问外网IdP和宿主机如果IdP回调地址是宿主机的域名。对于Docker Compose默认的网络模式通常没问题。检查回调URL确保oauth.callback_url配置的地址如https://vouch.example.com/auth是公网可访问的并且DNS解析正确指向了运行Nginx和Vouch Proxy的服务器。检查容器时间JWT验证对时间非常敏感。确保Docker宿主机的系统时间是准确的容器会继承宿主机的时钟。运行date命令在容器内外进行对比。问题四登录后访问不同子域的应用仍需重新登录症状在app1.example.com登录后访问app2.example.com又跳转到登录页。排查步骤确认Cookie域名这是最可能的原因。vouch.cookie.domain必须设置为.example.com注意前面的点这表示Cookie对example.com的所有子域都有效。在浏览器中检查两个站点的Cookie看它们的“域”属性是否一致且都是.example.com。检查Nginx配置确保两个应用的Nginx配置中auth_request /validate指向的是同一个Vouch Proxy实例proxy_pass http://127.0.0.1:9090/validate;。当遇到复杂问题时系统化的日志分析是关键。同时查看Vouch Proxy的日志、Nginx的错误日志和访问日志对照着请求流一步步分析大部分问题都能定位。
1. 项目概述与核心价值如果你正在管理一个由多个内部Web应用组成的服务生态比如公司内部的Wiki、GitLab、监控面板、项目管理工具那么“如何让用户只登录一次就能畅通无阻地访问所有应用”这个问题大概率会让你头疼。传统的做法是为每个应用单独配置登录用户得记住一堆账号密码体验差安全性也难统一保障。而“Vouch Proxy与Nginx auth_request模块的完美集成”这个方案正是为了解决这个痛点而生。它本质上是一个基于Nginx反向代理和OAuth/OpenID ConnectOIDC的轻量级、无侵入的单点登录SSO网关。简单来说它的工作模式就像一个“统一的安检门”。所有需要保护的Web应用我们称之为上游应用都躲在Nginx这个“大楼管理员”后面。当用户试图访问任何一个应用时Nginx不会直接放行而是先向部署在旁边的“安检员”——Vouch Proxy——发起一个内部询问“这个人有票吗”这个询问动作就是通过Nginx的auth_request模块发起的。Vouch Proxy检查用户浏览器里的“门票”一个加密的JWT Cookie。如果票有效就告诉Nginx“放行”如果没票或票无效就返回“无权访问”。Nginx收到“无权访问”的信号后会立即把用户重定向到Vouch Proxy的登录页面引导用户去Google、GitHub、Okta等身份提供商IdP那里完成认证。认证成功后Vouch Proxy会签发一张新的“门票”存到用户浏览器并把他送回到最初想访问的应用页面。整个过程对后端应用是透明的应用本身完全不需要知道任何关于OAuth的细节它只需要信任并读取Nginx转发过来的、包含用户身份信息的HTTP头部比如X-Vouch-User这个头部里通常就是用户的邮箱即可。这套方案的核心魅力在于它的“无侵入性”和“低成本”。你不需要改造任何一个现有应用的登录逻辑只需要在流量入口的Nginx层做一次统一的配置。Vouch Proxy本身用Go语言编写资源消耗极低配置也相对简单。对于中小型团队或拥有大量遗留系统、又希望快速实现统一身份认证的场景来说这几乎是最优雅的解决方案之一。接下来我将带你从零开始拆解这套方案的每一个技术细节和配置要点。2. 核心组件深度解析与选型考量在动手之前我们必须彻底理解方案中几个核心组件的工作原理和它们之间的协作关系。这能帮助你在遇到问题时快速定位是哪个环节出了岔子。2.1 Nginx的auth_request模块流量的守门人auth_request模块是Nginx实现子请求认证的基石。它允许Nginx在处理客户端的主请求之前先向另一个内部或外部的URI发起一个认证子请求并根据这个子请求的返回状态码来决定是放行还是拒绝主请求。工作原理定义认证端点在Nginx配置中通过auth_request指令指定一个用于认证的URI例如/validate。发起子请求当客户端请求到达时Nginx会先向这个/validate端点发起一个内部请求子请求。裁决Nginx根据子请求的HTTP状态码做出裁决2xx状态码成功认证通过Nginx继续处理原始请求例如将请求代理到后端应用。401或403状态码认证失败。Nginx会停止处理原始请求并返回错误页面或执行error_page指令定义的错误处理逻辑通常是重定向到登录页。其他状态码如500Nginx默认会返回500错误给客户端。这通常意味着认证服务本身出了问题。关键配置指令解析auth_request 核心指令定义认证子请求的URI。auth_request_set 这是整个方案中信息传递的关键。它允许你将认证子请求即Vouch Proxy/validate端点返回的响应头中的值提取并保存到Nginx变量中。这些变量随后可以在proxy_set_header等指令中使用将用户信息传递给后端应用。# 将Vouch Proxy返回的 X-Vouch-User 响应头赋值给Nginx变量 $auth_resp_x_vouch_user auth_request_set $auth_resp_x_vouch_user $upstream_http_x_vouch_user;error_page 401 error401; 定义当认证子请求返回401时跳转到名为error401的命名location块进行处理通常这里就是重定向到登录页的逻辑。注意auth_request模块默认不包含在Nginx的标准发行版中。对于通过包管理器如apt、yum安装的Nginx通常需要额外安装nginx-extras或nginx-full这类包含第三方模块的包。编译安装时则需要通过--with-http_auth_request_module参数显式启用。你可以通过nginx -V 21 | grep -o with-http_auth_request_module命令来检查你的Nginx是否已包含此模块。2.2 Vouch Proxy轻量级的认证代理与票据中心Vouch Proxy是一个用Go编写的独立HTTP服务它扮演了两个核心角色OAuth/OIDC客户端和JWT票据签发/验证器。作为OAuth/OIDC客户端Vouch Proxy预先在IdP如Google Cloud Console中注册为一个OAuth应用获得client_id和client_secret。当未认证的用户被重定向到Vouch Proxy的/login端点时Vouch Proxy会生成一个随机的state参数防止CSRF攻击并将用户重定向到IdP的授权页面。用户在IdP页面完成登录授权后IdP会将授权码通过回调URL/auth端点传回给Vouch Proxy。Vouch Proxy再用这个授权码与IdP进行服务器对服务器的通信“后端通道”换取用户的身份信息ID Token、Access Token 或调用UserInfo端点。作为JWT票据签发/验证器从IdP获取到用户信息通常是邮箱后Vouch Proxy会使用一个密钥通过vouch.jwt.secret配置或自动生成签发一个JWTJSON Web Token。这个JWT包含了用户的基本信息和过期时间然后被加密后作为一个名为VouchCookie默认的HTTP-Only Cookie设置到用户的浏览器中作用域Domain通常设置为你的主域名如.yourcompany.com以便所有子域名都能共享这个Cookie。当Nginx发起/validate请求时Vouch Proxy会做以下几件事从请求的Cookie中读取JWT。验证JWT的签名是否有效是否过期。可选根据配置的规则如邮箱域名白名单进行额外的授权检查。如果一切有效则返回200状态码并在响应头中带上用户信息如X-Vouch-User: userexample.com。如果无效则返回401状态码。为什么选择Vouch Proxy而不是其他方案市面上有类似的方案比如oauth2_proxy或keycloak-gatekeeper。Vouch Proxy的优势在于与Nginx集成极度简洁专为auth_request模块设计交互协议简单明了。配置直观一个YAML配置文件搞定大部分设置环境变量覆盖也让容器化部署非常方便。对后端应用零侵入应用无需任何OAuth库只需读取HTTP头部。轻量高效Go语言编译的单一二进制文件内存占用小性能好。社区支持与生态支持的主流IdP非常广泛从Google、GitHub到企业级的Okta、Keycloak、Azure AD都涵盖且社区活跃。2.3 身份提供商IdP的选择与准备IdP是整个信任链的源头。你需要根据你的使用场景选择一个并完成前期配置。常见IdP及适用场景Google OAuth 2.0最适合个人项目、初创公司或使用G Suite/Google Workspace的团队。配置简单用户认知度高。GitHub OAuth开发者社区和开源项目首选。可以方便地基于GitHub Organization或Team进行权限控制。Okta / Azure AD (Entra ID)企业级标准提供最完善的身份管理、安全策略如MFA和生命周期管理。Keycloak开源的身份和访问管理解决方案。适合需要完全自托管、高度定制化权限模型和协议的企业。以Google OAuth为例的准备工作访问 Google Cloud Console 。创建一个新项目或选择现有项目。进入“API和服务” - “凭据”。点击“创建凭据” - “OAuth 客户端ID”。应用类型选择“Web 应用”。在“已获授权的重定向 URI”中添加你的Vouch Proxy回调地址格式为https://vouch.yourdomain.com/auth请将vouch.yourdomain.com替换为你计划部署Vouch Proxy的实际域名。创建后记录下“客户端ID”和“客户端密钥”。这两个值将用于Vouch Proxy的配置。实操心得在配置IdP的回调URI时务必确保域名和路径完全准确包括http和https。很多登录循环问题都源于回调地址不匹配。对于本地开发你可能需要配置http://localhost:9090/auth并确保在Vouch配置中设置了vouch.cookie.secure: false。3. 完整部署与配置实战理解了原理我们进入实战环节。我将以最经典的架构为例在同一台服务器上通过Docker运行Vouch Proxy并通过宿主机上的Nginx同时代理Vouch Proxy本身和需要保护的上游应用。3.1 环境与架构准备假设我们有以下设定主域名example.comVouch Proxy服务域名vouch.example.com需要保护的应用域名app1.example.com(运行在localhost:8081),app2.example.com(运行在localhost:8082)服务器已安装Docker, Docker Compose和Nginx。已为vouch.example.com、app1.example.com、app2.example.com申请并配置了有效的SSL证书例如使用Let‘s Encrypt。这是必须的因为OAuth要求HTTPS环境。我们的网络流量走向将是用户浏览器 - HTTPS请求 - Nginx (443端口) - auth_request /validate - Vouch Proxy容器 - 返回认证结果 - Nginx - (若成功)代理到上游应用3.2 Vouch Proxy配置详解首先我们创建Vouch Proxy的配置文件和Docker运行环境。1. 创建目录结构mkdir -p ~/vouch-proxy/config cd ~/vouch-proxy2. 创建核心配置文件config/config.ymlvouch: # 日志级别调试时设为debug生产环境建议info logLevel: info # 测试模式会放慢重定向速度便于调试生产环境设为false testing: false # 允许访问的域名列表支持通配符子域名 domains: - example.com - .example.com # 匹配所有子域名 cookie: # Cookie名称 name: VouchCookie # Cookie作用域设置为根域名以实现跨子域共享 domain: example.com # 是否仅通过HTTPS传输生产环境必须为true secure: true # Cookie有效期默认24小时 maxAge: 14400 # 防止客户端脚本访问增强安全性 httpOnly: true jwt: # JWT签名密钥。非常重要生产环境务必使用强随机字符串。 # 可以通过命令生成openssl rand -base64 32 secret: your_very_strong_and_long_secret_key_here_change_me # JWT的有效期应小于或等于cookie的maxAge maxAge: 14400 # 签发者标识 issuer: Vouch # OAuth/OIDC 提供商配置 oauth: # 提供商类型这里是google provider: google # 在Google Cloud Console创建的客户端ID client_id: your_google_client_id.apps.googleusercontent.com # 在Google Cloud Console创建的客户端密钥 client_secret: your_google_client_secret # 回调URL必须与IdP中配置的完全一致 callback_url: https://vouch.example.com/auth # 申请的权限范围 scopes: - openid - email - profile # Google的特定端点Vouch通常能自动发现但显式指定更可靠 auth_url: https://accounts.google.com/o/oauth2/auth token_url: https://oauth2.googleapis.com/token user_info_url: https://openidconnect.googleapis.com/v1/userinfo # 从userinfo响应中提取用户名的字段通常是email preferred_username: email # 允许的头信息传递给后端应用 headers: # 将认证成功的用户邮箱传递给后端头部名为X-Vouch-User X-Vouch-User: X-Vouch-User # 如果需要也可以传递ID Token或Access Token注意安全 # X-Vouch-IdP-IdToken: X-Vouch-IdP-IdToken # X-Vouch-IdP-AccessToken: X-Vouch-IdP-AccessToken3. 创建docker-compose.yml文件version: 3.8 services: vouch-proxy: image: quay.io/vouch/vouch-proxy:latest container_name: vouch-proxy restart: unless-stopped ports: - 9090:9090 # 映射主机9090端口到容器9090端口 volumes: - ./config:/config # 挂载配置文件目录 environment: # 可以通过环境变量覆盖配置这里设置域名 - VOUCH_DOMAINSexample.com,.example.com # 可选设置容器内用户增强安全性镜像默认用户为vouch, UID 999 # user: 999:9994. 启动Vouch Proxy服务docker-compose up -d检查日志确认服务启动无误docker-compose logs -f vouch-proxy你应该能看到类似msg:started listening on的日志表示Vouch Proxy已在容器内的9090端口就绪。3.3 Nginx核心配置解析与实现这是整个集成中最关键的一步。我们需要配置两个Nginxserver块一个用于代理Vouch Proxy本身使其可通过HTTPS访问另一个或多个用于保护我们的上游应用。1. Vouch Proxy自身的Nginx配置 (/etc/nginx/sites-available/vouch.example.com):这个配置让Vouch Proxy服务可以通过https://vouch.example.com被外部访问。server { listen 443 ssl http2; server_name vouch.example.com; # SSL证书路径请替换为你的实际路径 ssl_certificate /etc/letsencrypt/live/vouch.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/vouch.example.com/privkey.pem; # 重要传递原始Host头否则Vouch Proxy无法正确设置Cookie的domain proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; location / { # 代理到运行在本地9090端口的Vouch Proxy容器 proxy_pass http://127.0.0.1:9090; # 确保传递请求体虽然/auth等端点需要但/validate不需要 proxy_pass_request_body on; proxy_set_header Content-Length $content_length; } }2. 受保护应用的Nginx配置 (/etc/nginx/sites-available/app1.example.com):这个配置为app1.example.com添加了Vouch Proxy认证层。server { listen 443 ssl http2; server_name app1.example.com; ssl_certificate /etc/letsencrypt/live/app1.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/app1.example.com/privkey.pem; root /var/www/html/app1; # 你的应用根目录 index index.html index.htm; # 核心对所有请求启用认证子请求 auth_request /validate; # 认证端点配置 location /validate { # 内部转发到Vouch Proxy的验证接口 proxy_pass http://127.0.0.1:9090/validate; proxy_set_header Host $http_host; # 传递原始Host头至关重要 # Vouch Proxy的/validate端点不处理请求体可以关闭以提高性能 proxy_pass_request_body off; proxy_set_header Content-Length ; # 从Vouch Proxy的响应头中提取信息并存入Nginx变量 # 提取用户标识通常是邮箱 auth_request_set $auth_resp_x_vouch_user $upstream_http_x_vouch_user; # 提取错误信息用于调试 auth_request_set $auth_resp_err $upstream_http_x_vouch_err; # 提取JWT令牌可用于自定义错误页 auth_request_set $auth_resp_jwt $upstream_http_x_vouch_jwt; # 提取失败计数 auth_request_set $auth_resp_failcount $upstream_http_x_vouch_failcount; # 如果需要传递自定义声明如用户组可以这样设置 # auth_request_set $auth_resp_x_vouch_idp_claims_groups $upstream_http_x_vouch_idp_claims_groups; } # 处理401未授权错误重定向到登录页 error_page 401 error401; location error401 { # 构造重定向URL跳转到Vouch Proxy的登录页面 # $scheme://$http_host$request_uri 会拼出用户最初请求的完整URL # Vouch Proxy会在登录成功后将用户带回这个URL return 302 https://vouch.example.com/login?url$scheme://$http_host$request_urivouch-failcount$auth_resp_failcountX-Vouch-Token$auth_resp_jwterror$auth_resp_err; } # 应用本身的反向代理配置 location / { # 代理到实际的应用服务器 proxy_pass http://127.0.0.1:8081; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 将从Vouch Proxy获取的用户信息通过HTTP头传递给后端应用 proxy_set_header X-Vouch-User $auth_resp_x_vouch_user; # 如果需要也可以传递自定义声明 # proxy_set_header X-Vouch-IdP-Claims-Groups $auth_resp_x_vouch_idp_claims_groups; # 注意$auth_resp_x_vouch_user 等变量是在上面的 location /validate 块中通过 auth_request_set 设置的。 # 根据Nginx的变量作用域规则这些变量在 location / 块中是可用的。 } }3. 启用配置并重载Nginx# 创建符号链接假设使用sites-enabled/sites-available模式 sudo ln -s /etc/nginx/sites-available/vouch.example.com /etc/nginx/sites-enabled/ sudo ln -s /etc/nginx/sites-available/app1.example.com /etc/nginx/sites-enabled/ # 测试Nginx配置语法 sudo nginx -t # 确认无误后重载Nginx使配置生效 sudo systemctl reload nginx3.4 验证与测试流程配置完成后必须进行系统性的测试。直接访问受保护应用在浏览器中打开https://app1.example.com。你应该会被立即重定向到https://vouch.example.com/login并很快跳转到Google的登录页面或其他你配置的IdP。完成登录使用你的Google账号登录并授权。重定向与访问授权成功后浏览器会被重定向回https://app1.example.com此时你应该能正常访问应用。验证单点登录在同一个浏览器中打开一个新的标签页访问https://app2.example.com假设你为app2配置了相同的保护。你应该无需再次登录直接就能访问。这说明Cookie在example.com域下共享成功。检查用户信息传递你可以在你的应用如一个简单的测试PHP页面或查看应用日志中检查收到的HTTP头应该能看到X-Vouch-User: your-emailgmail.com这样的头部。4. 高级配置、优化与故障排查基础流程跑通后我们可以根据实际需求进行优化和深度定制。4.1 安全加固与最佳实践使用强JWT Secret永远不要使用示例中的默认密钥。使用openssl rand -base64 32生成一个强随机字符串并妥善保管。限制Cookie作用域vouch.cookie.domain应设置为尽可能具体的范围。如果所有应用都在.internal.example.com下就设置为.internal.example.com而不是顶级的example.com以减少攻击面。启用HTTPS和Secure Cookie生产环境必须使用HTTPS并确保vouch.cookie.secure: true。配置IdP的授权范围在IdP如Google的应用配置中限制重定向URI只允许你的Vouch Proxy域名并定期审查已授权的应用。使用白名单Vouch Proxy支持通过vouch.allowAllUsers: false和vouch.whitelist或vouch.domains来限制只有特定邮箱或邮箱域的用户可以登录。这对于内部工具至关重要。vouch: allowAllUsers: false whitelist: - your-teamexample.com - adminexample.com # 或者使用域名白名单 # domains: # - example.com # - another-allowed-domain.com4.2 性能优化为/validate端点添加缓存每次请求都触发一次对Vouch Proxy的/validate调用可能会增加延迟。Nginx的auth_request模块可以与proxy_cache结合对认证结果进行短期缓存。http { # 定义一个缓存路径和区域 proxy_cache_path /var/cache/nginx/auth_cache levels1:2 keys_zoneauth_cache:10m inactive10m max_size100m; server { server_name app1.example.com; # ... 其他ssl等配置 ... auth_request /validate; location /validate { proxy_pass http://127.0.0.1:9090/validate; proxy_set_header Host $http_host; proxy_pass_request_body off; proxy_set_header Content-Length ; # 启用缓存使用$cookie_VouchCookie作为缓存键 proxy_cache auth_cache; proxy_cache_key $cookie_VouchCookie; proxy_cache_valid 200 10m; # 认证成功的结果缓存10分钟 proxy_cache_valid 401 1m; # 认证失败的结果缓存1分钟防止暴力重试 proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504; # 如果Vouch Proxy服务不可用允许使用陈旧的缓存谨慎使用 # proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504; # ... auth_request_set 变量提取 ... } # ... 其他配置 ... } }注意缓存认证状态是一把双刃剑。它提升了性能但也意味着用户在Vouch Proxy侧登出或会话过期后在缓存有效期内可能仍被Nginx认为是已登录状态。请根据你的安全要求权衡缓存时间。4.3 传递丰富的用户信息与声明除了基本的邮箱你可能需要将用户的姓名、部门、组等信息传递给后端应用。这需要在Vouch Proxy和Nginx配置中都进行设置。1. 在Vouch Proxy配置中请求更多Scope和映射Claimoauth: provider: google client_id: ... client_secret: ... scopes: - openid - email - profile # 请求profile scope以获取姓名等信息 # 假设你的IdP如Keycloak返回了‘groups’声明 # scopes: # - openid # - email # - profile # - groups headers: X-Vouch-User: X-Vouch-User # 邮箱 # 映射IdP返回的‘name’声明到‘X-Vouch-IdP-Claims-Name’头部 X-Vouch-IdP-Claims-Name: name # 映射IdP返回的‘groups’声明到‘X-Vouch-IdP-Claims-Groups’头部 X-Vouch-IdP-Claims-Groups: groups2. 在Nginx配置中提取并传递这些头部location /validate { proxy_pass ...; # ... 其他配置 ... auth_request_set $auth_resp_x_vouch_user $upstream_http_x_vouch_user; auth_request_set $auth_resp_x_vouch_idp_claims_name $upstream_http_x_vouch_idp_claims_name; auth_request_set $auth_resp_x_vouch_idp_claims_groups $upstream_http_x_vouch_idp_claims_groups; } location / { proxy_pass ...; proxy_set_header X-Vouch-User $auth_resp_x_vouch_user; proxy_set_header X-Vouch-IdP-Claims-Name $auth_resp_x_vouch_idp_claims_name; proxy_set_header X-Vouch-IdP-Claims-Groups $auth_resp_x_vouch_idp_claims_groups; }这样你的后端应用就能收到包含完整用户信息的头部进而实现更精细的权限控制。4.4 常见故障排查实录即使按照步骤操作也难免会遇到问题。以下是几个最常见的问题及其解决方法。问题一无限重定向循环症状浏览器在IdP登录页面和你的应用之间来回跳转无法进入应用。排查步骤检查Cookie域名这是最常见的原因。确保vouch.cookie.domain设置正确并且Vouch Proxy服务vouch.example.com和受保护应用app1.example.com共享同一个父域名或子域名且Cookie域名设置为此父域如.example.com。在浏览器开发者工具的“应用”-“Cookie”选项卡中检查VouchCookie是否被正确设置在了预期的域名下。检查Host头在Nginx代理Vouch Proxy的配置中必须包含proxy_set_header Host $http_host;。缺少这个头部Vouch Proxy可能无法正确生成和验证Cookie。检查HTTPS和Secure标志如果本地开发使用HTTP确保vouch.cookie.secure设置为false。生产环境必须为true且使用HTTPS。开启调试模式在Vouch Proxy配置中设置vouch.logLevel: debug和vouch.testing: true。后者会减慢重定向速度让你有机会观察浏览器地址栏的变化。查看Vouch Proxy的日志关注/validate端点的请求和响应看JWT是否被正确识别和验证。问题二认证成功但后端应用收不到用户头信息症状可以登录并访问应用但应用的日志里看不到X-Vouch-User等头部。排查步骤检查Nginx变量作用域确保auth_request_set指令是放在location /validate块内并且proxy_set_header指令是放在location /块内。变量在Nginx中通常有确定的作用域。直接检查/validate响应使用curl命令模拟请求查看Vouch Proxy是否返回了正确的头部。# 先获取一个有效的Cookie通过浏览器登录后复制 # 然后使用curl测试 curl -v -H Cookie: VouchCookie你的JWT令牌 https://vouch.example.com/validate在响应中你应该能看到X-Vouch-User:这样的头部。如果没有说明Vouch Proxy配置中的headers映射可能有问题。检查Nginx日志在Nginx配置中增加日志记录打印出相关变量的值。location / { # ... proxy_pass 等配置 ... # 记录日志 access_log /var/log/nginx/app1.access.log main; # 在日志格式中添加变量例如在http块中定义 # log_format main $remote_addr - $remote_user [$time_local] $request # $status $body_bytes_sent $http_referer # $http_user_agent $http_x_vouch_user; # 然后在这里就能看到传递的头部值了 }问题三Docker容器中Vouch Proxy无法访问IdP回调地址症状登录IdP后页面卡住或报错Vouch Proxy日志显示无法连接到/auth端点或回调失败。排查步骤检查网络确保Docker容器可以访问外网IdP和宿主机如果IdP回调地址是宿主机的域名。对于Docker Compose默认的网络模式通常没问题。检查回调URL确保oauth.callback_url配置的地址如https://vouch.example.com/auth是公网可访问的并且DNS解析正确指向了运行Nginx和Vouch Proxy的服务器。检查容器时间JWT验证对时间非常敏感。确保Docker宿主机的系统时间是准确的容器会继承宿主机的时钟。运行date命令在容器内外进行对比。问题四登录后访问不同子域的应用仍需重新登录症状在app1.example.com登录后访问app2.example.com又跳转到登录页。排查步骤确认Cookie域名这是最可能的原因。vouch.cookie.domain必须设置为.example.com注意前面的点这表示Cookie对example.com的所有子域都有效。在浏览器中检查两个站点的Cookie看它们的“域”属性是否一致且都是.example.com。检查Nginx配置确保两个应用的Nginx配置中auth_request /validate指向的是同一个Vouch Proxy实例proxy_pass http://127.0.0.1:9090/validate;。当遇到复杂问题时系统化的日志分析是关键。同时查看Vouch Proxy的日志、Nginx的错误日志和访问日志对照着请求流一步步分析大部分问题都能定位。
)
