如何获取客户端真实IP、域名、协议、端口？看这一篇就够了！

写在前面

Nginx最为最受欢迎的反向代理和负载均衡服务器，被广泛的应用于互联网项目中。这不仅仅是因为Nginx本身比较轻量，更多的是得益于Nginx的高性能特性，以及支持插件化开发，为此，很多开发者或者公司基于Nginx开发出了众多的高性能插件。使用者可以根据自身的需求来为Nginx指定某款插件以增强Nginx在某种特定场景下的功能或者提升Nginx在某种特定场景下的性能。

Nginx获取客户端信息

注意：本文中的客户端信息指的是：客户端真实IP、域名、协议、端口。

Nginx反向代理后，Servlet应用通过request.getRemoteAddr()取到的IP是Nginx的IP地址，并非客户端真实IP，通过request.getRequestURL()获取的域名、协议、端口都是Nginx访问Web应用时的域名、协议、端口，而非客户端浏览器地址栏上的真实域名、协议、端口。

直接获取信息存在哪些问题？

例如在某一台IP为192.168.1.100的服务器上，Jetty或者Tomcat端口号为8080，Nginx端口号80，Nginx反向代理8080端口：

server {
    listen 80;
    location / {
        proxy_pass http://127.0.0.1:8080; # 反向代理应用服务器HTTP地址
    }
}

在另一台机器上用浏览器打开http://192.168.1.100/test访问某个Servlet应用，获取客户端IP和URL：

System.out.println("RemoteAddr: " + request.getRemoteAddr());
System.out.println("URL: " + request.getRequestURL().toString());

打印的结果信息如下：

RemoteAddr: 127.0.0.1
URL: http://127.0.0.1:8080/test

可以发现，Servlet程序获取到的客户端IP是Nginx的IP而非浏览器所在机器的IP，获取到的URL是Nginx proxy_pass配置的URL组成的地址，而非浏览器地址栏上的真实地址。如果将Nginx用作https服务器反向代理后端的http服务，那么request.getRequestURL()获取的URL是http前缀的而非https前缀，无法获取到浏览器地址栏的真实协议。如果此时将request.getRequestURL()获取得到的URL用作拼接Redirect地址，就会出现跳转到错误的地址，这也是Nginx反向代理时经常出现的一个问题。

如何解决这些问题？

既然直接使用Nginx获取客户端信息存在问题，那我们该如何解决这个问题呢？

我们整体上需要从两个方面来解决这些问题：

（1）由于Nginx是代理服务器，所有客户端请求都从Nginx转发到Jetty/Tomcat，如果Nginx不把客户端真实IP、域名、协议、端口告诉Jetty/Tomcat，那么Jetty/Tomcat应用永远不会知道这些信息，所以需要Nginx配置一些HTTP Header来将这些信息告诉被代理的Jetty/Tomcat；

（2）Jetty/Tomcat这一端，不能再获取直接和它连接的客户端（也就是Nginx）的信息，而是要从Nginx传递过来的HTTP Header中获取客户端信息。

具体实践

配置nginx

首先，我们需要在Nginx的配置文件nginx.conf中添加如下配置。

proxy_set_header Host $http_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;

各参数的含义如下所示。

• Host包含客户端真实的域名和端口号；
• X-Forwarded-Proto表示客户端真实的协议（http还是https）；
• X-Real-IP表示客户端真实的IP；
• X-Forwarded-For这个Header和X-Real-IP类似，但它在多层代理时会包含真实客户端及中间每个代理服务器的IP。

此时，再试一下request.getRemoteAddr()和request.getRequestURL()的输出结果：

RemoteAddr: 127.0.0.1
URL: http://192.168.1.100/test

可以发现URL好像已经没问题了，但是IP还是本地的IP而非真实客户端IP。但是如果是用Nginx作为https服务器反向代理到http服务器，会发现浏览器地址栏是https前缀但是request.getRequestURL()获取到的URL还是http前缀，也就是仅仅配置Nginx还不能彻底解决问题。

通过Java方法获取客户端信息

仅仅配置Nginx不能彻底解决问题，那如何才能解决这个问题呢？一种解决方式就是通过Java方法获取客户端信息，例如下面的Java方法。

/***
 * 获取客户端IP地址;这里通过了Nginx获取;X-Real-IP
 */
public static String getClientIP(HttpServletRequest request) {
    String fromSource = "X-Real-IP";
    String ip = request.getHeader("X-Real-IP");
    if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
    	ip = request.getHeader("X-Forwarded-For");
    	fromSource = "X-Forwarded-For";
    }
    if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
    	ip = request.getHeader("Proxy-Client-IP");
    	fromSource = "Proxy-Client-IP";
    }
    if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
    	ip = request.getHeader("WL-Proxy-Client-IP");
    	fromSource = "WL-Proxy-Client-IP";
    }
    if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
    	ip = request.getRemoteAddr();
    	fromSource = "request.getRemoteAddr";
    }
    return ip;
}

