V2Ray 연결됨으로 표시되지만 인터넷이 안 될 때: 단계별 점검

핵심 내용

‘연결됨’은 보통 로컬 서비스나 VPN 인터페이스가 시작되었다는 뜻일 뿐, 웹 요청이 노드를 거쳐 목적지에 도달했다는 의미는 아닙니다. 먼저 트래픽이 클라이언트로 들어오는지 확인한 다음 수신 포트, 도메인 조회, 외부 연결 경로를 점검하고 마지막으로 노드 설정과 시스템 시간을 확인하세요. 한 번에 한 가지 조건만 바꾸고 같은 주소로 다시 테스트하면 여러 문제가 겹치는 것을 막을 수 있습니다.

연결 상태와 실제 접속 결과를 구분하세요

v2rayN은 데스크톱 클라이언트이고 V2Ray와 Xray는 트래픽을 처리하는 코어입니다. v2rayNG는 Xray 코어를 사용하는 Android 클라이언트입니다. 실행 중 표시, VPN 열쇠 아이콘, 노드 지연 시간만으로는 브라우저에서 웹페이지가 정상적으로 열리는지 확인할 수 없습니다. 포트 연결 테스트, 실제 요청 테스트, 다운로드 속도 테스트는 각각 다른 구간을 검증합니다.

클라이언트를 종료한 뒤 기기에서 평소 이용하는 웹사이트에 접속할 수 있는지 확인하세요. 공용 Wi-Fi는 먼저 네트워크 인증을 해야 할 수 있으며, 기본 네트워크 연결이 끊긴 상태라면 노드를 바꿔도 해결되지 않습니다. 문제가 발생한 웹사이트와 시각, 네트워크 유형, 모든 앱에서 실패하는지 브라우저에서만 실패하는지 기록해 두세요.

모든 앱에서 접속이 안 됨: 기본 네트워크, 프록시 진입점, 코어 시작 상태, 노드 연결을 먼저 확인하세요.
브라우저 하나에서만 실패: 브라우저 자체 프록시, 확장 프로그램, 보안 DNS를 확인하세요. 처음부터 설정 전체를 다시 만들 필요는 없습니다.
일부 도메인에서만 실패: DNS, 라우팅 규칙, 대상 사이트의 접근 제한, IPv4 및 IPv6 연결 가능성을 먼저 확인하세요.
Wi-Fi를 바꾼 뒤에만 실패: 모바일 네트워크와 비교하고, 네트워크 인증 여부와 DNS 변경, 노드 포트 연결 가능성을 확인하세요.

첫 번째: 시스템 프록시가 트래픽을 전달하는지 확인

Windows에서 v2rayN을 실행해도 시스템 프록시가 자동으로 설정되는 것은 아닙니다. 시스템 프록시는 해당 설정을 따르는 앱에서 주로 사용되며 모든 트래픽을 제어하는 스위치도 아닙니다. 터미널 프로그램은 환경 변수를 사용할 수 있고, 브라우저는 자체 프록시 설정을 사용할 수 있으며, 게임 등은 시스템 프록시를 전혀 따르지 않을 수도 있습니다. TUN 모드는 별도의 트래픽 전달 방식이므로 문제를 확인할 때 여러 모드를 동시에 바꾸지 마세요.

활성 노드 확인

v2rayN 노드 목록에서 사용할 노드를 선택하고 마우스 오른쪽 버튼을 눌러 ‘활성 서버로 설정’을 선택하세요. 목록에서 행을 선택하는 것만으로 활성 노드가 바뀌지 않을 수 있으므로, 메인 화면의 활성 서버 정보도 확인해야 합니다.
시스템 프록시 설정

작업 표시줄 알림 영역에서 v2rayN 아이콘을 마우스 오른쪽 버튼으로 클릭한 뒤 ‘시스템 프록시’ → ‘시스템 프록시 자동 설정’을 선택하세요. 데스크톱 버전에 따라 메뉴 위치가 달라질 수 있으니 현재 화면에서 같은 이름의 옵션을 찾으세요.
시스템 프록시 확인

