v2rayN 연결됨으로 표시되지만 인터넷이 안 될 때: 단계별 점검

핵심 내용

서버를 선택했고 코어도 실행 중인 것처럼 보이지만 브라우저에서 시간 초과 또는 연결 거부가 발생할 때 적용할 수 있습니다. 먼저 브라우저 요청이 v2rayN으로 전달되는지 확인한 다음 로컬 리스너, 원격 서버, TLS 핸드셰이크를 점검하고 라우팅과 방화벽을 살펴보세요. 한 번에 하나씩만 변경하고 같은 테스트 URL을 사용해야 우연히 복구된 상황을 해결로 착각하지 않습니다.

1. 시스템 프록시: 브라우저 요청이 코어에 전달되는지 확인

‘연결됨’은 웹 페이지에 접속할 수 있다는 뜻이 아닙니다. 서버를 선택하면 이후 연결에 해당 설정이 사용되고, 코어가 시작되면 프로세스가 실행 중이라는 의미입니다. 브라우저의 프록시 사용 여부, 서버의 연결 수락 여부, 대상 사이트의 응답 여부는 각각 별도로 확인해야 합니다. 우선 메인 창에서 ‘TUN 활성화’를 잠시 끄고 시스템 프록시만으로 기본 테스트를 진행하세요. 두 가지 연결 방식이 동시에 작동하면 원인을 찾기 어렵습니다.

시스템 프록시 설정

v2rayN 메인 창에서 ‘시스템 프록시’ → ‘시스템 프록시 자동 설정’을 선택합니다. 버전에 따라 창 아래쪽에 메뉴가 있거나 트레이 아이콘의 오른쪽 클릭 메뉴에서 설정할 수 있습니다. ‘시스템 프록시 지우기’ 또는 ‘시스템 프록시 변경 안 함’을 선택하지 않도록 주의하세요.
Windows 설정 확인

Windows 11에서 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’ → ‘수동 프록시 설정’으로 이동합니다. 프록시 서버가 켜져 있는지, 주소가 127.0.0.1인지, 포트가 클라이언트의 실제 HTTP 또는 혼합 리스너 포트와 일치하는지 확인하세요.
브라우저 설정 확인

브라우저의 프록시 확장 프로그램을 잠시 사용 중지합니다. Edge와 Chrome은 일반적으로 시스템 프록시 설정을 따릅니다. Firefox는 ‘설정’ → ‘일반’ → ‘네트워크 설정’ → ‘설정’에서 ‘시스템 프록시 설정 사용’을 선택했는지 확인하세요.
새 로그 확인

이전에 접속에 실패한 HTTPS 페이지를 열고 메인 창의 로그나 연결 목록을 확인합니다. 해당 도메인의 새 요청이 보이면 요청이 적어도 코어까지 전달된 것입니다. 기록이 전혀 없다면 서버를 바꾸기 전에 브라우저의 프록시 설정부터 확인하세요.

버전에 따라 로그 수준 설정으로 접속 기록이 표시되지 않을 수 있습니다. 따라서 ‘기록이 없다’는 것은 단서일 뿐 확정적인 증거는 아닙니다. 뒤에서 안내하는 명시적 프록시 명령을 사용하면 시스템 프록시 설정을 거치지 않고 로컬 연결을 바로 확인할 수 있습니다.

2. 리스너 포트: 미실행과 포트 충돌 구분

‘설정’ → ‘환경설정’에서 로컬 리스너 포트를 확인합니다. 최신 v2rayN은 HTTP와 SOCKS 요청을 모두 받는 혼합 포트로 10808을 사용하는 경우가 많습니다. 일부 구형 설정에서는 SOCKS와 HTTP 포트가 각각 10808, 10809로 나뉩니다. 이전 가이드의 포트를 현재 시스템 설정에 그대로 입력하지 마세요. 아래 명령은 실제 혼합 포트가 10808인 경우를 기준으로 합니다.

netstat -ano | findstr :10808
curl.exe -I --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 https://www.microsoft.com/

netstat 출력에서 로컬 주소에 해당하는 LISTENING 행을 확인하세요. 마지막 열에는 프로세스 PID가 표시됩니다. ‘작업 관리자’ → ‘세부 정보’에서 PID를 찾아 현재 실행한 코어가 리스너인지 확인하세요. 다른 클라이언트 인스턴스가 포트를 사용 중일 수도 있습니다. 명령의 10초는 연결 시간 초과 한도, 20초는 요청 전체의 시간 제한이며 측정된 네트워크 지연 시간이 아닙니다.

