사용자 이름·비밀번호 프록시 인증: 연결 방법과 오류 예방

사용자 이름·비밀번호 인증에서는 애플리케이션이 제공업체에서 발급받은 인증 정보를 프록시에 보냅니다. 프록시는 이를 확인하고 서비스 사용을 허용합니다. 이 방식은 여러 기기와 네트워크에서 작업할 때 유용합니다. 서비스가 IP 기반 접근 승인도 요구하지 않는다면 스크립트를 다른 서버로 옮겨도 허용 IP 주소를 변경할 필요가 없습니다.

연결이 작동하려면 사용자 이름과 비밀번호 외에도 필요한 것이 있습니다. 올바른 프록시 주소, 포트, 프로토콜이 필요하며, 애플리케이션이 필요한 인증 방식을 지원해야 합니다. 따라서 인증 오류가 반드시 비밀번호 오류를 뜻하지는 않습니다.

접근 방식의 비교와 선택에 대해서는 프록시 인증을 참고하세요. 이 글에서는 설정 입력부터 실행 중인 스크립트의 문제 진단까지 사용자 이름과 비밀번호로 연결하는 방법을 다룹니다.

사용자 이름·비밀번호 인증의 의미

사용자 이름은 계정이나 특정 서비스에 대한 접근을 식별하고, 비밀번호는 이를 사용할 권리를 확인합니다. 검사가 성공하면 프록시는 가용 주소 목록, 구매한 허용량, 적용되는 한도 등 부여된 권한 안에서 연결을 처리합니다.

프록시 인증 정보를 대시보드 비밀번호와 혼동하지 마세요. 애플리케이션에서 사용하는 정보는 제공업체 웹사이트의 로그인 정보와 다를 수 있습니다. API 키는 서비스 API 요청용이고 대상 웹사이트 비밀번호는 해당 사이트 로그인용입니다. 제공업체가 그 연결 방식을 명시한 경우에만 이를 프록시 비밀번호로 사용하세요.

프록시 인증에 성공해도 대상 웹사이트에 로그인되는 것은 아닙니다. 웹사이트가 자체 계정, 쿠키 또는 토큰을 요구한다면 애플리케이션이 별도로 제공해야 합니다.

이 방식이 유용한 경우

사용자 이름과 비밀번호 방식은 위치가 고정돼 있든 바뀌든 여러 장소의 애플리케이션에 접근을 제공할 수 있습니다. IP 제한이 없다면 각 애플리케이션에는 인증 정보와 프록시 연결 설정만 필요하며 네트워크별 허용 목록 항목은 필요하지 않습니다.

예를 들어 팀이 서로 다른 공인 IP를 사용하는 두 사무실과 집에서 작업합니다. 서비스가 IP 바인딩 없이 해당 애플리케이션들의 인증 정보 공유를 허용한다면 같은 프록시 인증 정보를 사용할 수 있습니다. 각 애플리케이션은 자체 연결 설정을 유지하고, 프록시는 각각이 보낸 인증 정보를 확인합니다.

이 방식은 여러 상시 서버에서도 사용할 수 있습니다. 다만 기기 수, 동시 연결 수, 가용 자원은 요금제에 따라 달라집니다. 비밀번호 하나가 무제한 접근을 부여하지는 않습니다.

애플리케이션이 프록시 인증 정보를 보내는 방법

전체 순서는 간단합니다. 애플리케이션이 프록시에 접속하고, 접근 검사를 통과한 뒤, 이를 통해 요청한 리소스에 도달합니다. 세부 과정은 프로토콜에 따라 다릅니다.

HTTP 프록시는 먼저 407 Proxy Authentication Required를 반환하며 허용하는 인증 방식을 알릴 수 있습니다. 애플리케이션은 Proxy-Authorization 헤더에 인증 정보를 보냅니다. 일부 클라이언트는 처음부터 이를 보내므로 최초 인증 요구가 로그에 나타나지 않을 수 있습니다.

일반 HTTP 프록시로 HTTPS 웹사이트를 열 때는 터널을 수립하는 CONNECT 요청 중 인증할 수 있습니다. 그다음 애플리케이션이 웹사이트와 보안 연결을 수립합니다. 이미 수립된 해당 터널을 통한 후속 웹사이트 요청은 터널을 열 때 사용한 프록시 로그인을 반복하지 않습니다.

