2026-09-15 · 문제 해결 · 약 12분

V2Ray 연결됨으로 표시되지만 웹사이트가 열리지 않을 때: 단계별 점검 10가지

시스템 프록시, 로컬 포트, 라우팅 규칙, DNS 문제를 쉬운 항목부터 확인해 연결은 됐지만 인터넷이 안 되는 원인을 찾습니다.

핵심 내용

v2rayN 데스크톱 앱에 실행 중이라고 표시돼도 브라우저 요청이 프록시를 거치거나 원격 노드에서 대상 사이트에 접속할 수 있다는 뜻은 아닙니다. 아래에서 로컬 네트워크, 시스템 프록시, 수신 포트, 노드 상태, 라우팅, DNS, TLS, TUN, 앱 설정, 로그를 차례로 확인합니다. Windows 기준으로 설명하고 v2rayNG와 v2flyNG의 Android 점검 항목도 덧붙였습니다. 한 번에 한 항목만 변경하고 같은 브라우저에서 같은 주소로 다시 테스트해 여러 문제가 뒤섞이지 않도록 하세요.

1. 기본 네트워크 확인: 로그인 페이지와 인터넷 연결 문제부터 점검

먼저 현재 노드 이름, 프록시 모드, 최근 오류를 기록한 다음 TUN을 잠시 끄고 v2rayN 트레이 메뉴에서 「시스템 프록시」→「시스템 프록시 해제」를 선택합니다. 평소 프록시 없이 접속되는 웹사이트를 열어 보세요. 여전히 접속되지 않으면 구독을 반복해서 업데이트하기보다 Wi-Fi, 유선 연결, 라우터, 네트워크 인증부터 확인해야 합니다.

호텔, 학교, 공용 네트워크에서는 인증 페이지에 접속해야 할 수 있습니다. 네트워크 아이콘에 연결됨으로 표시돼도 기기가 로컬 네트워크에 연결됐다는 뜻일 뿐입니다. 인증을 마친 뒤 프록시를 다시 켜서 테스트하세요. 다음 세 단계로 재현 가능한 테스트 조건을 만들고, 이후 모든 점검에서 같은 브라우저와 대상 주소를 사용합니다.

  1. 현재 상태 기록

    현재 노드, 시스템 프록시 상태, TUN 설정, 테스트 시간을 기록하세요. 오류에서 핵심 문구만 보관하고 구독 주소 전체는 공개하지 마세요.

  2. 직접 연결 확인

    TUN을 끄고 「시스템 프록시」→「시스템 프록시 해제」를 선택한 다음, 직접 접속되는 웹사이트를 엽니다. 필요한 경우 먼저 네트워크 인증을 완료하세요.

  3. 테스트 주소 고정

    노드를 다시 연결한 뒤 웹사이트 하나만 테스트하세요. 즉시 오류가 나는지, 오래 기다려야 하는지, 이미지 로딩만 실패하는지 기록하고 여러 조건을 동시에 바꾸지 마세요.

2. 시스템 프록시 확인: 요청이 v2rayN으로 전달되는지 점검

v2rayN 트레이 메뉴에서 「시스템 프록시」→「시스템 프록시 자동 설정」을 선택합니다. Windows 11에서는 「설정」→「네트워크 및 인터넷」→「프록시」에서 실제 프록시 주소와 포트를 확인할 수 있습니다. 로컬 프록시 주소는 보통 127.0.0.1을 사용합니다. 포트는 클라이언트가 현재 수신 대기 중인 값과 일치해야 하며, 오래된 화면 캡처를 보고 입력하면 안 됩니다.

시스템 프록시는 해당 설정을 따르는 앱에 주로 적용되며 모든 프로그램의 트래픽을 자동으로 처리하지는 않습니다. 먼저 TUN을 끄고 시스템 프록시 경로만 확인하세요. 브라우저에서 페이지를 새로고침해도 클라이언트에 관련 연결 기록이 없다면 명시적 프록시 명령으로 브라우저 설정을 우회해 테스트할 수 있습니다. 아래 10808은 HTTP 또는 혼합 수신이 활성화된 경우의 예시 포트일 뿐이므로 실행 전에 실제 값으로 바꿔야 합니다.

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

