v2rayN 문제 진단 및 장애 해결 총정리

1. 연결됨으로 표시되지만 인터넷이 되지 않을 때

먼저 문제가 발생한 계층을 확인하세요

“클라이언트 실행 중”이라는 표시는 로컬 코어 프로세스가 시작되었다는 뜻일 뿐, 원격 노드에 연결되었거나 브라우저가 해당 프록시를 사용하고 있다는 의미는 아닙니다. 전체 경로는 애플리케이션, 시스템 프록시 또는 VPN 인터페이스, 로컬 수신 포트, 라우팅 규칙, DNS, 원격 노드, 대상 웹사이트를 차례로 거칩니다. 첫 단계는 연결 버튼을 반복해서 누르는 것이 아니라 문제가 이 기기에서 끊겼는지 노드 이후에서 끊겼는지 판단하는 것입니다. 먼저 클라이언트의 시스템 프록시 또는 VPN을 끄고 일반 네트워크로 자주 이용하는 웹사이트가 열리는지 확인하세요. 직접 연결 자체가 되지 않는다면 Wi-Fi, 유선 연결, 게이트웨이 또는 통신사 연결부터 복구해야 합니다. 기본 네트워크가 정상화된 뒤 클라이언트를 다시 시작하세요.

그다음 v2rayN에서 설정이 완전한 것으로 확인된 노드를 하나 선택하고 라우팅을 잠시 전역 모드로 전환한 뒤 시스템 프록시를 활성화하세요. 전역 모드는 진단용으로만 사용하며, 복잡한 분할 규칙을 일시적으로 우회할 수 있습니다. 이때 접속이 복구되면 노드와 코어는 대체로 정상이고 문제는 라우팅 규칙, DNS 또는 우회 목록에 있습니다. 여전히 접속할 수 없다면 로컬 수신, 노드 연결성, 애플리케이션의 프록시 적용 범위를 계속 확인하세요. 진단이 끝나면 일상 사용에 적합한 라우팅 모드로 되돌려 임시 테스트 상태를 장기간 유지하지 않도록 합니다.

로컬 수신과 애플리케이션 프록시 확인

데스크톱 클라이언트는 보통 로컬 루프백 주소에서 HTTP, SOCKS 또는 혼합 프록시 포트를 제공합니다. 다른 프로그램이 포트를 점유하면 코어가 시작되지 않거나 시작 후 연결을 받지 못할 수 있습니다. v2rayN 로그를 열고 “address already in use”, “bind failed”, “failed to listen”처럼 의미가 분명한 오류를 찾으세요. 포트 충돌이 확인되면 해당 포트를 사용하는 프로그램을 종료하거나 v2rayN 설정에서 사용하지 않는 포트로 바꾼 뒤 코어를 다시 시작합니다. 브라우저 프록시만 바꾸고 클라이언트 수신 포트를 확인하지 않으면 안 됩니다. 양쪽 포트가 일치해야 합니다.

Windows에서는 PowerShell에서 포트가 수신 중인지 확인할 수 있습니다. 아래 예시의 포트는 클라이언트 화면에 표시된 실제 로컬 포트로 바꿔야 합니다.

Get-NetTCPConnection -State Listen |
  Where-Object LocalPort -In 10808,10809 |
  Select-Object LocalAddress,LocalPort,OwningProcess

Test-NetConnection 127.0.0.1 -Port 10809

포트가 정상적으로 수신 중인데 특정 애플리케이션만 인터넷에 연결되지 않는다면 해당 앱이 시스템 프록시를 따르는지 확인해야 합니다. 일부 프로그램은 자체 프록시 설정을 사용하고, 일부는 시작할 때만 시스템 프록시를 읽으며, 일부는 직접 연결을 수립합니다. 자체 프록시 옵션이 있는 앱에서는 127.0.0.1과 해당 HTTP 또는 SOCKS 포트를 직접 입력해 비교 테스트하세요. 직접 지정한 프록시는 작동하지만 시스템 프록시가 작동하지 않는다면 노드 문제가 아니므로 “시스템 프록시가 작동하지 않음” 장으로 이동합니다.

최소 설정으로 라우팅과 DNS 분리하기

복잡한 설정에서 자주 발생하는 단절 지점은 도메인 규칙이 직결로 먼저 매칭되는 경우, 대상 IP가 잘못 차단되는 경우, DNS 조회가 연결할 수 없는 출구로 나가는 경우, 구독을 병합한 뒤 유효하지 않은 아웃바운드 태그가 남는 경우입니다. 진단할 때는 사용자 지정 라우팅을 잠시 끄고 프록시 아웃바운드 하나와 직결 아웃바운드 하나만 남겨 보세요. 최소 설정이 작동한다면 규칙을 그룹별로 복원하고 그룹마다 같은 주소 목록을 테스트합니다. 여러 규칙 세트를 한 번에 가져온 뒤 어떤 규칙이 문제인지 추측하지 마세요.

로그는 아웃바운드 경로를 판단하는 핵심 근거입니다. 정상 요청에는 대상 도메인 또는 IP, 선택된 아웃바운드 태그, 연결 결과가 보이는 경우가 많습니다. 로그에 새 요청이 전혀 없다면 애플리케이션 트래픽이 클라이언트로 들어오지 않은 것입니다. 요청은 있지만 즉시 조회 실패가 발생하면 DNS를 확인하세요. 원격 노드 연결이 시간 초과되면 다음 장으로 이동하고, 일부 도메인만 실패한다면 분할 라우팅과 도메인 해석을 우선 확인합니다. “로컬 포트에 들어왔는가, 해석이 완료되었는가, 원격 연결이 수립되었는가”라는 세 가지 기준으로 막연한 인터넷 불가 문제를 실행 가능한 점검 항목으로 좁힐 수 있습니다.

시스템 시간도 확인해야 합니다. TLS 핸드셰이크는 올바른 날짜, 시간, 시간대에 의존하므로 기기 시간이 크게 어긋나면 인증서가 아직 유효하지 않거나 이미 만료되었다는 오류가 발생합니다. 운영체제의 자동 시간 동기화를 켠 뒤 클라이언트를 완전히 종료하고 다시 열어 테스트하세요. 기업 네트워크, 학교 네트워크 또는 공용 핫스팟은 먼저 포털 페이지에서 인증해야 할 수도 있습니다. 이 경우 프록시를 끄고 브라우저에서 네트워크 인증을 완료한 후 클라이언트를 다시 활성화하세요. 인증 페이지가 프록시에 막히면 모든 웹페이지가 열리지 않는 것처럼 보일 수 있습니다.

2. 노드 시간 초과, 연결 거부, 핸드셰이크 실패

세 가지 연결 오류를 구분하세요

노드 테스트의 “시간 초과”, “연결 거부”, “핸드셰이크 실패”는 서로 다른 단계의 문제를 뜻합니다. 시간 초과는 정해진 시간 안에 응답을 받지 못했다는 의미로, 서버에 도달할 수 없거나 포트가 필터링되었거나 회선에서 패킷 손실이 발생했거나 주소 해석이 잘못되었을 수 있습니다. 연결 거부는 대상 호스트에는 도달했지만 해당 포트에서 서비스가 수신 중이 아니라는 뜻이며, 포트 입력 오류나 서버 미실행에서 흔히 발생합니다. 핸드셰이크 실패는 TCP 연결은 수립되었지만 프로토콜 매개변수, TLS, 전송 방식 또는 인증 정보가 일치하지 않는다는 의미입니다. 먼저 단계를 구분해야 이후 조치가 무의미한 속도 테스트 반복에 머물지 않습니다.

