흔히 발생하는 레지덴셜 프록시 오류와 해결 방법

프록시 문제는 겪고 있는 동안에는 다양하게 느껴지지만 실제로는 상당히 반복적입니다. 잘못되는 거의 모든 것은 아홉 가지 패턴 중 하나에 해당하며, 대부분의 경우 응답 자체가 어떤 패턴인지 알려줍니다. 이 글은 색인입니다: 증상을 찾고, 가능성 있는 원인과 즉각적인 해결책을 확인한 다음, 더 자세한 내용이 필요할 때 링크를 따라가세요.

빠른 참조 표

증상	대체로 의미하는 것	가장 먼저 할 일	재시도?
407 Proxy Authentication Required	잘못된 인증 정보 또는 사용자 이름 내 형식이 잘못된 플래그	플래그 없이 기본 사용자 이름으로 테스트	절대 안 됨
502 Bad Gateway	해당 시점에 필터와 일치하는 주소가 없음	필터 범위를 넓히기	필터를 넓힌 후에만
509 Bandwidth Limit Exceeded	플랜 할당량 소진, 초과 사용 비활성화 상태	잔액과 플랜 확인	안 됨
연결 거부 또는 멈춤	게이트웨이에 아예 도달하지 못함	nc -vz p.shifter.io 443	안 됨, 먼저 연결 문제 해결
타임아웃	대상 서버의 지연, 지나치게 좁은 필터, 또는 자체 동시성 문제	연결 시간과 읽기 시간을 분리	백오프를 적용하여 재시도
403 또는 챌린지 페이지	프록시가 아니라 대상 서버가 신원을 거부함	세션 폐기, 헤더 확인	같은 세션에서는 안 됨
429 Too Many Requests	대상 서버가 요청 속도를 제한하고 있음	Retry-After를 준수한 뒤 속도를 늦춤	대기 후 재시도
200이지만 내용이 잘못되었거나 비어 있음	소프트 차단, 또는 잘못된 로케일	본문 검증, 지오 신호 확인	원인이 해결될 때까지 안 됨
매 요청마다 같은 IP	거의 항상 클라이언트 측 연결 재사용 문제	별도 프로세스로 테스트	해당 없음

407: 인증 거부

게이트웨이가 인증 정보를 거부했다는 것은 트래픽이 게이트웨이까지 도달했고 연결 자체는 문제없다는 뜻입니다.

거의 모든 경우가 세 가지 원인 중 하나입니다: 인증 정보의 오타, 확장된 사용자 이름 내 형식이 잘못된 플래그, 또는 패널에서 비밀번호가 변경되었는데 오래된 사본이 어딘가에 여전히 배포되어 있는 경우입니다. 두 번째가 가장 알아채기 어려운데, country-gb 대신 country-uk처럼 인식되지 않는 값이 들어가면 사용자 이름 전체를 파싱할 수 없게 되어 타겟팅 오류가 아니라 인증 실패로 보고되기 때문입니다.

진단 방법은 항상 동일합니다: 모든 플래그를 제거하고 먼저 기본 사용자 이름으로 테스트하세요. 그것이 성공하면 문제는 플래그에 있는 것이므로 하나씩 다시 추가합니다. 실패한다면 패널에서 비밀번호를 다시 복사하세요. 자세한 내용은 407 및 인증 정보 오류 해결하기에 있습니다.

407은 절대 재시도하지 마세요. 이는 종결된 상태이며, 이에 대한 재시도 루프는 대역폭을 낭비하면서 외부에서는 credential stuffing처럼 보이게 만듭니다.

502: 필터와 일치하는 것이 없음

인증 정보는 승인되었지만 요청한 조합에 사용 가능한 주소가 없었던 경우입니다. 이는 장애가 아니라 타겟팅 문제입니다.

필터가 매우 좁을 때, 즉 작은 도시, 특정 ASN, 혹은 둘의 조합일 때 주로 나타나며, 현지 활동에 따라 가용성이 달라지므로 로컬 풀이 얇은 시간대에 더 자주 발생합니다. 필터 범위를 넓히거나, 도시 단위에서 지역 또는 국가 단위로 낮추거나, 엄격한 매칭을 제거해 게이트웨이가 더 넓은 풀로 대체할 수 있게 하세요. 의도적으로 엄격한 매칭에 의존하고 있다면 이 오류는 시스템이 의도대로 작동하는 것입니다. 배경 지식은 국가별 가용성에 있습니다.

509: 대역폭 소진

플랜 할당량이 소진되었고 초과 사용이 활성화되어 있지 않아 요청이 중단됩니다. 연결이나 설정에는 아무 문제가 없습니다. 초과 사용을 활성화하려면 잔액을 충전하거나 주기가 초기화될 때까지 기다리세요. 이런 일이 정기적으로 발생한다면 플랜 용량이 부족한 것이며, 이는 월간 대역폭 산정하기에서 다루는 예측의 문제입니다.

