V2Ray 연결은 됐지만 인터넷이 안 될 때: 프록시 포트·라우팅 모드·DNS 점검표

먼저 ‘연결됨’의 의미부터 확인하기

클라이언트 트레이 아이콘의 색이 바뀌거나 실행 로그에 시작 완료가 표시되는 것은 핵심 프로세스가 설정을 불러왔다는 뜻일 뿐입니다. 브라우저 트래픽이 프록시를 거쳤다는 의미도, 원격 노드가 정상적으로 전달을 완료했다는 의미도 아닙니다. 전체 경로에는 최소한 앱, 시스템 프록시 또는 VPN 인터페이스, 로컬 수신 포트, 라우팅 규칙, DNS, 아웃바운드 노드라는 여섯 단계가 있으며, 어느 하나라도 끊기면 ‘화면은 정상인데 웹페이지는 열리지 않는’ 현상이 나타납니다.

먼저 범위를 좁혀 보세요. 추가 프록시 도구를 모두 끄고 V2Ray 클라이언트 하나만 남긴 뒤, 정상 작동이 확인된 노드를 선택합니다. 같은 브라우저에서 일반 웹페이지와 프록시가 필요한 웹페이지를 각각 열어 보세요. 일반 웹페이지도 열리지 않으면 로컬 포트, 시스템 프록시, TUN을 우선 확인하고, 일반 웹페이지는 열리지만 특정 사이트만 실패하면 라우팅, DNS, 노드 프로토콜 매개변수와 원격 연결 가능성을 중점적으로 살펴봅니다.

1단계: 시스템 프록시와 로컬 수신 포트 확인

데스크톱에서 가장 흔한 문제는 핵심 프로세스는 실행 중이지만 시스템 프록시는 꺼져 있는 경우입니다. v2rayN의 로컬 포트는 브라우저나 앱의 요청을 받고, 시스템 프록시는 시스템 프록시를 지원하는 프로그램에 해당 포트로 요청을 보내도록 알려 줍니다. 두 설정은 실제로 수신 중인 동일한 값을 가리켜야 하며, 기본 포트라고 추측해서는 안 됩니다.

브라우저에 별도의 프록시 설정이 있다면 먼저 이전 포트를 계속 가리키고 있지 않은지 확인하세요. 예를 들어 클라이언트는 127.0.0.1:10818로 변경했는데 브라우저 확장 프로그램에는 여전히 127.0.0.1:10808이 입력되어 있으면 요청이 존재하지 않는 수신기로 전달됩니다. 기업용 네트워크 도구, 디버깅 프록시, 구버전 클라이언트가 같은 포트를 점유하고 있을 수도 있습니다.

1. 실행 상태 확인

   v2rayN 기본 창에서 현재 서버가 선택되어 있는지, 핵심 로그에 시작 완료가 표시되는지 확인합니다. 연속 재시작이나 즉시 종료가 발생해서도 안 됩니다.

2. 수신 대기 포트 확인

   「설정」→「매개변수 설정」→「기본 설정」을 열고 로컬 SOCKS 또는 혼합 프록시 포트를 기록합니다. 흔히 10808을 사용하지만 현재 화면에 표시된 값을 기준으로 해야 합니다.

3. 시스템 프록시 켜기

   기본 창의 「시스템 프록시」 메뉴에서 「시스템 프록시 자동 구성」을 선택한 다음, 시스템 설정의 프록시 서버가 127.0.0.1과 현재 포트를 가리키는지 확인합니다.

4. 포트 점유 문제 제외

   다른 프록시와 네트워크 디버깅 프로그램을 종료한 뒤 v2rayN을 다시 시작합니다. 로그에 바인딩 실패가 계속 표시되면 로컬 포트를 10818로 변경하고 다시 시작하세요.

