HTTP 프록시란? 유형, 용도, 그리고 VPN과의 차이

휴대폰이나 노트북의 네트워크 설정을 열어보면 HTTP Proxy 항목이 있고, Off, Manual, Auto 같은 선택지가 보일 수 있습니다. 기본 원칙은 아주 단순합니다. 신뢰할 수 있는 관리자나 특정 앱이 프록시 정보를 따로 알려주지 않았다면, 함부로 값을 만들어 넣지 마세요. 프록시 주소는 성능을 끌어올리는 스위치도, 프라이버시를 지켜주는 모드도 아닙니다. 그냥 HTTP 요청이 지나가는 길을 바꿔줄 뿐입니다.

이 작은 설정 화면 뒤에는 생각보다 큰 개념들이 숨어 있습니다. HTTP 프록시는 회사 정책을 강제로 적용하거나, 개발자의 API 호출 경로를 바꾸거나, 공용 응답을 캐시하거나, HTTPS용 터널을 만들 수도 있습니다. 반대로 리버스 프록시는 사용자 앞이 아니라 웹사이트 앞에 놓여서, 반대편에서 동작하기도 합니다. 그렇다고 해서 이런 역할이 있다고 연결이 자동으로 비공개, 익명, 고속, 혹은 허용된 상태가 되는 건 아닙니다.

이 가이드는 마케팅식 표현이 아니라 프로토콜 자체를 설명합니다. HTTP 프록시가 무엇인지, 실제로 어떤 데이터가 오가는지, CONNECT가 일반 포워딩과 어떻게 다른지, SOCKS5와 VPN은 어디에 해당하는지, 그리고 설정을 이리저리 바꾸지 않고도 프록시 문제를 어떻게 디버깅하는지 살펴봅니다.

HTTP 프록시란?

HTTP 프록시는 HTTP 요청을 받아서 대신 전달하거나, 허용된 경우 저장된 응답을 돌려주거나, 아니면 프록시 자체의 응답을 반환하는 중간자입니다. RFC 9110은 클라이언트가 선택한 프록시를 메시지 전달 에이전트로 정의합니다. 클라이언트는 보통 앱 설정, 운영체제 설정, Proxy Auto-Configuration(PAC) 파일, 또는 환경 변수에서 이를 인식합니다.

명시적 포워드 프록시의 흐름은 보통 아래와 같습니다.

client  --->  forward proxy  --->  origin server
        <---                 <---

클라이언트는 먼저 프록시에 연결합니다. 그다음 프록시가 목적지로 향하는 연결을 새로 열거나 재사용합니다. 원본 서버는 보통 프록시의 네트워크 연결을 직접 상대방으로 보게 되지만, 이것만으로 익명성이 보장되지는 않습니다. 헤더, 쿠키, 브라우저 지문, 인증 세션, DNS 동작, 로그 등을 통해 사용자나 조직을 식별할 수 있기 때문입니다. “원본 서버가 다른 출발지 IP를 본다”는 것과 “사용자가 익명이다”는 건 완전히 다른 얘기입니다.

HTTP 프록시는 암호화 그 자체도 아닙니다. 별도의 보안 계층이 없다면 일반 HTTP는 그대로 평문입니다. HTTPS는 프록시를 통해 TLS 터널로 통과할 수 있지만, 암호화는 proxy라는 단어에서 오는 게 아니라 TLS에서 비롯됩니다.

명시적 HTTP 프록시는 요청을 어떻게 처리하나

중요한 차이는 요청 대상에서 바로 드러납니다. HTTP/1.1 클라이언트가 원본 서버와 직접 통신할 때는 보통 origin-form을 보냅니다.

GET /reports/weekly HTTP/1.1
Host: example.com

같은 클라이언트가 명시적 프록시로 일반 HTTP 요청을 보낼 때는, RFC 9112에 따라 프록시가 목적지를 알아볼 수 있도록 absolute-form을 사용합니다.

GET http://example.com/reports/weekly HTTP/1.1
Host: example.com

일반적인 흐름은 다음과 같습니다.