클라이언트 목록의 단일 지연 시간 테스트에만 의존하지 마세요. 일부 테스트 방식은 TCP 연결만 확인해 프로토콜 핸드셰이크를 검사하지 못하고, 다른 방식은 특정 웹사이트를 요청하므로 결과가 DNS와 라우팅의 영향을 받습니다. 실행 로그를 함께 확인하고 데스크톱 시스템에서는 서버 주소와 포트의 기본 도달 가능성도 테스트하세요. Windows에서는 다음 명령을 사용할 수 있습니다.

Resolve-DnsName node.example.com
Test-NetConnection node.example.com -Port 443

여기서 node.example.com은 문서용 예시 주소이므로 실제로는 설정에 입력된 서버 도메인을 사용해야 합니다. 도메인을 해석할 수 없다면 먼저 DNS를 처리하세요. 해석 결과는 있지만 TCP 테스트가 실패하면 네트워크 경로, 포트, 서버 상태를 확인합니다. TCP는 성공하지만 클라이언트 핸드셰이크가 실패하면 UUID, 비밀번호, 프로토콜 유형, 전송 방식, TLS 활성화, SNI, Host, 경로, REALITY 매개변수를 중점적으로 확인하세요.

프로토콜 매개변수를 하나씩 대조하세요

VMess, VLESS, Trojan 등의 설정은 서버 주소와 포트만 비교해서는 안 됩니다. 프로토콜 필드는 전체적으로 일치해야 합니다. 예를 들어 VLESS에서는 사용자 식별자, 흐름 제어 방식, 보안 계층, 전송 유형, 서버 이름이 서로 연결되어 있습니다. REALITY 설정에는 해당 공개 키, 짧은 식별자, 서버 이름도 필요합니다. WebSocket 설정은 올바른 경로와 Host가 필요한 경우가 많고, gRPC는 서비스 이름이 일치해야 합니다. TLS 연결의 SNI는 서버 인증서와 진입점 설정에 맞아야 합니다. 구독 변환 도구가 필드 하나라도 잘라 내면 TCP 연결 성공 직후 핸드셰이크가 실패할 수 있습니다.

노드를 수동으로 편집할 때는 경험에 따라 값을 채우기보다 제공자가 전달한 완전한 원본 설정과 항목별로 대조하세요. 대소문자, 앞쪽 슬래시, 공백, 보이지 않는 문자도 차이를 만들 수 있습니다. UUID나 키를 복사한 뒤 일반 텍스트 편집기에 먼저 붙여 넣어 앞뒤 공백을 확인하고 클라이언트에 입력하세요. QR 코드와 공유 링크로 가져온 뒤에도 노드 상세 정보를 열어 다시 확인해야 합니다. 이전 형식은 최신 전송 필드를 포함하지 못할 수 있습니다. 같은 노드가 한 기기에서는 작동하고 다른 기기에서는 작동하지 않는다면 양쪽 프로토콜 상세 정보를 나란히 비교하는 편이 다시 가져오는 것보다 효과적입니다.

회선, 네트워크, 서버 측 문제 구분

같은 설정이 모바일 네트워크에서는 연결되고 가정용 인터넷에서는 시간 초과가 발생한다면 클라이언트 설정은 대체로 유효하므로 로컬 네트워크, 라우터, DNS 또는 상위 경로를 확인해야 합니다. 반대로 모든 네트워크 환경에서 같은 단계에서 실패한다면 서버 측 이상이나 매개변수 불일치 가능성이 더 높습니다. 휴대폰 핫스팟으로 데스크톱을 연결해 비교하거나 Android 기기에서 Wi-Fi와 모바일 데이터를 전환해 보세요. 테스트 중에는 노드, 클라이언트 라우팅 모드, DNS 설정을 유지하고 접속 네트워크만 바꿔야 합니다.

노드 주소가 도메인이라면 네트워크에 따라 해석된 IP가 달라지는지도 확인하세요. CDN, 듀얼 스택 해석, 로컬 DNS 캐시 때문에 두 기기가 서로 다른 주소에 연결할 수 있습니다. nslookup 또는 Resolve-DnsName으로 결과를 기록한 뒤 클라이언트 로그의 실제 대상 IP와 비교하세요. 도메인이 IPv4와 IPv6을 모두 반환하는데 현재 네트워크의 IPv6 경로가 불완전하면 연결이 오래 기다린 후에야 대체 경로로 전환될 수 있습니다. 이때는 일시적으로 IPv4를 우선해 확인할 수 있지만, 근거 없이 시스템 IPv6 기능을 영구적으로 끄면 안 됩니다.

로그에 인증서 이름 불일치, 알 수 없는 인증 기관, 핸드셰이크 프로토콜 불일치가 나타나더라도 “인증서 검증 건너뛰기”를 일반적인 해결책으로 사용하지 마세요. 먼저 기기 시간, SNI, 서버 이름, TLS 설정을 확인하세요. 검증을 잠시 끄는 것은 문제가 인증서 체인에 있는지 확인하는 용도로만 사용할 수 있으며, 확인 후에는 반드시 원래대로 복구하고 설정을 수정해야 합니다. 구독에서 가져온 노드는 완전한 설정을 다시 받아오는 것이 우선입니다. 여러 클라이언트에서 같은 핸드셰이크 오류가 동시에 발생한다면 클라이언트에서 무관한 옵션을 반복해서 바꾸기보다 설정 제공자가 서버 진입점을 확인해야 합니다.

노드 시간 초과는 로컬 보안 프로그램이 코어 프로세스를 차단하거나 새로운 아웃바운드 연결을 막아서도 발생할 수 있습니다. 모든 보호 기능을 바로 끄지 말고 차단 기록을 확인해 v2rayN이 사용하는 코어 프로그램이 현재 네트워크에 접근하도록 허용되어 있는지 확인하세요. 클라이언트 디렉터리를 옮겼거나 코어 파일 경로가 바뀌었다면 기존 규칙이 더 이상 일치하지 않을 수 있습니다. 현재 실제 경로에 다시 권한을 부여한 뒤 클라이언트를 재시작하세요. 점검이 끝나면 실제 웹페이지와 파일 전송으로 검증해야 하며, “지연 시간 사용 가능” 표시만으로 전체 경로가 정상이라고 판단할 수 없습니다.

3. 구독 업데이트 실패, 노드가 비어 있거나 내용이 바뀌지 않을 때

요청 실패인지 파싱 실패인지 먼저 판단하세요

구독 업데이트에는 다운로드와 파싱이라는 두 단계가 있습니다. 요청이 실패하면 클라이언트가 구독 본문을 가져오지 못하며 로그에 시간 초과, 이름 해석 실패, 연결 거부, 비정상 HTTP 상태가 나타나는 경우가 많습니다. 파싱이 실패하면 요청은 성공했지만 반환된 내용이 클라이언트가 지원하는 구독 형식이 아닐 수 있어 노드 수가 그대로이거나 노드 목록이 비어 있거나 형식 오류가 표시됩니다. 점검할 때는 목록 결과만 보지 말고 먼저 업데이트 로그를 읽으세요. 두 문제의 해결 방향은 완전히 다릅니다.

먼저 구독 주소가 완전한지 확인하세요. 주소의 쿼리 매개변수, 대소문자, 특수 문자는 인증 정보의 일부일 수 있으므로 복사할 때 끝부분 문자가 빠지면 작동하지 않습니다. 아래 주소는 구조를 설명하기 위한 예시일 뿐 실제 구독에 사용할 수 없습니다.

https://example.com/subscription?token=xxxx&client=v2rayN