SOCKS5에서는 대상 연결 요청에 앞서 연결 시작 시 사용자 이름과 비밀번호를 확인합니다. 검사가 실패하면 애플리케이션은 프록시를 통한 요청 연결을 얻지 못합니다. SOCKS5 자체 인증 실패는 HTTP 407 응답이 아닙니다.

서비스가 지원하는 프로토콜과 인증 방식을 선택하세요. SOCKS4에는 사용자 ID 필드가 있지만 SOCKS5의 사용자 이름·비밀번호 교환을 정의하지 않습니다. 해당 필드를 채워도 SOCKS4 클라이언트가 SOCKS5 비밀번호 인증을 수행하지는 않습니다.

애플리케이션에 입력할 설정

해당 서비스의 연결 정보부터 확인하세요. 애플리케이션에 별도 필드가 있다면 각 값을 알맞은 칸에 입력하세요.

일부 애플리케이션은 protocol://username:password@host:port 형식의 문자열 하나를 받습니다. 예를 들어 http://client01:River%[email protected]:8080에서 사용자 이름은 client01, 비밀번호는 River@2026, 호스트는 proxy.example, 포트는 8080입니다. 비밀번호 안의 @는 호스트 앞의 구분자와 혼동되지 않도록 %40으로 표현합니다.

예를 들어 curl은 프록시 URL을 이 방식으로 해석합니다. 별도의 비밀번호 필드에는 일반적으로 URL 인코딩하지 않은 비밀번호 자체를 넣습니다. 형식을 확인하지 않고 URL의 인코딩된 값을 별도 필드로 복사하지 마세요. 애플리케이션이 다른 비밀번호로 해석할 수 있습니다. %, 콜론 또는 다른 특수 문자가 들어 있는 문자열은 해당 클라이언트의 형식 요구 사항을 따르세요.

인증 정보 안에서 필요한 문자를 한 번만 인코딩하세요. 문자열 전체를 인코딩하면 구분자가 손상됩니다. 명령 인수에 따옴표를 붙이는 것은 URL 인코딩을 대신하지 않습니다. 인증 방식 자체에도 제한이 있을 수 있습니다. 예를 들어 HTTP Basic은 비밀번호의 콜론은 허용하지만 사용자 이름의 콜론은 허용하지 않습니다.

가져오기 형식도 다릅니다. host:port:username:password와 username:password@host:port는 서로 바꿔 쓸 수 없습니다. 가져오기 기능이 다른 배열을 기대한다면 값이 정확해도 순서가 틀리면 작동하지 않습니다.

프록시 URL의 http:// 접두사는 클라이언트가 프록시 자체에 접속하는 방식을 설명합니다. HTTPS 웹사이트 접근을 막는 것은 아닙니다. 클라이언트는 해당 사이트용 터널을 수립할 수 있습니다. 접두사를 https://로 바꾸는 것만으로 서버에 보안 프록시 연결 지원이 추가되지는 않습니다.

일부 서비스는 사용자 이름에 국가, 출구 그룹 또는 세션 매개변수를 포함합니다. 문자열 전체를 복사하세요. 이 매개변수는 제공업체 규칙에 따라 라우팅을 제어합니다. 문법을 임의로 만들거나 다른 서비스의 문법을 가져오지 마세요.

애플리케이션의 인증 지원을 확인해야 하는 이유

프록시 지원과 프록시 인증 지원은 별개입니다. 호스트와 포트 필드가 있다고 클라이언트가 사용자 이름과 비밀번호를 보낼 수 있다는 뜻은 아닙니다.

프록시 프로토콜, 인증 방식, 애플리케이션의 정확한 조합을 확인하세요. 예를 들어 Chrome의 내장 SOCKS5 구현은 SOCKS5 프록시 인증을 지원하지 않습니다. 인증 정보가 정확하다는 것만으로 이 제한을 해결할 수 없습니다. 프록시를 선택하는 확장 프로그램도 누락된 인증 방식을 반드시 추가해 주는 것은 아닙니다.

스크립트에서는 라이브러리, 선택적 구성요소, 설정 전달 방식에 따라 지원 여부가 달라질 수 있습니다. 애플리케이션이 시스템 프록시 설정이나 이미 연결이 작동하는 브라우저의 설정을 반드시 사용하는 것은 아닙니다.

대규모 작업을 시작하기 전에 실제 실행할 애플리케이션에서 요청 하나를 테스트하세요. 지정한 프록시를 사용하고 실패 후 직접 연결로 계속하지 않는지 확인하세요. 페이지가 열렸다는 사실만으로 설정이 올바르다고 확인되지는 않습니다.

