프록시 연결됨, 인터넷 접속 불가: v2rayN 및 v2rayNG 단계별 점검 목록

먼저 ‘연결됨’이 어느 단계의 상태인지 확인하기

클라이언트에 실행 중이라고 표시된다고 해서 원격 노드와 실제 데이터 교환이 완료된 것은 아닙니다. v2rayN이 Xray 또는 V2Fly 코어를 실행한 뒤 확인되는 것은 로컬 프로세스가 실행 중이고 설정 파일이 기본적으로 해석되었다는 사실뿐입니다. v2rayNG 상단에 키 상태가 표시되거나 시스템에 VPN 연결이 나타나는 것도 Android의 트래픽 전달 서비스가 구축되었다는 뜻에 가깝습니다. 원격 주소가 해석되는지, 포트에 연결할 수 있는지, 프로토콜 매개변수가 일치하는지는 실제 연결 테스트로 확인해야 합니다.

웹 요청은 애플리케이션, 로컬 프록시 진입점, 라우팅 규칙, 프록시 아웃바운드, 원격 응답을 차례로 거칩니다. 어느 한 단계라도 실패하면 브라우저가 계속 로딩되거나 즉시 연결 재설정이 표시되거나 특정 사이트만 열리지 않을 수 있습니다. 따라서 클라이언트 트레이 아이콘의 색이 바뀌었다고 바로 DNS를 수정하지 말고, 노드 사용 가능성을 확인하기 전에는 라우팅 모드를 계속 바꾸지 마세요.

1단계: 노드 사용 가능성과 시스템 시간 확인

먼저 v2rayN 노드 목록에서 현재 노드를 선택하고 실제 연결 지연 테스트를 실행하세요. 일반 Ping은 대상 호스트가 ICMP에 응답하는지만 확인하므로 VMess, VLESS 또는 다른 프록시 연결이 핸드셰이크를 완료할 수 있는지는 보장하지 않습니다. 실제 연결 테스트는 현재 코어를 통해 아웃바운드 연결을 직접 수립하므로 첫 번째 필터로 더 적합합니다. 같은 구독의 여러 노드가 모두 시간 초과라면 먼저 구독을 업데이트한 뒤, 주소와 포트가 다른 노드 두 개를 골라 교차 테스트하세요.

테스트할 때 구체적인 수치를 기록해 두면 좋습니다. 예를 들어 노드 A의 실제 연결 지연이 186ms이고 세 번 연속 응답한 반면 노드 B는 세 번 모두 5000ms를 넘겨 시간 초과라면, 먼저 노드 A로 다음 단계를 점검해야 합니다. 지연 시간이 높다고 반드시 사용할 수 없는 것은 아니지만, 연속 시간 초과·연결 거부·즉시 핸드셰이크 실패는 대개 브라우저 설정을 바꾼다고 해결되지 않습니다.

1. v2rayN 메인 화면에서 노드를 선택하고 실제 연결 지연 테스트를 실행하세요. Ping 결과로 대신 판단하지 마세요.
2. 구독 노드를 최소 두 개 전환하고, 매번 테스트가 끝날 때까지 기다리세요. 너무 많은 연결을 동시에 시작하지 않는 것이 좋습니다.
3. 실행 로그를 열어 테스트 시 새 아웃바운드 기록이 실제로 생성되었는지 확인하세요. 이전 결과를 읽은 것이 아니어야 합니다.
4. v2rayNG에서 현재 설정의 테스트 기능을 누른 뒤 다른 노드로 바꿔 한 번 더 반복하세요.
5. Wi-Fi에서 모두 실패한다면 다른 사용 가능한 네트워크로 테스트해 노드 문제와 현재 네트워크 제한을 구분하세요.

시스템 시간 오차는 시간 검증이 필요한 연결에도 영향을 줍니다. Windows에서는 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’으로 이동해 시간 자동 설정을 켜고 즉시 동기화하세요. Android에서는 시스템 날짜 및 시간 설정에서 네트워크 제공 시간 사용을 활성화하세요. 기기 시간이 표준 시간과 몇 분 이상 차이 난다면 먼저 시간을 보정한 뒤 클라이언트 코어를 완전히 중지하고 다시 시작하세요.

2단계: DNS 해석 오류 위치 찾기

노드 테스트는 성공했지만 도메인을 입력한 뒤 웹페이지가 계속 대기한다면 DNS를 다음으로 확인해야 합니다. DNS는 도메인을 연결 가능한 주소로 변환하는 역할을 합니다. 프록시 아웃바운드가 정상이어도 로컬 DNS, 코어 DNS, 시스템 비공개 DNS의 조합이 현재 환경에 맞는다고 보장할 수는 없습니다. 특히 사용자 지정 설정을 가져왔거나 분기 규칙을 수정했거나 암호화 DNS를 활성화한 경우, 도메인 조회가 현재 네트워크에 적합하지 않은 경로로 전송될 수 있습니다.