주소를 메신저나 문서를 통해 옮기면 자동 줄바꿈이 들어가거나 문장 부호가 추가될 수 있습니다. 구독 그룹 설정에 다시 붙여 넣고 앞뒤에 공백이 없는지 확인하세요. 웹 관리 주소, 노드 공유 페이지, 로그인 페이지를 구독 주소로 사용하지 마세요. 브라우저에서 페이지가 열린다고 해서 반환 내용이 클라이언트 파싱에 적합한 것은 아닙니다. 반대로 브라우저에 긴 인코딩 문자열이 직접 표시되는 것은 정상적인 구독 응답일 수 있으며 내용이 손상되었다는 뜻은 아닙니다.

업데이트 요청이 프록시를 거칠지 결정하세요

구독 서버로 가는 경로와 노드 트래픽의 경로는 다를 수 있습니다. 클라이언트에서는 보통 구독 업데이트에 직결, 현재 프록시, 시스템 프록시 중 무엇을 사용할지 선택할 수 있습니다. 직결 요청이 시간 초과되지만 기존 노드는 연결된다면 구독 업데이트를 현재 프록시를 통해 실행하도록 바꿔 보세요. 반대로 프록시 노드 자체가 이미 만료되었다면 프록시를 통한 업데이트가 순환에 빠질 수 있으므로 직결로 바꾸거나 먼저 작동하는 노드를 가져와야 합니다. 판단 기준은 여러 옵션을 무작위로 전환하는 것이 아니라 로그에서 실제 요청이 어떤 출구를 사용했는지 확인하는 것입니다.

처음 설치했고 목록이 비어 있다면 구독 업데이트에 사용할 기존 프록시가 없습니다. 먼저 현재 기본 네트워크로 구독 주소에 접속할 수 있는지 확인하세요. 기존 노드가 있는 사용자는 실제로 작동하는 노드를 먼저 선택한 다음 업데이트를 실행할 수 있습니다. 업데이트가 끝나면 구독 그룹의 마지막 업데이트 시간, 노드 목록 변화, 오류 로그를 확인하세요. 수동 업데이트는 성공하지만 자동 업데이트가 실패한다면 자동 업데이트 간격, 기기 절전, 클라이언트 상주 여부, 업데이트 작업이 시작될 때 프록시 코어가 준비되었는지를 중점적으로 확인합니다.

업데이트 요청이 프록시를 거치지 않는 경우, 링크 만료, 시간 초과, 형식 오류에 대한 분기는 v2rayN 구독 업데이트 실패 원인 6가지와 자동 업데이트 설정 방법에서 계속 확인할 수 있습니다. 해당 글은 자동 업데이트 설정에 초점을 두고, 이 장에서는 로그를 기준으로 장애 단계를 구분합니다.

형식, 캐시, 그룹 덮어쓰기 처리

일반적인 구독 콘텐츠에는 base64로 인코딩된 공유 링크 모음, 줄바꿈으로 구분된 공유 링크, 기본 JSON 설정이 있습니다. 클라이언트와 코어마다 지원하는 필드 범위는 완전히 같지 않습니다. v2rayN 구독에는 여러 일반 노드 유형이 포함될 수 있지만 v2rayNG와 v2flyNG는 코어 기능과 가져오는 필드에서 차이가 있을 수 있습니다. 서버가 웹페이지 HTML, 로그인 안내, 오류 JSON, 빈 텍스트를 반환하면 클라이언트는 이를 노드 구독으로 파싱할 수 없습니다. 이 경우 실제 응답 유형과 계정 상태, 구독 진입점을 확인해야 합니다.

로그에서 다운로드와 파싱이 모두 성공했는데 목록이 바뀌지 않은 것처럼 보인다면 구독 그룹 필터, 별칭 덮어쓰기, 중복 제거 정책을 확인하세요. 현재 그룹만 표시하거나 키워드 필터, 메모 기준 중복 제거를 활성화하면 새 노드가 이미 가져와졌어도 화면에서 숨겨질 수 있습니다. 검색창을 먼저 비우고 전체 서버 목록으로 전환한 뒤 대상 그룹을 확인하세요. 기존 노드를 바로 모두 삭제하지 말고 현재 설정을 내보내거나 그룹을 복사한 다음 덮어쓰기 업데이트를 실행하세요. 그래야 구독 내용이 변하지 않은 것인지 클라이언트 병합 정책이 차이를 숨긴 것인지 구분할 수 있습니다.

구독 캐시 때문에 “업데이트 성공” 후에도 이전 내용이 표시될 수 있습니다. 클라이언트를 완전히 종료하고 다시 연 뒤 수동으로 업데이트하세요. 클라이언트에 구독 캐시 삭제 또는 캐시 사용 안 함 옵션이 있다면 백업 후 실행할 수 있습니다. 시스템 프록시가 현재 클라이언트를 가리키는 상태에서는 코어가 중지된 동안 브라우저로 구독 연결을 판단하지 않는 것이 좋습니다. 브라우저 요청이 이미 닫힌 로컬 포트로 향할 수 있기 때문입니다. 먼저 시스템 프록시를 끄고 직결 상태를 확인한 뒤 비교하세요.

자동 업데이트 간격을 너무 짧게 설정하지 마세요. 빈번한 요청은 노드 품질을 높이지 않으며 서버의 요청 제한에 걸리거나 네트워크 전환과 기기 절전 해제 시 작업이 겹칠 수 있습니다. 구독이 실제로 변경되는 주기에 맞춰 적절한 주기를 설정하고 필요할 때 수동으로 업데이트하세요. 업데이트 후 일부 새 프로토콜 노드만 작동하지 않는다면 노드 상세 정보에서 필드를 확인하고 선택한 클라이언트 코어가 해당 설정을 지원하는지 확인합니다. 형식 차이를 알아보려면 V2Ray 구독 형식과 변환 안내를 참고하세요.

4. 연결은 되지만 웹페이지와 다운로드가 느리거나 속도가 불안정할 때

지연 시간, 처리량, 안정성을 나누어 측정하세요

지연 시간이 짧다고 다운로드 속도가 빠른 것은 아닙니다. 지연 시간은 한 번 왕복하는 데 걸리는 시간을 나타내고, 처리량은 회선 용량, 혼잡, 패킷 손실, 서버 부하, TCP 동작에 좌우됩니다. 안정성은 연결이 지속되는 동안 흔들림이나 재전송이 얼마나 자주 발생하는지를 보여 줍니다. 클라이언트 노드 목록의 테스트 결과는 1차 선별 자료일 뿐 실제 접속을 대신할 수 없습니다. 속도 문제를 진단할 때는 같은 기기, 같은 접속 네트워크, 같은 시간대, 같은 대상을 고정하고 직결, 단일 노드, 다른 노드를 각각 비교해야 대상 웹사이트 자체의 부하를 클라이언트 문제로 오인하지 않습니다.

다른 다운로드, 클라우드 동기화, 시스템 업데이트, 동영상 재생을 먼저 중지한 뒤 일반 웹페이지의 최초 로딩, 연속 이미지 로딩, 합법적인 파일 하나의 다운로드를 테스트하세요. 같은 네트워크에서 모든 노드가 느리지만 휴대폰 핫스팟으로 바꾸면 회복된다면 로컬 인터넷 회선, Wi-Fi 간섭, 라우터 성능, 상위 경로를 우선 확인합니다. 특정 노드만 느리다면 대개 노드 회선 또는 부하 문제입니다. 브라우저는 빠르지만 특정 애플리케이션만 느리다면 해당 앱이 같은 프록시를 사용하는지, UDP를 사용하는지, 독립 DNS나 연결 동시성 제한이 있는지 확인하세요.

라우팅 때문에 트래픽이 우회하는지 확인하세요

