Apache mod_proxy本身不处理凭证验证，只负责转发请求；透传客户端认证头需用RequestHeader set Authorization %{HTTP:Authorization}e early，注入固定凭证则用RequestHeader set X-API-Key "sK-9a3f8c1e" early，并确保mod_headers启用且加early标志。

apache mod_proxy 本身不处理凭证验证，它只负责转发请求。要实现“凭证转发验证”，实际是指两种常见场景：一是把客户端携带的认证凭据（如 authorization、cookie）原样透传给后端；二是 apache 主动注入固定凭证（如 api key）并拦截/校验客户端请求。两者配置逻辑不同，但都依赖 mod_headers 和正确的代理头控制。

透传客户端原始凭证（如 Basic Auth、Bearer Token）

默认情况下，Apache 会保留大部分请求头，但某些安全敏感头（如 Authorization）在启用某些认证模块时可能被自动清除。若后端依赖这些头做鉴权，需显式确保它们不被丢弃：

• 确认未启用 mod_auth_basic 或 mod_auth_digest 等前端认证模块——否则 Apache 会提前消费 Authorization 头，不再转发
• 在 <VirtualHost> 中添加：
  RequestHeader unset Authorization early
  这行不是删除，而是防止其他模块干扰；接着再用下一行确保它被正常传递：
  RequestHeader set Authorization %{HTTP:Authorization}e early
• 对 Cookie 透传，一般无需额外操作，但若后端依赖特定 Cookie 域名或路径，可配合 ProxyPassReverseCookieDomain 和 ProxyPassReverseCookiePath 重写

主动注入固定凭证并校验请求来源

更常见的“凭证转发验证”其实是网关级行为：Apache 不信任客户端传来的任何认证头，而是统一注入自己的可信凭证，并可选地校验请求是否来自合法上游（如内网 IP、特定域名、或带预共享密钥的 Header）：

CPA Update - Secure CLI Proxy API Maintenance

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

下载

• 启用 mod_headers 模块（Debian：a2enmod headers；RHEL：取消 mod_headers.so 注释）
• 在 <VirtualHost> 中注入凭证：
  RequestHeader set X-API-Key "sK-9a3f8c1e" early
RequestHeader set X-Internal-Source "apache-gw-prod" early
• 若需校验客户端是否携带合法令牌，可用 mod_rewrite 配合环境变量判断：
  RewriteCond %{HTTP:X-Forwarded-For} ^10\.0\.0\.[0-9]+$ [OR]
RewriteCond %{HTTP:X-Api-Signature} ^[a-f0-9]{32}$
RewriteRule ^ - [E=VALID_CRED:1]
  再用 Require env VALID_CRED 控制访问

避免凭证泄露与误覆盖的关键细节

凭证类头极易因配置顺序或模块冲突而失效：

• RequestHeader set ... early 是必须的——不加 early 标志，头可能在代理阶段已被跳过
• 不要尝试设置 Host 头：RequestHeader set Host ... 是非法操作，Apache 会直接报错
• 若后端是 HTTPS，且需代理到带证书验证的地址，加上：
  SSLProxyVerify none
SSLProxyCheckPeerCN off
  （仅限测试或内网环境；生产建议用真实证书并开启校验）
• 所有凭证字符串建议从环境变量读取（通过 Define 或系统级 envvars），避免硬编码在配置文件中

凭证转发验证不是开箱即用的功能，它需要你明确区分“透传”和“注入”两种意图，并围绕后端服务的实际鉴权方式来组织 Apache 配置。核心始终是头信息的可控流转，而不是让 Apache 自己做密码比对。