클라이언트가 적용되는 설정 규칙에 따라 프록시를 고릅니다.
프록시에 연결한 뒤 대상 URI가 보이도록 요청을 보냅니다.
프록시는 인증을 요구하거나, 정책을 적용하거나, 캐시를 조회하거나, 요청을 거부할 수 있습니다.
전달이 허용되면 프록시는 알맞은 요청을 원본 서버로 보냅니다.
응답은 프록시를 거쳐 돌아옵니다. 프록시는 허용된 경우 중간 메타데이터를 추가하거나, 메시지를 변환하거나, 캐시 가능한 응답을 저장하거나, 그냥 그대로 전달할 수도 있습니다.

여기서 핵심은 “할 수 있다”입니다. HTTP는 가능한 동작과 상호운용 규칙을 정의할 뿐, 모든 프록시가 콘텐츠를 필터링하거나, 응답을 캐시하거나, 헤더를 바꾸거나, 식별 정보를 숨긴다고 보장하지는 않습니다.

상단은 absolute-form 포워딩, 하단은 HTTPS CONNECT 터널을 보여주는 두 갈래 HTTP 프록시 흐름

프록시가 인증을 요구하면 407 Proxy Authentication Required를 반환할 수 있습니다. 이건 401 Unauthorized와 다릅니다. 407은 프록시용 자격 증명을 뜻하고, 401은 원본 서버 인증 문제를 뜻합니다. RFC 9110은 이 차이를 분명하게 구분합니다. 또 자격 증명은 제대로 보호된 채널에서 다뤄져야 합니다. Basic 인증만으로는 기밀성이 생기지 않습니다.

HTTP 프록시를 통한 HTTPS: CONNECT는 터널이지, 암호화가 아니다

HTTPS 목적지에 접속할 때는 클라이언트가 보통 CONNECT를 써서 프록시에 TCP 터널을 열어 달라고 요청합니다. 이때 요청 대상은 전체 URL이 아니라 host와 port로 이루어진 authority-form입니다.

CONNECT example.com:443 HTTP/1.1
Host: example.com:443

성공 응답을 받은 뒤에는 연결이 터널이 됩니다. 그다음 클라이언트는 그 바이트 스트림을 통해 example.com과 TLS 핸드셰이크를 진행합니다.

client == TLS ==[ proxy relays bytes ]== TLS endpoint at origin

이 일반적인 터널링 모델에서 프록시는 프록시 사용자, 목적지 authority, 타이밍, 바이트 수 같은 연결 메타데이터는 볼 수 있지만, HTTPS 요청과 응답 본문은 TLS로 암호화됩니다. 터널 자체가 암호화 메커니즘은 아닙니다. 이 차이는 장애 분석에서 정말 중요합니다. CONNECT는 성공했는데 그 뒤 TLS 핸드셰이크가 실패할 수도 있기 때문입니다.

일부 관리형 네트워크는 승인된 TLS 가로채기를 수행합니다. 이 구조에서는 중간 장치가 한쪽 TLS 연결을 끝내고, 다른 TLS 연결을 원본 서버 쪽으로 새로 만듭니다. 이때 클라이언트는 해당 배포에서 사용하는 인증 기관을 신뢰해야 합니다. 그러면 중간 장치는 HTTP 콘텐츠를 검사할 수 있습니다. 이것은 모든 HTTP 프록시가 HTTPS를 마법처럼 읽기 때문이 아니라, 그 장치가 TLS 엔드포인트이기 때문입니다. 이런 방식은 관리형 장치에서 명시적으로 관리되는 정책이어야 합니다. 예기치 않은 인증서 오류를 해결하려고 인증서 검증을 끄는 건 운영 환경에서 올바른 해결책이 아닙니다.

프록시 쪽에도 보안 경계가 있습니다. 임의의 호스트와 포트로 CONNECT를 허용하면, 원래 노출할 생각이 없던 서비스로 이어지는 통로가 될 수 있습니다. 운영용 프록시는 목적에 맞게 대상과 포트를 제한해야 합니다.

Forward, Reverse, Explicit, Interception 프록시

프록시 용어는 서로 다른 두 축을 한데 섞어버리면 금방 헷갈립니다.

