
Proxy는 2가지 유형이 있다.
포워드 프록시
: 클라이언트 측의 프록시이며, Identity를 숨기거나 클라이언트를 대신합니다.
리버스 프록시
실제 백엔드 서비스의 Identity를 숨기거나 애플리케이션 서비스를 대신합니다.
일반적으로 NGINX를 리버스 프록시로 배포합니다.

Syntax: proxy_pass ;
Request: https://www.example.com/
location / {
proxy_pass http://10.1.1.4:9000/app1;
}
proxy_pass 지시문은 들어오는 요청을 백엔드 서버의 대상으로 이동합니다.
따라서 Address는 도메인 이름, IP 주소 포트, 유닉스 소켓, 업스트립 이름 또는 변수 집합이 있습니다.
proxy_pass 다음에 목적지가 옵니다.
일반적으로 server 및 location Context에서만 사용됩니다.
Ex)
위의 예시로 설명하면,
https://www.example.com/으로 요칭이 오면,
특정 요청을 슬래시와 일치시키고 이 경우 10.1.1.4인 대상으로 요청을 전달합니다.
따라서 클라이언트는 리버스 프록시로 요청을 보내면,
리버스 프록시는 백엔드 서버로 엑세스를 할 수 있습니다.
server{
listen 80;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
location / {
proxy_pass http://10.1.1.4:9000/app1;
}
}
NGINX의 기본 동작은 연결이 끊어지기 전에 연결을 닫고,
백엔드에 대한 새 연결을 시작하는 것입니다.
따라서 이 과정에서 Original 요청정보 중 일부가 여기에서 손실됩니다.
클라이언트에서 원래 요청이 만들어지면 해당정보는 리버스 프록시를 통해 백엔드 서버로 전송됩니다.
이때 NGINX는 리버스 프록시 지점에서 해당 연결을 종료합니다.
따라서 Original 클라이언트의 실제 IP주소, 호스트 정보와 같은 일부 세부정보를 캡쳐합니다.
그리고 그것을 백엔드나 UPSTREAM 서버로 전달합니다.
이를 수행하기 위해서는 NGINX의 헤더 설정을 해야합니다
사용자께서 제공하신 설명은 일부 정확하지만, 몇 가지 오해가 있는 것 같습니다. NGINX를 리버스 프록시로 사용할 때, NGINX는 클라이언트와 백엔드 서버 간의 중개자 역할을 합니다. 이 과정에서 NGINX는 클라이언트의 원래 IP 주소와 호스트 정보 등의 요청 정보를 캡처하여 백엔드 서버로 전달할 수 있습니다.
1. 연결 관리: NGINX는 클라이언트와의 연결을 수신하고, 별도로 백엔드 서버와의 연결을 설정합니다. 이 두 연결은 독립적으로 관리되며, NGINX는 클라이언트와 백엔드 서버 간의 직접적인 연결을 생성하지 않습니다. 따라서 NGINX는 클라이언트와 백엔드 서버 사이에서 요청과 응답을 중계하는 역할을 수행합니다.
2. 원래 요청 정보 전달: NGINX는 기본적으로 클라이언트의 원래 IP 주소나 호스트 정보를 백엔드 서버로 전달하지 않습니다. 그러나 이러한 정보를 백엔드 서버에서 확인하려면, NGINX 설정을 통해 관련 헤더를 추가로 전달하도록 구성해야 합니다. 예를 들어, proxy_set_header 지시어를 사용하여 X-Real-IP 또는 X-Forwarded-For 헤더에 클라이언트의 IP 주소를 담아 백엔드 서버로 전달할 수 있습니다.
3. 백엔드 서버의 로그: 백엔드 서버의 로그 파일에는 기본적으로 NGINX 서버의 IP 주소가 기록됩니다. 클라이언트의 실제 IP 주소를 로그에 남기려면, 앞서 언급한 헤더 정보를 백엔드 서버에서 처리하도록 설정해야 합니다. 예를 들어, Apache 서버의 경우 mod_remoteip 모듈을 사용하여 X-Forwarded-For 헤더를 통해 전달된 클라이언트의 IP 주소를 로그에 기록할 수 있습니다.
결론적으로, NGINX를 리버스 프록시로 사용할 때 클라이언트의 원래 IP 주소와 호스트 정보를 백엔드 서버로 전달하려면, NGINX와 백엔드 서버 모두에서 적절한 설정이 필요합니다. 이를 통해 백엔드 서버의 로그에 실제 클라이언트 정보를 기록할 수 있습니다.
proxy_set_header 지시문으로 해결하자!
이 지시문은 NGINX로 들어오는 요청 헤더를 재정의한다.
proxy_set_header Host $host;
: 백엔드 서버에 요청을 보낼 때 $host라는 변수로 대체합니다.
proxy_set_header X-Real-IP $remote_addr;
: 요청자의 원래 IP주소를 캡쳐하고, 이를 백엔드 서버로 전달하여 이 요청에 대한 Original 요청자의 IP임을 백엔드 서버에 알려줍니다.
proxy_set_header X-Forwarded ...
: 다양한 주소와 IP 목록을 생성합니다.
어떤 경우에는 실제 요청이 백에드 애플리케이션 서버에 도달하지 전에 두 개의 웹 서버와 두 개의 프록시가 있을 수 있습니다.
따라서 이와 같은 시나리오에서 NGINX는 나가서 모든 IP를 수집하고 해당 정보를 실제 백엔드 서버로 보냅니다.
프로덕션 환경에서는 리버스 프록시의 로컬 호스트 또는 IP주소만 백엔드 애플리케이션에 엑세스 할 수 있으므로 중지해야만 합니다.
그리고 실제 서버로 요청이 아래와 같이 실제 요청자, 요청된 URI를 캡쳐하고 이를 백엔드 서버로 전달을 합니다.
( curl은 아님 )
