Wget 프록시 설정은 겉으로 보면 5초면 끝날 일처럼 보입니다. 그런데 요청이 프록시를 아예 우회하고 있는데도 에러 메시지 하나 없이 그냥 넘어가는 이유를 찾느라 한 시간을 날리는 순간, 얘기가 완전히 달라집니다. 이런 상황은 숙련된 시스템 관리자든 신입 개발자든 가리지 않고 정말 자주 봤습니다.
문제의 원인은 대개 프록시 자체가 아닙니다. Wget이 프록시 설정을 읽는 네 가지 방식, 변수 대소문자를 잘못 썼을 때 조용히 실패하는 동작, 그리고 어떤 매뉴얼에도 자세히 안 나오는 기업 네트워크 특유의 제약 때문인 경우가 대부분입니다. 이 가이드에서는 Wget에 프록시를 설정하는 모든 방법, 여러 방식이 충돌할 때 실제로 어떤 우선순위가 적용되는지, 흔한 오류별 터미널 출력 예시, 그리고 다른 글에서는 거의 다루지 않는 Windows 및 기업 방화벽 환경까지 모두 살펴봅니다.
- 난이도: 초급 ~ 중급
- 예상 소요 시간: 읽고 설정하는 데 약 15분, 익숙해지면 약 2분
- 준비물: 정상 동작하는 Wget 설치(아래 안내 참고), 프록시 주소(호스트 + 포트), 그리고 필요하다면 프록시 계정 정보
구조화된 데이터 추출을 위해 Thunderbit 사용해 보기
Wget이란 무엇이고, 왜 프록시와 함께 쓰나요?
Wget은 브라우저 없이 인터넷에서 파일과 웹페이지를 내려받는 명령줄 도구입니다. GNU의 공식 설명에서는 이를 "비대화형 네트워크 다운로드 도구"라고 부르는데, 즉 백그라운드에서 실행되고, 끊긴 전송을 이어받으며, 사람이 일일이 클릭하지 않아도 재귀 다운로드를 처리한다는 뜻입니다.
이 맥락에서 프록시는 중간 서버 역할을 합니다. 내 기기가 대상 웹사이트에 직접 연결하는 대신, Wget이 먼저 프록시로 요청을 보내고 프록시가 이를 대신 전달합니다. 이렇게 쓰는 이유는 보통 다음과 같습니다.
- 기업 방화벽 준수 — 회사 정책상 모든 외부 트래픽을 승인된 프록시로 보내야 함
- 개인정보 보호 및 IP 관리 — 실제 IP가 아니라 프록시의 IP로 요청이 나감
- 지역별 테스트 — 특정 지역에서만 열리는 리소스 접근 또는 CDN 동작 확인
- 데이터 수집 파이프라인 — 연구나 모니터링을 위해 회전 프록시를 통해 HTML 다운로드
- CI/CD 환경 — 제한된 네트워크에서 프록시를 통해서만 인터넷에 접근 가능한 빌드 러너
Wget은 기본적으로 HTTP, HTTPS, FTP 프록시를 지원합니다. SOCKS5는 지원하지 않습니다. SOCKS5가 필요하다면 curl은 socks4://, socks5://, socks5h://를 네이티브로 지원합니다. 또는 proxychains4 같은 도구로 Wget을 감싸서 사용할 수도 있습니다.
Linux, macOS, Windows에 Wget 설치하기
프록시를 설정하기 전에 먼저 Wget이 설치되어 있어야 합니다. 이 부분은 짧게 넘어가겠습니다. 본론이 아니라 전제 조건이니까요.
Linux (Debian/Ubuntu 및 RHEL/CentOS)
# Debian/Ubuntu
sudo apt update
sudo apt install wget
# RHEL/CentOS/Fedora
sudo dnf install wget
# 버전 확인
wget --version
Ubuntu 24.04 LTS에는 Wget 1.21.4가 포함되어 있고, Debian Trixie에는 1.25.0이 있습니다. CentOS Stream 10 패키지는 1.24.5를 보여줍니다.
macOS (Homebrew)
brew install wget
wget --version
Homebrew의 공식 formula는 현재 안정 버전인 Wget 1.25.0을 제공하며, 지난 1년간 396,818회 설치되었습니다.
Windows (Chocolatey 및 수동 설치)
choco install wget
wget --version
Chocolatey의 GNU Wget 패키지는 총 다운로드 수 1,000만 회 이상으로 표시되지만, 현재 버전은 1.21.4입니다. 실행 파일은 보통 C:\ProgramData\chocolatey\bin\wget.exe에 설치됩니다.
Windows 사용자에게 한 가지 주의할 점이 있습니다. Wget이 .wgetrc를 어디서 찾는지는 빌드에 따라 다릅니다. 자세한 내용은 아래 Windows 섹션에서 설명합니다.
프록시와 함께 Wget을 사용하는 4가지 방법과 선택 기준
방법은 네 가지이며, 각각 적용 범위와 우선순위가 다릅니다.
- 명령줄
-e옵션 — 한 번만 쓰는 단일 명령 - 사용자 설정 파일 (
~/.wgetrc) — 해당 사용자가 실행하는 모든 Wget 명령에 적용 - 시스템 설정 파일 (
/etc/wgetrc) — 이 머신의 모든 사용자에게 적용 - 환경 변수 (
http_proxy,https_proxy) — 현재 셸 세션 전체에 적용
방법 1: 명령줄 옵션(일회성 프록시)
빠른 테스트에 가장 좋습니다. 명령이 끝나면 설정도 사라집니다.
wget -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://example.com/file.zip
HTTPS 대상인 경우:
wget -e use_proxy=on -e https_proxy=http://HOST:PORT/ https://example.com/
간단한 확인 테스트 — 프록시를 통해 현재 보이는 IP를 가져옵니다.
wget -qO- -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://ifconfig.me
출력에 내 IP가 아니라 프록시 IP가 나오면 정상입니다.
방법 2: 사용자 설정 파일 (~/.wgetrc)
~/.wgetrc에 아래 내용을 추가하세요. 파일이 없다면 새로 만들면 됩니다.
use_proxy = on
http_proxy = http://proxy.company.com:8080/
https_proxy = http://proxy.company.com:8080/
no_proxy = localhost,127.0.0.1,.internal.company.com
= 앞뒤에 공백이 있는 점에 유의하세요. 이것이 문서화된 .wgetrc 문법입니다. 이제 이 사용자로 실행하는 모든 Wget 명령은 프록시를 거치게 됩니다.
방법 3: 시스템 전체 설정 (/etc/wgetrc)
~/.wgetrc와 같은 지시문을 쓰지만, 시스템 설정 파일에 넣는 방식입니다. GNU 문서에서는 이를 전역 시작 파일로 설명하며, 정확한 경로는 설치 접두사에 따라 달라집니다. 일반적인 위치는 다음과 같습니다.
/etc/wgetrc(대부분의 Linux 패키지 관리자)/usr/local/etc/wgetrc(일부 Homebrew 빌드)wget --version출력의Wgetrc:항목에 표시되는 경로
공용 서버, Docker 컨테이너, 또는 모든 사용자가 같은 프록시를 써야 하는 환경에서 유용합니다.
방법 4: 환경 변수 (http_proxy / https_proxy)
export http_proxy=http://HOST:PORT/
export https_proxy=http://HOST:PORT/
export no_proxy=localhost,127.0.0.1,.internal.company.com
이 설정은 Wget뿐 아니라 현재 셸 세션 전체에 적용됩니다. curl 같은 도구도 함께 영향을 받습니다.
중요 경고: Wget은 소문자 환경 변수만 읽습니다. HTTP_PROXY처럼 대문자로 쓰면 조용히 무시됩니다. 오류도 없고, 경고도 없고, 아무 메시지도 없습니다. 정확한 터미널 출력은 아래 함정 섹션에서 보여드리겠지만, 이건 지금 바로 기억해 둘 가치가 있습니다.
프록시 설정 우선순위: 여러 방법이 동시에 있을 때 무엇이 이기나요?
환경 변수에도 프록시가 있고 .wgetrc에도 있고 명령줄에도 있다면, 실제로는 무엇이 적용될까요? 이 부분은 어디에도 명확히 안 나와 있어서 직접 테스트했습니다.
아래는 테스트와 문서 기준 우선순위입니다.
| 우선순위 | 방법 | 적용 범위 | 덮어쓰는 대상 |
|---|---|---|---|
| 1 (최상위) | -e CLI 옵션 | 단일 명령 | 전부 |
| 2 | ~/.wgetrc | 현재 사용자 | 시스템 설정 + 환경 변수 |
| 3 | /etc/wgetrc | 시스템 전체 | 환경 변수만 |
| 4 (최하위) | http_proxy / https_proxy 환경 변수 | 셸 세션 | 없음 |
각 레벨마다 서로 다른 프록시를 넣고 Wget 1.25.0에서 확인했습니다. 환경 변수는 3128번 포트, 설정 파일은 3129번 포트, CLI는 3130번 포트를 가리키도록 했을 때:
- 설정 파일이 환경 변수를 이김: Wget은 3128이 아니라 3129로 연결했습니다.
- CLI가 설정 파일을 이김: Wget은 3129와 3128을 무시하고 3130으로 연결했습니다.
예외적으로 모든 프록시 설정을 무시하려면 --no-proxy를 쓰면 됩니다. 어디에 설정됐든 전부 우회합니다.
wget --no-proxy https://internal-server.company.com/report.pdf
실무 예시: 시스템 관리자가 /etc/wgetrc에 프록시를 설정했지만, 내부 서버에는 직접 접속해야 하는 경우입니다. 시스템 설정을 건드리는 대신 해당 명령에만 --no-proxy를 사용하세요.
인증이 필요한 프록시와 함께 Wget 사용하는 방법
대부분의 상용 또는 가정용 프록시는 사용자 이름과 비밀번호가 필요합니다. Wget은 두 가지 방식으로 이를 지원하며, 둘 다 프록시 자격 증명에 HTTP Basic 인증을 사용합니다.
프록시 URL에 자격 증명을 직접 넣기
wget -e use_proxy=on \
-e http_proxy=http://USERNAME:PASSWORD@proxy.company.com:8080/ \
http://example.com/file.zip
이 방식은 .wgetrc에서도 가능합니다.
http_proxy = http://USERNAME:PASSWORD@proxy.company.com:8080/
https_proxy = http://USERNAME:PASSWORD@proxy.company.com:8080/
--proxy-user 및 --proxy-password 옵션 사용하기
wget --proxy-user=USERNAME --proxy-password=PASSWORD \
-e use_proxy=on \
-e http_proxy=http://proxy.company.com:8080/ \
http://example.com/file.zip
이 옵션들은 프록시 URL 안에 들어 있는 user:pass@ 정보를 덮어씁니다.
자격 증명을 안전하게 보관하는 방법
두 방식 모두 자격 증명이 노출될 수 있습니다. GNU 문서도 명령줄의 비밀번호는 ps나 프로세스 목록 도구로 보일 수 있다고 경고합니다. 대응 방법은 다음과 같습니다.
- 개인용 머신: 자격 증명을
~/.wgetrc에 저장하고 파일 권한을 잠그세요:chmod 600 ~/.wgetrc - CI/CD 파이프라인: GitHub Actions 암호화 비밀값 또는 플랫폼의 동등한 기능을 사용하세요. YAML에 직접 적지 말고, 단계 정의에서 소문자 환경 변수로 넘기세요.
- Docker 빌드: 비밀값에
ARG나ENV를 사용하지 마세요. Docker 문서도 빌드 인자가 최종 이미지에 남을 수 있다고 명시합니다. 대신 BuildKit 비밀 마운트를 사용하세요. - 버전 관리: 자격 증명이 들어 있는
.wgetrc를 절대 커밋하지 마세요..gitignore에 추가하세요.
GitHub Actions에서 특히 주의할 점이 하나 있습니다. 비밀 이름은 관례상 대문자로 저장되지만, Wget에 노출할 때는 반드시 소문자 환경 변수(HTTP_PROXY가 아니라 http_proxy)를 써야 합니다.
Windows와 기업 방화벽 뒤에서 Wget 프록시를 사용하는 방법
이 주제의 글 대부분은 "Chocolatey로 설치하세요"에서 끝납니다. 하지만 Windows를 쓰거나 기업 프록시 뒤에 있다면, 문제는 그때부터 시작됩니다.
Windows에서 .wgetrc를 찾는 위치
GNU 문서에 따르면 Wget은 WGETRC 환경 변수가 다른 곳을 가리키지 않는 한 $HOME/.wgetrc를 읽습니다. Windows에서는 $HOME이 %USERPROFILE%(예: C:\Users\alice)로 매핑될 수도 있고 아닐 수도 있습니다. Chocolatey 빌드인지, MSYS2 빌드인지, Git Bash인지, 독립 실행형 바이너리인지에 따라 달라집니다.
추천하는 방법은 추측하지 말고 --config 옵션으로 명확하게 지정하는 것입니다.
wget --config=C:\Users\alice\wgetrc https://example.com/file.zip
특정 위치에서 설정 파일을 읽는지 테스트하려면, 일부러 잘못된 프록시를 가리키는 테스트 파일을 만들어 보세요.
; C:\Users\alice\wget-test.rc
use_proxy = on
http_proxy = http://127.0.0.1:3128/
그다음 실행합니다.
wget --config=C:\Users\alice\wget-test.rc --spider http://example.com/
Wget이 127.0.0.1:3128로 접속을 시도하면 그 파일을 읽은 것입니다.
Windows에서 프록시 환경 변수 설정하기
CMD(현재 세션만):
set http_proxy=http://HOST:PORT/
set https_proxy=http://HOST:PORT/
wget http://example.com/
PowerShell(현재 세션만):
$env:http_proxy = "http://HOST:PORT/"
$env:https_proxy = "http://HOST:PORT/"
wget http://example.com/
영구 설정(재부팅 후에도 유지):
setx http_proxy http://HOST:PORT/
setx https_proxy http://HOST:PORT/
setx를 사용한 뒤에는 새 터미널 창을 열어야 합니다. 현재 세션에는 변경 사항이 반영되지 않습니다.
기업 프록시에서 자주 겪는 함정: PAC 파일, NTLM 인증, 프록시 주소 찾기
기업 환경 사용자들이 공통적으로 막히는 세 가지가 있습니다.
PAC 파일: 많은 기업은 PAC(Proxy Auto-Configuration) 파일을 사용합니다. 이는 어떤 URL에 어떤 프록시를 써야 하는지를 알려주는 JavaScript 기반 스크립트입니다. Wget에는 JavaScript 해석기가 없기 때문에 PAC 파일을 읽을 수 없습니다. curl 문서도 같은 점을 설명합니다. 해결 방법은 PAC 파일을 열어보거나 IT 부서에 문의해서, 대상 도메인에 대한 PROXY host:port 값을 찾아 Wget에 정적 주소로 넣는 것입니다.
NTLM 인증: Wget의 프록시 인증은 Basic 인증만 구현되어 있습니다. 회사 프록시가 NTLM을 요구하고 407 Proxy Authentication Required 오류가 난다면, --proxy-user 문법을 이것저것 바꾸며 시간을 낭비하지 마세요. Cntlm을 설치하세요. 이는 NTLM/NTLMv2 인증을 처리하고 Wget에는 Basic 인증 인터페이스를 제공하는 로컬 릴레이입니다. Cntlm은 아직도 유지관리 중이며(2025년 10월 마지막 업데이트, 주당 약 395회 다운로드), 여전히 실무에서 유용합니다.
기업 프록시 사용자용 결정 트리:
set http_proxy=http://YOUR_PROXY:PORT/를 실행하고 Wget을 돌려봅니다.407오류가 나고 회사가 NTLM을 사용한다면 → Cntlm을 설치하고 도메인 계정으로 설정한 뒤, Wget을 Cntlm의 로컬 포트(보통http://127.0.0.1:3128/)로 향하게 합니다.- 회사가 PAC 파일을 쓴다면 → PAC 파일에서 실제
PROXY host:port를 추출하거나 IT에 정적 프록시 주소를 요청합니다.
일반적인 기업 프록시 포트는 3128(Squid 계열), 8080(일반 HTTP 프록시), 8888(Fiddler/Charles 같은 디버깅 프록시)입니다. 다만 이는 관례일 뿐, 보장은 아닙니다.
프록시와 함께 Wget을 사용할 때 흔한 함정들(실제 오류 출력 포함)
이제 제목에서 약속한 핵심을 보여드리겠습니다. 아래 출력은 모두 2026-06-01 기준, Wget 1.25.0(macOS, Homebrew)에서 재현했습니다.
함정 1: http:// 접두사 누락
일부 오래된 가이드는 이 경우 항상 실패한다고 말합니다. 하지만 Wget 1.25.0에서는 http_proxy=127.0.0.1:3128로 설정해도 실제로 동작합니다. Wget이 조용히 http://를 앞에 붙이기 때문입니다.
Prepended http:// to '127.0.0.1:3128'
Spider mode enabled. Check if remote file exists.
--2026-06-01 10:38:15-- http://example.com/
Connecting to 127.0.0.1:3128... failed: Operation not permitted.
실제로는 올바른 프록시에 연결을 시도했습니다. 그래도 저는 항상 http:// 접두사와 끝의 슬래시(/)를 넣는 것을 권장합니다. Wget 버전마다 애매함을 줄이고, 자격 증명 표기(http://user:pass@host:port/)도 헷갈리지 않게 해줍니다.
함정 2: use_proxy=yes와 use_proxy=on
제 테스트에서 Wget 1.25.0은 yes와 on 둘 다 동작했습니다. 하지만 잘못된 값은 분명한 오류를 냅니다.
wget: use_proxy: Invalid boolean 'true'; use `on' or `off'.
가장 넓은 호환성을 위해 on을 사용하세요. 매뉴얼에 나온 불리언 형식과 Wget 자체 오류 힌트 모두 이를 뒷받침합니다.
함정 3: 대문자 HTTP_PROXY가 조용히 무시됨
이건 가장 짜증나는 함정입니다. 에러가 전혀 없기 때문입니다. Wget은 마치 프록시를 설정하지 않은 것처럼 직접 연결해 버립니다.
대문자 사용(문제 있음 — 프록시 미사용):
HTTP_PROXY=http://127.0.0.1:3128/ wget --no-config --spider http://example.com/
Spider mode enabled. Check if remote file exists.
--2026-06-01 10:40:06-- http://example.com/
Resolving example.com (example.com)... 198.18.58.61
Connecting to example.com (example.com)|198.18.58.61|:80... connected.
HTTP request sent, awaiting response... 200 OK
소문자 사용(정상 — 프록시 시도):
http_proxy=http://127.0.0.1:3128/ wget --no-config --spider http://example.com/
Spider mode enabled. Check if remote file exists.
--2026-06-01 10:40:16-- http://example.com/
Connecting to 127.0.0.1:3128... failed: Connection refused.
차이가 보이시나요? 대문자 버전은 example.com에 직접 연결했고, 소문자 버전은 프록시를 시도했습니다. 어느 쪽이든 경고는 없습니다. curl에도 비슷한 특성이 있는데, 대부분의 프록시 변수는 대문자를 허용하지만 보안상 HTTP_PROXY는 명시적으로 거부합니다.
해결책: 항상 소문자 http_proxy와 https_proxy를 사용하세요.
함정 4: 오래된 .wgetrc 때문에 "Connection Refused" 발생
예전 프록시 주소가 설정 파일에 남아 있으면(본인, 시스템 관리자, 또는 Docker 이미지에 의해) 이런 메시지가 나옵니다.
Spider mode enabled. Check if remote file exists.
--2026-06-01 10:39:10-- http://example.com/
Connecting to 127.0.0.1:3128... failed: Connection refused.
오류는 대상 사이트가 아니라 오래된 프록시 IP를 가리킵니다. 우선순위 순서대로 확인하세요.
- 명령에
-e옵션이나 셸 별칭이 있는지 확인 ~/.wgetrc(또는WGETRC가 지정한 파일) 확인- 시스템 설정 확인(
wget --version에 나오는 경로) - 환경 변수 확인:
env | grep -i proxy
디버깅할 때는 --no-config가 큰 도움이 됩니다. 모든 설정 파일을 건너뛰게 해줍니다.
wget --no-config --spider http://example.com/
이 명령이 동작한다면 문제는 설정 파일 쪽에 있는 것입니다.
함정 5: HTTPS 프록시 문법 혼동
많이 헷갈리는 부분입니다. https_proxy를 설정할 때 프록시 URL 자체는 보통 https://가 아니라 http://입니다. Wget이 프록시를 통해 HTTP CONNECT 요청을 보내 암호화된 HTTPS 세션용 터널을 만들기 때문입니다.
정상 예시:
https_proxy=http://proxy.company.com:8080/
wget https://example.com/
Wget은 프록시에 CONNECT example.com:443 HTTP/1.1을 보낸 뒤, 그 위로 HTTPS를 터널링합니다.
잘못된 예시(HTTP 대상 URL에 HTTPS 프록시 엔드포인트 사용):
http_proxy=https://127.0.0.1:18082/
wget http://example.com/
Error in proxy URL https://127.0.0.1:18082/: Must be HTTP.
Wget 1.25.0은 HTTP 대상 URL에 대해 프록시 URL로 https://를 아예 거부합니다. 조직에서 HTTPS 프록시 엔드포인트를 명시적으로 문서화했고, 본인 Wget 빌드에서 이미 테스트한 경우가 아니라면 https_proxy=http://HOST:PORT/를 사용하세요.
Wget 프록시 명령 치트시트(북마크용 빠른 참고표)
이 표를 북마크해 두세요. 프록시 관련 Wget 옵션과 설정 지시문을 한눈에 정리했습니다.
| 옵션 / 지시문 | 사용 위치 | 예시 | 참고 |
|---|---|---|---|
-e use_proxy=on | CLI | -e use_proxy=on | on이 가장 안전합니다. 일부 빌드는 yes도 허용 |
-e http_proxy= | CLI | -e http_proxy=http://proxy:8080/ | http:// 접두사와 끝의 /를 포함 |
-e https_proxy= | CLI | -e https_proxy=http://proxy:8080/ | HTTPS 대상이어도 프록시 URL은 보통 http:// |
--proxy-user | CLI | --proxy-user=admin | 내장 user:pass@ 정보를 덮어씀 |
--proxy-password | CLI | --proxy-password=secret | ps에 보일 수 있으므로 공유 시스템에서는 피할 것 |
--no-proxy | CLI | --no-proxy | 모든 출처의 프록시 설정을 전부 무시 |
--no-config | CLI | --no-config | 모든 설정 파일을 건너뜀 — 디버깅에 유용 |
--config=FILE | CLI | --config=/tmp/wgetrc | 결정적인 설정 경로 — Windows와 CI에 특히 좋음 |
http_proxy | .wgetrc / env | http_proxy = http://proxy:8080/ | 설정 파일은 = 양쪽에 공백, 환경 변수는 소문자 |
https_proxy | .wgetrc / env | https_proxy = http://proxy:8080/ | http_proxy와 같은 형식 |
ftp_proxy | .wgetrc / env | ftp_proxy = http://proxy:8080/ | FTP 다운로드용 |
no_proxy | .wgetrc / env | no_proxy = localhost,127.0.0.1,.corp | 쉼표로 구분된 도메인 목록 |
proxy_user | .wgetrc | proxy_user = admin | --proxy-user와 동일 |
proxy_password | .wgetrc | proxy_password = secret | 파일은 chmod 600으로 보호 |
Wget + 프록시가 적절하지 않은 경우와 대신 쓸 도구
이렇게 프록시 설정을 다 하고 나면, 이런 생각이 들 수 있습니다. 사실 굳이 Wget을 쓸 필요가 없는 경우도 많다는 점입니다.
"wget proxy"를 검색하는 많은 사람들은 사실 단일 파일을 내려받으려는 게 아닙니다. 상품 가격, 연락처 목록, 부동산 매물 같은 구조화된 데이터를 웹사이트에서 수집하려는 경우가 많고, 익숙한 명령줄 도구라서 Wget을 선택했을 뿐입니다. 문제는 Wget이 원시 HTML만 준다는 점입니다. 그다음엔 직접 파싱하고, 정리하고, 구조화해야 합니다. 차단을 피하려고 회전 프록시까지 쓰고 있다면, 이제는 프록시 목록, 다운로드 스크립트, 파서, 내보내기 파이프라인까지 모두 관리해야 합니다.
| 목표 | 가장 적합한 도구 | 이유 |
|---|---|---|
| 프록시를 통해 단일 파일 다운로드 | 프록시 옵션이 있는 wget | 간단하고 한 줄이면 끝 |
| 프록시를 통해 사이트나 디렉터리 전체 미러링 | wget --recursive + 프록시 설정 | Wget의 재귀 다운로드가 강점 |
| 구조화된 데이터(표, 목록, 연락처) 수집 | Thunderbit | Wget은 원시 HTML만 줍니다. 여전히 파싱이 필요합니다. Thunderbit의 AI는 페이지를 읽고, 코딩 없이 Excel, Google Sheets, Airtable, Notion으로 구조화된 데이터를 내보냅니다. 클라우드 스크래핑이 IP 회전과 봇 차단 대응까지 처리하므로 프록시 설정 자체를 건너뛸 수 있습니다. |
| 프록시를 통한 REST API 호출 | curl | 더 나은 헤더 제어, 네이티브 JSON 지원, SOCKS5 지원 |
| 정기적인 데이터 수집 | Thunderbit Scheduled Scraper 또는 cron + wget | Thunderbit은 페이지 구조가 바뀌어도 적응하지만, cron + wget 스크립트는 조용히 깨질 수 있음 |
Wget은 파일 다운로드에 아주 강합니다. 하지만 "프록시 설정 → IP 회전 → HTML 다운로드 → 파서 작성 → 스프레드시트로 내보내기" 같은 흐름은, 실제로 필요한 게 데이터 표 하나일 때 너무 많은 구성 요소를 관리하게 됩니다. 이런 상황이라면 Chrome 확장 프로그램을 이용해 두 번의 클릭으로 전체 과정을 처리할 수 있습니다. 이 접근 방식에 대해 더 알고 싶다면 AI 웹 스크래핑과 코딩 없이 웹 스크래핑하기 가이드를 참고하세요.
하지만 목표가 "기업 프록시를 통해 ZIP 파일 하나를 다운로드하는 것"이라면, Wget은 여전히 올바른 도구입니다. 이제 그 설정 방법도 제대로 아시게 됐습니다.
핵심 정리
짧게 정리하면 다음과 같습니다.
- 네 가지 방법과 명확한 우선순위: CLI 옵션이 사용자 설정을 덮어쓰고, 사용자 설정은 시스템 설정을 덮어쓰며, 시스템 설정은 환경 변수를 덮어씁니다.
--no-proxy는 모든 것을 무시합니다. - 환경 변수는 반드시 소문자를 사용하세요(
HTTP_PROXY가 아니라http_proxy). 대문자는 조용히 무시됩니다. - 프록시 URL에는 항상
http://를 넣으세요.https_proxy를 쓸 때도 마찬가지입니다. 프록시 엔드포인트는 HTTP이고, CONNECT로 HTTPS를 터널링합니다. - 불리언 값은
on을 쓰세요..wgetrc와-e옵션 모두에서 가장 안전합니다. - Windows 사용자: 설정 파일 혼동을 피하려면
--config=C:\path\to\wgetrc를 사용하세요. 세션 변수는set(CMD) 또는$env:(PowerShell)로 설정합니다. - 기업 프록시 사용자: Wget은 PAC 파일을 읽지 못하고 NTLM 인증도 네이티브로 지원하지 않습니다. 필요하다면 Cntlm을 로컬 릴레이로 사용하세요.
- 위 치트시트를 북마크해 두세요. 옵션 이름이 헷갈릴 때마다 이 글을 다시 읽는 수고를 덜어줍니다.
실제 목적이 구조화된 데이터 추출이라면 Thunderbit나 curl이 더 적합할 수 있습니다. 최고의 디버깅 세션은 애초에 시작하지 않아도 되는 세션입니다.
자주 묻는 질문
1. Wget은 SOCKS5 프록시를 지원하나요?
아니요. GNU Wget 1.x는 HTTP, HTTPS, FTP 프록시만 지원합니다. Wget2 프로젝트에는 SOCKS5 기능 요청이 있지만, 표준 문서화된 옵션은 아닙니다. SOCKS5가 필요하다면 curl의 socks5:// 또는 socks5h:// 스킴을 사용하거나, proxychains4로 Wget을 감싸 SOCKS 라우팅을 강제하세요.
2. 왜 대문자 HTTP_PROXY를 쓰면 프록시 설정이 무시되나요?
Wget은 소문자 환경 변수 이름만 읽습니다(http_proxy, https_proxy, ftp_proxy, no_proxy). HTTP_PROXY 같은 대문자 버전은 조용히 무시되며, 오류나 경고도 없습니다. 아무 문제 없어 보이는데 실제론 잘못된 경우가 많아 가장 흔하고도 답답한 문제 중 하나입니다. 항상 소문자를 사용하세요.
3. 특정 도메인만 프록시를 우회하려면 어떻게 하나요?
환경 변수 또는 .wgetrc에서 no_proxy 지시문을 사용하면 됩니다.
export no_proxy=localhost,127.0.0.1,.mycompany.com
또는 ~/.wgetrc에 다음처럼 적습니다.
no_proxy = localhost,127.0.0.1,.mycompany.com
도메인은 쉼표로 구분합니다. 앞에 점(.mycompany.com)을 붙이면 모든 하위 도메인에 매칭됩니다.
4. 회전 프록시와 함께 Wget을 사용할 수 있나요?
Wget 자체에는 프록시 회전 기능이 내장되어 있지 않습니다. 두 가지 방법이 있습니다. 하나는 IP를 서버 측에서 회전해 주는 프록시 제공자를 사용해 항상 같은 게이트웨이 주소로 접속하지만 출구 IP가 바뀌게 하는 것, 다른 하나는 프록시 목록에서 무작위로 하나를 골라 매 실행마다 -e http_proxy=...로 넘기는 셸 스크립트를 작성하는 것입니다. 자동 회전, 재시도 로직, 봇 차단 대응처럼 더 복잡한 작업은 보통 전용 스크래핑 도구가 더 적합합니다.
5. Wget에서 http_proxy와 https_proxy의 차이는 무엇인가요?
대상 URL이 http://일 때는 http_proxy가 사용됩니다. 대상 URL이 https://일 때는 https_proxy가 사용됩니다. 두 경우 모두 프록시 URL 자체는 보통 http:// 주소입니다. HTTPS 대상의 경우 Wget은 프록시를 통해 HTTP CONNECT 요청을 보내 터널을 만들고, 실제 HTTPS 암호화는 Wget과 대상 서버 사이에서 종단 간으로 이루어집니다. 프록시는 CONNECT 요청에 포함된 호스트 이름은 볼 수 있지만, 암호화된 트래픽 내용은 읽을 수 없습니다.
AI 웹 스크래핑을 위해 Thunderbit 사용해 보기 Get Started Free
더 알아보기
