SOCKS와 HTTP 프록시: 차이, 속도, 프로토콜 선택

HTTP와 SOCKS 프록시는 중계자를 통해 애플리케이션을 대상에 연결합니다. 브라우저, 스크레이퍼 또는 API 클라이언트에는 CONNECT를 지원하는 HTTP 프록시가 실용적인 출발점입니다. 애플리케이션이 SOCKS를 요구하거나 다른 TCP 프로토콜이 필요하거나 UDP 전달을 지원한다면 SOCKS5가 유용합니다. 두 방식 모두 HTTPS 사이트로 트래픽을 전달할 수 있습니다.

프로토콜은 프로그램이 프록시와 통신하는 방식을 결정합니다. 출구 IP의 출처, 순환, 공유 또는 전용 접근은 별개의 선택 사항으로, 프록시 유형과 구성 선택 안내에서 설명합니다. HTTP에서 SOCKS로 바꾸는 것만으로 이러한 속성이 달라지지는 않습니다.

HTTP와 SOCKS가 연결을 처리하는 방식

HTTP 전달: 프록시가 웹 요청 처리

일반적인 암호화되지 않은 HTTP 요청에서 클라이언트는 프록시에 대상 URL, 메서드, 헤더를 보냅니다. 프록시는 해당 요청을 처리하고 대상에서 응답을 가져옵니다. 설정에 따라 HTTP 규칙을 적용하거나 헤더를 바꾸거나 캐시를 사용할 수 있습니다. 이는 HTTP 프록시가 제공할 수 있는 기능이며, 모든 서비스가 전부 활성화하는 것은 아닙니다.

SOCKS5: 프록시가 애플리케이션 대신 연결 수립

클라이언트는 인증 방식을 합의하고, 필요하면 인증한 뒤 대상 주소와 포트를 전달합니다. 프록시는 요청된 TCP 연결을 수립하고 애플리케이션의 바이트를 중계합니다. 같은 방식으로 HTTPS, SSH 또는 지원되는 다른 TCP 애플리케이션 프로토콜을 전달할 수 있습니다. 프록시는 HTTP 요청을 전달하기 위해 그 내용을 해석할 필요가 없습니다.

CONNECT를 통한 HTTPS: 두 방식이 비슷해짐

일반 HTTP 프록시를 통해 HTTPS 사이트를 열 때 클라이언트는 보통 CONNECT 요청을 보냅니다. 프록시가 터널을 허용하면 클라이언트가 그 안에서 사이트와 TLS 연결을 수립합니다. 프록시는 암호화된 데이터를 중계합니다. SOCKS5도 자체 준비 과정이 끝난 뒤 같은 TLS 교환을 중계할 수 있습니다.

속도와 개인정보 보호를 비교할 때 이 차이가 중요합니다. 터널로 HTTPS를 전달하는 HTTP 프록시는 암호화된 각 페이지 요청을 분석하지 않습니다. 두 유형 모두 보호된 트래픽을 중계합니다. 처리 순서와 HTTP 전달 및 터널링의 차이는 HTTP 및 HTTPS 프록시에서 설명합니다.

HTTP와 SOCKS5 한눈에 비교

아래 비교는 SOCKS5를 기준으로 합니다. 오래된 SOCKS4와 SOCKS4a는 기능이 더 적으며, 주로 기존 소프트웨어가 요구할 때 고려합니다.

HTTP와 SOCKS5 중 어느 쪽이 더 빠른가?

일반적인 준비 과정에서 프록시와 주고받는 횟수가 더 적으므로 HTTP CONNECT를 통한 새 HTTPS 연결이 더 빨리 준비될 수 있습니다. 아래 비교에서는 그 차이가 생기는 가정을 보여 줍니다. 터널이 열리고 나면 긴 파일 내려받기나 후속 요청에서 재사용할 수 있습니다. 지속적인 전송 속도에서 어느 프로토콜이 언제나 우세한 것은 아닙니다.

새 연결: 교환 횟수 계산

프록시와 TCP 연결이 준비된 뒤, 각 요청이 응답을 기다리는 순차적인 준비 메시지 수를 셉니다. 이 비교에는 프록시까지의 TLS 계층이 없습니다. HTTP 인증은 필요하지 않거나, 첫 CONNECT 요청에 인증 정보를 포함해 성공하는 것으로 가정합니다.

