V2Ray 연결은 되는데 웹페이지가 열리지 않을 때: 시스템 프록시·DNS·라우팅 점검

이 글의 핵심

v2rayN 데스크톱 버전이나 v2rayNG·v2flyNG 안드로이드 버전에서 “앱은 실행 중인데 브라우저에서 사이트가 열리지 않는” 경우를 위한 안내입니다. 먼저 요청이 클라이언트에 도달하는지 확인한 다음, 코어가 원격 서버에 연결되는지 살펴보세요. 한 번에 한 항목만 변경하고 같은 주소로 다시 테스트해야 합니다. 아래에서 시스템 메뉴, 포트 확인 명령어, DNS 비교 방법, 로그 확인 기준을 안내합니다. 연결 아이콘이나 한 번의 지연 시간 테스트만으로 웹 접속이 된다고 판단하지 마세요.

1. 연결 상태와 웹 요청 구분하기

클라이언트에서 “연결됨”은 로컬 코어가 실행 중이라는 뜻일 수도 있고, 안드로이드 VPN 인터페이스가 연결됐다는 뜻일 수도 있습니다. 원격 서버 인증이 완료됐거나 웹 접속에 필요한 DNS·TCP·TLS가 모두 정상이라는 의미는 아닙니다. 지연 시간 테스트도 특정 주소나 연결 방식만 확인할 수 있어 모든 웹사이트의 접속 여부를 보장하지 않습니다.

현재 설정을 먼저 보존하고 오류가 발생한 시각, 사용 중인 서버, 연결 방식, 접속에 실패한 주소를 기록하세요. 테스트할 때마다 다른 경로로 연결되지 않도록 서버 자동 전환을 끄세요. DNS, 구독, 코어를 동시에 바꾸면 문제가 해결되어도 원인을 알기 어렵습니다.

모든 웹페이지 접속 실패: 기본 네트워크, 로컬 포트 수신 상태, 트래픽 연결 상태부터 확인하세요.
일부 도메인만 접속 실패: DNS, 라우팅 규칙 적용 여부, 대상 사이트 상태를 우선 비교하세요.
브라우저만 실패하고 다른 앱은 정상: 브라우저 프록시 확장 프로그램, 별도 프록시, 보안 DNS 설정을 확인하세요.
Wi-Fi에서는 정상이고 모바일 네트워크에서는 실패: 서버를 그대로 둔 채 다시 테스트하고 네트워크별 차이를 기록하세요. 구독이 만료됐다고 단정하지 마세요.

2. 시스템 프록시 및 VPN 연결 확인

v2rayN의 시스템 프록시는 시스템 프록시 설정을 따르는 앱의 요청을 로컬 포트로 전달합니다. TUN은 가상 네트워크 인터페이스로 트래픽을 연결합니다. 일반 브라우저 문제를 확인할 때는 변수를 줄이기 위해 시스템 프록시만 사용해 보세요. 이미 TUN을 사용 중이라면 원래 설정을 저장한 뒤 연결 방식을 바꿔 비교하세요.

현재 서버 확인

v2rayN 기본 화면에서 테스트하려는 서버 설정이 선택되어 있는지 확인하고, 로그에 코어 종료 기록이 있는지 살펴보세요. 목록에서 행을 선택하는 것과 해당 설정을 실제로 활성화하는 것은 다를 수 있으므로 현재 활성 설정과 로그를 기준으로 판단하세요.
시스템 프록시 설정

v2rayN 트레이 메뉴의 「시스템 프록시」에서 「시스템 프록시 자동 설정」을 선택하세요. 버전에 따라 메뉴 이름이 조금 다를 수 있습니다. 중요한 것은 메인 창만 실행하는 것이 아니라 시스템 프록시가 현재 수신 중인 로컬 주소를 가리키도록 설정하는 것입니다.
시스템 프록시 주소 확인

Windows 11에서 「설정」→「네트워크 및 인터넷」→「프록시」→「수동 프록시 설정」을 열어 주소와 포트를 확인하세요. 클라이언트가 자동 구성 스크립트를 사용한다면 해당 스크립트 설정을 확인하고, 수동 프록시를 추가로 설정하지 마세요.
브라우저 설정 덮어쓰기 확인

프록시를 변경하는 브라우저 확장 프로그램을 잠시 사용 중지한 뒤 브라우저를 다시 실행하세요. Firefox에서는 「설정」→「일반」→「네트워크 설정」→「설정」에서 시스템 프록시 사용 여부를 확인할 수 있습니다.
안드로이드 연결 확인

