V2Ray 연결은 됐는데 웹페이지가 열리지 않나요? 12가지 단계별 문제 해결 체크리스트

이 글 한눈에 보기

v2rayN에 “시작됨”, v2rayNG에 “연결됨”으로 표시되지만 브라우저가 계속 시간 초과되거나 일부 웹사이트 또는 모든 앱에서 인터넷이 되지 않는 경우에 적용됩니다. 로컬 프록시 진입점부터 시작해 노드 핸드셰이크, 라우팅 분기, DNS를 차례로 확인하면 구독을 반복해서 삭제하지 않고도 문제를 클라이언트, 노드 설정, 규칙, DNS 경로 중 한 단계로 좁힐 수 있습니다.

먼저 문제가 발생한 단계를 확인하세요

클라이언트에 연결됨으로 표시된다는 것은 화면에서 코어에 시작 명령을 전달했다는 뜻일 뿐입니다. 브라우저 트래픽이 프록시로 들어갔는지, 원격 노드가 핸드셰이크를 완료했는지는 보장하지 않습니다. 하나의 요청은 최소한 애플리케이션, 시스템 프록시 또는 TUN, 라우팅 판단, 프록시 아웃바운드, DNS 확인을 거칩니다. 어느 한 단계라도 실패하면 겉으로는 웹페이지가 계속 로딩되는 것처럼 보일 수 있습니다.

시작하기 전에 테스트 조건을 고정하세요. 다운로드 중인 작업은 중지하고 브라우저 창 하나만 남긴 뒤, 접속 가능한 일반 HTTPS 웹사이트 하나를 선택해 테스트합니다. 노드, 라우팅 모드, DNS를 동시에 바꾸지 말고 한 번에 변수 하나만 변경하세요. 변경 후 같은 페이지를 다시 로드하고 결과를 기록합니다.

브라우저 요청로컬 프록시 진입점라우팅 규칙 일치노드 연결 수립DNS 주소 반환대상 사이트 응답

범위를 좁힐 때는 두 가지를 비교해 볼 수 있습니다. 첫 번째는 시스템 프록시를 끈 상태에서 로컬 네트워크에 접속한 뒤, 시스템 프록시를 켜고 같은 주소에 접속하는 방법입니다. 두 번째는 현재 노드와 정상 작동이 확인된 다른 노드를 번갈아 사용하는 방법입니다. 모든 노드에서 실패한다면 로컬 진입점, 라우팅 또는 DNS 문제일 가능성이 높고, 한 노드에서만 실패한다면 해당 노드의 상태와 설정 항목을 먼저 확인해야 합니다.

1단계: 로컬 설정 3가지 점검

로컬 단계에서는 애플리케이션 트래픽을 코어로 전달합니다. 가장 흔한 문제는 시스템 프록시가 활성화되지 않았거나, 수신 포트를 다른 프로그램이 사용 중이거나, 브라우저에 별도의 프록시 설정이 남아 있는 경우입니다. v2rayN 7.x에서는 클라이언트 실행 후 작업 표시줄 아이콘만 보지 말고 코어 상태와 시스템 프록시 상태를 함께 확인해야 합니다.

