V2Ray 연결은 되는데 인터넷이 안 될 때: v2rayN·v2rayNG 단계별 문제 해결 체크리스트

이 글의 핵심

v2rayN이 실행 중이거나 v2rayNG에 실행 중으로 표시되는데 웹페이지가 열리지 않을 때 참고하세요. 먼저 코어 실행, 앱 트래픽 유입, 노드 연결이라는 세 단계로 나눈 뒤 로컬 포트, 프록시를 지정한 요청, 로그를 통해 원인을 찾습니다. DNS와 라우팅, 노드를 한꺼번에 바꾸면 원인을 판단하기 어려우니 한 번에 하나씩 변경하고 실패 기록을 남기세요.

1. 연결 상태 확인: 요청이 어느 단계에서 멈추는지 살펴보기

v2rayN의 코어 실행 알림이나 v2rayNG의 실행 상태는 해당 프로세스 또는 로컬 VPN 서비스가 시작됐다는 뜻일 뿐입니다. 브라우저 요청이 프록시에 전달됐거나 원격 서버와 프로토콜 핸드셰이크를 마쳤다는 의미는 아닙니다. 노드 옆에 지연 시간이 표시되더라도 테스트 종류를 확인해야 합니다. TCP 연결 테스트는 포트만 확인하므로 프록시가 정상 작동하는지는 검증하지 못합니다.

앱 요청 로컬 진입점 라우팅 규칙 적용 노드 핸드셰이크 대상 서버 응답

다운로드와 백그라운드 동기화를 잠시 멈추고 노드 하나, 브라우저 하나, 테스트 주소 하나를 정하세요. 데스크톱에서는 우선 일반 로컬 프록시만 사용하고 TUN과 시스템 프록시를 함께 테스트하지 마세요. Android에서는 VPN 모드를 사용 중인지 확인하고 브라우저가 앱별 프록시 제외 대상이 아닌지도 살펴보세요.

모든 앱에서 실패: 코어, 로컬 리스닝, 노드 연결을 먼저 확인합니다.
브라우저에서만 실패: 시스템 프록시, 브라우저 자체 프록시 설정, 확장 프로그램을 확인합니다.
일부 도메인에서만 실패: DNS, 분할 라우팅 규칙, IPv6 출구를 먼저 확인합니다.
노드 하나에서만 실패: 해당 노드의 로그를 저장한 뒤 정상 작동이 확인된 노드와 비교합니다.

2. 시스템 시간과 기본 네트워크: 프록시 외부의 문제부터 확인

프록시를 끄고 원래 직접 접속되던 사이트에 로컬 네트워크로 접속할 수 있는지 확인하세요. 이 상태에서도 접속되지 않으면 Wi-Fi 로그인 페이지, 게이트웨이, 네트워크 권한, 통신사 연결부터 점검해야 합니다. 프록시 클라이언트는 끊어진 기본 네트워크를 복구할 수 없습니다. 공용 네트워크에서 웹 인증을 마치지 않았다면 노드 연결도 계속 시간 초과될 수 있습니다.

시스템의 날짜와 시각, 시간대를 확인하세요. TLS 인증서 유효기간 검증에는 정확한 시각이 필요하고 VMess 인증도 시각 오차에 민감합니다. 화면에 표시된 시간대가 다르다는 이유만으로 오류라고 단정하지 마세요. 중요한 것은 화면에 어떤 시간대가 표시되는지가 아니라 기기의 실제 시각이 정확한지입니다.

Windows: 「설정」→「시간 및 언어」→「날짜 및 시간」에서 자동으로 시간 설정을 켠 다음 지금 동기화를 실행합니다.
Linux: timedatectl status를 실행해 현재 시각과 System clock synchronized 항목을 확인합니다. 동기화되지 않았다면 배포판의 시간 서비스 설정을 점검하세요.
Android: 시스템 설정에서 「날짜 및 시간」을 검색하고 날짜 및 시간 자동 설정을 켭니다. 메뉴 위치는 시스템마다 다를 수 있습니다.
네트워크 비교: 휴대전화에서 Wi-Fi와 모바일 네트워크를 한 번씩 바꿔 접속해 보세요. 같은 노드가 특정 네트워크에서만 실패하면 해당 네트워크의 연결 제한이나 DNS를 점검합니다.