첫 번째 축은 누가 중간자를 선택하느냐입니다.

Forward proxy는 클라이언트를 대신해 선택됩니다. 해당 클라이언트나 네트워크의 외부 접근을 통제하거나 보조합니다.
Reverse proxy는 HTTP 의미론에서 gateway라고도 하며, 하나 이상의 원본 서버 앞에 위치합니다. 방문자는 공개 서비스에 접속하고, 게이트웨이는 백엔드를 고르거나, TLS를 종료하거나, 허용된 응답을 캐시하거나, 서버 측 정책을 적용합니다.

두 번째 축은 트래픽이 중간자에게 어떻게 도달하느냐입니다.

Explicit proxy는 클라이언트 설정에 명시되어 있습니다. 클라이언트가 의도적으로 그 프록시에 맞게 요청을 만들거나 CONNECT 터널을 엽니다.
Interception proxy는 클라이언트의 명시 설정 없이, 네트워크가 트래픽을 우회시켜 받습니다.

이 라벨들은 겹칠 수도 있습니다. 기업용 forward proxy는 explicit일 수 있습니다. 네트워크 게이트웨이는 일부 외부 트래픽만 가로챌 수도 있습니다. reverse proxy는 방문자에게는 별도의 홉처럼 보이지 않지만, 실제로 클라이언트가 연결하는 서버이기도 합니다.

Interception은 단순히 “설정 화면이 없는 explicit proxy”가 아닙니다. 목적지 주소, 인증, TLS, path MTU에 대한 가정을 흔들 수 있습니다. Squid의 interception 가이드는 이런 운영 제약을 문서화합니다. 네트워크가 이를 만족하지 못하면, 깔끔한 오류 메시지 대신 원인 모를 부분 실패로 이어지는 경우가 많습니다. 참 반갑지 않은 형태죠.

anonymous, elite, high-anonymity 같은 용어는 주로 벤더 분류에 가깝습니다. HTTP의 공식 기능은 아닙니다. 라벨을 보안 보증으로 받아들이지 말고, 필요한 실제 동작—헤더, egress 주소, 인증, 로깅, DNS 해석, 터널 정책—을 기준으로 판단하세요.

HTTP 프록시 vs SOCKS5 vs VPN

이 중 하나가 항상 더 빠르다, 더 싸다, 더 안전하다는 식의 보편적인 순위는 없습니다. 성능은 거리, 혼잡, 암호화, 구현, 프로토콜, 목적지에 따라 달라집니다. 비용은 제공업체와 구축 방식에 따라 달라집니다. 대신 제어 경계를 비교해야 합니다.

질문	HTTP 프록시	SOCKS5 프록시	VPN
클라이언트는 어떤 인터페이스를 쓰나?	HTTP 포워딩과 보통 `CONNECT` 터널링	SOCKS 프로토콜 명령	OS 또는 VPN 클라이언트가 관리하는 가상/네트워크 터널
어떤 트래픽이 대상인가?	설정된 HTTP 프록시를 지원하는 앱의 트래픽	TCP, 그리고 클라이언트와 서버가 지원하면 UDP association	라우팅과 split-tunnel 정책으로 선택된 트래픽
페이로드 암호화를 보장하나?	아니오	아니오	VPN 터널은 보통 설정된 경계 안의 트래픽을 보호하지만, 프로토콜과 정책은 여전히 중요함
보통 어디에서 설정하나?	앱, OS, PAC/WPAD, 또는 환경 변수	개별 앱 또는 라이브러리	OS 또는 VPN 클라이언트, 경우에 따라 앱별
목적지 DNS는 누가 해석하나?	클라이언트, 요청 모드, 구현 방식에 따라 다름	클라이언트가 목적지를 어떻게 제공하느냐에 따라 다름	VPN 라우팅과 DNS 정책에 따라 다름
가장 중요한 판단 질문	이 HTTP 지원 앱이 중간자가 필요한가?	이 앱에 더 일반적인 릴레이 인터페이스가 필요한가?	어떤 기기나 앱의 경로를 암호화된 네트워크 터널로 넣어야 하는가?