1번: 시스템 프록시가 실제로 활성화되어 있는지 확인합니다. v2rayN 메인 창에서 시스템 프록시 모드가 “시스템 프록시 지우기”로 설정되어 있지 않은지 확인합니다. 그런 다음 Windows의 “설정”→“네트워크 및 인터넷”→“프록시”로 이동해 수동 프록시가 로컬 주소를 가리키는지 확인합니다. 일반적인 수신 주소는 127.0.0.1이며, 포트는 v2rayN의 현재 로그 또는 “설정”→“매개변수 설정”에 표시된 로컬 포트를 기준으로 해야 합니다. 기존 설정에서는 SOCKS 포트가 10808, HTTP 포트가 10809인 경우가 많지만, 업그레이드나 설정 이전 후에도 포트가 같다고 단정해서는 안 됩니다.
2번: 코어가 해당 포트에서 실제로 수신 중인지 확인합니다. Windows에서는 PowerShell로 로컬 포트를 테스트할 수 있습니다. 결과의 TcpTestSucceeded가 False라면 브라우저에 프록시 주소가 입력되어 있어도 연결을 받을 로컬 프로세스가 없다는 뜻입니다. 먼저 v2rayN을 완전히 종료한 뒤 다시 시작하세요. 그래도 실패하면 로그에서 포트 점유 정보를 확인하고 “설정”→“매개변수 설정”에서 사용되지 않는 포트로 변경합니다.
3번: 애플리케이션 자체의 프록시 덮어쓰기를 배제합니다. 일부 브라우저나 개발 도구는 별도의 프록시 주소를 사용할 수 있습니다. 시스템 프록시가 127.0.0.1:10809인데 애플리케이션이 이미 중지된 127.0.0.1:7890을 가리키고 있다면 요청이 현재 코어로 들어가지 않습니다. 애플리케이션 프록시를 “시스템 프록시 사용”으로 바꾸고 애플리케이션을 재시작한 뒤 다시 테스트하세요. 명령줄 도구는 환경 변수에 오래된 HTTP 또는 SOCKS 프록시 값이 남아 있지 않은지도 확인해야 합니다.

Test-NetConnection 127.0.0.1 -Port 10808
Test-NetConnection 127.0.0.1 -Port 10809

오류:failed to listen TCP on 127.0.0.1:10808

원인 및 해결: 로컬 포트가 다른 프로세스에 의해 사용 중입니다. 기존 코어 프로세스를 종료하거나 “설정”→“매개변수 설정”에서 로컬 수신 포트를 변경한 뒤 재시작하세요.

오류:connectex: No connection could be made because the target machine actively refused it

원인 및 해결: 애플리케이션이 연결하려는 로컬 포트에서 서비스가 수신 중이지 않습니다. 시스템 프록시 포트와 코어 로그의 inbound 포트가 일치하는지 확인하세요.

Android에서 v2rayNG 또는 v2flyNG를 사용할 때는 시스템 VPN 인터페이스가 로컬 진입점을 담당합니다. 연결을 눌렀는데 상태가 곧바로 연결 안 됨으로 돌아간다면 먼저 시스템 VPN 인터페이스를 점유한 다른 네트워크 도구를 중지한 뒤 다시 연결 권한을 부여하세요. 연결 상태는 유지되지만 일부 앱에서만 실패한다면 해당 앱이 “앱별 프록시” 우회 목록에 포함되어 있는지 확인합니다.

결론: 로컬 포트가 실패했다면 먼저 노드를 바꾸지 마세요

127.0.0.1 연결이 모두 실패한다면 트래픽이 아직 원격 노드에 도달하지 않은 것입니다. 구독을 계속 업데이트하거나 VMess, VLESS 매개변수를 수정해도 로컬 수신 문제는 해결되지 않습니다.

2단계: 노드 상태 및 핸드셰이크 매개변수 3가지 점검

로컬 포트가 정상이라면 다음으로 노드가 TCP, TLS 또는 다른 전송 계층 연결을 수립할 수 있는지 확인합니다. 지연 시간 테스트는 최종 사용 가능성을 증명하지 않지만, 주소에 전혀 도달하지 못하는 경우와 핸드셰이크 후 요청이 실패하는 경우를 빠르게 구분하는 데 도움이 됩니다. 테스트 결과의 유형도 함께 확인해야 합니다. ICMP 지연, TCP 지연, 실제 연결 지연 중 하나만으로는 전체 웹 요청을 대신할 수 없습니다.

