# SOCKS5 프록시 인증 릴레이: 직접 구축할 것인가, 아니면 완전히 건너뛸 것인가

Chrome과 많은 자동화 도구는 여전히 SOCKS5 프록시를 인증할 수 없습니다. 작은 로컬 릴레이가 자격 증명을 보유함으로써 이를 해결합니다 — 여기에 최소한의 작동 가능한 릴레이, 준비된 도구들, 그리고 전혀 필요하지 않은 경우들이 있습니다.

**SOCKS5 프록시 인증 릴레이**는 프록시의 사용자 이름/비밀번호 도전을 대신 응답하고, 도구에 `127.0.0.1`에서 인증이 필요 없는 단순한 엔드포인트를 제공하는 작은 로컬 프로세스입니다. 이는 완고한 간극을 메우기 위해 존재합니다: Chromium은 인증된 SOCKS5를 지원한 적이 없으며 (Chromium 버그 40829748로 추적됨), 많은 자동화 도구는 단순한 `host:port`만을 수용합니다. Reddit의 한 스레드에서는 — 도구들이 여전히 인증된 SOCKS5를 처리할 수 없어서 작은 릴레이를 구축할 만큼 좌절한 사람이 있었는데 — 이 모든 장르를 한 문장으로 요약합니다. 이 가이드는 최소한의 작동 가능한 릴레이, 준비된 도구들, 그리고, 마찬가지로 중요한, 필요하지 않은 경우를 보여줍니다.

## 패턴: 앞에는 인증 없음, 뒤에는 인증

