무료 체험 시작로그인

용어집

HTTP 프록시란 무엇인가요?

HTTP 프록시는 HTTP를 이해하고 전달하는(CONNECT 메서드를 통해서는 HTTPS도) 프록시 서버로, 애플리케이션 계층에서 작동하며 일반 HTTP의 요청 및 응답 데이터를 검사, 수정, 캐싱할 수 있습니다.

HTTP 프록시가 SOCKS5와 어떻게 다른지, HTTP CONNECT가 무엇을 하는지, 그리고 왜 HTTP 프록시가 대부분의 스크래퍼와 HTTP 클라이언트가 지원하는 기본 프로토콜인지 이해합니다.

설명

HTTP 프록시는 가장 흔한 유형의 프록시 서버입니다. 애플리케이션 계층에서 HTTP를 이해합니다. 클라이언트가 요청을 보낼 때, 프록시는 목적지로 요청을 전달하기 전에 URL, 헤더, 그리고 (일반 HTTP의 경우) 본문을 읽을 수 있습니다. HTTPS의 경우 프록시는 CONNECT 메서드를 사용해 목적지까지 TCP 터널을 구축하며, 이후에는 내용을 보지 않고 암호화된 바이트만 전달합니다.

레지덴셜, ISP, 데이터센터 제공업체를 포함한 대부분의 상업용 프록시 서비스는 HTTP 프록시 엔드포인트를 제공합니다. 모든 HTTP 클라이언트와 라이브러리가 이를 기본적으로 지원하기 때문입니다. `HTTP_PROXY`와 `HTTPS_PROXY` 환경 변수를 설정하거나, Python의 `requests`에 `proxies={...}`를 전달하거나, Playwright에서 실행 플래그를 설정하는 것 모두 `http://user:pass@gate.shifter.io:10000`과 같은 HTTP 프록시 URL로 별도 설정 없이 바로 작동합니다.

HTTP와 SOCKS5의 차이는 대체로 구조적인 것입니다. HTTP 프록시는 애플리케이션 계층에서 작동합니다(HTTP를 파싱할 수 있음). SOCKS5는 전송 계층에서 작동합니다(단순히 TCP/UDP 바이트를 전달함). HTTPS 스크래핑의 경우 그 차이는 대체로 표면적인 것입니다. 두 방식 모두 결국 암호화된 바이트를 터널링하게 되며, HTTP 프록시 지원이 도구 전반에서 더 보편적입니다.

작동 방식

일반 HTTP의 경우, 클라이언트는 전체 요청을 프록시로 보내고(절대 URL을 포함한 `GET http://example.com/path HTTP/1.1`), 프록시는 URL을 읽어 대상에 연결을 열고, 요청을 전달한 뒤 응답을 다시 전달합니다. HTTPS의 경우, 클라이언트는 먼저 프록시에 `CONNECT example.com:443` 요청을 보내고, 프록시는 대상까지 TCP 터널을 열며, 이후부터 클라이언트와 서버는 프록시를 통해 종단 간으로 TLS를 사용하고, 프록시는 단지 암호화된 바이트를 전달할 뿐입니다.

인증은 보통 `Proxy-Authorization` 헤더(username:password를 사용한 Basic 인증)를 통해 이루어지거나, 프록시 URL에 자격 증명을 인코딩하는 방식(`http://user:pass@host:port`)으로 이루어집니다. 상용 서비스의 지리적 타겟팅 및 세션 매개변수는 일반적으로 사용자 이름에 인코딩됩니다(`customer-USER-country-us-session-12345`).

타입

포워드 HTTP 프록시

상업용 프록시 서비스가 사용하는 형태입니다. 클라이언트 앞단에 위치하며, 더 넓은 인터넷에 대해 클라이언트를 대표합니다. 클라이언트는 프록시 주소를 명시적으로 구성합니다.

리버스 HTTP 프록시

백엔드 서버 앞단에 위치합니다. 로드 밸런싱, 캐싱, SSL 종료에 사용됩니다(Nginx, HAProxy, Cloudflare). 클라이언트는 리버스 프록시가 있다는 것을 알지 못합니다.

