ProxyAddHeaders默认开启但不自动添加X-Forwarded-Proto，因其仅处理Server、Via及X-Forwarded-For基础头，不感知SSL状态；必须手动配置RequestHeader set X-Forwarded-Proto "https"等，并确保后端框架（如Spring Boot）启用信任代理机制解析该头。
ProxyAddHeaders 默认是开启的，它本身不负责透传 SSL 信息——真正起作用的是你手动设置的 X-Forwarded-Proto、X-Forwarded-Port 等头，以及后端是否信任并解析它们。
为什么 ProxyAddHeaders 不会自动加 X-Forwarded-Proto
Apache 的 ProxyAddHeaders 只控制是否自动添加 Server、Via、X-Forwarded-For 这类基础代理头，它不会自动推断或注入协议/端口信息。哪怕你用 HTTPS 访问 Apache，它也不会主动加 X-Forwarded-Proto: https —— 这必须显式配置。
-
ProxyAddHeaders on（默认）仅表示：如果后端返回了Server或Via头，Apache 会保留；同时会在请求发往后端时自动补上X-Forwarded-For（基于$remote_addr） - 它不读取当前连接的 SSL 状态，也不感知
SSLEngine on是否启用 - 所以即使
ProxyAddHeaders开着，后端仍可能收到X-Forwarded-Proto: http或压根没这个头，导致 Spring Security 重定向回 HTTP
必须手动 set X-Forwarded-Proto 和 X-Forwarded-Port
在
RequestHeader set X-Forwarded-Proto "https" RequestHeader set X-Forwarded-Port "443"
- 不要依赖
%{HTTPS}e或%{SERVER_PORT}e动态取值——在mod_proxy转发路径中，这些变量可能不反映客户端真实上下文 - 如果同一个
VirtualHost同时处理 HTTP 和 HTTPS（比如强制跳转），请用 - 若后端监听非标准 HTTPS 端口（如 8443），
X-Forwarded-Port必须写实际端口，不能写 443
后端不识别 X-Forwarded-* 头的典型表现
Spring Boot 日志里反复出现 Redirecting to http://example.com/login，或者登录后 Cookie 缺少 Secure 标志——这说明后端根本没把请求当 HTTPS 处理。
- Spring Boot 2.6+ 必须配
server.forward-headers-strategy=framework，仅靠server.tomcat.remoteip.remote-ip-header=X-Forwarded-For不够 - Tomcat 原生部署需在
server.xml的Connector中加：scheme="https" secure="true" proxyPort="443" - Java 应用若用了
HttpServletRequest.getScheme()，它返回的是容器解析后的结果，不是原始请求协议——必须靠框架层解析头来覆盖
容易被忽略的坑：X-Forwarded-Host 与 Host 头冲突
如果你还用了 ProxyPreserveHost on，又手动 RequestHeader set Host ...，就可能让后端收到两个 Host 头，引发 400 或路由错乱。
-
ProxyPreserveHost on会让 Apache 把客户端发来的Host头原样转发给后端（推荐开启，保证虚拟主机路由正确） - 此时不要再用
RequestHeader set Host ...覆盖它，否则破坏原始 Host - 如果后端需要知道原始域名（比如生成绝对 URL），应依赖
X-Forwarded-Host，而不是篡改Host - 必要时加：
RequestHeader set X-Forwarded-Host %{HTTP_HOST}e，但只在VirtualHost里做，别放全局
最常出问题的地方不在 Apache 配置本身，而在于后端框架是否真正启用了对 X-Forwarded-* 的信任和解析——光加头没用，后端不认，一切白搭。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