3. 수신 포트 확인: 코어 미실행과 포트 충돌 구분

v2rayN은 관리 인터페이스이며 실제 연결 처리는 코어 프로세스가 담당합니다. 인터페이스가 열려 있어도 코어 시작에 실패했다면 시스템 프록시가 서비스가 없는 로컬 포트를 가리킬 수 있습니다. 「설정」→「매개변수 설정」에서 로컬 수신 관련 옵션을 확인하고 로그에 표시된 수신 주소와 대조하세요. 항목 이름과 기본 포트는 버전에 따라 다를 수 있습니다.

10808
문서의 로컬 프록시 포트 예시
53
일반적인 DNS 서비스 포트
443
일반적인 HTTPS 대상 포트

PowerShell에서 다음 명령을 실행하세요. 첫 번째 명령으로 수신 포트와 프로세스 ID를 확인하고, 두 번째 명령으로 확인한 ID에 해당하는 프로세스를 찾습니다. 예시의 1234는 고정값이 아닙니다. 포트가 같다는 이유만으로 프로세스를 종료하지 말고, 정체를 모르는 시스템 서비스를 강제 종료하지 마세요.

Get-NetTCPConnection -LocalPort 10808 -State Listen
Get-Process -Id 1234

오류: bind: address already in use

원인 및 해결: 수신 주소나 포트를 다른 프로세스가 이미 사용 중입니다. 클라이언트가 중복 실행됐는지 먼저 확인하세요. 중복 인스턴스를 종료하거나 로컬 수신 포트를 변경한 뒤 시스템 프록시와 앱 프록시 설정도 같은 값으로 업데이트하세요.

오류: Failed to connect to 127.0.0.1 port 10808

원인 및 해결: 이번 요청은 예시 로컬 포트에 연결하지 못했습니다. 수신 포트, 코어 시작 로그, 로컬 보안 소프트웨어의 차단 기록을 확인하세요. 원격 노드가 작동하지 않는다고 바로 단정할 수는 없습니다.

4. 노드와 구독 확인: 테스트 결과가 실제 사용 가능성을 보장하지는 않습니다

노드 목록에 지연 시간이 표시돼도 프록시 연결 전체가 정상이라는 뜻은 아닙니다. TCP 지연 시간은 대개 특정 주소와 포트에 연결할 수 있다는 점만 보여 주며, 실제 지연 테스트 결과는 클라이언트가 사용하는 테스트 주소에도 좌우됩니다. 먼저 노드를 선택해 활성 서버로 설정한 뒤 실제 대상 사이트에 접속해 보세요. 목록의 숫자만 확인해서는 안 됩니다.

VMess와 VLESS는 프록시 프로토콜이고 REALITY는 관련 보안 전송 방식입니다. 세 이름을 서로 배타적인 노드 유형으로 취급해서는 안 됩니다. 매개변수를 직접 수정하기 전에 먼저 백업하세요. 특히 VLESS와 REALITY 조합에서는 서버 주소, 공개 키, 짧은 ID, 서버 이름 등의 값을 서버 설정에 맞춰야 하며 추측으로 채우면 안 됩니다.

5. 라우팅 분할 확인: 대상 트래픽이 어떤 아웃바운드로 나가는지 점검

일부 웹사이트만 열리지 않는다면 라우팅을 먼저 확인하세요. 시스템 프록시는 요청을 로컬 진입점으로 전달하고, 라우팅 규칙은 요청을 직접 연결할지 프록시로 보낼지 차단할지 결정합니다. 서로 다른 단계입니다. 시스템 프록시가 켜져 있어도 모든 대상이 원격 노드로 전달되는 것은 아닙니다.

