이 글에서는 Windows용 v2rayN을 기준으로, 시스템 프록시를 설정했는데도 브라우저나 터미널에서 접속되지 않는 문제를 살펴봅니다. 먼저 프록시를 명시한 요청으로 로컬 진입점을 확인한 뒤, 브라우저 확장 프로그램과 자동 구성 스크립트, 터미널 환경 변수를 점검합니다. 문제 원인을 앱의 프록시 설정, 로컬 포트 수신, 코어의 아웃바운드 또는 라우팅 규칙으로 좁혀 노드를 반복해서 바꾸지 않도록 안내합니다.
1. 시스템 프록시, 라우팅, TUN의 차이
v2rayN의 시스템 프록시는 운영체제에 프록시 설정을 적용하는 기능이며, 모든 네트워크 연결을 가로채는 것은 아닙니다. 앱이 해당 설정을 읽어야 요청이 로컬 프록시 포트로 전달됩니다. 브라우저는 대체로 시스템 프록시를 지원하지만, 명령줄 도구가 시스템 프록시나 환경 변수, 자체 설정 파일을 읽는지는 도구마다 다릅니다.
문제를 확인할 때는 먼저 TUN 모드를 끄세요. 가상 네트워크 어댑터가 트래픽을 가로채면 시스템 프록시 문제를 파악하기 어려울 수 있습니다. 다른 터널 프로그램이나 기업 네트워크 소프트웨어를 사용 중이라면 현재 상태를 기록하고 설정을 바로 삭제하지 마세요. 이 글에 나오는 포트는 테스트용 예시이므로, 현재 v2rayN에 표시된 실제 수신 포트로 바꿔 사용하세요.
| 설정 계층 | 실제 기능 | 이 설정만으로는 확인할 수 없는 점 |
|---|---|---|
| 시스템 프록시 | 시스템 설정을 따르는 앱에 사용할 프록시 진입점을 지정 | 모든 터미널과 백그라운드 프로그램이 프록시를 사용한다는 것 |
| 로컬 인바운드 | 루프백 주소의 지정된 포트에서 HTTP 또는 SOCKS 요청 수신 | 원격 서버에 연결되었다는 것 |
| 코어 라우팅 | 수신한 요청을 직접 연결, 프록시 또는 차단 중 하나로 전달 | 수신한 모든 요청이 원격 프록시를 통한다는 것 |
| TUN 모드 | 가상 네트워크 어댑터를 통해 지정된 네트워크 트래픽을 가로챔 | 앱이 시스템 프록시 설정을 제대로 읽는다는 것 |
2. 로컬 포트를 확인하고 프록시를 명시해 테스트
먼저 v2rayN의 「설정」→「매개변수 설정」에서 로컬 수신 설정을 확인하고, 메인 화면 하단의 포트 정보를 살펴보세요. 버전에 따라 HTTP 포트와 SOCKS 포트가 따로 있거나 혼합 포트를 제공할 수 있으며, 메뉴 이름과 배치도 다를 수 있습니다. 혼합 포트는 지원되는 프로토콜을 모두 받을 수 있지만, SOCKS 전용 포트는 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. 브라우저에서 프록시가 작동하지 않을 때: 확장 프로그램과 별도 설정 확인
브라우저 확장 프로그램이 시스템 프록시 설정을 덮어쓸 수 있습니다. 한 창에서는 접속되는데 다른 창에서는 안 된다면 노드 탓으로 돌리기 전에 브라우저 프로필과 확장 프로그램 상태를 비교하세요. 시크릿 창도 확장 프로그램이 없는 확실한 테스트 환경은 아닙니다. 시크릿 창에서 실행하도록 허용된 확장 프로그램은 계속 작동할 수 있습니다.
-
시스템 프록시 사용
Windows용 v2rayN 메인 화면 하단의 「시스템 프록시」 메뉴에서 「시스템 프록시 자동 설정」을 선택하세요. 이 항목은 클라이언트가 시스템 프록시를 설정하는 기능이며, PAC 스크립트 모드를 뜻하는 것은 아닙니다.
-
시스템 프록시 진입점 확인
Windows 「설정」→「네트워크 및 인터넷」→「프록시」를 열어 수동 프록시의 주소와 포트를 확인하세요. 루프백 주소는 이 컴퓨터를 가리켜야 하며, 포트는 앞에서 연결에 성공한 HTTP 또는 혼합 진입점과 일치해야 합니다.
-
프록시 확장 프로그램 끄기
Chrome의 「확장 프로그램」→「확장 프로그램 관리」에서 프록시를 제어하는 확장 프로그램을 잠시 사용 중지하세요. Edge에서는 「확장」→「확장 관리」에서 설정할 수 있습니다. 그런 다음 브라우저 관련 프로세스를 종료하고 다시 실행한 뒤 같은 테스트 주소에 접속하세요.
-
브라우저 자체 설정 확인
Firefox에서는 「설정」→「일반」→「네트워크 설정」→「설정」에서 「시스템 프록시 설정 사용」을 선택할 수 있습니다. 수동 프록시를 선택했다면 해당 포트를 확인하세요. Windows 설정이 바뀌어도 Firefox의 값이 자동으로 갱신된다고 가정하면 안 됩니다.
시스템 프록시 주소를 설정한 직후 값이 바뀐다면 다른 프로그램이나 조직 정책이 관리 중일 수 있습니다. 중복 실행 중인 프록시 프로그램을 종료한 뒤 다시 확인하세요. 관리 대상 기기라면 관리자에게 정책을 문의해야 합니다. 이 컴퓨터의 브라우저를 프록시에 연결할 때 수신 주소를 0.0.0.0으로 바꿀 필요는 없으며, 방화벽 전체를 끄는 것도 우선적으로 시도할 방법이 아닙니다.
4. PAC 모드: 스크립트 주소와 반환값 확인
PAC는 자동 프록시 구성 스크립트입니다. 브라우저는 스크립트의 FindProxyForURL(url, host)을 호출해 반환값에 따라 프록시를 사용할지 직접 연결할지 결정합니다. PAC 규칙은 v2rayN 코어의 routing.rules와 다른 계층에 적용됩니다. PAC 설정 때문에 요청이 코어에 도달하지 않을 수 있지만, 코어 라우팅은 로컬 인바운드에 도착한 요청만 처리할 수 있습니다.
- 스크립트 사용 여부 확인: Windows 「설정」→「네트워크 및 인터넷」→「프록시」→「설정 스크립트 사용」에서 주소를 확인하세요. 수동 시스템 프록시만 사용할 예정이라면 기존 주소를 기록한 뒤 스크립트를 잠시 끄고 테스트할 수 있습니다.
- 스크립트에 접속할 수 있는지 확인: 스크립트가 로컬 포트를 가리킨다면 해당 서비스가 실행 중인지 확인하세요. 이전 클라이언트를 종료한 뒤 남은 스크립트 주소는 더 이상 읽을 수 없을 수 있습니다.
- 반환값 확인:
DIRECT는 직접 연결,PROXY 127.0.0.1:10808은 해당 HTTP 프록시 진입점으로 전달한다는 뜻입니다. 스크립트가 오래된 포트를 가리키면 현재 코어가 정상 작동해도 접속에 실패합니다. - 대체 연결 설정 확인:
PROXY 127.0.0.1:10808; DIRECT에는 직접 연결로 전환하는 설정이 포함되어 있습니다. 프록시를 사용할 수 없을 때 브라우저가 직접 연결을 시도하므로 일부 사이트는 계속 열릴 수 있습니다.
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의 「설정」→「매개변수 설정」에서 로그 관련 옵션을 확인하고, 잠시 더 자세한 로그를 켠 뒤 코어를 다시 시작하세요. 시간도 함께 기록하면서 테스트를 한 번 실행합니다. 완료 후에는 원래 로그 수준으로 되돌리고, 로그를 공유하기 전에 구독 주소와 인증 정보 등 민감한 내용을 삭제하세요.
정리: 한 번에 설정 하나만 변경하세요
같은 테스트 대상을 사용해 프록시 직접 지정, 브라우저 시스템 프록시, 터미널 환경 변수의 결과를 차례로 기록하세요. 프록시를 직접 지정한 요청도 실패할 때만 코어와 원격 연결을 계속 점검하고, 그렇지 않다면 앱이 프록시를 읽는 경로부터 바로잡으세요.
- 프록시 직접 지정은 성공하고 브라우저는 실패: 확장 프로그램, 브라우저 자체 프록시 설정, PAC, 조직 정책을 확인하세요.
- 브라우저는 성공하고 터미널은 실패: 환경 변수, 프로세스 상속, 도구 자체 설정을 확인하세요.
- 포트에 연결되지만 프록시 요청은 실패: 인바운드 프로토콜, 아웃바운드 로그, 서버 설정, DNS를 확인하세요.
- 요청에는 접속되지만 출구가 예상과 다름: PAC가 직접 연결을 반환하는지, 코어 라우팅이 어떤 아웃바운드를 선택했는지 확인하세요.