HTTP 오류 407: 프록시 인증 필요 해결 방법

HTTP 오류 407은 사용자와 대상 사이트 사이의 프록시가 요청을 전달하기 전에 인증을 요구한다는 뜻입니다. 대상 서버에서 발생하는 401 또는 403과 달리 HTTP 오류 407은 프록시에서 발생하며, 거의 항상 사용자가 해결할 수 있는 자격 증명, 화이트리스트 또는 구성 문제를 가리킵니다.

이 가이드에서는 407 상태가 실제로 무엇을 의미하는지, 유사한 오류와 어떻게 다른지, 일반적인 원인, 그리고 브라우저, Python, curl, Selenium 및 Playwright, 기업용 프록시 설정에서의 단계별 해결 방법을 설명합니다.

DataImpulse는 195개국에서 9천만 개가 넘는 레지덴셜 프록시(residential proxy), 모바일 프록시(mobile proxy), 데이터센터 프록시(datacenter proxy) IP 주소를 제공하는 윤리적 프록시 제공업체입니다. GB당 1달러부터 시작하는 종량제 모델과 만료되지 않는 트래픽을 사용하며, 웹 스크래핑, 광고 검증, 가격 모니터링, 시장 조사 및 다중 계정 관리에 사용됩니다.

HTTP 오류 407은 무엇을 의미하며 401, 403과 어떻게 다릅니까?

HTTP 오류 407은 신원을 증명할 때까지 요청을 전달하지 않는 프록시 서버가 보내는 "프록시 인증 필요" 상태 코드입니다. 프록시는 예상하는 방식을 설명하는 Proxy-Authenticate 헤더로 응답하며, 클라이언트는 일치하는 Proxy-Authorization 헤더로 응답해야 합니다.

핵심은 오류를 보내는 주체입니다. 407은 접속하려는 웹사이트가 아니라 프록시에서 발생하므로 트래픽은 프록시를 벗어나지 않았고 대상 서버도 요청을 보지 못했습니다. 이는 대상 사이트에서 발생하는 다음과 같은 유사한 코드와 구별되는 점입니다.

• 401 Unauthorized: 대상 서버가 Authorization 헤더로 전송되는 리소스 자체의 자격 증명을 요구합니다.
• 403 Forbidden: 대상 서버가 요청을 이해했지만 흔히 차단, 지역 제한 또는 봇 방지 규칙 때문에 거부합니다. 스크래핑 중 계속 403이 발생하면 차단되지 않고 스크래핑하는 방법 가이드를 참조하십시오.
• 407 Proxy Authentication Required: 프록시 자체가 무엇이든 전달하기 전에 Proxy-Authorization 헤더의 자격 증명을 필요로 합니다.

407이 표시되면 대상 사이트 디버깅을 멈추고 먼저 프록시 자격 증명과 연결을 확인하십시오.

HTTP 오류 407의 원인은 무엇입니까?

대부분의 407 오류는 프록시가 수락하지 못한 자격 증명이나 프록시가 인식하지 못하는 IP로 거슬러 올라갑니다. 프록시에는 연결할 수 있지만 세션 인증을 거부합니다.

• 누락되었거나 잘못된 자격 증명: 사용자 이름 또는 비밀번호가 없거나 오타가 있거나 URL 인코딩되지 않은 특수 문자를 포함합니다.
• 화이트리스트에 없는 IP: 일부 제공업체는 사용자 이름과 비밀번호 대신 또는 이와 함께 원본 IP를 허용 목록에 추가하여 인증합니다. IP가 변경되면 프록시는 사용자를 더 이상 인식하지 못합니다.
• 잘못된 형식의 Proxy-Authorization 헤더: 헤더가 없거나 잘못된 방식을 사용하거나 잘못 Base64 인코딩된 값을 포함합니다.
• 만료된 계정 또는 남은 트래픽 없음: 만료된 플랜이나 소진된 잔액으로 인해 프록시가 새 세션을 거부합니다.
• 기업용 프록시의 특성: PAC 또는 WPAD 자동 구성, 혹은 클라이언트가 지원하지 않는 NTLM 또는 Kerberos 방식은 407 인증 창이 반복적으로 표시되게 할 수 있습니다.
• 백신 또는 VPN 가로채기: 트래픽을 검사하는 로컬 보안 소프트웨어나 VPN은 자체 프록시 계층을 삽입하여 인증을 중단시킬 수 있습니다.

