리버스 프록시는 클라이언트의 요청을 받아 뒤쪽 서버에 전달하고 그 응답을 다시 반환하는 서버다. 사용자는 하나의 서비스 주소로 접근하면서도 경로에 따라 다른 애플리케이션을 이용할 수 있다. NGINX는 이런 구성을 지원하는 소프트웨어의 한 예다. NGINX 리버스 프록시 문서
요청이 지나가는 경로
사용자 → 프록시 → 애플리케이션 구조에서 프록시는 공개 진입점 역할을 한다. /wiki/는 문서 서버로, /api/는 API 서버로 전달하는 식이다. 목적지는 IP 주소나 이름으로 지정할 수 있다. 서비스별 포트를 사용자가 직접 기억하지 않아도 되는 장점이 있다.
경로와 헤더의 중요성
프록시가 경로를 그대로 넘길지 일부를 바꿀지에 따라 백엔드가 받는 URL이 달라진다. 또한 Host 같은 헤더를 어떻게 전달하는지 확인해야 한다. 원래 요청 정보를 쓰는 애플리케이션이라면 신뢰할 프록시의 범위와 전달 헤더 해석을 함께 설계한다.
| 증상 | 먼저 비교할 값 |
|---|---|
| 특정 경로만 404 | 외부 경로와 백엔드 수신 경로 |
| 잘못된 주소로 이동 | 호스트·스킴 관련 전달 정보 |
| 응답이 늦게 나타남 | 백엔드 응답 방식과 버퍼링 설정 |
이 표는 진단 출발점이며 단일 증상의 원인을 확정하는 규칙은 아니다. NGINX 프록시 모듈
버퍼링과 스트리밍
프록시는 백엔드 응답을 버퍼에 받아 전달할 수 있다. 일반 응답에는 유용하지만 실시간 출력에서는 데이터가 언제 사용자에게 보이는지 달라질 수 있다. SSE 같은 스트리밍을 서비스한다면 애플리케이션뿐 아니라 프록시 구간에서도 실제 도착 시점을 확인한다.
다른 기능과 구분하기
리버스 프록시를 둔다고 자동으로 서버가 여러 대가 되거나 장애 복구가 완성되지는 않는다. 로드 밸런싱은 요청을 여러 대상에 나누는 별도 기능이고, HTTPS 종료도 관련 설정이 필요하다. 역할을 구분하면 어느 계층에서 오류가 발생했는지 추적하기 쉬워진다.