연결 거부, 혹은 영원히 멈춰버리는 요청

게이트웨이와 아예 통신하지 못하고 있는 상태입니다. 흔한 원인 두 가지: p.shifter.io:443 대신 예전 방식의 포트 기반 호스트를 가리키고 있거나, 자체 네트워크가 해당 포트로의 아웃바운드 트래픽을 차단하고 있는 경우입니다.

프록시에 대해 어떤 가정도 하기 전에 먼저 원시 연결성을 테스트하세요:

nc -vz p.shifter.io 443

이것이 실패하면 자체 측의 아웃바운드 또는 방화벽 문제입니다. 성공했는데도 요청이 계속 실패한다면 위에서 다룬 인증 경로 문제로 넘어간 것입니다.

타임아웃

가장 모호한 범주인데, 여러 다른 문제가 같은 증상을 만들어내기 때문입니다. 가장 유용한 단계는 연결 시간과 전체 시간을 분리하는 것으로, 이 둘은 서로 반대 방향을 가리킵니다:

curl -o /dev/null -s -w "connect: %{time_connect}s  total: %{time_total}s\n" \
  -x customer-USERNAME:PASSWORD@p.shifter.io:443 https://example.com

연결이 느리다면 프록시 경로 문제이거나 지나치게 좁은 필터가 주소 선택을 느리게 만드는 것을 가리킵니다. 연결은 빠른데 전체가 느리다면 대상 서버가 느린 것이며, 이는 프록시를 바꾼다고 해결되는 문제가 아닙니다. 또한 타임아웃 설정이 단순히 데이터센터 지연 시간에 맞춰져 있는지도 확인하세요. 레지덴셜 연결은 원래 더 느리기 때문에 2초 타임아웃은 오류가 아닌 이유로 계속 실패할 것입니다. 전체 진단 과정은 요청이 타임아웃되는 이유에, 튜닝 옵션은 지연 시간 줄이기에 있습니다.

403, 캡차, 챌린지 페이지

이것들은 프록시가 아니라 대상 서버에서 오는 것이며, 인증과 연결 모두 정상적으로 작동했다는 뜻입니다. 대상 서버가 요청을 확인하고 거부한 것입니다.

즉각적인 대응은 같은 신원으로 재시도하지 말고 해당 세션을 폐기하고 새로 시작하는 것입니다. 근본적인 대응은 원인을 파악하는 것이며, 가능성이 높은 순서는 속도, 요청 형태, 행동, 주소 품질 순입니다. 속도를 늦추는 것이 다른 무엇보다 많은 문제를 해결하며, 자세한 내용은 속도 제한과 스로틀링에 있습니다. 속도가 문제가 아니라면 다음으로 의심할 것은 헤더와 User Agent가 서로 모순되는지입니다. 복구 절차는 IP가 차단되었을 때 해야 할 일에 있습니다.

429: 너무 많은 요청

대상 서버가 요청 속도를 제한하고 있는 것입니다. 403과 마찬가지로 이는 게이트웨이가 아니라 대상 서버에서 발생하므로, 인증 정보와 연결에는 문제가 없습니다. 이는 한 방문자, 한 세션, 또는 한 네트워크에서 대상 서버가 허용하는 것보다 더 빠르게 요청이 도착하고 있다는 의미입니다.

즉시 재시도하는 대신 속도를 늦추세요. 응답에 Retry-After 헤더가 있다면 대상 서버로 다음 요청을 보내기 전에 최소한 그만큼 기다리세요. 없다면 지수적으로 백오프하고, 해당 대상 서버에 대한 동시성을 낮추며, 한 세션에 더 많이 밀어 넣는 대신 더 많은 세션에 요청을 분산하세요. 429를 같은 속도로 재시도하면 일시적인 제한이 차단으로 바뀝니다. 속도 조절 방법은 위의 403 섹션에 연결된 속도 제한 가이드에 있습니다.

원하는 결과가 아닌 200

가장 비용이 큰 실패 유형인데, 겉으로는 아무 문제도 없어 보이기 때문입니다. 챌린지 페이지, 빈 결과 세트, 잘린 목록, 일반적인 지역 페이지 모두 성공 상태 코드와 함께 도착할 수 있으며, 상태 코드만 집계하는 파이프라인은 이를 데이터로 기록해버립니다.

내용이 없는 게 아니라 잘못된 경우라면 우선 지리적 문제를 의심하세요: exit 국가와 모순되는 Accept-Language 헤더, 혹은 프록시가 아닌 자신의 위치에서 호스트 이름을 해석하는 DNS 누출 모두 잘못된 시장에 대해 그럴듯한 콘텐츠를 만들어냅니다. 지오, 시간대, 로케일 일치시키기와 DNS 누출 방지하기를 참고하세요.

내용이 챌린지 페이지나 껍데기뿐이라면 차단으로 취급하세요. 자세한 내용은 차단되거나 가짜인 콘텐츠 감지하기에 있습니다. 어느 쪽이든 교훈은 같습니다: 응답을 성공으로 집계하기 전에 본문을 검증하지 않으면 모니터링은 아무 의미가 없습니다.