분할 라우팅 규칙이 잘못되면 원래 직결이 적합한 트래픽이 원격 노드를 거치거나, 프록시가 필요한 요청이 먼저 직결을 시도한 뒤 시간 초과 후 전환될 수 있습니다. 두 경우 모두 페이지 최초 로딩 시간이 길어집니다. 로그에서 느린 요청이 최종적으로 어떤 아웃바운드 태그에 매칭되었는지 확인하고 도메인 규칙, IP 규칙, 기본 규칙의 순서를 특히 살펴보세요. 라우팅은 보통 위에서 아래로 또는 코어가 정한 우선순위에 따라 매칭되며, 범위가 지나치게 넓은 규칙 하나가 뒤의 세부 규칙을 가릴 수 있습니다. 수정하기 전에 기존 규칙 세트를 복사하고 적은 수의 도메인으로 검증하세요. 전체 설정을 바로 다시 작성하지 마세요.

분할 라우팅 구조를 이해하기 위한 간단한 규칙 예시는 다음과 같습니다. 이 조각은 geosite와 기본 아웃바운드의 관계를 보여 주며, 실제 태그 이름은 클라이언트에 현재 존재하는 아웃바운드와 일치해야 합니다.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

domainStrategy는 도메인 매칭과 해석의 관계를 결정합니다. AsIs를 사용하면 원래 도메인 규칙을 우선 처리해 불필요한 조기 해석을 피할 수 있습니다. IP 규칙으로 분할 라우팅해야 하는 경우 코어가 이후에 해석을 수행할 수 있습니다. 모든 네트워크에 적합한 단일 설정은 없으므로 규칙 구조에 맞춰 선택하세요. 수정 후에는 설정을 다시 불러오고 로그에서 새 규칙이 적용되었는지 확인해야 합니다.

MTU, UDP, 다중화를 점검하세요

웹페이지는 열리지만 큰 파일 전송이 멈추거나 동영상이 간헐적으로 버퍼링되거나 일부 요청이 오래 멈춘다면 경로 MTU와 관련이 있을 수 있습니다. VPN 인터페이스, 터널, 일부 접속 네트워크는 캡슐화 오버헤드를 늘립니다. 큰 패킷을 올바르게 조각화하지 못하면 작은 요청은 정상인데 대용량 전송만 문제가 생길 수 있습니다. 데스크톱에서는 먼저 시스템 프록시 모드와 가상 네트워크 어댑터 모드를 비교하세요. 시스템 프록시는 정상이고 가상 네트워크 어댑터 모드만 이상하다면 해당 모드의 MTU, 드라이버, 라우팅 테이블을 확인합니다. 경험만으로 MTU를 지나치게 낮추지 말고 단계적으로 조정하면서 대용량 파일 전송이 안정적인지 관찰하세요.

UDP는 DNS, 실시간 통신, 일부 최신 전송 방식에 중요하지만 노드와 네트워크마다 UDP 지원이 다를 수 있습니다. UDP를 활성화한 뒤 간헐적인 문제가 발생하면 먼저 애플리케이션 계층에서 정말 필요한지 확인하고 코어 로그에 UDP 시간 초과가 있는지 살펴보세요. 특정 앱의 UDP만 끄는 것과 전역에서 UDP를 비활성화하는 것은 다른 작업이며, 후자는 DNS와 다른 프로그램의 동작까지 바꿀 수 있습니다. QUIC을 사용하는 웹페이지는 UDP가 불안정할 때 브라우저가 대체 경로로 전환할 수 있어 최초 로딩이 느리고 이후에는 정상적으로 보일 수 있습니다.

다중화는 일부 환경에서 반복적인 연결 수립을 줄일 수 있지만 많이 설정한다고 항상 빨라지는 것은 아닙니다. 회선에서 패킷 손실이 뚜렷하면 너무 많은 요청이 하나의 연결을 공유하면서 서로 영향을 줄 수 있고, 서버가 같은 방식으로 설정되지 않았으면 핸드셰이크가 실패할 수도 있습니다. 속도 변동을 점검할 때는 동시성, 캐시, DNS, 전송 프로토콜을 동시에 바꾸지 말고 다중화를 잠시 끈 상태와 비교하세요. 끈 뒤 안정성이 높아진다면 노드 서버의 지원 능력에 따라 다시 활성화할지 결정합니다.

로컬 리소스와 무선 네트워크 확인

코어는 암호화, 복호화, 라우팅 매칭, 로그 기록을 수행해야 합니다. 오래된 기기, 절전 모드, 지나치게 상세한 로그는 처리량을 제한할 수 있습니다. 전송 중 CPU, 메모리, 디스크 사용량을 확인하세요. 특정 코어 하나의 부하가 계속 높다면 병목이 로컬 처리에 있을 수 있습니다. 리소스 사용량은 낮은데 네트워크 처리량이 주기적으로 0이 된다면 회선 패킷 손실, 무선 간섭, 서버 혼잡일 가능성이 더 큽니다. Android 기기는 절전 정책과 백그라운드 제한의 영향도 받으며 자세한 내용은 모바일 장치 장을 참고하세요.

Wi-Fi 신호 막대 수만으로는 연결 품질을 완전히 알 수 없습니다. 같은 주파수 간섭, 라우터 과열, 기기와의 거리, 자동 주파수 대역 전환이 흔들림을 만들 수 있습니다. 가능하다면 먼저 유선 네트워크로 테스트하세요. 무선만 사용할 수 있다면 라우터 가까이에서 다른 기기의 대용량 작업을 잠시 중지하세요. 매일 특정 시간대에 느려지고 클라이언트 설정은 변하지 않았다면 시간대, 접속 네트워크, 노드 차이를 기록하세요. 클라이언트를 반복해서 재설치할 필요는 없습니다. 안정성 문제는 한 번의 최고 속도보다 여러 번의 저간섭 비교 데이터가 중요합니다.

5. DNS 해석 실패, 도메인 오염 증상, 주소 불일치

도메인 문제인지 연결 문제인지 판단하세요

DNS 장애는 웹페이지에서 서버를 찾을 수 없다고 표시되거나, 로그에 해석 실패가 나타나거나, 같은 노드가 IP로는 연결되지만 도메인으로는 시간 초과가 발생하거나, 일부 도메인이 잘못된 주소로 열리는 형태로 나타납니다. 먼저 “해석 결과가 없는 경우”와 “사용할 수 없는 주소로 해석된 경우”를 구분하세요. 전자는 DNS 서버에 도달할 수 없거나 프록시 DNS 설정이 잘못되었거나 시스템 캐시가 비정상일 때 흔합니다. 후자는 캐시, 분할 라우팅 정책, IPv4와 IPv6 우선순위, DNS별 응답 차이에서 비롯될 수 있습니다. DNS 주소를 무작정 여러 개 바꾸는 것보다 현재 해석 결과를 먼저 기록해야 원인을 파악할 수 있습니다.

Windows에서는 다음 명령으로 시스템 해석 결과와 지정한 레코드 유형의 응답을 확인할 수 있습니다.

nslookup node.example.com
Resolve-DnsName node.example.com -Type A
Resolve-DnsName node.example.com -Type AAAA
ipconfig /displaydns

macOS와 Linux에서는 nslookup을 사용할 수 있고, 시스템 환경에 따라 dig도 사용할 수 있습니다. 클라이언트 로그의 대상 IP와 비교해 요청이 시스템 DNS, 클라이언트 내장 DNS, 원격 해석 중 무엇을 사용했는지 판단하세요. 명령줄 결과는 정상인데 클라이언트 로그에서 해석이 실패한다면 클라이언트 DNS 설정과 아웃바운드 태그를 중점적으로 확인합니다. 시스템과 클라이언트가 모두 실패한다면 네트워크에서 제공하는 DNS, 라우터 전달, 로컬 방화벽부터 확인하세요.

로컬 해석과 원격 해석 이해하기