5. 앱을 다시 열어 테스트

   브라우저를 완전히 종료한 뒤 다시 열어 기존 연결 풀이 직접 연결을 계속 재사용하지 않도록 합니다. 먼저 일반 웹페이지를 테스트하고, 그다음 프록시가 필요한 주소를 테스트하세요.

2단계: 검증 가능한 상태로 라우팅 모드 되돌리기

라우팅 규칙은 요청을 프록시로 보낼지, 직접 연결할지, 차단할지를 결정합니다. 오래된 규칙 세트, 잘못 입력한 사용자 지정 도메인, 뒤바뀐 규칙 우선순위 때문에 대상 웹사이트가 잘못된 아웃바운드로 전달될 수 있습니다. 문제를 확인하는 동안 여러 규칙 그룹을 동시에 수정하지 말고, 먼저 경계가 분명한 모드로 전환한 뒤 로그에서 대상 도메인이 최종적으로 어떤 규칙과 일치했는지 확인하세요.

v2rayN에서 「설정」→「라우팅 설정」으로 이동해 잠시 클라이언트가 제공하는 기본 규칙을 선택하고, 방금 추가한 사용자 지정 규칙은 비활성화합니다. ‘전역 프록시’에서는 접속되지만 ‘로컬 네트워크 및 일반적인 직접 연결 도메인 우회’에서는 접속되지 않는다면 노드와 포트는 대체로 정상이며, 문제는 분할 라우팅 규칙, 도메인 분류 또는 DNS 응답에 있을 가능성이 큽니다.

• 전역 프록시는 작동하지만 규칙 모드가 실패하는 경우: 대상 도메인이 잘못 직접 연결 아웃바운드로 분류되지 않았는지 확인하세요. 특히 사용자 지정 접미사 규칙과 정규 표현식을 점검해야 합니다.
• 전역 프록시도 실패하는 경우: 로컬 포트, 노드 프로토콜 매개변수, TLS 시간 설정과 원격 네트워크를 차례로 다시 확인하세요. 라우팅만 계속 바꾸지는 마세요.
• 로컬 네트워크 주소만 실패하는 경우: 사설 주소가 프록시로 전달되고 있지 않은지 확인하세요. 프린터, 라우터 관리 페이지와 공유 장치는 대개 직접 연결로 유지해야 합니다.
• 일부 서브도메인만 실패하는 경우: 웹페이지가 여러 API 도메인을 동시에 호출할 수 있습니다. 메인 도메인만 추가하지 말고 핵심 로그에서 실패한 실제 호스트 이름을 찾아야 합니다.

3단계: DNS 확인과 시스템 시간 점검

DNS 문제는 보통 세 가지 형태로 나타납니다. 도메인이 전혀 확인되지 않거나, 연결할 수 없는 주소로 확인되거나, DNS 요청이 잘못된 경로로 분배되는 경우입니다. 서버 주소를 직접 입력하면 연결되지만 도메인을 입력하면 실패한다면 원인을 DNS 범위로 좁힐 수 있습니다. 노드 서버 자체가 도메인을 사용하는 경우 DNS 실패로 인해 아웃바운드를 시작하기도 전에 핵심 프로세스가 종료될 수 있습니다.

먼저 시스템 날짜, 시간대와 자동 시간 동기화를 확인하세요. 시간 오차는 TLS 인증서 검증에 영향을 줄 뿐 아니라 구독에 포함된 유효한 설정도 핸드셰이크 실패처럼 보이게 할 수 있습니다. 그런 다음 시스템 DNS 캐시를 삭제하고, 브라우저에서 별도로 설정한 암호화 DNS는 잠시 끄세요. 테스트 요청이 동일한 확인 경로를 사용하도록 하는 것이 중요합니다.

1. 시스템 시간 동기화

   시스템 「설정」→「시간 및 언어」→「날짜 및 시간」을 열고 시간과 시간대 자동 설정을 활성화한 다음 즉시 한 번 동기화하세요.