这种方式虽然能够获取客户端的IP地址，但是我总感觉这种方式不太友好，因为既然Servlet API提供了request.getRemoteAddr()方法获取客户端IP，那么无论有没有用反向代理对于代码编写者来说应该是透明的。

接下来，我就分别针对Jetty服务器和Tomcat服务器为大家介绍下如何进行配置才能更加友好的获取客户端信息。

Jetty服务器

在Jetty服务器的jetty.xml文件中，找到httpConfig，加入配置：

<New id="httpConfig" class="org.eclipse.jetty.server.HttpConfiguration">
    ... 
  <Call name="addCustomizer">
    <Arg><New class="org.eclipse.jetty.server.ForwardedRequestCustomizer"/></Arg>
  </Call>
</New>

重新启动Jetty，再用浏览器打开http://192.168.1.100/test测试，结果：

RemoteAddr: 192.168.1.100
URL: http://192.168.1.100/test

此时可发现通过request.getRemoteAddr()获取到的IP不再是127.0.0.1而是客户端真实IP，request.getRequestURL()获取的URL也是浏览器上的真实URL，如果Nginx作为https代理，request.getRequestURL()的前缀也会是https。

另外，Jetty将这个功能封装成一个模块：http-forwarded。如果不想改jetty.xml配置文件的话，也可以启用http-forwarded模块来实现。

例如可以通过命令行启动Jetty：

java -jar start.jar --module=http-forwarded

更多Jetty如何启用模块的相关资料可以参考：http://www.eclipse.org/jetty/documentation/current/startup.html

Tomcat

和Jetty类似，如果使用Tomcat作为应用服务器，可以通过配置Tomcat的server.xml文件，在Host元素内最后加入：

<Valve className="org.apache.catalina.valves.RemoteIpValve" />

 $http_x_forwarded_proto 和 $scheme 有什么差别，分别什么时候可以用？

$http_x_forwarded_proto 和 $scheme 是两个在 Web 服务器（尤其是 Nginx）配置中常用的变量，它们都与请求协议（HTTP 或 HTTPS）相关，但作用和来源完全不同。

核心区别

使用场景

• ‌$scheme 的使用场景‌：
  • ‌设置代理头‌：在 Nginx 反向代理配置中，最常用的是 proxy_set_header X-Forwarded-Proto $scheme;。这里 $scheme 作为安全、可靠的来源，将当前连接的协议信息传递给后端服务器。‌
  • ‌重定向‌：在 Nginx 配置中，根据 $scheme 的值进行 301 重定向。例如，强制将所有 HTTP 请求重定向到 HTTPS：if ($scheme = http) { return 301 https://$host$request_uri; }。‌‌
  • ‌构建 URL‌：在 proxy_redirect 指令中使用，确保后端返回的重定向 URL 协议正确：proxy_redirect http:// $scheme://;。‌‌
• ‌$http_x_forwarded_proto 的使用场景‌：
  • ‌后端应用逻辑‌：后端应用（如 PHP、Java Spring Boot）需要判断原始请求是否为 HTTPS 时，会读取 X-Forwarded-Proto 请求头（在 PHP 中表现为 $_SERVER['HTTP_X_FORWARDED_PROTO']）。‌
  • ‌Nginx 条件判断‌：当 Nginx 本身是负载均衡器或位于代理链的中间层时，可以使用 $http_x_forwarded_proto 来判断原始客户端的协议，并据此做出决策。例如，一个 Nginx 实例监听 80 端口，但知道前面有负载均衡器将 HTTPS 转为 HTTP，此时可以用 $http_x_forwarded_proto 来判断是否应执行 HTTPS 重定向。‌‌
  • ‌安全审计与日志‌：在日志格式中同时记录 $http_x_forwarded_proto 和 $scheme，可以清晰地看到请求的完整路径：proto=$http_x_forwarded_proto->$scheme。‌‌

总结

简单来说，‌$scheme 是 Nginx 看到的“当前”协议，而 $http_x_forwarded_proto 是 Nginx 从请求头中读到的“原始”协议‌。

• ‌在 Nginx 配置内部‌，优先使用 $scheme，因为它可靠、安全。
• ‌当需要将原始协议信息传递给后端服务器‌时，使用 proxy_set_header X-Forwarded-Proto $scheme;，将 $scheme 的值安全地赋给 X-Forwarded-Proto 头。
• ‌在后端应用或特定 Nginx 条件判断中‌，才需要直接使用 $http_x_forwarded_proto 的值，但需注意其可能被伪造的风险，应结合 IP 白名单等机制确保安全。‌‌

好了，咱们今天就聊到这儿吧！别忘了给个在看和转发，让更多的人看到，一起学习一起进步！！