v2rayNG 또는 v2flyNG를 사용한다면 설정을 실행하고 VPN 연결 권한을 허용했는지 확인하세요. 앱별 프록시를 사용 중이면 브라우저가 적용 대상인지 확인하고, 다른 앱이 VPN 연결을 사용하고 있지는 않은지도 살펴보세요.

안드로이드의 VPN 아이콘은 인터페이스가 존재한다는 뜻일 뿐입니다. 시스템에서 클라이언트의 백그라운드 실행을 제한하면 실제 트래픽 전달 상태가 아이콘이나 앱 화면에 반영되지 않을 수 있습니다. 앱을 전면에 둔 채 같은 주소로 다시 접속하고 새 연결 로그가 기록되는지 확인하세요. 백그라운드 실행 권한은 시스템 「설정」→「앱」에서 해당 클라이언트의 배터리 관리 화면을 확인하세요. 메뉴 이름은 기기와 시스템에 따라 다를 수 있습니다.

3. 로컬 포트가 실제로 수신 중인지 확인

프록시 주소가 맞더라도 포트에서 수신 대기 중이지 않으면 브라우저는 연결할 수 없습니다. 아래에서는 로컬 SOCKS 인바운드 127.0.0.1:10808을 예로 듭니다. 이 포트는 테스트용이며 모든 버전이 같은 기본값을 사용해야 하는 것은 아닙니다. 먼저 클라이언트의 현재 인바운드 설정이나 시작 로그에서 실제 포트를 확인한 뒤 명령어의 숫자를 바꾸세요.

10808

이 섹션의 SOCKS 인바운드 예시 포트

일반 DNS 서비스에 주로 사용하는 포트

443

HTTPS 대상에 주로 사용하는 포트

Windows PowerShell에서 다음 명령어를 실행하세요. 첫 번째 명령은 TCP 수신 대기 및 연결 목록을 표시하고, 두 번째 명령은 로컬 TCP 연결이 가능한지만 확인합니다. LISTENING이 표시되면 마지막 열의 PID도 확인해 예상한 코어가 수신 중인지, 다른 프로세스가 포트를 사용 중인지 살펴보세요.

netstat -ano | findstr ":10808"
Test-NetConnection -ComputerName 127.0.0.1 -Port 10808

수신 기록이 없음: 코어 시작 로그를 확인해 설정이 정상적으로 로드됐는지 살펴보세요. 브라우저 프록시를 반복해서 바꾸지 마세요.
다른 프로세스가 수신 중: 작업 관리자의 「세부 정보」에서 PID를 찾으세요. 용도를 확인한 뒤 충돌하는 프로그램을 종료하거나 클라이언트 인바운드 포트를 변경하고 시스템 설정도 함께 수정하세요.
로컬 TCP 테스트 성공: 포트에서 연결을 수락한다는 뜻일 뿐, SOCKS 협상이나 원격 연결이 정상이라는 의미는 아닙니다.

이어서 시스템 프록시 설정을 거치지 않도록 프록시를 명시한 요청을 실행하세요. Windows에서는 명령어 별칭에 따른 매개변수 차이를 피하기 위해 curl.exe를 사용하고, macOS와 Linux에서는 시스템에 설치된 curl을 사용할 수 있습니다. 아래 명령어는 해당 포트가 SOCKS5를 지원해야 합니다. HTTP만 지원하는 인바운드 포트로 대체할 수 없습니다.

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

확인: 프록시를 명시한 요청이 성공하면 브라우저를 점검

이 명령어로 HTTP 응답을 받는데 브라우저에서는 접속되지 않는다면, 브라우저 프록시 재정의와 시스템 프록시 주소를 먼저 확인하세요. 403이나 405 응답도 HTTP 계층의 응답을 받은 것이므로 “로컬 포트에서 수신하지 않음”으로 분류하면 안 됩니다.

4. DNS 조회가 실패하는 구간 찾기

DNS는 최소 두 종류의 주소와 관련됩니다. 노드 서버의 도메인과 웹사이트의 도메인입니다. 전자를 조회하지 못하면 클라이언트가 원격 서버를 찾지 못하고, 후자를 조회하지 못하면 일부 웹사이트만 접속되지 않을 수 있습니다. 브라우저에 “서버를 찾을 수 없음”이 표시된다는 이유만으로 시스템 DNS를 바꿔야 한다고 판단하지 마세요.