4번: 노드 주소와 포트의 연결 가능성을 테스트합니다. v2rayN 노드 목록에서 현재 노드를 선택하고 실제 연결 지연 시간 테스트를 실행합니다. 일반적인 가정용 네트워크에서는 수십~수백 밀리초가 나올 수 있습니다. 3회 연속 시간 초과가 발생하고 로그가 서버 연결 단계에서 멈춘다면 서버 도메인과 포트를 확인하세요. 지연이 큰 연결을 완전히 도달 불가로 오판하지 않도록 시간 초과 기준을 잠시 5000밀리초로 설정해 다시 테스트할 수 있습니다.
5번: 시스템 시간을 보정하고 TLS 핸드셰이크를 확인합니다. TLS 인증서 검증에는 기기 시간이 사용됩니다. 시스템 시간이 몇 분만 어긋나도 인증서가 아직 유효하지 않거나 이미 만료된 것으로 판단될 수 있습니다. Windows에서는 “설정”→“시간 및 언어”→“날짜 및 시간”으로 이동해 자동 시간 설정을 켜고 즉시 동기화하세요. Android 기기에서는 시스템 날짜 및 시간 설정에서 네트워크 제공 시간 사용을 활성화합니다. 동기화 후 코어를 완전히 중지했다가 다시 연결하세요.
6번: 노드 설정을 항목별로 대조합니다. VMess에서는 주소, 포트, 사용자 ID, 전송 방식, TLS, 경로를 중점적으로 확인합니다. VLESS에서는 flow, 보안 유형, 서버 이름, Reality 관련 공개 키 매개변수도 노드 설정에 맞는지 확인해야 합니다. WebSocket 경로의 슬래시, gRPC serviceName의 대소문자, TLS 서버 이름은 정확히 일치해야 합니다. 프로토콜 이름만 보고 임의로 항목을 추가하지 말고 실제 서버 설정 또는 최신 구독 내용을 기준으로 하세요.

관찰 결과	가능성이 높은 원인	다음 조치
모든 노드에서 시간 초과	로컬 네트워크 제한, DNS 또는 클라이언트 진입점 이상	다른 네트워크와 비교하고 DNS 단계 점검 계속하기
하나의 노드에서만 시간 초과	노드 주소, 포트 또는 서비스 상태 이상	구독을 업데이트하고 해당 노드의 설정 항목 확인
TCP는 연결되지만 TLS 실패	시간, SNI 또는 인증서 체인 문제	시간 동기화 후 서버 이름 확인
지연 시간은 정상이지만 웹페이지가 빈 화면으로 표시됨	라우팅, DNS 또는 대상 사이트 응답 이상	도메인 일치 결과와 DNS 로그 확인

오류:context deadline exceeded

원인 및 해결: 연결 또는 핸드셰이크가 설정된 시간 안에 완료되지 않았습니다. 먼저 노드 주소와 포트를 테스트하고 다른 네트워크와 비교하세요. 해당 노드에서만 실패한다면 구독을 업데이트하거나 설정 제공자에게 서비스 상태를 확인하세요.

오류:remote error: tls: handshake failure

원인 및 해결: TLS 매개변수가 서버와 일치하지 않습니다. 시스템 시간을 동기화하고 TLS 활성화 여부, 서버 이름, 전송 계층 매개변수를 확인하세요.

오류:failed to find an available destination

원인 및 해결: 아웃바운드 서버 주소를 확인할 수 없거나 사용 가능한 대상이 없습니다. 노드 주소의 오탈자를 확인하고 사용 가능한 DNS로 변경한 뒤 코어를 재시작하세요.

3단계: 라우팅 분기 3가지 점검

노드 핸드셰이크는 성공했는데 웹페이지가 여전히 열리지 않는다면 라우팅 규칙을 중점적으로 확인해야 합니다. V2Ray 및 Xray 코어는 도메인, IP, 포트, 네트워크 유형, inbound 태그에 따라 아웃바운드를 선택합니다. 규칙이 대상을 direct 또는 차단 아웃바운드로 잘못 보내면 노드 자체는 연결된 상태이므로 화면에는 정상 연결로 표시될 수 있습니다.

