포워드 프록시 대 리버스 프록시: 어느 쪽을 제공하나요?

포워드 프록시는 아웃바운드 요청을 하는 클라이언트를 대신하여 작동합니다. 리버스 프록시는 인바운드 요청을 받는 서버를 대신하여 작동합니다. 포워드 프록시와 리버스 프록시의 결정을 내릴 때, 요청을 하는 사람이나 애플리케이션, 또는 그것을 받는 웹사이트 중 어떤 트래픽을 제어하고 싶은지 파악하는 것부터 시작하세요.

두 프록시 모두 중개자 역할을 하며, 요청을 계속해서 보낼 수 있습니다. 그들의 이름은 아키텍처에서의 역할을 설명할 뿐, 보안, 익명성 또는 성능에 대한 약속은 아닙니다. 웹사이트 게이트웨이는 자동으로 아웃바운드 브라우징 서비스가 되지 않으며, 아웃바운드 프록시를 구매한다고 해서 귀하의 애플리케이션이 방문자에게 공개되는 것은 아닙니다.

TL;DR

클라이언트가 정의된 아웃바운드 경로 또는 접근 정책이 필요할 때 포워드 프록시를 사용하세요.
방문자가 귀하가 운영하는 애플리케이션에 대한 진입점이 필요할 때 리버스 프록시를 사용하세요.
인증, 암호화, 캐싱 및 로깅은 실제 구성에 따라 다르며, 단순히 프록시 레이블에 의존하지 않습니다.
두 역할은 하나의 시스템에 존재할 수 있지만, 각각의 소유자, 자격 증명 및 실패 모드가 다릅니다.
주거용, ISP 또는 데이터 센터 레이블은 네트워크 제공을 설명하며, 포워드와 리버스의 구별을 대체하지 않습니다.

하나의 표로 본 차이점

질문	포워드 프록시	리버스 프록시
누구를 대신하여 작동하나요?	클라이언트 또는 클라이언트 그룹	서버 또는 서버 그룹
전형적인 요청 경로	애플리케이션 → 프록시 → 목적지	방문자 → 프록시 → 애플리케이션
누가 보통 선택하나요?	클라이언트 운영자 또는 네트워크 관리자	웹사이트 또는 서비스 운영자
즉각적인 목표는 무엇인가요?	아웃바운드 접근 제어 또는 경로 설정	인바운드 접근 수신 및 경로 설정
전형적인 인증 문제는 무엇인가요?	이 클라이언트가 프록시를 사용할 수 있나요?	이 방문자가 이 애플리케이션에 접근할 수 있나요?
일반적인 운영 문제는 무엇인가요?	엔드포인트 접근, 자격 증명 및 아웃바운드 정책	업스트림 상태, 라우팅, 인증서 및 출처 접근
자동으로 제공하지 않는 것은 무엇인가요?	귀하의 웹사이트에 대한 공개 진입점	관련 없는 브라우저 트래픽에 대한 다른 아웃바운드 신원

이것들은 특정 소프트웨어 패키지에 대한 제한이 아니라 전형적인 역할입니다. 유능한 게이트웨이는 여러 기능을 지원할 수 있지만, 각 기능은 여전히 명시적인 구성이 필요합니다. MDN 프록시 서버 개요는 HTTP 요청 경로에서 포워딩 중개자와 게이트웨이를 구별합니다.

포워드 프록시의 작동 방식

보고 애플리케이션이 외부 서비스에 대한 승인된 요청을 하는 모습을 상상해 보세요. 직접 연결하는 대신, 구성된 포워드 프록시를 통해 요청을 보냅니다. 프록시는 다음 연결을 설정하고 동일한 논리적 경로를 통해 응답을 반환합니다.

클라이언트 운영자는 중앙 집중식 아웃바운드 정책, 제어된 네트워크 경로 또는 애플리케이션이 목적지에 도달할 수 있는 지원 방법을 원할 수 있습니다. 정확한 결과는 프로토콜, 클라이언트의 프록시 지원 및 제공자의 구성에 따라 다릅니다. 일부 애플리케이션은 자체 프록시 설정을 가지고 있으며, 다른 애플리케이션은 시스템 또는 환경 설정을 상속받습니다.

중요한 운영 질문은 의도된 애플리케이션이 실제로 프록시를 사용하는지 여부입니다. 하나의 도구에서 설정을 변경한다고 해서 컴퓨터의 모든 프로세스가 그것을 따르는 것은 아닙니다. 백그라운드 서비스, 브라우저 및 명령줄 클라이언트는 서로 다른 유효한 구성을 가질 수 있습니다.

