2026년 8월 21일 · 문제 해결 · 약 10분

V2Ray 연결됨으로 표시되지만 웹페이지가 열리지 않을 때: 노드·DNS·라우팅 규칙 점검

연결 성공으로 표시되는데 웹페이지가 열리지 않는다면 노드, 시간 동기화, DNS, 라우팅 규칙, 로컬 포트 순으로 원인을 확인하세요.

이 글의 핵심

‘연결됨’은 보통 코어가 실행 중이거나 프록시 인터페이스가 만들어졌다는 뜻이지, 대상 웹사이트에 접속할 수 있다는 의미는 아닙니다. 이 글에서는 Windows용 v2rayN을 기준으로 노드와 시스템 시간을 먼저 확인한 다음 DNS, 라우팅, 로컬 포트 문제를 구분해 살펴봅니다. 안드로이드에서도 같은 순서로 점검할 수 있습니다. 한 번에 한 항목만 변경하고 같은 주소로 다시 테스트해야 일시적인 복구를 설정 정상으로 오해하지 않습니다.

1. 코어 실행과 웹 요청 성공을 구분하세요

현재 설정은 그대로 두고 선택한 노드, 프록시 모드, 테스트 주소, 오류 발생 시각을 기록하세요. 클라이언트 로그를 열고 웹페이지를 한 번 새로고침합니다. 상태 표시줄의 ‘실행 중’보다 로그에 새 연결 기록이 생기는지가 요청이 어디까지 전달됐는지 더 잘 보여 줍니다. 이 단계에서 구독 업데이트, DNS 변경, TUN 활성화를 동시에 하지 마세요. 문제가 해결되더라도 원인을 찾기 어렵습니다.

v2rayN은 설정과 관리를 위한 클라이언트이며 실제 연결은 선택한 코어가 처리합니다. V2Ray와 Xray는 상태 버튼의 이름이 아닙니다. 안드로이드의 v2rayNG는 Xray 코어를, v2flyNG는 v2fly 코어를 사용합니다. VPN 인터페이스가 만들어져도 노드 인증, 이름 조회 또는 외부 연결 단계에서 실패할 수 있습니다.

표시되는 현상확인할 수 있는 내용다음 단계
코어 실행 중프로세스가 시작된 상태이며 요청 성공을 뜻하지는 않음웹페이지를 새로고침하고 새 로그 확인
노드 지연 시간이 표시됨특정 테스트에 응답이 도착함실제 HTTPS 요청 테스트
브라우저에서 프록시 연결 오류로컬 프록시 진입점에 연결하지 못했을 수 있음수신 주소와 포트 확인
일부 웹사이트만 열리지 않음도메인 규칙, 이름 조회 또는 대상 사이트 문제일 수 있음오류가 난 도메인의 연결 로그 확인

2. 노드 확인: 포트 연결과 인증 성공은 다릅니다

먼저 프록시를 끄고 현재 네트워크에서 원래 접속할 수 있는 웹사이트를 열어 기본 인터넷 연결을 확인합니다. 그런 다음 프록시를 켜고 같은 HTTPS 주소로 현재 노드와 사용 가능한 다른 노드를 테스트하세요. 다른 노드에서만 접속된다면 클라이언트를 재설치하기보다 먼저 기존 노드 설정이나 서버 문제를 의심해야 합니다.

  1. 현재 노드 확인

    v2rayN 기본 화면에서 실제로 활성화된 서버를 확인하세요. 목록에서 한 항목을 선택했다고 해서 활성 서버로 지정된 것은 아닐 수 있습니다. 현재 버전에서 제공하는 활성 서버 지정 기능으로 전환한 뒤 로그를 확인하세요.

  2. 연결 설정 항목 확인

    서버 편집 창을 열고 구독 정보와 주소, 포트, 인증 정보, 전송 방식, TLS 설정을 대조하세요. WebSocket을 사용한다면 경로와 Host도 확인해야 합니다. Host와 TLS의 serverName은 서로 다른 항목이므로 같은 값이라고 보고 임의로 바꾸지 마세요.

  3. 다른 노드와 비교

    라우팅, DNS, 프록시 모드는 그대로 두고 노드만 바꿔 다시 시도하세요. 모든 노드가 실패하면 시간과 로컬 연결 설정을 확인하고, 특정 노드만 실패한다면 해당 구독을 업데이트하거나 서비스 제공자에게 문의하세요.

  4. 코어 지원 여부 확인

    설정을 불러올 때 오류가 발생하면 현재 코어가 해당 프로토콜과 전송 방식 조합을 지원하는지 확인하세요. VMess와 VLESS는 이름이 비슷해도 인증 방식과 설정 항목을 서로 바꿔 쓸 수 없습니다. 노드 설정을 다른 프로토콜에 맞게 임의로 변경하지 마세요.