Windows ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 프록시 서버 주소와 포트를 확인하고 클라이언트가 현재 수신 중인 값과 일치하는지 확인하세요. 자동 구성 스크립트를 사용한다면 스크립트 상태를 확인하고 두 모드를 혼동하지 마세요.
별도 프록시 설정 확인

브라우저 프록시 확장 프로그램을 잠시 사용 중지한 다음 브라우저를 완전히 종료했다가 다시 여세요. 프록시를 명시한 명령은 접속되는데 브라우저만 실패한다면 노드를 바꾸기보다 브라우저 설정을 확인하세요.

두 번째: 로컬 포트가 실제로 수신 중인지 확인

프록시 주소는 원격 노드의 서버 포트가 아니라 이 기기에서 수신 중인 포트를 가리켜야 합니다. 아래 숫자는 문제 해결을 위한 예시일 뿐, 같은 값으로 바꾸라는 뜻은 아닙니다. v2rayN의 ‘설정’ → ‘매개변수 설정’에서 로컬 수신 관련 설정을 확인하세요. 버전에 따라 항목 위치가 다를 수 있으므로 시작 로그도 함께 확인할 수 있습니다. 구형 설정은 SOCKS 포트와 HTTP 포트를 따로 제공할 수 있고, 최신 설정은 혼합 포트를 사용할 수 있습니다.

127.0.0.1

이 기기에서만 연결할 수 있는 루프백 주소

10808

아래 예시에서 사용하는 로컬 SOCKS 포트

443

HTTPS에서 흔히 사용하는 대상 포트이며 로컬 프록시 포트가 아닙니다

Windows PowerShell에서 아래 명령을 실행해 로컬 수신 상태를 확인한 다음 SOCKS 프록시를 명시해 HTTPS 요청을 보내세요. 실제 포트가 다르면 명령의 10808을 해당 포트로 바꾸세요. 일부 PowerShell 환경에서는 curl이 다른 명령으로 해석될 수 있으므로 여기서는 curl.exe를 사용합니다.

Get-NetTCPConnection -State Listen -LocalPort 10808 |
  Select-Object LocalAddress, LocalPort, OwningProcess

curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

수신 기록이 없다면 먼저 코어가 시작되지 않았는지 확인하세요. 기록이 있더라도 포트를 다른 프로그램이 사용하고 있지 않은지 프로세스를 확인해야 합니다. socks5h는 대상 도메인의 조회를 프록시 측에 맡기므로, 이를 근거로 로컬 시스템 DNS가 정상이라고 판단할 수는 없습니다. HTTP 상태 코드가 반환되면 어떤 HTTP 응답 지점에는 도달했다는 뜻이지만, 예상한 사이트에 연결되었는지는 상태 코드와 인증서, 로그를 함께 살펴봐야 합니다.

판단 기준: 먼저 진입점을 고정하고 원격 연결을 점검하세요

프록시를 명시한 요청은 성공하고 브라우저만 실패한다면 브라우저나 시스템 프록시 설정부터 바로잡으세요. 로컬 포트에조차 연결할 수 없다면 수신 설정부터 해결해야 합니다. 요청이 코어에 실제로 들어간 것을 확인한 뒤에야 노드를 바꿔 비교하는 의미가 있습니다.

세 번째: 두 종류의 DNS 조회를 구분

조회가 필요한 주소는 크게 두 가지입니다. 노드 서버 도메인과 브라우저에서 접속하려는 대상 도메인입니다. 전자의 조회가 실패하면 코어가 노드에 연결하지 못할 수 있고, 후자가 실패하면 노드 테스트는 정상이지만 특정 웹페이지가 열리지 않을 수 있습니다. 브라우저 보안 DNS, 시스템 DNS, 코어 DNS가 반드시 같은 경로를 사용하는 것은 아닙니다.

