v2rayN 연결됨 표시인데 웹페이지가 열리지 않을 때: 시스템 프록시·라우팅 규칙·DNS 점검

핵심 내용

v2rayN에서 서버를 선택하고 코어가 실행 중인데도 브라우저가 시간 초과되거나 프록시 오류를 표시할 때 확인할 내용입니다. 먼저 트래픽이 로컬 프록시로 전달되는지 확인하고 포트와 라우팅을 점검한 뒤 DNS와 시스템 시간을 살펴보세요. Windows 데스크톱을 예로 들어 명시적 프록시 요청과 로그를 활용해 브라우저 설정, 로컬 수신 대기, 원격 연결 문제를 구분합니다. 한 번에 한 항목씩 변경하고 결과를 확인한 뒤 다음 단계로 넘어가세요.

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

메인 화면에 실행 중으로 표시되더라도 클라이언트가 해당 시작 작업을 마쳤다는 뜻일 뿐, 원하는 웹사이트에 접속할 수 있다는 보장은 아닙니다. 서버 목록의 지연 시간에도 테스트 범위가 있습니다. TCP 연결 성공이 프로토콜 인증 성공을 뜻하지 않으며, 특정 테스트 주소에 접속된다고 모든 사이트가 열리는 것도 아닙니다. 문제를 확인할 때는 동일한 주소를 계속 사용하세요. 테스트 사이트가 달라지면 네트워크 차이를 설정 변경 효과로 오해할 수 있습니다.

현재 설정을 먼저 저장하고 사용 중인 서버, 시스템 프록시 상태, 라우팅 모드, 로컬 포트, 테스트 시간을 기록하세요. 아래 숫자는 재현을 위한 명령 매개변수이며 속도 측정 결과도, 모든 기기의 기본 설정값도 아닙니다. 클라이언트에 표시된 수신 대기 포트가 다르면 이후 명령에도 실제 값을 사용해야 합니다.

127.0.0.1

원격 서버가 아닌 로컬 루프백 주소

10808

이 문서의 프록시 포트 예시입니다. 실제 수신 대기 포트를 확인하세요.

15초

실패한 테스트를 끝내기 위한 요청당 전체 시간 제한

TUN을 먼저 끄고 시스템 프록시로 기본 점검을 진행하세요. 트래픽을 처리하는 경로가 두 개 겹치지 않도록 합니다.
프록시, 가상 네트워크 어댑터 또는 DNS 설정을 바꾸는 다른 네트워크 도구는 잠시 중지하세요. 조직에서 관리하는 기기라면 먼저 관리 정책을 따르세요.
v2rayN의 로그 창을 열고 요청 오류가 발생한 시각을 기록하세요. 시작 성공 메시지만 캡처해서는 안 됩니다.
일반 네트워크에 연결되어 있는지 확인하세요. 웹 로그인 인증이 필요한 네트워크라면 시스템 프록시를 해제하고 인증을 완료한 뒤 다시 테스트하세요.

2. 시스템 프록시: 브라우저 요청이 v2rayN을 거치는지 확인

시스템 프록시 설정과 서버 선택은 서로 별개입니다. 서버를 선택했더라도 시스템 프록시가 해제되어 있으면 시스템 설정을 따르는 브라우저는 직접 연결할 수 있습니다. 반대로 클라이언트를 종료한 뒤 시스템 프록시 설정이 남아 있으면 이미 수신 대기를 멈춘 로컬 포트에 브라우저가 계속 연결을 시도할 수 있습니다.

시스템 프록시 사용

v2rayN의 「시스템 프록시」 메뉴에서 「시스템 프록시 자동 설정」을 선택하세요. 데스크톱 화면에서 메뉴 위치는 버전에 따라 달라질 수 있으므로 메뉴 이름과 실제 상태를 기준으로 확인하세요.
시스템 설정 확인

Windows 11에서 「설정」→「네트워크 및 인터넷」→「프록시」를 열고 「수동 프록시 설정」의 주소와 포트를 확인하세요. 원격 노드 주소가 아니라 클라이언트의 HTTP 또는 혼합 프록시 수신 설정과 일치해야 합니다.
브라우저 자체 설정 확인

프록시 전환 확장 프로그램을 잠시 끄고 브라우저에 별도 프록시가 지정되어 있는지 확인하세요. 독립 프록시 설정을 사용하는 브라우저라면 시스템 프록시를 사용하도록 바꾼 뒤 테스트 페이지를 다시 여세요.
클라이언트 종료 상태 확인

클라이언트를 종료하고 직접 연결을 테스트하려면 「시스템 프록시」→「시스템 프록시 해제」를 선택해 설정을 되돌리세요. 창만 닫아도 트레이에 계속 실행 중일 수 있으므로 창이 사라졌다는 이유만으로 코어가 종료됐다고 판단하지 마세요.

