먼저 프록시를 명시한 요청으로 로컬 포트와 노드를 확인한 다음, 브라우저의 프록시 설정과 터미널 환경 변수를 각각 점검하세요. 마지막으로 TUN이 필요한지 판단하면 됩니다. 이 글은 Windows용 v2rayN을 기준으로, “브라우저는 되는데 터미널은 안 되는” 경우나 “시스템 프록시를 켰는데도 직접 연결되는” 경우를 다룹니다. 예시 포트는 반드시 PC의 실제 설정과 대조하세요.
시스템 프록시, 로컬 포트, 라우팅 규칙 구분하기
v2rayN의 ‘시스템 프록시 자동 설정’은 운영체제 설정에 프록시 주소를 입력하는 기능이며, 모든 프로그램의 트래픽을 가로채지는 않습니다. 앱이 이 설정을 읽어야 로컬 프록시에 연결됩니다. 브라우저는 보통 시스템 설정을 읽지만 명령줄 도구는 각기 다른 방식을 사용하므로, 같은 PC에서도 결과가 다를 수 있습니다.
요청이 로컬 프록시에 도달하면 코어가 라우팅 규칙에 따라 직접 연결, 프록시 연결 또는 차단을 결정합니다. 시스템 프록시를 켰다는 것은 앱이 코어를 거칠 수 있다는 뜻일 뿐, 모든 목적지로 원격 노드를 통해 나간다는 보장은 아닙니다. 구독 업데이트 성공이나 노드 지연 시간 확인만으로 실제 웹 요청이 정상인지 판단할 수도 없습니다.
| 점검 단계 | 역할 | 주요 확인 항목 |
|---|---|---|
| 앱의 프록시 설정 | 요청을 로컬 프록시로 보낼지 결정 | 브라우저 설정, 실행 옵션, 터미널 옵션 |
| 로컬 인바운드 포트 | HTTP 또는 SOCKS 요청 수신 | 수신 주소, 수신 포트, 코어 시작 로그 |
| 라우팅 및 DNS | 도메인 해석 방식과 연결의 출구 결정 | 접속 로그의 대상 및 아웃바운드 태그 |
| 원격 노드 | 프록시 연결 및 트래픽 전달 | 실제 요청 결과, 핸드셰이크 오류, 시간 초과 기록 |
문제 해결을 시작할 때는 TUN을 끄고 프록시 클라이언트 하나만 실행하세요. 그러면 TUN이 잘못된 시스템 프록시 설정을 대신 처리하는 상황을 막고, 트래픽 처리 방식이 겹쳐 생기는 혼선을 줄일 수 있습니다. 조직에서 관리하는 기기라면 조직이 적용한 네트워크 정책을 우회하지 마세요.
1단계: 포트 확인 후 프록시를 명시해 테스트
먼저 v2rayN에서 ‘설정’ → ‘매개변수 설정’을 열어 로컬 수신 포트와 인바운드 프로토콜을 확인하고, 코어 시작 로그도 살펴보세요. 버전에 따라 HTTP와 SOCKS 포트를 따로 사용하거나 혼합 포트를 사용할 수 있습니다. 오래된 안내를 기준으로 포트 번호를 고정값처럼 입력하지 마세요. 아래에서는 포트 두 개를 예시로 보여 주며, 현재 버전의 기본 설정을 의미하지 않습니다.
-
포트 기록
로컬 HTTP 또는 혼합 포트와 SOCKS 포트를 기록하세요. 혼합 포트 하나만 있다면 두 테스트에 같은 포트를 사용하면 됩니다. 구독 정보에 표시된 원격 서버 포트를 입력하지 마세요.
-
코어 실행
메인 화면에서 테스트할 서버를 선택해 활성 서버로 지정하고, 로그에 시작 오류가 없는지 확인하세요. 테스트 중에는 노드 하나와 동일한 규칙만 사용하세요.
-
포트 수신 확인
PowerShell에서 아래 포트 수신 확인 명령을 실행하세요. 결과가 없으면 먼저 코어 시작 상태를 확인하세요. 다른 프로세스가 해당 포트를 사용 중이라면 충돌을 해결한 뒤 진행하세요. 아직 브라우저 설정을 바꿀 단계는 아닙니다.
-
프록시 지정
curl.exe에서 프록시를 명시해 HTTP 응답과 오류를 확인하세요. Windows PowerShell에서curl을 입력하면 별칭이 실행될 수 있으므로, 여기서는 프로그램 이름 전체를 사용합니다.
# 포트는 이 PC에서 실제로 수신 중인 값으로 바꾸세요
Get-NetTCPConnection -State Listen -LocalPort 10809 |
Select-Object LocalAddress, LocalPort, OwningProcess
# HTTP 프록시: HTTPS 요청은 CONNECT 터널을 통해 전송
curl.exe --proxy http://127.0.0.1:10809 --noproxy "" --connect-timeout 10 --max-time 20 -I https://example.com/
# SOCKS5: 대상 도메인은 프록시 측에서 해석
curl.exe --proxy socks5h://127.0.0.1:10808 --noproxy "" --connect-timeout 10 --max-time 20 -I https://example.com/--noproxy ""는 이번 프록시 지정 테스트에서 우회 목록을 비우는 옵션입니다. 예시 URL은 연결 경로를 확인하기 위한 것으로, 특정 지역에서 접속 가능하다는 뜻은 아닙니다. 추가로 진단할 때는 실제로 문제가 발생하는 주소를 사용하세요. 대상 사이트에서 HTTP 상태 코드가 돌아왔다면 HTTP 응답을 받은 것입니다. 403이나 405도 로컬 프록시에 연결하지 못한 상황과는 다르지만, 원격 노드를 거쳤는지는 로그와 함께 판단해야 합니다.
브라우저가 프록시를 사용하지 않을 때: 시스템 설정과 확장 프로그램 확인
프록시 지정 테스트는 성공했는데 브라우저가 예상대로 작동하지 않는다면, 우선 브라우저가 시스템 프록시를 사용하도록 설정한 뒤 자체 프록시 확장 프로그램을 확인하세요. Edge와 Chrome은 보통 Windows 프록시 설정을 사용하지만, 확장 프로그램이나 실행 옵션, 조직 정책에 따라 동작이 달라질 수 있습니다. 일부 확장 프로그램은 시크릿 모드에서도 실행할 수 있으므로 시크릿 창만으로 확장 프로그램의 영향을 배제할 수는 없습니다.
-
시스템 프록시 설정 적용
v2rayN 트레이 아이콘을 마우스 오른쪽 버튼으로 클릭하고 ‘시스템 프록시’ → ‘시스템 프록시 자동 설정’을 선택하세요. ‘시스템 프록시 지우기’를 선택하지 말고, ‘시스템 프록시 변경 안 함’을 자동 활성화로 오해하지 마세요.
-
시스템 프록시 주소 확인
Windows 11에서 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’를 열고 ‘프록시 서버 사용’ 항목의 주소와 포트를 확인하세요. v2rayN의 HTTP 또는 혼합 인바운드와 일치해야 합니다. 기존 자동 구성 스크립트도 기록해 두어 두 설정이 점검을 방해하지 않도록 하세요.
-
프록시 확장 프로그램 일시 중지
브라우저 확장 프로그램 관리 페이지에서 프록시 전환 확장 프로그램을 잠시 끄세요. 실행 바로 가기에 프록시 옵션이 포함되어 있는지도 확인하세요. 브라우저 창을 모두 닫았다가 다시 열고, 같은 테스트 주소에 접속해 보세요.
-
브라우저 자체 설정 확인
Firefox에서 ‘설정’ → ‘일반’ → ‘네트워크 설정’ → ‘설정’을 열고 ‘시스템 프록시 설정 사용’을 선택하세요. 수동 설정을 사용한다면 HTTP, SOCKS, 프록시를 사용하지 않을 주소 목록을 각각 확인해야 합니다.
특정 사이트만 직접 연결된다면 프록시 예외 목록과 v2rayN 라우팅 규칙을 확인하세요. 예를 들어 브라우저가 로컬 네트워크 주소를 프록시 대상에서 제외했거나, 특정 도메인이 직접 연결 아웃바운드로 지정되었을 수 있습니다. 이는 시스템 프록시가 작동하지 않는 문제가 아닙니다. 비교 테스트를 위해 잠시 전체 프록시 라우팅 모드로 전환한 뒤, 테스트가 끝나면 기존 규칙을 복원하세요. 라우팅 규칙 전체를 바로 삭제하지 마세요.
- 모든 브라우저에서 실패: 시스템 프록시 포트, 자동 구성 스크립트, 다른 소프트웨어가 설정을 반복해서 변경하는지 먼저 확인하세요.
- 브라우저 하나에서만 실패: 해당 브라우저의 확장 프로그램, 별도 설정, 실행 옵션, 관리 정책을 먼저 점검하세요.
- 웹페이지는 열리지만 출구 IP가 예상과 다름: 해당 도메인의 아웃바운드 로그를 확인하세요. 출구 IP 확인 사이트에는 그 사이트에 접속한 요청의 결과만 표시됩니다.
터미널이 프록시를 사용하지 않을 때: 명시적 옵션을 먼저, 환경 변수는 다음으로
명령줄 도구가 Windows 시스템 프록시를 읽는다고 보장할 수 없습니다. 터미널 창 자체도 하나의 통일된 네트워크 클라이언트가 아닙니다. 같은 PowerShell에서도 curl.exe, 스크립트 런타임, 패키지 관리 도구가 서로 다른 프록시 설정을 사용할 수 있습니다. 먼저 문제의 프로그램을 직접 테스트한 뒤 환경 변수를 설정하세요. 브라우저가 작동한다고 터미널도 프록시를 사용한다고 단정하면 안 됩니다.
curl에서 https_proxy는 “HTTPS 대상에 접속할 때 사용할 프록시”를 뜻하며, 값은 http://127.0.0.1:10809일 수 있습니다. 여기서 http://는 로컬 프록시의 프로토콜을 나타낼 뿐, 대상 웹페이지가 암호화되지 않는다는 의미가 아닙니다. https://127.0.0.1:10809로 잘못 설정하면 일반 HTTP 프록시 포트에 TLS 핸드셰이크를 시도해 실패할 수 있습니다.
# 기존 값을 먼저 기록하세요. 아래 설정은 현재 PowerShell과 새로 시작하는 하위 프로세스에만 적용됩니다
$oldHttpsProxy = $env:https_proxy
$oldNoProxy = $env:no_proxy
$env:https_proxy = "http://127.0.0.1:10809"
$env:no_proxy = "localhost,127.0.0.1"
# --proxy 없이 실행해 프로그램이 환경 변수를 읽는지 확인
curl.exe --connect-timeout 10 --max-time 20 -I https://example.com/
# 테스트를 마친 뒤 기존 값 복원
if ($null -eq $oldHttpsProxy) {
Remove-Item Env:https_proxy -ErrorAction SilentlyContinue
} else {
$env:https_proxy = $oldHttpsProxy
}
if ($null -eq $oldNoProxy) {
Remove-Item Env:no_proxy -ErrorAction SilentlyContinue
} else {
$env:no_proxy = $oldNoProxy
}설정, 테스트, 복원을 순서대로 하나씩 실행하세요. 코드 블록 전체를 한꺼번에 실행한 뒤 환경 변수를 확인하지 마세요. HTTP 대상에도 프록시가 필요하다면 해당 도구 문서에서 http_proxy 지원 여부를 확인하세요. curl은 변수의 대소문자를 별도로 처리하므로, 여러 플랫폼에서 사용하는 스크립트에는 소문자 이름을 권장합니다. ALL_PROXY는 curl에서 일반 프록시 대체값으로 쓸 수 있지만 모든 프로그램이 지원하는 것은 아니며, 모든 도구가 SOCKS 주소를 허용하는 것도 아닙니다.
| 설정 방법 | 적용 범위 | 점검 시 유의 사항 |
|---|---|---|
--proxy | 현재 curl 요청 1회 | 반복 가능한 진단 기준을 세우는 데 적합 |
$env:https_proxy | 현재 PowerShell과 이후 시작하는 하위 프로세스 | 이미 실행 중인 다른 터미널에는 새 값이 적용되지 않음 |
NO_PROXY | 해당 변수를 지원하는 도구 | 대상 도메인이나 와일드카드 규칙으로 프록시를 우회할 수 있음 |
| 도구 자체 설정 | 해당 프로그램 또는 프로젝트 | 환경 변수를 덮어쓸 수 있으므로 항목별 확인 필요 |
환경 변수가 적용되지 않는다면 프로그램 자체의 프록시 옵션을 확인하세요. PowerShell의 Invoke-WebRequest는 -Proxy http://127.0.0.1:10809를 지정해 테스트할 수 있습니다. curl이 성공했다고 해서 이 명령도 같은 환경 변수를 읽는다고 단정할 수는 없습니다. WSL과 컨테이너는 별도의 네트워크 환경을 사용합니다. 그 안의 127.0.0.1이 Windows 호스트를 가리키지 않을 수 있으므로 네트워크 모드에 맞춰 호스트 주소와 수신 범위를 확인해야 합니다.
실제 오류 메시지로 포트, TLS, 원격 연결 시간 초과 구분하기
실패한 요청의 전체 오류 메시지와 발생 시각을 기록한 뒤 v2rayN 로그와 대조하세요. 아래 포트는 이 글의 예시이며, 실제 오류에는 사용 중인 포트와 대기 시간이 표시됩니다. “연결 실패”라는 네 글자만 잘라 공유하지 마세요. 구독 링크나 인증 정보가 포함된 전체 로그를 공개적으로 보내서도 안 됩니다.
curl: (7) Failed to connect to 127.0.0.1 port 10809
원인: 이 PC에서 프록시 수신 포트로 연결되지 않았습니다. 코어가 실행되지 않았거나 포트를 잘못 입력했을 때 자주 발생합니다. 해결: 먼저 수신 기록과 포트를 사용 중인 프로세스를 확인한 다음 HTTP 또는 혼합 인바운드 설정을 점검하세요. 로컬 연결 실패라면 원격 노드를 바꿔도 대개 해결되지 않습니다.
curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed
원인: TLS 핸드셰이크에 실패했습니다. 프록시 프로토콜 설정 오류, 대상 서버 또는 로컬 보안 소프트웨어가 원인일 수 있으며, 이 메시지만으로 노드가 유효하지 않다고 단정할 수 없습니다. 해결: 프록시 URL을 HTTPS로 잘못 입력하지 않았는지 확인하고, 시스템 시간을 점검한 뒤 다른 대상과 비교하세요. 인증서 검증을 끄는 방식으로 문제를 덮지 마세요.
curl: (28) Operation timed out after 20000 milliseconds with 0 bytes received
원인: 설정한 시간 안에 응답을 받지 못했습니다. 원격 연결, DNS, 대상 서버 응답 단계에서 지연될 수 있습니다. 해결: -v를 추가해 다시 시도하고 프록시 연결과 CONNECT가 완료되었는지 확인한 뒤, 코어 로그에서 대상 도메인과 아웃바운드를 점검하세요.
socks5h://로는 테스트가 성공하지만 로컬에서 이름을 해석해야 하는 방식은 실패한다면, 우선 DNS 해석 경로를 점검해야 합니다. 그렇다고 특정 공용 DNS에 반드시 문제가 있다는 뜻은 아닙니다. 라우팅 규칙이 도메인 해석에 의존하는지, DNS 요청이 예상한 아웃바운드로 전달되는지도 확인하세요.
TUN으로 전환할 때와 시스템 프록시를 계속 점검할 때
프록시 설정이 없는 앱이 여럿 있거나 각 앱의 환경 변수를 관리하기 어렵거나 더 많은 IP 트래픽을 처리해야 한다면 TUN을 고려할 수 있습니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 처리하므로 보통 시스템 프록시보다 적용 범위가 넓습니다. 다만 올바르게 처리되는지는 코어, 권한, 라우팅, DNS, 앱 동작에 달려 있습니다. 모든 네트워크 문제를 한 번에 해결하는 스위치는 아닙니다.
- 시스템 프록시부터 수정: 브라우저 포트 오입력, 확장 프로그램의 강제 직접 연결, curl 옵션 오류처럼 원인이 분명한 문제는 연결 처리 방식을 바꿀 필요가 없습니다.
- TUN 고려: 여러 앱이 시스템 프록시를 읽지 않고 앱마다 프록시를 설정하는 비용이 큰 경우입니다. 먼저 일반 프록시 연결이 정상인지 확인하세요.
- 활성화를 미루세요: 프록시를 명시한 요청이 계속 실패하거나 원격 노드 핸드셰이크에 오류가 있거나 조직 네트워크에 강제 정책이 적용된 경우입니다. TUN이 노드나 인증 설정을 자동으로 고쳐 주지는 않습니다.
활성화 전에 현재 시스템 프록시와 라우팅 상태를 기록하세요. v2rayN 안내에 따라 필요한 권한을 부여한 다음 화면에서 TUN을 켭니다. 테스트 중에는 시스템 프록시를 끄고 터미널의 임시 변수도 복원해, 앱이 명시적 프록시와 TUN을 동시에 거치지 않도록 하세요. 그래야 결과를 해석하기 쉽습니다. 가상 인터페이스, 기본 경로, DNS가 설정되었는지 확인한 다음 로컬 네트워크 서비스에 계속 접속할 수 있는지도 점검하세요.
자주 묻는 질문과 최종 점검
브라우저에서 웹페이지가 열리는데 터미널은 왜 시간 초과가 발생하나요?
먼저 이 글의 curl.exe --proxy 테스트를 실행하세요. 명시적 옵션을 사용하면 성공하지만 일반 명령은 실패한다면, 해당 도구가 환경 변수를 읽는지와 NO_PROXY에 대상이 포함되어 있는지를 먼저 확인하세요. 클라이언트를 바로 다시 설치하지 마세요.
v2rayN을 종료한 뒤 웹페이지도 열리지 않습니다. 어떻게 복구하나요?
Windows에서 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’를 열고 중지된 로컬 포트를 가리키는지 확인하세요. 개인 기기라면 수동 프록시 설정을 끌 수 있습니다. 원래 조직 프록시나 자동 구성 스크립트를 사용했다면 기존 설정을 복원하세요.
HTTP와 SOCKS에는 각각 어떤 포트를 입력해야 하나요?
이름을 보고 추측하지 말고 로컬 인바운드 프로토콜에 맞춰 입력하세요. 브라우저의 HTTP 프록시 항목에는 HTTP 또는 호환되는 혼합 포트를, SOCKS 설정에는 SOCKS 또는 호환되는 혼합 포트를 입력합니다. 원격 노드의 443 포트는 로컬 프록시 포트가 아닙니다.
시스템 프록시가 켜져 있는데 출구 IP가 바뀌지 않았습니다. 프록시가 작동하지 않는 건가요?
꼭 그렇지는 않습니다. 먼저 출구 IP 확인 사이트의 도메인이 직접 연결 규칙에 해당하는지 살펴보고 코어 접속 로그와 대조하세요. 접속 로그가 아직 꺼져 있다면 현재 코어가 지원하는 설정으로 진단 중에만 켠 뒤 완료 후 원래대로 복원하세요. 확인 사이트 하나의 결과만으로 모든 앱의 연결 경로를 판단할 수는 없습니다.
마지막으로 확인할 것은 명확한 증거의 흐름입니다. 로컬 포트가 실제로 수신 중이고, 프록시를 명시한 요청이 응답을 받으며, 브라우저가 올바른 프록시 설정을 사용하고, 터미널 프로그램이 자체 프록시 옵션을 읽고, 라우팅 로그에 예상한 아웃바운드가 표시되어야 합니다. 이 순서대로 단계별로 확인하면 시스템 프록시를 반복해서 켜고 끄거나 노드를 계속 바꾸는 것보다 원인을 찾기 쉽습니다. 구독, 노드, 시작 순서를 다시 정리하려면 사이트의 빠른 시작 가이드에서 기준 설정을 다시 마련하세요.