把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转发给后端。