HTTP 프록시, SOCKS5 릴레이, split-tunnel VPN의 트래픽 범위를 손그림으로 비교한 그림

SOCKS5는 CONNECT, BIND, UDP ASSOCIATE를 정의합니다. 그래서 HTTP 전용 포워딩보다 범용성이 높지만, 그렇다고 암호화나 익명성을 보장하는 건 아닙니다. 보안은 인증, 외부 보호 채널, 엔드포인트의 동작, 운영 주체에 달려 있습니다.

VPN은 보통 더 넓은 네트워크 경계에서 작동하지만, “VPN이면 기기에서 나가는 모든 바이트를 항상 다 감싼다”는 말은 틀립니다. split tunneling은 특정 경로나 앱만 포함하거나 제외할 수 있습니다. Apple의 VPN 배포 문서는 범위가 제한된 VPN 동작을 지원하는 플랫폼 예시입니다.

한 단어 라벨보다 범위와 신뢰를 기준으로 선택하세요. 하나의 HTTP 클라이언트만 회사 게이트웨이가 필요하다면, 기기 전체 VPN은 오히려 과할 수 있습니다. 여러 앱이 사설 네트워크에 접근해야 한다면, 앱별 HTTP 프록시를 따로 맞추는 건 맞지 않는 추상화일 수 있습니다.

HTTP 프록시 설정은 켜야 하나, 꺼야 하나?

관리되지 않는 가정용 네트워크라면, 신뢰하는 서비스가 주소, 포트, 인증 방식을 분명히 알려주지 않는 한 꺼 두세요. 아무 공개 프록시나 켜는 건 검증되지 않은 운영자의 경로로 트래픽을 보내는 것과 같습니다.

관리형 업무용 또는 학교용 장치라면, 관리자 지침을 따르세요. 익숙하지 않은 설정이라고 해서 먼저 지우지 말고, 먼저 기기 관리 설정, VPN/보안 클라이언트, 또는 관리자에게 확인하세요. 프록시는 접근 제어의 일부일 수 있습니다. 지워버리면 접속이 끊기거나, 나중에 브라우징은 되는 것처럼 보여도 정책 위반이 될 수 있습니다.

“Auto”는 보통 PAC URL이나 자동 탐지 메커니즘을 뜻합니다. PAC 파일은 JavaScript로 되어 있고, URL마다 다른 경로를 돌려줄 수 있습니다. 예를 들어 내부 호스트명은 프록시로 보내고 공개 사이트는 직접 연결하도록 할 수 있습니다. 즉, 브라우저는 같은 설정 화면을 보고도 한 목적지는 되는데 다른 목적지는 실패할 수 있습니다.

메뉴 구성은 버전마다 다르니, 오래된 글의 스크린샷보다 최신 벤더 문서를 기준으로 보세요. 계속 유효한 질문은 아래와 같습니다.

이 설정은 조직에서 관리하나요, 사용자가 직접 넣는 건가요?
Manual, PAC/Auto, 앱별 설정 중 무엇인가요?
어떤 프로토콜과 목적지를 포함하나요?
NO_PROXY나 “simple hostnames 제외” 같은 우회 규칙이 있나요?
앱, OS, 환경 변수, PAC가 서로 다르게 말할 때 어떤 설정이 우선하나요?

마지막 질문은 클라이언트마다 다릅니다. Chrome/Chromium은 보통 플랫폼의 프록시 해석과 통합되지만, 자체 규칙도 있습니다. Firefox는 자체 연결 설정을 사용할 수 있습니다. 명령줄 도구는 종종 환경 변수를 따로 읽습니다. 그래서 시스템 프록시가 설정되어 있다고 해서 모든 앱이 그걸 쓴다는 뜻은 아닙니다.

curl과 Python에서 HTTP 프록시 사용하기

한 번만 요청할 때는 curl의 --proxy 옵션으로 설정이 아주 분명하게 드러납니다.

curl --fail-with-body --show-error \
  --proxy 'http://proxy.example:8080' \
  'https://api.example.com/health'

