SOCKS5와 HTTP 프록시는 무엇이 다를까? 지문 브라우저에 설정하기 전에 알아야 할 것들

프록시를 고를 때 대부분은 지역과 대역폭, 가격만 봅니다. 유형 칸은 거의 넘겨버립니다. HTTP냐 SOCKS5냐 하는 그 칸이 사실 세 가지를 결정합니다. DNS 요청이 어느 쪽에서 나가는지, UDP 트래픽이 통과할 수 있는지, 프록시가 요청 헤더를 바꾸는지입니다. 평소 인터넷을 쓸 때는 거의 느낄 수 없지만, MakoBrowser 같은 지문 브라우저 환경에 프록시를 넣는 순간 환경 품질에 곧바로 영향을 줍니다. 아래에서 두 방식의 차이를 먼저 정리하고, 이어서 선택 기준과 설정 및 검증 방법을 안내합니다.

두 방식의 근본 차이: 하나는 웹 언어를 알고, 하나는 전달만 한다

HTTP 프록시는 애플리케이션 계층에서 동작하며 자신을 통과하는 HTTP 요청을 읽을 수 있고, 그래서 내용을 바꿀 능력도 있습니다. SOCKS5는 범용 전달 통로일 뿐, 안에 무엇이 들어 있는지 신경 쓰지 않습니다.

HTTP 페이지에 접속할 때 HTTP 프록시는 요청 주소와 헤더를 볼 수 있습니다. HTTPS에 접속할 때는 브라우저가 먼저 CONNECT 요청을 보내 터널을 만들고, 터널이 만들어진 뒤에는 내용이 프록시에 보이지 않습니다. 이 과정은 MDN의 CONNECT 메서드 설명에 잘 나와 있습니다. 즉 HTTP 프록시가 HTTPS를 처리하는 방식도 터널이지만, 그 능력은 언제나 HTTP 프로토콜을 중심으로 합니다.

SOCKS5는 위치가 다릅니다. RFC 1928은 SOCKS5를 "애플리케이션 계층과 전송 계층 사이의 중간 계층"으로 설명하고 CONNECT, BIND, UDP ASSOCIATE 세 가지 명령을 정의합니다. 쉽게 말하면 트래픽 내용을 해석하지 않고 데이터를 원래대로 목적지로 보내며, 보내는 것이 TCP만도 아닙니다.

차이가 실제 사용에서 갈리는 지점은 주로 다음 몇 가지입니다.

• 어떤 트래픽이 통과하는가: HTTP 프록시는 HTTP와 HTTPS를 처리하고, SOCKS5는 임의의 TCP 트래픽을 전달하며 UDP도 기본 지원합니다.
• 요청을 건드리는가: HTTP 프록시는 HTTP 계층에서 요청 내용이 보이며, 일부 구현은 Via, X-Forwarded-For 같은 헤더를 덧붙입니다. SOCKS5는 애플리케이션 계층 내용을 바꾸지 않습니다.
• 인증 방식: HTTP 프록시는 주로 Basic 인증을 쓰며 자격 증명은 base64 인코딩일 뿐이라 안전성은 HTTPS 보호에 의존합니다. SOCKS5는 별도의 인증 협상을 하며, RFC 1929가 사용자 이름과 비밀번호 방식을 따로 정의합니다.
• 포트 관례: SOCKS 서비스는 전통적으로 1080 포트에서 동작하지만, 공급자가 준 포트를 그대로 넣으면 됩니다.

지문 브라우저에 넣고 나면 실제로 문제가 되는 것은 DNS와 UDP다

프록시 유형을 잘못 고르면 가장 먼저 나타나는 문제는 "연결이 안 된다"가 아니라 DNS 요청이 조용히 로컬 네트워크로 새는 것입니다.

DNS가 어느 쪽에서 해석되는지가 유출 여부를 가른다

도메인이 어느 쪽에서 해석되는지는 프록시 유형의 이름이 아니라 클라이언트 설정이 결정합니다. SOCKS5는 도메인을 프록시 쪽에 그대로 넘겨 처리하는 방식을 지원하며, RFC 1928은 도메인 유형 주소를 따로 정의합니다. 하지만 클라이언트가 기본적으로 그렇게 동작하지는 않습니다. Firefox를 예로 들면 "SOCKS v5 사용 시 프록시 DNS"를 체크해야 해석이 프록시를 거치고, 체크하지 않으면 클라이언트가 먼저 로컬에서 도메인을 IP로 바꾼 뒤 프록시에 넘깁니다. 그래서 DNS 요청이 로컬 통신사 손에 들어갑니다. 이것이 프록시 DNS 유출의 가장 흔한 원인입니다.