「시스템 프록시 자동 설정」은 클라이언트 메뉴의 동작입니다. Windows에서 자동 구성 스크립트 주소를 직접 입력해야 한다는 뜻은 아닙니다. 조직에서 배포한 스크립트나 프록시 정책이 있다면 덮어쓰고 결과를 추측하지 마세요. 명령줄 프로그램이 Windows 시스템 프록시를 따르지 않을 수도 있으므로 다음 단계에서는 명시적 매개변수로 이 변수를 제외합니다.

3. 로컬 포트: 수신 대기 여부를 확인한 뒤 명시적 프록시 테스트

포트 번호는 현재 설정이나 시작 로그에서 확인해야 합니다. 버전, 기존 설정, 사용자 지정 값에 따라 포트가 다를 수 있으므로 오래된 안내의 HTTP 포트를 현재 혼합 포트에 그대로 적용하지 마세요. Windows PowerShell에서 아래 명령을 실행해 예시 포트의 수신 대기 여부를 확인하세요.

netstat -ano -p tcp | findstr ":10808"

주소가 127.0.0.1:10808이고 상태가 LISTENING인 행을 찾으세요. 마지막 열은 프로세스 PID입니다. 다른 주소에서 수신 대기 중이라면 실제 설정에 따라 판단해야 합니다. 그런 다음 「작업 관리자」→「세부 정보」에서 해당 PID의 프로세스를 확인해 다른 프로그램의 수신 대기를 v2rayN 코어로 착각하지 않도록 하세요.

curl.exe --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 15 -I https://www.example.com/
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 15 -I https://www.example.com/

두 명령은 해당 포트가 HTTP, SOCKS 또는 두 방식을 모두 지원하는 경우에만 사용할 수 있습니다. 혼합 수신 포트라면 차례대로 테스트하고, 포트가 분리되어 있다면 각각 실제 포트로 바꾸세요. --noproxy ""는 프록시 제외 목록의 영향을 배제하고, socks5h는 대상 도메인 처리를 프록시 쪽에 맡깁니다. 이후 DNS 조회 위치는 코어 설정에 따라 달라집니다. 테스트 도메인은 비교를 위해 고정한 주소이며 모든 네트워크에서 접속 가능하다는 보장은 없습니다.

확인 결과	우선 확인할 항목	다음 단계
수신 대기가 없어 연결이 즉시 거부됨	코어 미실행, 잘못된 포트 입력 또는 수신 대기 실패	시작 로그와 포트 사용 여부부터 확인
명시적 프록시는 성공하지만 브라우저는 실패	시스템 프록시 설정이나 브라우저 자체 설정이 다를 가능성	시스템 설정으로 돌아가 프록시 확장 프로그램을 끈 뒤 다시 테스트
로컬 수신 대기는 정상인데 요청 시간 초과	라우팅, 서버 연결 또는 DNS 조회 단계의 문제일 수 있음	같은 시각의 코어 로그를 대조
대상 사이트의 HTTP 응답을 받음	해당 요청이 HTTP 서버까지 도달함	네트워크 연결 문제와 사이트 자체의 접속 거부를 구분

4. 라우팅 규칙: 프록시로 들어오는 경로와 프록시를 통한 출구를 구분

브라우저가 요청을 로컬 프록시에 전달한 뒤에도 코어는 라우팅 규칙에 따라 프록시, 직접 연결 또는 차단 중 어떤 방식으로 내보낼지 결정합니다. 따라서 시스템 프록시가 켜져 있다고 모든 도메인이 원격 서버를 거치는 것은 아닙니다. 특히 사용자 지정 규칙을 가져온 뒤 범위가 지나치게 넓은 직접 연결 규칙이 있으면 대상 요청이 로컬에서 바로 나갈 수 있습니다.

현재 규칙을 먼저 저장하세요: 선택한 라우팅 설정을 기록하고 사용자 지정 규칙을 복사해 두세요. 삭제한 뒤 기본값을 기억에 의존해 복구하려고 하지 마세요.
규칙 적용 순서를 확인하세요: 대상 도메인이 앞쪽의 도메인, 주소 범위 또는 인바운드 조건에 일치하는지 살펴보세요. 규칙은 순서대로 적용되는 경우가 많아 뒤에 있는 프록시 규칙이 실행되지 않을 수 있습니다.
한 가지 조건만 바꿔 비교하세요: 「라우팅」 메뉴에서 전역 프록시로 명확하게 표시된 내장 설정을 잠시 선택한 뒤, 앞 절의 명령으로 같은 URL을 테스트하세요. 서버와 DNS를 동시에 바꾸지 마세요.
로그와 함께 확인하세요: 로그에 아웃바운드 태그가 표시되면 실제 아웃바운드가 예상과 일치하는지 살펴보세요. 태그 이름은 설정에서 정하는 것이므로 이름만 보고 프로토콜을 추측할 수 없습니다.
검증 후 분할 라우팅을 복원하세요: 전역 프록시가 정상이라면 기존 설정을 복원한 뒤 실제로 일치하는 규칙을 찾으세요. 규칙 문제를 가리기 위해 모든 요청을 장기간 하나의 경로로 보내지 마세요.