브라우저 또는 운영체제에서 407을 어떻게 해결합니까?

프록시 설정을 열고 호스트와 포트를 확인한 다음 사용자 이름과 비밀번호를 다시 입력하여 브라우저가 유효한 Proxy-Authorization 헤더를 만들 수 있게 하십시오. 대부분의 데스크톱 브라우저는 운영체제 프록시 구성을 읽으므로 OS 수준에서 한 번 수정하면 흔히 모든 곳에서 오류가 해결됩니다.

Windows에서는 설정, 네트워크 및 인터넷, 프록시를 확인하고 주소와 포트가 제공업체가 알려준 값과 일치하는지 검증하십시오. macOS에서는 시스템 설정, 네트워크로 이동한 뒤 활성 연결의 프록시 탭을 확인하십시오. 프록시가 사용자 이름과 비밀번호를 요청하면 끝의 공백과 대소문자 구분에 유의해 정확히 입력하십시오. 트래픽 검사가 포함된 VPN 또는 백신이 활성화되어 있다면 자체 프록시를 삽입하여 407을 일으키는지 확인하기 위해 잠시 비활성화하십시오.

Python requests 및 curl에서 407을 어떻게 해결합니까?

클라이언트가 모든 요청에 이를 전송하도록 프록시 URL에 사용자 이름과 비밀번호를 직접 넣으십시오. Python의 requests 라이브러리에서는 proxies 딕셔너리를 전달하고, curl에서는 -x 및 -U 플래그를 사용하십시오.

프록시 게이트웨이에 인증하는 최소 Python 예시는 다음과 같습니다.

import requests

proxy = "http://USERNAME:[email protected]:823"
proxies = {"http": proxy, "https": proxy}

r = requests.get("https://httpbin.org/ip", proxies=proxies, timeout=30)
print(r.status_code, r.text)

동등한 curl 명령은 명령줄에서 동일한 자격 증명과 게이트웨이를 유지합니다.

curl -x http://gw.dataimpulse.com:823 \
     -U USERNAME:PASSWORD \
     https://httpbin.org/ip

비밀번호에 @, : 또는 / 같은 문자가 있으면 프록시 URL에 넣기 전에 URL 인코딩하십시오. 그렇지 않으면 클라이언트가 문자열을 잘못된 위치에서 분할해 잘못된 형식의 헤더를 보낼 수 있습니다. DataImpulse는 HTTP, HTTPS 및 SOCKS5를 지원하므로 작업 흐름에 SOCKS5 터널이 필요하면 URL의 방식을 전환하십시오.

Selenium 또는 Playwright에서 407을 어떻게 해결합니까?

브라우저 자동화 도구는 일반 host:port 문자열에서 프록시 자격 증명을 항상 전달하지는 않으므로, 프레임워크의 프록시 옵션을 통해 사용자 이름과 비밀번호를 제공하거나 작은 인증 확장 프로그램을 로드해야 합니다. Playwright는 자격 증명을 직접 허용하지만 Chrome과 함께 사용하는 Selenium은 흔히 도우미가 필요합니다.

Playwright에서는 브라우저 컨텍스트를 실행할 때 server, username, password를 포함하는 proxy 객체 등으로 사용자 이름과 비밀번호를 포함한 프록시를 전달하십시오. Selenium에서는 자격 증명을 포함할 수 없는 기본 --proxy-server 인수를 사용하므로, 브라우저의 인증 콜백에 사용자 이름과 비밀번호로 응답하는 작은 Chrome 확장 프로그램을 패키징하거나 로컬 인증 포워더를 통해 라우팅하십시오. 두 방법 모두 제어 중인 브라우저가 407을 표시하는 대신 프록시 인증 요구에 응답하도록 합니다. 레지덴셜 프록시 및 모바일 프록시 같은 레지덴셜 엔드포인트는 자격 증명을 올바르게 연결하면 둘 다에서 작동합니다.