확인 결과	우선 판단할 항목	다음 단계
LISTENING 행이 없음	포트 설정 오류 또는 코어 시작 실패	시작 로그를 확인하고 설정 오류를 수정한 뒤 서버를 다시 선택하세요
리스너 PID가 다른 프로그램에 해당함	포트 충돌	충돌하는 프로그램을 종료하거나 로컬 포트를 변경한 뒤 시스템 프록시 설정도 업데이트하세요
명시적 프록시 요청에 대상 사이트의 HTTP 응답이 있지만 브라우저에서는 실패함	로컬 연결과 해당 요청은 대체로 정상	브라우저 확장 프로그램, 개별 프록시 설정, 캐시된 연결을 확인하세요
로컬 리스너는 정상인데 요청이 계속 시간 초과됨	원격 연결, DNS 또는 라우팅 문제 가능성	다른 서버로 테스트하고 같은 시각의 오류 로그를 확인하세요

결론: 먼저 로컬 연결을 확인한 뒤 원격 연결을 점검하세요

명시적 프록시 명령으로 대상 사이트의 응답을 받았다면 현재 서버와 포트를 유지하고 브라우저의 프록시 경로만 점검하세요. HTTP CONNECT 연결이 성립했다는 메시지만으로는 충분하지 않습니다. 이후 TLS 핸드셰이크와 대상 사이트의 응답까지 확인해야 접속이 성공했다고 판단할 수 있습니다.

3. 서버 연결 상태: Tcping 성공이 프록시 정상 작동을 뜻하지는 않습니다

서버 목록에서 대상을 선택한 뒤 마우스 오른쪽 버튼 메뉴에서 ‘서버 실제 연결 지연 시간 테스트’를 실행하세요. ‘서버 지연 시간 테스트 Tcping’도 함께 사용해 비교할 수 있습니다. 메뉴 이름은 버전에 따라 다를 수 있습니다. 중요한 점은 TCP 포트에 연결할 수 있는지와 프록시 요청 전체가 완료되는지를 구분하는 것입니다. 구독을 가져왔다는 사실은 설정을 읽었다는 뜻일 뿐 원격 서비스가 여전히 작동한다는 보장은 아닙니다.

Tcping은 성공하지만 실제 연결은 실패: 프로토콜, 포트, 사용자 ID, 전송 방식, TLS의 serverName, 서버에서 요구하는 기타 인증 매개변수를 우선 확인하세요. TCP 핸드셰이크만으로는 이러한 설정을 검증할 수 없습니다.
두 테스트 모두 시간 초과: 서버 도메인이 올바르게 해석되는지, 원격 포트의 서비스가 실행 중인지 확인하세요. 같은 서버를 다른 네트워크에서도 테스트해 비교합니다.
실제 연결은 성공하지만 특정 사이트만 열리지 않음: 다른 HTTPS 사이트도 테스트하세요. 속도 테스트 주소에는 다른 라우팅 규칙이 적용될 수 있으므로 대상 도메인의 라우팅 문제나 서버 측 제한을 배제할 수 없습니다.
다른 서버는 정상: 정상 서버를 비교 기준으로 유지한 다음 문제가 있는 서버의 구독 정보를 확인하세요. 클라이언트를 재설치하고 DNS를 초기화하고 방화벽을 변경하는 작업을 한꺼번에 진행하지 마세요.

VMess와 VLESS는 서로 바꿔 쓸 수 있는 선택지가 아니라 각각 별도의 프로토콜 설정입니다. ‘시험 삼아’ 서버 프로토콜을 임의로 바꾸거나 TLS 검증 조건을 삭제하지 마세요. 제공자가 주소나 인증 정보를 변경했다면 ‘구독 그룹’ 메뉴에서 해당 구독을 업데이트한 뒤 현재 선택한 서버가 최신 항목을 가리키는지 확인하세요.

오류: connection refused

원인 및 해결: 대상 주소의 포트에서 연결을 거부했습니다. 오류에 표시된 주소를 먼저 확인하세요. 127.0.0.1:10808이면 로컬 리스너를 점검하고, 서버 주소라면 원격 포트와 서비스 상태를 확인하세요.

오류: i/o timeout

원인 및 해결: 연결 과정 중 어느 단계에서든 대기 시간이 초과될 수 있습니다. 이 문구만으로는 문제 위치를 특정할 수 없습니다. 전체 로그에 표시된 대상 주소를 바탕으로 서버 연결, DNS 조회, 대상 사이트의 응답을 각각 확인하세요.