3. 로컬 포트: 코어가 실제로 리스닝 중인지 확인

v2rayN 창이 열려 있다고 프록시 진입점이 만들어진 것은 아닙니다. 「설정」→「매개변수 설정」에서 로컬 리스닝 주소와 포트, 진입점 유형을 확인하세요. 데스크톱 버전에 따라 메뉴 이름은 다를 수 있습니다. 아래에서는 127.0.0.1:10808을 예로 들었으니 화면에 표시된 실제 값으로 바꿔 사용하세요. 이전 설정은 SOCKS 포트와 HTTP 포트를 따로 제공할 수 있고, 새 설정은 혼합 진입점을 사용할 수도 있습니다.

Windows PowerShell 또는 Linux 터미널에서 해당 명령을 실행하세요. 확인 대상은 TCP 리스닝 상태이지 노드 주소가 아닙니다. 루프백 주소에서 리스닝하면 보통 이 기기에서 사용하기에 충분하며, 문제 해결을 위해 모든 네트워크 인터페이스에서 리스닝하도록 바꿀 필요는 없습니다.

# Windows PowerShell: 10808의 TCP 리스닝 프로세스 확인
Get-NetTCPConnection -LocalPort 10808 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# Linux: 같은 포트와 프로세스 확인
ss -lntp 'sport = :10808'

점검 결과	설명	다음 단계
리스닝 기록 없음	포트를 잘못 입력했거나 코어가 정상적으로 시작되지 않았습니다	설정을 확인하고 시작 단계 로그를 살펴봅니다
다른 프로그램이 리스닝 중	로컬 포트 충돌	충돌하는 프로세스를 종료하거나 사용 가능한 포트로 변경합니다
코어 프로세스가 정상적으로 리스닝 중	로컬 진입점이 설정되었습니다	프록시를 지정한 요청 테스트를 계속합니다

포트를 바꾸면 시스템 프록시, 브라우저의 별도 설정, 터미널 환경 변수도 함께 업데이트해야 합니다. 클라이언트 포트만 10808에서 10818로 바꾸고 앱이 이전 포트를 계속 사용하면 코어는 정상 실행 중인데 웹페이지는 계속 열리지 않을 수 있습니다. 포트 충돌이 보인다고 방화벽을 바로 끄지 마세요. 먼저 해당 포트를 사용하는 프로세스가 별도로 실행 중인 코어인지 확인합니다.

4. 시스템 프록시: 프록시 진입점과 노드 문제 구분하기

데스크톱의 v2rayN에서 「시스템 프록시」 메뉴를 열고 「시스템 프록시 자동 설정」을 선택한 뒤 운영체제에 실제로 기록된 프록시 주소를 확인하세요. Windows에서는 「설정」→「네트워크 및 인터넷」→「프록시」에서 확인할 수 있습니다. HTTP 프록시 항목에는 HTTP 또는 혼합 진입점을 입력해야 합니다. SOCKS만 지원하는 포트를 HTTP 포트처럼 사용할 수는 없습니다.

시스템 프록시가 모든 앱의 트래픽을 투명하게 가로채는 것은 아닙니다. 일부 명령줄 프로그램, 게임, 브라우저 확장 프로그램은 자체 프록시 설정을 사용하거나 시스템 설정을 아예 무시합니다. 이 차이를 배제하려면 curl로 로컬 SOCKS 진입점에 직접 연결해 보세요. 아래 테스트 도메인은 요청 흐름 확인용이며, 응답 상태 코드는 응답 내용과 함께 판단해야 합니다.

# Windows: 구버전 PowerShell의 동명 별칭을 피하려면 curl.exe 호출
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

# Linux: 로컬 SOCKS 진입점을 통해 같은 요청 보내기
curl --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