라우팅의 도메인 조회 정책은 IP 기반 규칙 적용에도 영향을 줍니다. 대상 도메인이 서로 다른 주소로 해석되면 다른 규칙과 일치할 수 있으므로 모든 문제를 노드 탓으로 돌리는 것은 정확하지 않습니다. 인바운드, 라우팅, 아웃바운드의 관계만 확인하려면 고급 설정을 참고하세요. 다만 이번 테스트에서는 현재 코어와 호환되지 않는 전체 설정을 그대로 붙여 넣지 마세요.

5. DNS 조회: 서버 주소와 대상 도메인을 각각 확인

조회 대상은 적어도 두 가지입니다. 원격 서버 자체의 도메인과 브라우저 요청의 대상 도메인입니다. 서버 도메인을 조회하지 못하면 보통 원격 서버에 연결하기도 전에 실패합니다. 대상 도메인 조회가 실패하면 일부 사이트만 열리지 않을 수 있습니다. 브라우저의 보안 DNS, 시스템 DNS, 코어 DNS도 서로 다른 설정이므로 하나를 바꿔도 다른 경로까지 함께 바뀐다고 볼 수 없습니다.

nslookup www.example.com
ipconfig /flushdns

첫 번째 명령은 시스템의 현재 DNS 리졸버가 대상 도메인에 어떤 응답을 반환하는지 확인합니다. 노드 설정에 실제 서버 도메인이 있다면 그 도메인도 같은 방법으로 조회하세요. 서버 주소를 IP로 입력했다면 이 단계의 도메인 조회는 필요하지 않습니다. 두 번째 명령은 Windows DNS 클라이언트 캐시를 비우지만 브라우저나 코어의 캐시까지 자동으로 지우지는 않습니다. 시스템 조회가 성공해도 프록시 측 DNS 조회가 성공했다고 단정할 수 없습니다.

오류: curl: (5) Could not resolve proxy

원인 및 해결: 프록시 호스트 이름을 조회할 수 없어 발생한 오류입니다. 문제는 대상 사이트가 아니라 프록시 진입점에 있습니다. 명령의 프록시 주소를 확인하세요. 로컬 테스트에서는 실제 루프백 수신 주소를 사용하고 원격 노드 도메인을 HTTP 프록시 주소에 잘못 입력하지 마세요.

오류: curl: (6) Could not resolve host

원인 및 해결: 현재 요청 경로에서 대상 호스트를 조회하지 못했습니다. 먼저 요청이 의도한 대로 프록시를 사용하는지 확인한 다음 시스템 조회, 코어 DNS 조회, 브라우저의 보안 DNS 설정을 비교하세요. 페이지를 반복해서 새로고침하는 것만으로 복구 여부를 판단하지 마세요.

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

원인 및 해결: 수신 대기를 시작할 때 주소나 포트가 충돌한 것입니다. 포트 조회로 PID를 찾고 프로세스가 무엇인지 확인한 뒤 중복 실행을 종료하거나 수신 포트를 바꾸고 시스템 프록시 설정도 함께 수정하세요. 정체를 모르는 시스템 프로세스를 바로 종료하지 마세요.

일반 SOCKS 요청은 실패하지만 socks5h 요청은 성공한다면 로컬 대상 도메인 조회를 집중적으로 살펴볼 수 있습니다. 다만 이는 문제를 좁히기 위한 단서일 뿐 확정적인 결론은 아닙니다. 암호화 DNS를 사용하는 경우 DNS 리졸버에 연결하는 경로 자체가 프록시에 의존할 수도 있습니다. 프록시 연결에 필요한 서버 도메인을 조회하는 데 아직 연결되지 않은 프록시를 다시 필요로 하는 순환 의존이 생기지 않도록 하세요. 설정을 바꾼 뒤 코어를 재시작하고 같은 대상을 다시 테스트하세요.

6. 시간 동기화와 핸드셰이크: 검증을 끄는 방식으로 오류를 우회하지 마세요

