cURL와 Postman에서 레지덴셜 프록시 설정하기

두 도구 모두 프록시를 잘 처리하지만, 둘 다 조용히 문제를 일으키는 설정이 하나씩 있다. 각각의 정상 작동 구성과 나머지를 디버깅하는 방법을 소개한다.

프록시가 애플리케이션 코드 근처에 가기 전에, 검사할 수 있는 도구에서 작동하는지 증명해 보는 것이 좋습니다. cURL과 Postman은 대부분의 개발자가 선택하는 두 가지 도구이며, 둘 다 설정만 제대로 하면 프록시를 잘 처리하지만, 각각 놓치면 혼란스러운 동작을 일으키는 설정이 하나씩 있습니다. 여기 두 도구 모두에 대한 작동하는 설정, 중요한 디버깅 플래그, 그리고 함정을 소개합니다.

연결 세부 정보는 어디서나 동일합니다: 호스트 p.shifter.io, 포트 443, 그리고 타겟팅 정보를 담은 사용자 이름. 형식에 대한 참조는 레지덴셜 프록시 연결 방법에 있습니다.

cURL

전체 설정은 플래그 하나로 끝납니다.

curl -x customer-USERNAME:PASSWORD@p.shifter.io:443 https://ipinfo.io/json

-x와 --proxy는 같은 것입니다. 이것을 두 번 실행하면 주소가 달라져야 하며, 이는 한 번에 자격 증명과 로테이션을 모두 확인해 줍니다.

타겟팅은 사용자 이름에 들어가므로, 명령어의 다른 부분은 전혀 바뀌지 않습니다:

# 독일 출구
curl -x customer-USERNAME-country-de:PASSWORD@p.shifter.io:443 https://ipinfo.io/json

# 고정 세션, 10분
curl -x customer-USERNAME-country-de-sid-abc123-ttl-600:PASSWORD@p.shifter.io:443 https://ipinfo.io/json

자격 증명을 셸 히스토리에 남기지 않기

URL에 비밀번호를 넣으면 히스토리와 프로세스 목록에 남게 됩니다. 더 나은 두 가지 방법은 다음과 같습니다:

# 자격 증명을 별도로 전달
curl -x p.shifter.io:443 -U customer-USERNAME-country-de:PASSWORD https://ipinfo.io/json

# 또는 환경 변수에서 가져오기
export PROXY_USER="customer-USERNAME-country-de"
export PROXY_PASS="..."
curl -x p.shifter.io:443 -U "$PROXY_USER:$PROXY_PASS" https://ipinfo.io/json

-U는 프록시 자격 증명이고 -u는 대상 사이트에 대한 자격 증명이라는 점에 유의하세요. 둘을 혼동하는 것이 완전히 멀쩡한 비밀번호로 407 오류가 발생하는 흔한 원인입니다.

알아둘 만한 디버깅 플래그

# 프록시 핸드셰이크와 인증 성공 여부 확인
curl -v -x customer-USERNAME:PASSWORD@p.shifter.io:443 https://ipinfo.io/json

# 타이밍 분석: 지연이 실제로 어디서 발생하는지
curl -o /dev/null -s -w "connect: %{time_connect}s  ttfb: %{time_starttransfer}s  total: %{time_total}s\n" \
  -x customer-USERNAME:PASSWORD@p.shifter.io:443 https://example.com

두 번째 명령은 느린 프록시 연결과 느린 타겟을 구분하는 가장 빠른 방법이며, 이는 요청이 시간 초과되는 이유에서 다루는 첫 번째 갈림길이자 지연 시간 줄이기의 출발점입니다.

cURL에서의 SOCKS5, 그리고 함정

HTTP 대신 SOCKS5를 사용한다면, 스킴이 보이는 것보다 훨씬 중요합니다:

# DNS 유출: 본인 머신이 호스트명을 확인함
curl -x socks5://customer-USERNAME:PASSWORD@p.shifter.io:443 https://example.com

# 올바름: 프록시가 확인함
curl -x socks5h://customer-USERNAME:PASSWORD@p.shifter.io:443 https://example.com

h 하나가 전체 차이를 만들며, 이를 틀리면 DNS 쿼리가 본인 위치에서 나가게 되어 지역적으로 잘못된 결과가 반환될 수 있습니다. 자세한 내용은 DNS 유출 방지하기에 있습니다.

절대 배포하면 안 되는 플래그 하나

--proxy-insecure는 프록시 구간의 인증서 검증을 비활성화합니다. TLS 오류가 인증서 문제인지 아닌지 확인하는 데 가끔 유용하지만, 영구적인 설정에는 절대 포함되어서는 안 됩니다.

Postman

Postman의 프록시 지원은 견고하지만, 요청별이 아니라 애플리케이션 설정에서 구성되며, 이는 요청 자체에서 설정할 것이라 예상하는 사람들에게 놀라움을 줍니다.

설정하기

Settings를 연 다음 Proxy 탭으로 이동합니다. 시스템 프록시 옵션을 끄고 사용자 지정 프록시 구성을 활성화합니다. 프록시 서버를 p.shifter.io로, 포트를 443으로 설정하고, HTTP와 HTTPS 둘 다 체크한 다음, 프록시 인증을 활성화하고 타겟팅 플래그를 포함한 사용자 이름과 비밀번호를 입력합니다.

