v2rayN 시스템 프록시가 작동하지 않을 때: 브라우저와 명령줄 프록시 문제 해결

브라우저와 터미널은 프록시 설정을 읽는 방식이 다릅니다. 확장 프로그램 충돌, PAC 모드, 환경 변수, 로컬 포트를 차례로 확인하세요.

이 글의 핵심 내용

이 글에서는 Windows용 v2rayN을 기준으로, 시스템 프록시를 설정했는데도 브라우저나 터미널에서 접속되지 않는 문제를 살펴봅니다. 먼저 프록시를 명시한 요청으로 로컬 진입점을 확인한 뒤, 브라우저 확장 프로그램과 자동 구성 스크립트, 터미널 환경 변수를 점검합니다. 문제 원인을 앱의 프록시 설정, 로컬 포트 수신, 코어의 아웃바운드 또는 라우팅 규칙으로 좁혀 노드를 반복해서 바꾸지 않도록 안내합니다.

1. 시스템 프록시, 라우팅, TUN의 차이

v2rayN의 시스템 프록시는 운영체제에 프록시 설정을 적용하는 기능이며, 모든 네트워크 연결을 가로채는 것은 아닙니다. 앱이 해당 설정을 읽어야 요청이 로컬 프록시 포트로 전달됩니다. 브라우저는 대체로 시스템 프록시를 지원하지만, 명령줄 도구가 시스템 프록시나 환경 변수, 자체 설정 파일을 읽는지는 도구마다 다릅니다.

문제를 확인할 때는 먼저 TUN 모드를 끄세요. 가상 네트워크 어댑터가 트래픽을 가로채면 시스템 프록시 문제를 파악하기 어려울 수 있습니다. 다른 터널 프로그램이나 기업 네트워크 소프트웨어를 사용 중이라면 현재 상태를 기록하고 설정을 바로 삭제하지 마세요. 이 글에 나오는 포트는 테스트용 예시이므로, 현재 v2rayN에 표시된 실제 수신 포트로 바꿔 사용하세요.

설정 계층실제 기능이 설정만으로는 확인할 수 없는 점
시스템 프록시시스템 설정을 따르는 앱에 사용할 프록시 진입점을 지정모든 터미널과 백그라운드 프로그램이 프록시를 사용한다는 것
로컬 인바운드루프백 주소의 지정된 포트에서 HTTP 또는 SOCKS 요청 수신원격 서버에 연결되었다는 것
코어 라우팅수신한 요청을 직접 연결, 프록시 또는 차단 중 하나로 전달수신한 모든 요청이 원격 프록시를 통한다는 것
TUN 모드가상 네트워크 어댑터를 통해 지정된 네트워크 트래픽을 가로챔앱이 시스템 프록시 설정을 제대로 읽는다는 것

2. 로컬 포트를 확인하고 프록시를 명시해 테스트

먼저 v2rayN의 「설정」→「매개변수 설정」에서 로컬 수신 설정을 확인하고, 메인 화면 하단의 포트 정보를 살펴보세요. 버전에 따라 HTTP 포트와 SOCKS 포트가 따로 있거나 혼합 포트를 제공할 수 있으며, 메뉴 이름과 배치도 다를 수 있습니다. 혼합 포트는 지원되는 프로토콜을 모두 받을 수 있지만, SOCKS 전용 포트는 HTTP 프록시로 사용할 수 없습니다.

10808
아래 예시의 혼합 수신 포트
10809
일부 설정에서 사용하는 별도 HTTP 포트 예시

두 숫자는 모든 버전의 고정 기본값이 아니며, 두 포트를 모두 열어야 하는 것도 아닙니다. 다음 명령은 PowerShell에서 실행하며, 127.0.0.1:10808이 HTTP와 SOCKS를 모두 지원한다고 확인한 경우를 가정합니다. 일부 Windows PowerShell 환경에서는 curl이 별칭으로 동작해 매개변수 처리에 차이가 생길 수 있으므로 curl.exe를 사용하세요.