2. 확인 로그 확인

   노드에 다시 연결하고 핵심 로그를 연 뒤 lookup, DNS, no such host 또는 timeout을 검색해 실패한 도메인을 기록하세요.

3. 캐시 삭제

   일반적인 문제 해결 절차에 따라 시스템 DNS 캐시를 갱신한 다음 브라우저를 종료하고 다시 열어 캐시에 남은 이전 주소를 계속 사용하지 않도록 합니다.

4. DNS 진입점 통일

   문제를 확인하는 동안 DNS 설정은 하나만 유지하세요. 클라이언트 DNS, 브라우저 자체 DNS, 다른 네트워크 도구의 DNS 가로채기를 동시에 활성화하지 마세요.

ipconfig /flushdns
nslookup example.com
netstat -ano | findstr 10808

첫 번째 명령은 Windows DNS 캐시를 삭제하고, 두 번째 명령은 현재 시스템 확인자가 주소를 반환할 수 있는지 검증하며, 세 번째 명령은 10808이 수신 대기 중인지 확인합니다. 실제 클라이언트 포트가 10808이 아니라면 「매개변수 설정」에 표시된 값으로 바꾸세요. 명령에 출력이 있다고 해서 경로가 반드시 정상인 것은 아니지만, ‘수신 대기 없음’과 ‘DNS 확인 실패’를 빠르게 구분할 수 있습니다.

4단계: TUN, VPN 인터페이스와 방화벽 충돌 배제

TUN 모드는 가상 네트워크 인터페이스를 만들어 시스템 프록시를 읽지 않는 프로그램도 전달 경로에 포함합니다. 적용 범위가 넓은 만큼 다른 VPN 인터페이스, 가상 머신 네트워크 어댑터, 기업 보안 소프트웨어 또는 방화벽 규칙과 충돌하기 쉽습니다. 시스템 프록시를 켜면 웹페이지를 볼 수 있지만 TUN을 켜는 순간 인터넷이 모두 끊기거나, 클라이언트를 종료한 뒤에도 비정상 라우팅이 남는 것이 대표적인 증상입니다.

점검할 때는 먼저 TUN을 끄고 일반 시스템 프록시만 유지하세요. 접속이 복구되면 노드 설정이 우선 원인은 아니라는 뜻입니다. 이후 가상 인터페이스가 정상적으로 생성됐는지, 기본 경로를 여러 프로그램이 중복으로 제어하고 있지 않은지, DNS가 이미 중지된 가상 인터페이스를 가리키고 있지 않은지 확인하세요. 기본 경로를 변경할 수 있는 네트워크 도구를 두 개 동시에 실행하지 마세요.

• 가상 네트워크 어댑터를 만들거나 기본 경로를 변경하는 다른 프로그램을 종료하고 현재 클라이언트만 남깁니다.
• v2rayN에서 TUN 모드를 끄고 「시스템 프록시 자동 구성」을 다시 활성화한 뒤 브라우저의 기본 접속을 확인하세요.
• 방화벽이 v2rayN 본체와 현재 핵심 프로세스의 사설 네트워크 및 공용 네트워크 접근을 허용하는지 확인하세요.
• 클라이언트를 방금 업그레이드했다면 시스템을 다시 시작해 이전 가상 인터페이스, 라우팅 테이블과 점유 프로세스를 완전히 해제하세요.
• TUN을 다시 활성화한 뒤 로그를 관찰해 인바운드 유형이 변경됐는지 확인하고, 실패가 DNS 전달 단계에서 발생하는지도 살펴보세요.

5단계: 안드로이드 VPN 권한과 앱별 라우팅 확인