4. 시스템 시간과 TLS: 검증을 끄는 방식으로 오류를 우회하지 마세요

시스템 시간이 크게 어긋나면 인증서 유효 기간을 잘못 판단할 수 있으며 시간 검증이 포함된 프로토콜 인증에도 영향을 줄 수 있습니다. Windows ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’에서 ‘자동으로 시간 설정’을 켜고 시간대를 확인한 다음 ‘지금 동기화’를 클릭하세요. 바탕 화면의 시각이 대략 맞아 보이는 것보다 날짜와 실제 시간이 정확한지가 중요합니다.

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

원인 및 해결: 인증서가 만료되었거나 아직 유효하지 않거나, PC의 시계가 잘못되었을 수 있습니다. 먼저 시스템 시간을 동기화하세요. 시간이 정확한데도 문제가 반복되면 서버 운영자에게 인증서 유효 기간을 확인해 달라고 요청하세요.

오류: x509: certificate signed by unknown authority

원인 및 해결: 인증서 체인을 신뢰할 수 없거나 네트워크에서 HTTPS 검사가 이루어지고 있을 수 있습니다. 서버 인증서 체인과 네트워크 환경을 확인하세요. 인증서 검증을 건너뛰도록 설정하지 마세요.

TLS를 사용하는 서버에서는 연결 주소와 인증서 검증에 사용하는 serverName이 서로 다를 수 있으므로 서버 설정에 맞게 입력해야 합니다. serverName을 흔히 쓰이는 웹사이트 도메인으로 임의 변경하지 마세요. REALITY 서버라면 공개 키, shortId, 서버에서 지정한 serverName도 확인하세요. 이러한 매개변수가 잘못된 경우 로컬 리스너 포트를 바꿔도 해결되지 않습니다.

5. 라우팅과 DNS: 전체 라우팅은 비교 테스트에만 사용

앞의 네 항목을 확인한 뒤 메인 창의 ‘라우팅’ 설정을 점검하세요. 현재 규칙 이름을 기록하고 내장 ‘전역’ 모드로 잠시 바꾼 다음 동일한 실패 URL을 다시 테스트합니다. 일반 프록시 요청에서는 기존의 직접 연결, 프록시 또는 차단 규칙이 잘못 선택되었는지 확인하는 데 도움이 됩니다. 다만 모든 앱과 DNS 요청이 프록시를 거친다는 뜻은 아닙니다.

테스트 결과	가능한 원인	확인할 위치
전역 모드에서는 접속되지만 기존 규칙에서는 실패	대상 사이트가 직접 연결되거나 차단되었거나 적절하지 않은 경로로 연결됨	‘설정’ → ‘라우팅 설정’에서 규칙 순서와 대상 도메인 조건을 확인하세요
로그에 no such host가 표시됨	도메인 이름을 해석하지 못함	해석에 실패한 주소가 서버인지 대상 사이트인지 구분한 뒤 해당 DNS 경로를 확인하세요
사용자 지정 라우팅에서만 시작 실패	규칙 문법 오류 또는 필요한 데이터 파일을 사용할 수 없음	내장 규칙으로 되돌린 뒤 시작 로그에서 오류가 발생한 필드와 파일을 확인하세요
전역 모드와 기존 규칙 모두 실패	라우팅이 원인이 아닐 수도 있음	서버 핸드셰이크와 로컬 연결을 다시 확인하고 도메인 규칙을 계속 추가하지 마세요

라우팅은 일반적으로 규칙 순서대로 일치 항목을 찾습니다. 앞쪽의 포괄적인 규칙이 뒤쪽의 구체적인 규칙을 가릴 수 있습니다. geosite:cn, geoip:private 등의 규칙을 사용한다면 현재 코어에서 필요한 데이터를 읽을 수 있는지도 확인하세요. Xray와 다른 코어의 설정 형식은 모든 부분이 같지 않으므로 서로 다른 코어의 설정을 통째로 복사해 붙여 넣지 마세요.

Windows 터미널에서 nslookup www.microsoft.com을 실행하면 현재 시스템의 DNS 조회 경로를 확인할 수 있지만 코어의 원격 DNS가 정상이라는 증거는 되지 않습니다.
시스템 DNS 캐시가 의심된다면 관련 설정을 변경한 뒤 ipconfig /flushdns를 실행하고 브라우저를 다시 열어 테스트하세요. 캐시를 비워도 서버 인증 오류는 해결되지 않습니다.
테스트를 마친 뒤 기존 라우팅으로 되돌리고 규칙을 하나씩 수정하세요. 임시 전역 모드를 모든 DNS 문제의 영구적인 해결책으로 사용하지 마세요.