# TCP 포트에서 연결을 수락하는지 확인
Test-NetConnection 127.0.0.1 -Port 10808

# 수신 프로세스를 확인하고 현재 코어 프로세스인지 점검
Get-NetTCPConnection -State Listen -LocalPort 10808 |
  Select-Object LocalAddress, LocalPort, OwningProcess

# HTTP 프록시를 명시하고 제외 목록에는 로컬 주소만 지정
curl.exe --proxy http://127.0.0.1:10808 --noproxy "localhost,127.0.0.1" --connect-timeout 10 --max-time 20 -I https://example.com

# SOCKS를 명시하고 대상 도메인의 DNS 조회를 프록시에 맡김
curl.exe --proxy socks5h://127.0.0.1:10808 --noproxy "localhost,127.0.0.1" --connect-timeout 10 --max-time 20 -I https://example.com

TcpTestSucceeded : True는 TCP 포트에 연결할 수 있다는 뜻일 뿐입니다. HTTP 프록시 테스트에서 200 Connection established가 표시되어도 CONNECT 터널을 만들 수 있다는 의미일 뿐이므로, 이후 TLS 처리와 대상 사이트의 응답을 계속 확인해야 합니다. 대상에서 403이나 405를 반환하더라도 대상 사이트, 프록시 서비스, 중간 네트워크 장비 중 어디에서 보낸 응답인지 먼저 확인하세요. 상태 코드만으로 시스템 프록시의 실패 여부를 판단할 수 없습니다.

정리: 프록시를 명시한 요청이 성공하면 앱 설정을 확인하세요

HTTP 프록시를 명시한 요청은 대상 응답을 받는데 일반 브라우저에서 접속이 안 된다면, 브라우저가 다른 진입점을 사용하는지 먼저 확인하세요. 이때 구독 설정이나 전송 프로토콜, 원격 포트부터 바꾸지 마세요.

3. 브라우저에서 프록시가 작동하지 않을 때: 확장 프로그램과 별도 설정 확인

브라우저 확장 프로그램이 시스템 프록시 설정을 덮어쓸 수 있습니다. 한 창에서는 접속되는데 다른 창에서는 안 된다면 노드 탓으로 돌리기 전에 브라우저 프로필과 확장 프로그램 상태를 비교하세요. 시크릿 창도 확장 프로그램이 없는 확실한 테스트 환경은 아닙니다. 시크릿 창에서 실행하도록 허용된 확장 프로그램은 계속 작동할 수 있습니다.

  1. 시스템 프록시 사용

    Windows용 v2rayN 메인 화면 하단의 「시스템 프록시」 메뉴에서 「시스템 프록시 자동 설정」을 선택하세요. 이 항목은 클라이언트가 시스템 프록시를 설정하는 기능이며, PAC 스크립트 모드를 뜻하는 것은 아닙니다.

  2. 시스템 프록시 진입점 확인

    Windows 「설정」→「네트워크 및 인터넷」→「프록시」를 열어 수동 프록시의 주소와 포트를 확인하세요. 루프백 주소는 이 컴퓨터를 가리켜야 하며, 포트는 앞에서 연결에 성공한 HTTP 또는 혼합 진입점과 일치해야 합니다.

  3. 프록시 확장 프로그램 끄기

    Chrome의 「확장 프로그램」→「확장 프로그램 관리」에서 프록시를 제어하는 확장 프로그램을 잠시 사용 중지하세요. Edge에서는 「확장」→「확장 관리」에서 설정할 수 있습니다. 그런 다음 브라우저 관련 프로세스를 종료하고 다시 실행한 뒤 같은 테스트 주소에 접속하세요.

  4. 브라우저 자체 설정 확인

    Firefox에서는 「설정」→「일반」→「네트워크 설정」→「설정」에서 「시스템 프록시 설정 사용」을 선택할 수 있습니다. 수동 프록시를 선택했다면 해당 포트를 확인하세요. Windows 설정이 바뀌어도 Firefox의 값이 자동으로 갱신된다고 가정하면 안 됩니다.