지연 시간 테스트는 TCP 연결만 확인할 수도 있고, 선택한 테스트 기능에 따라 HTTP 요청을 보낼 수도 있습니다. 따라서 결과가 의미하는 바는 테스트 방식에 따라 다릅니다. 노드 포트에 연결되더라도 TLS 핸드셰이크, 사용자 인증 또는 서버의 외부 연결 단계에서 실패할 수 있습니다. 구독 업데이트 성공은 설정을 가져왔다는 뜻일 뿐, 설정에 포함된 모든 노드가 작동한다는 보장은 아닙니다.

3. 시스템 시간을 동기화한 뒤 TLS와 인증 로그를 확인하세요

인증서나 인증 오류를 살펴보기 전에 컴퓨터의 실제 시간을 바로잡으세요. Windows 11에서는 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’으로 이동해 ‘자동으로 시간 설정’을 켜고 ‘지금 동기화’를 누릅니다. 날짜, 연도, 시간대를 확인하세요. 표시 시간대만 바꿔서는 시스템 시계 오차가 해결되지 않을 수 있습니다. 동기화한 다음 코어를 재시작하고 요청을 다시 보내세요.

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

원인 및 해결: 컴퓨터 시간이 잘못되었거나 서버 인증서의 유효 기간에 문제가 있을 수 있습니다. 먼저 시스템 시간을 동기화하세요. 같은 오류가 계속되면 로그에 표시된 인증서 유효 기간을 확인하고 서비스 제공자에게 문의하세요. 인증서 검증을 건너뛰는 방식으로 문제를 대신 해결하지 마세요.

오류: tls: handshake failure

원인 및 해결: 상대 서버가 TLS 핸드셰이크를 거부한 상태입니다. serverName, 프로토콜 매개변수 또는 서버 설정이 원인일 수 있습니다. 구독에서 제공한 원래 설정을 복원한 뒤 서버 로그와 함께 원인을 확인하세요. 이 한 줄만으로 DNS 문제라고 단정할 수는 없습니다.

4. 시스템 DNS와 프록시 코어 DNS를 나눠 확인하세요

먼저 조회에 실패한 도메인이 노드 서버인지 접속하려는 웹사이트인지 구분하세요. 노드 서버의 이름을 확인하지 못하면 터널 자체를 만들 수 없고, 웹사이트 도메인만 실패한다면 일부 요청에만 영향을 줄 수 있습니다. Windows의 nslookup으로 시스템 쪽 이름 조회를 확인할 수 있지만, 이 결과만으로 코어의 원격 DNS 설정이나 브라우저의 암호화 DNS까지 정상이라고 볼 수는 없습니다.

nslookup example.com

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

위 명령은 진단 예시이며 속도 측정 결과가 아닙니다. 먼저 10808이 실제로 수신 중인 SOCKS 또는 혼합 포트인지 확인한 다음 두 번째 명령을 실행하세요. 실제로 접속에 실패한 웹사이트 주소로 바꿔야 결과를 비교할 수 있습니다. socks5h는 도메인 조회를 프록시 쪽에 맡기고, socks5는 보통 curl이 로컬에서 도메인을 조회합니다. 두 방식의 결과가 다르면 조회 경로를 더 살펴봐야 하지만, 로그도 함께 확인해야 합니다.

오류: no such host

