“브라우저는 열리지만 터미널은 실패하는 경우”, “시스템 프록시는 켜졌지만 일부 프로그램이 직접 연결하는 경우”, “프록시 오류에 연결 거부가 표시되는 경우”에 해당하는 Windows 사용자를 위한 글입니다. 먼저 v2rayN과 프록시 코어가 로컬 리스너를 열었는지 확인하고, 브라우저와 명령줄 도구의 연결 방식을 각각 점검한 다음, 앱 적용 범위를 기준으로 TUN 필요 여부를 판단하세요.
먼저 ‘작동하지 않음’을 세 가지 범위로 나누기
v2rayN은 설정과 코어를 관리하는 데스크톱 클라이언트이고, Xray 같은 프록시 코어가 실제 연결을 처리합니다. Windows 시스템 프록시는 일부 앱에 로컬 프록시 주소를 알려주는 역할만 합니다. 시스템 프록시를 켠다고 해서 모든 네트워크 연결이 코어로 강제 전달되는 것은 아니며, 라우팅 규칙이 반드시 프록시 출구를 선택한다는 뜻도 아닙니다.
첫 번째 계층은 로컬 리스너입니다. 클라이언트가 코어를 시작하면 일반적으로 루프백 주소에서 HTTP, SOCKS 또는 혼합 프록시 포트를 엽니다. 리스너가 실제로 존재해야 브라우저와 터미널이 연결할 진입점이 생깁니다. 두 번째 계층은 앱 연결 방식입니다. 앱이 Windows 시스템 프록시를 읽는지, 아니면 자체적으로 저장한 별도 프록시 설정을 사용하는지 확인해야 합니다. 세 번째 계층은 라우팅과 아웃바운드입니다. 연결이 코어에 들어온 뒤에는 설정의 도메인, IP, 프로토콜 및 규칙에 따라 직접 연결, 프록시 또는 차단이 결정됩니다.
따라서 “브라우저는 되는데 PowerShell은 안 된다”는 상황은 대개 노드가 갑자기 고장 난 것이 아니라 두 앱의 연결 방식이 다르기 때문입니다. “브라우저에 프록시 연결 실패가 표시된다”면 먼저 로컬 포트를 확인해야 하며, VLESS, VMess 또는 TLS 매개변수부터 바꿔서는 안 됩니다. 계층별로 점검하면 진입점 문제를 서버 문제로 잘못 판단하는 일을 줄일 수 있습니다.
| 현상 | 우선 확인할 항목 | 지금은 우선순위가 낮은 항목 |
|---|---|---|
| 모든 브라우저에서 프록시 연결 실패가 표시됨 | 코어 프로세스, 로컬 리스닝 주소, 포트 사용 여부 | 브라우저 캐시와 웹사이트 계정 |
| 브라우저는 정상인데 터미널이 직접 연결되거나 시간 초과됨 | HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 및 도구 옵션 | 구독 다시 가져오기 |
| 브라우저 하나만 비정상임 | 브라우저별 프록시 설정, 확장 프로그램 개입, 시작 매개변수 | Windows 전체 네트워크 초기화 |
| 프록시 테스트는 성공하지만 특정 도메인은 여전히 직접 연결됨 | 라우팅 규칙, 도메인 매칭, DNS 확인 위치 | 로컬 리스닝 포트 변경 |
첫 단계: 코어와 로컬 리스너 확인
먼저 v2rayN에서 설정 하나를 선택해 코어를 시작한 다음, 메인 화면이나 로그 영역에 시작 실패, 포트 사용 중, 설정 해석 오류가 표시되는지 확인하세요. 구독은 설정의 출처일 뿐입니다. 구독 업데이트에 성공했다고 해서 코어가 실행 중이거나 시스템 프록시가 올바른 포트를 가리킨다는 뜻은 아닙니다.
그다음 「설정」→「매개변수 설정」을 열어 현재 HTTP 및 SOCKS 리스닝 포트를 기록하세요. 버전에 따라 통합 혼합 포트를 사용하는 경우에는 화면에 실제로 표시된 값을 기록하면 됩니다. 리스닝 주소는 일반적으로 127.0.0.1이어야 하며, 로컬 컴퓨터의 연결만 허용합니다. LAN 연결이 명확히 필요한 경우가 아니라면 문제를 해결한다는 이유로 모든 네트워크 어댑터에 노출되는 주소로 함부로 변경하지 마세요.
포트 기록
v2rayN의 「설정」→「매개변수 설정」에서 HTTP, SOCKS 또는 혼합 리스닝 포트를 적어 두세요. 오래된 튜토리얼을 보고 값을 추측하지 마세요.
프로세스 확인
선택한 설정을 시작한 뒤 코어 종료 알림이 계속 나타나지 않는지 확인하고, 로그의 마지막 줄만 보지 말고 첫 번째 오류부터 찾아보세요.
리스닝 조회
PowerShell에서
Get-NetTCPConnection을 실행해 대상 포트가 Listen 상태인지 확인하고 해당 프로세스 ID를 기록하세요.진입점 테스트
Test-NetConnection으로 루프백 주소와 HTTP 포트를 테스트하세요. TCP 테스트가 실패하면 먼저 리스닝 문제를 해결해야 합니다.
Get-NetTCPConnection -State Listen |
Where-Object { $_.LocalPort -in 10808, 10809 } |
Select-Object LocalAddress, LocalPort, OwningProcess
Test-NetConnection 127.0.0.1 -Port 10809TcpTestSucceeded가 True라는 사실은 포트가 TCP 연결을 받아들인다는 것만 증명하며, 노드 프로토콜, 서버 주소 또는 라우팅 규칙이 올바르다는 뜻은 아닙니다. 다음 단계에서는 프록시를 명시한 요청으로 전체 연결 경로를 검증해야 합니다. 조회 결과에 대상 포트가 없으면 v2rayN 로그로 돌아가 코어 시작 문제를 처리하세요. 포트를 다른 프로세스가 사용 중이라면 Get-Process -Id 프로세스 ID로 프로그램 출처를 확인할 수 있습니다.
오류: ERR_PROXY_CONNECTION_FAILED
원인과 해결: 브라우저가 설정된 로컬 프록시에 연결하지 못했습니다. v2rayN이 실행 중인지, 시스템 프록시의 포트가 「매개변수 설정」과 일치하는지 확인하고, 해당 포트를 다른 프로세스가 사용 중인지 점검하세요.
오류: TcpTestSucceeded : False
원인과 해결: 지정한 주소와 포트에 사용 가능한 리스너가 없습니다. 먼저 코어를 시작하고 로그를 확인하세요. 방금 포트를 변경했다면 코어를 다시 시작한 뒤 테스트하고, 원격 노드 점검은 그다음에 진행하세요.
오류: Only one usage of each socket address is normally permitted
원인과 해결: 대상 포트를 다른 프로세스가 사용 중입니다. OwningProcess를 확인해 중복 실행된 인스턴스를 종료하거나, v2rayN에서 사용하지 않는 포트로 변경한 뒤 다른 앱의 설정도 함께 업데이트하세요.
브라우저는 ‘시스템 프록시 따르기’와 ‘개별 설정’을 나누어 확인
시스템 네트워크 설정을 사용하는 대부분의 데스크톱 브라우저는 Windows 프록시를 읽지만, 브라우저 확장 프로그램, 기업 정책, 시작 매개변수 또는 브라우저 자체 네트워크 설정이 이를 덮어쓸 수 있습니다. 문제를 점검할 때는 제어 경로를 하나만 남기세요. Windows 시스템 프록시를 따르거나 브라우저에서 로컬 프록시를 명시적으로 지정해야 하며, 확장 프로그램과 시스템 설정이 동시에 출구를 바꾸게 두지 마세요.
v2rayN 트레이 메뉴에서 시스템 프록시 관련 항목을 선택할 때는 현재 목적에 맞는 모드인지 확인하세요. 예를 들어 시스템 프록시 자동 구성을 사용할 수 있습니다. 이어서 Windows의 「설정」→「네트워크 및 인터넷」→「프록시」를 열어 수동 프록시 또는 자동 구성 스크립트가 현재 클라이언트 설정을 반영하는지 확인하세요. v2rayN 모드에 따라 시스템 설정을 기록하는 방식이 다를 수 있으므로 주소를 동시에 수동으로 덮어쓰지 마세요.
브라우저 하나만 비정상이라면 임시 브라우저 프로필을 새로 만들거나 프록시 전환을 담당하는 확장 프로그램을 비활성화한 뒤 다시 테스트하세요. 시크릿 창은 일반적으로 시스템 프록시를 우회하지 않으므로 캐시와 로그인 상태를 배제하는 데는 적합하지만, 프록시 진입점이 복구되었다는 증거로는 적합하지 않습니다. 브라우저의 보안 DNS는 도메인 확인을 담당하며 HTTP 또는 SOCKS 프록시와는 별개입니다.
제어 경로 통일
브라우저에서 프록시 전환을 담당하는 확장 프로그램을 잠시 비활성화하고 테스트용 시작 매개변수를 삭제한 뒤, Windows 시스템 프록시 하나만 제어 경로로 남기세요.
시스템 설정 확인
Windows 「설정」→「네트워크 및 인터넷」→「프록시」를 열어 주소, 포트 또는 자동 구성 상태가 v2rayN의 현재 모드와 일치하는지 확인하세요.
브라우저 재시작
모든 브라우저 프로세스를 완전히 종료한 뒤 다시 열어, 이전 프로세스가 시작 시 읽은 오래된 프록시 설정을 계속 사용하지 않도록 하세요.
하나씩 비교
먼저 일반 HTTPS 페이지를 테스트한 다음 처음 실패했던 도메인을 테스트하세요. 후자만 실패한다면 라우팅, DNS, SNI 및 서버 설정을 확인하세요.
브라우저 확장 프로그램에 직접 연결로 표시되면 어떻게 하나요?
확장 프로그램이 시스템 설정보다 우선할 수 있습니다. 먼저 확장 프로그램을 비활성화하고 브라우저를 다시 시작하세요. 정상으로 돌아오면 확장 프로그램에서 HTTP 또는 SOCKS 주소를 v2rayN의 현재 리스닝 값으로 변경하세요.
브라우저 하나는 되는데 다른 하나는 안 되나요?
두 브라우저가 모두 시스템 프록시를 따르는지 비교하고, 문제가 있는 브라우저의 정책 페이지, 프록시 확장 프로그램 및 시작 바로 가기에 별도 프록시 매개변수가 있는지 확인하세요.
보안 DNS를 끄면 해결되나요?
보안 DNS와 프록시 진입점은 서로 다른 계층입니다. 로그에 도메인 확인 문제가 명확히 나타날 때만 DNS를 조정하세요. 로컬 프록시 포트 연결 자체가 실패한 경우 보안 DNS를 꺼도 효과가 없습니다.
터미널 프로그램은 프록시 환경 변수를 명시적으로 설정해야 합니다
PowerShell, 명령줄 다운로드 도구, 패키지 관리자 및 개발 도구가 Windows 시스템 프록시를 반드시 읽는 것은 아닙니다. 어떤 프로그램은 대문자 환경 변수만 인식하고, 어떤 프로그램은 대소문자를 모두 인식하며, 일부는 자체 설정 파일에 프록시를 지정해야 합니다. 시스템 프록시가 켜졌는데도 터미널이 직접 연결하는 현상은 이런 프로그램에서 흔히 발생합니다.
먼저 curl.exe의 --proxy 옵션으로 프록시를 명시한 테스트를 한 번 실행하세요. 이렇게 하면 도구가 시스템 설정을 읽는지 여부를 배제하고 로컬 진입점부터 대상 사이트까지의 전체 요청을 바로 확인할 수 있습니다. HTTP 포트 예시는 10809이고 SOCKS 포트 예시는 10808이지만, 실제 테스트 전에는 v2rayN의 현재 값으로 바꿔야 합니다.
curl.exe --proxy http://127.0.0.1:10809 https://example.com/ --max-time 10
curl.exe --proxy socks5h://127.0.0.1:10808 https://example.com/ --max-time 10socks5h의 h는 대상 호스트 이름을 프록시 측에서 처리한다는 뜻입니다. 로컬 DNS와 프록시 측 확인 결과의 차이를 비교할 때 유용합니다. HTTP와 SOCKS 테스트가 모두 성공하지만 --proxy 없이 실행한 명령이 실패하거나 직접 연결된다면 문제는 터미널의 연결 방식에 있으므로 구독 설정을 계속 바꿀 필요가 없습니다.
현재 PowerShell 세션의 여러 도구에서 프록시를 사용하도록 시도하려면 환경 변수를 임시로 설정할 수 있습니다. 세션을 닫으면 이 변수는 사라지므로 문제를 점검할 때 적합합니다. 사용자 또는 시스템 수준 환경 변수에 저장하기 전에는 관련 도구가 해당 변수를 지원하는지, 내부망 주소에 어떤 영향을 주는지 먼저 확인하세요.
$env:HTTP_PROXY = "http://127.0.0.1:10809"
$env:HTTPS_PROXY = "http://127.0.0.1:10809"
$env:ALL_PROXY = "socks5h://127.0.0.1:10808"
$env:NO_PROXY = "localhost,127.0.0.1"
Get-ChildItem Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:ALL_PROXY, Env:NO_PROXY오류: curl: (7) Failed to connect to 127.0.0.1 port 10809
원인과 해결: curl이 지정한 로컬 포트에 접근하지 못했습니다. 포트 유형과 번호를 확인하고 코어의 리스닝 상태를 점검하세요. v2rayN이 혼합 포트를 사용한다면 해당 포트를 입력해야 합니다.
오류: curl: (28) Operation timed out after 10000 milliseconds
원인과 해결: 요청이 10초 제한을 초과했습니다. 로컬 TCP 연결이 성공했다면 코어 로그에서 DNS, 원격 연결, TLS 또는 라우팅 오류를 계속 확인하세요. 인바운드 기록이 전혀 없다면 명령에 입력한 프록시 주소를 점검하세요.
오류: The underlying connection was closed
원인과 해결: 연결이 설정된 뒤 프로토콜 또는 TLS 단계에서 종료되었습니다. 먼저 curl로 비교 테스트를 하고, 노드 도메인, 시스템 시간, SNI 및 인증서 설정을 확인하세요. 인증서 검증을 끄는 방법을 장기적인 해결책으로 사용하지 마세요.
연결 성공 후 라우팅과 DNS 확인
명시적 프록시 요청이 코어에 도달했는데도 특정 웹사이트가 실패할 때 비로소 점검의 초점이 “앱이 연결되었는가”에서 “코어가 어떻게 처리하는가”로 이동합니다. v2rayN이 관리하는 라우팅 규칙은 도메인, IP 또는 프로토콜에 따라 직접 연결과 프록시를 선택할 수 있습니다. VLESS와 VMess는 노드 프로토콜 설정의 일부이며, 터미널이 Windows 시스템 프록시를 읽는지 여부를 결정하지 않습니다.
로그를 확인할 때는 동일한 테스트 요청과 대응시켜야 합니다. 먼저 테스트 시간을 정확히 기록하고 단일 요청을 보낸 다음, 대상 도메인, 매칭된 규칙 및 아웃바운드 오류가 나타나는지 확인하세요. 로그에 해당 요청이 전혀 없다면 트래픽이 아직 코어에 들어오지 않은 것입니다. 요청이 기록되었고 직접 연결을 선택했다면 라우팅 규칙을 확인하세요. 프록시를 선택한 뒤 확인 또는 핸드셰이크 오류가 발생한다면 노드 매개변수와 DNS를 점검하세요.
| 로그 현상 | 판단 | 다음 단계 |
|---|---|---|
| 테스트 중 해당 요청이 나타나지 않음 | 앱이 로컬 프록시에 연결되지 않음 | 브라우저 설정, 명령 옵션 또는 환경 변수 확인 |
| 요청이 들어온 뒤 직접 연결로 매칭됨 | 라우팅 규칙이 직접 연결 출구를 선택함 | 도메인 규칙, IP 규칙 및 규칙 순서 확인 |
| 도메인 확인 실패가 발생함 | DNS 설정 또는 확인 경로 이상 | 로컬 확인과 프록시 측 확인을 비교하고 도메인 철자를 점검 |
| 원격 연결 후 핸드셰이크 실패 | 노드 프로토콜 또는 TLS 단계 이상 | 서버 이름, 시스템 시간 및 전송 매개변수 확인 |
- 구독 업데이트는 설정 목록을 가져오는 역할만 하며, 목록의 모든 설정이 현재 연결 가능한지 증명하지는 않습니다.
- 시스템 프록시는 일부 앱이 로컬 진입점을 찾는 방식을 결정하고, 트래픽 분할 라우팅은 코어에 들어온 뒤의 이동 경로를 결정합니다.
- 로컬 DNS가 먼저 확인한 결과와 프록시 측 확인 결과는 다를 수 있습니다. SOCKS 테스트에서는
socks5와socks5h를 비교해 보세요. - 규칙을 변경한 뒤에는 단일 요청을 다시 보내고 새 로그로 확인하세요. 포트, DNS, 노드 및 라우팅을 동시에 변경하지 마세요.
TUN을 고려해야 하는 경우
TUN은 HTTP 또는 SOCKS 프록시 설정을 지원하지 않는 앱까지 적용해야 하거나 더 많은 네트워크 트래픽을 통합적으로 관리하려는 경우에 적합합니다. 가상 네트워크 인터페이스를 통해 트래픽 연결 방식을 바꾸므로 시스템 프록시보다 적용 범위가 넓은 경우가 많지만, 라우팅 테이블, DNS, 관리자 권한 및 다른 VPN 유형 연결과의 조정이 함께 필요합니다.
문제가 프록시 옵션을 지원하는 터미널 도구 하나에서만 발생한다면 먼저 해당 도구를 설정하거나 환경 변수를 사용하는 편이 관찰과 복구가 쉽습니다. 여러 앱이 시스템 프록시를 전혀 읽지 않고 하나씩 설정하기도 어렵다면 TUN을 검토하세요. TUN을 로컬 포트 미리스닝, 노드 핸드셰이크 실패 또는 잘못된 라우팅 규칙의 대체 해결책으로 사용해서는 안 됩니다.
브라우저는 정상인데 게임이나 전용 프로그램이 프록시를 사용하지 않나요?
먼저 해당 프로그램이 HTTP, SOCKS 또는 네트워크 프록시 설정을 제공하는지 확인하세요. 프록시 진입점이 없고 반드시 적용해야 할 때만 TUN을 검토하고, 해당 프로그램의 서비스 약관과 네트워크 요구 사항도 확인하세요.
TUN을 켠 뒤에도 시스템 프록시를 켜야 하나요?
현재 클라이언트 설정과 트래픽 가로채기 방식에 따라 다르므로 기계적으로 동시에 켜서는 안 됩니다. 먼저 어떤 방식이 연결을 담당할지 정해 중복 프록시를 피하고 문제 점검 경로를 명확하게 유지하세요.
TUN을 켠 뒤 인터넷이 완전히 끊기면 어떻게 하나요?
먼저 TUN을 끄고 기본 네트워크를 복구한 다음 관리자 권한, 가상 인터페이스, DNS 및 라우팅 충돌을 확인하세요. 다른 VPN 연결이 실행 중이라면 동일한 트래픽을 동시에 가로채지 않도록 먼저 정리해야 합니다.
터미널에 환경 변수를 설정한 뒤에도 TUN이 필요한가요?
대상 도구가 HTTP_PROXY 또는 명시적인 프록시 옵션을 통해 안정적으로 작동한다면 해당 도구 하나만을 위해 TUN을 켤 필요는 없습니다. 적용 범위가 작고 동작을 검증할 수 있는 연결 방식을 계속 유지하세요.
변경을 최소화하는 순서로 재점검
한 번에 하나의 조건만 바꿔야 어느 단계에서 연결이 복구되었는지 알 수 있습니다. 가장 안정적인 순서는 로컬 리스닝, 명시적 프록시 테스트, 앱 연결 설정, 라우팅과 DNS, 마지막으로 TUN입니다. 각 단계에서 포트, 명령 결과 및 로그 시간을 기록하고 화면의 스위치 상태만으로 판단하지 마세요.
- v2rayN의 「설정」→「매개변수 설정」에서 현재 리스닝 주소와 포트를 기록하고 코어가 시작되었는지 확인하세요.
Get-NetTCPConnection과Test-NetConnection으로 포트가 실제로 리스닝 상태인지 확인하세요.curl.exe --proxy로 HTTP 또는 SOCKS 진입점을 각각 테스트하고 시간 초과 제한은 10초로 설정하세요.- 브라우저의 프록시 제어 출처는 하나만 남기고 완전히 종료한 뒤 다시 시작하여 다른 브라우저와 비교하세요.
- 터미널은 명령 옵션 또는 임시 환경 변수로 연결하고 Windows 시스템 프록시를 자동으로 읽는다고 가정하지 마세요.
- 요청이 코어에 들어온 것을 확인한 뒤 로그를 기준으로 라우팅 분할, DNS, 노드 프로토콜 및 TLS를 점검하세요.
- 여러 앱에서 개별 프록시 설정이 불가능하고 적용 범위를 반드시 넓혀야 할 때만 TUN을 설정하고 검증하세요.