IP가 바뀌면 어떻게 되는가

유동 IP를 사용하는 ADSL 연결에서는 라우터를 다시 시작하거나 재연결하면 인터넷 제공업체가 새 주소를 할당할 수 있습니다. 프록시가 사용자 이름과 비밀번호만 확인한다면 애플리케이션은 같은 인증 정보로 연결합니다. 대시보드에 새 IP를 추가할 필요가 없습니다. 사무실에서 가정용 네트워크로 옮길 때도 같습니다.

다만 네트워크 변경으로 기존 연결이 중단될 수 있습니다. 클라이언트가 다시 연결해야 하며 미완료 요청을 재시도해야 할 수 있습니다. Wi-Fi에서 모바일 인터넷으로 바꾼 직후의 오류를 자동으로 비밀번호 문제라고 판단해서는 안 됩니다.

일부 서비스는 인증 정보와 출발지 주소를 모두 확인합니다. 올바른 비밀번호도 이 네트워크 제한을 무효화하지 않습니다. 새 IP가 허용 주소 또는 범위와 일치해야 합니다. 스크립트를 옮기기 전에 서비스가 모든 네트워크의 접속을 받는지, 결합 검사를 적용하는지 확인하세요.

전송 중 비밀번호가 보호되는가?

인증은 누가 접근할 수 있는지 결정합니다. 암호화는 경로상의 누군가가 전송 데이터를 읽을 수 있는지 결정합니다. 비밀번호가 있다는 사실만으로 연결이 암호화되지는 않습니다.

HTTP Basic은 사용자 이름과 비밀번호를 Base64로 인코딩합니다. 되돌릴 수 있는 표현 방식이며 암호화가 아닙니다. 프록시 연결이 보호되지 않으면 해당 네트워크 경로를 관찰하는 사람이 인증 정보를 얻을 수 있습니다. 표준 SOCKS5 사용자 이름·비밀번호 인증도 전송을 암호화하지 않습니다.

대상 웹사이트의 HTTPS는 애플리케이션과 해당 사이트 사이의 연결을 보호합니다. HTTP 프록시에서는 터널 준비 중의 인증이 그보다 먼저 이루어지므로 사이트의 TLS가 이미 보낸 프록시 인증 정보를 보호하지 않습니다. 마찬가지로 SOCKS5를 통한 HTTPS 요청도 앞서 수행한 프록시 비밀번호 검사를 암호화하지 않습니다.

해당 경로를 보호하려면 애플리케이션과 프록시 사이에 보호가 필요합니다. 서비스와 클라이언트가 모두 지원할 때 TLS를 사용하는 HTTPS 프록시가 한 예입니다. 애플리케이션은 프록시 인증서를 검증해야 합니다. 일부 판매 목록의 “HTTPS 프록시”는 HTTPS 웹사이트에 접근할 수 있다는 뜻일 뿐이므로 TLS가 실제로 어디에 적용되는지 확인하세요.

유효한 비밀번호를 포함한 전체 연결 문자열이 노출되면 다른 사람이 서비스 규칙 안에서 이를 사용해 허용량을 소비하거나 연결을 차지할 수 있습니다. 인증 정보가 별개라면 이는 대시보드 비밀번호를 얻은 것과 같지는 않습니다. 인증 방식이 주소의 프록시 식별을 막아 주는 것도 아닙니다. 외부에서 접근 가능한 인증 요구 응답이 서비스를 드러낼 수 있습니다.

여러 애플리케이션이 같은 인증 정보를 사용할 수 있는가?

기술적으로는 여러 클라이언트가 같은 사용자 이름과 비밀번호를 보낼 수 있습니다. 제공업체는 허용 여부와 경계를 정합니다. 공유 조건, 활성 연결 한도, 구매한 허용량, 추가 제한 등이 해당합니다.

예를 들어 두 스크립트가 한 계정을 사용하면서 서로 다른 수의 연결을 열 수 있습니다. 비밀번호 하나가 연결 하나를 뜻하지는 않습니다. 마찬가지로 프로세스 10개를 시작한다고 서비스의 전체 연결 허용량이 10배가 되지는 않습니다.

인증 정보 쌍의 수와 출구 IP 수 역시 다릅니다. 하나의 사용자 이름과 비밀번호로 고정 프록시 목록이나 주소 풀을 사용하는 게이트웨이에 접근할 수 있습니다. 웹사이트에 표시되는 IP는 선택한 프록시와 서비스의 라우팅 규칙에 따라 달라집니다.

