2026-10-21 · 문제 해결 · 약 10분

v2rayN 연결은 되는데 인터넷이 안 될 때: 시스템 프록시·라우팅·DNS·시간 점검

시스템 프록시 모드, 로컬 포트 점유, 라우팅 프리셋, DNS 설정, 시스템 시간, 노드 상태를 차례로 확인해 연결 후 인터넷이 되지 않는 원인을 찾습니다.

핵심 요약

v2rayN에서 코어가 실행되고 노드 지연 시간도 표시되지만 웹페이지가 열리지 않는 경우를 다룹니다. 먼저 브라우저 요청이 로컬 포트로 전달되는지 확인한 다음 라우팅, 도메인 조회, 시간, 원격 노드 상태를 점검하세요. 프록시를 명시한 테스트와 동일한 대상에 대한 비교 결과로 로컬 진입 문제와 외부 연결 문제를 구분하면, 여러 설정을 한꺼번에 바꿔 원인을 놓치는 일을 막을 수 있습니다.

1. 코어 실행과 웹 접속은 별개

v2rayN은 설정을 관리하고 프록시 코어를 실행하는 클라이언트입니다. 화면에 코어 실행 중이라고 표시되어도 보통 로컬 프로세스가 시작됐다는 뜻일 뿐입니다. 노드 목록에 지연 시간이 표시되는 것도 해당 시점에 테스트 결과를 받았다는 의미입니다. 브라우저 요청은 로컬 진입점, 라우팅, 노드 연결, 대상 사이트 응답을 차례로 거치므로 어느 한 단계에서 문제가 생겨도 웹페이지가 계속 로딩될 수 있습니다.

이 문서에서는 Windows 데스크톱 환경을 기준으로 설명합니다. 버전에 따라 설정 메뉴 구성이 달라질 수 있으므로 먼저 「도움말」→「정보」에서 버전을 확인한 뒤 설정 이름으로 찾아보세요. 포트 예시는 127.0.0.1:10808로 통일했지만 모든 버전에서 고정으로 사용하는 값은 아닙니다. 이전 설정에서 HTTP 포트가 10809로 지정되어 있을 수도 있으니 「설정」→「매개변수 설정」의 로컬 수신 설정과 시작 로그를 기준으로 확인하세요.

화면에 표시되는 상태와 확인 가능한 범위
확인된 상태확인할 수 있는 내용추가 점검 항목
코어가 정상적으로 시작됨프로세스가 시작되고 설정을 읽음수신 포트, 시스템 프록시, 외부 연결
TCP 지연 시간 표시테스트 시점에 서버 포트에 연결할 수 있음프로토콜 핸드셰이크, 인증, TLS, 사이트 응답
실제 연결 테스트 성공지정한 테스트 요청이 완료됨브라우저 진입 경로, 다른 사이트, 분할 라우팅 규칙
브라우저에 프록시 오류 표시브라우저가 프록시를 사용하려 했지만 연결 실패실제 프록시 주소와 포트, 프로세스 상태

문제를 찾을 때는 노드 하나, 테스트 사이트 하나, 네트워크 하나를 정해 설정을 바꾸기 전후의 오류를 기록하세요. TUN을 켜거나 DNS를 수정하고, 코어를 바꾸고, 구독을 업데이트하는 작업을 동시에 하지 마세요. 문제가 해결되어도 어떤 변경이 효과가 있었는지 판단하기 어려워집니다.

2. 시스템 프록시: 브라우저 요청이 클라이언트로 전달되는지 확인

시스템 프록시는 앱의 요청을 v2rayN으로 전달하는 방법을 정하고, 라우팅은 전달된 요청을 어디로 보낼지 정합니다. 노드를 선택했다고 모든 앱이 자동으로 해당 노드를 사용하는 것은 아닙니다. 일부 앱은 Windows 시스템 프록시를 따르지만 별도로 설정해야 하는 앱도 있습니다. 원인을 좁히려면 먼저 TUN 모드를 잠시 끄고 일반 시스템 프록시 경로만 확인한 뒤 테스트 후 원래 설정으로 되돌리세요.

  1. 시스템 프록시 켜기

    메인 화면 하단이나 트레이 메뉴에서 「시스템 프록시」→「시스템 프록시 자동 설정」을 선택합니다. 진입 경로를 확인하는 동안에는 사이트별 규칙의 영향을 받을 수 있는 PAC 모드는 사용하지 마세요.

  2. 시스템 진입 설정 확인

    Windows에서 「설정」→「네트워크 및 인터넷」→「프록시」→「수동 프록시 설정」으로 이동해 클라이언트가 입력한 주소와 포트를 확인하세요. 로컬 HTTP 포트 또는 혼합 수신 포트와 일치하는지 점검합니다.

  3. 브라우저 설정이 프록시를 덮어쓰는지 확인

    프록시를 변경하는 브라우저 확장 프로그램을 잠시 끄세요. 브라우저에 별도의 프록시 설정이 있다면 시스템 프록시를 사용하도록 변경합니다. 브라우저를 완전히 닫았다가 다시 열고 기존 테스트 사이트에 접속하세요.

  4. 프록시를 지정해 테스트

    PowerShell에서 아래 명령을 실행합니다. 브라우저가 시스템 설정을 읽는지와 관계없이 HTTP 프록시를 명시합니다. 로컬 포트가 SOCKS만 지원한다면 뒤에 나오는 SOCKS 테스트를 사용하세요.

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