HTTP CONNECT 터널

HTTP 프록시가 HTTPS를 처리하는 방식입니다. 클라이언트는 프록시에 목적지까지의 터널을 열도록 요청하고, 이후 그 터널을 통해 목적지와 종단 간으로 TLS를 주고받습니다.

HTTPS 프록시

TLS를 통해 통신하는 HTTP 프록시입니다. 클라이언트에서 프록시로의 연결이 암호화됩니다(CONNECT 터널을 통한 종단 간 TLS에 더해). 흔하지 않으며, 프라이버시 중심 구성에서 사용됩니다.

일반적인 사용 사례

HTTP/HTTPS 콘텐츠 스크래핑 (가장 일반적인 사용 사례)
고정 IP 이그레스를 통한 API 액세스
내부 기업 아웃바운드 필터링
대역폭 절약을 위한 정적 콘텐츠 캐싱
아웃바운드 트래픽을 중앙에서 인증하기
개발 / 테스트 환경에서의 애플리케이션별 HTTP 라우팅
자주 묻는 질문

자주 묻는 질문

다음에 대한 일반적인 질문 http 프록시.

HTTP 프록시는 애플리케이션 계층에서 작동하며 HTTP 요청을 파싱할 수 있습니다. SOCKS5 프록시는 전송 계층에서 작동하며 원시 TCP/UDP를 전달합니다. HTTPS의 경우 그 차이는 대체로 표면적인 것입니다. 두 방식 모두 결국 암호화된 바이트를 터널링합니다. 비HTTP 프로토콜(FTP, SMTP, BitTorrent, 게임)을 프록시해야 할 때는 SOCKS5가 우세합니다.

아니요, 콘텐츠는 볼 수 없습니다. HTTPS의 경우 프록시는 CONNECT를 통해 TCP 터널을 열고 클라이언트와 대상 사이의 암호화된 바이트를 그대로 전달할 뿐입니다. 프록시는 (CONNECT 요청과 TLS SNI를 통해) 대상 호스트명과 바이트 볼륨은 볼 수 있지만, 요청 본문, 헤더, 응답은 볼 수 없습니다.

`proxies={'http': 'http://user:pass@gate.shifter.io:10000', 'https': 'http://user:pass@gate.shifter.io:10000'}; requests.get(url, proxies=proxies)`. http와 https 모두 동일한 프록시 URL을 사용합니다. scheme이 https일 때 Python이 CONNECT 흐름을 자동으로 처리합니다.

예. Shifter는 HTTP/HTTPS(및 SOCKS5)를 통해 레지덴셜 및 ISP(고정 레지덴셜) 프록시 엔드포인트를 제공합니다. 두 프로토콜 모두에서 동일한 자격 증명과 지역 타겟팅 매개변수를 사용하세요. 대부분의 고객은 더 폭넓은 클라이언트 지원 때문에 HTTP를 사용합니다.

HTTP 프록시가 HTTPS를 처리하는 방식입니다. 클라이언트는 프록시에 `CONNECT host:port HTTP/1.1`을 전송하고, 프록시는 목적지로 TCP 소켓을 열며, 이후부터 클라이언트와 목적지는 터널을 통해 종단 간으로 TLS를 주고받습니다. 프록시는 암호화된 콘텐츠를 볼 수 없습니다.

대부분의 상업적 용도에는 프록시로의 HTTP 연결로 충분합니다. HTTPS 대상에 대한 종단 간 TLS는 어느 경우든 암호화된 상태로 유지됩니다. 프록시로의 HTTPS 연결은 사용자와 프록시 사이에 한 겹의 추가 암호화 계층을 더해, 신뢰할 수 없는 네트워크에서 CONNECT 라인과 Proxy-Authorization 헤더에 대한 수동적 관찰을 막아줍니다. 공용 WiFi에서는 사용할 가치가 있지만, 서버에서는 대체로 과합니다.