관찰 결과우선 확인할 항목테스트 방법
프록시 대상이 직접 연결됨도메인 규칙과 규칙 순서임시로 모든 트래픽을 프록시로 보내는 라우팅 설정 사용
웹페이지 본문은 열리지만 이미지가 로드되지 않음이미지 및 정적 리소스 도메인실패한 리소스의 아웃바운드 기록 확인
로그에 차단으로 명확히 표시됨차단 규칙의 범위가 지나치게 넓은지 확인일치한 규칙만 조정
설정을 바꾼 뒤 정상 작동기존 설정의 도메인 및 IP 일치 여부기존 설정으로 되돌린 뒤 차이를 규칙별로 확인

정리: 비교용 설정으로 라우팅 문제부터 분리

같은 노드와 주소를 사용했을 때 모든 트래픽을 프록시로 보내면 정상이고 기존 분할 라우팅 설정에서 실패한다면, 일치한 규칙부터 수정하세요. 이 경우 노드를 바꾸거나 TLS 보안 설정을 낮추는 것은 문제의 원인에서 벗어난 대응일 가능성이 큽니다.

라우팅 설정 이름은 버전과 사용자 지정 설정에 따라 다르므로 규칙이 실제로 어떤 아웃바운드로 연결하는지 확인하세요. 용어와 정의는 라우팅 분할 용어 설명에서 확인할 수 있습니다. 점검이 끝나면 일상적으로 사용하기 적합한 설정으로 되돌리고 비교용 설정을 최종 설정으로 사용하지 마세요.

6. DNS 확인: 노드 도메인과 대상 도메인 구분

DNS에는 적어도 두 종류의 주소가 관련됩니다. 클라이언트가 먼저 원격 서버를 찾아야 하고, 웹사이트의 대상 도메인도 적절한 위치에서 조회해야 합니다. 첫 번째 단계가 실패하면 대개 노드에 연결할 수 없습니다. 두 번째 단계에 문제가 있으면 노드 지연 시간은 표시되지만 웹사이트가 열리지 않을 수 있습니다. IP 주소 하나를 찾았다고 조회가 올바르다는 뜻은 아닙니다. 네트워크에 따라 다른 IP가 반환된다는 이유만으로 DNS 오염이라고 단정해서도 안 됩니다. 콘텐츠 전송 네트워크는 원래 서로 다른 결과를 반환할 수 있습니다.

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

첫 번째 명령으로 시스템의 DNS 조회 결과를 확인하고, 두 번째 명령으로 Windows 시스템 DNS 캐시를 비웁니다. 세 번째 명령은 해당 포트에서 SOCKS5 또는 혼합 수신을 제공할 때만 사용하세요. socks5h는 대상 호스트 이름 처리를 프록시 서버에 맡기므로 로컬 DNS 조회 경로와 비교하기에 적합합니다. 다만 코어 내부의 DNS 및 라우팅 설정까지 우회한다는 보장은 없습니다.

7. 시스템 시간, TLS, SNI 확인

인증서 오류는 발생한 계층을 구분해 판단해야 합니다. 노드의 TLS 핸드셰이크가 실패했을 수도 있고, 브라우저가 대상 사이트에 접속할 때 인증서 오류를 받았을 수도 있습니다. Windows 11에서 「설정」→「시간 및 언어」→「날짜 및 시간」을 열고 자동 시간 설정을 켠 다음 「지금 동기화」를 실행하세요. 인증서 검증은 실제 시스템 시간을 기준으로 하므로 표시 시간대를 바꾸는 것만으로는 시간이 동기화되지 않습니다.

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

원인 및 해결: 인증서 유효 기간이 현재 시간과 맞지 않습니다. 먼저 로컬 시간을 동기화하세요. 시간이 정확한데도 오류가 발생하면 서버 운영 담당자에게 인증서 유효 기간과 배포 상태를 확인하도록 요청하세요.