먼저 로컬에서 도메인을 조회한 뒤 SOCKS 요청 두 가지를 비교하세요. socks5://는 일반적으로 curl이 로컬에서 대상 도메인을 조회하고, socks5h://는 대상 도메인 처리를 프록시에 맡깁니다. 후자의 경우 실제로 어떤 리졸버를 사용하는지는 코어의 DNS 및 라우팅 설정에 달려 있으며, 원격 서버의 시스템 DNS를 그대로 사용한다는 보장은 없습니다.

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

로컬 DNS 조회는 실패하지만 socks5h는 성공: 로컬 DNS 조회 경로를 우선 확인하세요. Windows에서는 DNS 설정을 변경한 뒤 ipconfig /flushdns를 실행할 수 있지만, 캐시를 지워도 연결할 수 없는 DNS 서버가 복구되지는 않습니다.
두 프록시 요청 모두 시간 초과: 라우팅과 원격 연결을 계속 확인하세요. DNS만 계속 바꾸지 마세요.
시스템 DNS 조회는 정상인데 브라우저만 실패: 브라우저의 보안 DNS 설정을 확인하세요. 시스템 조회와 다른 경로를 사용할 수 있습니다.
로그에 노드 도메인 문제가 표시됨: nslookup 뒤에 실제 노드 도메인을 입력해 확인하세요. 노드 도메인과 접속하려는 웹사이트 도메인을 혼동하지 마세요.

5. 라우팅 규칙과 서버 상태 확인

로컬 포트와 DNS가 모두 정상이라면 실패한 요청이 어떤 아웃바운드 규칙에 일치하는지 확인하세요. V2Ray/Xray 라우팅은 일반적으로 규칙 순서대로 일치 여부를 확인하며, 먼저 적용된 규칙이 트래픽 경로를 결정합니다. 범위가 지나치게 넓은 직접 연결·차단 규칙이나 앱 제외 설정 때문에 요청이 예상한 프록시를 완전히 우회할 수 있습니다.

현재 라우팅 모드와 사용자 지정 규칙을 기록하고 복원 가능한 사본을 보관하세요. 클라이언트의 연결 로그나 액세스 로그에서 테스트 도메인이 코어에 전달됐는지 확인하세요.
클라이언트에서 제공하는 전역 프록시 라우팅 모드로 잠시 전환한 뒤 같은 도메인에 다시 접속하세요. 여기서 바꾸는 것은 코어의 아웃바운드 선택 방식이지, 시스템 프록시 스위치를 다시 켜는 것이 아닙니다.
전역 모드에서는 성공하고 분할 라우팅 모드에서는 실패한다면 원래 모드로 돌아간 뒤 해당 도메인의 규칙 순서, 직접 연결 아웃바운드, 도메인/IP 일치 조건을 확인하세요.
전역 모드에서도 실패한다면 다른 설정은 그대로 둔 채 정상 작동이 확인된 다른 설정으로 비교하세요. 특정 설정만 실패할 때 해당 설정의 서버 주소, 포트, 인증 정보, 유효 기간을 확인하세요.

VMess와 VLESS는 프로토콜 유형이지 연결을 켜고 끄는 옵션이 아닙니다. 설정에 지정된 전송 방식, TLS, SNI 또는 REALITY 매개변수는 서버 설정과 일치해야 하며, 프로토콜을 임의로 바꿔 문제를 해결할 수 없습니다. v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 구독을 가져올 수 있다고 해서 현재 코어가 모든 매개변수를 지원한다는 뜻은 아닙니다. 클라이언트 선택이 필요하다면 클라이언트 선택 가이드를 확인하세요.

구독 업데이트 성공은 구독 내용을 가져올 수 있다는 뜻일 뿐, 그 안의 모든 설정으로 현재 접속할 수 있다는 의미는 아닙니다. 노드의 TCP 포트에 연결할 수 있어도 프로토콜 인증이 성공했다고 볼 수 없습니다. 테스트할 때는 한 서버를 고정하고 HTTPS 요청에 정상 응답이 오는지 확인한 뒤 자동 선택이나 복잡한 분할 라우팅을 다시 사용하세요.

6. 로그 오류별 다음 조치

실패한 요청을 한 번 실행한 뒤 발생 시각을 기준으로 가장 먼저 나타난 관련 오류를 확인하세요. 아래는 자주 보이는 오류 문구입니다. 코어에 따라 주소나 포트, 더 구체적인 원인이 함께 표시될 수 있습니다. 마지막 줄만 보고 모든 문제를 노드 탓으로 돌리지 마세요. 로그를 공유하기 전에는 구독 링크, 인증 정보, 개인 네트워크 정보를 삭제하세요.