example.com은 테스트 대상의 예시이며, 현재 열리지 않는 사이트로 바꿔도 됩니다. --noproxy ""는 이번 호출에서 프록시 우회 목록의 영향을 없애는 옵션입니다. HTTP 상태 코드가 반환되면 적어도 HTTP 응답은 받은 것이지만 사이트의 모든 리소스가 정상적으로 로드된다는 뜻은 아닙니다. 프록시 자체가 오류 페이지를 반환한다면 응답 내용과 코어 로그도 함께 확인하세요.

판단: 프록시를 지정한 테스트가 성공하면 브라우저 진입 경로부터 점검

같은 노드와 같은 대상에서 명령줄 프록시 테스트는 응답을 받는데 브라우저만 실패한다면 시스템 프록시, 브라우저 자체 프록시 설정, 확장 프로그램을 먼저 확인하세요. 노드를 바꾸거나 DNS를 다시 설정하는 것은 나중에 해도 됩니다.

3. 로컬 포트: 수신 프로세스와 프록시 유형 확인

로컬 연결 거부는 대개 트래픽이 원격 서버에 도달하기 전에 발생합니다. 코어가 종료됐거나 포트를 잘못 입력했거나 다른 프로세스가 포트를 사용 중일 수 있습니다. Windows에서는 먼저 수신 상태를 확인하고 프로세스를 조회하세요. 프로세스 번호가 보인다고 바로 작업을 종료해서는 안 됩니다.

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

# 앞 명령의 출력에 나온 OwningProcess 번호를 넣어 조회
Get-Process -Id 1234

1234는 프로세스 번호 입력 방법을 보여주는 예시입니다. 실제 사용 시에는 앞 명령이 반환한 값을 넣으세요. 수신 기록이 없다면 v2rayN 로그에서 시작 실패 원인을 확인합니다. 다른 프로그램이 포트를 사용 중이라면 해당 프로그램을 정상적으로 종료하거나 「설정」→「매개변수 설정」에서 로컬 수신 포트를 변경한 뒤 시스템 프록시를 다시 적용하세요.

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

원인: Windows에서 같은 수신 주소와 포트를 이미 사용 중이어서 코어가 바인딩하지 못했습니다.

해결 방법: 포트를 사용하는 프로세스를 조회하고 중복 실행된 클라이언트를 종료하거나, 수신 포트를 변경한 뒤 시스템 프록시에도 같은 값을 적용하세요.

오류: ERR_PROXY_CONNECTION_FAILED

원인: 브라우저가 설정된 프록시에 연결하지 못했습니다. 포트에서 수신 중인 프로세스가 없거나 프록시 주소가 오래된 경우일 수 있습니다.

해결 방법: Windows 프록시 설정의 주소와 포트를 확인한 다음 프록시를 지정한 명령으로 테스트하세요. 먼저 로컬 진입 문제를 해결하고 프로토콜 변경은 서두르지 마세요.

4. 라우팅 프리셋: 요청이 예상한 출구로 나가는지 확인

로컬 진입이 정상이라면 다음으로 요청이 어디에 할당되는지 확인합니다. 라우팅 규칙은 일반적으로 순서대로 적용되며, 먼저 일치하는 규칙이 출구를 결정합니다. 사용자 지정 규칙에 따라 특정 도메인이 직접 연결되거나 차단된 출구로 전달될 수 있습니다. 우회 유형의 프리셋으로 바꾼 뒤 일부 사이트만 실패한다면, 모든 문제를 노드 탓으로 돌리기보다 규칙을 확인하세요.

“전역”이라는 이름만 보고 모든 트래픽이 프록시를 거친다고 판단하지 마세요. 일반적으로 코어에 전달된 요청에만 적용되므로 시스템 프록시를 사용하지 않는 앱은 직접 연결될 수 있습니다. 도메인 규칙과 IP 규칙의 동작은 코어의 domainStrategy 같은 설정에도 영향을 받습니다. 특정 사이트 하나를 해결하려고 전체 라우팅 동작을 바꾸지 말고 우선 기본 정책을 유지하세요.