시스템 프록시 주소를 설정한 직후 값이 바뀐다면 다른 프로그램이나 조직 정책이 관리 중일 수 있습니다. 중복 실행 중인 프록시 프로그램을 종료한 뒤 다시 확인하세요. 관리 대상 기기라면 관리자에게 정책을 문의해야 합니다. 이 컴퓨터의 브라우저를 프록시에 연결할 때 수신 주소를 0.0.0.0으로 바꿀 필요는 없으며, 방화벽 전체를 끄는 것도 우선적으로 시도할 방법이 아닙니다.

4. PAC 모드: 스크립트 주소와 반환값 확인

PAC는 자동 프록시 구성 스크립트입니다. 브라우저는 스크립트의 FindProxyForURL(url, host)을 호출해 반환값에 따라 프록시를 사용할지 직접 연결할지 결정합니다. PAC 규칙은 v2rayN 코어의 routing.rules와 다른 계층에 적용됩니다. PAC 설정 때문에 요청이 코어에 도달하지 않을 수 있지만, 코어 라우팅은 로컬 인바운드에 도착한 요청만 처리할 수 있습니다.

5. 터미널에서 프록시가 작동하지 않을 때: 환경 변수와 도구 설정 확인

브라우저에서는 되지만 터미널에서는 안 되는 문제는 프록시 설정 출처가 달라 흔히 발생합니다. 많은 명령줄 도구는 Windows 사용자 프록시 설정을 자동으로 읽지 않으며, 일부 도구는 자체 설정 파일을 사용합니다. 먼저 2절의 프록시 지정 명령으로 테스트한 뒤 현재 터미널 세션에 환경 변수를 설정할지 결정하세요. 전역 환경 변수부터 수정하지 마세요.