인증이 필요하다면, 실제 비밀 정보는 소스 파일, 셸 기록, 스크린샷, 글 예시에 넣지 마세요. 환경에서 승인된 자격 증명 방식을 사용해야 합니다. 아래 예시는 일부러 자리표시자를 사용합니다.

curl --fail-with-body --show-error \
  --proxy 'http://proxy.example:8080' \
  --proxy-user "$PROXY_USER:$PROXY_PASSWORD" \
  'https://api.example.com/data'

지속적인 자동화에서는 실패 시 닫히도록 구성하세요. 정책상 반드시 프록시를 써야 한다면, 프록시 오류를 잡아서 조용히 직접 연결로 다시 시도하지 마세요. 직접 연결로 넘어가면 클라이언트의 egress 주소가 노출되거나 접근 정책을 우회할 수 있습니다.

Python Requests는 명시적 매핑을 허용합니다.

import os
import requests

proxy_url = os.environ["APP_PROXY_URL"]
proxies = {
    "http": proxy_url,
    "https": proxy_url,
}

response = requests.get(
    "https://api.example.com/health",
    proxies=proxies,
    timeout=(5, 20),
)
response.raise_for_status()
print(response.json())

위의 https 키는 “HTTPS 목적지에 이 프록시를 사용하라”는 뜻이지, 클라이언트가 반드시 프록시와 TLS를 맺는다는 뜻은 아닙니다. http:// 프록시 URL이라도 CONNECT를 받아 원본 서버로 TLS를 터널링할 수 있습니다. Requests는 고급 프록시 가이드에서 환경 변수 지원과 CA 번들 처리도 설명합니다.

환경 동작은 완전히 똑같지 않습니다. curl은 의도적으로 소문자 http_proxy를 허용하지만, 다른 변수와 도구는 대소문자 규칙이 다를 수 있습니다. NO_PROXY 매칭, CIDR 지원, 앞의 점 처리, 포트, loopback 동작, 우선순위도 서로 다릅니다. 각 런타임 문서를 계약처럼 보세요. curl이 된다고 해서 Requests, Go, 브라우저, 컨테이너가 같은 경로를 고른다는 뜻은 아닙니다.

이런 “해결책”도 피하세요.

# 운영 환경에서 인증서 문제를 숨기기 위해 쓰지 마세요.
requests.get("https://api.example.com", verify=False)

승인된 검사 프록시가 private CA를 사용한다면, 올바른 trust bundle을 설치하거나 참조하세요. 그 프록시가 승인되지 않은 경우에는 멈추고 원인을 조사해야 합니다.

계층별로 HTTP 프록시 문제 해결하기

프록시 장애는 한 번에 한 계층씩 확인하면 훨씬 다루기 쉬워집니다.

구성 선택: 실패하는 앱이 실제로 어떤 프록시 소스를 쓰는지 확인합니다. 수동 설정인지, 시스템 설정인지, PAC인지, 환경 변수인지, 아니면 앱 자체 설정인지 보세요. 우회 규칙도 확인합니다.
이름 해석: 클라이언트가 목적지를 로컬에서 해석하는지, 아니면 프록시가 호스트명을 해석하도록 보내는지 확인합니다. 프록시 호스트명도 따로 테스트하세요.
TCP 연결 가능성: 클라이언트가 프록시 호스트와 포트에 연결할 수 있나요? 여기서의 타임아웃은 HTTP 오류가 아닙니다.
프록시 인증: 407은 프록시가 자격 증명을 요구한다는 뜻입니다. 원본 서버의 401과 헷갈리지 마세요.
HTTP 포워딩: 일반 HTTP 대상이라면 응답 코드를 확인하고, 요청이 올바른 absolute-form 대상인지 살펴보세요.
CONNECT 정책: HTTPS의 경우, 프록시가 해당 목적지 호스트와 포트를 허용하는지 확인합니다. 터널이 거부되면 TLS 단계까지 못 갑니다.
TLS: CONNECT가 성공한 뒤에는 인증서 신원, 신뢰 체인, 프로토콜 협상, 그리고 승인된 interception이 예상된 동작인지 확인합니다.
원본 응답: 목적지에서 온 403, 404, 429는 반드시 프록시 장애를 뜻하지 않으며, 신원을 바꾸거나 제어를 우회할 권한도 주지 않습니다.