시스템 프록시는 주로 애플리케이션의 HTTP 또는 SOCKS 트래픽을 전달하지만 애플리케이션이 실행한 DNS 조회까지 자동으로 프록시를 거친다고 보장할 수는 없습니다. 일부 브라우저는 자체 보안 DNS를 사용하고, 일부 프로그램은 시스템 해석을 직접 호출하며, SOCKS 클라이언트는 로컬에서 도메인을 해석한 뒤 IP만 프록시에 전달할 수도 있습니다. 따라서 같은 기기에서도 애플리케이션마다 서로 다른 주소를 받을 수 있습니다. 점검할 때는 애플리케이션이 프록시에 도메인을 전달하는지 이미 해석된 IP를 전달하는지 확인하고, 브라우저 내장 DNS 설정이 시스템 정책을 덮어쓰는지도 확인하세요.

가상 네트워크 어댑터 모드는 더 넓은 트래픽을 인계할 수 있지만 올바른 DNS 가로채기, 라우팅, 제외 규칙이 여전히 필요합니다. 활성화한 뒤 모든 도메인이 실패하고 IP 직접 접속에는 응답이 있다면 가상 인터페이스가 트래픽을 인계했지만 DNS 요청이 사용 가능한 해석기로 도달하지 못한 것입니다. 클라이언트가 생성한 DNS 인바운드, 가상 주소 범위, 라우팅 테이블을 확인하고 DNS 서버 자체가 잘못된 아웃바운드를 다시 거쳐 순환하지 않는지 확인하세요. 가상 네트워크 어댑터 관련 설정을 바꾼 뒤에는 코어를 중지하고 인터페이스가 해제될 때까지 기다린 다음 다시 시작해야 합니다.

원격 해석은 프록시 출구가 도메인 주소를 결정해야 하는 환경에 적합하고, 로컬 해석은 로컬 네트워크 기준으로 가까운 주소를 반환하는 서비스에 더 적합합니다. 둘 중 하나가 항상 우월한 것은 아닙니다. 라우팅 규칙이 먼저 도메인으로 출구를 결정한다면 원래 도메인 정보를 유지하는 편이 일반적입니다. 규칙이 IP 집합에 의존한다면 적절한 시점에 해석해야 합니다. 설정에 여러 DNS 서버가 함께 있다면 각 서버의 매칭 도메인, 조회 출구, 실패 시 대체 경로를 명확히 정해 조회가 직결과 프록시 사이를 순환하지 않도록 하세요.

캐시, IPv6, Fake DNS 처리

DNS를 바꾼 뒤에도 이전 레코드가 운영체제, 브라우저, 클라이언트 캐시에 남아 있을 수 있습니다. Windows에서는 ipconfig /flushdns를 실행해 시스템 캐시를 지운 다음 브라우저와 클라이언트를 완전히 종료하고 다시 테스트하세요. 캐시 삭제는 저장된 결과만 제거할 뿐 잘못된 라우팅이나 DNS 설정을 고치지는 않습니다. 기록이 곧바로 다시 잘못되면 실제 조회 경로를 계속 확인해야 합니다. 브라우저 자체 캐시와 보안 DNS도 별도로 점검해야 하며 시스템 명령만으로 판단해서는 안 됩니다.

듀얼 스택 네트워크에서는 도메인이 A와 AAAA 레코드를 동시에 반환할 수 있습니다. 시스템은 네트워크 상태와 주소 선택 정책에 따라 연결 순서를 결정합니다. 라우터가 IPv6을 알리지만 상위 연결이 불완전하면 애플리케이션이 IPv6 시간 초과를 먼저 기다린 뒤 IPv4로 전환해 페이지 최초 로딩이 느려질 수 있습니다. A와 AAAA를 각각 조회하고 로그에서 실제로 시도한 주소를 확인하세요. IPv4를 일시적으로 우선하는 것은 검증에 사용할 수 있지만, 최종적으로는 라우터 IPv6, 프록시 아웃바운드, 클라이언트 도메인 정책을 수정해야 하며 문제를 영구적으로 가려서는 안 됩니다.

Fake DNS는 애플리케이션에 예약 주소를 반환한 뒤 클라이언트가 원래 도메인을 복원해 라우팅하는 방식입니다. 가상 네트워크 어댑터가 인계하는 환경에 적합하지만 예약 주소 풀이 LAN, 회사 네트워크, 다른 VPN과 충돌하지 않아야 합니다. 활성화한 뒤 LAN 기기에 도달할 수 없거나 특정 앱이 비정상 주소를 감지하거나 재시작 후 기존 매핑이 사라진다면 주소 풀, 도메인 제외, 캐시 수명을 확인하세요. LAN 프린터, 라우터 관리 도메인, 내부 업무 도메인은 실제 네트워크에 맞춰 로컬 해석 또는 직결로 설정해야 하는 경우가 많습니다.

DNS를 수정한 뒤에는 노드 도메인, 일반 웹페이지 도메인, LAN 도메인을 함께 테스트하세요. 공개 웹사이트 하나만 테스트해서는 구독 업데이트, 노드 진입점, 로컬 기기 접속을 모두 확인할 수 없습니다. 특정 앱에서만 문제가 발생한다면 해당 앱이 별도 DNS를 활성화했는지 확인하세요. 같은 라우터에 연결된 여러 기기에서 동일한 문제가 발생하면 라우터의 DNS 전달과 IPv6을 우선 점검하고, 클라이언트를 켰을 때만 이상하다면 코어 DNS, 라우팅 아웃바운드, 가상 인터페이스 설정을 항목별로 확인하세요.

6. 시스템 프록시는 켜져 있지만 브라우저나 앱에서 작동하지 않을 때

운영체제의 프록시 값을 확인하세요

v2rayN의 “시스템 프록시” 스위치는 운영체제의 프록시 주소를 로컬 수신 포트로 지정합니다. 코어 실행과 시스템 프록시는 별개의 상태입니다. 코어가 실행 중이어도 시스템 프록시가 꺼져 있으면 명시적으로 프록시를 설정한 앱만 클라이언트를 거칩니다. 시스템 프록시가 기록되어 있어도 코어가 중지되면 앱은 서비스가 없는 로컬 포트에 연결합니다. 점검할 때는 코어 실행 상태, 로컬 포트 수신, 시스템 프록시 주소를 모두 확인해야 하며 하나라도 빠지면 안 됩니다.

Windows에서는 시스템 네트워크 프록시 설정에서 수동 프록시 주소와 포트를 확인할 수 있고 PowerShell로 현재 사용자 설정을 확인할 수도 있습니다. 중요한 것은 레지스트리 위치를 외우는 것이 아니라 화면에 표시된 포트와 v2rayN이 실제로 수신 중인 포트가 일치하는지 확인하는 것입니다. 설정을 전환한 뒤 포트가 바뀌면 기존 시스템 프록시가 이전 포트를 계속 가리킬 수 있습니다. 시스템 프록시를 끈 다음 클라이언트에서 다시 활성화하는 편이 여러 위치를 수동으로 수정하는 것보다 일반적으로 안전합니다.

macOS의 프록시 설정은 네트워크 서비스별로 저장되므로 Wi-Fi와 유선 네트워크에 서로 다른 설정이 있을 수 있습니다. 접속 방식을 바꾼 뒤 클라이언트가 이전 네트워크 서비스만 갱신했다면 새 연결은 프록시를 사용하지 않습니다. Linux 데스크톱 환경은 시스템 프록시 지원 방식이 서로 다릅니다. 일부 앱은 데스크톱 설정을 읽고, 일부는 환경 변수를 읽으며, 일부는 자체 네트워크 설정만 사용합니다. 따라서 “시스템 프록시 켜짐”이 모든 데스크톱 앱이 자동으로 따른다는 뜻은 아닙니다.