이 구성은 Postman 앱 전체에 적용되는 것이므로 유념해야 합니다. 한번 설정하면 끌 때까지 모든 컬렉션의 모든 요청이 프록시를 거치게 됩니다. 내부 서비스도 함께 테스트하고 있다면, 그것들도 라우팅되므로 보통 원하는 상황이 아닙니다.

문제를 일으키는 설정

Settings 다음 General에는 SSL certificate verification이 있습니다. 프록시를 통해 인증서 오류가 발생해 이를 껐다면, 해당 프록시 요청뿐 아니라 Postman이 하는 모든 작업에 대해 검증을 비활성화했다는 점을 기억하세요. 이후에는 다시 켜두세요. 인증서 오류가 발생하고 있다면 그 자체가 끄기보다는 이해할 가치가 있는 문제입니다.

다시 입력하지 않고 타겟팅 전환하기

타겟팅이 사용자 이름에 들어 있으므로, 국가를 바꾸는 것은 필드 하나를 편집하는 일입니다. Postman 변수를 사용하면 이 작업이 덜 번거로워집니다. 프록시 사용자 이름을 위한 변수를 가진 환경을 정의한 다음, 환경을 전환하여 시장을 바꾸면 됩니다. 프록시 설정 대화상자는 변수 문법을 허용하므로, customer-USERNAME-country-{{market}}으로 설정하면 매번 설정을 열지 않고 활성 환경을 바꾸는 것만으로 국가를 변경할 수 있습니다.

작동 여부 확인하기

https://ipinfo.io/json에 GET을 보내고 응답을 읽습니다. 본인 것이 아니라 타겟팅한 국가의 주소가 나와야 합니다. 사용자 이름에 sid 없이 두 번 보내면 주소가 바뀌어야 합니다.

주소가 본인 것과 같다면 프록시가 전혀 적용되지 않고 있는 것입니다. 사용자 지정 프록시 구성이 실제로 활성화되어 있는지, HTTP와 HTTPS 둘 다 체크되어 있는지 확인하세요.

Collection Runner

약간 더 큰 볼륨으로 테스트하려면 Collection Runner가 동일한 프록시 구성을 통해 컬렉션을 반복 실행합니다. 전속력으로 실행하기보다는 반복 사이에 지연을 추가하세요. 동일한 요청이 몰아치면 속도 제한과 스로틀링에 따르면 타겟이 응답을 멈추게 만드는 가장 빠른 방법이기 때문입니다.

무언가 실패했을 때

네 가지 응답이 거의 모든 것을 다루며, 각각은 구체적인 곳을 가리킵니다.

407은 자격 증명이 거부되었거나, 사용자 이름의 플래그가 잘못되었음을 의미합니다. 인식되지 않는 값 하나가 전체 사용자 이름을 파싱 불가능하게 만들기 때문입니다. 플래그 없이 순수한 사용자 이름을 먼저 테스트하세요. 그것이 작동하면 하나씩 다시 추가하세요. 전체 경로는 407 오류 해결하기에 있습니다.

502는 자격 증명은 괜찮았지만 그 순간 필터에 맞는 것이 아무것도 없었음을 의미합니다. 필터를 넓히거나, 도시에서 국가로 낮추세요.

509는 초과 사용이 비활성화된 상태에서 요금제 대역폭이 소진되었음을 의미합니다.

연결 거부 또는 멈춤은 게이트웨이에 아예 도달하지 못했음을 의미합니다. 프록시 문제라고 가정하기 전에 nc -vz p.shifter.io 443을 확인하고, 레거시 호스트를 가리키고 있지 않은지 확인하세요.

더 넓은 색인은 일반적인 레지덴셜 프록시 오류에 있습니다.

도구에서 코드로 넘어가기

두 도구가 모두 작동하면, 동일한 네 가지 값이 무엇을 만들든 그대로 전달되며, 클라이언트 측 패턴은 Python으로 레지덴셜 프록시 사용하기에 있습니다. 전달되지 않는 것 하나: 애플리케이션 코드에서는 연결 재사용으로 인해 기존 터널을 통해 전송된 요청이 동일한 출구 주소를 유지하며, 이는 로테이션이 실패하는 것처럼 보입니다. 이 놀라운 점은 IP가 로테이션되지 않음에서 다룹니다.

결론

cURL에서는 전체가 -x이고, 자격 증명을 URL 밖에 두려면 -U, 핸드셰이크를 보려면 -v, 느림이 프록시인지 타겟인지 알아내려면 -w를 사용합니다. SOCKS5를 사용한다면 DNS가 프록시에서 확인되도록 socks5h를 사용하세요. Postman에서는 구성이 요청이 아니라 애플리케이션 설정에 있으므로 비활성화할 때까지 전역적으로 적용되며, SSL 검증 토글은 요청별이 아니라 앱 전체에 적용됩니다. 둘 다에서 타겟팅은 사용자 이름에 있으므로, 국가를 바꾸는 것이 호스트나 포트나 다른 어떤 것도 바꾸는 일이 아닙니다. 코드에 넣기 전에 검사할 수 있는 도구에서 작동을 증명하고, 상태 코드로 실패를 읽으세요.

이 모든 것 뒤에 있는 게이트웨이는 레지덴셜 프록시로, 모든 국가와 세션 모드에 걸쳐 하나의 호스트와 하나의 자격 증명 쌍을 사용하며, GB당 요금이 청구되므로 테스트는 사용한 대역폭만큼만 비용이 듭니다.