HTTP 프록시는 보통 호스트 이름을 프록시가 해석하도록 넘기지만, 이 역시 당연하게 여기면 안 됩니다. WebRTC 직접 연결, 브라우저 사전 해석, 프록시를 거치지 않는 트래픽은 모두 해석 요청을 로컬로 되돌려보낼 수 있습니다.

검증은 어렵지 않습니다. 환경을 시작한 뒤 아무 DNS 유출 검사 페이지에 접속해 해석 서버가 어느 지역에 속하는지 보면 됩니다. 로컬 통신사가 뜬다면 해석이 프록시를 따라가지 않았다는 뜻입니다.

UDP 지원은 언제 중요해지는가

브라우저가 HTTP/3를 지원하는 사이트에 접속하면 QUIC을 시도하고, QUIC은 UDP를 기반으로 합니다. 프록시가 TCP만 지원하면 트래픽은 자동으로 TCP로 되돌아가고 웹 페이지는 평소처럼 열려서 일상에서는 차이를 느끼지 못합니다. SOCKS5가 정말 필요한 경우는 환경 안에 UDP에 의존하는 도구가 함께 돌아갈 때입니다.

웹 운영만 한다면 UDP는 결정 요인이 아니고, 환경에 별도 도구가 있다면 그때 결정 요인이 됩니다.

어떤 상황에 SOCKS5를 쓰고, 어떤 상황이면 HTTP로 충분한가

선택은 어느 쪽이 "더 고급"인지가 아니라, 내 트래픽 구성과 공급자가 주는 유형이 무엇인지로만 판단합니다.

바로 대조해 볼 수 있는 판단 기준 몇 가지입니다.

1. 공급자가 HTTP 유형만 제공하고, 용도가 브라우저 웹 트래픽뿐일 때: HTTP 프록시를 그대로 쓰면 충분합니다.
2. 환경에 브라우저 외에 UDP에 의존하는 도구가 있거나 DNS 노출 면적을 줄이고 싶을 때: SOCKS5를 우선합니다.
3. 프록시로 캐싱, 콘텐츠 필터링, 접근 감사가 필요할 때: HTTP 프록시가 더 맞습니다. 요청 내용을 읽을 수 있다는 점이 바로 그 가치입니다.
4. 계정을 여러 개 열어 소셜 미디어나 스토어 운영만 할 때: 두 유형 모두 충족하며, 실제 차이는 프로토콜에 있지 않습니다.

널리 퍼진 오해 두 가지는 짚고 넘어갈 만합니다. 하나는 "SOCKS5가 무조건 빠르다"인데, 속도는 프록시 서버의 대역폭과 부하, 링크 거리에 달려 있고 프로토콜 유형과 직접 관계가 없습니다. 다른 하나는 "SOCKS5가 더 익명적이다"인데, SOCKS5는 트래픽 내용을 바꾸지 않을 뿐 당신이 누구인지 숨기지 않으며, 로그를 남기는지는 프록시 서비스 제공자가 정합니다.

한 가지 더 짚어둡니다. 프록시 유형은 선택의 여러 파라미터 중 하나일 뿐입니다. 프록시가 전용인지, 지역이 안정적인지, IP를 자주 바꾸는지가 환경 격리에 미치는 영향은 대개 프로토콜 유형보다 큽니다. 유형을 오래 고민하면서 정작 IP가 계속 바뀌는 공유 프록시를 쓴다면 순서가 뒤바뀐 것입니다.

지문 브라우저에서 프록시 설정하기: 유형 입력부터 작동 검증까지

설정 자체는 몇 단계 되지 않지만 순서를 틀리면 계속 되돌아가게 됩니다. 환경 밖에서 먼저 연결을 확인하고, 환경 안에서 설정한 뒤, 마지막으로 브라우저 안에서 다시 점검하세요.

1. 먼저 프록시 자체가 쓸 수 있는지 확인합니다. 호스트, 포트, 유형, 인증 정보를 받은 뒤 환경 밖에서 한 번 연결을 테스트하면 "프록시를 못 쓰는 것"과 "환경 설정이 잘못된 것"을 구분할 수 있습니다.

2. 환경의 프록시 설정을 열고 유형을 선택합니다. 유형은 공급자가 준 것과 반드시 일치해야 합니다. SOCKS5 프록시를 HTTP로 넣으면 바로 연결이 되지 않고, 오류 메시지도 대개 모호해서 환경 고장으로 오해하기 쉽습니다.

   

3. 호스트, 포트, 인증 정보를 입력합니다. 아이디와 비밀번호가 있으면 채우고, 불필요한 공백이 함께 복사되지 않도록 주의하세요. 가장 흔한 저급 실수입니다.

   

4. 저장한 뒤 환경 안에서 프록시 점검을 한 번 실행합니다. 출구 IP와 국가, 지역이 예상과 맞는지 확인합니다.

