Java中Request.getScheme在Nginx代理下HTTPS返回HTTP

Question

在Nginx反向代理环境下，Java应用通过`request.getScheme()`获取URL协议时，常出现本应返回“https”的请求却返回“http”的问题。这是由于Nginx与后端应用服务器之间通信通常使用HTTP明文传输，导致Java服务无法感知前端的真实协议。尽管用户通过HTTPS访问，但后端Request对象仅看到代理转发的HTTP请求，从而影响重定向、资源链接生成等逻辑，造成混合内容或跳转错误。

Answer 1

一、问题背景与现象分析

在现代Web架构中，Nginx常作为反向代理服务器部署于Java应用（如Spring Boot、Tomcat等）前端，用于负载均衡、SSL终止和静态资源处理。当用户通过HTTPS访问服务时，Nginx负责解密请求并以HTTP协议转发至后端Java应用。然而，Java应用调用request.getScheme()方法时，返回的却是“http”而非预期的“https”，导致生成的URL链接、重定向地址或安全策略判断出现偏差。

这种现象的根本原因在于：Java应用接收到的是Nginx代理转发后的内部请求，其底层通信基于HTTP明文传输，原始的HTTPS上下文信息未被保留。因此，getScheme()仅反映代理与后端之间的协议，而非客户端与Nginx之间的实际协议。

二、常见表现与影响范围

• 重定向跳转至HTTP地址，造成安全警告或登录失败
• 前端资源（CSS/JS）使用HTTP加载，触发浏览器混合内容拦截
• OAuth2回调地址生成错误，认证流程中断
• Strict-Transport-Security (HSTS) 策略无法正确启用
• API响应中包含非安全链接，违反安全合规要求
• Spring Security的requiresChannel()判断失效
• CDN回源签名URL协议错误，导致访问拒绝
• 微服务间调用链路追踪中协议标识失真
• 日志记录中的scheme字段误导运维排查
• 第三方集成接口因URL协议不符而验证失败

三、协议传递机制解析

Nginx可通过标准HTTP头部将原始请求信息传递给后端应用。以下是关键代理头字段：

Header Name	Description	Example Value
X-Forwarded-Proto	指示原始请求使用的协议	https
X-Forwarded-Port	原始请求的目标端口	443
X-Forwarded-For	客户端IP地址链	203.0.113.195
X-Forwarded-Host	原始Host头	example.com
X-Forwarded-Ssl	Nginx自定义标识是否为SSL请求	on

四、Nginx配置修正方案

确保在Nginx的server块中正确设置代理头，示例如下：

location / {
    proxy_pass http://backend_java_app;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Port $server_port;
    proxy_set_header X-Forwarded-Host $host;
}

其中$scheme变量会根据当前请求是HTTP还是HTTPS自动填充，确保X-Forwarded-Proto准确传递协议类型。

五、Java应用层解决方案

Java应用需主动识别代理头以重构真实请求属性。以下是几种主流框架的处理方式：

1. 通用Filter处理：编写自定义Filter，包装HttpServletRequest，覆盖getScheme()方法
2. Spring Boot内置支持：启用server.forward-headers-strategy=framework，并配置RemoteIpValve或使用@EnableWebMvc结合ForwardedHeaderFilter
3. Tomcat Valve机制：在server.xml中添加RemoteIpValve
4. Jetty ProxyConfiguration：配置ProxyLoadBalancing
5. Netty/WebFlux环境：利用ForwardedHeaderTransformer

六、代码实现示例

以下是一个通用的Java Filter实现，用于修复scheme感知问题：

public class SchemePreservingFilter implements Filter {
    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws IOException, ServletException {
        
        HttpServletRequest httpRequest = (HttpServletRequest) request;
        String proto = httpRequest.getHeader("X-Forwarded-Proto");
        boolean isSecure = "https".equalsIgnoreCase(proto);
        
        HttpServletRequest wrappedRequest = new HttpServletRequestWrapper(httpRequest) {
            @Override
            public String getScheme() {
                return isSecure ? "https" : super.getScheme();
            }
            
            @Override
            public boolean isSecure() {
                return isSecure || super.isSecure();
            }
        };
        
        chain.doFilter(wrappedRequest, response);
    }
}

七、架构级流程图示意

graph TD
            A[Client HTTPS Request] --> B[Nginx SSL Termination]
            B --> C{Check X-Forwarded Headers}
            C --> D[Add X-Forwarded-Proto: https]
            D --> E[Proxy to Java App via HTTP]
            E --> F[Java App receives request]
            F --> G[Custom Filter reads X-Forwarded-Proto]
            G --> H[Override getScheme() → returns 'https']
            H --> I[Correct URL generation & redirection]

八、安全注意事项与最佳实践

直接信任X-Forwarded-*头存在安全风险，可能被恶意伪造。应采取以下措施：

• 仅在可信网络边界（如内网）中启用该逻辑
• 配置Nginx仅从特定IP段转发请求
• 使用internal指令限制非法访问
• 在Java侧校验请求来源IP是否属于代理服务器白名单
• 结合Forwarded标准头（RFC 7239）替代传统X-Forwarded系列
• 启用Strict Transport Security策略强化整体安全性
• 定期审计日志中scheme与proto头的一致性
• 避免在无TLS终止设备的场景下误启此功能