원인 및 해결: 현재 조회 경로에서 해당 호스트의 유효한 결과를 찾지 못했습니다. 오류에 표시된 도메인을 확인하고 철자, DNS 응답, 조회 설정을 점검하세요. 이 오류가 모든 네트워크 연결이 끊겼다는 뜻은 아닙니다.

5. 라우팅 확인: 요청이 잘못된 출구로 전달되는지 살펴보세요

먼저 임시로 글로벌 프록시 라우팅을 적용해 비교한 뒤 원래 분기 설정으로 되돌리세요. 여기서 ‘글로벌’은 라우팅 정책을 뜻하며 시스템 프록시나 TUN을 켠다는 의미는 아닙니다. 애플리케이션이 먼저 요청을 코어에 전달해야 코어의 라우팅 규칙이 적용됩니다. 시스템 프록시가 요청을 받지 않는 앱은 코어 라우팅을 바꿔도 자동으로 프록시를 사용하지 않습니다.

v2rayN에서 현재 라우팅 설정을 기록한 뒤, 현재 버전에서 제공하는 글로벌 프록시 설정으로 바꾸고 같은 주소를 테스트하세요. 글로벌 설정에서는 정상이고 분기 설정에서 실패한다면 도메인 규칙, IP 규칙, 기본 출구를 중점적으로 확인하세요. 버전과 코어에 따라 화면에 표시되는 이름이 다를 수 있으므로 설정 이름만 보지 말고 실제 출구 기록을 기준으로 판단하세요.

비교 결과우선 확인할 항목조치 방법
글로벌은 정상, 분기 설정은 실패규칙 순서, 도메인 일치 여부, 기본 출구실패한 요청이 실제로 사용한 출구를 확인하고 사용자 지정 규칙의 적용 범위를 줄이세요
분기 설정에서 대상이 직접 연결됨범위가 지나치게 넓은 직접 연결 도메인 또는 IP 규칙해당 규칙을 수정한 뒤 관련 하위 도메인도 테스트하세요
대상 연결이 차단됨차단 규칙 또는 규칙 모음의 잘못된 일치잘못 일치한 항목만 수정하고 나머지 유효한 규칙은 유지하세요
두 라우팅 방식 모두 실패노드, DNS, 로컬 수신 포트, 앱의 프록시 연결오류 로그로 돌아가 확인하고 라우팅 예외를 더 추가하지 마세요

결론: 비교 테스트에서 복구된 경우에만 분기 설정을 수정하세요

글로벌과 분기 설정 모두에서 같은 HTTPS 요청이 실패한다면 도메인 규칙 추가를 멈추세요. 명시적 프록시 요청으로 로컬 진입점과 노드를 확인하고, 문제 범위를 좁힌 뒤 분기 설정을 복구하세요.

6. 로컬 포트와 시스템 프록시 진입점 확인

마지막으로 로컬 포트가 실제로 수신 중인지, 브라우저가 해당 포트를 사용하도록 설정되어 있는지 확인하세요. v2rayN의 포트는 변경할 수 있으며 이전 설정이나 버전에 따라서도 다를 수 있습니다. 아래 숫자는 점검 예시일 뿐이므로 클라이언트에 현재 표시된 값으로 바꿔야 합니다. 노드 서버 포트를 Windows의 로컬 프록시 설정에 입력하지 마세요.

10808
로컬 SOCKS 또는 혼합 포트 예시
127.0.0.1
로컬 루프백 주소이며 노드 주소가 아닙니다
443
HTTPS에서 흔히 사용하는 대상 포트

Windows PowerShell에서 아래 두 명령을 실행하세요. 첫 번째 명령은 수신 포트와 해당 프로세스 번호를 확인하고, 두 번째 명령은 프록시 진입점을 통해 HTTPS 요청을 보낼 수 있는지 확인합니다. SOCKS만 수신 중이라면 일반 HTTP 프록시로 시스템 설정에 입력하면 안 됩니다. 혼합 포트가 두 프로토콜을 모두 지원하는지는 현재 코어 설정을 확인하세요.

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

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

