Apache 通过 ProxyPassReverseCookieDomain 和 ProxyPassReverseCookiePath 指令修正后端 Cookie 的 Domain 和 Path，解决跨域登录态丢失问题；需配合 ProxyPreserveHost、ProxyPassReverse 及后端 Cookie 属性（Secure、SameSite=None）共同生效。
apache 反向代理本身不直接提供类似 nginx 的 proxy_cookie_domain 或 proxy_cookie_path 指令，但它通过一组配套的 proxypassreverse* 指令，能有效修正后端返回的 cookie 域名（domain）和路径（path），从而解决跨域场景下浏览器拒绝保存或发送 cookie 导致的登录态丢失问题。
用 ProxyPassReverseCookieDomain 统一 Cookie 域名
当后端（如 Spring Boot 或 Tomcat）返回 Set-Cookie: sessionid=xxx; Domain=localhost 时，前端页面运行在 app.example.com 下，浏览器因域名不匹配而丢弃该 Cookie。Apache 可在响应发出前重写 Domain 属性：
- 在对应
<Location>或虚拟主机配置中添加：ProxyPassReverseCookieDomain localhost .example.com - 注意前导点：
.example.com表示通配所有子域（app.example.com、api.example.com），浏览器才允许在这些域名下读写该 Cookie - 若后端返回的是 IP（如
Domain=192.168.1.10）或空值，同样可用此指令覆盖为合法公网域名
用 ProxyPassReverseCookiePath 限定 Cookie 作用路径
多个后端应用共用同一域名时（如 /app1/ 和 /app2/），若都返回 Path=/，浏览器会在任意路径下发送同一个 Cookie，造成 Session 污染。Apache 可按代理路径隔离：
- 对
/app1/代理块内加：ProxyPassReverseCookiePath / /app1/ - 对
/app2/代理块内加：ProxyPassReverseCookiePath / /app2/ - 效果：后端原
Set-Cookie: JSESSIONID=abc; Path=/→ 浏览器收到Path=/app1/，只在/app1/开头的请求中自动携带 - ⚠️ 路径末尾斜杠必须一致（
/app1/≠/app1），否则浏览器可能不匹配
配合关键基础配置才能生效
仅改 Cookie 的 Domain 和 Path 不够，还需确保整个链路支持凭据传递：
-
启用凭证透传：添加
ProxyPreserveHost On，并确保后端响应含Access-Control-Allow-Credentials: true且Access-Control-Allow-Origin是具体域名（不能是*） -
前端请求带 credentials：JavaScript 中使用
fetch(url, { credentials: 'include' })或xhr.withCredentials = true -
Cookie 自身属性合规：后端设置 Cookie 时需带
Secure（HTTPS 环境必需）和SameSite=None（Chrome 80+ 要求），Apache 不修改这些属性，需后端配合 - 不可省略 ProxyPassReverse：它不仅修正重定向 Location，也参与 Cookie 头处理逻辑；漏掉会导致后端重定向跳转到内网地址，间接破坏 Cookie 上下文
常见失效原因排查
如果配置后 Cookie 仍丢失，优先检查以下几点：
- 打开浏览器开发者工具 → Application → Cookies，确认实际收到的 Cookie 的 Domain 和 Path 是否已按预期被重写
- 用
curl -v https://your-domain.com/api/login查看原始响应头，确认后端是否真的返回了Set-Cookie，以及原始 Domain/Path 值 - 确认 Apache 已加载
mod_proxy和mod_proxy_http，且配置写在 虚拟主机或主配置中（.htaccess不支持ProxyPassReverse*） - 若代理路径含版本号（如
/v2/api），确保ProxyPass和ProxyPassReverseCookiePath的路径前缀完全一致，避免拼接错误