포워드 프록시는 목적지가 다른 식별 정보를 보지 않는 것을 보장하지도 않습니다. 요청에는 계정 자격 증명, 쿠키 및 애플리케이션 데이터가 포함될 수 있습니다. 정당한 기술적 필요에 따라 경로를 선택하고, 데이터 처리와 네트워크 연결에 사용된 주소를 별도로 평가하세요.

예시: 예약된 데이터 통합

허구의 통합을 고려해 보세요. 매일 아침 허용된 공급업체 데이터를 검색합니다. 운영자는 요청이 문서화된 엔드포인트를 통해 나가기를 원합니다. 운영자는 통합의 HTTP 클라이언트를 구성하고, 공급업체 API 토큰과 별도로 프록시 자격 증명을 저장하며, 경로 및 애플리케이션 동작을 모두 확인합니다.

프록시 자격 증명은 통합이 중개자를 사용할 수 있는지를 답합니다. 공급업체 토큰은 공급업체의 데이터를 읽을 수 있는지를 답합니다. 작동하는 프록시는 두 번째 권한을 부여하지 않습니다. 이러한 책임을 분리하면 인증 실패를 진단하기가 훨씬 쉬워집니다.

리버스 프록시의 작동 방식

이제 공개 웹사이트에 애플리케이션이 개인 서비스 포트에서 실행되고 있다고 상상해 보세요. 방문자는 웹사이트의 정문에 연결합니다. 리버스 프록시는 해당 트래픽을 수신하고 구성된 업스트림 애플리케이션으로 전달한 다음, 애플리케이션의 응답을 반환합니다.

웹사이트 운영자는 업스트림을 선택하고 진입점을 제어합니다. 디자인에 따라 리버스 프록시는 TLS 종료, 서비스 간 라우팅, 버퍼링 또는 로드 분배를 처리할 수 있습니다. 이는 구성된 기능이지 모든 배포에 포함된다고 가정할 수 있는 기능이 아닙니다.

NGINX 리버스 프록시 문서는 proxy_pass를 사용하여 업스트림에 요청을 전달하고, 요청 헤더를 설정하며, 버퍼링을 제어하는 방법을 설명합니다. 이 가이드는 역할 선택에 중점을 두며, 설치 및 지침 세부 사항은 실제로 배포하는 소프트웨어의 문서에 포함됩니다.

리버스 프록시는 건강하지 않은 애플리케이션을 건강하게 만들 수 없습니다. 업스트림 데이터베이스가 사용할 수 없는 경우, 그 앞에 다른 구성 요소를 두는 것만으로는 누락된 데이터를 복원할 수 없습니다. 아키텍처가 그렇게 설계된 경우에만 제어된 실패 응답을 제공하거나 다른 건강한 인스턴스로 라우팅할 수 있습니다.

예시: 하나의 도메인 아래 두 개의 내부 애플리케이션

작은 팀이 대시보드와 문서 서비스를 운영한다고 가정해 보세요. 이는 허구의 설계이며 벤치마크가 아닙니다. 리버스 프록시는 정의된 공개 진입점을 제공하고 구성된 호스트 또는 경로에 따라 적절한 애플리케이션으로 요청을 보낼 수 있습니다.

팀은 여전히 각 애플리케이션에 누가 접근할 수 있는지, 인증서가 어떻게 갱신되는지, 출처 서비스에 직접 접근할 수 있는지를 결정해야 합니다. 깔끔한 도메인 구조는 유용하지만 접근 제어를 대체하지는 않습니다. 예상되는 공개 경로와 의도하지 않은 대체 진입점을 모두 테스트하세요.

인증과 신뢰는 양쪽에서 다릅니다

포워드 프록시는 트래픽을 전달하기 전에 사용자 이름과 비밀번호를 요구할 수 있습니다. 애플리케이션은 또한 자체 목적지 자격 증명이 필요할 수 있습니다. 두 개의 신원을 구성, 로그 및 사고 보고서에서 분리하세요.

리버스 프록시에서는 방문자가 애플리케이션이나 그 앞의 접근 계층에 인증할 수 있습니다. 애플리케이션은 어떤 헤더나 신원 주장을 신뢰할 수 있는지를 이해해야 합니다. 신뢰할 수 있는 경계 없이 방문자가 제공한 신원 헤더를 수용하는 것은 의도된 제어를 약화시킬 수 있습니다.

예를 들어, 애플리케이션은 트래픽이 게이트웨이를 통과한 후 원래 방문자 주소를 기록하고 싶어할 수 있습니다. 이는 의도적인 신뢰할 수 있는 프록시 구성이 필요합니다. 단순히 전달된 헤더를 읽는 것만으로는 그 내용이 권위 있는 것임을 확립하지 않습니다. 애플리케이션과 게이트웨이 설정은 어떤 구성 요소가 그것을 제공할 수 있는지에 대해 동의해야 합니다.