매 요청마다 같은 주소

로테이션이 고장 난 것처럼 보이지만 거의 항상 그렇지 않습니다. 일반적인 원인은 HTTP 클라이언트가 하나의 연결을 재사용하고 있고, exit 주소는 요청마다가 아니라 연결이 수립될 때 선택된다는 것입니다.

먼저 별도 프로세스로 테스트하세요:

for i in 1 2 3; do
  curl -s -x customer-USERNAME:PASSWORD@p.shifter.io:443 http://ip-info.com/json | head -c 60; echo
done

이것이 로테이션되는데 애플리케이션에서는 되지 않는다면 원인은 클라이언트의 커넥션 풀링입니다. 둘 다 로테이션되지 않는다면 사용자 이름에 sticky 세션을 요청하는 sid 플래그가 있는지 확인하고, 보고 있는 주소가 단순히 자신의 주소는 아닌지, 즉 프록시가 아예 적용되지 않고 있는 것은 아닌지 확인하세요. 전체 원인은 IP가 로테이션되지 않음에 있습니다.

브라우저에서: ERR_PROXY_CONNECTION_FAILED와 ERR_TUNNEL_CONNECTION_FAILED

브라우저는 흔히 프록시의 상태 코드를 자체 오류 이름 뒤에 숨깁니다. 두 가지가 대부분의 경우를 다룹니다.

• ERR_PROXY_CONNECTION_FAILED는 브라우저가 프록시에 아예 도달하지 못했음을 의미합니다. 위의 연결 거부와 동일하게 취급하세요. 호스트가 p.shifter.io이고 포트가 443인지 확인한 다음, 네트워크, 방화벽 또는 백신이 연결을 차단하고 있는지 확인하세요.
• ERR_TUNNEL_CONNECTION_FAILED는 브라우저가 프록시에 도달했지만 프록시가 대상 서버로의 터널을 열지 못했음을 의미합니다. 이는 보통 407(인증 정보 또는 잘못된 형식의 플래그)이거나 502(필터와 일치하는 것이 없음)이므로, 407 섹션에서처럼 먼저 기본 사용자 이름을 테스트하세요.

TLS 및 인증서 오류

덜 흔하며 대체로 환경적인 문제입니다. 게이트웨이의 cipher suite를 거부하는 오래된 TLS 라이브러리, 혹은 신뢰 체인을 깨뜨리는 회사 미들박스가 원인입니다. 먼저 클라이언트 라이브러리를 업데이트하세요. 인증서 검증을 비활성화하면 오류가 사라지겠지만, 이는 진단을 확인하는 용도로만 사용해야 하며 실제 배포하는 어떤 것에도 사용해서는 안 됩니다.

일반적인 작업 순서

무언가 고장났는데 어디서부터 시작할지 모를 때: 먼저 원시 연결성을 확인하고, 플래그 없이 기본 인증 정보를 테스트한 다음, 플래그를 하나씩 다시 추가하고, 마지막으로 상태 코드를 그냥 믿기보다 응답이 실제로 요청한 내용이 맞는지 확인하세요. 이 순서는 몇 분 안에 문제 계층을 좁혀주며, 증상이 오류 코드든 미묘하게 잘못된 데이터든 동일하게 적용됩니다.

급성이 아니라 지속적인 문제라면, 수동으로 알아차리기 전에 이런 것들을 잡아내는 계측 방법이 대규모로 프록시 상태 모니터링하기에 있습니다.

자주 묻는 질문

결론

아홉 가지 패턴이 거의 모든 것을 다룹니다. 407은 인증 정보 문제이거나 형식이 잘못된 플래그이며 재시도할 가치가 전혀 없습니다. 502는 장애가 아니라 빈 필터입니다. 509는 대역폭 문제입니다. 연결 거부는 게이트웨이에 아예 도달하지 못했다는 뜻입니다. 타임아웃은 다른 무엇보다 먼저 연결 시간과 전체 시간을 분리해야 합니다. 403이나 챌린지는 대상 서버가 거부하는 것이므로 신원을 바꾼 다음 원인을 파악하세요. 429는 대상 서버가 속도를 늦추라고 요청하는 것이므로 Retry-After를 준수하고 속도를 줄이세요. 잘못된 콘텐츠와 함께 오는 200은 가장 위험한 경우이며, 이것이 본문 검증이 선택이 아닌 이유입니다. 그리고 매 요청마다 같은 주소가 나온다면 거의 항상 자체 클라이언트의 연결 재사용 문제입니다. 연결성부터 바깥쪽으로 작업하고, 상태 코드가 주장하는 것이 아니라 실제로 돌아온 것을 확인하세요.

게이트웨이 자체는 연결하는 방법에, 용어는 용어집에 문서화되어 있으며, 제품은 레지덴셜 프록시이고 GB당 요금제도 있습니다.