오류: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.

원인 및 해결: 수신 주소와 포트가 이미 사용 중입니다. 프로세스 번호로 어떤 프로그램이 사용 중인지 확인하고, 중복 실행된 클라이언트를 종료하거나 로컬 포트를 변경한 뒤 앱의 프록시 설정도 함께 수정하세요. 정체를 알 수 없는 시스템 프로세스를 바로 종료하지 마세요.

오류: Failed to connect to 127.0.0.1 port 10808

원인 및 해결: 지정한 로컬 진입점에 연결하지 못했습니다. 코어가 실행 중인지, 실제 포트가 설정과 일치하는지, 수신 주소에 루프백 주소가 포함되어 있는지 확인한 다음 원격 노드를 점검하세요.

명시적 프록시 명령은 성공하지만 브라우저에서 실패한다면 Windows 11의 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 현재 설정된 로컬 HTTP 또는 혼합 진입점이 맞는지 확인하세요. v2rayN 트레이 메뉴에서 ‘시스템 프록시’ → ‘시스템 프록시 자동 설정’을 사용했다면 시스템 설정으로 돌아가 적용 결과를 확인하세요. 메뉴 이름은 설치된 버전에 따라 다를 수 있습니다. 브라우저 프록시 확장 프로그램이 시스템 설정을 덮어쓸 수 있으므로 테스트하는 동안 관련 확장 프로그램을 잠시 사용 중지하세요.

7. 자주 묻는 질문과 복구 후 점검

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

지연 시간 테스트와 전체 웹 요청은 서로 다른 과정입니다. 같은 노드를 유지한 채 --proxy를 지정한 curl 명령으로 실제 접속에 실패한 주소를 요청하고 해당 시각의 코어 로그를 확인하세요. HTTP 상태 코드가 반환되면 HTTP 응답을 받은 것입니다. 다만 403, 405 등은 대상 사이트의 규칙과 함께 살펴봐야 합니다.

휴대폰에서는 같은 구독을 쓸 수 있는데 컴퓨터에서는 안 됩니다. 재설치해야 하나요?

먼저 두 기기에서 같은 노드를 선택했는지 확인한 뒤, 컴퓨터와 휴대폰을 같은 네트워크에 연결해 비교하세요. 같은 구독을 사용해도 활성 노드, 코어 지원 기능, DNS 설정은 다를 수 있습니다. 컴퓨터에서는 로컬 수신 포트와 명시적 프록시 요청부터 확인하고 로그를 보관한 다음 설정을 다시 만들지 검토하세요.

안드로이드에서 VPN 연결됨으로 표시되는데 모든 앱이 접속되지 않아요.

v2rayNG 또는 v2flyNG에서 현재 노드를 확인한 뒤 앱별 프록시 설정에서 브라우저가 제외되어 있는지 살펴보세요. 앱별 필터링을 잠시 끄고 비교한 다음 코어 오류 로그를 확인하세요. VPN 표시만으로 인터페이스가 만들어졌다는 것은 알 수 있지만 원격 인증이나 DNS 요청 성공까지 보장되지는 않습니다.

클라이언트를 종료한 뒤 일반 웹페이지도 열리지 않으면 어떻게 하나요?

먼저 v2rayN을 다시 열고 트레이의 ‘시스템 프록시’ 메뉴에서 시스템 프록시를 해제한 다음 종료하세요. Windows의 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 점검 중 설정한 수동 프록시나 구성 스크립트를 끌 수도 있습니다. 회사에서 관리하는 설정은 임의로 변경하지 마세요. TUN을 사용했다면 클라이언트의 네트워크 연결 가로채기가 정상적으로 중지됐는지도 확인하세요.

접속이 복구되면 임시 글로벌 프록시, 디버그 로그, 테스트용 DNS를 실제 사용할 설정으로 하나씩 되돌리고 매번 테스트하세요. ‘오류 현상—변경 항목—재테스트 결과’를 간단히 기록해 두면 출처를 알 수 없는 예외 규칙을 여러 개 남기는 것보다 유용합니다.

v2rayN 다운로드