Microsoft Reverse Proxy 中 Forwarded 标头转换的注意事项

在 Microsoft Reverse Proxy 项目中，Forwarded 请求转换功能存在一个值得开发者注意的行为特性。这个特性会影响代理链中 HTTP 标头的传递方式，特别是在同时使用 Forwarded 和 X-Forwarded 标头时。

问题背景

Reverse Proxy 提供了两种方式来传递代理信息：

1. 标准化的 Forwarded 标头（RFC 7239）
2. 非标准但广泛使用的 X-Forwarded-* 系列标头

当开发者使用 AddForwarded 转换时，系统不仅会添加 Forwarded 标头转换，还会自动添加四个 X-Forwarded-* 转换（X-Forwarded-For、X-Forwarded-Prefix、X-Forwarded-Host 和 X-Forwarded-Proto），并将这些转换的动作设置为 Remove。这意味着所有现有的 X-Forwarded 标头都会被清除。

实际影响

这种行为会导致以下问题：

1. 如果代理链中有前置代理添加了 X-Forwarded 标头，这些标头会被清除
2. 后续显式添加的 Append 转换将无法看到之前的标头信息
3. 整个代理链的历史信息会丢失，只能保留当前跃点的信息

典型使用场景

在实际应用中，开发者可能需要同时支持两种标头格式，原因包括：

1. 后端系统多样性：一些现代系统只支持 Forwarded 标头，而一些遗留系统可能只支持 X-Forwarded 标头
2. 特殊需求：某些旧系统（如 Tomcat）可能需要额外的非标准标头（如 X-Forwarded-Port）

解决方案

目前有两种可行的解决方法：

1. 手动移除自动添加的转换： 在添加自定义 X-Forwarded 转换前，先移除 RequestTransforms 中已有的 X-Forwarded 转换

2. 直接实例化转换： 不使用 AddForwarded 扩展方法，而是直接创建 RequestHeaderForwardedTransform 实例

最佳实践建议

1. 如果只需要 Forwarded 标头，直接使用 AddForwarded 方法即可
2. 如果需要同时支持两种标头格式，采用上述解决方案之一
3. 在混合环境中，仔细测试标头传递行为，确保所有后端系统都能正确接收所需信息

这个问题的本质在于标头转换的执行顺序和默认行为，理解这一点对于正确配置反向代理至关重要。开发者应当根据实际后端系统的需求，选择合适的标头传递策略。