v2rayN 7.x에서는 ‘설정’ → ‘매개변수 설정’에서 기본 설정과 DNS 관련 옵션을 확인할 수 있습니다. 사용자 지정 DNS 설정을 사용한다면 먼저 원본을 저장한 뒤 클라이언트 기본 설정으로 되돌려 비교하세요. 변경 후에는 코어를 재시작해야 하며, 브라우저 탭만 닫아서는 코어가 설정을 다시 불러오지 않습니다. Windows에서는 터미널에서 시스템에 내장된 조회 명령을 실행해 로컬에서 해석 결과를 얻는지도 확인할 수 있습니다.

nslookup example.com
ipconfig /flushdns

nslookup에서 주소가 반환되었다고 해서 시스템 조회 경로에 결과가 있다는 뜻일 뿐, 코어 내부에서도 같은 DNS를 사용한다는 의미는 아닙니다. 시스템 조회는 성공하지만 v2rayN 로그에서 계속 도메인 해석 실패가 발생한다면 코어 DNS 설정과 라우팅 규칙을 확인하세요. 시스템 조회 자체가 시간 초과라면 네트워크 어댑터 DNS를 자동으로 되돌리고 캐시를 비운 뒤 다시 테스트하세요.

3단계: 전역 프록시로 라우팅 규칙 오판 배제

라우팅 규칙은 요청을 프록시로 보낼지, 직접 연결할지, 차단할지를 결정합니다. 사용자 지정 규칙의 도메인, IP 대역, 포트, 인바운드 태그가 잘못 매칭되면 노드 자체는 정상인데 특정 사이트나 앱만 계속 접속할 수 없게 됩니다. 규칙은 보통 정해진 순서대로 매칭되므로, 범위가 지나치게 넓은 직접 연결 규칙이 이후의 프록시 규칙보다 먼저 요청을 가로챌 수 있습니다.

가장 직접적인 진단 방법은 규칙을 바로 삭제하는 것이 아니라 잠시 전역 프록시 모드로 바꾼 뒤 같은 도메인에 접속하는 것입니다. 전역 프록시에서는 열리지만 기존 라우팅 모드에서는 실패한다면 문제 범위를 분기 설정으로 좁힐 수 있습니다. 테스트가 끝나면 원래 모드로 되돌리고 사용자 지정 규칙의 매칭 대상과 아웃바운드 동작을 하나씩 확인하세요.

VMess와 VLESS는 노드 연결 프로토콜이고, 라우팅 규칙은 어떤 요청을 해당 노드로 보낼지 결정합니다. 둘은 같은 항목으로 취급할 수 없습니다. 잘못된 직접 연결 규칙은 프로토콜 매개변수를 바꿔도 해결되지 않으며, 반대로 잘못된 사용자 식별자·전송 계층 매개변수·서버 포트는 전역 프록시로 바꿔도 해결되지 않습니다.

4단계: v2rayN 시스템 프록시와 로컬 포트 확인

Windows, macOS, Linux 데스크톱 앱이 프록시 경로를 사용하는지는 시스템 프록시를 읽는지, 별도 프록시가 설정되어 있는지, 현재 TUN이 활성화되어 있는지에 따라 달라집니다. v2rayN 코어가 실행 중이면 보통 로컬에서 SOCKS 또는 HTTP 진입 포트를 수신합니다. 시스템 프록시가 실제 수신 포트를 가리키지 않으면 브라우저가 계속 직접 연결되거나, 이전 포트를 가리켜 페이지가 전혀 열리지 않을 수 있습니다.

v2rayN에서 먼저 ‘설정’ → ‘매개변수 설정’을 열고 로컬 SOCKS, HTTP 또는 혼합 진입 포트를 확인하세요. 일반적인 설정에서는 127.0.0.1:10808을 SOCKS 진입점으로 사용하고 127.0.0.1:10809를 HTTP 진입점으로 사용할 수 있지만, 실제 값은 현재 화면을 기준으로 해야 합니다. 그런 다음 트레이 메뉴에서 시스템 프록시 자동 설정을 선택하고 시스템 프록시 주소가 클라이언트의 현재 포트와 일치하는지 확인하세요.