확인 대상	확인 방법	결과 해석
대상 도메인의 로컬 조회	`Resolve-DnsName example.com` 실행	조회 결과가 있다는 것은 이번 시스템 조회에서 응답을 받았다는 뜻일 뿐, 노드 연결 성공을 의미하지는 않습니다.
대상 도메인의 프록시 조회	`socks5://`와 `socks5h://` 요청 비교	전자는 로컬에서 대상 도메인을 조회하고 후자는 도메인 조회를 프록시 측에 맡깁니다. 결과 차이는 조회 경로에 문제가 있을 가능성을 보여줄 수 있습니다.
노드 도메인 조회	로그에서 서버 도메인과 `lookup` 오류 확인	브라우저 캐시만 지우지 말고 노드 주소와 초기 조회 설정, 현재 네트워크 DNS를 확인하세요.
캐시된 조회 결과	조회 설정을 바로잡은 뒤 `ipconfig /flushdns` 실행	Windows 캐시를 지우고 다시 요청하세요. 브라우저와 코어에는 별도의 캐시가 남아 있을 수 있습니다.

노드 도메인을 임의로 찾은 IP 주소로 바꾸지 마세요. TLS 또는 REALITY를 사용할 때는 서버 주소, SNI, 대상 이름 사이에 설정상 제약이 있습니다. 무작정 바꾸면 DNS 문제를 핸드셰이크 실패로 악화시킬 수 있습니다. 기존 노드를 먼저 저장하고 서버에서 제공한 설정값과 대조하세요.

curl.exe --proxy socks5://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

네 번째: 라우팅 규칙이 올바른 출구를 선택하는지 확인

시스템 프록시는 요청이 클라이언트로 들어오는지를 결정하고, 라우팅 규칙은 들어온 요청이 어떤 출구로 나갈지를 결정합니다. ‘전역 프록시’는 애플리케이션 계층에서 흔히 쓰는 표현이지만 클라이언트마다 의미가 다를 수 있습니다. 문제를 기록할 때는 실제 라우팅 모드와 규칙, 출구 태그를 구체적으로 적으세요.

v2rayN의 라우팅 설정에서 테스트할 대상을 프록시 출구로 보내는 규칙 모드를 잠시 선택한 뒤 같은 주소에 다시 접속하세요. 접속이 복구되면 사용자 지정 도메인 규칙, 직접 연결 규칙, 차단 규칙을 집중적으로 살펴보세요. 테스트 후에는 원래 모드로 되돌리세요. 모든 로컬 리소스를 계속 원격으로 보낼 필요는 없습니다.

규칙 순서 확인: 일반적으로 코어는 규칙을 순서대로 적용합니다. 앞쪽의 포괄적인 규칙이 먼저 일치하면 뒤쪽의 세부 규칙은 적용되지 않을 수 있습니다.
태그 확인: routing.rules의 outboundTag는 실제로 존재하는 출구의 tag를 참조해야 하며 이름이 정확히 일치해야 합니다.
직접 연결과 프록시 구분: 로그에 요청이 직접 연결된 것으로 표시된다면 규칙이 직접 연결을 선택했다는 뜻일 뿐, 프록시 노드를 사용할 수 없다는 뜻은 아닙니다.
규칙 리소스 확인: 지역 또는 도메인 데이터 파일을 사용하는 설정에서 파일을 불러오지 못한다면 파일과 설정 참조를 먼저 수정하세요. 노드를 바꾸는 것만으로 해결되지는 않습니다.

다섯 번째: 오류 메시지에 따라 노드 점검

진입점, DNS, 라우팅을 확인한 뒤 노드 주소와 원격 포트, 사용자 식별자, 전송 방식, 보안 설정을 점검하세요. 구독 업데이트 성공은 설정을 가져왔다는 뜻이지 모든 노드가 온라인이라는 뜻은 아닙니다. 먼저 같은 구독의 다른 노드로 다시 테스트하고, 이어서 네트워크를 바꿔 기존 노드를 테스트하면 노드 문제와 현재 네트워크 제한을 빠르게 구분할 수 있습니다.

