把apache和jettty(jboss/tomcat)通讯从mod_jk方式调整为mod_proxy方式后，应该获取IP方式要修改。

原来直接用request.getRemoteAddr();获取ip，可以到真实的ip，但是修改成mod_proxy方式后，request.getRemoteAddr();是发起求apache服务器的ip，大多数情况是本机。

所以应该修改为：

 

        String ip = request.getHeader("x-forwarded-for");
        if (ip != null && !"unknown".equalsIgnoreCase(ip)) {
            String[] ipList = ip.split(",");
            for (String ipItem : ipList) {
                //ip min length 7: 0.0.0.0
                if (ipItem.length() >= 7 && !"unknown".equalsIgnoreCase(ipItem)) {
                    return ipItem;
                }
            }
        }

       return null;//一定是配置有问题了。

至于网上流传的Proxy-Client-IP,还有八辈子用不到的WEBLogic自定义头WL-Proxy-Client-IP等等都是浮动，半点不可靠，请求端可以在头域中任意添加。

而只有这个XFF是apache获取到客端ip然后转发给后端，这两端的转发对我们而言是真实可信的。如果你启动了mod_proxy,那么在后端的

web容器中获取XFF就一定是在apache中看到的ip(指连接到apache的客户端，它有可能本身就是代理，但这称们平时直接getRemoteAddr()是

一致的),对于apache反向代理而言，它一定不会是unknown,上面的unknown是为了兼容squid的 forwarded_for off场景。如果这样取不到，那么根本没有

必要再取getRemoteAddr()还不如直接return null或return "127.0.0.1".

 

千万要注意的是，按IETF的XFF规范，对于原来的XFF应该保留，代理把当前获取的IP附加到最后面。如果我们取XFF的第一个非unknown就有可能是客户端

提交的值，从而被客端欺骗了，所以应该在apache中把原来的值给unset掉：

RequestHeader unset x-forwarded-for

这样apache会把原来的x-forwarded-for清这，然后把当前客户端的值作为x-forwarded-for转发给后端。