Spring Cloud Gateway rewritePath路径重写未按预期生效排查

核心矛盾点 #

你提供的Netty出站请求debug日志，解码后实际发送的请求行是GET /xyz/data/getNext?page=0&size=100&createdBefore=2021-01-29T23%3A59%3A59.999%2B08%3A00&createdAfter=2021-01-29，已经完全去掉了原始请求的/api/out前缀。
这说明Spring Cloud Gateway层面的路径重写逻辑实际已经执行完成，不存在“网关始终按原始URL路由”的情况，你感知到的路由异常，是后续链路的问题导致的。

高频触发原因 #

• 自定义过滤器逻辑覆盖了路径变更
  当前配置的过滤器链路执行顺序中，rewritePath是Spring Cloud Gateway内置过滤器，默认Order值为1，执行优先级极高。如果链路中的自定义this::filter方法在实现时，直接从原始ServerHttpRequest对象重新构建请求，没有将已经修改过的路径上下文随ServerWebExchange透传，就会把重写后的路径覆盖回原始值。
  你提到相同重写逻辑在其他端点运行正常，本质是其他路由链路没有加入这个会重建请求的自定义过滤器，不存在路径被覆盖的问题。
• 目标URI配置携带冗余前缀
  如果.uri(uri)配置的目标地址本身带了/api/out后缀（比如写为http://external-url/api/out），哪怕网关把请求路径里的/api/out移除，最终拼接的完整请求地址还是会变成http://external-url/api/out/xyz/data/getNext，直接抵消路径重写的效果。
• 下游服务链路存在反向路径拼接
  下游服务本身、或者下游前置的Nginx/网关组件，如果配置了路径拼接规则，会把收到的无/api/out前缀的请求，重新补上前缀再做内部路由，最终让你产生“重写没生效”的错觉。这种情况网关发出去的请求实际已经是重写后的状态，问题完全出在下游链路。

快速验证步骤 #

• 临时注释掉自定义的this::filter过滤器，重新发请求测试。如果重写效果立刻恢复，即可定位是自定义过滤器的上下文透传问题。
• 检查.uri(uri)的配置值，确认目标地址没有携带/api/out的冗余路径前缀。
• 直接用curl向http://external-url/xyz/data/getNext发请求，验证下游服务是否能正常响应。如果返回404，说明下游路由没有匹配无/api/out前缀的路径，需要调整下游配置。
• 调整过滤器链路顺序，把.rewritePath("/api/out", "")移动到所有自定义过滤器的最前面，强制路径重写在自定义逻辑执行前完成，观察是否恢复正常。

内容的提问来源于stack exchange，提问作者Ruchira Gayan Ranaweera