브라우저 캐시와 독립 프록시 설정 처리

브라우저는 보통 시스템 프록시를 읽지만 확장 프로그램, 기업 정책, 보안 DNS, 시작 매개변수가 시스템 설정을 덮어쓸 수 있습니다. 브라우저가 작동하지 않으면 추가 확장 프로그램을 로드하지 않는 임시 프로필을 새로 만들어 비교하거나 브라우저 네트워크 설정에 다른 프록시가 명시되어 있는지 확인하세요. 시스템 프록시를 수정한 뒤에는 브라우저를 완전히 종료하고 다시 열어야 합니다. 일부 프로그램은 시작할 때만 프록시를 읽기 때문입니다. 새 프로필에서 작동한다면 문제는 v2rayN 노드가 아니라 원래 브라우저 설정에 있습니다.

명령줄에서 로컬 프록시를 명시해 코어가 요청을 받는지 확인할 수 있습니다. 아래 포트는 예시이므로 클라이언트의 실제 HTTP 포트로 바꿔야 합니다.

curl.exe --proxy http://127.0.0.1:10809 https://example.com/
curl.exe --socks5-hostname 127.0.0.1:10808 https://example.com/

명시적 프록시는 성공하지만 브라우저가 실패한다면 노드, 코어, 로컬 수신은 정상이며 운영체제의 프록시 전달 경로를 계속 확인해야 합니다. 두 명령 모두 실패한다면 클라이언트 로그에 요청이 들어왔는지 확인하세요. 로그가 전혀 없다면 포트 또는 보안 프로그램 문제일 가능성이 높고, 요청은 있지만 연결이 실패한다면 노드, DNS, 라우팅 장으로 돌아가야 합니다. --socks5-hostname을 사용하면 도메인을 SOCKS 프록시 측에서 처리하므로 로컬 해석과 비교할 수 있습니다.

우회 목록과 PAC 동작 이해하기

시스템 프록시에는 보통 로컬 주소, LAN 대역, 특정 도메인을 우회하는 목록이 포함됩니다. 우회 규칙의 범위가 지나치게 넓으면 대상 요청이 직접 연결되어 프록시가 작동하지 않는 것처럼 보입니다. 와일드카드가 너무 넓거나, 도메인 접미사 표기가 잘못되었거나, 테스트 사이트가 직결 목록에 포함된 경우가 없는지 확인하세요. LAN 주소는 보통 프록시를 우회해야 하지만 구체적인 범위는 실제 네트워크에 맞춰야 합니다. 우회 항목을 모두 삭제하는 것은 장기적인 해결책이 아니며 라우터 관리 페이지, 프린터, 내부 서비스에 영향을 줄 수 있습니다.

PAC 모드는 스크립트로 각 요청을 프록시로 보낼지 직결할지 결정합니다. 브라우저가 PAC 파일을 캐시할 수 있고 스크립트 주소에 도달하지 못하면 직결로 대체될 수도 있습니다. 진단할 때 고정 시스템 프록시로 잠시 전환해 즉시 복구된다면 문제는 PAC 가져오기, 캐시, 매칭 규칙에 있습니다. 수정 후 PAC로 되돌리고 프록시 도메인, 직결 도메인, LAN 주소 세 종류의 요청을 검증하세요. 시스템 프록시, 전역 모드, 우회 규칙의 관계는 시스템 프록시·전역 모드·중국 본토 우회 모드의 차이 상세 설명에서 확인할 수 있습니다.

권한, 잔존 상태, 프록시 순환

클라이언트가 비정상 종료된 뒤 시스템 프록시가 남아 있을 수 있습니다. 다음 실행에서 다른 포트를 사용하면 브라우저는 계속 이전 주소에 연결합니다. “종료 후 인터넷이 안 됨” 문제가 발생하면 먼저 시스템 설정에서 수동 프록시를 끄고 자동 구성 스크립트가 여전히 활성화되어 있는지 확인하세요. 그다음 클라이언트를 시작해 코어가 정상인지 확인한 후 클라이언트가 설정을 다시 기록하게 합니다. 여러 프록시 클라이언트가 동시에 시스템 프록시를 관리하지 않도록 하세요. 서로 주소를 번갈아 덮어써 화면과 실제 상태가 달라질 수 있습니다.

프록시 순환은 클라이언트가 구독 업데이트, 네트워크 확인, 규칙 다운로드를 수행할 때 잘못해서 이미 만료된 자체 시스템 프록시를 다시 거치는 경우에 흔히 발생합니다. 로그에 로컬 포트로 반복 연결하거나, 요청 응답이 없거나, 코어를 중지한 뒤 모든 네트워크 작업이 실패하는 현상이 나타날 수 있습니다. 해결 방법은 내부 요청 유형별로 직결과 현재 프록시 중 무엇을 사용할지 명확히 정하고, 클라이언트 시작 전에 아직 만들어지지 않은 출구에 의존하지 않도록 하는 것입니다. 노드를 전환할 때도 새 코어가 수신을 완료할 때까지 기다린 후 프록시가 필요한 작업을 실행하세요.

일부 앱은 시스템 프록시를 지원하지 않거나 HTTP 트래픽만 프록시할 수 있습니다. 이런 프로그램은 자체 설정에 SOCKS 또는 HTTP 주소를 입력하거나, 적합한 데스크톱 환경에서 가상 네트워크 어댑터 모드를 사용해 트래픽을 인계해야 합니다. 가상 네트워크 어댑터 모드로 전환하기 전에 권한, DNS, 라우팅에 미치는 영향을 이해하세요. 이를 시스템 프록시 문제의 만능 스위치로 취급하면 안 됩니다. 특정 프로그램 하나만 이상하다면 해당 프로그램 문서의 프록시 지원 여부를 먼저 확인하고, 모든 프로그램이 이상할 때 시스템 계층과 클라이언트 계층을 점검하세요.

7. 클라이언트가 시작되지 않거나 코어가 종료되거나 자주 충돌할 때

인터페이스 프로세스와 코어 프로세스를 구분하세요

v2rayN은 그래픽 인터페이스로 설정을 관리하고 Xray 또는 V2Fly 코어를 호출해 트래픽을 처리합니다. 인터페이스는 열리지만 연결 직후 중지된다면 대개 코어 시작 실패입니다. 인터페이스 자체가 열리지 않거나 창이 바로 닫히거나 설정 페이지가 충돌한다면 실행 환경, 설정 파일, 권한, 인터페이스 관련 구성 요소를 확인해야 합니다. 두 문제는 로그 위치와 해결 경로가 다릅니다. 먼저 충돌이 “클라이언트 열기”, “코어 시작”, “구독 불러오기”, “전송 시작” 중 어느 단계에서 발생했는지 기록하세요.

인터페이스를 조작할 수 있다면 먼저 로그 디렉터리를 열고 이번 시작 전후의 오류 내용을 보관하세요. 코어의 일반적인 시작 오류에는 JSON 구문 오류, 존재하지 않는 아웃바운드 태그, 포트 충돌, 규칙 파일 읽기 실패, 지원되지 않는 설정 필드가 있습니다. 마지막 한 줄만 잘라 내지 마세요. 근본 원인은 앞쪽의 설정 파싱 단계에 있을 수 있습니다. 로그가 지나치게 상세하다면 수준을 잠시 warning 또는 info로 낮추고 한 번 재현해 정상 연결 기록이 핵심 오류를 가리지 않게 하세요.

생성된 설정이 완전한지 확인하세요

