리버스 프록시란? DNS와 웹 실무 가이드

리버스 프록시는 하나 이상의 백엔드 서버를 대신해 요청을 받아 적절한 대상으로 전달하는 서버입니다. 방문자 입장에서는 프록시가 공개 엔드포인트인 경우가 많으며, 브라우저는 애플리케이션 서버에 직접 연결하지 않습니다. 리버스 프록시는 HTTPS를 종료하고, 호스트 이름이나 경로로 요청을 라우팅하고, 트래픽을 분산하고, 응답을 캐시하고, 콘텐츠를 압축하고, 보안 통제를 적용할 수 있습니다. DNS는 보통 공개 호스트 이름이 프록시 또는 그 앞단에 있는 제공업체 관리형 주소를 가리키게 합니다. 그러면 프록시는 자체 라우팅 설정으로 업스트림 애플리케이션에 도달합니다.

리버스 프록시와 포워드 프록시

포워드 프록시는 클라이언트를 대신합니다. 클라이언트가 정책, 프라이버시, 네트워크 접근 등의 이유로 프록시를 거쳐 외부 서비스에 요청을 보냅니다. 리버스 프록시는 서버를 대신합니다. 외부 클라이언트가 프록시에 연결하고, 프록시가 백엔드 서비스로 요청을 전달합니다. 따라서 "프록시"라는 단어만으로는 모호합니다. 웹사이트 아키텍처에서 리버스 프록시는 대개 공개 서비스 엔드포인트를 제공하고 백엔드 풀의 세부 사항을 숨깁니다. 같은 인프라에서 여러 도메인을 라우팅하고, 하나의 공개 접속 지점을 유지하면서 경로별로 서로 다른 애플리케이션으로 보낼 수 있습니다.

DNS와 리버스 프록시는 연결의 서로 다른 부분을 해결합니다. DNS는 호스트 이름을 공개 주소나 별칭에 매핑합니다. 클라이언트가 연결하고 나면 프록시는 HTTP 호스트 정보, TLS 서버 이름 표시(SNI), 자체 설정을 사용해 올바른 서비스를 선택합니다. 그래서 도메인은 잘 동작하는데 IP만으로 요청하면 기본 페이지나 인증서 경고가 보일 수 있습니다. 요청에 기대하는 호스트 이름 정보가 없을 수 있기 때문입니다. 마찬가지로 DNS를 변경한다고 해서 그에 맞는 프록시 라우트가 자동으로 만들어지거나 인증서가 프로비저닝되지는 않습니다. 두 계층이 호스트 이름과 대상에 대해 일치해야 합니다.

프록시가 장애의 일부가 되는 흔한 경우

도메인이 올바르게 확인되는데도 리버스 프록시가 죽은 업스트림을 가리키거나, 잘못된 포트를 사용하거나, 처리하도록 설정되지 않은 호스트 이름을 거부할 수 있습니다. 엣지에 유효한 인증서가 없거나 암호화된 업스트림 설정이 잘못되었다면 TLS 오류가 발생할 수 있습니다. 백엔드에 과부하가 걸렸거나 접근할 수 없을 때 프록시가 시간 초과를 반환하기도 합니다. 반대로 DNS가 클라이언트를 잘못된 프록시 주소로 안내하면 멀쩡한 애플리케이션이 사용할 수 없는 것처럼 보일 수 있습니다. 먼저 DNS 응답을 기록한 뒤 HTTP 응답, TLS 연결, 프록시 로그, 백엔드 상태를 순서대로 점검하세요.

• DNS가 의도한 공개 프록시 엔드포인트를 가리키는지 확인하세요.
• 프록시에 해당 도메인의 호스트 규칙과 정상적인 업스트림이 있는지 확인하세요.
• HTTPS가 실패하면 엣지와 업스트림의 TLS 설정을 모두 확인하세요.
• 프록시 로그로 라우팅 오류와 애플리케이션 오류를 구분하세요.
• IP 조회로 백엔드 서버가 드러난다고 가정하지 마세요.

보안과 운영상의 경계

리버스 프록시는 백엔드 서비스가 직접 노출되는 것을 줄일 수 있지만, 접근 규칙을 구성하고 유지하지 않는 한 자동으로 보안 경계가 되지는 않습니다. 아키텍처가 허용하는 경우 원본은 의도된 경로를 통한 트래픽만 받아야 합니다. 관리 인터페이스를 적절한 인증 없이 공개 경로에 두어서는 안 됩니다. 프록시 소프트웨어를 최신 상태로 패치하고, 관리 접근을 제한하고, 전달된 헤더를 검증하세요. 프록시는 클라이언트와 업스트림 정보를 해석하는 신뢰받는 주체가 되기 때문입니다. DNS, 프록시 규칙, 인증서, 백엔드를 어느 팀이 소유하는지 문서화해 두면, 각 팀이 다른 계층에 책임이 있다고 가정하는 바람에 사고 대응이 지연되지 않습니다.

공개 엣지와 백엔드의 관계는 오리진 서버란 무엇인가를 읽어 보세요. 전 세계 프록시 네트워크는 CDN이 DNS를 활용하는 방법을 참고하세요. 공개 도메인-IP 확인으로 DNS가 제시하는 주소를 확인할 수 있지만, 리버스 프록시의 라우트와 애플리케이션의 상태는 별도의 운영 점검이 필요합니다. 이러한 책임을 구분해 두면 디버깅이 더 정확해지고, 주소 결과를 인프라 전체에 대한 진단으로 착각하는 일을 막을 수 있습니다.

프록시 규칙의 소유자를 분명히 하세요

리버스 프록시는 중요한 인계 지점에 위치하므로 DNS, 호스트 라우팅, 인증서, 업스트림 정의, 접근 정책을 누가 소유하는지 기록하세요. 한 계층에서는 변경이 올바르더라도 다른 계층이 갱신되지 않아 실패할 수 있습니다. DNS는 프록시를 가리키지만 프록시에 가상 호스트가 없거나, 라우트는 있는데 인증서가 다른 이름용이거나, 업스트림은 정상인데 방화벽이 프록시 서브넷을 차단하는 경우입니다. 프로덕션 호스트 이름마다 간단한 경로 다이어그램과 정상 동작이 확인된 요청을 유지하세요. 사고가 발생하면 같은 요청 타임스탬프나 상관 ID를 사용해 공개 DNS 응답, 프록시 접근 로그, 업스트림 상태, 애플리케이션 로그를 비교하세요.