어떤 설계에서든 라우팅 구성을 변경할 수 있는 사람을 정의하세요. 프록시 관리자는 요청이 어디로 가고 어떤 정보가 중개자를 통해 전달되는지에 영향을 미칠 수 있습니다. 그 권한을 의미 있는 운영 허가로 취급하고, 무해한 편의 설정으로 간주하지 마세요.

어느 프록시가 모든 것을 자동으로 암호화하나요?

아니요. 연결을 별도로 식별하세요. 클라이언트에서 프록시로의 연결과 프록시에서 목적지 또는 업스트림으로의 연결이 있을 수 있습니다. 한 연결에서의 암호화는 다른 연결에서의 암호화를 설정하지 않습니다.

HTTPS를 종료하는 리버스 프록시의 경우, 애플리케이션에 대한 연결도 TLS가 필요한지 결정하고, 관련 인증서 및 신뢰 설정을 확인하세요. 포워드 프록시의 경우, 목적지 URL을 프록시 엔드포인트에 도달하는 데 사용된 프로토콜과 구별하세요.

그 선택 사항을 아키텍처 기록에 적어 두세요. 암호화가 시작되고 끝나는 위치를 설명하지 않고 전체 경로를 “안전하다”고 레이블링하는 다이어그램은 피하세요. 유용한 검토는 각 중개자가 무엇을 관찰할 수 있는지, 자격 증명이 어디로 이동하는지, 어떤 당사자가 신뢰 구성 관리를 하는지를 묻습니다.

실용적인 선택 과정

1. 요청을 간단한 언어로 작성하세요

“우리 작업자가 외부 API를 호출합니다” 또는 “고객이 우리 대시보드를 엽니다”와 같은 문장을 사용하세요. 요청자와 목적지를 명명하세요. 이 작은 연습은 일반적으로 제품 비교가 시작되기 전에 프록시 구별의 관련 측면을 식별합니다.

요구 사항이 “우리는 프록시가 필요하다”라고만 말한다면, 무엇이 변경되어야 하는지 물어보세요: 아웃바운드 라우팅, 인바운드 애플리케이션 접근, 인증 또는 트래픽 관리. 이러한 목표는 서로 다른 구성 요소를 요구할 수 있습니다.

2. 제어할 수 있는 경계를 식별하세요

클라이언트, 중개자 및 목적지를 나열하세요. 귀하의 팀이 운영하는 시스템과 다른 조직에 속하는 시스템을 표시하세요. 제3자 웹사이트에 대한 관리 제어를 가정하는 솔루션을 설계하지 마세요.

귀하가 소유한 애플리케이션의 경우, 인바운드 게이트웨이를 선택하고 출처를 구성할 수 있습니다. 제3자 API의 경우, 귀하는 클라이언트와 그 승인된 경로를 제어하지만, API의 계정 권한 및 사용 규칙은 그 경계 밖에 남아 있습니다.

3. 필요한 프로토콜 및 동작을 정의하세요

애플리케이션 프로토콜, 인증 방법, 요청 크기, 스트리밍 동작 및 예상 연결 기간을 포함하세요. 성공적인 짧은 페이지 요청이 긴 스트림이나 대용량 업로드가 올바르게 동작할 것임을 증명하지는 않습니다.

대표적인 승인 테스트를 사용하고, 클라이언트 버전을 기록하세요. “프록시”라는 단어를 모든 프로토콜이나 인증 메커니즘이 작동할 것이라는 증거로 취급하지 마세요. 호환성은 전체 연결 경로의 속성입니다.

4. 각 실패에 대한 소유자를 지정하세요

누가 클라이언트 구성, 프록시 가용성, 애플리케이션 건강 및 인증서 갱신을 확인할지를 결정하세요. 지원 직원에게 프록시 인증 실패와 업스트림 애플리케이션 실패를 구별할 수 있는 충분한 정제된 정보를 제공하세요.

또한 라우팅 변경을 비활성화하거나 롤백하는 방법을 결정하세요. 되돌릴 수 있는 구성은 모든 사람이 중단 중에 발견하는 문서화되지 않은 종속성보다 운영하기가 훨씬 쉽습니다.

5. 실제 결과를 검증하세요

포워드 프록시의 경우, 의도된 애플리케이션이 선택된 경로를 따르고 실제 작업을 완료하는지 테스트하세요. 리버스 프록시의 경우, 공개 호스트 이름, 라우팅, 인증 및 예상 업스트림 동작을 테스트하세요. 의도하지 않은 직접 접근이 귀하의 설계에서 요구하는 곳에서 제한되는지 확인하세요.