라우팅을 수동으로 추가하거나 이전 설정에서 마이그레이션한 뒤 쉼표, 따옴표, 괄호 오류로 인해 코어가 시작을 거부할 수 있습니다. 표준 JSON에서는 주석을 사용할 수 없고 배열의 마지막 항목 뒤에 불필요한 쉼표를 둘 수도 없습니다. 아래는 계층 구조를 이해하기 위한 완전한 최소 예시이며 기존 노드 설정을 그대로 대체하는 용도로 사용하면 안 됩니다.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    }
  ]
}

클라이언트에서 생성된 설정을 볼 수 있다면 로그가 지목한 필드 경로를 중점적으로 확인하세요. 사용자 지정 조각에서 클라이언트가 이미 생성한 최상위 객체를 다시 정의하지 말고 존재하지 않는 outboundTag를 참조하지도 마세요. 다른 클라이언트에서 설정을 복사할 때는 대상 코어가 같은 필드를 지원하는지 확인해야 합니다. Xray와 V2Fly는 공통 기반이 있지만 지원 기능에는 차이가 있습니다. 코어 차이는 Xray 코어와 V2Fly 코어 차이 비교에서 확인할 수 있습니다.

권한, 경로, 보안 프로그램 차단 처리

클라이언트 디렉터리에 쓰기 권한이 없으면 설정 저장, 코어 파일 업데이트, 로그 기록이 실패할 수 있습니다. 데스크톱에서는 현재 사용자가 정상적으로 읽고 쓸 수 있는 위치에 클라이언트를 두고, 임시 디렉터리나 자동 정리되는 위치는 피하세요. 관리자 권한으로 장기간 실행하지 마세요. 일반 권한에서 실패한다면 먼저 어떤 파일이나 작업이 거부되었는지 확인한 뒤 디렉터리 권한을 수정해야 합니다. 높은 권한으로 실행하면 설정 파일 소유자가 바뀌어 이후 일반 실행도 계속 실패할 수 있습니다.

보안 프로그램은 새로 다운로드한 코어 프로세스의 실행을 막거나 업데이트 후 새 파일을 승인되지 않은 프로그램으로 판단할 수 있습니다. 시스템 보안 기록과 격리 기록을 확인해 실제로 차단된 파일 경로를 확인하세요. 신뢰할 수 있는 현재 설치 디렉터리에만 필요한 실행 및 네트워크 권한을 부여하고 전체 보호 체계를 끄지는 마세요. v2rayN 인터페이스는 정상적으로 시작되지만 코어 파일이 즉시 사라진다면 먼저 격리 규칙을 처리한 뒤 Windows 다운로드 진입점에서 클라이언트를 다시 받으세요.

경로에 특수 문자가 포함되거나 동기화 드라이브의 자리 표시자 파일 또는 지나치게 긴 디렉터리 계층이 사용되면 외부 코어와 규칙 파일을 정상적으로 읽지 못할 수 있습니다. 클라이언트를 짧고 안정적이며 쓰기 가능한 사용자 디렉터리로 옮겨 비교하세요. 이동 전에는 프로그램을 종료하고, 이동 후 코어 경로를 다시 선택한 뒤 구독, 로그, 규칙 디렉터리가 여전히 이전 위치를 가리키는지 확인합니다. 프로그램 실행 중 디렉터리를 옮기면 인터페이스 저장 위치와 코어의 현재 작업 디렉터리가 달라질 수 있습니다.

전체 데이터를 잃지 않고 손상된 설정 복구

구독을 업데이트하거나 라우팅을 수정한 직후 인터페이스가 충돌한다면 먼저 전체 설정 디렉터리를 복사해 백업한 뒤 최근에 수정한 사용자 규칙, 인터페이스 상태 파일, 단일 구독 그룹을 차례로 다른 곳으로 옮겨 보세요. 복구는 최소 변경부터 시작해야 하며 설정을 바로 전부 삭제하면 안 됩니다. 다시 열 수 있게 되면 서버와 라우팅 설정을 항목별로 가져오고 매번 재시작해 확인하세요. 이렇게 하면 손상된 파일을 특정하면서 정상 데이터는 보존할 수 있습니다.

클라이언트의 잦은 충돌은 메모리 부족, 지나치게 큰 규칙 세트, 계속 증가하는 로그 때문에도 발생할 수 있습니다. 충돌 전 메모리, 디스크 공간, 로그 크기를 확인하세요. 중복 규칙이 많으면 시작 시 파싱 시간이 늘어나고 사용자 지정 도메인 목록에 비정상적으로 긴 한 줄이 있어도 부담이 될 수 있습니다. 중복 항목을 삭제하고 용도별로 규칙을 나누며 필요한 로그만 보관하세요. 대량 연결을 전송할 때만 충돌한다면 애플리케이션 동시성을 낮춰 비교하고 시스템에 리소스 제한으로 프로세스가 종료되었다는 기록이 있는지도 확인합니다.

복구가 끝나면 “인터페이스 시작, 코어 수신, 단일 노드 연결, 구독 업데이트, 사용자 지정 라우팅” 순서로 기능을 단계별로 다시 추가하세요. 각 단계가 정상적으로 작동한 뒤 다음으로 넘어가야 합니다. 특정 사용자 지정 조각에서만 오류가 발생한다면 이전 클라이언트가 내보낸 전체 설정을 계속 재사용하지 말고 현재 코어가 지원하는 필드에 맞춰 다시 작성하세요. 재설치가 필요하다면 다운로드 센터에서 현재 플랫폼의 패키지를 선택하고 이전 데이터를 가져오기 전에 빈 설정이 정상적으로 시작되는지 먼저 확인하세요.

8. Android에서 연결 끊김, 백그라운드 중단, 앱별 라우팅

VPN 권한과 시스템 충돌 확인

v2rayNG와 v2flyNG는 보통 Android의 VPN 인터페이스를 통해 앱 트래픽을 인계합니다. 처음 연결할 때 시스템에 VPN 권한 요청이 표시되며 권한이 없거나 철회되었거나 다른 VPN이 이미 사용 중이면 클라이언트가 인터페이스를 만들 수 없습니다. 상태 표시줄의 VPN 아이콘은 인터페이스가 존재한다는 뜻일 뿐입니다. 클라이언트 로그에서 코어가 시작되고 선택한 노드를 불러왔는지도 확인해야 합니다. 연결을 누르자마자 끊기면 다른 VPN이 실행 중이라는 시스템 안내가 있는지 먼저 확인하고, 업무 프로필, 기업 관리, 보안 앱이 VPN 권한을 제한하는지도 확인하세요.

Android에서는 일반적으로 한 번에 하나의 주요 VPN 서비스만 사용할 수 있습니다. 광고 차단기, 기업 VPN, 네트워크 가속 도구, 다른 프록시 클라이언트가 v2rayNG 또는 v2flyNG와 충돌할 수 있습니다. 점검할 때는 최근 앱 화면에서 UI만 닫지 말고 VPN 인터페이스를 점유한 다른 앱을 완전히 중지하세요. 시스템 설정의 “항상 켜진 VPN”과 “VPN을 사용하지 않는 연결 차단”도 클라이언트 전환에 영향을 줍니다. 항상 켜진 VPN이 다른 앱에 연결되어 있으면 새 클라이언트가 권한을 얻지 못할 수 있습니다.

클라이언트를 선택할 때 v2rayNG는 Xray 코어를 사용하고 v2flyNG는 V2Fly 코어를 기반으로 합니다. 일반적인 설정은 서로 겹치지만 일부 프로토콜과 전송 필드 지원에는 차이가 있습니다. 구독을 가져온 뒤 특정 노드만 연결되지 않는다면 해당 노드가 특정 코어 기능에 의존하는지 먼저 확인하세요. 같은 설정을 두 클라이언트 사이에서 조건 없이 복사하지 마세요. 패키지를 설치하거나 교체해야 한다면 Android 다운로드 진입점으로 이동하세요.