5. DNS: 로컬·코어·노드 주소 조회를 구분

DNS 문제는 웹사이트 도메인을 조회하지 못하는 경우만 있는 것이 아닙니다. 노드 서버 주소가 도메인이라면 연결을 시작하기 전에 해당 주소도 조회해야 합니다. 브라우저의 보안 DNS, 시스템 리졸버, 코어의 DNS 설정은 서로 다른 경로를 사용할 수 있습니다. Windows 캐시를 비워도 관련된 로컬 캐시에만 영향을 줄 뿐 브라우저와 프록시 측의 조회 결과까지 모두 지워지는 것은 아닙니다.

# 시스템 DNS 조회 경로 확인용이며 코어 DNS 확인을 대신하지 않음
Resolve-DnsName example.com

# SOCKS를 통해 대상 도메인을 프록시 측에서 조회
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

# 비교 테스트: 로컬에서 대상 도메인을 조회한 뒤 SOCKS로 연결
curl.exe --noproxy "" --proxy socks5://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

# 관련 설정을 변경한 뒤 필요하면 Windows DNS 캐시 삭제
ipconfig /flushdns

위의 두 SOCKS 명령은 해당 포트가 SOCKS를 지원해야 합니다. socks5h는 대상 도메인 조회를 프록시 측에 맡기고, socks5는 로컬에서 먼저 조회합니다. 전자는 성공하고 후자는 실패한다면 로컬 조회 경로를 우선 확인하세요. 다만 도메인과 IP가 서로 다른 라우팅 규칙에 일치해 두 명령의 결과가 달라질 수도 있으므로 로그도 함께 확인해야 합니다. 한 번의 결과만으로 단정하지 마세요.

오류: Could not resolve host

원인: curl이 현재 사용하는 조회 경로에서 대상 주소를 찾지 못했습니다. 이 오류만으로 노드 프로토콜에 문제가 있다고 판단할 수는 없습니다.

해결 방법: 먼저 시스템 DNS 조회를 실행한 뒤 두 가지 SOCKS 테스트를 비교해 로컬과 프록시 중 어느 쪽에서 조회에 실패하는지 확인하세요.

오류: no such host

원인: 로그에 표시된 도메인을 조회하지 못했습니다. 노드 서버 도메인일 수도 있고 대상 웹사이트 도메인일 수도 있습니다.

해결 방법: 오류 주변의 전체 도메인 이름을 확인한 다음 노드 주소의 철자와 실제 사용 중인 DNS 설정을 점검하세요. 임시 조회로 얻은 IP 주소로 도메인을 바로 바꾸지 마세요.

브라우저에서만 문제가 발생한다면 브라우저 설정에서 「보안 DNS」를 검색하고 현재 값을 기록한 뒤 잠시 꺼서 비교해 보세요. 노드 도메인 조회가 실패한다면 프록시 연결에 필요한 기본 DNS 경로부터 복구해야 합니다. 아직 연결되지 않은 프록시에 기대어 해당 도메인을 조회하게 해서는 안 됩니다.

6. 시스템 시간과 노드: 핸드셰이크 및 서버 문제 확인

시스템 날짜가 크게 틀리면 TLS 인증서의 유효 기간을 잘못 판단할 수 있으며, 일부 프로토콜 인증도 시간에 영향을 받습니다. Windows 시간 설정에 표시되는 시간대 이름만으로 판단하지 말고 시스템 시각이 정확한지 확인하세요. 먼저 시간을 동기화한 다음 인증서 오류를 해결하고, 인증서 검증을 건너뛰는 방식으로 대체하지 마세요.

  1. 시스템 시간 동기화

    Windows에서 「설정」→「시간 및 언어」→「날짜 및 시간」으로 이동해 「자동으로 시간 설정」을 켜고 시간대를 확인한 다음 「지금 동기화」를 클릭하세요. 동기화에 실패하면 기본 네트워크 연결과 시간 서비스를 먼저 확인합니다.

  2. 노드 설정 항목 확인

    현재 노드의 편집 창을 열고 서비스 제공자가 안내한 설정과 서버 주소, 포트, 사용자 ID, 전송 방식, TLS 서버 이름 및 프로토콜에서 요구하는 매개변수를 비교하세요. 서로 다른 노드의 설정 항목을 섞어 사용하지 마세요.

  3. 다른 노드와 비교

    시스템 프록시, 라우팅, DNS는 그대로 두고 같은 구독에 있는 정상 작동이 확인된 노드로 바꿔 보세요. 원래 노드만 실패한다면 서비스 제공자의 만료일, 잔여 트래픽, 회선 상태를 확인합니다.

  4. 접속 네트워크 바꾸기

    원인을 여전히 구분하기 어렵다면 모바일 핫스팟에서 같은 노드와 같은 대상에 다시 접속해 보세요. 네트워크에 따라 결과가 크게 다르면 현재 네트워크의 접속 제한, 포털 인증, 회선 문제를 확인합니다.

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