5. 환경을 시작한 뒤 브라우저에서 다시 한 번 점검합니다. 출구 IP, DNS 해석 위치, WebRTC 세 가지를 중점적으로 봅니다.

6. 고정합니다. 계정 하나에 고정 출구 하나를 대응시키고, "더 안전해 보이려고" 노드를 자주 바꾸지 마세요. 잦은 전환 자체가 이상 신호입니다.

4단계와 5단계는 서로 다른 것을 확인합니다. 환경 안 점검은 프록시 경로가 뚫렸는지, 브라우저 안 재점검은 트래픽이 다른 곳으로 새지 않았는지를 확인합니다. 전자만 하면 DNS와 WebRTC를 놓치기 쉽습니다.

설정 후 반드시 해야 할 세 가지 검증

프록시를 넣었다고 바로 적용되는 것은 아닙니다. 출구 IP, DNS 해석 위치, WebRTC 세 가지를 각각 따로 확인해야 합니다.

• 출구 IP와 지역: 아무 IP 조회 페이지에 접속해 프록시의 IP가 표시되는지, 로컬 IP가 아닌지 확인하고 지역이 공급자 설명과 일치하는지 봅니다.
• DNS 해석 위치: DNS 유출 검사 페이지에서 해석 서버의 소속 지역을 확인합니다. 이 항목은 SOCKS5 상황에서도 중요합니다. 해석 위치는 클라이언트 설정에 달려 있어 당연하게 여길 수 없기 때문입니다.
• WebRTC: 브라우저가 WebRTC를 통해 실제 IP를 노출하는지 점검합니다. 프록시만 바꾸고 환경 격리를 하지 않은 일반 브라우저에서 흔한 문제입니다.

놓치기 쉬운 부분이 하나 더 있습니다. 시간대, 언어, 시스템 지역이 출구 지역과 맞아야 합니다. 미국 지역 프록시를 넣었는데 시간대는 아직 UTC+8에 머물러 있다면, 이 모순은 프로토콜 유형을 잘못 고른 것보다 더 쉽게 눈에 띕니다.

손에 설정할 환경이 열 개, 많게는 수십 개라면 유형과 출구, 지역을 재사용 가능한 구성으로 고정하는 편이 매번 손으로 입력하는 것보다 훨씬 편합니다. MakoBrowser가 프록시를 환경과 함께 관리하는 이유도 여기 있습니다. 환경, 계정, 네트워크 출구를 한곳에서 유지하므로 담당자가 바뀌어도 "이 계정이 어느 노드에 물려 있는지" 다시 묻지 않아도 됩니다. 환경 하나를 먼저 돌려보려면 다운로드 페이지에서 클라이언트를 설치해 시작하면 됩니다.

자주 묻는 질문

SOCKS5와 HTTP 프록시 중 어느 쪽이 빠른가요

정해진 답은 없습니다. 속도는 프록시 서버의 대역폭과 부하, 링크 거리, 대상 사이트에 달려 있고 프로토콜 유형과는 큰 관계가 없습니다. 유형을 고민하기보다 프록시 자체의 회선 품질을 먼저 보세요.

지문 브라우저는 반드시 SOCKS5를 써야 하나요

반드시 그렇지는 않습니다. 웹 트래픽만 다루고 공급자가 HTTP 유형만 제공한다면 HTTP 프록시도 충분합니다. SOCKS5의 강점은 UDP 지원과 통제 가능한 원격 DNS 해석에 모여 있으니, 환경에 UDP에 의존하는 도구가 있을 때 우선 고려하면 됩니다.

프록시를 제대로 넣었는데 왜 실제 IP가 표시되나요

흔한 원인은 세 가지입니다. 유형을 잘못 골라 프록시가 실제로 적용되지 않았거나, 브라우저가 WebRTC로 직접 연결하거나, DNS가 여전히 로컬에서 해석되는 경우입니다. 앞 절의 순서대로 항목별로 점검하면 어느 단계인지 대개 찾아낼 수 있습니다.

HTTP 프록시로 HTTPS 사이트에 접속할 수 있나요

가능합니다. 브라우저가 먼저 CONNECT 메서드로 프록시에 터널을 만들고, 터널 안의 트래픽은 암호화되어 프록시가 구체적인 페이지 내용을 볼 수 없습니다. 이것이 HTTP 프록시가 HTTPS를 처리하는 표준 방식입니다.

프록시 유형이 계정 안전에 영향을 주나요

프록시 유형 자체가 계정 결과를 결정하지는 않습니다. 실제로 작용하는 것은 출구가 안정적인지, 지역이 계정과 일치하는지, 자주 전환하지 않는지입니다. 어떤 도구도 계정이 플랫폼 검증을 받지 않는다고 보장할 수 없으니, 환경을 깨끗하게 유지하고 이상 변동을 피하는 것이 당신이 통제할 수 있는 부분입니다.