절전과 백그라운드 제한 처리

화면을 잠근 뒤 연결이 끊기거나 앱을 전환한 후 곧 작동하지 않는다면 배터리 최적화와 백그라운드 제한이 원인일 수 있습니다. 시스템이 클라이언트 프로세스를 일시 중지하거나 백그라운드 네트워크를 제한하거나 VPN 서비스를 회수할 수 있습니다. 앱 배터리 설정에서 백그라운드 활동을 허용하고 기기 시스템이 제공하는 옵션에 따라 클라이언트에 대한 강한 절전 제한을 해제하세요. 일부 기기에는 자동 시작, 백그라운드 팝업, 작업 잠금 설정도 있으므로 네트워크와 관계없는 권한까지 켤 필요는 없고 VPN 서비스가 계속 실행되도록 설정하면 됩니다.

절전 설정을 바꾼 뒤 클라이언트를 재시작하고 전체 테스트를 진행하세요. 화면을 켠 상태에서 한 번 접속하고, 몇 분간 화면을 잠근 뒤 다시 접속한 다음 Wi-Fi와 모바일 데이터를 전환합니다. 화면을 잠근 뒤에만 실패한다면 백그라운드 정책을 우선 확인하세요. 네트워크를 전환한 뒤 실패한다면 VPN 인터페이스가 다시 만들어지지 않았거나 이전 DNS 캐시가 갱신되지 않았거나 노드 연결이 재수립되지 않았을 수 있습니다. 로그에 네트워크 손실 후 새 기본 네트워크가 없다고 표시되면 클라이언트가 시스템 네트워크 변화를 제때 받지 못한 것입니다.

시스템 메모리가 부족하면 백그라운드 프로세스도 회수될 수 있습니다. 상주 앱, 게임, 브라우저 탭이 많을수록 가능성이 높아집니다. 중단 시 클라이언트 알림이 사라지는지 확인하세요. 알림이 사라지면 서비스 자체가 중지된 경우가 많고, 알림은 남아 있지만 접속되지 않으면 터널, DNS, 노드 연결이 끊겼을 가능성이 더 큽니다. 지속 알림을 켜면 시스템이 VPN 서비스를 전면 작업으로 인식하는 데 도움이 되고 서비스 중지와 경로 장애도 구분하기 쉽습니다.

앱별 라우팅과 우회 설정 확인

Android 클라이언트에서는 앱별로 VPN을 통과할지, VPN을 우회할지, 선택한 앱만 프록시할지 정할 수 있습니다. 목록 설정이 잘못되면 브라우저는 작동하지만 다른 앱은 직결되거나 일부 앱만 인터넷에 연결되지 않을 수 있습니다. 점검할 때는 먼저 앱별 라우팅을 잠시 끄고 모든 일반 앱을 VPN으로 보내 기본 연결이 정상인지 확인하세요. 그런 다음 화이트리스트나 블랙리스트를 복원하며 대상 앱을 하나씩 검증합니다. “선택한 앱만 프록시”와 그 반대의 우회 로직을 동시에 활성화하지 마세요.

시스템 구성 요소, 다운로드 관리자, 내장 웹페이지는 서로 다른 프로세스에서 요청을 실행할 수 있습니다. 앱 화면에서 시작한 다운로드가 해당 앱 패키지 이름으로 직접 실행된다고 보장할 수 없으므로 주 앱만 선택하면 로그인은 정상인데 다운로드가 실패할 수 있습니다. 이런 차이가 발생하면 클라이언트의 앱별 통계나 로그를 확인해 실제 트래픽이 VPN에 들어갔는지 확인하세요. LAN 기기에 의존하는 앱은 필요에 따라 로컬 네트워크 우회를 허용해야 화면 전송, 프린터, 라우터 관리 기능이 정상적으로 작동합니다.

앱별 프록시와 코어 라우팅은 서로 다른 계층입니다. 전자는 앱 트래픽이 VPN에 들어갈지 결정하고, 후자는 VPN에 들어온 트래픽이 프록시와 직결 중 어디로 갈지 결정합니다. 앱이 VPN에 아예 들어오지 않았다면 geosite나 IP 규칙을 수정해도 효과가 없습니다. 앱은 들어왔지만 대상 도메인이 잘못된 아웃바운드에 매칭된 경우에만 코어 라우팅을 조정해야 합니다. 로그에 해당 앱 요청이 전혀 없으면 앱별 라우팅을 먼저 확인하고, 요청은 있지만 출구가 맞지 않으면 라우팅 규칙을 확인하세요.

네트워크 전환, 비공개 DNS, 핫스팟 공유

Wi-Fi에서 모바일 데이터로 전환하면 로컬 주소, DNS, MTU가 모두 바뀔 수 있습니다. 클라이언트는 기본 네트워크에 다시 연결하고 터널을 복구해야 합니다. 전환 후 연결됨으로 표시되지만 웹페이지가 멈춘다면 노드를 삭제하지 말고 먼저 일시 중지한 뒤 다시 연결하세요. 자주 발생한다면 네트워크 변화 후 자동 재연결을 허용했는지 확인하고 시스템이 백그라운드 네트워크를 제한하지 않는지도 확인합니다. 듀얼 SIM 기기에서는 현재 데이터 SIM과 시스템 기본 네트워크가 일치하는지도 확인하세요.

Android의 비공개 DNS 설정은 클라이언트 내장 DNS와 동시에 작동하거나 충돌할 수 있습니다. 도메인은 실패하지만 IP는 연결될 때 현재 비공개 DNS 모드를 기록하고 잠시 시스템 자동으로 전환해 비교하세요. 자동 모드에서 복구된다면 비공개 DNS 호스트에 도달할 수 있는지와 클라이언트 DNS 라우팅을 계속 확인합니다. 변화가 없다면 문제는 VPN 내부의 해석 경로에 있을 가능성이 높습니다. 비공개 DNS를 끄는 것을 최종 결론으로 삼지 말고 테스트 후 실제 해석 구조에 맞는 설정을 선택하세요.

기기에서 핫스팟을 켰을 때 연결된 다른 기기의 트래픽이 휴대폰 VPN을 거치는지는 시스템 기능과 클라이언트의 전달 방식에 따라 달라집니다. 휴대폰 자체가 연결된다고 해서 추정할 수 없습니다. 휴대폰은 접속되지만 핫스팟에 연결한 컴퓨터가 접속되지 않는다면 먼저 하위 기기가 일반 네트워크에 연결되는지 확인하고, 클라이언트가 핫스팟 트래픽 전달을 명시적으로 지원하는지 확인하세요. 해당 전달 기능이 없다면 휴대폰 노드를 계속 조정하기보다 하위 기기에 데스크톱 클라이언트를 별도로 설치해야 합니다.

마지막으로 정해진 순서에 따라 검증하세요. 강한 절전 제한을 해제하고, 다른 VPN을 중지하고, 앱별 라우팅을 끄고, 작동이 확인된 노드를 선택한 뒤 기본 라우팅으로 웹페이지를 테스트합니다. 그다음 화면을 잠그고 네트워크를 전환하면서 앱별 라우팅을 하나씩 복원하세요. 기본 상태에서도 실패한다면 로그가 해석, 연결, 핸드셰이크 중 어느 문제인지 확인하고 앞의 해당 장으로 돌아갑니다. 기본 상태는 정상인데 특정 설정을 복원한 뒤 실패한다면 그 설정이 명확한 점검 대상입니다. 앱 데이터를 반복해서 삭제하는 것보다 단계적으로 복원하는 편이 구독과 라우팅 설정을 보존하기 쉽습니다.