SOCKS5 프록시 인증 릴레이: 직접 구축할 것인가, 아니면 완전히 건너뛸 것인가
Chrome과 많은 자동화 도구는 여전히 SOCKS5 프록시를 인증할 수 없습니다. 작은 로컬 릴레이가 자격 증명을 보유함으로써 이를 해결합니다 — 여기에 최소한의 작동 가능한 릴레이, 준비된 도구들, 그리고 전혀 필요하지 않은 경우들이 있습니다.
SOCKS5 프록시 인증 릴레이는 프록시의 사용자 이름/비밀번호 도전을 대신 응답하고, 도구에 127.0.0.1에서 인증이 필요 없는 단순한 엔드포인트를 제공하는 작은 로컬 프로세스입니다. 이는 완고한 간극을 메우기 위해 존재합니다: Chromium은 인증된 SOCKS5를 지원한 적이 없으며 (Chromium 버그 40829748로 추적됨), 많은 자동화 도구는 단순한 host:port만을 수용합니다. Reddit의 한 스레드에서는 — 도구들이 여전히 인증된 SOCKS5를 처리할 수 없어서 작은 릴레이를 구축할 만큼 좌절한 사람이 있었는데 — 이 모든 장르를 한 문장으로 요약합니다. 이 가이드는 최소한의 작동 가능한 릴레이, 준비된 도구들, 그리고, 마찬가지로 중요한, 필요하지 않은 경우를 보여줍니다.
패턴: 앞에는 인증 없음, 뒤에는 인증
이 영역의 모든 릴레이는 동일한 작업을 수행합니다. 로컬에서 인증 없이 수신하고, 각 연결에 대해 실제 자격 증명을 사용하여 업스트림 단계를 엽니다. 도구는 127.0.0.1에 연결합니다 — 비밀번호가 필요하지 않습니다 — 그리고 릴레이는 SOCKS5 게이트웨이에 SOCKS5 인증 핸드셰이크를 수행합니다. 자격 증명은 루프백에 한 곳에 존재하며, 도구의 설정에 절대 닿지 않습니다. 이는 두 번째 이유로 중요합니다: SOCKS5는 암호화되지 않았으며 자격 증명을 평문으로 전송하므로, 인증된 단계를 자신의 기기에서 127.0.0.1에 바인딩하여 유지하는 것이 안전한 방법입니다.
단일 명령 릴레이: gost
릴레이를 직접 작성할 필요는 거의 없습니다. gost는 사용자 이름/비밀번호 인증을 포함한 전체 SOCKS5 사양을 구현하는 오픈 소스 터널링 도구로, 전체 작업을 단일 명령으로 전환합니다. 로컬에 인증 없는 SOCKS5 리스너를 노출하고 인증된 업스트림으로 포워딩합니다:
# local no-auth SOCKS5 on :1080 -> authenticated SOCKS5 upstream
gost -L socks5://:1080 -F socks5://USER:PASS@gate.quantumproxies.io:PORT
# now point any tool at the loopback address, no credentials:
# --proxy-server=socks5://127.0.0.1:1080 (Chrome, nodriver, zendriver)도구가 HTTP를 지원하지만 SOCKS5는 지원하지 않는 경우, 동일한 명령으로 프로토콜을 변환할 수 있습니다 — 인증된 SOCKS5 게이트웨이로 포워딩하는 로컬 HTTP 프록시를 노출합니다. 이는 반복되는 "SOCKS5를 HTTP 프록시로 변환" 질문에 대한 깔끔한 답변이며, gost가 업스트림 인증을 한 곳에서 처리하기 때문에 고전적인 Privoxy 설정보다 우수합니다:
# local HTTP proxy on :8080 -> authenticated SOCKS5 upstream
gost -L http://:8080 -F socks5://USER:PASS@gate.quantumproxies.io:PORT
# Chrome/curl/anything with an HTTP proxy setting can now use 127.0.0.1:8080
기초부터의 최소 릴레이
구성 요소를 이해하고 싶다면, 순수 Python으로 작성된 가장 작은 유용한 버전을 소개합니다. 이는 PySocks (pip install PySocks)를 사용하여 인증된 업스트림 단계를 열고 양방향으로 바이트를 터널링합니다. 이 특정 스케치는 하나의 대상 호스트를 터널링합니다 — 인증된 SOCKS5 출구를 통해 단일 API를 스크래핑하기에 충분하며, 이를 짧고 정확하게 유지합니다; 클라이언트 핸드셰이크를 구문 분석하는 일반적인 SOCKS5 서버는 gost와 같은 도구가 이미 수행하는 것입니다:
import asyncio, socks # PySocks
UP_HOST, UP_PORT = "gate.quantumproxies.io", 0000 # your SOCKS5 gateway
UP_USER, UP_PASS = "USER", "PASS"
TARGET = ("example.com", 443) # the one host to reach
async def pipe(reader, writer):
try:
while data := await reader.read(65536):
writer.write(data)
await writer.drain()
finally:
writer.close()
async def handle(local_r, local_w):
# open the upstream leg with SOCKS5 auth (PySocks is blocking -> a thread)
up = await asyncio.to_thread(
socks.create_connection, TARGET,
proxy_type=socks.SOCKS5, proxy_addr=UP_HOST, proxy_port=UP_PORT,
username=UP_USER, password=UP_PASS,
)
up_r, up_w = await asyncio.open_connection(sock=up)
await asyncio.gather(pipe(local_r, up_w), pipe(up_r, local_w))
async def main():
server = await asyncio.start_server(handle, "127.0.0.1", 1080)
async with server:
await server.serve_forever()
asyncio.run(main())모든 클라이언트가 가리킬 수 있는 전체 로컬 SOCKS5 서버의 경우, GitHub의 커뮤니티 socks-relay 프로젝트가 좋은 참고 자료입니다: 이는 인증 없음 또는 사용자/비밀번호 리스너를 실행하고 다른 SOCKS5 서버로 릴레이하며, PySocks를 기반으로 수백 줄로 구성됩니다. socks-to-http-proxy 프로젝트 (Rust)는 컴파일된 바이너리를 선호하는 경우 HTTP 변환 작업을 수행합니다. 어느 쪽이든, gost가 한 줄로 제공하는 동일한 패턴을 실행하고 있는 것입니다.
릴레이가 필요하지 않은 경우
릴레이는 소유한 홉이며, 종종 전체 문제를 삭제할 수 있습니다. 다음 중 하나가 참인 경우 건너뛰십시오:
- 제공자가 HTTP 엔드포인트를 제공합니다. HTTP 프록시는 URL에서 기본 인증으로 인증하며, 거의 모든 도구가 이를 처리합니다. HTTP 게이트웨이를 가리키면 SOCKS5 인증 문제는 사라집니다 — 트레이드오프는 SOCKS5 대 HTTP에서 다루어집니다.
- IP 화이트리스트가 가능합니다. 제공자에게 이그레스 IP를 등록하면 릴레이할 자격 증명이 전혀 없습니다. 모든 QuantumProxies 플랜은 사용자:비밀번호와 함께 주거용 프록시에서 화이트리스트를 지원합니다 — IP가 안정적일 때 가장 간단한 해결책입니다.
- 라이브러리가 이미 SOCKS5 인증을 수행합니다. curl, Python
requests[socks]및httpx, 그리고 대부분의 HTTP 클라이언트는 인증된 SOCKS5를 네이티브로 지원합니다. 릴레이는 주로 Chromium 기반 브라우저와 같이 이를 수행할 수 없는 도구를 위한 것입니다.
# no relay needed — curl authenticates SOCKS5 directly (socks5h resolves DNS
# through the proxy, avoiding leaks):
curl -x socks5h://USER:PASS@gate.quantumproxies.io:PORT https://httpbin.org/ip
# and HTTP Basic proxy auth is even more widely supported:
curl -x http://USER:PASS@gate.quantumproxies.io:PORT https://httpbin.org/ip
솔직한 단점
자신의 릴레이를 실행하면 실패 지점이 추가됩니다. 이는 감독해야 할 또 다른 프로세스입니다: 충돌하면 그 뒤의 모든 요청이 실패하며, 기본 스크립트는 재시작, 상태 검사 및 로깅을 제공하지 않으므로 이를 추가해야 합니다. 자체 회전이 없으며, 구성한 단일 업스트림으로 포워딩하므로 출구 회전은 여전히 게이트웨이에서 나와야 합니다. 지연 홉이 추가되며, 평문 자격 증명을 메모리에 보유하므로, 이는 반드시 127.0.0.1에 바인딩되어야 하며, 공개 인터페이스에는 절대 바인딩되지 않아야 합니다. 한 사이트를 스크래핑하는 노트북에는 괜찮습니다. 페이지를 넘기는 모든 것에는 새로운 이동 부품이 없는 해결책 — 화이트리스트 또는 HTTP 엔드포인트 — 을 선호하십시오.
동일한 릴레이 패턴은 스텔스 생태계 전반에 걸쳐 나타납니다, 왜냐하면 Chromium의 SOCKS5 간극은 이를 기반으로 하는 모든 브라우저에 공유되기 때문입니다. 특정 프레임워크에 이를 연결하려면, Playwright SOCKS5 인증 및 407 문제 해결 가이드를 참조하여 진행 중에 발생할 오류를 확인하십시오.
자주 묻는 질문
SOCKS5 프록시 인증 릴레이란 무엇인가요?
인증 없이 수신하고 각 연결을 사용자 이름과 비밀번호를 사용하여 업스트림 SOCKS5 프록시로 포워딩하는 작은 로컬 프로세스입니다. SOCKS5 자격 증명을 보낼 수 없는 도구들 — 주로 Chromium 기반 브라우저 — 이 127.0.0.1:1080와 같은 루프백 주소를 가리켜 인증된 프록시에 도달할 수 있게 해줍니다. gost는 단일 명령으로 이를 생성합니다.
SOCKS5 프록시를 HTTP 프록시로 어떻게 변환하나요?
프록시 자체를 변환할 수는 없습니다; 로컬에서 HTTP를 지원하고 업스트림에서 SOCKS5를 지원하는 중개자를 실행해야 합니다. gost -L http://:8080 -F socks5://USER:PASS@host:port는 인증된 SOCKS5 게이트웨이로 포워딩하는 로컬 HTTP 프록시를 노출합니다. socks-to-http-proxy 및 Privoxy와 같은 전용 도구들도 동일한 작업을 수행합니다.
Chrome은 왜 인증된 SOCKS5 프록시를 사용할 수 없나요?
Chromium은 SOCKS5 사용자 이름/비밀번호 인증을 구현한 적이 없습니다 — 이는 Chromium 버그 40829748로 기록된 오래된 제한 사항입니다. 인증되지 않은 SOCKS5는 --proxy-server=socks5://host:port를 통해 작동하지만, 자격 증명을 제공할 방법이 없습니다. 로컬 릴레이 또는 IP 화이트리스트가 표준 해결책이며, 프록시 인증 확장은 HTTP 프록시를 다룹니다.
릴레이에 SOCKS5 자격 증명을 보내는 것이 안전한가요?
루프백을 통해서만 가능합니다. SOCKS5는 암호화되지 않았으며 자격 증명을 평문으로 전송하므로, 릴레이는 127.0.0.1에 바인딩되어야 하며, 절대 공개 인터페이스에 바인딩되어서는 안 됩니다 — 이는 인증된 단계를 자신의 기기에 유지합니다. 대상에 대한 암호화된 터널은 HTTPS에 대해 종단 간으로 설정되므로, 릴레이는 읽을 수 없는 TLS 바이트만을 볼 수 있습니다.
도구가 다른 선택지를 제공하지 않을 때만 릴레이를 사용하십시오. gost는 단일 명령의 답변이며, PySocks는 기초부터의 답변입니다 — 하지만 대부분의 사람들에게 가장 빠른 해결책은 IP를 화이트리스트에 등록하거나 HTTP 엔드포인트를 사용하여 추가 작업을 실행하지 않는 것입니다. 이동 부품이 적을수록, 새벽 3시의 호출도 적습니다.