7번: 가장 단순한 프록시 모드로 전환해 비교합니다. 라우팅을 잠시 모든 트래픽을 프록시로 보내는 테스트 모드로 전환하고 실패한 웹사이트를 다시 엽니다. 즉시 복구된다면 노드와 로컬 진입점은 정상이며 문제는 분기 규칙에 집중됩니다. 테스트가 끝나면 원래 모드로 되돌리고 일치한 규칙을 하나씩 확인하세요. 규칙 오류를 가린 채 비교 모드를 장기간 사용해서는 안 됩니다.
8번: GeoIP 및 GeoSite 데이터가 누락되었거나 오래되지 않았는지 확인합니다. 사용자 지정 규칙은 geoip:cn, geosite:cn 또는 다른 분류 집합을 참조하는 경우가 많습니다. 데이터 파일이 없으면 코어에서 규칙 로드 실패가 표시될 수 있고, 데이터가 오랫동안 업데이트되지 않으면 새 도메인이 기본 규칙으로 빠질 수 있습니다. v2rayN은 메인 화면의 업데이트 확인 기능에서 Geo 파일을 업데이트할 수 있습니다. 완료 후 코어를 재시작하고 로그에 리소스 로드 오류가 없는지 확인하세요. Android에서는 클라이언트가 제공하는 데이터 업데이트 메뉴를 사용한 뒤 다시 연결합니다.
9번: 도메인 스니핑과 규칙 우선순위를 확인합니다. 브라우저 요청이 먼저 IP로 해석되는데 규칙이 도메인으로만 일치한다면 대상이 예상한 아웃바운드를 우회할 수 있습니다. 도메인 스니핑을 켜면 코어가 HTTP Host 또는 TLS Server Name에서 도메인을 복원해 라우팅에 사용할 수 있지만, 일부 로컬 네트워크 서비스에는 스니핑이 적합하지 않습니다. 먼저 실패한 웹사이트가 로그에 도메인으로 표시되는지 IP로 표시되는지 확인한 뒤 스니핑 설정을 조정하세요. 사용자 지정 규칙은 일반적으로 위에서 아래 순서로 일치하므로, 범위가 넓은 direct 규칙을 더 구체적인 프록시 규칙보다 앞에 배치해서는 안 됩니다.

도메인 규칙: domain:example.com
접미사 규칙: domainSuffix:example.com
완전 일치: full:service.example.com
포트 범위: 80,443
기본 동작: proxy / direct / block

특정 웹사이트 하나만 열리지 않으면 노드를 바꿔야 하나요?

먼저 코어 로그에서 해당 도메인을 검색해 proxy, direct, block 중 어디로 전달되었는지 확인하세요. 다른 웹사이트가 정상이라면 규칙 일치 결과나 DNS 응답을 먼저 수정하고 전체 구독을 바로 삭제하지 마세요.

전체 프록시로 전환하면 복구되는데 어떻게 수정해야 하나요?

원래 분기 모드로 돌아간 뒤 실패한 도메인을 명시적인 프록시 규칙에 추가하고, 범위가 넓은 direct 규칙보다 앞에 배치하세요. 코어를 재시작한 후 로그의 최종 아웃바운드 태그를 다시 확인합니다.

Geo 데이터를 업데이트했는데도 이전 규칙과 일치하나요?

코어를 완전히 중지했다가 다시 시작하고, 로그에 새 파일 경로가 로드되었는지 확인하세요. 클라이언트에 여러 설정이 남아 있다면 현재 활성화된 라우팅 구성이 방금 수정한 구성인지도 확인해야 합니다.

로컬 네트워크 주소가 프록시로 전달된 후 접속되지 않나요?

사설 주소 대역과 로컬 도메인에 우선순위가 높은 direct 규칙을 추가하고, 도메인 스니핑이 로컬 네트워크 요청을 외부 도메인으로 바꾸고 있지 않은지 확인하세요.

결론: 전체 프록시에서는 되고 분기 모드에서만 실패한다면 명확한 단서입니다

같은 노드와 같은 네트워크에서 라우팅 모드만 바꿔 접속이 복구된다면 프로토콜 매개변수를 수정할 필요가 없습니다. 규칙 순서, Geo 데이터, 최종 아웃바운드 태그 확인에 집중하세요.

4단계: DNS 확인 3가지 점검

