X-Forwarded-For not forwarded correctly by Spring Cloud Gateway 4.3.0 after upgrading to Spring Cloud 2025.

[axeon]

Hi spring cloud gateway team,

After upgrading to Spring Cloud 2025, I found that Spring Cloud Gateway 4.3.0 does not correctly forward the X-Forwarded-For header.

Expected behavior:
Spring Cloud Gateway should forward the real client IP in X-Forwarded-For to microservices.

Actual behavior:
Using tcpdump, I observed that Gateway WebFlux 4.3.0 (included in Spring Cloud 2025) does not forward X-Forwarded-For at all.

Configuration tried:
I set the following property as suggested in the docs:

spring.cloud.gateway.server.webflux.trusted-proxies=10\.\\d{1,3}\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3}|169\.254\.\d{1,3}\.\d{1,3}|127\.\d{1,3}\.\d{1,3}\.\d{1,3}|100\.6[4-9]{1}\.\d{1,3}\.\d{1,3}|100\.[7-9]{1}\d{1}\.\d{1,3}\.\d{1,3}|100\.1[0-1]{1}\d{1}\.\d{1,3}\.\d{1,3}|100\.12[0-7]{1}\.\d{1,3}\.\d{1,3}|172\.1[6-9]{1}\.\d{1,3}\.\d{1,3}|172\.2[0-9]{1}\.\d{1,3}\.\d{1,3}|172\.3[0-1]{1}\.\d{1,3}\.\d{1,3}|0:0:0:0:0:0:0:1|::1|fe[89ab]\p{XDigit}:.*|f[cd]\p{XDigit}{2}:.*+

But it has no effect.

As I understand, this config is for trusting other proxies. In my case, users access Spring Cloud Gateway directly (no proxy).

Question:
How can I configure Spring Cloud Gateway so that it always forwards the real client IP as X-Forwarded-For to downstream services?
Thanks!!!

[axeon]

application.yaml

server:
  port: 443
  http2:
    enabled: true
  shutdown: graceful
  forward-headers-strategy: NATIVE
  compression:
    enabled: true
  error:
    include-message: always
  ssl:
    certificate: "classpath:/cert/default/cert.crt"
    certificate-private-key: "classpath:/cert/default/private.key"

spring:
  cloud:
    config:
      allow-override: true
      override-none: true
    gateway:
      server:
        webflux:
          trusted-proxies: "10\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}|192\\.168\\.\\d{1,3}\\.\\d{1,3}|169\\.254\\.\\d{1,3}\\.\\d{1,3}|127\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}|100\\.6[4-9]{1}\\.\\d{1,3}\\.\\d{1,3}|100\\.[7-9]{1}\\d{1}\\.\\d{1,3}\\.\\d{1,3}|100\\.1[0-1]{1}\\d{1}\\.\\d{1,3}\\.\\d{1,3}|100\\.12[0-7]{1}\\.\\d{1,3}\\.\\d{1,3}|172\\.1[6-9]{1}\\.\\d{1,3}\\.\\d{1,3}|172\\.2[0-9]{1}\\.\\d{1,3}\\.\\d{1,3}|172\\.3[0-1]{1}\\.\\d{1,3}\\.\\d{1,3}|0:0:0:0:0:0:0:1|::1|fe[89ab]\\p{XDigit}:.*|f[cd]\\p{XDigit}{2}:.*+"
          globalcors:
            add-to-simple-url-handler-mapping: true
            cors-configurations:
              "[/**]":
                allowCredentials: true
                allowedOriginPatterns: "*"
                allowedMethods: "*"
                allowedHeaders: "*"
          metrics:
            enabled: false
          discovery:
            locator:
              enabled: true
              lower-case-service-id: true
      
management:
  endpoints:
    enabled-by-default: false

[spencergibb]

I am unable to replicate this issue. I plugged your regex into my existing integration test and it passed. The local test uses localhost 127.0.0.1, which your regex matches and it passes.

If you'd like us to spend more time investigating, please take the time to provide a complete, minimal, verifiable sample (something that we can unzip attached to this issue or git clone, build, and deploy) that reproduces the problem.

[axeon]

After rollback to Spring Boot 3.3.12 & Spring Cloud 2025.0.5, the X-Forward-For header can be passed correctly.
I will gradually remove code and debug step by step to identify the root cause of the issue.

[axeon]

I am unable to replicate this issue. I plugged your regex into my existing integration test and it passed. The local test uses localhost 127.0.0.1, which your regex matches and it passes.

If you'd like us to spend more time investigating, please take the time to provide a complete, minimal, verifiable sample (something that we can unzip attached to this issue or git clone, build, and deploy) that reproduces the problem.

I've identified the root cause.

Spring Cloud Gateway uses XForwardedHeadersFilter to forward the real client IP.
From Spring Cloud Gateway 4.3.0, must configure spring.cloud.gateway.server.webflux.trusted-proxies to enable XForwardedHeadersFilter.
The filter restricts forwarding X-Forwarded headers to requests whose IPs match the trusted proxies, as shown in the code below:

if (request.getRemoteAddress() != null
		&& !trustedProxies.isTrusted(request.getRemoteAddress().getHostString())) {
	log.trace(LogMessage.format("Remote address not trusted. pattern %s remote address %s", trustedProxies,
			request.getRemoteAddress()));
	return input;
}

This causes confusion because as a gateway, typically forward request.getRemoteAddress() to microservices via X-Forwarded-For without any restriction.
X-Forwarded headers from other proxies can be restricted by trusted-proxies, but this should not affect passing the user's IP.
A better approach, similar to Spring Boot, would be to use an internal-proxies property with predefined internal network ranges for compatibility.

Currently, for restore forwarding of the real client IP, I have to set trusted-proxies to [\s\S]*, which defeats its purpose.

Suggestions to improve XForwardedHeadersFilter:

1. Always forward request.getRemoteAddress() as X-Forwarded-For by default, without any restriction.
2. Only validate and forward existing X-Forwarded headers in the request if they pass the trusted-proxies check.

Thanks!

[spencergibb]

Always forward request.getRemoteAddress() as X-Forwarded-For by default, without any restriction.

This will not happen. See this security advisory for details.

[axeon]

Always forward request.getRemoteAddress() as X-Forwarded-For by default, without any restriction.

This will not happen. See this security advisory for details.

In the official preset scenarios of Spring Cloud Gateway, is it only intended to run behind a proxy? If so, your explanation makes sense.

However, given its rich features, Spring Cloud Gateway should ideally serve a role similar to nginx, Caddy, or OpenResty.

Looking forward to further discussions with you.