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

koflover

　　原来直接用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转发给后端。