proxy 代理不维护拦截器状态，仅作无状态中转；状态维护由后端应用（如 spring boot）的拦截器或过滤器承担，proxy 只负责安全透传认证信息（如 authorization、cookie）并支持必要头重写。

Proxy 代理本身不维护拦截器状态，它只是请求/响应的中转层。真正负责状态维护的是后端应用（如 Spring Boot）中的拦截器或过滤器，而 Proxy（比如 Nginx、Spring Cloud Gateway 或自定义反向代理）只做路由、转发、头信息修改等无状态操作。

Proxy 不持有登录态或用户上下文

Proxy 层通常不解析 Session、JWT 或 Cookie 内容，也不参与认证逻辑。它不会：

• 读取并校验 JWT token 的签名或过期时间
• 从 Cookie 中提取 session ID 并查 Redis 或内存 Session 存储
• 在请求链路中设置或传递用户身份对象（如 User 对象）

这些职责应由业务服务端（如 Spring Boot 应用）通过拦截器（HandlerInterceptor）或过滤器（Filter）完成。

Proxy 可协助传递和透传认证信息

虽然 Proxy 不维护状态，但可确保认证凭证完整、安全地抵达后端：

CPA Update - Secure CLI Proxy API Maintenance

安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。

下载

• 转发原始 Authorization 请求头（含 Bearer Token）
• 保留 Cookie（包括 JSESSIONID 或自定义登录标识）不被丢弃或覆盖
• 必要时重写 Header（如添加 X-Forwarded-User、X-Real-IP），供后端日志或权限判断使用
• 对敏感 Header（如 Authorization）做白名单透传，避免被 Proxy 默认剥离

状态维护必须由后端拦截器承担

以 Spring Boot 为例，登录态的实际维护依赖于：

• Session 方式：拦截器调用 request.getSession() 获取会话，检查 session.getAttribute("loginUser") 是否存在
• JWT 方式：拦截器解析 Authorization 头中的 token，验证签名与有效期，再将解析出的用户信息存入 SecurityContextHolder 或 ThreadLocal
• Redis + Token 绑定：拦截器校验 token 后，查询 Redis 确认是否有效且未被主动退出

这些逻辑全部发生在业务服务内部，Proxy 仅作为通道存在——它不感知、不干预、不缓存这些状态。

常见误用与避坑点

开发者有时会误以为 Proxy 能“保持登录”，结果出现以下问题：

• Nginx 默认不转发带 Cookie 的跨域请求 → 前端需设 credentials: 'include'，Nginx 需配 add_header 'Access-Control-Allow-Credentials' 'true';
• Spring Cloud Gateway 默认不透传 Authorization → 需显式配置 filters: - SetRequestHeader=Authorization, {token} 或启用全局透传
• 代理层做了负载均衡但 Session 未共享 → 后端需用 Redis 存储 Session，而非依赖单机内存
• 前端把 token 存 localStorage，但 Proxy 没有转发该 header → 后端拦截器始终拿不到 token，判定未登录

归根结底，状态不在 Proxy，而在你写的拦截器里；Proxy 只负责别把它弄丢。