따라서 이 가정에서 SOCKS5는 무인증일 때 클라이언트와 프록시 사이의 왕복이 1회, 표준 사용자 이름/비밀번호 인증일 때 2회 추가됩니다. 왕복 시간인 RTT는 메시지가 프록시로 갔다가 응답이 돌아오는 데 걸리는 시간입니다. 예시 RTT가 50 ms라면 추가 교환에 약 50 또는 100 ms가 걸립니다. 이는 프로토콜 순서로 계산한 추정치이며, 프록시 서비스의 벤치마크나 요청 전체 소요 시간이 아닙니다.

두 경로 모두 프록시가 대상에 연결하고 클라이언트가 사이트의 TLS 준비를 마쳐야 합니다. DNS 시간, 처리 시간, 혼잡도는 다를 수 있습니다. HTTP 인증 요청에 대한 추가 응답 과정은 교환 횟수를 늘리며, HTTPS 프록시까지의 TLS에도 별도 준비가 필요합니다. 실제 구성을 비교할 때는 이러한 경우를 포함해야 합니다.

연결 재사용: 초기 차이가 여러 요청에 분산됨

연결 풀은 적합한 연결을 후속 요청에 사용할 수 있도록 유지합니다. HTTPS 연결을 재사용하면 요청마다 TCP, 프록시 협상, 사이트 TLS 핸드셰이크를 반복하지 않습니다. 클라이언트와 대상이 HTTP/2를 지원하면 여러 요청 스트림이 이미 수립된 하나의 연결을 공유할 수 있습니다. HTTP CONNECT 터널과 SOCKS5 연결 모두에서 가능하며, 프록시가 TLS 내부의 HTTP/2 메시지를 분석할 필요는 없습니다.

URL마다 새 HTTP 클라이언트 객체를 만들면 연결 풀이 사라질 수 있습니다. 여기서 클라이언트를 재사용한다는 것은 소프트웨어 객체와 연결을 유지한다는 뜻이며, 프록시에 출구 IP 유지를 요청한다는 뜻이 아닙니다. 일괄 작업이 같은 호스트에 반복 접속한다면 프록시 프로토콜을 바꾸는 것보다 연결을 재사용하는 편이 준비 과정을 더 많이 줄일 수 있습니다. 새로운 대상, 닫힌 연결, 바뀐 프록시 설정에는 여전히 새 터널이 필요할 수 있습니다.

대용량 전송: 가용 대역폭 확인

터널이 수립된 뒤 내려받기 속도는 경로, 패킷 손실, 가용 대역폭, 프록시 부하, 서비스 한도에 따라 달라집니다. CONNECT로 HTTPS를 중계하는 작업도 이미 바이트를 전달하는 작업입니다. SOCKS5가 “HTTP를 읽지 않아서” 더 빠르다는 설명은 이 경우를 놓칩니다.

암호화되지 않은 HTTP에서는 설정된 캐시나 콘텐츠 처리가 결과를 바꿀 수 있습니다. 캐시된 응답을 받는 작업은 원본 서버에서 같은 콘텐츠를 내려받는 작업과 다릅니다. 공정하게 비교하려면 이 차이를 고려해야 합니다.

대규모 웹 스크립트에는 어떤 프로토콜을 사용해야 하는가?

웹 스크립트는 SOCKS5를 사용해도 여전히 HTTP 요청을 보냅니다. 프록시 옵션은 서버에 도달하는 방식을 바꿉니다. 웹페이지를 가져오거나 HTTPS API를 호출하는 새 스크립트라면 특별한 요구 사항이 없는 한 안정적으로 널리 사용되는 HTTP 클라이언트와 HTTP CONNECT부터 시작하세요. 프록시 선택은 설정으로 분리해 같은 요청 로직으로 SOCKS5도 테스트할 수 있게 하세요. 프로젝트에서 이 비교가 중요하다면 둘 다 지원하는 라이브러리를 선택하세요.

HTTP와 SOCKS5 모두 비동기 소프트웨어에서 사용할 수 있습니다. 요청을 동시에 실행할 수 있는지는 프록시 프로토콜이 결정하지 않습니다. 클라이언트 라이브러리가 선택한 프록시 모드로 동시 요청을 보내고, 연결 풀을 유지하며, 진행 중인 작업 수를 제한할 수 있는지 확인하세요. 완료된 작업과 오류를 관찰하면서 동시 실행 수를 늘리세요. 프록시, 네트워크 또는 대상의 한도에 도달하면 연결을 더 늘려도 대기열이 길어지고 재시도가 많아질 수 있습니다.

규모를 늘리기 전 속도 비교 방법