서비스가 애플리케이션이나 팀원별로 별도 인증 정보를 제공한다면 다른 정보를 바꾸지 않고 한 세트만 비활성화할 수 있습니다. 비밀번호를 공유한다면 변경 시 이를 사용하는 모든 애플리케이션을 갱신해야 합니다. 별도 인증 정보라고 연결이나 트래픽 허용량도 별개라는 뜻은 아닙니다. 어떤 한도를 공유하는지 확인하세요.

프록시가 사용자 이름과 비밀번호를 거부하는 이유

먼저 누가 오류를 반환했는지 확인하세요. HTTP 407은 프록시 인증에 관한 것이고, 대상 웹사이트의 401은 해당 사이트 접근에 관한 것입니다. 403 메시지나 시간 초과만으로는 추가 근거 없이 프록시 비밀번호가 올바른지 알 수 없습니다.

서비스 상태와 남은 허용량을 확인한 뒤 실제 애플리케이션에서 제공된 설정으로 요청 하나를 테스트하세요. 실패하면 표를 참고해 클라이언트 지원, 인증 정보 형식, 출발지 IP 제한을 확인하며 설정을 한 번에 하나씩 바꾸세요. 요청이 안정적으로 작동하면 작업량을 늘리고 부하가 있을 때만 나타나는 한도를 관찰하세요.

실행 중인 스크립트의 인증 정보 보관과 변경

인증 정보는 코드와 분리해 접근이 제한된 설정이나 사용 환경의 비밀 정보 저장소에 보관하세요. 애플리케이션이 환경 변수로 받을 수 있지만 환경 변수 자체는 암호화가 아닙니다. 실제 비밀번호를 저장소나 다른 사람과 공유하는 템플릿에 넣지 마세요.

로그에는 보통 프록시 호스트와 포트, 연결 결과, 오류 코드가 필요합니다. 전체 연결 문자열에는 비밀번호가 있으므로 로그에 쓰기 전에 가리세요. 명령줄 도구에서는 애플리케이션과 시스템에 따라 비밀 정보가 명령 기록에 남거나 프로세스 인수에 보일 수 있다는 점을 고려하세요.

비밀번호를 바꾸기 전에 이를 사용하는 로컬 애플리케이션, 서버 프로세스, 예약 작업, 빌드 시스템을 모두 찾으세요. 변경 후 설정을 갱신하고 새 연결로 테스트하세요. 오래 실행되는 프로세스도 새 값을 반영했는지 확인하세요. 일부는 다시 시작해야 합니다.

이전 비밀번호가 더 이상 작동해서는 안 된다면 이를 사용한 새 연결이 거부되는지 테스트하세요. 기존 연결에는 서비스 자체 규칙이 적용됩니다. 비밀번호 변경이 언제나 즉시 기존 연결을 닫는 것은 아닙니다. 긴급하게 권한을 취소하려면 제공업체가 지원하는 접근 비활성화 방식을 사용하세요.

결합 인증: IP와 비밀번호

결합 인증에서 프록시는 인증 정보와 애플리케이션이 연결을 보내는 출발지 주소 두 조건을 확인합니다. 둘 다 통과해야 합니다. 올바른 비밀번호만으로 IP 제한을 무효화하지는 않습니다.

ProxyCompass 고정 패키지의 결합 방식은 /24 서브넷을 사용합니다. 같은 서브넷에 여러 공인 IPv4 주소가 있다면 그중 하나만 허용 목록에 추가하면 됩니다. 같은 서브넷의 다른 주소도 주소마다 별도로 추가할 필요 없이 올바른 사용자 이름과 비밀번호로 접속할 수 있습니다.

그림에서 애플리케이션의 공인 IP는 허용 목록 주소와 앞의 숫자 세 개가 같습니다. 유효한 인증 정보로 연결할 수 있습니다. 서브넷 밖의 주소는 네트워크 검사에 실패하며, 안에 있어도 비밀번호가 틀리면 실패합니다. 같은 서브넷의 다른 클라이언트 IP도 이 항목을 사용할 수 있습니다. 사용자 이름과 비밀번호 필드가 필요한 애플리케이션에 유용합니다. 이 규칙은 구매한 프록시 출구 IP가 아니라 애플리케이션의 공인 IP에 관한 것입니다.