오류: x509: certificate signed by unknown authority

원인 및 해결: 현재 검증 환경에서 신뢰할 수 있는 인증서 체인을 구성하지 못했습니다. 서버 인증서 체인, 시스템 신뢰 저장소, 네트워크의 HTTPS 검사 장비를 확인하세요. 검증을 바로 건너뛰지 마세요.

오류: tls: handshake failure

원인 및 해결: 범위가 넓은 핸드셰이크 실패 메시지입니다. 노드에 지정된 서버 이름, 전송 방식, TLS 매개변수를 확인하고 서버 로그와 함께 판단하세요. 이 한 줄만 보고 인증서가 만료됐다고 단정할 수 없습니다.

SNI는 서버 설정에서 요구하는 이름을 사용해야 합니다. 연결 주소와 다를 수 있으며, 유명 웹사이트 도메인으로 임의 변경해서는 안 됩니다. allowInsecure를 만능 해결책처럼 사용하지 마세요. 인증서 검증을 우회하면 잘못된 연결이나 중간 단계의 문제를 감출 수 있지만 계정, 라우팅, 전송 매개변수 문제는 해결되지 않습니다.

8. TUN, 권한, 가상 네트워크 어댑터 충돌 확인

명시적 프록시 테스트는 성공하지만 TUN을 켠 뒤 기기 전체에서 인터넷이 되지 않는다면 가상 네트워크 어댑터, 라우팅, DNS 처리 범위를 점검하세요. TUN은 시스템 트래픽 경로를 바꾸며 일반적으로 권한 상승이 필요합니다. 브라우저에만 프록시를 설정해 테스트할 때는 TUN을 함께 켤 필요가 없습니다.

  1. 먼저 TUN을 끄고 2단계의 명시적 프록시 테스트가 성공하는지 확인해 가상 네트워크 어댑터에 의존하지 않는 기준 상태를 만드세요.
  2. 클라이언트 안내에 따라 네트워크 어댑터 생성과 라우팅 변경에 필요한 권한을 허용하세요. Windows에서는 v2rayN을 종료한 뒤 관리자 권한으로 실행하고 다시 켜 보세요.
  3. 가상 네트워크 어댑터 여러 개가 기본 경로를 동시에 변경하지 않도록 다른 VPN이나 트래픽 처리 프로그램을 잠시 종료하세요. 회사 기기라면 조직의 네트워크 정책을 먼저 따르세요.
  4. Get-NetAdapter로 네트워크 어댑터 상태를 확인하고 route print로 라우팅 정보를 저장하세요. 먼저 기록만 하고 모르는 경로를 한꺼번에 삭제하지 마세요.

Android의 v2rayNG와 v2flyNG는 시스템 VPN 서비스를 이용해 선택한 앱의 트래픽을 처리합니다. 연결 권한, 앱별 프록시 목록, 시스템의 다른 VPN 연결 여부를 확인하세요. 화면을 잠근 뒤에만 연결이 끊긴다면 배터리 최적화와 백그라운드 실행 제한을 확인하세요. 백그라운드에서 앱이 종료된 것을 노드 문제로 오해하지 마세요. 데스크톱 TUN 기본 안내는 TUN 사용 가이드를 참고하세요.

9. 브라우저, 앱 프록시, 방화벽 확인

명시적 프록시 테스트는 성공하지만 브라우저에서 실패한다면 앱 계층의 차이를 먼저 확인할 만합니다. 브라우저 확장 프로그램이 시스템 프록시를 덮어쓸 수 있고 보안 DNS가 다른 조회 경로를 선택할 수 있습니다. 터미널 앱은 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 환경 변수를 읽을 수도 있습니다. 시크릿 창에서도 모든 확장 프로그램과 기업 정책이 제외되는 것은 아니므로 유일한 판단 근거로 삼지 마세요.

