HttpHeadersFilter

HttpHeadersFilter是用来处理传递到下游微服务的请求头

要理解“传递到下游微服务的请求头”，需要先明确 “上游”“下游” 的概念，再结合网关（如Spring Cloud Gateway）的角色，拆解“请求头传递”的核心逻辑和实际意义，最终结合你提到的XForwardedHeadersFilter案例加深理解。

概念

在微服务架构中，请求的流转存在清晰的“方向”，这是理解“下游”的基础：

• 上游（Upstream）：发起请求的一方。比如用户浏览器、移动端App，或调用其他服务的“调用方服务”。
• 下游（Downstream）：接收并处理请求的一方。通常是最终提供业务功能的微服务（如订单服务、用户服务）。

而 Spring Cloud Gateway 的角色是“网关”——所有上游请求不会直接打给下游微服务，而是先经过网关，再由网关“转发”到对应的下游微服务。此时，网关既是上游的“接收方”，也是下游的“调用方”。

核心逻辑

请求头（HTTP Headers）是HTTP请求中携带的“元数据”，用于描述请求的额外信息（如Host表示请求的目标域名、Authorization表示用户令牌、Content-Type表示请求体格式等）。

“传递到下游微服务的请求头”，本质是：

网关在接收上游请求后，会将上游请求头中的部分或全部信息，“复制”或“处理后”添加到网关发给下游微服务的新请求中，确保下游微服务能获取到必要的元数据，从而正确处理请求。

为什么需要传递请求头？

如果网关不传递请求头，下游微服务会丢失关键信息，导致业务异常。举两个典型场景：

场景1：下游需要知道“用户真实请求的域名（Host）”

用户通过浏览器访问 https://api.example.com/order（这是网关的域名），网关再转发到下游的“订单服务”（地址可能是内网的 http://order-service:8080）。

• 上游发给网关的请求头中，Host 是 api.example.com（用户真实访问的域名）；
• 如果网关不传递 Host 头，下游订单服务收到的请求中，Host 会变成 order-service:8080（网关转发时的目标地址）；
• 若订单服务需要根据 Host 区分环境（如 api.example.com 是生产，test-api.example.com 是测试），就会因为 Host 丢失而判断错误。

场景2：下游需要验证“用户身份令牌（Authorization）”

用户登录后，浏览器会在请求头中携带 Authorization: Bearer xxx（令牌），发送给网关；

• 网关本身可能不验证令牌（仅负责路由），而是需要将 Authorization 头传递给下游的“用户服务”或“订单服务”；
• 下游服务收到 Authorization 头后，会解析令牌验证用户身份，若网关不传递该头，下游会认为“用户未登录”，直接返回401错误。

XForwardedHeadersFilter理解具体实现

你提到的 org.springframework.cloud.gateway.filter.headers.XForwardedHeadersFilter，是Spring Cloud Gateway中专门处理“代理相关请求头”的过滤器，它解决的核心问题是：让下游微服务知道“请求的真实来源”（因为经过网关代理后，原始信息会被覆盖）。

它会自动向下游传递一组以 X-Forwarded- 开头的请求头，最常用的包括：

请求头名称	作用说明
X-Forwarded-Host	传递上游请求的真实 Host（如用户访问的 api.example.com）
X-Forwarded-For	传递请求的真实IP地址（避免下游看到的是网关的IP，而非用户的真实IP）
X-Forwarded-Proto	传递请求的真实协议（如 https，避免下游看到的是网关与下游通信的 http）

示例：XForwardedHeadersFilter的流转过程

1.用户通过浏览器发送请求：https://api.example.com/order，请求头包含 Host: api.example.com，用户IP是 123.123.123.123；

2.网关（地址 192.168.1.100）接收请求，XForwardedHeadersFilter 自动添加3个请求头：

• X-Forwarded-Host: api.example.com（真实Host）
• X-Forwarded-For: 123.123.123.123（真实用户IP）
• X-Forwarded-Proto: https（真实协议）

3.网关将请求转发到下游订单服务（地址 http://order-service:8080），此时发给订单服务的请求头中，除了原始必要头（如 Authorization），还包含上述3个 X-Forwarded- 头；

4.下游订单服务读取 X-Forwarded-Host 就知道用户真实访问的是 api.example.com，读取 X-Forwarded-For 就知道用户IP是 123.123.123.123，从而正确处理业务逻辑。

总结

“传递到下游微服务的请求头”，本质是网关作为“请求中转站”，将上游请求中对下游业务有用的元数据（如身份令牌、真实域名、真实IP），转发给最终处理请求的微服务，避免因网关代理导致关键信息丢失，确保下游微服务能正确识别请求来源、验证身份、区分环境等，是微服务架构中请求正常流转的关键环节。