1. 같은 프로그램, 대상 요청, 응답 크기, 동시 실행 수를 사용하세요. 가능하면 같은 출구 IP와 경로를 사용하는 프로토콜 엔드포인트를 비교하세요. 그렇지 않다면 출구 지역과 서비스 한도를 비슷하게 맞추고 차이를 기록하세요.
2. 한 차례는 새 연결로 실행하고, 다른 차례는 준비 실행 후 일반적인 풀링으로 실행하세요. DNS 동작, TLS 보호, 인증, HTTP 버전, 재시도 정책을 동등하게 유지하거나 다른 이유를 기록하세요.
3. 초당 성공적으로 완료한 작업 수와 재시도를 포함한 전체 일괄 작업 시간을 측정하세요. 완료 시간의 중앙값과 95백분위수, 시간 초과, 실패 작업도 기록하세요. 95백분위수는 측정한 작업의 95%가 완료되는 데 걸린 시간을 나타냅니다.
4. 내려받기는 초당 실제로 받은 유효 바이트 수를 기록하세요. 짧은 요청에서는 연결 준비 시간, 첫 바이트까지의 시간, 전체 응답 시간을 구분하세요. 첫 바이트까지의 시간에는 대상이 응답을 생성하기를 기다리는 시간도 포함됩니다.
5. 두 구성을 번갈아 반복 실행하고 의도한 프록시 경로를 확인하세요. 한 테스트가 다른 출구 풀을 사용하거나 직접 연결로 전환됐다면 그 결과로 프록시 프로토콜의 영향만 분리할 수 없습니다.

허용할 만한 오류율에서 실제 작업을 더 빨리 완료하는 구성을 선택하세요. 인증 실패나 불완전한 응답이 빨리 돌아오는 것은 유용한 처리량이 아닙니다. 성능이 비슷하다면 선택한 애플리케이션에서 지원하고 관리하기 더 쉬운 쪽을 우선하세요.

애플리케이션 지원을 먼저 확인해야 하는 이유

“proxy”라고 적힌 입력란이 모든 프로토콜이나 인증 방식을 지원한다는 뜻은 아닙니다. 예를 들어 Chrome의 내장 SOCKS5 기능은 TCP 요청을 지원하지만 SOCKS5 사용자 이름/비밀번호 인증이나 UDP 전달을 구현하지 않습니다. 서비스에 해당 기능이 있더라도 지원하지 않는 브라우저 모드에서 사용할 수 있게 되지는 않습니다.

SSH, 파일 전송 또는 다른 TCP 애플리케이션에는 자체 SOCKS 지원이 편리할 수 있습니다. HTTP CONNECT도 프로그램이 터널을 만들 수 있고 프록시가 대상 포트를 허용하면 다른 TCP 프로토콜을 전달할 수 있습니다. 따라서 “HTTP 프록시”가 언제나 “웹 트래픽 전용”을 뜻하지는 않습니다.

브라우저 프록시 설정이 다른 프로그램이나 브라우저 안의 모든 기능에 자동으로 적용되지도 않습니다. 외부 어댑터에는 별도의 적용 범위와 제한이 있습니다. 버전 차이와 협상 과정은 SOCKS5 및 SOCKS4 프록시에서 다룹니다.

대상 호스트 이름은 누가 확인하는가?

SOCKS5에서는 애플리케이션이 대상을 로컬에서 확인한 뒤 IP 주소를 보내거나, 프록시가 확인하도록 호스트 이름을 보낼 수 있습니다. curl에서 socks5://는 대상의 로컬 확인을 선택하고, socks5h://는 프록시를 통한 확인을 요청합니다. 추가된 문자는 클라이언트 동작을 선택할 뿐, 새로운 SOCKS 프로토콜을 만들지 않습니다.

HTTP 프록시도 URL이나 CONNECT 요청으로 받은 대상 이름을 확인할 수 있습니다. 따라서 두 프로토콜 모두 원격 대상 DNS를 사용할 수 있습니다. 프록시 측 조회는 다른 서버 주소를 반환할 수 있으며 해당 대상에 대한 로컬 조회를 피하게 합니다. 다만 클라이언트는 프록시 자체의 호스트 이름을 확인해야 할 수 있고, 다른 애플리케이션은 각자의 DNS 설정을 유지합니다. 프록시 프로토콜로 추측하지 말고 클라이언트에서 DNS 동작을 선택하세요.

어느 연결이 암호화되는가?

사이트 콘텐츠 보호와 프록시까지의 연결 보호를 구분하세요. HTTPS 사이트는 보통 어느 종류의 터널을 사용하든 클라이언트와 사이트 사이의 애플리케이션 데이터를 암호화합니다. 정상적인 인증서 검증을 사용하며 TLS 가로채기가 설정되지 않았다는 전제입니다.