시간 오차는 인증서 유효기간 판정에 영향을 줄 수 있으며 VMess 등의 프로토콜 인증에도 영향을 미칠 수 있습니다. VLESS 자체와 그 바깥 계층의 TLS, REALITY 등 전송 보안 설정은 별도로 봐야 합니다. 프로토콜 인증 실패, 인증서 오류, 네트워크 시간 초과는 각각 다르게 해결해야 하며 실행 중 표시만으로 이런 문제를 배제할 수는 없습니다.

Windows에서 「설정」→「시간 및 언어」→「날짜 및 시간」을 열고 「시간 자동 설정」을 켠 다음 시간대를 확인하고 「지금 동기화」를 선택하세요.
동기화에 실패하면 먼저 Windows 시간 서비스와 시간 서버에 접속할 수 있는 조건을 확인하세요. 조직에서 관리하는 기기라면 관리자에게 문의하세요. 시간대 표시만 바꾸고 실제 시스템 시간이 잘못된 상태로 두지 마세요.
요청을 다시 보내고 로그에 인증서 만료, 유효 기간 시작 전 또는 핸드셰이크 실패 메시지가 계속 나타나는지 확인하세요.
노드에서 제공한 서버 주소, 포트, 사용자 식별자, 전송 매개변수를 확인하세요. TLS 서버 이름, REALITY 공개 키 등의 값은 서버 설정과 일치해야 하며 추측으로 바꾸지 마세요.

7. 자주 묻는 질문과 점검 마무리

지연 시간은 표시되는데 웹페이지가 시간 초과되는 이유는 무엇인가요?

지연 시간 테스트는 해당 테스트 경로만 확인합니다. 먼저 명시적 프록시 명령으로 고정 URL에 접속하고 관련 로그를 확인하세요. TCP 지연 시간이 정상이어도 사용자 식별자, TLS 매개변수 또는 대상 사이트 접속까지 성공했다고 볼 수 없습니다.

TUN을 켜야만 사용할 수 있는데 시스템 프록시가 고장 난 건가요?

반드시 그렇지는 않습니다. 앱이 시스템 프록시를 따르지 않거나 별도의 프록시 설정을 사용할 수 있습니다. 먼저 TUN을 끄고 브라우저와 명시적 프록시 요청을 각각 테스트하세요. 명시적 프록시만 정상이고 브라우저가 실패할 때 앱의 프록시 연결 방식을 우선 확인하면 됩니다.

다른 노드로 바꾸니 정상 작동합니다. 원래 노드가 고장 난 건가요?

두 설정의 차이와 문제 사이에 관련이 있다는 점만 알 수 있습니다. 서버 도메인, 포트, 프로토콜, 전송 매개변수를 비교하고 다시 테스트하세요. 구독 갱신으로 서버 정보가 바뀌었을 수 있으므로 출처를 확인한 뒤 해당 그룹을 업데이트하세요. 전체 구독 URL을 공개 게시판에 올리지 마세요.

v2rayN을 종료한 뒤 모든 웹페이지가 열리지 않으면 어떻게 해야 하나요?

먼저 Windows 「설정」→「네트워크 및 인터넷」→「프록시」에서 로컬 프록시 설정이 남아 있는지 확인하세요. 필요하면 v2rayN을 다시 실행하고 「시스템 프록시」→「시스템 프록시 해제」를 선택한 뒤 직접 연결을 테스트하세요. 조직에서 관리하는 프록시 설정은 임의로 삭제하지 마세요.

점검을 마친 뒤 임시로 끈 기능을 복원하고 최종적으로 정상 작동한 설정을 저장하세요. 추가 지원을 요청할 때는 클라이언트 및 코어 버전, 운영체제, 수신 대기 포트, 라우팅 모드, 오류 발생 시각, 민감 정보를 가린 로그를 함께 제공하세요. 구독 토큰, 사용자 식별자 및 기타 인증 정보는 삭제하되 오류 유형과 발생 순서는 남겨 두세요. 이런 기록은 「연결됨」 화면 한 장보다 문제를 찾는 데 도움이 됩니다.

명시적 프록시는 성공하지만 브라우저가 실패함: 시스템 프록시와 브라우저 설정을 집중적으로 확인하세요.
수신 대기가 없거나 포트 충돌이 발생함: 원격 프로토콜을 바꾸기 전에 로컬 코어 실행 문제부터 해결하세요.
전역 프록시는 성공하지만 분할 라우팅이 실패함: 규칙 일치 여부, DNS 조회 정책, 실제 아웃바운드를 확인하세요.
모든 경로에서 실패함: DNS, 핸드셰이크 로그, 서버 매개변수를 함께 확인하고 설정을 계속 덧붙이지 마세요.