# 현재 PowerShell 프로세스가 상속한 프록시 환경 변수 확인
Get-ChildItem Env: |
  Where-Object { $_.Name -match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$' }

# 현재 세션과 이후 시작되는 하위 프로세스에 사용할 프록시 설정
$env:http_proxy = "http://127.0.0.1:10808"
$env:https_proxy = "http://127.0.0.1:10808"
$env:no_proxy = "localhost,127.0.0.1,::1"

# --proxy를 지정하지 않고 curl.exe가 현재 환경 변수를 읽는지 확인
curl.exe --connect-timeout 10 --max-time 20 -I https://example.com

https_proxy라는 이름은 HTTPS 대상에 사용할 프록시를 의미합니다. 값에는 여전히 http://를 사용할 수 있으며, HTTP CONNECT로 터널을 설정합니다. 대상이 HTTPS라는 이유만으로 로컬 진입점을 https://로 바꾸지 마세요. 환경 변수 지원 여부와 지원하는 변수 이름은 도구별 문서를 확인해야 합니다. curl은 HTTP 프록시 변수의 대소문자를 특별하게 처리하므로 여러 플랫폼에서 사용하는 스크립트에는 소문자 http_proxy를 권장합니다.

확인 항목자주 발생하는 문제해결 방법
NO_PROXY대상 도메인이나 *가 포함되어 프록시를 우회함테스트 세션에서는 필요한 로컬 주소만 남긴 뒤 다시 시도
ALL_PROXY이전 SOCKS 포트를 가리킴프로토콜과 포트를 확인하고 여러 변수가 서로 다른 진입점을 가리키지 않도록 설정
터미널 프로세스시스템 변수를 변경하기 전에 이미 실행됨터미널과 이를 실행한 프로그램을 다시 시작하거나 현재 세션에 직접 값을 설정
도구 설정 파일도구 자체의 프록시 옵션이 예상한 설정을 덮어씀도구에 적용된 설정을 확인하고 명시적 매개변수로 비교 테스트

WSL, 컨테이너, 원격 터미널은 각각 별도의 네트워크 환경을 사용합니다. 해당 환경의 127.0.0.1이 Windows의 수신 포트를 가리키지 않을 수 있으므로, 여기서 접속에 실패해도 Windows 시스템 프록시 문제라고 단정할 수 없습니다. 먼저 Windows에서 기본 테스트를 마친 뒤 가상 네트워크와 호스트 주소를 따로 확인하세요. 이 문제를 해결하려고 모든 네트워크 인터페이스에 프록시 포트를 개방하지 마세요.

위 설정은 현재 PowerShell 세션과 이후 실행되는 하위 프로세스에만 적용됩니다. 세션을 닫으면 임시 설정도 끝납니다. 기존 세션에서 이미 프록시 변수를 사용 중이라면 원래 값을 기록하고 테스트가 끝난 뒤 복원하세요.

6. 오류 메시지와 로그로 남은 문제 찾기

프록시를 명시해도 실패한다면 「로컬 수신 → 프로토콜 일치 여부 → 원격 연결 → 대상 응답」 순서로 확인하세요. 다음은 curl에서 볼 수 있는 오류 일부이며, 문구는 버전과 운영체제에 따라 달라질 수 있습니다. 오류 코드는 문제 범위를 좁히는 데 도움이 되지만, 하나의 오류만으로 원인을 단정하기는 어렵습니다.

curl: (7) Failed to connect to 127.0.0.1 port 10808

원인: 로컬 TCP 연결이 성립되지 않았습니다. 코어가 실행되지 않았거나 포트가 잘못 입력되었거나 로컬 연결이 차단된 경우가 흔합니다.

해결 방법: 포트 수신 상태로 돌아가 수신 프로세스를 확인한 뒤 v2rayN의 코어 시작 로그를 살펴보세요. 원격 프로토콜부터 변경하지 마세요.

curl: (5) Could not resolve proxy

원인: 프록시 주소의 호스트 이름을 확인할 수 없거나 프록시 변수 값의 형식이 잘못되었을 수 있습니다.

해결 방법: 로컬 테스트에서는 http://127.0.0.1:10808을 명시적으로 사용하고, 변수 값에 따옴표나 공백, 유효하지 않은 호스트 이름이 들어 있는지 확인하세요.

curl: (28) Connection timed out

원인: 연결 또는 데이터 전송이 제한 시간을 초과했습니다. 프록시 진입점, 원격 서버, 대상 사이트의 응답 단계에서 지연이 발생했을 수 있습니다.

해결 방법: -v를 추가해 마지막으로 완료된 단계가 무엇인지 확인한 뒤 같은 시각의 코어 로그와 비교하세요. 로컬 진입점에 접속할 수 없는지 원격 연결이 시간 초과되었는지 구분할 수 있습니다.

curl: (60) SSL certificate problem

원인: 인증서 검증에 실패했습니다. 시스템 시간, 인증서 신뢰 체인, 네트워크의 TLS 검사와 관련이 있을 수 있습니다.

해결 방법: 시스템 시간과 인증서 출처를 확인하세요. 인증서 검증을 건너뛰는 방법을 장기적인 해결책으로 사용하지 말고, 이 오류를 시스템 프록시가 작동하지 않는 문제로 단정하지 마세요.

로그에 새 기록이 없다고 해서 요청이 코어에 도달하지 않았다고 단정할 수는 없습니다. 현재 로그 수준에서 요청별 기록을 남기지 않을 수 있습니다. v2rayN의 「설정」→「매개변수 설정」에서 로그 관련 옵션을 확인하고, 잠시 더 자세한 로그를 켠 뒤 코어를 다시 시작하세요. 시간도 함께 기록하면서 테스트를 한 번 실행합니다. 완료 후에는 원래 로그 수준으로 되돌리고, 로그를 공유하기 전에 구독 주소와 인증 정보 등 민감한 내용을 삭제하세요.

정리: 한 번에 설정 하나만 변경하세요

같은 테스트 대상을 사용해 프록시 직접 지정, 브라우저 시스템 프록시, 터미널 환경 변수의 결과를 차례로 기록하세요. 프록시를 직접 지정한 요청도 실패할 때만 코어와 원격 연결을 계속 점검하고, 그렇지 않다면 앱이 프록시를 읽는 경로부터 바로잡으세요.

v2rayN / v2rayNG 다운로드