프록시 목록과 일부 제공업체는 프록시를 투명(transparent), 익명(anonymous), 엘리트(elite)라는 세 가지 익명성 수준으로 분류합니다. 이 라벨이 설명하는 것은 단 하나, 프록시가 요청의 HTTP 헤더에 무엇을 추가하는지입니다. 투명 프록시는 실제 IP 주소를 그대로 전달하고, 익명 프록시는 IP 주소를 숨기지만 프록시라는 사실은 드러내며, 고익명 프록시라고도 불리는 엘리트 프록시는 아무것도 추가하지 않습니다.
알아두면 유용하지만, 이는 대부분의 구매자가 생각하는 것보다 작은 질문에 대한 답일 뿐입니다. 대상 사이트는 헤더보다 훨씬 많은 것을 살펴보며, 익명성 라벨보다 IP 주소의 유형이 더 중요합니다. 이 가이드에서는 각 수준이 무엇을 드러내는지, 프록시를 직접 확인하는 방법, 그리고 헤더를 추가하지 않는 레지덴셜 프록시가 실제로 일반 방문자처럼 보이는 조합인 이유를 설명합니다.
세 가지 수준을 헤더별로 살펴보기
프록시가 일반 HTTP 요청을 전달할 때, 프록시가 개입했다는 사실을 목적지에 알리는 헤더를 추가할 수 있습니다. 중요한 헤더는 세 가지입니다.
- Via는 요청을 처리한 프록시를 나타냅니다. HTTP 표준은 프록시가 이 헤더를 추가하도록 요구합니다.
- X-Forwarded-For는 원래 클라이언트의 주소를 전달합니다. 핵심 표준에는 포함되지 않지만 거의 모든 프록시와 로드 밸런서가 이를 인식합니다.
- Forwarded는 같은 개념을 표준화한 것으로, RFC 7239에 정의되어 있으며 클라이언트 주소, 프로토콜, 호스트를 위한 필드를 갖습니다.
익명성 수준은 이 헤더들의 조합일 뿐입니다.
| 수준 | 실제 IP 노출 | 프록시 사용 노출 | 일반적으로 추가되는 헤더 |
|---|---|---|---|
| 투명 | 예 | 예 | Via, 사용자 IP가 담긴 X-Forwarded-For |
| 익명 | 아니요 | 예 | Via, 또는 프록시 자체 IP나 빈 값이 담긴 X-Forwarded-For |
| 엘리트(고익명) | 아니요 | 헤더로는 알 수 없음 | 없음 |
투명 프록시가 고장 난 프록시는 아닙니다. 기업 네트워크, 학교, 캐싱 서버는 의도적으로 이를 사용합니다. 목적이 누군가를 숨기는 것이 아니라 트래픽을 필터링하거나 캐싱하는 것이기 때문입니다. 네트워킹에서 “투명”이라는 단어에는 전혀 다른 두 번째 의미도 있습니다. 클라이언트가 따로 설정하지 않아도 트래픽을 가로채는 프록시를 가리키는 것입니다. 이 의미는 프록시 서버 용어집 항목에서 다룹니다. 익명성 척도에서는 단지 “사용자의 주소를 그대로 전달한다”는 뜻일 뿐입니다.
이 라벨은 일반 HTTP에만 적용됩니다
이제 웹의 대부분은 HTTPS로 운영되며, 이로 인해 상황이 달라집니다. HTTPS 사이트의 경우 클라이언트는 CONNECT 요청으로 프록시에 터널을 열어 달라고 요청한 뒤, 그 터널을 통해 목적지와 직접 TLS로 통신합니다. 프록시는 암호화된 바이트를 중계할 뿐입니다. 터널 내부의 헤더를 읽거나 추가할 수 없으므로, 원하더라도 Via나 X-Forwarded-For를 추가할 수 없습니다.
실제로는 다음과 같은 의미입니다.
- HTTPS 대상의 경우, 정상적으로 작동하는 프록시는 헤더 측면에서 모두 엘리트 프록시처럼 동작합니다.
- 일반 HTTP 대상의 경우, 익명성 수준은 실제로 의미가 있으며 확인할 가치가 있습니다.
- HTTPS 테스트에서 “엘리트”로 나온 프록시도 HTTP에서는 헤더가 노출될 수 있으므로, 실제로 사용하는 프로토콜로 테스트하세요.
대상 사이트가 헤더 외에 확인하는 것
프록시 헤더를 제거하는 것은 쉬운 부분입니다. 자동화된 트래픽이나 프록시를 거친 트래픽에 신경 쓰는 사이트는 프록시가 간단히 빼 버릴 수 없는 신호를 살펴봅니다.
IP 주소 자체. 모든 주소는 특정 네트워크에 속하며, IP 데이터베이스는 그 네트워크가 가정용 브로드밴드 제공업체인지, 모바일 통신사인지, 호스팅 회사인지, 알려진 프록시 대역인지를 기록합니다. 클라우드 데이터센터에서 온 요청은 프록시 헤더가 없어도 여전히 서버에서 온 것처럼 보입니다. 그래서 데이터센터 프록시는 엘리트로 표시되어 있어도 보호된 사이트에서 더 자주 차단됩니다.
IP 평판. 스팸, 공격, 대량의 자동화 트래픽을 보낸 주소는 차단 목록에 오릅니다. 공개 목록에 있는 무료 “엘리트” 프록시는 대개 수많은 낯선 사람들과 공유되며 이미 플래그가 지정된 경우가 많습니다.
클라이언트. TLS 핸드셰이크, HTTP/2 설정, 헤더 순서를 통해 요청을 보내는 소프트웨어가 식별됩니다. 프록시는 이 중 어떤 것도 바꾸지 않습니다. TLS 및 HTTP/2 핑거프린팅 가이드에서는 첫 페이지가 로드되기 전에 클라이언트가 얼마나 많은 정보를 드러내는지 설명합니다.
일관성. 시간대, 언어, 위치가 IP 주소와 일치하지 않는 브라우저는 헤더 내용과 관계없이 눈에 띕니다.
행동. 요청 빈도, 탐색 패턴, 일반적인 페이지 리소스가 로드되지 않는 점만으로도 자동화가 드러납니다.
따라서 “엘리트”는 필요조건이지만 충분조건은 아닙니다. 쉽게 드러나는 신호 하나를 없앨 뿐, 요청을 집에 있는 사람이 보낸 것처럼 보이게 만들지는 않습니다.
프록시의 익명성 수준을 확인하는 방법
어떤 프록시든 몇 분이면 테스트할 수 있습니다. 받은 헤더를 그대로 돌려주는 서버로 프록시를 통해 일반 HTTP 요청을 보내고, 프록시가 무엇을 추가했는지 확인하면 됩니다.
직접 관리하는 에코 서버를 사용하세요. 공개 헤더 에코 서비스는 대개 자체 로드 밸런서 뒤에 있어서, 에코 코드가 확인하기 전에 X-Forwarded-For를 제거하거나 다시 쓰기 때문에 투명 프록시가 엘리트처럼 보일 수 있습니다. 공인 IP가 있는 작은 서버라면 몇 줄로 충분합니다.
# echo.py: run on your own server, e.g. python3 echo.py
import json
from http.server import BaseHTTPRequestHandler, HTTPServer
class Echo(BaseHTTPRequestHandler):
def do_GET(self):
body = json.dumps({
"remote_addr": self.client_address[0],
"headers": dict(self.headers),
}).encode()
self.send_response(200)
self.send_header("Content-Type", "application/json")
self.end_headers()
self.wfile.write(body)
HTTPServer(("0.0.0.0", 8080), Echo).serve_forever()그런 다음 일반 HTTP로 프록시를 통해 이 서버를 호출합니다.
import os
import requests
PROXY = os.environ["PROXY_URL"] # e.g. http://user:pass@host:port
ECHO = "http://YOUR_SERVER_IP:8080/" # plain HTTP on purpose
seen = requests.get(ECHO, proxies={"http": PROXY}, timeout=20).json()
PROXY_HEADERS = ["via", "x-forwarded-for", "forwarded", "x-real-ip", "proxy-connection"]
found = {k: v for k, v in seen["headers"].items() if k.lower() in PROXY_HEADERS}
print("Address the server saw:", seen["remote_addr"])
print("Proxy headers added:", found or "none (elite for HTTP)")X-Forwarded-For에 사용자 자신의 주소가 들어 있으면 투명 프록시입니다. 프록시 헤더는 있지만 사용자의 주소가 없다면 익명 프록시입니다. 추가로 아무것도 도착하지 않는다면 HTTP 트래픽에 대해서는 엘리트 프록시입니다. 그다음 IP 데이터베이스에서 출구 주소를 조회해 어떤 종류의 네트워크에 속하는지 확인하세요. 그것이 대상 사이트가 다음으로 확인할 항목이기 때문입니다.
레지덴셜 프록시의 역할
프록시에게 가장 좋은 경우는 헤더를 전혀 추가하지 않고, 일반 가정용 회선에 속한 주소에서 나가는 것입니다. 레지덴셜 프록시 네트워크가 바로 이를 제공합니다. 요청은 선택한 국가나 도시의 가정용 브로드밴드 회선에서 나가며, 그 과정에서 프록시 헤더가 추가되지 않습니다. Shifter의 레지덴셜 게이트웨이는 전달하는 요청에 Via나 X-Forwarded-For를 추가하지 않습니다.
한계도 분명히 해 두는 것이 좋습니다. 어떤 익명성 수준도 계정, 쿠키, 브라우저 핑거프린트를 숨겨 주지 않으며, 제공업체는 여전히 자사 고객이 누구인지 알고 있습니다. 프록시가 익명성 도구가 아닌 이유에 관한 글에서 프록시가 숨기는 것과 숨기지 않는 것을 자세히 다룹니다. 공개 데이터 수집, 다른 시장에서 사이트가 어떻게 동작하는지 테스트, 여러 주소로 요청 분산 같은 작업에는 깨끗한 출구 IP와 일반 브라우저처럼 동작하는 클라이언트를 함께 쓰는 것이 올바른 구성입니다.
자주 묻는 질문
엘리트 프록시란 무엇인가요?
엘리트 프록시는 고익명 프록시 또는 레벨 1 프록시라고도 하며, 사용자의 IP 주소나 프록시 사용 사실을 드러내는 헤더를 전혀 추가하지 않고 요청을 전달합니다. 목적지에는 프록시의 주소만 보입니다.
엘리트 프록시와 레지덴셜 프록시는 같은 것인가요?
아니요. “엘리트”는 프록시가 어떤 헤더를 추가하는지를 설명합니다. “레지덴셜”은 출구 IP가 어디에서 오는지, 즉 데이터센터가 아닌 가정용 인터넷 회선이라는 점을 설명합니다. 데이터센터 프록시는 엘리트이더라도 IP 주소만으로 쉽게 식별될 수 있습니다.
HTTPS 사이트에서도 익명성 수준이 중요한가요?
훨씬 덜 중요합니다. HTTPS에서 프록시는 암호화된 터널을 중계할 뿐 그 안에 헤더를 추가할 수 없습니다. 익명성 수준은 프록시가 요청을 읽고 변경할 수 있는 일반 HTTP 트래픽에서 의미가 있습니다.
웹사이트가 제가 엘리트 프록시를 사용한다는 것을 알 수 있나요?
헤더로는 알 수 없지만 다른 신호로는 알 수 있습니다. IP 주소의 유형과 평판, 클라이언트의 TLS 핑거프린트, 일치하지 않는 위치 설정, 요청 행동 등이 그 신호입니다.
핵심 정리
투명, 익명, 엘리트는 프록시가 일반 HTTP 헤더에 무엇을 추가하는지를 설명할 뿐, 그 이상은 아닙니다. HTTPS에서는 그 차이가 사라지고, 대상 사이트는 대신 IP 주소, 그 평판, 클라이언트 핑거프린트, 행동에 의존합니다. 헤더를 추가하지 않는 프록시를 선택하고, 실제로 사용하는 프로토콜로 확인하며, 무엇보다 출구 IP가 어디에서 오는지에 주의를 기울이세요.