기업용 프록시에서 407을 어떻게 해결합니까?

관리되는 기업 네트워크에서 407은 보통 PAC 또는 WPAD 파일로 자동 검색되는 NTLM 또는 Kerberos를 통해 도메인 자격 증명을 기대하는 프록시에서 발생합니다. 이러한 자격 증명을 운영체제 자격 증명 저장소에 저장하면 반복되는 인증 창이 흔히 해결됩니다.

Windows에서는 애플리케이션이 자동으로 인증할 수 있도록 자격 증명 관리자에 프록시 항목을 추가하고, 브라우저가 사용하는 PAC 또는 WPAD URL이 실제로 의도한 프록시를 가리키는지 확인하십시오. 명령줄 도구와 스크립트는 기본적으로 NTLM을 지원하지 않을 수 있으므로 브라우저가 성공해도 계속 실패할 수 있습니다. 이 경우 네트워크 팀에 정확한 호스트, 포트 및 지원되는 인증 방식을 요청하거나 기업용 핸드셰이크를 처리하는 로컬 프록시 브리지를 실행하십시오. DataImpulse와 같은 상용 제공업체는 간단한 사용자 이름과 비밀번호 또는 IP 화이트리스트로 인증하므로 내부 기업용 프록시의 NTLM 및 Kerberos 복잡성을 피할 수 있습니다.

제공업체 지원팀에 문의하기 전에 무엇을 확인해야 합니까?

티켓을 열기 전에 프록시가 먼저 확인하는 세 가지, 즉 계정 잔액, IP 화이트리스트, 정확한 게이트웨이 호스트와 포트를 검증하십시오. 올바른 자격 증명으로도 지속되는 407은 보통 이 중 하나입니다.

• 잔액 및 계정 상태: 플랜이 활성 상태이고 트래픽이 남아 있는지 확인하십시오. DataImpulse는 만료되지 않는 종량제 트래픽을 사용하지만 잔액이 비어 있으면 새 세션이 중단됩니다.
• IP 화이트리스트: 허용 목록으로 인증하는 경우 현재 공용 IP가 나열되어 있는지 확인하십시오. IP가 변경되었을 수 있습니다.
• 게이트웨이 호스트 및 포트: 예를 들어 gw.dataimpulse.com:823의 DataImpulse 게이트웨이처럼 올바른 엔드포인트를 가리키고 있으며 오래된 주소가 아닌지 확인하십시오.
• 자격 증명 형식: 사용자 이름과 비밀번호를 다시 복사하고 특수 문자를 URL 인코딩한 뒤 HTTP, HTTPS, SOCKS5 중 올바른 프로토콜을 사용 중인지 확인하십시오.

DataImpulse는 195개국에서 9천만 개 이상의 레지덴셜 프록시, 모바일 프록시 및 데이터센터 프록시를 제공하는 윤리적 프록시 제공업체이므로, 이 네 가지 검사를 통과했는데도 407이 남아 있다면 지원팀이 해당 측에서 세션을 추적할 수 있습니다.

프록시 관련 HTTP 코드 한눈에 보기

자주 묻는 질문

관련 가이드

• 프록시 인증이란 무엇입니까
• 프록시 서버가 응답하지 않는 문제 해결
• 연결이 비공개가 아님 문제 해결

인증이 원활한 프록시가 필요하십니까?

기업용 프록시의 복잡성 없이 간단한 사용자 이름 및 비밀번호 또는 IP 화이트리스트 인증을 원한다면, DataImpulse는 만료되지 않는 트래픽을 포함한 GB당 1달러부터의 종량제 프록시를 제공합니다. 계정 만들기를 하고 gw.dataimpulse.com:823 게이트웨이를 통해 연결하여 시작하십시오.