socks5h는 대상 도메인을 SOCKS 프록시 측에서 처리하도록 전달합니다. 실제로 코어가 DNS를 사용하는지 원격에서 조회하는지는 설정에 따라 달라집니다. 연결 제한 10초와 전체 제한 20초는 진단용 값이며 성능을 보장하지 않습니다. HTTP 진입점만 사용 중이라면 프록시 인수를 --proxy http://127.0.0.1:10808로 바꾸고 실제 HTTP 포트를 지정하세요.

판단: 프록시를 지정한 요청은 성공한다면 앱 진입점부터 점검

curl에서 유효한 HTTP 응답을 받는데 브라우저는 여전히 실패한다면 브라우저 프록시 확장 프로그램, 시스템 프록시 주소, 우회 목록을 먼저 확인하세요. 이때 노드를 바로 바꾸거나 DNS 설정을 다시 작성하지 마세요. 일부 서버는 HEAD 요청을 거부해 405를 반환할 수 있으며, 이것만으로 프록시 연결 실패라고 볼 수는 없습니다.

로컬 포트 연결이 거부됨: 앞 절로 돌아가 리스닝 주소와 진입점 유형을 확인합니다.
로컬 포트에는 연결되지만 요청 시간이 초과됨: 같은 시각의 노드 핸드셰이크와 아웃바운드 로그를 확인합니다.
페이지 응답은 오지만 특정 웹사이트만 오류: 라우팅 출구, 대상 사이트 제한, DNS 결과를 비교합니다.

5. v2rayNG: VPN 권한과 앱별 프록시 확인

Android에서는 데스크톱 시스템 프록시 점검 방법을 그대로 적용할 수 없습니다. v2rayNG의 VPN 모드는 Android VPN 서비스를 통해 앱 트래픽을 전달하지만 실행 중이라고 해서 모든 앱의 트래픽을 처리하는 것은 아닙니다. 먼저 메인 화면에서 서비스를 시작하고 시스템에서 VPN 권한을 허용했는지 확인하세요. 다른 VPN 서비스가 연결을 사용 중인지도 살펴봅니다.

실행 모드 확인: v2rayNG의 「설정」으로 이동해 VPN 모드가 선택되어 있는지 확인합니다. 프록시 모드만으로는 모든 앱의 트래픽을 자동으로 처리하지 않습니다.
앱 범위 확인: 「설정」에서 「앱별 프록시」를 찾아 브라우저가 제외되지 않았는지 확인합니다. 선택한 앱만 프록시하는 모드라면 브라우저를 선택해야 하고, 제외 모드라면 반대로 설정합니다.
시스템 VPN 확인: 시스템 설정에서 「VPN」을 검색해 현재 v2rayNG가 연결되어 있는지 확인합니다. 「항상 사용」이나 「VPN 연결 없이 연결 차단」 옵션도 의도한 설정과 일치하는지 살펴보세요.
백그라운드 제한 확인: 화면을 잠근 뒤 연결이 끊긴다면 앱 정보의 배터리 설정에서 백그라운드 실행을 허용한 후 다시 잠금 상태에서 테스트합니다. 권한 이름은 기기 시스템에 따라 다를 수 있습니다.

노드의 실제 연결 테스트가 성공했다고 앱별 설정까지 올바르다는 뜻은 아닙니다. 테스트는 클라이언트가 직접 보낼 수 있지만 브라우저는 여전히 제외되어 있을 수 있습니다. v2rayNG는 Xray 코어를 사용합니다. 다른 기기에서 V2fly 코어를 사용하는 v2flyNG를 쓴다면 프로토콜 지원과 노드 매개변수도 각각 확인해야 합니다. 구독 이름이 같다고 실행 설정까지 같다고 단정하지 마세요.

6. 코어 로그: 실제 오류를 기준으로 원인 찾기

이전 로그를 지운 뒤 실패 요청을 한 번만 보내고 v2rayN의 코어 로그 또는 v2rayNG의 로그 화면을 확인하세요. 발생 시간, 연결 단계, 오류 전후 문맥을 기록합니다. 코어 버전에 따라 오류 형식이 달라질 수 있으므로 아래 문구는 흔히 보이는 예시이며 매번 같은 전체 로그가 나타나는 것은 아닙니다.