• 로컬 주소는 먼저 127.0.0.1인지 확인하고, 원격 노드 주소를 시스템 프록시에 입력하지 마세요.
• 포트를 변경한 뒤에는 반드시 코어를 재시작하고 시스템 프록시 설정을 다시 적용해야 합니다.
• 브라우저에 수동 프록시가 설정되어 있다면 프로토콜 유형과 포트가 일치하는지 확인하거나, 잠시 시스템 프록시 사용으로 바꾸세요.
• 명령줄 프로그램이 데스크톱 시스템 프록시를 반드시 읽는 것은 아닙니다. 해당 프로그램이 지원하는 프록시 환경 변수나 설정 항목을 확인하세요.
• 다른 프로세스가 포트를 사용 중이면 코어가 시작되지 않거나 해당 인바운드를 생성하지 못할 수 있습니다.

5단계: v2rayNG VPN 트래픽 전달과 앱 범위 확인

v2rayNG는 Android에서 일반적으로 시스템 VPN 인터페이스를 통해 트래픽을 전달합니다. 상태 표시줄에 연결 표시가 나타난 뒤에도 시스템이 해당 서비스의 실행을 허용하는지, 앱별 프록시·LAN 우회·라우팅 모드·배터리 관리 설정이 올바른지 확인해야 합니다. 특정 앱 하나만 접속할 수 없고 브라우저는 정상이라면 문제는 대개 노드 자체가 아니라 앱별 선택이나 해당 앱의 네트워크 정책에 있습니다.

먼저 v2rayNG 설정에서 로컬 포트와 라우팅 옵션을 확인한 뒤 앱별 프록시가 활성화되어 있는지 점검하세요. ‘선택한 앱만 프록시’를 활성화했다면 대상 앱이 목록에 있어야 합니다. 반대로 제외 방식이 활성화되어 있다면 대상 앱이 제외 목록에 없어야 합니다. 변경 후 연결을 끊고 몇 초 기다렸다가 다시 연결해 시스템이 VPN 라우팅을 새로 설정하도록 하세요.

v2flyNG에서 V2Fly 코어를 사용할 때도 비슷한 Android 트래픽 전달 방식을 따르지만, 코어 지원 범위와 로그 내용은 다를 수 있습니다. v2rayNG 전용 Xray 설정을 v2flyNG에 그대로 적용하지 마세요. 구독에 특정 코어가 필요한 매개변수가 포함되어 있다면 노드 요구 사항에 맞는 클라이언트와 코어를 선택하세요.

마지막으로 정해진 순서대로 다시 테스트하고 로그를 확인하기

각 항목을 점검한 뒤에는 같은 조건으로 다시 테스트해야 합니다. 같은 네트워크, 같은 노드, 같은 도메인, 같은 브라우저를 사용하세요. 매번 테스트 대상을 바꾸면 페이지가 다시 열려도 실제 원인을 판단하기 어렵습니다. 마지막 빨간색 메시지만 캡처하지 말고 로그 창을 열어 둔 채 코어 시작 시점부터 확인하는 것이 좋습니다.

로그는 시간 순서대로 읽어야 합니다. 먼저 로컬 진입점이 요청을 받았는지 확인하고, 다음으로 어떤 아웃바운드가 선택되었는지 살펴본 뒤, 해석·연결·핸드셰이크·원격 응답 중 어느 단계에서 실패했는지 판단하세요. timeout 한 줄은 작업이 제한 시간을 넘겼다는 뜻일 뿐입니다. 앞뒤 줄에 표시된 대상 주소, 아웃바운드 태그, DNS 정보가 실제 처리 방향을 결정합니다.

1. 시스템 프록시를 끄거나 Android VPN 연결을 해제해 기기 자체의 기본 네트워크가 일반 페이지에 접속할 수 있는지 확인하세요.
2. 시스템 시간을 보정하고 구독을 업데이트한 뒤 실제 연결 테스트에 성공한 노드를 선택하세요.
3. 코어를 시작한 뒤 로그를 확인해 설정 해석 실패나 로컬 포트 충돌이 없는지 확인하세요.
4. 잠시 전역 프록시를 사용해 같은 도메인을 테스트하고 사용자 지정 라우팅 규칙을 배제하세요.
5. 기본 DNS로 되돌려 비교하고 코어를 재시작한 뒤 브라우저 또는 시스템 DNS 캐시를 비우세요.
6. 데스크톱에서 시스템 프록시를 다시 적용하고 127.0.0.1과 실제 수신 포트를 확인하세요.
7. Android에서 VPN을 다시 연결하고 앱별 범위, 비공개 DNS, 백그라운드 실행 권한을 확인하세요.
8. 정상 복구를 확인한 뒤 사용자 지정 설정을 하나씩 되돌리고, 각 항목을 복원할 때마다 다시 테스트하세요.