이 영역의 모든 릴레이는 동일한 작업을 수행합니다. 로컬에서 인증 없이 수신하고, 각 연결에 대해 실제 자격 증명을 사용하여 업스트림 단계를 엽니다. 도구는 `127.0.0.1`에 연결합니다 — 비밀번호가 필요하지 않습니다 — 그리고 릴레이는 [SOCKS5 게이트웨이](https://quantumproxies.io/socks5-proxies)에 SOCKS5 인증 핸드셰이크를 수행합니다. 자격 증명은 루프백에 한 곳에 존재하며, 도구의 설정에 절대 닿지 않습니다. 이는 두 번째 이유로 중요합니다: SOCKS5는 암호화되지 않았으며 자격 증명을 평문으로 전송하므로, 인증된 단계를 자신의 기기에서 `127.0.0.1`에 바인딩하여 유지하는 것이 안전한 방법입니다.

## 단일 명령 릴레이: gost

릴레이를 직접 작성할 필요는 거의 없습니다. `gost`는 사용자 이름/비밀번호 인증을 포함한 전체 SOCKS5 사양을 구현하는 오픈 소스 터널링 도구로, 전체 작업을 단일 명령으로 전환합니다. 로컬에 인증 없는 SOCKS5 리스너를 노출하고 인증된 업스트림으로 포워딩합니다:

```bash
# local no-auth SOCKS5 on :1080  ->  authenticated SOCKS5 upstream
gost -L socks5://:1080 -F socks5://USER:PASS@residentialpremium.quantumproxies.io:1080

# 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 설정보다 우수합니다:

```bash
# local HTTP proxy on :8080  ->  authenticated SOCKS5 upstream
gost -L http://:8080 -F socks5://USER:PASS@residentialpremium.quantumproxies.io:1080

# Chrome/curl/anything with an HTTP proxy setting can now use 127.0.0.1:8080
```

![세 홉으로 구성된 로컬 SOCKS5 인증 릴레이: 도구가 127.0.0.1:1080의 인증 없는 리스너에 연결하고, 릴레이가 사용자 이름과 비밀번호를 추가하며, 인증된 게이트웨이가 SOCKS5 핸드셰이크를 받습니다. 카드는 자격 증명이 어디에 있는지 보여줍니다: 루프백에 바인딩된 릴레이 안에만 있습니다.](https://res.cloudinary.com/dmqliab0t/image/upload/f_auto,q_auto,w_1200/v1785776557/blog/generated/qp-b10-035-diag1.png)
*릴레이는 루프백에 자격 증명을 보유하고 SOCKS5 인증 핸드셰이크를 수행하므로, 도구는 인증이 필요 없는 엔드포인트만을 볼 수 있습니다.*

## 기초부터의 최소 릴레이

구성 요소를 이해하고 싶다면, 순수 Python으로 작성된 가장 작은 유용한 버전을 소개합니다. 이는 PySocks (`pip install PySocks`)를 사용하여 인증된 업스트림 단계를 열고 양방향으로 바이트를 터널링합니다. 이 특정 스케치는 하나의 대상 호스트를 터널링합니다 — 인증된 SOCKS5 출구를 통해 단일 API를 스크래핑하기에 충분하며, 이를 짧고 정확하게 유지합니다; 클라이언트 핸드셰이크를 구문 분석하는 일반적인 SOCKS5 서버는 gost와 같은 도구가 이미 수행하는 것입니다:

```python
import asyncio, socks   # PySocks

UP_HOST, UP_PORT = "residentialpremium.quantumproxies.io", 1080   # 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](https://quantumproxies.io/blog/socks5-vs-http-proxy-difference)에서 다루어집니다.
- **IP 화이트리스트가 가능합니다.** 제공자에게 이그레스 IP를 등록하면 릴레이할 자격 증명이 전혀 없습니다. 모든 QuantumProxies 플랜은 사용자:비밀번호와 함께 [주거용 프록시](https://quantumproxies.io/residential-proxies)에서 화이트리스트를 지원합니다 — IP가 안정적일 때 가장 간단한 해결책입니다.
- **라이브러리가 이미 SOCKS5 인증을 수행합니다.** curl, Python `requests[socks]` 및 `httpx`, 그리고 대부분의 HTTP 클라이언트는 인증된 SOCKS5를 네이티브로 지원합니다. 릴레이는 주로 Chromium 기반 브라우저와 같이 이를 수행할 수 없는 도구를 위한 것입니다.

```bash
# no relay needed — curl authenticates SOCKS5 directly (socks5h resolves DNS
# through the proxy, avoiding leaks):
curl -x socks5h://USER:PASS@residentialpremium.quantumproxies.io:1080 https://httpbin.org/ip

# and HTTP Basic proxy auth is even more widely supported:
curl -x http://USER:PASS@residentialpremium.quantumproxies.io:8080 https://httpbin.org/ip
```

![SOCKS5 인증 릴레이가 필요 없는 경우와 제 역할을 하는 경우: curl, Python requests, httpx는 SOCKS5 인증을 기본 지원하지만, Chromium 기반 브라우저는 SOCKS5 자격 증명을 보낼 수 없습니다. 카드에는 릴레이를 없애는 방법이 나열되어 있습니다: HTTP 엔드포인트, IP 화이트리스트, 또는 SOCKS5 인증을 기본 지원하는 클라이언트.](https://res.cloudinary.com/dmqliab0t/image/upload/f_auto,q_auto,w_1200/v1785776556/blog/generated/qp-b10-035-diag2.png)
*대부분의 설정은 릴레이를 건너뛸 수 있습니다: HTTP 엔드포인트, IP 화이트리스트 또는 SOCKS5 인증을 네이티브로 지원하는 클라이언트는 릴레이의 필요성을 제거합니다.*

## 솔직한 단점

자신의 릴레이를 실행하면 실패 지점이 추가됩니다. 이는 감독해야 할 또 다른 프로세스입니다: 충돌하면 그 뒤의 모든 요청이 실패하며, 기본 스크립트는 재시작, 상태 검사 및 로깅을 제공하지 않으므로 이를 추가해야 합니다. 자체 회전이 없으며, 구성한 단일 업스트림으로 포워딩하므로 출구 회전은 여전히 게이트웨이에서 나와야 합니다. 지연 홉이 추가되며, 평문 자격 증명을 메모리에 보유하므로, 이는 반드시 `127.0.0.1`에 바인딩되어야 하며, 공개 인터페이스에는 절대 바인딩되지 않아야 합니다. 한 사이트를 스크래핑하는 노트북에는 괜찮습니다. 페이지를 넘기는 모든 것에는 새로운 이동 부품이 없는 해결책 — 화이트리스트 또는 HTTP 엔드포인트 — 을 선호하십시오.

동일한 릴레이 패턴은 스텔스 생태계 전반에 걸쳐 나타납니다, 왜냐하면 Chromium의 SOCKS5 간극은 이를 기반으로 하는 모든 브라우저에 공유되기 때문입니다. 특정 프레임워크에 이를 연결하려면, [Playwright SOCKS5 인증](https://quantumproxies.io/blog/playwright-socks5-proxy-authentication) 및 [407 문제 해결 가이드](https://quantumproxies.io/blog/fix-407-proxy-authentication-required)를 참조하여 진행 중에 발생할 오류를 확인하십시오.

## 자주 묻는 질문

### 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시의 호출도 적습니다.

[IP 화이트리스트를 사용하는 SOCKS5 프록시 얻기](https://quantumproxies.io/socks5-proxies)