오류: `address already in use`

원인: 리스닝 주소와 포트가 이미 사용 중이라 코어가 바인딩하지 못했습니다.

해결: 포트 조회 명령으로 프로세스를 찾고 중복 실행을 종료하거나 사용 가능한 포트로 변경한 뒤 앱의 프록시 설정도 함께 수정합니다.

오류: `connection refused`

원인: 연결 대상이 요청을 명시적으로 거부했습니다. 대상은 로컬 진입점일 수도 있고 원격 노드일 수도 있습니다.

해결: 로그에 표시된 주소부터 확인합니다. 로컬 주소라면 리스닝 상태를, 원격 주소라면 노드 포트와 서비스 상태를 점검합니다.

오류: `i/o timeout`

원인: 연결 또는 읽기·쓰기가 제한 시간 안에 완료되지 않았습니다. 네트워크 경로, 서버, 핸드셰이크 단계가 원인일 수 있습니다.

해결: 다른 네트워크와 정상 작동이 확인된 노드에서 비교하고 전후 로그를 보관해 연결 시간 초과와 연결 후 읽기 시간 초과를 구분합니다.

오류: `x509: certificate has expired or is not yet valid`

원인: 인증서 유효기간 검증에 실패했습니다. 기기 시각이 틀렸거나 서버 인증서에 문제가 있을 수 있습니다.

해결: 먼저 시스템 시간을 동기화한 다음 서버 인증서 상태를 확인하세요. 인증서 검증을 건너뛰는 방법을 장기적인 해결책으로 삼지 마세요.

오류: `no such host`

원인: 사용할 수 있는 도메인 조회 결과를 얻지 못했습니다. 노드 도메인과 웹페이지 도메인을 구분해야 합니다.

해결: 도메인 철자와 실제 DNS 경로를 확인합니다. 노드 도메인 조회가 실패했다면 프록시 연결 전 단계의 이름 조회부터 복구하세요.

로그에서 노드 연결은 확인되지만 이후 핸드셰이크가 실패한다면 구독 만료 여부, 인증 정보 일치 여부, 전송 방식, 경로, TLS 서버 이름 등의 매개변수를 점검하세요. VLESS 노드에서 REALITY를 사용한다면 공개 키, 짧은 ID, 흐름 제어 설정도 확인해야 합니다. VMess, VLESS, 전송 설정을 서로 바꿔가며 시도하지 말고 서버에서 제공한 전체 설정을 기준으로 점검하세요.

7. DNS와 라우팅: 일부 웹사이트가 열리지 않을 때

로컬 진입점과 프록시 요청 하나 이상이 정상인지 확인한 뒤 DNS와 분할 라우팅을 점검하세요. Windows의 nslookup example.com, Linux의 getent ahosts example.com으로 시스템 쪽 조회를 확인할 수 있지만 코어 내장 DNS가 정상이라는 뜻은 아닙니다. 브라우저에서 보안 DNS를 사용하면 세 번째 조회 경로가 생길 수도 있습니다.

같은 도메인을 시스템 조회와 프록시를 지정한 요청에서 각각 테스트해 비교하세요. DNS를 바꿀 때는 기존 설정을 기록하고 한 번에 한 항목만 변경합니다. 특히 노드 연결에 필요한 서버 도메인은 먼저 조회되어야 합니다. 해당 도메인 조회가 노드를 거쳐야만 접속할 수 있는 DNS에 의존한다면 시작 단계에서 순환 의존성이 생길 수 있습니다.

증상	우선 점검 항목	비교 방법
시스템 조회는 실패하지만 프록시 요청은 성공	시스템 DNS 또는 브라우저의 조회 경로	앱이 도메인 조회를 프록시에 전달하는지 확인
전역 프록시는 성공하지만 분할 라우팅 모드는 실패	직접 연결 규칙, 분류 데이터, 규칙 순서	로그에서 해당 요청의 아웃바운드 태그 확인
도메인에 AAAA 레코드가 있을 때 실패	IPv6 연결과 출구 지원 여부	실제 연결 주소를 확인하고 IPv4로 임시 비교
브라우저만 실패하고 다른 앱은 정상	브라우저 보안 DNS 및 별도 프록시	관련 확장 프로그램을 잠시 중지하고 같은 주소로 재테스트