특정 웹사이트에서만 로그인에 실패하거나 403 응답 또는 인증 확인이 표시된다면 사이트 계층의 응답을 받은 것입니다. 이를 완전한 인터넷 연결 실패로 분류해서는 안 됩니다. 출구 IP 평판, 지역 제한, 계정 보안 정책 등이 원인일 수 있으므로 연결 시간 초과와 구분해 처리하세요.

10. 로그를 확인하며 마무리: 한 번에 변수 하나만 변경

앞의 아홉 단계를 거쳐도 원인을 찾지 못했다면 현재 로그 표시를 지우고 시간을 기록한 뒤 대상 요청을 한 번만 실행하세요. 필요한 경우 로그 상세 수준을 잠시 높여 재현하고, 끝나면 원래대로 돌려 과도한 접속 정보가 장기간 기록되지 않게 하세요. 실패가 로컬 연결, 원격 연결, 핸드셰이크, 대상 웹사이트 응답 중 어느 단계에서 발생했는지 확인하는 것이 핵심입니다.

키워드 또는 증상의미다음 단계
connection refused연결이 명시적으로 거부됨오류에 표시된 주소를 보고 로컬 수신인지 원격 서비스인지 구분
i/o timeout특정 네트워크 단계에서 시간 초과주소, 포트, 네트워크 경로, 시간 초과 직전 로그 확인
no such host관련 도메인 조회 실패조회에 실패한 도메인이 노드인지 대상인지 확인
해당 요청 기록이 없음요청이 관찰 중인 진입점으로 전달되지 않았을 수 있음로그 수준을 확인한 뒤 앱 프록시와 트래픽 처리 범위 점검

관리 담당자에게 문의할 때는 운영체제, 클라이언트 버전, 코어 버전, 테스트 시간, 네트워크 유형, 민감 정보를 가린 오류 일부를 제공하세요. 구독 토큰, 사용자 식별 정보, 비밀번호, 개인 키, 민감한 접속 기록은 숨기고 설정 파일 전체를 보내지 마세요. 클라이언트를 업데이트할 경우 먼저 노드와 라우팅 설정을 백업한 뒤 클라이언트 다운로드 페이지에서 플랫폼과 아키텍처에 맞는 파일을 선택하세요.

자주 묻는 질문: 테스트 결과는 어떻게 해석하나요?

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

먼저 측정한 값이 TCP 지연 시간인지 실제 요청 지연 시간인지 확인하세요. 노드를 선택한 뒤 2단계의 명시적 프록시 명령을 실행해 보세요. 포트에 연결할 수 있어도 인증, TLS, 대상 사이트 접속까지 모두 정상이라는 뜻은 아닙니다.

구독 업데이트가 되면 노드에도 문제가 없다는 뜻인가요?

아닙니다. 구독 주소와 노드 서버는 서로 다른 서비스일 수 있습니다. 업데이트한 뒤 활성 노드, 데이터 사용량, 만료 상태를 확인하고 같은 대상 주소를 사용해 두 노드에서 각각 테스트한 다음 실제 요청 결과를 비교하세요.

브라우저는 되는데 다른 앱은 모두 안 되면 어떻게 해야 하나요?

먼저 해당 앱이 시스템 프록시를 따르는지, 로컬 프록시를 직접 설정할 수 있는지 확인하세요. 프록시를 지원하지 않는 앱까지 처리해야 하는 경우에만 가이드에 따라 TUN을 설정하고 권한과 앱별 적용 범위를 점검하세요.

재시작하면 복구됐다가 잠시 뒤 다시 끊깁니다. 무엇부터 확인해야 하나요?

문제가 발생한 시간대의 로그를 보관하고 포트 충돌, 절전 모드 해제 후 네트워크 어댑터 경로, 백그라운드 제한을 확인하세요. “재시작하면 해결됨”만 기록하지 말고 연결이 끊기기 전후의 수신 프로세스, 활성 노드, 프록시 상태가 달라졌는지 비교하세요.

v2rayN 다운로드 · 플랫폼 선택