HTTPS 프록시는 클라이언트와 프록시 사이에 TLS를 추가합니다. 해당 경로에서 프록시 요청과 인증 정보를 보호합니다. 프록시 주소의 https://는 보통 이 보호된 연결을 나타냅니다. 단지 “HTTPS 사이트용 프록시”라고만 설명한 설정은 CONNECT를 지원하는 일반 HTTP 프록시를 뜻할 수도 있습니다.

일반 HTTP 프록시로 보낸 HTTP Basic 인증 정보와 표준 SOCKS5 사용자 이름/비밀번호 교환은 보호되지 않은 해당 네트워크 경로를 관찰할 수 있는 사람이 읽을 수 있습니다. 이후의 웹사이트 TLS 연결이 이전 프록시 로그인을 소급해서 보호하지는 않습니다. 이 보호가 필요하다면 일반 SOCKS5에는 별도의 보안 전송 계층이 필요합니다.

프록시는 자체 TLS 연결의 끝점이며 어디에 연결하라는 요청을 받았는지 압니다. 최종 대상이 일반 HTTP를 사용한다면 프록시까지의 TLS가 그다음 HTTP 연결을 암호화하지는 않습니다. 마찬가지로 SOCKS 전달도 프록시가 내용을 분석할 필요가 없다는 이유만으로 평문 콘텐츠를 숨기지는 않습니다.

UDP나 HTTP/3가 선택에 영향을 주는가?

실제로 UDP가 필요한 애플리케이션을 위해 SOCKS5는 UDP ASSOCIATE를 정의합니다. 클라이언트와 서비스가 이를 구현해야 하고, 네트워크 경로로 데이터그램이 전달돼야 합니다. 일반 HTTP CONNECT는 TCP 터널을 전달합니다. HTTP 기반 UDP 전달은 CONNECT-UDP 같은 추가 방식으로 가능하지만 양쪽에서 구현해야 합니다.

HTTP/3는 UDP 위에서 QUIC을 사용합니다. 프록시를 통해 HTTPS 페이지가 정상적으로 열렸다고 HTTP/3가 작동한다는 증거는 아닙니다. 클라이언트가 TCP 위의 HTTP/2나 HTTP/1.1을 사용했을 수도 있습니다. 이 대체 동작은 웹 스크립트에 적합할 수 있지만 데이터그램이 필요한 기능에서 UDP를 대신하지는 못합니다. 전달 경로와 한계는 프록시를 통한 UDP 및 QUIC을 참고하세요.

SOCKS가 클라이언트를 더 잘 숨기는가?

암호화되지 않은 HTTP 전달에서는 프록시가 원래 클라이언트 정보를 담는 Forwarded 같은 헤더를 추가할 수 있습니다. 일반적인 HTTPS CONNECT 터널은 사이트의 TLS 연결을 종료하지 않고 암호화된 요청에 해당 헤더를 넣을 수 없습니다. SOCKS5도 HTTP 헤더를 자동으로 추가하지 않습니다.

그렇다고 어느 프로토콜이든 익명성이나 웹사이트의 수락을 보장하는 것은 아닙니다. 프록시 운영자는 연결 메타데이터를 관찰할 수 있고, 대상은 계정, 쿠키, 애플리케이션 동작을 식별할 수 있습니다. 출구 IP 평판과 공유 사용자 수는 별도의 요인입니다. 같은 서비스에서 HTTP를 SOCKS로 바꾼다고 차단이 자동으로 해제되거나 웹사이트 세션이 초기화되지는 않습니다.

최종 선택 방법

애플리케이션이 지원하는 프로토콜과 접근 방식부터 확인하세요. 일반 웹 자동화에서는 HTTP CONNECT가 적절한 첫 선택입니다. SOCKS를 중심으로 설계된 애플리케이션이나 지원되는 UDP 방식에는 SOCKS5가 더 적합할 수 있습니다. 그다음 필요한 DNS 동작과 프록시까지의 보호를 선택하고 실제 작업으로 성능을 비교하세요.

선택한 프로토콜에 해당하는 서비스의 실제 호스트 이름과 포트를 사용하세요. 설정에서 http://를 socks5://로 바꾼다고 SOCKS를 제공하지 않는 서버에 해당 기능이 생기지는 않습니다. 규모를 늘리기 전에 요청이 예상한 프록시를 통해 나가는지, 프록시 실패 시 원치 않는 직접 경로로 조용히 전환되지 않는지 확인하세요.