6. 방화벽과 TUN: 마지막으로 권한과 차단 여부 확인

로컬 리스너, 서버 설정, DNS 조회가 모두 정상인 경우에만 보안 프로그램의 차단 기록을 확인하세요. ‘Windows 보안’ → ‘방화벽 및 네트워크 보호’ → ‘고급 설정’으로 이동해 ‘아웃바운드 규칙’에서 현재 코어 실행 파일을 차단하는 규칙이 있는지 살펴봅니다. 클라이언트 업데이트 후 프로그램 경로가 바뀔 수 있으므로 기존 규칙 이름만 보지 말고 실제 파일 위치를 확인하세요.

이 PC에서만 프록시 테스트: 일반적으로 로컬 네트워크에 리스너를 공개하거나 라우터에서 10808 포트를 포워딩할 필요가 없습니다. 웹 접속 문제를 해결하기 위해 ‘로컬 네트워크에서 연결 허용’을 켜지 마세요.
차단 기록이 확인됨: 신뢰할 수 있는 클라이언트와 현재 코어에만 필요한 허용 규칙을 추가하세요. 방화벽이나 보안 기능 전체를 계속 꺼 두지 마세요.
시스템 프록시는 정상이지만 TUN은 실패: 클라이언트 안내에 따라 필요한 관리자 권한을 부여하고 가상 네트워크 어댑터 및 라우팅 생성 로그를 확인하세요. 트래픽을 가로채는 다른 프로그램을 종료한 상태에서도 비교 테스트합니다.
회사 또는 학교 네트워크 사용 중: 먼저 네트워크 관리 규정을 따르세요. 같은 설정이 다른 네트워크에서 정상 작동한다면 네트워크 차이를 기록하고 관리자에게 외부 연결 정책을 확인하세요. PC 권한을 임의로 확대하지 마세요.

7. 자주 묻는 질문: 접속 복구 후 확인 사항

브라우저는 되는데 터미널에서는 왜 시간 초과가 발생하나요?

많은 명령줄 프로그램은 Windows 시스템 프록시 설정을 자동으로 사용하지 않습니다. 먼저 앞에서 안내한 curl.exe --proxy 명령으로 연결 주소를 명시하세요. 정상 작동을 확인한 뒤 해당 도구의 프록시 설정 방법에 맞게 구성합니다. 브라우저에서 접속된다는 이유만으로 터미널도 작동한다고 판단하지 마세요.

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

시스템 프록시가 이미 중지된 로컬 포트를 가리키는지 확인하세요. v2rayN을 다시 열고 ‘시스템 프록시’ → ‘시스템 프록시 지우기’를 선택하거나 Windows 프록시 설정에서 이번에 설정한 수동 프록시를 끈 다음 브라우저를 다시 열어 테스트할 수 있습니다.

실제 연결 지연 시간은 표시되는데 웹 페이지가 계속 로딩되나요?

속도 테스트 결과는 테스트 주소와 해당 시점의 요청만 반영합니다. 접속에 실패한 동일한 도메인으로 로그를 확인하고 내장 ‘전역’ 라우팅을 임시로 적용해 비교하세요. 해당 사이트만 실패한다면 사이트별 라우팅과 대상 서비스부터 확인하세요. 속도 테스트 수치만으로 모든 사이트에 접속할 수 있다고 볼 수는 없습니다.

끝까지 점검해도 해결되지 않으면 어떤 정보를 제공해야 하나요?

v2rayN 및 코어의 정확한 버전, Windows 버전, 프록시 모드, 로컬 포트, 문제 발생 시각 전후의 로그를 기록하세요. 정보를 공유하기 전에 구독 링크, 사용자 ID, 인증 정보, 사설 주소를 가리세요. 오류 원문, 발생 단계, 테스트 절차는 그대로 남겨도 됩니다.

문제가 해결되면 반대 순서로 정리하세요. 평소 사용하는 라우팅 규칙을 복원하고 임시 변경을 되돌린 다음 브라우저와 프록시가 필요한 앱에서 접속되는지 확인합니다. 클라이언트를 종료한 뒤 시스템 프록시가 제대로 해제되는지도 살펴보세요. 최종적으로 정상 작동한 포트, 서버, 규칙 이름을 기록해 두면 다음 업데이트 후 빠르게 비교할 수 있습니다.