오류: connection refused

원인 및 해결: 연결 대상이 TCP 연결을 거부했습니다. 오류에 표시된 주소가 로컬인지 원격인지 확인하세요. 로컬 주소라면 수신 상태를, 원격 주소라면 노드 포트와 서비스 실행 상태를 확인하세요.

오류: i/o timeout

원인 및 해결: 네트워크 읽기 또는 쓰기 작업이 제한 시간 안에 완료되지 않았습니다. 로그에 나온 대상 주소와 진행 단계에 따라 다른 노드와 다른 네트워크를 비교하세요. 바로 DNS 문제라고 단정하지 마세요.

오류: no such host

원인 및 해결: 관련 도메인을 조회하지 못했습니다. 노드 도메인과 대상 도메인 중 어느 쪽에서 실패했는지 먼저 확인하고, 철자와 조회 서버 연결, 초기 조회 설정을 점검하세요.

오류: tls: handshake failure

원인 및 해결: TLS 핸드셰이크가 종료되었습니다. 원인은 여러 가지일 수 있습니다. 포트와 SNI, 전송 설정, 서버 측 구성을 확인하고 오류 전후 시점의 전체 로그를 보관한 뒤 판단하세요.

VLESS, VMess, Trojan의 설정값은 서로 바꿔 쓸 수 없습니다. VLESS와 REALITY를 함께 사용한다면 공개 키와 짧은 ID, 서버 이름, 서버에서 요구하는 흐름 제어 설정을 확인하세요. XTLS Vision을 사용한다면 flow가 서버 설정과 일치해야 합니다. 프로토콜 이름만으로 현재 코어나 노드 설정의 사용 가능 여부를 판단할 수는 없습니다.

기존 노드는 임시로 보관하고 구독을 업데이트한 뒤 설정값이 어떻게 달라졌는지 비교하세요. 백업 없이 일괄 삭제하지 마세요.
같은 대상에 대한 노드 A와 노드 B의 결과를 기록해 대상 사이트 자체의 문제를 노드 오류로 오인하지 마세요.
로그를 확인할 때는 오류 전후의 문맥을 함께 보관하세요. 기록을 공유하기 전에는 구독 주소, 사용자 식별자, 공개 키 외의 민감한 인증 정보와 개인 네트워크 정보를 숨기세요.

여섯 번째: 시스템 시간과 Android 트래픽 전달 확인

TLS 인증서 유효기간 검증에는 시스템 시간이 사용되며 VMess 인증에도 시간이 관여합니다. 컴퓨터나 휴대폰의 날짜가 크게 틀리면 네트워크와 포트가 정상이어도 인증 또는 인증서 오류가 발생할 수 있습니다. Windows에서는 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’으로 이동해 자동 시간 설정을 켜고 지금 동기화를 실행하세요. Android에서는 시스템 설정에서 ‘날짜 및 시간’을 검색해 자동 설정을 켜고 실제 날짜가 맞는지 확인하세요.

표시된 시간대가 다르다고 실제 시간이 잘못된 것은 아닙니다. 시계 오차를 가리기 위해 시간대만 바꾸지 말고 날짜와 실제 시각을 확인하세요. 문제를 우회하려고 인증서 검증을 끄지 마세요. 시간, 서버 이름, 인증서 체인의 이상을 숨길 수 있습니다.

