전 세계에는 추정 200억 건의 설치가 이뤄진 cURL이 존재합니다. macOS에는 기본 탑재되어 있고, 대부분의 Linux 배포판과 Windows 10/11에도 기본으로 들어 있습니다. 그런데도 개발자 10명에게 cURL 요청을 프록시로 올바르게 라우팅하는 방법을 물어보면, 10가지의 서로 조금씩 다른 답이 돌아오고, 그중 절반은 인증이나 SOCKS가 끼어드는 순간 바로 깨집니다.
바로 이 간극을 여기서 메우고자 합니다. 대부분의 튜토리얼은 명령어 하나만 보여주고 “이렇게 하면 된다”로 끝납니다. 프록시가 실제로 동작하는지 확인하는 법은 알려주지 않죠(반전: 가끔은 실제로 아무 일도 안 일어납니다). 설정이 아주 조금만 달라져도 바로 등장하는 오류 코드도 거의 설명하지 않습니다. 이 가이드는 HTTP/HTTPS 프록시, SOCKS4/SOCKS5/socks5h, 환경 변수와 그에 따른 함정, 제대로 된 문제 해결 표, 그리고 cURL과 프록시만으로는 더 이상 해결이 안 될 때 어떻게 해야 하는지까지 전부 다룹니다.
cURL이란 무엇이고, 왜 프록시와 함께 써야 할까?
cURL은 URL로부터, 그리고 URL로 데이터를 전송하는 명령줄 도구입니다. 끝입니다. GUI도 없고, 화려한 기능도 없습니다. HTTP, HTTPS, FTP와 몇 가지 다른 프로토콜을 다루는 프로그램일 뿐입니다. 가장 기본적인 사용 예는 다음과 같습니다.
curl https://example.com
이 명령은 페이지를 가져와 원시 HTML을 터미널에 출력합니다. 그 자체로도 유용하지만, 개발자와 기술에 익숙한 비즈니스 사용자들이 cURL을 찾는 진짜 이유는 API 테스트, 데이터 스크래핑, 지역 제한 콘텐츠 확인, CI/CD 파이프라인 내 요청 실행에 있습니다.
프록시는 내 기기와 목적지 서버 사이에 위치해 요청을 대신 전달합니다. 목적지 서버가 보는 것은 내 IP가 아니라 프록시의 IP입니다. 이 점은 여러 정당한 이유에서 중요합니다. 예를 들어 다른 나라에서 내 사이트가 어떻게 보이는지 확인하거나, QA 과정에서 속도 제한을 우회해 테스트하거나, 회사에서 요구하는 게이트웨이를 통해 트래픽을 우회해야 할 때가 그렇습니다. cURL은 HTTP, HTTPS, SOCKS4, SOCKS5까지 폭넓게 지원하며, 이 가이드에서 자주 보게 될 옵션은 -x / --proxy(프록시 주소), -v(상세 출력, 최고의 디버깅 친구), -k(SSL 검증을 건너뜀, 테스트 외에는 사실상 쓰지 말아야 함)입니다.
한 가지 먼저 짚고 넘어가면, 이 가이드는 cURL에서 프록시를 사용하는 네트워크 메커니즘에 관한 내용입니다. 대상 사이트의 이용약관이나 조직의 보안 정책을 무시해도 된다는 뜻은 아닙니다. 프록시는 네트워크 경로를 바꿀 뿐, 합법성이나 허용 범위를 바꾸지는 않습니다.
시작하기 전에
난이도: 초급 ~ 중급
소요 시간: 핵심 예제를 따라 해보는 데 약 15분
준비물:
- cURL 설치됨 (
curl --version으로 확인 가능 — macOS, Linux, Windows 10/11이라면 이미 설치되어 있을 가능성이 매우 높습니다) - 프록시 제공업체가 준 자격 증명: 호스트, 포트, 프로토콜(HTTP/HTTPS/SOCKS), 필요 시 사용자명/비밀번호
- 터미널(macOS의 Terminal, Linux의 쉘, Windows의 PowerShell 또는 CMD)
만약 어떤 이유로든 cURL이 설치되어 있지 않다면, 설치는 한 줄이면 됩니다. macOS에서는 Homebrew로 brew install curl, Debian/Ubuntu에서는 sudo apt install curl, RHEL/CentOS에서는 sudo yum install curl을 사용하세요. Windows에서는 Windows 10 빌드 17063 이후부터 OS에 번들로 포함되어 있습니다.
이 가이드 전반에서는 예시 값으로 프록시 주소는 proxy.example:8080, 인증 정보는 user:pwd를 사용하겠습니다. 실제 프록시 정보로 바꿔 넣으시고, 실자격 증명을 셸 히스토리, 스크린샷, Slack 메시지에 절대 붙여 넣지 마세요. 솔직히 말해 Slack 채널에서 유출된 프록시 비밀번호를 너무 많이 봤습니다.
HTTP 또는 HTTPS 프록시와 함께 cURL 사용하기
가장 흔한 구성이고, 대부분의 프록시 작업에서 쓰게 될 방식입니다.
-x / --proxy 플래그 사용하기
기본 문법은 다음과 같습니다.
curl -x "http://user:pwd@proxy.example:8080" "https://httpbin.org/ip"
-x와 --proxy는 완전히 같은 기능을 합니다. 기억하기 편한 쪽을 쓰면 됩니다. HTTP가 cURL의 기본 프록시 스킴이므로, 기술적으로는 http:// 접두어를 빼고 proxy.example:8080만 써도 됩니다. 그래도 저는 명시적으로 쓰는 편을 권합니다. 6개월 뒤에는 그게 얼마나 명확했는지 스스로에게 감사하게 될 테니까요.
URL 전체는 반드시 큰따옴표로 감싸세요. 비밀번호에 @, #, &가 들어 있다면, 따옴표 없이 작성한 문자열은 cURL에 도달하기도 전에 셸이 먼저 망가뜨립니다.
HTTPS 프록시로 연결하기
일부 제공업체는 프록시 자체로의 연결을 TLS로 처리합니다. 단지 프록시에서 대상 서버로 가는 연결만이 아니라, 내 기기에서 프록시로 가는 구간도 암호화하는 방식입니다. 이건 HTTPS 사이트를 스크래핑하는 것과는 다른 이야기입니다. 프록시 프로토콜과 대상 프로토콜은 서로 독립적입니다. 지정 방법은 다음과 같습니다.
curl -x "https://user:pwd@proxy.example:8080" "https://httpbin.org/ip"
여기서 인증서 오류가 나더라도 -k를 덧붙이고 넘어가고 싶은 유혹은 참으세요. 이 옵션은 SSL 인증서 검증을 완전히 비활성화합니다. 5분짜리 로컬 테스트에서는 괜찮을 수 있지만, 운영 환경이나 실제 사용자 데이터와 맞닿는 경우엔 매우 나쁜 선택입니다. 기업용 프록시가 TLS를 가로채는 환경(MITM 구성, 엔터프라이즈에서 흔함)이라면, 올바른 해결책은 검증을 끄는 것이 아니라 프록시의 CA 인증서를 가져와 신뢰 체인에 추가하는 것입니다.
--proxy-user로 인증하기
자격 증명을 URL에 억지로 넣지 않고 별도 플래그로 분리할 수도 있습니다.
curl -x "http://proxy.example:8080" --proxy-user "user:pwd" "https://httpbin.org/ip"
대문자 -U는 대상 사이트 인증(-u / --user, 소문자)과 다르다는 점에 주의하세요. 이걸 헷갈리면 프록시 비밀번호를 엉뚱한 곳으로 보내는 실수를 하게 됩니다. Basic 대신 NTLM이나 Digest 인증을 쓰는 기업 환경이라면 --proxy-user와 함께 --proxy-ntlm 또는 --proxy-digest를 추가하면 됩니다.
SOCKS 프록시와 함께 cURL 사용하기: SOCKS4 vs. SOCKS5 vs. socks5h
SOCKS 프록시는 HTTP 프록시보다 낮은 계층에서 동작합니다. 어떤 프로토콜을 터널링하는지 신경 쓰지 않기 때문에, HTTP가 아닌 트래픽, Tor 회선, 그리고 프라이버시가 중요한 작업에 유용합니다. 많은 경쟁사 가이드는 이 부분을 명령어 하나만 던지고 넘어가지만, SOCKS4, SOCKS5, socks5h://의 차이는 실제로 중요하므로 그렇게 하면 안 됩니다.
| 기능 | SOCKS4 | SOCKS5 | socks5h:// |
|---|---|---|---|
| TCP 지원 | 예 | 예 | 예 |
| UDP 지원 | 아니오 | 예 | 예 |
| 인증 | 아니오 | 예 | 예 |
| 원격 DNS 해석 | 아니오 | 아니오(로컬 DNS) | 예(프록시가 해석) |
| Tor 호환 | 아니오 | 위험함(DNS 유출 가능) | 예 |
사람들이 실제로 가장 많이 당하는 부분은 DNS 해석입니다. socks5://를 쓰면 연결을 프록시에 넘기기 전에 내 기기가 호스트명을 먼저 해석합니다. 즉, 실제 HTTP 트래픽은 프록시를 통해 가더라도 로컬 DNS 확인자, 더 나아가 ISP가 내가 어떤 도메인에 접속하려는지 그대로 보게 됩니다. socks5h://는 호스트명 해석을 프록시가 대신 하도록 해서 이 누수를 막습니다. 그래서 Tor 문서가 socks5h://를 강조하는 것입니다. 그냥 socks5://를 쓰면 Tor가 제공해야 할 익명성의 상당 부분이 무너집니다.
cURL에서 각 방식은 다음과 같습니다.
curl --socks4 "proxy.example:1080" "http://example.com"
curl -x "socks5://user:pwd@proxy.example:1080" "http://example.com"
curl -x "socks5h://user:pwd@proxy.example:1080" "http://example.com"
특별한 이유가 없다면 기본값은 socks5h://로 두세요. 추가 비용은 없고, 그렇지 않으면 눈치채지 못했을 누수를 막을 수 있습니다.
환경 변수로 프록시 설정하기(그리고 함정 피하기)
매번 -x를 입력하는 건 금방 지칩니다. 환경 변수를 쓰면 셸 세션당 한 번만 프록시를 설정하고, 이후의 모든 cURL 호출이 이를 자동으로 상속받습니다. cURL 매뉴얼은 http_proxy, HTTPS_PROXY, ALL_PROXY, NO_PROXY를 지원 변수로 문서화하고 있습니다.
기본 사용법
export http_proxy="http://user:pwd@proxy.example:8080"
export HTTPS_PROXY="http://user:pwd@proxy.example:8080"
export ALL_PROXY="socks5h://proxy.example:1080"
여기서 사람들이 늘 헷갈리는 부분이 있습니다. 변수명은 프록시의 프로토콜이 아니라 대상 URL의 프로토콜을 가리킵니다. 즉 http_proxy는 http:// URL에 대한 요청을, HTTPS_PROXY는 https:// URL에 대한 요청을 제어합니다. 두 변수 모두 정확히 같은 HTTP 프록시 서버를 가리키도록 해도 전혀 이상하지 않습니다.
NO_PROXY로 우회하기
export NO_PROXY="localhost,127.0.0.1,.internal.example"
쉼표로 구분하며, .internal.example 앞의 점은 하위 도메인 전체에 대한 와일드카드처럼 작동합니다. NO_PROXY는 다른 모든 설정보다 우선합니다. 명령줄에 -x를 명시해도 NO_PROXY와 일치하면 해당 요청은 프록시를 우회합니다.
실제로 많이 걸리는 함정들
export를 빼먹는 경우.http_proxy=http://...만 입력하고export를 하지 않으면, 변수는 현재 셸에만 존재하고 자식 프로세스인 cURL에는 보이지 않습니다. 제 경험상 “프록시가 안 된다”는 문의의 가장 흔한 원인입니다.- 대소문자 문제. cURL은 특히 소문자
http_proxy를 먼저 확인하고, 두 가지가 모두 있으면 소문자에 우선순위를 둡니다. 다른 도구들은 대문자만 읽기도 합니다. “변수가 안 읽힌다”고 느껴지면 대소문자가 다른 중복 항목이 있는지 확인하세요. - PowerShell의
curl별칭 함정. PowerShell 5.1에서curl을 입력하면 실제 cURL이 아니라Invoke-WebRequest가 실행됩니다. 이건 완전히 다른 도구이며 플래그도 다릅니다. Windows에서-x가 이상한 오류를 낸다면curl.exe를 명시해서 진짜 cURL이 실행되는지 확인하세요. - Windows 문법 차이. CMD에서는
set http_proxy=...를 쓰고, PowerShell에서는$env:http_proxy = "..."를 씁니다. 터미널 세션마다 이걸 섞어 쓰면 오후가 통째로 날아갈 수 있습니다. - 오래된 변수.
unset http_proxy와unset https_proxy는 더 이상 유효하지 않은 프록시 설정을 지워서, 조용히 모든 요청을 잘못된 경로로 보내며 실패하게 만드는 문제를 없애 줍니다.
빠르게 켜고 끄려면 .bashrc에 몇 개의 별칭을 넣어두는 것이 꽤 유용합니다.
alias proxyon='export http_proxy="http://proxy.example:8080"; export https_proxy="http://proxy.example:8080"'
alias proxyoff='unset http_proxy; unset https_proxy'
cURL이 항상 프록시를 사용하게 만들기(설정 파일)
대부분의 시간을 기업용 프록시 뒤에서 보낸다면, .curlrc 파일(유닉스 계열은 홈 디렉터리)이나 _curlrc(Windows는 app-data 폴더)를 사용해 환경 변수를 건드리지 않고도 지속적인 기본값을 설정할 수 있습니다.
proxy="http://proxy.example:8080"
어떤 한 번의 요청에서만 이를 건너뛰고 싶다면 --noproxy "*"를 사용해 그 명령 한 번에만 설정을 무시할 수 있습니다. 일반적으로 우선순위는 명령줄 플래그 > 환경 변수 > 설정 파일 순서이므로, 충돌이 있을 경우 명령줄의 -x가 항상 이깁니다.
중요한 주의사항 하나: .curlrc에 평문 비밀번호를 넣지 마세요. 동기화되거나 백업되거나, 실수로 저장소에 커밋될 수 있는 위치라면 더더욱 안 됩니다. CI 파이프라인에서는 플랫폼의 비밀 관리자를 사용하고, 자격 증명은 마스킹된 환경 변수로 주입하는 편이 안전합니다.
프록시가 실제로 작동하는지 확인하는 방법
대부분의 다른 가이드가 건너뛰는 부분이면서, 디버깅 시간을 가장 많이 아껴주는 부분입니다. 프록시를 설정한 뒤 실제로 트래픽이 그 경로로 가고 있다고 가정하는 방식 때문에, 프록시를 전혀 쓰지 않은 채로 스크래퍼 문제를 몇 시간씩 붙잡는 일이 벌어집니다.
방법 1: 외부 IP 비교하기
같은 IP 확인 요청을 두 번 실행하세요. 한 번은 직접, 한 번은 프록시를 통해서 비교합니다.
curl https://httpbin.org/ip
curl -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip
두 명령이 같은 IP 주소를 반환한다면 프록시는 아무 역할도 하지 않은 것입니다. 플래그 문법, 환경 변수, 또는 NO_PROXY가 우연히 대상과 매칭되는지 확인하세요.
방법 2: 상세 출력 읽기
프록시 요청에 -v를 추가하면 cURL이 전체 핸드셰이크를 출력합니다.
curl -v -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip
* Connected to proxy.example (xx.xx.xx.xx) port 8080 같은 줄이 보이고, 이어서 > CONNECT httpbin.org:443 HTTP/1.1, 그리고 결국 < HTTP/1.1 200 Connection established가 나타나는지 보세요. 이 흐름 — 프록시에 연결한 뒤 CONNECT 터널로 대상에 접속하는 과정 — 은 HTTP CONNECT 메서드가 실제로 동작하는 모습이며, HTTPS 대상이 HTTP 프록시를 거칠 때 정확히 이렇게 되어야 합니다. CONNECT 줄이 끝내 보이지 않는다면 프록시 플래그가 적용되지 않은 것입니다. 한 가지 주의: -v는 오직 디버깅 중에만 사용하고, 어디든 공유하기 전에는 반드시 출력 내용을 가리세요. 상세 모드에서는 프록시 자격 증명이 평문으로 드러날 수 있습니다.
방법 3: 나란히 비교하기
특히 지역 제한 테스트라면, 두 결과를 파일로 저장해 diff를 해보세요.
curl https://httpbin.org/ip > direct.json
curl -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip > proxied.json
diff direct.json proxied.json
응답 본문(또는 지역 제한 콘텐츠의 경우 헤더)이 다르다면, 프록시가 실제로 네트워크 경로를 바꾸고 있다는 시각적 증거를 확보한 셈입니다. 더 파고들기 전에 의심을 빠르게 정리할 수 있는 가장 간단한 방법입니다.
흔한 cURL 프록시 오류 해결하기
대부분의 가이드는 이 부분을 대충 넘기며 -k 한 번 언급하고 끝냅니다. 이 주제는 제대로 된 참조표가 필요합니다.
| 오류 | 가능한 원인 | 해결 방법 |
|---|---|---|
curl: (7) Failed to connect | 프록시 호스트/포트가 잘못되었거나 프록시가 다운됨 | 주소를 확인하고, telnet host port 또는 nc -zv host port로 원시 연결을 테스트 |
407 Proxy Authentication Required | 프록시 자격 증명이 없거나 잘못됨 | --proxy-user user:pass를 추가하고, 제공업체가 Basic이 아니라 NTLM/Digest/Negotiate를 요구하는지 확인 |
curl: (56) Recv failure: Connection reset by peer | 전송 중 프록시가 연결을 끊음 | 제공업체에 프록시 안정성을 확인하고, TLS 종료 프록시라면 검증을 강제 해제하지 말고 인증서 처리 방식을 점검 |
curl: (28) Connection timed out | 방화벽 차단, 오래된 프록시 설정, 잘못된 포트 | env | grep -i proxy로 남아 있는 변수를 확인하고, 오래된 항목을 제거한 뒤, 직접 요청으로 원인을 분리 |
| 인증서 검증 실패 | 신뢰되지 않거나 가로채는 프록시 인증서 | 올바른 CA 체인을 받아 --proxy-cacert 사용; 일회성 진단 외에는 검증 비활성화를 피할 것 |
이런 문제에서 가장 먼저 할 일은 항상 -v를 붙이는 것입니다. 그러면 DNS 해석, TCP 연결, TLS 핸드셰이크, 프록시 인증 교환 중 어디에서 끊기는지 정확히 알 수 있어, 세 자리 오류 코드만 보고 추측하는 일을 피할 수 있습니다.
특히 기업용 프록시에서는 --proxy-ntlm과 --proxy-negotiate가 Windows 도메인 인증 방식을 다룹니다. 그리고 cURL이 네이티브로 진짜 잘 처리하지 못하는 것이 하나 있는데, 바로 PAC 파일(기업 환경에서 프록시를 동적으로 지정하는 Proxy Auto-Config 스크립트)입니다. 회사가 이를 사용한다면 브라우저의 네트워크 설정 등을 통해 실제 프록시 호스트와 포트를 수동으로 추출해야 합니다. cURL에는 PAC 파서가 내장되어 있지 않기 때문입니다.
cURL + 프록시만으로는 부족할 때
프록시를 붙인 cURL은 정적 HTML, REST API 호출, 단순 데이터 수집을 거의 가능한 한 잘 처리합니다. 하지만 최신 웹이 가장 즐겨 쓰는 방어막 앞에서는 한계가 드러납니다. JavaScript로 렌더링되는 SPA, Cloudflare나 Akamai 같은 안티봇 시스템, CAPTCHA 장벽이 대표적입니다. 이런 구조 뒤에 있는 React나 Vue 앱에 cURL을 보내면, 돌아오는 것은 비어 있는 <div id="root"></div>일 가능성이 큽니다. 기술적으로는 성공한 요청이지만, 실질적으로는 쓸모없는 데이터입니다. 이건 cURL의 버그가 아닙니다. 그냥 브라우저가 아닐 뿐입니다.
터미널에서 cURL을 쓰는 데 익숙한 상태에서 이 벽을 만났다면, 자연스러운 다음 단계는 완전히 다른 도구로 갈아타는 것이 아니라 렌더링과 구조화를 대신 해줄 계층을 더하는 것입니다. 바로 이 간극을 메우도록 설계된 것이 Thunderbit의 개발자 도구입니다.
| 상황 | cURL + 프록시 | Thunderbit API (POST /extract) |
|---|---|---|
| 정적 HTML 페이지 | 완벽하게 동작 | 동작하며, 구조화된 데이터도 반환 |
| JS 렌더링 SPA | 빈/부분 HTML만 얻음 | renderMode: "full"로 JS 처리 |
| 안티봇 / CAPTCHA | 차단됨 | 내장 처리 |
| 구조화된 데이터 출력 | 원시 HTML — 직접 파싱 필요 | 자체 스키마 기반 JSON |
| 대량 처리(100개 이상 URL) | 수동 루프 + 직접 속도 제한 처리 | POST /batch/extract |
Thunderbit의 Open API는 JS 비중이 높은 페이지에서도 스키마에 맞는 JSON을 바로 돌려주는 /extract 엔드포인트와, 깔끔한 Markdown 변환용 /distill 엔드포인트를 제공합니다. 둘 다 지금까지 cURL 명령을 실행하던 바로 그 터미널 세션에서 호출할 수 있습니다. Claude나 Cursor 같은 AI 코딩 어시스턴트를 위한 MCP 서버도 있고, 스크립트 안에서만 처리하고 싶다면 CLI(npx @thunderbit/thunderbit-cli extract <url> --schema fields.json)도 사용할 수 있습니다. 물론 이 중 어느 것도 cURL이 잘하는 일을 대체하는 건 아닙니다. 다만 cURL이 구조적으로 더 나아갈 수 없는 구간을 이어받아 줄 뿐입니다. AI 보조 추출이 직접 스크래퍼 로직을 짜는 방식과 어떻게 다른지 더 넓은 그림을 보고 싶다면 AI 웹 스크래핑 개요와 최고의 AI 웹 스크래퍼 비교 글이 도움이 되고, 비즈니스 관점에서 접근 중이라면 코딩 없이 웹 스크래핑하기 글이 좋은 입문서가 될 것입니다.
마무리
cURL과 프록시를 올바르게 연결하는 일은 실제 실패 지점을 알기만 하면 어렵지 않습니다. 그리고 놀랍게도, 그중 거의 아무것도 프록시 자체의 문제가 아닙니다. export를 빼먹는 것, -u와 -U를 혼동하는 것, socks5h:// 대신 socks5://를 쓰는 것, PowerShell의 curl 별칭을 curl.exe 대신 실행하는 것. 이 중 어느 하나도 프록시 제공업체와는 상관없는, 그럴듯하게 보이는 혼란스러운 오류를 만듭니다.
가장 시간을 아껴주는 습관은 먼저 검증하고 그다음 문제를 파고드는 것입니다. IP 확인을 먼저 돌리고, -v 출력을 훑어보며, 실제로 프록시가 요청 경로에 들어가 있는지 확인한 뒤에야 하위 문제를 의심하세요. 그리고 대상이 깔끔한 HTML 대신 JavaScript를 던져주기 시작한다면, 그건 더 많은 플래그로 해결할 cURL 문제가 아니라 렌더링용 도구가 필요하다는 신호입니다. 예를 들면 Thunderbit API는 무료 플랜도 제공하니, 원시 HTML 대신 JSON이 바로 나오는 차이를 직접 확인해볼 수 있습니다.
자주 묻는 질문
cURL은 기본적으로 프록시를 사용하나요?
아니요. http_proxy / HTTPS_PROXY 환경 변수를 설정했거나 .curlrc 파일에 프록시를 구성한 경우가 아니라면, cURL은 프록시 없이 대상에 직접 연결합니다.
한 번의 요청만 프록시 없이 보내려면 어떻게 하나요?
해당 명령에 --noproxy "*"를 추가하세요. 셸 세션 전체에서 끄려면 unset http_proxy && unset https_proxy를 실행하면 됩니다.
회전형 프록시와 cURL을 함께 사용할 수 있나요?
네. 제공업체가 회전 게이트웨이(요청마다 새 IP를 할당하는 단일 엔드포인트)를 제공한다면, 다른 프록시처럼 -x를 그 게이트웨이 주소로 지정하면 됩니다. JS 렌더링 대상에 대한 더 복잡한 회전 로직이 필요하다면, Thunderbit 같은 API 계층이 회전과 안티봇 처리를 내부에서 맡아 주므로 재시도 로직을 직접 관리할 필요가 없습니다.
socks5://는 왜 DNS 요청이 새고 socks5h://는 그렇지 않나요?
<socks5://는 연결 요청을 프록시에 보내기 전에 로컬 기기가 먼저 대상 호스트명을 해석합니다. 그래서 ISP의 DNS 확인자가 내가 방문하는 도메인을 보게 됩니다. 반면 socks5h://는 호스트명 해석을 프록시 자체로 넘기므로, 로컬에서는 대상 정보가 드러나지 않습니다.
프록시와 함께 cURL을 쓰는 건 합법인가요?
대부분의 관할권에서 프록시 자체를 사용하는 것은 합법입니다. 중요한 것은 무엇을 하느냐입니다. 항상 대상 사이트의 이용약관, 해당되는 경우 robots.txt, 관련 개인정보 보호법을 준수하세요. 이 가이드는 기술적 메커니즘만 다루며, 어떤 특정 사용 사례에 대한 법적 허가를 의미하지는 않습니다.
더 알아보기
