리버스 프록시 소프트웨어가 사용되는 경우, 리버스 프록시 http://192.168.110:2046/의 URL을 http://www.xxx.com/의 URL로 프록시 할 때 request.getRemoteaddr () 메서드를 사용하여 IP를 얻으십시오. request.getRemoteaddr () 메소드를 사용하여 얻은 주소는 다음과 같습니다. 127.0.0.1 또는 192.168.1.110, 클라이언트의 실제 IP가 아닙니다.
프록시를 통과 한 후 클라이언트와 서비스 사이에 중간 계층이 추가되므로 서버는 클라이언트의 IP를 직접 얻을 수 없으며 서버 측 응용 프로그램은 전달 주소를 통해 클라이언트에게 직접 반환 할 수 없습니다. 그러나 요청을 전달하는 HTTP 헤더 정보에서 x-forwarded-for 정보가 추가됩니다. 원래 클라이언트 IP 주소와 원래 클라이언트가 요청한 서버 주소를 추적하는 데 사용됩니다. http://www.xxx.com/index.jsp/에 액세스하면 실제로 서버의 index.jsp 파일에 액세스하는 브라우저가 아니라 먼저 http : //192.168에 액세스합니다. 2046/index.jsp, 프록시 서버는 브라우저에 액세스 한 결과를 반환합니다 클라이언트의 IP 주소가 아닌 프록시 서버.
그런 다음 클라이언트의 실제 IP 주소를 얻는 방법을 얻을 수 있습니다.
코드 사본은 다음과 같습니다.
공개 문자열 getRemortip (httpservletrequest 요청) {
if (request.getheader ( "x-forwarded-for") == null) {
return request.getRemoteaddr ();
}
return request.getheader ( "x-forwarded-for");
}
그러나 http://www.xxx.com/index.jsp/를 방문하면 위에 표시된 것처럼 반환 된 IP 주소는 항상 127.0.0.1 또는 192.168.1.110이 아니라 항상 알려지지 않았으며 http : // ///192.168을 방문합니다. 1.110 : 2046/index.jsp, 클라이언트의 실제 IP 주소를 반환하고 검증하기 위해 메소드가 작성 될 수 있습니다. 그 이유는 오징어에 있습니다. squid.conf configuration file forected_for의 forword_for가 꺼져 있으면 : x-forwarded-for : unknown
따라서 클라이언트의 실제 IP 주소를 얻는 두 번째 방법을 얻을 수 있습니다.
코드 사본은 다음과 같습니다.
공개 문자열 getipaddr (httpservletrequest 요청) {
문자열 ip = request.getheader ( "x-forwarded-for");
if (ip == null || ip.length () == 0 || "알 수없는".EqualSEndoreCase (ip)) {
ip = request.getheader ( "proxy-client-ip");
}
if (ip == null || ip.length () == 0 || "알 수없는".EqualSEndoreCase (ip)) {
ip = request.getheader ( "wl-proxy-client-ip");
}
if (ip == null || ip.length () == 0 || "알 수없는".EqualSEndoreCase (ip)) {
ip = request.getRemoteaddr ();
}
반환 IP;
}
그러나 다단계 리버스 프록시가 통과되면 x-forwarded 값이 하나 이상 있지만 실제 사용자 측면의 실제 IP는 무엇입니까?
답은 최초의 비 unknown 유효한 IP 문자열을 x-forwarded-for로 가져가는 것입니다.
좋다:
코드 사본은 다음과 같습니다.
x-forwarded-for : 192.168.1.110, 192.168.1.120, 192.168.130, 192.168.1.100
사용자의 실제 IP는 192.168.1.110입니다