원인: 로컬 시스템 시간이 정확하지 않거나 원격에서 제공한 인증서의 유효 기간이 실제로 지났습니다.

해결 방법: 시스템 시간을 동기화하고 다시 시도하세요. 계속 발생하면 노드의 TLS 이름을 확인하고 서비스 제공자에게 인증서 설치 상태를 점검하도록 요청합니다.

오류: i/o timeout

원인: 네트워크 작업이 제한 시간 안에 완료되지 않았습니다. 연결, 핸드셰이크, 응답 수신 중 어느 단계에서든 발생할 수 있습니다.

해결 방법: 오류 앞뒤의 대상 주소를 확인해 어느 단계에서 발생했는지 파악한 뒤 노드와 네트워크를 바꿔 비교하세요. 시간 초과를 곧바로 DNS 실패로 단정하지 마세요.

VLESS와 REALITY를 사용한다면 선택한 클라이언트 코어가 해당 설정을 지원해야 하며, 서비스 제공자가 안내한 공개 키, 서버 이름, 짧은 ID 등의 항목도 정확히 입력해야 합니다. V2Ray 생태계에 속한다는 이유만으로 코어마다 지원 방식이 완전히 같다고 가정하지 마세요. TCP 포트에 연결된다고 핸드셰이크 설정까지 올바른 것은 아닙니다.

판단: 노드만 바꿔 해결됐다면 로컬 설정은 유지

같은 진입 경로와 대상에서 노드만 바꾼 뒤 안정적으로 응답을 받았다면 기존 로컬 설정을 유지하고 원래 노드의 매개변수, 서비스 상태, 회선을 집중적으로 확인하세요. 포트와 DNS까지 동시에 변경하지 마세요.

7. 자주 묻는 질문과 설정 복구

노드 지연 시간이 80ms인데도 웹페이지가 열리지 않는 이유는?

80ms는 지연 시간 측정값의 예일 뿐, 웹페이지 전체가 정상적으로 열리는 것을 증명하지는 않습니다. 먼저 측정 방식이 TCP 지연 시간인지 실제 연결 테스트인지 확인하세요. 그런 다음 프록시를 명시해 현재 접속이 안 되는 사이트에 요청을 보내고 코어 로그에 요청이 기록되는지 살펴봅니다.

v2rayN을 종료한 뒤 일반 웹페이지도 열리지 않나요?

시스템에 로컬 포트를 가리키는 프록시 설정이 남아 있을 수 있습니다. 클라이언트를 다시 실행하고 「시스템 프록시」에서 「시스템 프록시 해제」를 선택하세요. 또는 Windows의 「네트워크 및 인터넷」→「프록시」에서 남아 있는 수동 프록시를 끈 다음 직접 연결을 확인합니다.

웹사이트 한 곳만 열리지 않아도 클라이언트를 다시 설치해야 하나요?

먼저 같은 노드로 다른 HTTPS 사이트에 접속한 뒤 해당 도메인에 적용된 라우팅 규칙, DNS 조회 결과, 응답 상태를 확인하세요. 403 또는 429가 반환됐다면 HTTP 응답을 받은 것입니다. 먼저 재설치하기보다 사이트의 접속 정책이나 요청 제한을 살펴보세요.

TUN을 켜면 해결되는데 시스템 프록시도 고쳐야 하나요?

두 방식은 진입 경로가 다르므로 TUN이 작동한다고 시스템 프록시 설정까지 올바르다는 뜻은 아닙니다. 평소 시스템 프록시를 쓴다면 TUN을 끄고 포트 및 프록시 지정 테스트를 다시 진행하세요. TUN을 사용하기로 했다면 다른 트래픽 가로채기 프로그램과 동시에 작동하지 않도록 하세요.

문제 해결이 끝나면 임시로 바꾼 라우팅, 브라우저 DNS, 로그 수준을 원래대로 되돌리고 더 이상 필요하지 않은 테스트 설정을 삭제하세요. 해결되지 않았다면 클라이언트 및 코어 버전, 문제 발생 시각, 프록시 진입 포트, 테스트 대상, 민감 정보를 가린 오류 로그 일부를 정리하세요. 스크린샷을 공유하기 전에 구독 주소, 노드 인증 정보, 개인 네트워크 정보를 가리세요. 이런 정보가 단순히 “연결됨으로 표시된다”는 설명보다 문제를 찾는 데 도움이 됩니다.

v2rayN 다운로드