구성과 DNS부터 CONNECT, TLS, 원본 상태 코드까지 이어지는 8단계 HTTP 프록시 문제 해결 경로

일부 중간 장치는 진단 정보를 담은 선택적 Proxy-Status 필드를 보냅니다. 있으면 활용하되, 그것만으로 문제 해결 경로를 짜지는 마세요. 어떤 홉이 실패했는지 확인하는 데는 클라이언트, 프록시, 원본 서버 로그가 여전히 가장 믿을 만합니다.

프록시 캐싱은 어떤가요?

공유 캐싱은 유용하지만, 자동으로 되는 건 아니고 조건이 붙습니다. RFC 9111은 공유 캐시가 응답을 재사용하기 전에 메서드, 캐시 키, freshness, 응답 지시자, 인증, 재검증 규칙을 따져보도록 요구합니다.

자주 오해되는 지시자는 네 가지입니다.

private는 공유 캐시가 응답(또는 지정된 필드)을 저장하지 말라는 뜻입니다.
no-store는 메시지를 저장하지 말라는 뜻이지만, RFC는 이것이 완전한 프라이버시 메커니즘은 아니라고 분명히 경고합니다.
no-transform은 중간 장치가 표현을 변형하지 말라고 요청합니다.
proxy-revalidate는 저장된 응답이 오래된 뒤 재사용되는 방식에 영향을 주며, 원래 캐시 불가능한 응답을 캐시 가능하게 바꾸지는 않습니다.

HTTPS가 종단 간으로 터널링되면 포워딩 프록시에는 내용이 보이지 않으므로, 그 프록시는 터널 안의 암호화된 메시지에 대해 HTTP 콘텐츠 캐시처럼 동작할 수 없습니다. 반대로 reverse proxy나 승인된 TLS 종료 게이트웨이는 다른 구조입니다.

HTTP 프록시, 웹 스크래핑, 그리고 Thunderbit

데이터 수집 시스템은 통제된 egress, 지역별 라우팅, 작업 분리, 안정적인 네트워크 식별을 위해 프록시를 사용할 수 있습니다. 하지만 이건 라우팅 능력일 뿐, 허가증은 아닙니다. 프록시가 페이지 수집 권한을 주거나, 접근 제어를 무시하게 하거나, 대상이 요청을 받아들이도록 보장하지는 않습니다. 403, 429, CAPTCHA 같은 응답은 정책을 고려한 처리 방식이 필요하며, 단순히 “프록시 유형만 바꾸면 된다”는 식으로 해결되지 않습니다.

또 하나의 선택지는 추상화 수준입니다. raw forward proxy는 개발자에게 HTTP 라우팅 또는 터널링 인터페이스를 제공합니다. 그 뒤의 가져오기(fetch), 렌더링, 파싱, 스키마 검증, 재시도, 관측성, 규정 준수 판단은 여전히 애플리케이션의 몫입니다.

Thunderbit의 문서화된 인터페이스는 그보다 상위 계층에 있습니다. Thunderbit 문서는 렌더링과 라우팅 기능을 갖춘 URL 기반 추출을 설명하고, Web Scraper API는 URL에서 깔끔한 Markdown을 얻는 방식 또는 스키마 형태의 JSON을 얻는 두 가지 출력 모드를 문서화합니다. 이를 통해 팀이 직접 운영해야 하는 크롤러와 파싱 인프라를 줄일 수 있습니다. 하지만 이것이 모든 대상에 성공을 보장하거나, 접근 제어를 우회하거나, 수집이 승인되었는지 대신 판단해 주지는 않습니다.

전송 동작을 직접 제어해야 하고 나머지 크롤러 책임도 감당할 준비가 되어 있다면 낮은 수준의 프록시 인터페이스를 사용하세요. 실제 요구가 구조화된 페이지 데이터이고, 문서화된 서비스 경계가 그 요구와 맞는다면 더 높은 수준의 추출 인터페이스를 사용하세요. 이 둘은 같은 프록시의 다른 이름이 아니라, 서로 다른 엔지니어링 책임입니다.

