프록시는 다섯 가지 정보로 이루어집니다: 스킴, 사용자 이름, 비밀번호, 호스트, 포트. 제공업체, 도구, 포럼마다 이 요소들을 서로 다른 순서로 배치하며, 한 도구에서 작동하는 프록시가 다른 도구에서는 단지 형식이 맞지 않아 실패하는 경우가 있습니다. 이 가이드는 일반적인 배치 방식, 어떤 도구가 어떤 형식을 기대하는지, 그리고 레지덴셜 프록시에서 가장 자주 발견되는 실수를 피하는 방법을 다룹니다.
다섯 가지 일반적인 배치 방식
여기 저희 대시보드의 Proxy Generator가 생성할 수 있는 다섯 가지 형식으로 표현된 동일한 Shifter 프록시가 있습니다. 사용자 이름에는 타겟팅 정보와 세션 정보가 포함되므로 예상보다 길 수 있습니다.
| 형식 | 예시 |
|---|---|
scheme://user:pass@host:port | http://customer-USERNAME-sid-a1-ttl-60:PASSWORD@p.shifter.io:443 |
user:pass@host:port | customer-USERNAME-sid-a1-ttl-60:PASSWORD@p.shifter.io:443 |
host:port:user:pass | p.shifter.io:443:customer-USERNAME-sid-a1-ttl-60:PASSWORD |
user:pass:host:port | customer-USERNAME-sid-a1-ttl-60:PASSWORD:p.shifter.io:443 |
host:port@user:pass | p.shifter.io:443@customer-USERNAME-sid-a1-ttl-60:PASSWORD |
첫 번째 형식은 웹 표준으로 정의된 실제 URL이며, 도구가 이를 지원한다면 가장 안전한 선택입니다. 나머지는 관례입니다. 많은 대량 처리 도구가 한 줄에 프록시 하나씩 들어있는 일반 텍스트 목록을 가져오기 때문에 존재하며, 각 도구가 자체적인 순서를 선택한 것입니다.
어떤 도구가 어떤 형식을 기대하는가
curl. URL 형식을 -x에 전달하십시오. 스킴을 생략하면 curl은 http://를 가정합니다. -U username:password로 자격 증명을 별도로 유지할 수도 있으며, 이는 인코딩 문제를 피하게 해줍니다. 저희의 curl 및 Postman 설정 가이드에 전체 예시가 있습니다.
Python requests 및 Scrapy. 둘 다 URL 형식을 사용합니다. requests에서는 딕셔너리 키가 웹사이트의 스킴을 가리키고, 값이 프록시를 가리키므로, 보통 두 값 모두 http:// 프록시를 가리킵니다:
proxy = "http://customer-USERNAME:PASSWORD@p.shifter.io:443"
proxies = {"http": proxy, "https": proxy}Playwright. 각 요소를 별도의 필드로 받습니다: 스킴, 호스트, 포트가 포함된 server, 그리고 username과 password. 직접 분리해서 전달하면 모든 인코딩 문제를 피할 수 있습니다.
Puppeteer 및 Chrome. --proxy-server 플래그는 호스트와 포트만 받습니다. 자격 증명은 page.authenticate()를 통해 전달됩니다.
브라우저 프로필 관리자 및 대량 처리 도구. 많은 도구가 host:port:user:pass 형식으로 목록을 가져오며, 일부는 목록이 어떤 순서를 사용하는지 묻습니다. 수백 줄을 붙여넣기 전에 가져오기 화면을 확인하십시오.
스킴은 웹사이트가 아니라 프록시를 나타낸다
이것이 저희가 가장 자주 보는 실수입니다. HTTPS 웹사이트를 스크래핑하는 고객이 프록시 앞에 https://를 쓰면, 모든 요청이 TLS 오류로 실패합니다.
스킴은 클라이언트에게 프록시와 어떻게 통신할지 알려줍니다. HTTPS 웹사이트는 CONNECT 메서드를 사용하는 http:// 프록시를 통해 접속됩니다: 클라이언트가 프록시에게 터널을 열도록 요청한 다음, 그 터널을 통해 웹사이트와 TLS를 실행합니다. 웹사이트로의 연결은 여전히 종단 간 암호화됩니다. https://p.shifter.io:443라고 쓰면 클라이언트는 게이트웨이 자체와 TLS를 시작하려 하는데, 저희 게이트웨이는 이를 제공하지 않으므로 핸드셰이크가 실패합니다. HTTP와 HTTPS 사이트 모두에 http://를 사용하거나, 도구가 SOCKS를 선호한다면 socks5://를 사용하십시오.
SOCKS의 경우 두 번째 선택지가 있습니다. socks5://는 웹사이트의 이름을 사용자 머신에서 확인하는 반면, socks5h://는 이름을 프록시로 보내 확인합니다. DNS 조회가 어디에서 이루어지는지 신경 쓰인다면 저희의 DNS 유출 방지 가이드를 참고하십시오.
특수 문자는 형식을 깨뜨린다
각 형식은 일부 문자를 예약어로 사용합니다.
- URL 형식: 사용자 이름이나 비밀번호 안의
@,:,/,#,?,%는 퍼센트 인코딩되어야 합니다.p@ss:word같은 비밀번호는p%40ss%3Aword가 됩니다. - 콜론으로 구분된 형식: 비밀번호 안의 콜론은 그 뒤의 모든 필드를 밀어내므로, 도구가 호스트나 포트를 잘못 읽게 됩니다.
Shifter 사용자 이름의 타겟팅과 세션 부분은 문자, 숫자, 대시, 밑줄만 사용합니다. 예를 들어 city-new_york와 같이요. 따라서 모든 형식에서 안전합니다. 기호가 포함된 비밀번호를 설정한다면, 인코딩을 사용하는 URL 형식이나 필드를 분리하는 도구가 신뢰할 수 있는 방법입니다.
형식 간 변환
한 도구가 한 가지 형식을 제공하고 코드가 다른 형식을 원할 때는, 줄을 손으로 편집하는 대신 목록을 변환하십시오. 이 Python 함수는 다섯 가지 배치 방식 중 어느 것이든 URL 형식으로 바꾸고 자격 증명을 인코딩합니다:
from urllib.parse import quote
def to_proxy_url(line: str, scheme: str = "http") -> str:
line = line.strip()
if "://" in line:
return line
if "@" in line:
left, right = line.split("@", 1)
if left.rsplit(":", 1)[-1].isdigit():
hostport, creds = left, right # host:port@user:pass
else:
creds, hostport = left, right # user:pass@host:port
user, password = creds.split(":", 1)
host, port = hostport.rsplit(":", 1)
else:
parts = line.split(":")
if len(parts) != 4:
raise ValueError(f"unrecognised proxy line: {line}")
if parts[1].isdigit():
host, port, user, password = parts # host:port:user:pass
else:
user, password, host, port = parts # user:pass:host:port
return f"{scheme}://{quote(user, safe='')}:{quote(password, safe='')}@{host}:{port}"
print(to_proxy_url("p.shifter.io:443:customer-USERNAME:PASSWORD"))
# http://customer-USERNAME:PASSWORD@p.shifter.io:443이 함수는 포트 번호를 찾아 순서를 판단하므로, 사용자 이름이나 비밀번호가 모두 숫자로만 이루어진 경우에는 배치 방식을 구분할 수 없습니다. 이런 경우에는 목록을 준 쪽에 어떤 순서를 사용하는지 물어보십시오.
ISP 프록시도 같은 형식을 사용한다
ISP 프록시도 호스트만 다를 뿐 같은 규칙을 따릅니다. 모든 ISP 프록시는 isp.shifter.io:443를 통해 연결되므로, host:port:user:pass 형식의 줄은 isp.shifter.io:443:USERNAME:PASSWORD로 표시됩니다. 각 프록시는 프록시별로 분리된 IP와 포트가 아니라 사용자 이름으로 구분되며, 이는 ip:port:user:pass 형식의 목록에 익숙한 사람들에게는 의외로 느껴질 수 있습니다.
프록시가 연결되지 않을 때 빠르게 확인할 사항
- 407 Proxy Authentication Required: 프록시에는 도달했지만 자격 증명이 받아들여지지 않았습니다. 사용자 이름과 비밀번호가 누락되었거나 바뀌지 않았는지, 혹은 인코딩되지 않은 기호가 있는지 확인하십시오. 저희의 407 문제 해결 가이드에서 나머지를 다룹니다.
- 즉시 발생하는 TLS 또는 핸드셰이크 오류: 프록시 앞에
https://를 썼을 가능성이 높습니다.http://로 변경하십시오. - 모든 요청에서 연결 거부 또는 타임아웃 발생: 호스트나 포트가 잘못되었을 가능성이 있으며, 콜론으로 구분된 줄이 잘못된 순서로 읽힌 경우가 많습니다.
- curl에서는 작동하지만 사용하는 도구에서는 실패: 해당 도구가 다른 배치 방식을 기대하는 것입니다. 줄을 변환하거나 필드를 별도로 입력하십시오.
대시보드에서는 Proxy Generator를 통해 복사하기 전에 프로토콜과 형식을 선택할 수 있으며, 전체 목록을 같은 형식의 CSV로 다운로드할 수도 있습니다. 처음부터 올바른 형식을 선택하면 이러한 오류 대부분을 피할 수 있습니다.
출처 및 참고자료
- RFC 3986, Uniform Resource Identifier: Generic Syntax: rfc-editor.org
- curl, the —proxy option: curl.se
- Requests, proxies: requests.readthedocs.io
- Playwright, HTTP proxy: playwright.dev