프록시 문제는 겪고 있는 동안에는 다양하게 느껴지지만 실제로는 상당히 반복적입니다. 잘못되는 거의 모든 것은 여덟 가지 패턴 중 하나에 해당하며, 대부분의 경우 응답 자체가 어떤 패턴인지 알려줍니다. 이 글은 색인입니다: 증상을 찾고, 가능성 있는 원인과 즉각적인 해결책을 확인한 다음, 더 자세한 내용이 필요할 때 링크를 따라가세요.
빠른 참조 표
| 증상 | 대체로 의미하는 것 | 가장 먼저 할 일 |
|---|---|---|
407 Proxy Authentication Required | 잘못된 인증 정보 또는 사용자 이름 내 형식이 잘못된 플래그 | 플래그 없이 기본 사용자 이름으로 테스트 |
502 Bad Gateway | 해당 시점에 필터와 일치하는 주소가 없음 | 필터 범위를 넓히기 |
509 Bandwidth Limit Exceeded | 플랜 할당량 소진, 초과 사용 비활성화 상태 | 잔액과 플랜 확인 |
| 연결 거부 또는 멈춤 | 게이트웨이에 아예 도달하지 못함 | nc -vz p.shifter.io 443 |
| 타임아웃 | 대상 서버의 지연, 지나치게 좁은 필터, 또는 자체 동시성 문제 | 연결 시간과 읽기 시간을 분리 |
403 또는 챌린지 페이지 | 프록시가 아니라 대상 서버가 거부함 | 세션 폐기, 헤더 확인 |
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가 차단되었을 때 해야 할 일에 있습니다.
원하는 결과가 아닌 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 https://ipinfo.io/json | head -c 60; echo
done이것이 로테이션되는데 애플리케이션에서는 되지 않는다면 원인은 클라이언트의 커넥션 풀링입니다. 둘 다 로테이션되지 않는다면 사용자 이름에 sticky 세션을 요청하는 sid 플래그가 있는지 확인하고, 보고 있는 주소가 단순히 자신의 주소는 아닌지, 즉 프록시가 아예 적용되지 않고 있는 것은 아닌지 확인하세요. 전체 원인은 IP가 로테이션되지 않음에 있습니다.
TLS 및 인증서 오류
덜 흔하며 대체로 환경적인 문제입니다. 게이트웨이의 cipher suite를 거부하는 오래된 TLS 라이브러리, 혹은 신뢰 체인을 깨뜨리는 회사 미들박스가 원인입니다. 먼저 클라이언트 라이브러리를 업데이트하세요. 인증서 검증을 비활성화하면 오류가 사라지겠지만, 이는 진단을 확인하는 용도로만 사용해야 하며 실제 배포하는 어떤 것에도 사용해서는 안 됩니다.
일반적인 작업 순서
무언가 고장났는데 어디서부터 시작할지 모를 때: 먼저 원시 연결성을 확인하고, 플래그 없이 기본 인증 정보를 테스트한 다음, 플래그를 하나씩 다시 추가하고, 마지막으로 상태 코드를 그냥 믿기보다 응답이 실제로 요청한 내용이 맞는지 확인하세요. 이 순서는 몇 분 안에 문제 계층을 좁혀주며, 증상이 오류 코드든 미묘하게 잘못된 데이터든 동일하게 적용됩니다.
급성이 아니라 지속적인 문제라면, 수동으로 알아차리기 전에 이런 것들을 잡아내는 계측 방법이 대규모로 프록시 상태 모니터링하기에 있습니다.
결론
여덟 가지 패턴이 거의 모든 것을 다룹니다. 407은 인증 정보 문제이거나 형식이 잘못된 플래그이며 재시도할 가치가 없습니다. 502는 장애가 아니라 빈 필터입니다. 509는 대역폭 문제입니다. 연결 거부는 게이트웨이에 아예 도달하지 못했다는 뜻입니다. 타임아웃은 다른 무엇보다 먼저 연결 시간과 전체 시간을 분리해야 합니다. 403이나 챌린지는 대상 서버가 거부하는 것이므로 신원을 바꾼 다음 원인을 파악하세요. 잘못된 내용의 200은 위험한 경우이며, 이것이 본문 검증이 선택이 아닌 이유입니다. 그리고 매 요청마다 같은 주소가 나온다면 거의 항상 자체 클라이언트의 연결 재사용 문제입니다. 연결성부터 바깥쪽으로 작업하고, 상태 코드가 주장하는 것이 아니라 실제로 돌아온 것을 확인하세요.
게이트웨이 자체는 연결하는 방법에, 용어는 용어집에 문서화되어 있으며, 제품은 레지덴셜 프록시이고 GB당 요금제도 있습니다.