DNS 문제는 노드 지연 시간과 IP 연결은 정상이지만 도메인으로 접속한 웹페이지가 열리지 않는 형태로 자주 나타납니다. 메인 페이지는 열리지만 이미지나 로그인 API가 시간 초과되는 경우도 있는데, 하위 도메인마다 다른 주소가 반환되기 때문입니다. 점검할 때는 “노드 서버 도메인 확인”과 “접속 대상 도메인 확인”을 구분해야 합니다. 전자가 실패하면 노드 연결 수립이 막히고, 후자는 노드 연결이 완료된 뒤 발생합니다.

10번: DNS 서버 자체에 도달할 수 있는지 확인합니다. 프록시를 통해서만 접속할 수 있는 DNS 서비스를 사용하면서 DNS 질의를 direct로 라우팅하면 질의가 계속 시간 초과될 수 있습니다. 반대로 로컬 도메인을 모두 원격 DNS로 보내면 현재 네트워크에 적합하지 않은 주소가 반환될 수도 있습니다. 먼저 시스템 DNS를 임시로 사용해 비교하세요. 복구된 뒤에는 로컬 질의와 프록시 질의의 아웃바운드 경로를 각각 설정하고 로그에서 질의 시간을 확인합니다. 일반적인 질의는 수십~수백 밀리초 안에 반환되어야 하며, 2000밀리초를 계속 초과하면 이상으로 판단해야 합니다.
11번: 캐시를 비우고 FakeDNS 사용 범위를 확인합니다. 브라우저, 시스템, 코어가 각각 DNS 결과를 캐시할 수 있습니다. DNS를 변경한 뒤 관련 프로세스를 재시작하지 않으면 테스트에 이전 주소가 계속 사용될 수 있습니다. Windows에서는 브라우저를 닫고 시스템 DNS 캐시를 지운 다음 v2rayN을 재시작하세요. TUN과 FakeDNS를 사용할 때는 가상 주소 풀이 해당 트래픽 경로에서만 사용되는지 확인해야 합니다. 애플리케이션이 가상 주소를 받았는데 TUN을 우회해 direct로 연결하면 반드시 실패합니다.
12번: IPv4와 IPv6 반환 결과를 확인합니다. 일부 네트워크는 AAAA 레코드를 확인할 수 있지만 안정적인 IPv6 출구가 없습니다. 이 경우 브라우저가 도달할 수 없는 주소를 먼저 시도하고 시간 초과를 기다릴 수 있습니다. 로그에 대상이 IPv6로 우선 연결되고 매번 수 초 후 IPv4로 되돌아간다면 도메인 정책을 잠시 IPv4 우선으로 조정해 비교하세요. 문제가 확인되면 로컬 IPv6 네트워크를 수정하거나 현재 환경에 맞는 질의 정책을 유지해야 하며, 모든 DNS 문제를 노드 탓으로 돌려서는 안 됩니다.

테스트 현상	판단 기준	해결 방향
IP로는 접속되지만 도메인 접속 실패	대상 주소 확인 경로 이상	DNS 서버와 질의 아웃바운드 확인
노드 도메인을 확인할 수 없음	프록시가 수립되기 전에 실패	노드 주소에 직접 도달 가능한 부트스트랩 DNS 설정
일부 하위 도메인에서 시간 초과	캐시 또는 분기 결과 불일치	캐시를 비우고 도메인별 일치 결과 확인
몇 초 기다린 뒤 복구	IPv6 실패 후 IPv4로 전환	IPv4 우선 정책으로 비교 테스트

오류:failed to lookup ip for domain

원인 및 해결: 대상 도메인에서 사용할 수 있는 주소를 얻지 못했습니다. DNS 서버 연결 가능성, 질의 아웃바운드, 도메인 정책을 확인하고 캐시를 비운 뒤 다시 테스트하세요.

오류:server misbehaving

원인 및 해결: 업스트림 DNS가 비정상 응답을 반환했거나 응답 형식을 사용할 수 없습니다. 현재 네트워크에서 접속 가능한 DNS 서버로 바꾸고 질의가 잘못된 차단 아웃바운드로 라우팅되지 않는지 확인하세요.

오류:network is unreachable