클라이언트의 「라우팅」 메뉴에서 전역 프록시 설정으로 잠시 전환한 뒤 같은 주소를 테스트하고 원래 설정으로 되돌릴 수 있습니다. 전역 프록시는 이미 코어에 들어온 트래픽의 출구만 바꾸며, 시스템 프록시를 무시하는 앱까지 자동으로 연결하지는 않습니다. 전역 모드는 정상인데 분할 라우팅에서 실패한다면 범위가 넓은 직접 연결 규칙이 먼저 적용되는지 확인하세요. V2Ray/Xray 라우팅 규칙은 순서대로 적용되므로 앞에서 일치한 규칙이 이후 판단에 영향을 줍니다.

8. 재테스트와 자주 묻는 질문: 최소한의 문제 기록 남기기

문제를 해결한 뒤 기본 네트워크, 로컬 리스닝, 프록시를 지정한 요청, 브라우저, 기존에 실패했던 웹사이트 순서로 다시 테스트하세요. 한 번에 한 항목만 바꿔 안정적으로 결과가 달라져야 실제 원인을 찾기 쉽습니다. 구독 업데이트와 노드 연결은 별개의 작업입니다. 업데이트에 실패해도 기존 노드가 작동할 수 있고, 기존 노드가 작동하더라도 현재 구독 주소에 접속할 수 있다는 뜻은 아닙니다.

노드 지연 시간은 표시되는데 웹페이지가 열리지 않는 이유는 무엇인가요?

먼저 지연 시간 테스트가 TCP 테스트에 불과한지 확인하세요. 이어서 프록시를 지정한 요청을 보내고 핸드셰이크 로그를 확인합니다. 포트 연결에 성공해도 인증, TLS, 전송 매개변수가 일치하지 않을 수 있습니다.

v2rayN을 종료한 뒤 브라우저도 인터넷에 연결되지 않나요?

클라이언트를 다시 열고 「시스템 프록시」 메뉴에서 「시스템 프록시 지우기」를 선택한 다음 시스템 프록시 주소가 여전히 로컬 포트를 가리키는지 확인합니다. 조직에서 관리하는 PC라면 기존 프록시 설정부터 확인하세요.

v2rayNG은 실행 중인데 브라우저만 연결되지 않나요?

「설정」에서 「앱별 프록시」의 포함 또는 제외 모드를 확인해 브라우저가 프록시 적용 범위에 들어가도록 설정하세요. 브라우저를 완전히 종료했다가 다시 열고 다른 VPN 서비스가 연결을 가로채고 있지 않은지도 확인합니다.

DNS를 바꿔도 해결되지 않는데 재설치해야 하나요?

먼저 원래 DNS 설정을 복원하고 요청이 코어에 전달되는지, 로그에서 어느 단계가 실패하는지 확인하세요. 재설치 전에 설정과 버전 정보를 저장합니다. 로컬 리스닝, 시스템 프록시, 서버 매개변수에 문제가 있다면 재설치만으로 원인을 찾기 어렵습니다.

환경 기록: 운영체제, 클라이언트 버전, 코어 버전, 네트워크 종류.
진입점 기록: 시스템 프록시 또는 VPN 모드, 로컬 포트, 앱별 설정.
비교 결과 기록: 같은 요청이 다른 노드나 다른 네트워크에서 성공하는지 확인합니다.
로그 기록: 실패 전후의 관련 줄을 보관하고 공유 전에 구독 주소, 인증 정보, 개인 네트워크 정보를 삭제합니다.

기본 설정은 빠른 시작 가이드를 참고하세요. DNS와 라우팅을 더 살펴보려면 사용 설명서의 DNS 설정을 확인하세요. 먼저 실패 단계를 파악한 뒤 해당 설정만 바꾸면 구독을 반복해서 가져오거나 여러 옵션을 한꺼번에 변경하는 것보다 같은 결과를 재현하고 원인을 찾기 쉽습니다.