핵심 요약

HTTP 프록시는 메시지 전달 중간자이며, 자동 프라이버시나 암호화 기능이 아닙니다.
명시적 HTTP 포워딩은 absolute URI를 사용하고, HTTPS는 보통 CONNECT host:port로 시작해 터널 안에서 TLS를 실행합니다.
터널링 프록시는 일반적으로 TLS로 보호된 HTTP 본문을 읽을 수 없지만, 승인된 TLS interception 게이트웨이는 다른 구조입니다.
forward/reverse, explicit/interception은 서로 다른 축을 설명합니다.
HTTP 프록시, SOCKS5, VPN은 속도나 비용의 일반론이 아니라 트래픽 범위, 설정, 신뢰, 라우팅 정책으로 비교해야 합니다.
신뢰하는 관리자나 의도적으로 사용하는 앱이 프록시 정보를 주지 않았다면 설정은 꺼 두세요.
자동화에서는 프록시 사용을 명시하고, 자격 증명을 보호하며, 우회와 우선순위 규칙을 이해하고, 프록시가 필수일 때는 실패 시 닫히도록 하세요.

자주 묻는 질문

HTTP 프록시는 VPN과 같은 건가요?

아니요. HTTP 프록시는 이를 선택한 애플리케이션을 위해 HTTP를 인식하는 포워딩 또는 터널링 인터페이스를 제공합니다. VPN은 네트워크 터널을 만들고, 정책에 포함된 트래픽의 라우팅을 바꿉니다. 어느 라벨도 익명성을 보장하지 않으며, VPN의 split tunneling 때문에 기기 전체를 항상 다 덮는 것도 아닙니다.

HTTP 프록시는 HTTPS 트래픽을 볼 수 있나요?

일반적인 CONNECT 터널에서는 프록시가 TLS 바이트를 전달할 뿐, 보호된 HTTP 내용을 읽을 수 없습니다. 다만 연결 메타데이터는 볼 수 있습니다. 관리된 클라이언트가 신뢰하는 CA를 사용해 인증서를 종료하는 승인된 게이트웨이라면, 두 개의 TLS 연결 중 한쪽 끝점이기 때문에 내용을 검사할 수 있습니다.

407 Proxy Authentication Required는 무슨 뜻인가요?

프록시가 클라이언트에게 프록시 자격 증명을 요구하고 있다는 뜻입니다. 원본 서버가 보내는 401과는 다릅니다. 자격 증명을 보내기 전에 승인된 인증 방식과 보호 채널을 확인하세요.

HTTP 프록시가 내 IP를 숨겨주나요?

원본 서버는 보통 프록시 연결을 직접 네트워크 상대방으로 보지만, 그것만으로 익명성이 성립하지는 않습니다. 전달된 헤더, 인증, 쿠키, 지문, DNS 동작, 로그 등을 통해 클라이언트가 식별될 수 있습니다.

웹 스크래핑에 프록시가 꼭 필요한가요?

항상 그런 건 아닙니다. 승인된 대상, 요청량, 지역 요건, 아키텍처, 사이트가 공개한 접근 규칙에 따라 달라집니다. 프록시는 라우팅과 egress 제어를 제공할 수 있지만, 승인, 속도 제한 대응, 파싱, 모니터링, 오류 처리를 대신하지는 않습니다.

왜 어떤 앱은 시스템 프록시를 무시하나요?

앱마다 설정 소스와 우선순위 규칙이 다를 수 있습니다. 어떤 앱은 OS 설정을 따르고, 어떤 앱은 자체 설정을 사용하며, 명령줄 도구는 환경 변수를 읽을 수 있습니다. 시스템 패널이 전부를 제어한다고 가정하지 말고, 실패하는 앱의 문서와 우회 규칙을 확인하세요.

더 알아보기

AI를 사용하여 데이터 추출

Google Sheets, Airtable 또는 Notion으로 데이터를 쉽게 전송하세요

Chrome Store Rating

PRODUCT HUNT#1 Product of the Week