모든 요청이 407 Proxy Authentication Required로 돌아오고, 타겟에는 아무것도 도달하지 않으며, 패널에서 자격 증명은 정상으로 보인다. 이것은 이 제품 카테고리에서 가장 흔한 지원 티켓 중 하나이면서 동시에 가장 빠르게 해결되는 것이기도 한데, 407을 발생시킬 수 있는 원인의 수가 적고 정해진 순서로 하나씩 배제할 수 있기 때문이다.
이 상태 코드가 실제로 무엇을 의미하는지, 확인해볼 가치가 있는 원인들, 확인해야 할 순서, 그리고 자격 증명이 올바른데도 407을 발생시키는 클라이언트별 실수들을 살펴본다.
407이 실제로 의미하는 것
407은 도달하려는 사이트가 아니라 프록시로부터 온다. 이것은 프록시가 수용 가능한 자격 증명 없이 요청이 도착했다고 알리는 방식이며, 오리진 서버의 401에 해당하는 프록시 계층의 등가물이다. 이 구분은 디버깅에서 중요하다: 407은 트래픽이 게이트웨이에 도달했고 게이트웨이가 이를 거부했다는 뜻이다. 연결은 문제 없다. 인증에 문제가 있는 것이다.
이는 또한 타겟 사이트가 전혀 관여하지 않았다는 뜻이기도 하다. 407을 받고 있다면, 헤더, 사용자 에이전트, 렌더링, 속도 조절을 아무리 바꿔도 도움이 되지 않는데, 애초에 요청이 프록시를 벗어난 적이 없기 때문이다.
가장 먼저 확인해볼 세 가지 원인
타겟팅이 사용자 이름에 표현되는 게이트웨이에서는 거의 모든 407이 다음 세 가지 중 하나다.
자격 증명이 잘못되었다. 오타, 대시보드에서 복사할 때 딸려온 공백 문자, 또는 다른 제품의 자격 증명일 수 있다. 프록시 자격 증명은 보통 계정 로그인과 다른데, 이는 의외로 흔한 혼동이다.
확장된 사용자 이름 안의 플래그가 잘못되었다. 이것은 사람들이 놓치기 쉬운 원인으로, 사용자 이름에 타겟팅을 인코딩하는 게이트웨이에 특유한 문제다. 사용자 이름에 country, city, session, TTL 플래그가 담겨 있다면, 인식되지 않는 값 하나가 사용자 이름 전체를 파싱 불가능하게 만들며, 게이트웨이는 이를 타겟팅 오류가 아니라 인증 실패로 거부한다. 잘못 입력된 국가 코드, 형식이 틀린 도시 슬러그, 허용되지 않는 문자가 포함된 세션 식별자, 또는 sid 없이 사용된 ttl 등이 모두 여기에 해당한다. 자격 증명은 완벽하지만 사용자 이름 문자열이 그렇지 않은 경우다.
비밀번호가 교체되었다. 누군가 패널에서 비밀번호를 재발급했다면, 이전 값을 여전히 가지고 있는 모든 클라이언트는 업데이트될 때까지 407을 반환한다. 이는 한 머신에서는 작동하고 다른 머신에서는 실패하는 전형적인 사례다.
진단 순서
작동할 때까지 아래 목록을 순서대로 내려가며 확인한다. 문제를 해결한 단계가 곧 원인을 알려주기 때문이다.
하나: 모든 플래그를 제거하고 순수 자격 증명을 테스트한다. 이 한 단계만으로 자격 증명 문제와 플래그 문제를 구분할 수 있으며, 항상 가장 먼저 해야 한다.
# bare username, no targeting flags at all
curl -x customer-USERNAME:PASSWORD@p.shifter.io:443 https://ipinfo.io/json성공한다면 자격 증명은 문제 없으며 원인은 플래그에 있다. 여전히 407을 반환한다면 자격 증명 자체가 잘못된 것이며, 플래그를 아무리 고쳐도 소용없다.
둘: 플래그를 하나씩 다시 추가한다. country 먼저, 그다음 city 또는 ASN, 그다음 session과 TTL 순이다. 407을 다시 발생시키는 플래그가 잘못된 것이며, 이제 정확히 어떤 값을 확인해야 할지 알 수 있다.
curl -x customer-USERNAME-country-us:PASSWORD@p.shifter.io:443 https://ipinfo.io/json
curl -x customer-USERNAME-country-us-city-new_york:PASSWORD@p.shifter.io:443 https://ipinfo.io/json
curl -x customer-USERNAME-country-us-city-new_york-sid-abc123:PASSWORD@p.shifter.io:443 https://ipinfo.io/json형식을 주의 깊게 확인한다: country 코드는 두 글자 ISO 코드이므로 uk는 흔한 실수이고 gb가 올바르다. city 슬러그는 공백이나 하이픈 대신 언더스코어를 사용하며, new_york처럼 표기한다. 그리고 ttl은 sid와 함께일 때만 유효하므로, 단독으로 쓰인 TTL은 무효다. 전체 문법은 게이트웨이 및 인증 문서에 있으며, 타겟팅 옵션은 도시 단위 타겟팅과 ASN 타겟팅에서 다룬다.
셋: 패널에서 비밀번호를 다시 복사한다. 1단계에서 순수 자격 증명이 실패했다면, 메모나 설정 파일이 아니라 패널에서 직접 비밀번호를 가져오고, 특히 끝의 공백, 문서에서 온 스마트 따옴표, 또는 잘려나간 붙여넣기가 없는지 확인한다.
넷: 값을 모든 곳에 롤아웃한다. 로컬에서는 작동하지만 프로덕션에서는 작동하지 않는다면, 환경 변수, 시크릿 관리자, 컨테이너 이미지, 또는 CI 설정에 오래된 사본이 남아 있는 것이다. 이는 프록시 문제가 아니라 배포 문제다.
407처럼 보이지만 아닌 오류들
이를 구분하면 많은 시간 낭비를 줄일 수 있는데, 각각 해결 방법이 다르기 때문이다.
이 게이트웨이에서 502는 그 순간 필터에 일치하는 주소가 없었다는 뜻이다. 이는 인증 문제가 아니라 타겟팅 문제다: 자격 증명은 수용되었지만 요청한 조합에 사용 가능한 것이 없었던 것이다. 필터를 넓히거나, 도시 단위에서 국가 단위로 낮추거나, 엄격한 일치 플래그를 완화한다.
509는 오버리지가 비활성화된 상태에서 요금제 대역폭이 소진되었다는 뜻이다. 인증은 성공했으며, 할당량이 부족한 것이다. 관련 산정 가이드는 월간 대역폭 추정에 있다.
Connection refused는 게이트웨이에 전혀 도달하지 못했다는 뜻으로, 보통 현재 엔드포인트가 아니라 레거시 포트 기반 호스트를 가리키고 있거나, 네트워크의 아웃바운드가 차단되어 있기 때문이다. 인증 문제라고 가정하기 전에 nc -vz p.shifter.io 443으로 원시 연결을 테스트한다.
타겟에서 오는 403 또는 챌린지 페이지는 인증이 완벽하게 작동했고 사이트가 거부한 것으로, 차단 회피에서 다루는 완전히 다른 문제다.
407을 발생시키는 클라이언트별 실수
때로는 자격 증명과 플래그가 모두 올바른데 클라이언트에 문제가 있는 경우가 있다.
비밀번호에 포함된 특수 문자. 비밀번호에 URL에서 의미를 갖는 문자, 즉 @, :, #, /, %가 포함되어 있다면, 이를 프록시 URL에 직접 삽입하면 파싱이 깨져서 자격 증명이 손상된 채로 도착한다. 퍼센트 인코딩을 해야 한다.
import requests
from urllib.parse import quote
user = "customer-USERNAME-country-us"
pwd = quote("p@ss:word/123", safe="") # encode before embedding
PROXY = f"http://{user}:{pwd}@p.shifter.io:443"
r = requests.get("https://ipinfo.io/json",
proxies={"http": PROXY, "https": PROXY}, timeout=15)
print(r.status_code, r.text[:120])프록시 인증과 타겟 인증의 혼동. curl -U는 프록시 자격 증명을 설정하고, -u는 타겟 사이트의 자격 증명을 설정한다. 프록시 자격 증명을 Authorization 헤더로 보내는 것은 아무 효과가 없는데, 프록시 인증은 Proxy-Authorization을 통해 전달되며, 대부분의 클라이언트는 자격 증명이 프록시 URL에 있을 경우 이를 자동으로 설정해주기 때문이다.
HTTPS에서 자격 증명이 누락됨. 일부 클라이언트 설정은 HTTP에만 프록시를 설정하여, 일반 요청은 인증되지만 HTTPS 요청은 인증되지 않는다. 위 Python 예제처럼 두 항목 모두 설정해야 한다.
생각한 것과 다른 환경 변수. 셸 프로필, Dockerfile, 또는 CI 러너에 설정된 HTTP_PROXY와 HTTPS_PROXY는 코드가 전달하는 값을 조용히 덮어쓸 수 있으며, 그 결과 애플리케이션이 소스 코드에 있는 것과 완전히 다른 프록시 문자열로 인증을 시도하게 된다. 디버깅할 때는 코드를 신뢰하기보다 실제 적용되는 프록시 설정을 출력해본다.
선제적 프록시 인증을 보내지 않는 라이브러리. 일부 HTTP 클라이언트는 자격 증명을 보내기 전에 챌린지를 기다리며, 특히 특정 터널링 설정에서 챌린지를 잘못 처리한다. 순수 curl은 작동하는데 애플리케이션은 작동하지 않는다면, 차이는 게이트웨이가 아니라 클라이언트에 있다. 일반적인 스택에서 작동하는 설정은 Python으로 레지덴셜 프록시 사용하기에 있다.
프로덕션 코드에서 407 처리하기
운영상 참고할 점 하나: 407은 일시적 오류가 아니라 종결 오류다. 재시도는 무의미한데, 다음 시도에서도 자격 증명은 동일하게 잘못되어 있을 것이며, 인증 실패에 대한 재시도 루프는 대역폭만 낭비하고 외부에서 보기에는 크리덴셜 스터핑 패턴처럼 보일 수 있다. 이를 종결 오류로 분류하고, 명확하게 실패시키고, 알림을 보내야 한다. 이것이 재시도와 백오프에서 다루는 분류 원칙이다.
자격 증명 교체는 패널 클릭이 아니라 배포 계획이 필요한데, 이전 값을 가진 모든 클라이언트가 교체 순간부터 실패하기 시작하기 때문이다. 먼저 시크릿 저장소를 업데이트하고, 클라이언트를 순차적으로 갱신한 다음, 교체한다.
결론
407은 요청이 게이트웨이에 도달했고 게이트웨이가 자격 증명을 거부했다는 뜻이므로, 타겟 사이트는 무관하며 연결은 이미 증명된 것이다. 먼저 플래그 없이 순수 자격 증명을 테스트하는데, 이 한 단계가 문제를 절반으로 나눠주기 때문이다. 그런 다음 플래그를 하나씩 다시 추가하며 잘못된 것을 찾는데, 잘못된 국가 코드나 세션 없는 TTL이 사용자 이름 전체를 파싱 불가능하게 만든다는 점을 기억해야 한다. 순수 테스트가 실패했다면 패널에서 비밀번호를 다시 복사하고, 한 곳에서는 작동하는데 다른 곳에서는 작동하지 않는다면 환경 변수와 시크릿 저장소에 오래된 값이 남아 있는지 확인한다. 비슷해 보이는 것들을 배제한다: 502는 빈 필터, 509는 대역폭, connection refused는 잘못된 호스트, 사이트에서 오는 403은 애초에 인증 문제가 아니다. 그리고 407은 절대 재시도하지 않는다.
전체 문법 레퍼런스는 게이트웨이 및 인증 문서에 있으며, 제품 자체는 레지덴셜 프록시로, 동일한 자격 증명이 모든 국가, 도시, 세션 모드에서 GB당 요금제와 함께 작동한다.