오류: connection refused

원인: 대상 포트에서 연결을 거부했습니다. 로컬 프록시 포트 또는 원격 서버 포트에서 발생했을 수 있습니다.

해결: 먼저 오류에 표시된 주소를 확인하세요. 127.0.0.1이면 로컬 포트 수신 상태를, 노드 주소라면 서버 포트와 서비스 상태를 확인하세요.

오류: no such host

원인: 도메인을 조회하지 못했습니다. 같은 줄이나 인접한 로그를 확인해 어떤 도메인인지 파악하세요.

해결: 먼저 도메인 철자를 확인한 뒤 노드 도메인과 웹사이트 도메인을 구분하고, 앞 절의 방법으로 해당 DNS 조회 경로를 검사하세요.

오류: context deadline exceeded

원인: 작업이 제한 시간을 초과했습니다. DNS, 원격 연결, 핸드셰이크 대기 등 여러 원인이 있을 수 있으며, 이 오류만으로 특정 장애를 단정할 수 없습니다.

해결: 앞선 로그를 함께 확인해 어느 단계에서 멈췄는지 파악한 다음, 같은 서버로 네트워크를 바꾸거나 같은 네트워크에서 서버를 바꿔 한 가지 변수만 비교하세요.

오류: address already in use

원인: 코어가 바인딩하려는 로컬 주소와 포트를 다른 프로세스가 사용 중이라 해당 인바운드를 시작하지 못했습니다.

해결: 포트 확인 명령어로 PID를 찾고 충돌을 해결한 뒤 코어를 다시 시작하세요. 시스템 프록시가 실제로 사용하는 새 포트를 가리키는지도 확인하세요.

인증서 만료, 인증서 호스트 이름 불일치 또는 핸드셰이크 오류가 발생하면 먼저 시스템 날짜·시간·시간대를 확인한 다음 구독에 지정된 TLS 매개변수를 살펴보세요. 인증서 검증을 건너뛰는 방법을 일반적인 해결책으로 사용하지 마세요. 문제가 해결되면 임시 상세 로그를 끄고 불필요하게 접속 기록을 계속 남기지 않도록 하세요.

7. 접속 복구 후 자주 묻는 질문

속도 테스트는 성공했는데 웹페이지는 왜 시간 초과되나요?

속도 테스트는 지정된 주소에 연결할 수 있는지만 확인할 수 있습니다. 이 글의 프록시 지정 명령어로 실제 HTTPS 요청을 확인하고 브라우저 결과와 비교하세요. 브라우저에서만 실패한다면 브라우저의 별도 프록시와 보안 DNS를 먼저 점검하세요.

TUN을 켜면 모든 앱의 인터넷 연결 문제가 해결되나요?

아닙니다. TUN은 트래픽 연결 방식을 바꿀 뿐, 사용할 수 없는 서버나 잘못된 인증 정보를 자동으로 고치지 않습니다. 먼저 시스템 프록시 모드에서 외부 연결을 확인하세요. 시스템 프록시를 따르지 않는 앱의 트래픽까지 연결해야 할 때 TUN을 켜고 클라이언트 안내에 따라 권한, 라우팅, DNS를 확인하세요.

클라이언트를 종료한 뒤 브라우저에서 오히려 접속할 수 없어요

로컬 포트를 가리키는 시스템 프록시 설정이 남아 있는지 확인하세요. Windows 「설정」→「네트워크 및 인터넷」→「프록시」에서 수동 프록시를 해제하거나, v2rayN을 다시 실행한 뒤 「시스템 프록시」→「시스템 프록시 해제」를 선택하세요.

문제 해결 후 어떤 설정을 유지해야 하나요?

비교 테스트로 효과를 확인한 변경 사항만 유지하세요. 임시 전역 라우팅을 원래대로 돌리고 디버그 로그를 끈 뒤 브라우저의 프록시 방식이 현재 연결 방식과 일치하는지 확인하세요. 수정한 항목, 테스트 주소, 시간을 기록해 두면 다음에 문제가 생겼을 때 같은 지점부터 확인할 수 있습니다.

원인을 찾지 못했다면 클라이언트 이름, 코어 종류, 연결 모드, 민감 정보를 삭제한 로그, “프록시 지정 요청의 성공 여부”를 정리하세요. 연결됨 화면만 캡처하는 것보다 문제 범위를 파악하는 데 도움이 됩니다. 기본 설정은 설치 및 설정 가이드에서 확인하고, 관련 개념은 용어집을 참고하세요.