결과를 하나의 성공적인 요청의 스크린샷이 아니라 작은 수용 기록으로 유지하세요. 정상 동작, 하나의 제어된 실패 및 복구 단계를 포함하세요. 이는 향후 변경을 위한 참고 자료를 생성합니다.

시스템이 둘 다 사용할 수 있나요?

예. 웹 애플리케이션은 리버스 프록시를 통해 방문자를 받을 수 있으며, 백그라운드 작업자는 승인된 외부 통합을 위해 포워드 프록시를 사용할 수 있습니다. 이는 동일한 인프라에서 구성 요소가 실행되더라도 별도의 요청 경로입니다.

그들의 자격 증명, 로그 및 구성 이름을 구별하세요. “프록시 비밀번호”는 여러 중개자가 포함된 배포에서 모호한 비밀 레이블입니다. 비밀 자체를 드러내지 않으면서 서비스와 목적을 식별하는 이름을 선호하세요.

또한 실패 독립성을 고려하세요. 아웃바운드 프록시가 사용할 수 없는 경우, 공개 애플리케이션이 여전히 사용 가능해야 하며 예약된 통합이 일시 중지되어야 합니까? 인바운드 게이트웨이가 실패하면 운영자가 여전히 복구 콘솔에 접근할 수 있습니까? 이러한 질문은 하나의 구성 요소가 관련 없는 작업에 대한 종속성이 되었는지를 드러냅니다.

호스팅 및 프록시 제품의 적합성

서버는 소프트웨어를 실행할 장소를 제공합니다. 포워딩 서비스는 호환되는 클라이언트에 요청 경로를 제공합니다. 이들은 결합될 수 있지만, 어느 것도 자동으로 다른 것을 포함하지 않습니다. 기존의 VPS 대 주거용 프록시 비교는 그 구별을 확장합니다.

애플리케이션이나 게이트웨이를 호스팅하기 위해 Cloud VPS의 런타임 및 유지 관리 책임을 평가하세요. NGINX Proxy Manager를 선택하면, 기존의 NGINX Proxy Manager 배포 가이드가 그 별도의 설치 작업을 다룹니다. 더 넓은 VPS 관리 가이드는 기본 서버 유지 관리와 관련이 있습니다.

아웃바운드 프록시의 ISP 또는 데이터 센터 분류는 다른 결정입니다. 이는 귀하의 웹사이트가 리버스 프록시가 필요한지를 알려주지 않으며, 인증 및 애플리케이션 접근을 구성할 필요성을 제거하지 않습니다. 아키텍처를 먼저 선택한 후, 특정 요구 사항에 대해 네트워크 제공을 평가하세요.

FAQ

포워드 프록시와 리버스 프록시의 주요 차이점은 무엇인가요?

포워드 프록시는 아웃바운드 요청을 하는 클라이언트를 서비스하고, 리버스 프록시는 인바운드 요청을 받는 애플리케이션을 서비스합니다. 귀하가 운영하는 측과 변경하고 싶은 트래픽 행동을 식별한 후 소프트웨어나 서비스를 선택하세요.

리버스 프록시가 내 브라우저의 아웃바운드 IP를 변경할 수 있나요?

단순히 귀하의 웹사이트 앞에 존재한다고 해서 그렇지는 않습니다. 이는 자신이 제공하는 애플리케이션에 주소가 지정된 요청을 처리합니다. 관련 없는 브라우저 트래픽을 중개자를 통해 라우팅하려면 별도의 지원되는 포워드 프록시 또는 네트워크 구성이 필요합니다.

리버스 프록시는 로드 밸런서와 동일한가요?

아니요. 로드 밸런싱은 리버스 프록시 설계의 한 가지 가능한 기능입니다. 리버스 프록시는 단일 업스트림으로 전달할 수 있으며, 로드 밸런싱 시스템은 다양한 방식으로 작동할 수 있습니다. 레이블에서 중복성을 가정하기보다는 실제 구성을 검사하세요.

포워드 프록시가 요청을 익명으로 만들까요?

그 역할에서 그런 보장은 없습니다. 계정 로그인, 쿠키, 요청 데이터 및 운영자 로그는 여전히 중요합니다. 전송되고 유지되는 정보가 무엇인지 평가하고, 귀하가 수행할 수 있는 접근만을 위해 서비스를 사용하세요.

작은 웹사이트에 둘 다 필요하나요?

반드시 그렇지는 않습니다. 애플리케이션의 요구 사항부터 시작하세요. 관리형 호스팅 서비스가 이미 인바운드 진입점을 처리할 수 있으며, 일반적인 아웃바운드 요청은 추가 프록시가 필요하지 않을 수 있습니다. 문서화된 요구 사항을 해결하고 누군가 유지 관리할 수 있을 때만 구성 요소를 추가하세요.