v2rayNG은 Xray 코어를 사용하고 v2flyNG은 v2fly 코어를 사용합니다. 안드로이드에서는 두 앱 모두 보통 시스템 VPN 인터페이스를 통해 트래픽을 전달합니다. 상태 표시줄에 VPN 아이콘이 보인다는 것은 인터페이스 사용을 요청했다는 뜻일 뿐, 모든 앱이 올바르게 포함됐다는 의미는 아닙니다. 브라우저는 되지만 특정 앱만 안 되면 앱별 라우팅을 먼저 확인하고, 모든 앱이 안 되면 VPN 권한, 노드 매개변수, DNS와 배터리 백그라운드 제한을 점검하세요.

VMess, VLESS 등의 설정에서는 서버 주소, 포트, 사용자 식별자, 전송 방식, TLS와 경로 매개변수가 일치해야 합니다. 구독 업데이트 후 서버 매개변수가 바뀌었는데 이전 설정이 목록에 남아 선택 가능한 상태로 표시되면 핸드셰이크 단계에서 연결이 시간 초과될 수 있습니다. 이 경우 이전 노드를 복사해 계속 수정하지 말고 구독을 업데이트한 뒤 새로 갱신된 항목을 선택하세요.

1. VPN 인터페이스 다시 만들기

   현재 연결을 중지하고 상태 표시줄의 VPN 아이콘이 사라질 때까지 기다린 다음 연결을 다시 시작합니다. 시스템 권한 요청 대화상자에서 허용을 선택했는지도 확인하세요.

2. 앱별 라우팅 끄기

   클라이언트의 「설정」→「앱별 프록시」로 이동해 문제를 확인하는 동안 허용 목록 또는 차단 목록 규칙을 잠시 비활성화합니다. 브라우저와 테스트 앱이 동일한 경로를 사용하도록 해야 합니다.

3. 구독 업데이트

   구독 그룹에서 업데이트를 실행하고 새 노드의 개수와 이름이 갱신됐는지 확인한 뒤, 업데이트된 노드를 선택해 연결을 테스트하세요.

4. 노드 매개변수 확인

   서버 포트, 전송 방식, TLS, SNI, Host와 경로를 확인해 다른 노드의 매개변수가 현재 설정에 섞이지 않았는지 점검하세요.

5. 백그라운드 실행 허용

   시스템 앱 설정에서 클라이언트의 백그라운드 활동을 허용해 화면이 꺼진 뒤 배터리 정책으로 VPN 프로세스가 일시 중지되지 않도록 하세요.

10분 점검 순서: 한 번에 변수 하나만 변경

가장 빠른 방법은 노드를 계속 바꾸는 것이 아니라 노드는 그대로 두고 트래픽 경로를 가까운 단계부터 먼 단계 순서로 확인하는 것입니다. 각 단계를 마칠 때마다 다시 테스트하고 결과를 기록하세요. 접속이 복구되면 방금 수정한 유일한 변수가 원인인지 확인할 수 있습니다. 노드, 포트, DNS와 라우팅을 동시에 바꾸면 복구되더라도 실제 원인을 알 수 없어 다음에도 같은 작업을 반복하게 됩니다.

1. 1분 차: 다른 프록시 도구를 종료하고 클라이언트 인스턴스 하나만 실행 중인지 확인합니다.
2. 2분 차: 시스템 프록시 주소, 클라이언트 로컬 수신 포트와 브라우저 프록시 포트를 대조합니다.
3. 3~4분 차: 전역 프록시로 전환해 비교하고, 결과에 따라 라우팅 분할 문제인지 판단합니다.
4. 5~6분 차: 시스템 시간을 동기화하고 로그에서 DNS, lookup과 timeout 정보를 확인합니다.
5. 7~8분 차: TUN 또는 앱별 프록시를 끄고 가장 단순한 시스템 프록시 또는 VPN 경로로 테스트합니다.
6. 9분 차: 구독을 업데이트하고 VMess 또는 VLESS의 포트, 전송 방식, TLS, SNI와 경로를 확인합니다.
7. 10분 차: 클라이언트와 테스트 앱을 다시 시작하고 핵심 로그를 저장한 뒤 노드를 바꿀지 결정합니다.