VPN 권한 확인: v2rayNG를 시작한 뒤 시스템 VPN 권한을 허용해야 합니다. 다른 VPN 서비스가 실행 중이라면 먼저 종료하고 테스트하세요.
작동 모드 확인: 로컬 프록시 전용 모드는 VPN을 통한 트래픽 전달과 다릅니다. 일반 앱에서 프록시를 바로 사용하려면 VPN 모드가 활성화되어 있는지 확인하세요.
앱 범위 확인: v2rayNG ‘설정’에서 앱별 프록시 옵션을 확인하고 브라우저가 제외되지 않았는지 살펴보세요. 우회 옵션을 켜면 목록의 의미가 반대가 될 수 있습니다.
백그라운드 제한 확인: 화면이 켜져 있을 때는 정상인데 잠시 잠근 뒤 연결이 끊긴다면 시스템 앱 설정에서 v2rayNG의 배터리 및 백그라운드 실행 권한을 확인한 뒤 다시 잠금 테스트를 하세요.
네트워크별로 테스트: Wi-Fi와 모바일 데이터를 각각 테스트하세요. 네트워크를 바꾼 뒤에는 연결을 중지했다가 다시 시작해 기존 연결이 복구되지 않은 문제인지 확인하세요.

자주 묻는 질문과 점검 기록

지연 시간이 수십 밀리초인데 웹페이지가 열리지 않는 이유는 무엇인가요?

먼저 테스트 종류를 확인하세요. TCP 지연 시간은 연결의 일부 구간만 확인합니다. 실제 요청 테스트가 통과했더라도 그때 테스트한 대상에 접속할 수 있다는 뜻일 뿐입니다. 이 문서의 프록시 지정 명령으로 같은 웹사이트에 접속한 뒤 브라우저와 라우팅 경로를 확인하세요.

휴대폰에서는 되는데 같은 노드가 컴퓨터에서는 안 되나요?

먼저 두 기기를 같은 네트워크에 연결한 다음 활성 노드 설정을 비교하세요. 컴퓨터에서는 시스템 프록시와 로컬 수신 상태를 우선 확인하세요. 명령으로 요청했을 때는 되지만 브라우저에서만 실패한다면 브라우저 확장 프로그램과 별도 프록시 설정을 확인하세요.

특정 웹사이트만 열리지 않을 때 클라이언트를 다시 설치해야 하나요?

먼저 다른 노드로 같은 웹사이트에 접속한 뒤 해당 도메인에 적용된 라우팅 규칙과 DNS 결과를 확인하세요. 정상적인 HTTP 오류 응답이 돌아온다면 클라이언트 설치 문제가 아니라 대상 사이트의 접근 정책일 수도 있습니다.

재시작 후 잠시 정상으로 돌아왔습니다. 다음에는 무엇을 확인해야 하나요?

다시 실패한 시각을 기록하고 절전 모드 전환, 네트워크 변경, 백그라운드 서비스 중단이 함께 발생했는지 살펴보세요. 실패한 순간에 먼저 수신 포트와 코어 로그를 확인하고 바로 재시작하지 마세요. 중요한 당시 상태가 사라질 수 있습니다.

한 차례 점검한 뒤에는 반복해서 재설치하기보다 재현 가능한 기록을 남기는 편이 효과적입니다. DNS와 라우팅, 코어, 노드를 한꺼번에 바꾸지 말고 한 번에 한 항목만 수정하세요. 같은 테스트 대상과 대기 시간을 사용하고 변경 전후 결과를 기록하세요.

환경: 클라이언트 및 코어 버전, 운영체제 버전, Wi-Fi 또는 모바일 네트워크.
진입점: 시스템 프록시 또는 VPN 모드, 로컬 수신 주소와 포트, 앱별 설정 활성화 여부.
결과: 프록시 지정 명령에서 응답이 왔는지, 브라우저가 정상화되었는지, 다른 노드가 작동하는지.
근거: 오류 발생 시각, 관련 로그, 실제로 선택된 출구, 완료한 개별 비교 테스트.

클라이언트와 기본 설정

클라이언트 출처를 다시 확인하려면 다운로드 페이지에서 플랫폼을 선택하세요. 가져오기와 프록시 설정을 다시 하려면 먼저 가이드에 따라 기본 연결을 설정한 뒤 사용자 지정 라우팅을 복원하세요.

다운로드 페이지 가이드 보기