원인 및 해결: 확인 결과가 현재 기기에서 사용할 수 있는 경로가 없는 주소 체계를 가리킵니다. IPv6 연결을 확인하거나 잠시 IPv4 우선으로 변경해 비교하세요.

결과를 바탕으로 문제를 좁히고 재테스트 완료하기

12가지 점검을 마친 뒤에는 “어떤 메인 페이지 하나가 열렸다”는 사실만으로 복구를 판단하지 마세요. 일반 HTTPS 페이지 하나, 여러 하위 도메인 리소스가 포함된 페이지 하나를 최소한 테스트하고 구독 업데이트도 한 번 실행합니다. 데스크톱에서는 브라우저를 다시 시작하고, Android에서는 한 번 연결을 끊었다가 다시 연결해 시스템 프록시 또는 VPN 인터페이스가 안정적으로 재구성되는지 확인하세요.

로컬 포트가 사용 가능하고 여러 노드의 실제 연결 테스트가 정상이며 전체 프록시로 접속할 수 있지만 원래 분기 모드에서 실패한다면 문제는 라우팅 단계로 명확히 좁혀집니다. 노드 도메인을 확인할 수 없거나 연결 수립 전에 로그에 lookup 오류가 나타난다면 먼저 부트스트랩 DNS를 처리하세요. 한 노드만 여러 네트워크에서 핸드셰이크에 실패한다면 해당 노드의 설정과 서비스 상태를 확인해야 합니다.

로컬 단계 통과 기준: 애플리케이션이 올바른 진입점을 사용하고, 코어의 수신 포트가 존재하며, 로그에 새 요청이 들어오는 것이 보여야 합니다.
노드 단계 통과 기준: 서버 주소에 도달할 수 있고 시스템 시간이 정확하며 VMess 또는 VLESS 항목이 실제 설정과 일치해야 합니다.
라우팅 단계 통과 기준: 실패한 도메인이 예상한 아웃바운드와 일치하고 Geo 데이터가 정상적으로 로드되며, 범위가 넓은 규칙이 우선순위를 덮어쓰지 않아야 합니다.
DNS 단계 통과 기준: 노드 도메인과 대상 도메인이 모두 합리적인 시간 안에 현재 네트워크에서 도달 가능한 주소를 반환해야 합니다.

클라이언트를 재시작하면 잠시 복구되었다가 다시 실패하나요?

복구된 시점과 다시 실패한 시점의 로그를 기록하고 DNS 응답, 포트 수신, 라우팅 일치 결과를 중점적으로 비교하세요. 주기적으로 재발하는 문제는 대개 캐시 만료, 네트워크 전환 또는 업스트림 DNS 시간 초과와 관련이 있습니다.

브라우저는 되는데 명령줄 도구만 계속 시간 초과되나요?

명령줄 도구가 시스템 프록시를 자동으로 읽는 것은 아닙니다. 프록시 환경 변수나 명시적인 프록시 매개변수를 확인하고 주소와 포트가 v2rayN의 현재 수신 값과 일치하는지 확인하세요.

v2rayNG에는 연결됨으로 표시되지만 일부 앱만 인터넷이 안 되나요?

앱별 프록시 설정으로 이동해 해당 앱이 제외되어 있는지 확인하세요. 또한 배터리 절전 정책이 v2rayNG의 백그라운드 실행을 제한하지 않는지 확인하고, 변경 후 연결을 끊었다가 다시 연결합니다.

구독을 업데이트했는데 이전 노드 매개변수가 그대로인가요?

현재 사용 중인 구독 그룹을 업데이트했는지 확인하고 로컬 변경 사항 보존 옵션이 활성화되어 있는지도 확인하세요. 업데이트된 노드를 다시 선택한 뒤 코어 로그에서 실제 주소와 포트를 확인합니다.

모든 설정을 바로 초기화해야 하나요?

먼저 현재 설정을 내보내고 단계별 점검을 완료하세요. 여러 로컬 설정이 서로 충돌하고 원인을 찾을 수 있을 때만 설정을 다시 구성해, 아직 유효한 라우팅 및 구독 설정을 잃지 않도록 합니다.