407 Proxy Authentication Required 해결

Problem

요청이 407 Proxy Authentication Required를 반환합니다. 로드하려던 사이트에는 닿지도 못했습니다. 당신과 오리진 사이의 프록시 — 회사 게이트웨이, 스크래핑 프록시, 캐싱 장비 — 가 당신이 프록시에 인증하지 않아 요청을 거부한 것입니다. 여기서 오리진 서버는 무관합니다. 목적지가 아니라 문지기에서 막힌 것입니다.

Symptoms

• 클라이언트(브라우저, curl, 스크래퍼, CI 작업)가 407 Proxy Authentication Required를 보고합니다.
• 응답에 스킴을 명시하는 Proxy-Authenticate 헤더가 있습니다 — Basic, Digest, NTLM, 또는 Negotiate.
• 프록시가 있는 네트워크(사무실, VPN, 데이터센터 egress)에서만 뜨고, 프록시 없는 네트워크에선 사라집니다.
• 프록시 자격증명이 만료·교체되거나 프록시 URL에서 박혀 있던 user:pass가 빠지기 전까지는 다 잘 됐습니다.

What 407 Actually Means

RFC 9110(§15.5.8)은 407을 “401(Unauthorized)과 유사하나, 클라이언트가 이 요청에 대해 프록시를 사용하기 위해 스스로 인증해야 함을 나타낸다”로 정의합니다. 그 한 단어 — 프록시 — 가 진단의 전부입니다. 요청이 중간자까지 갔다가 프록시 자격증명이 없어 되돌려진 것입니다. 오리진은 그 요청을 본 적이 없습니다.

407을 그 쌍둥이와 가르는 건 헤더 짝입니다. 407 응답은 요구를 담은 Proxy-Authenticate 헤더(RFC 9110 §11.7.1)를 반드시 포함하고, 클라이언트는 Proxy-Authorization 헤더(§11.7.2)로 답합니다. 401과 비교하면 401은 WWW-Authenticate와 Authorization을 씁니다. 같은 핸드셰이크, 다른 배우: 401은 오리진이 당신이 누군지 묻는 것이고, 407은 프록시가 묻는 것입니다. 어느 헤더가 요구를 담는지 읽으면 어느 홉이 거부했는지 즉시 알 수 있고 — 앞의 프록시가 전달조차 하지 않을 오리진 자격증명을 붙이느라 오후를 낭비하는 걸 막아줍니다.

그 전달 세부사항이 보기보다 중요합니다. 프록시 인증은 hop-by-hop입니다: Proxy-Authorization은 가장 가까운 프록시가 소비하고 전달하지 않는 반면, Authorization은 end-to-end로 오리진까지 갑니다. 프록시가 연쇄로 있으면 인증을 원하는 각 홉이 자기 407을 던집니다. 자격증명 하나가 체인을 “흘러가지” 않습니다.

Top 3 Causes

1. 프록시 자격증명 누락 또는 오류 - 클라이언트가 Proxy-Authorization 헤더를 안 보내거나 잘못된 아이디/비밀번호를 보냅니다. 스크래퍼·CI의 전형적 경우: 프록시 URL이 user:pass 없는 http://proxy.example:8080이거나, 자격증명이 교체됐는데 갱신 안 됨. 실제 407의 압도적 다수입니다.
2. 클라이언트가 프록시 설정을 못 찾음 - 프록시가 어떤 도구는 읽고 다른 도구는 무시하는 환경변수·시스템 설정에 있습니다. curl은 http_proxy/https_proxy를 따르지만 라이브러리는 안 그럴 수 있거나 프록시를 명시로 넘겨야 합니다. 요청이 프록시 인증 없이 나가고 프록시가 튕겨냅니다.
3. 미지원·불일치 인증 스킴 - 프록시가 NTLM이나 Negotiate(회사 Windows 네트워크에 흔함)를 요구하는데 클라이언트는 Basic만 말합니다. 자격증명은 있으나 Proxy-Authenticate가 요구하는 챌린지를 클라이언트가 수행하지 못합니다.

Diagnose with DechoNet

• HTTP 검사는 대상 URL을 우리 서버에서 요청하며, 우리 서버는 당신의 회사·스크래핑 프록시 뒤에 있지 않습니다. HTTP 검사가 정상 200(또는 사이트의 실제 상태)을 반환하는데 당신은 407을 받는다면, 오리진은 건강하고 407은 당신의 프록시 홉이 만든 것임을 확인한 셈입니다 — 문제를 목적지가 아니라 당신 쪽으로 좁힙니다.

Resolution Checklist

• 오리진이 아니라 프록시 문제인지 확인하세요: Proxy-Authenticate 헤더가 붙은 407(프록시)인가요, WWW-Authenticate가 붙은 401(오리진)인가요? 맞는 홉을 고치세요.
• Proxy-Authenticate의 스킴을 읽으세요. Basic/Digest는 단순 user:pass, NTLM/Negotiate는 Windows 통합 인증을 할 수 있는 클라이언트가 필요합니다. 클라이언트를 스킴에 맞추세요.
• 자격증명이 실제로 붙는지 확인하세요. curl로: curl -v -x http://user:pass@proxy:8080 https://YOUR_TARGET 후 나가는 Proxy-Authorization 헤더를 확인. 없으면 클라이언트가 자격증명을 못 잡은 것입니다.
• 비밀번호에 특수문자가 있으면 프록시 URL에서 URL 인코딩하세요(@, :, /가 파싱을 깨뜨립니다).
• HTTP 검사로 교차 확인하세요. 우리의 오리진 직접 요청은 성공하는데 당신은 407이라면, 잘못은 사이트가 아니라 당신의 프록시 홉입니다 — 서버가 아니라 프록시 설정을 쫓으세요.
• 프록시 체인이라면 각 홉이 개별 인증함을 기억하세요. 첫 프록시 뒤의 407은 뒤쪽 프록시가 자기 Proxy-Authorization을 원하는 것입니다.

When to Escalate

• 자격증명이 맞고 붙는 것도 확인했는데 프록시가 여전히 407을 반환하면, 프록시 운영자에게 문의하세요 — 계정이 비활성화·IP 잠금됐거나 인증 백엔드(LDAP/AD)가 다운됐을 수 있습니다.
• NTLM/Negotiate를 요구하는 회사 네트워크에서는 모든 클라이언트에서 챌린지를 손수 구현하려 하지 말고 IT에 문의하거나 로컬 인증 전달 프록시(예: Cntlm)를 쓰세요.
• 스크래핑·egress 프록시가 간헐적으로 407을 낸다면 제공자에게 문의하세요 — 설정 문제가 아니라 사용량 기반 자격증명 스로틀링이나 교체된 풀인 경우가 많습니다.