v2rayN 문제 해결
연결·구독 및 클라이언트 설정

1. 연결 후 인터넷이 안 될 때: 먼저 문제 발생 구간을 나누세요

직접 연결과 프록시 연결 결과 비교하기

‘인터넷이 안 된다’는 증상만으로는 원인을 단정할 수 없습니다. 클라이언트를 종료하고 시스템 프록시 설정을 원래대로 되돌린 다음, 평소 직접 접속할 수 있는 웹사이트를 열어 보세요. 이 상태에서도 접속되지 않는다면 Wi-Fi, 게이트웨이, 시스템 시간, 네트워크 로그인 페이지부터 확인하세요. 호텔·학교·공공 Wi-Fi는 웹 인증을 먼저 마쳐야 할 수 있습니다. 클라이언트가 실행 중이라는 표시만으로 기본 네트워크 연결이 확인되는 것은 아닙니다. 기본 연결이 복구되기 전에는 프로토콜을 계속 바꾸지 마세요.

직접 접속이 정상이라면 클라이언트를 실행하고 서버 목록에 실제로 사용할 수 있는 활성 서버가 있는지 확인하세요. 마우스로 선택된 항목만 있고 활성 서버가 없는 경우도 있습니다. 실행 로그에서 코어가 정상적으로 시작되고 로컬 인바운드가 리슨 중인지 확인하세요. 트레이 아이콘은 그래픽 프로그램이 실행 중임을 보여줄 뿐입니다. 코어 시작 실패, 포트 충돌 또는 설정 생성 오류가 있으면 브라우저는 서비스가 없는 로컬 주소에 연결하게 됩니다.

같은 테스트 웹사이트에 직접 연결했을 때와 프록시를 거쳤을 때의 결과를 각각 기록하세요. 한 번에 요청을 한 번만 보내고 시각도 적어 두면 로그에서 해당 기록을 찾기 쉽습니다. 브라우저에는 오류가 표시되지만 클라이언트 로그가 전혀 늘지 않는다면 앱의 프록시 적용이나 로컬 인바운드가 원인일 가능성이 큽니다. 아웃바운드 연결 오류가 기록되면 서버와 프로토콜을 확인하세요. 브라우저 캐시에 남은 이전 오류 페이지를 새 테스트 결과로 오인하지 마세요.

수동 프록시로 로컬 인바운드 확인하기

v2rayN의 매개변수 설정에서 HTTP 또는 혼합 인바운드에 지정된 실제 포트를 확인하세요. 아래 예시는 포트가 10808이라고 가정합니다. 설정이 다르면 그대로 실행하지 말고 숫자를 먼저 바꾸세요. Windows에서는 일부 명령 환경의 동명 별칭이 인수에 영향을 주지 않도록 curl.exe를 사용하세요. 이 테스트는 요청이 로컬 인바운드를 통과하는지 확인하기 위한 것이며, 모든 웹사이트 접속을 보장하지는 않습니다.

curl --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com

로컬 포트에 연결할 수 없다는 메시지가 나오면 원격 서버를 바로 수정하지 말고 코어 프로세스, 리슨 주소와 포트 종류부터 확인하세요. 로컬 연결은 성립했지만 핸드셰이크 실패나 원격 시간 초과가 발생하면 다음 장을 참고하세요. 웹사이트의 HTTP 응답을 받았다면 상태 코드가 성공이 아니더라도 애플리케이션 계층까지 응답이 도달한 것입니다. 응답 내용을 살펴 대상 사이트의 제한, 인증 문제 또는 프록시 경로의 다른 구간을 구분하세요.

수동 프록시 테스트는 성공하지만 브라우저가 실패한다면 브라우저의 별도 프록시 설정, 확장 프로그램과 시스템 프록시를 확인하세요. 시크릿 창에서도 모든 확장 프로그램이 꺼지거나 시스템 설정을 우회하는 것은 아닙니다. 별도 프록시 규칙이 없는 브라우저 프로필로 비교해 보세요. 특정 앱만 실패한다면 시스템 프록시를 따르는 앱인지도 확인해야 합니다. 브라우저가 작동한다고 해서 모든 프로그램이 같은 로컬 인바운드를 자동으로 사용한다고 볼 수는 없습니다.

최소 설정으로 되돌린 뒤 기능을 하나씩 다시 추가하기

사용자 지정 설정이 여러 개라면 먼저 백업한 다음, 정상 작동이 확인된 서버 하나와 단순한 라우팅 설정만 남기세요. 추가 프록시 체인, 복잡한 규칙 세트와 중복 실행 중인 네트워크 도구는 잠시 비활성화해 요청이 여러 로컬 인바운드 사이를 순환하지 않도록 합니다. 각 인바운드와 아웃바운드의 역할을 파악한 경우가 아니라면 테스트 중 시스템 프록시, 다른 트래픽 가로채기 도구와 브라우저 프록시 확장 프로그램을 동시에 켜지 마세요. 그러면 로그와 실제 연결 경로를 맞춰 보기 어렵습니다.

모든 웹사이트에서 문제가 발생하면 공통으로 사용하는 인바운드, DNS와 아웃바운드를 확인하세요. 특정 도메인만 실패한다면 라우팅 규칙, 대상 주소와 웹사이트 상태를 살펴보세요. 테스트 도메인만 프록시 아웃바운드로 임시 지정해 확인한 뒤 원래 규칙으로 되돌릴 수 있습니다. 임시 글로벌 프록시를 장기적인 해결책으로 남겨 두지 마세요. 잘못된 규칙을 우회한 것일 뿐, 원래 설정 문제는 해결되지 않았을 수 있습니다.

문제를 해결한 뒤 사용자 지정 라우팅, 브라우저 설정과 다른 네트워크 도구를 순서대로 복구하고, 항목을 하나씩 되돌릴 때마다 같은 대상으로 다시 테스트하세요. 마지막으로 클라이언트를 종료했다가 재실행해 설정이 유지되는지 확인합니다. 정상 작동하는 인바운드, 활성 서버와 프록시 모드를 기록해 두면 다음에 문제가 생겼을 때 기준 상태와 비교할 수 있습니다. 연결 설정이 확실하지 않다면 같은 설정을 여러 번 가져오기보다 빠른 시작 가이드를 다시 확인하세요.

2. 노드 연결 시간 초과: 전송 연결과 프로토콜 핸드셰이크 구분하기

시간 초과가 발생한 단계 확인하기

클라이언트 테스트에서 시간 초과가 발생하는 원인은 서버 도메인 조회 실패, 대상 포트 연결 실패, 전송 연결 후 프로토콜 핸드셰이크 미완료 등 다양합니다. 테스트 기능마다 대상과 방식이 다르므로 목록에 표시된 테스트 결과가 실제 접속 결과를 대신하지는 않습니다. 로그에서 가장 먼저 나타난 오류부터 확인하세요. 뒤이어 반복되는 오류는 같은 실패에 따른 재시도일 수 있으므로 각각 별개의 문제로 보지 마세요.

Windows에서는 아래 명령으로 포트를 테스트할 수 있습니다. 주소와 포트는 예시이므로 설정에 맞는 실제 값으로 바꾸세요. 테스트 성공은 해당 TCP 연결이 성립했다는 뜻일 뿐, VLESS·REALITY 또는 사용자 인증이 올바르다는 의미는 아닙니다. 테스트 실패도 서버가 특정 네트워크 경로에서만 연결을 허용하는지 함께 확인해야 합니다. 한 번의 결과만으로 클라이언트가 손상됐다고 단정하지 마세요.

Test-NetConnection -ComputerName your-server.example.com -Port 443

서버 전송 방식이 단순한 TCP 연결이 아니라면 이 테스트로 확인할 수 있는 범위는 더 좁습니다. UDP 기반 경로라면 로컬 네트워크와 서버 측에서 해당 트래픽을 허용하는지도 확인해야 합니다. 일반 웹페이지가 열린다고 해서 모든 전송 방식에 접근할 수 있는 것은 아닙니다. 프로토콜 매개변수를 여러 개 연달아 바꾸기보다 같은 대상으로 Wi-Fi와 모바일 네트워크를 비교하면 네트워크 환경에 따른 차이를 파악하기 쉽습니다.

VLESS 및 REALITY 매개변수를 항목별로 확인하기

전송 포트에 연결되지만 핸드셰이크에 실패한다면 서버 제공자가 전달한 원본 정보와 각 항목을 대조하세요. 서버 주소는 연결할 대상을 지정하고 서버 이름은 보안 핸드셰이크에 사용되므로 두 값이 같지 않을 수 있습니다. 서버 이름을 연결 주소로 임의 변경하지 말고, 주소에 특정 포트가 쓰였다는 이유만으로 전송 계층 보안을 끄지 마세요. 클라이언트와 서버는 동일한 프로토콜 조합을 사용해야 합니다.

XTLS Vision을 사용하는 경우 흐름 제어와 현재 전송 방식 및 보안 옵션이 서로 맞는지도 확인하세요. 유사한 설정이 작동한다는 이유로 다른 서버에 흐름 제어 값을 그대로 복사하지 마세요. REALITY의 공개 키, 짧은 ID와 서버 이름은 모두 서버에서 요구하는 값과 일치해야 합니다. 짧은 ID의 설정 방식은 서버마다 다를 수 있으며 비워도 되는지는 서버 설정에 따라 달라집니다. 특정 튜토리얼 화면만을 유일한 기준으로 삼지 마세요.

시스템 시간이 크게 어긋나면 보안 핸드셰이크에 영향을 줄 수 있습니다. 운영체제의 자동 시간 설정을 켜고 날짜와 시간이 실제 시각과 일치하는지 확인하세요. 오류 메시지에 인증서나 서버 신원이 언급되면 서버 이름, 인증서 설정과 시스템 신뢰 환경을 살펴보세요. 일반적인 해결책으로 신원 확인을 끄지 마세요. 핸드셰이크 오류를 숨기면 연결이 복구된 것처럼 보일 수 있지만 원래 설정 및 보안 문제는 남아 있습니다.

서버, 코어와 로컬 네트워크의 문제 범위 구분하기

같은 네트워크에서 서버 하나만 계속 시간 초과되고 정상 작동이 확인된 다른 서버는 연결된다면, 먼저 해당 서버의 주소, 서비스 상태와 계정 유효성을 확인하세요. 모든 서버에 동시에 문제가 생겼고 라우터 설정 변경이나 네트워크 전환 직후라면 공통 네트워크 경로부터 살펴보세요. 비교 테스트에는 동일한 매개변수를 사용해야 네트워크와 설정 중 어느 쪽이 원인인지 판단할 수 있습니다.

선택한 코어가 해당 설정에 필요한 기능을 지원하는지도 확인하세요. Xray와 V2Fly의 기능은 완전히 같지 않습니다. 공유 설정을 가져올 수 있다고 해서 코어에서 실행할 수 있다는 뜻은 아닙니다. REALITY와 설정 호환성에 대한 배경은 Xray와 V2Fly 코어 차이를 참고하세요. 로그에 기능 미지원이 명확히 표시된 경우에만 설정 요구사항에 맞춰 코어나 클라이언트를 변경하세요.

설정 제공자에게 문의할 때는 테스트 시각, 사용한 네트워크, 연결 대상, 오류가 발생한 단계와 민감 정보를 가린 첫 번째 오류 메시지를 정리하세요. ‘시간 초과’ 화면만 보내거나 구독 인증 정보를 공개하지 마세요. 같은 설정이 다른 네트워크에서 작동한다면 두 환경의 차이를 설명하세요. 모든 환경에서 실패한다면 서버 측 로그도 확인해야 합니다. 클라이언트만으로 원격 서버의 리슨 문제, 계정 비활성화나 서버 매개변수 불일치를 해결할 수는 없습니다.

3. 구독 실패: 가져오기·파싱·업데이트 단계 구분하기

주소가 올바른 내용을 반환하는지 확인하기

구독 업데이트는 주소에서 내용을 가져오고, 데이터를 파싱한 뒤, 서버 목록에 기록하는 세 단계로 진행됩니다. 업데이트 실패가 표시되면 구체적인 오류부터 확인하세요. 도메인 조회 실패, 연결 시간 초과, 인증 거부와 콘텐츠 파싱 오류는 해결 방법이 서로 다릅니다. 일부 서비스는 정상적인 웹 상태 코드를 반환하더라도 실제 내용은 로그인 페이지나 접근 안내일 수 있습니다. 유효한 구독 데이터가 아니므로 업데이트 버튼을 반복해서 눌러도 해결되지 않습니다.

신뢰할 수 있는 설정 관리 페이지에서 구독 주소 전체를 다시 복사하고 프로토콜 접두사, 경로와 쿼리 매개변수가 모두 있는지 확인하세요. 메신저에서 줄바꿈이 들어가거나 끝부분이 잘리고 앞뒤에 공백이 붙으면 주소가 달라질 수 있습니다. 구독 링크에는 접근 인증 정보가 포함되는 경우가 많으므로 비밀번호처럼 취급하세요. 공개 속도 테스트 사이트, 온라인 디코딩 도구나 문제 게시판에 붙여 넣지 말고, 주소 전체가 보이는 화면을 공유하지 마세요.

로그에 인증 거부 또는 리소스 없음이 표시되면 원래 설정 관리 페이지에서 구독이 유효한지, 계정에 권한이 있는지, 주소가 재설정됐는지 확인하세요. 서버 노드 연결과 구독 주소 업데이트는 별개의 문제입니다. 이미 저장된 서버 항목은 계속 사용할 수 있어도 구독 인증 정보는 변경됐을 수 있습니다. 반대로 구독 내용을 가져오는 데 성공해도 각 서버에 현재 연결할 수 있다는 뜻은 아닙니다.

업데이트 요청이 어떤 네트워크 경로를 사용하는지 확인하기

구독 업데이트는 직접 연결을 사용하거나 클라이언트 설정에 따라 기존 프록시를 거칠 수 있습니다. 관련 업데이트 옵션을 확인하고 시스템 프록시를 자동으로 따른다고 가정하지 마세요. 클라이언트를 새로 설치해 사용할 수 있는 서버가 없는데 구독은 프록시를 통해서만 가져올 수 있다면 설정이 필요한데 설정을 가져올 수 없는 의존 관계가 생깁니다. 이때는 같은 실패 경로를 반복해서 시도하지 말고 제공자가 허용하는 접근 가능한 주소나 신뢰할 수 있는 수동 설정 경로를 사용하세요.

사용 가능한 서버가 이미 있다면 해당 서버를 활성 상태로 유지하고, 직접 업데이트와 프록시를 통한 업데이트를 각각 테스트하세요. 업데이트 방식을 한 번에 하나만 바꾸세요. 한 가지 방식만 성공한다면 구독 주소에 접근하는 경로나 DNS 환경이 원인일 가능성이 큽니다. 시스템 프록시, DNS와 업데이트 방식을 동시에 바꾸지 마세요. 여러 변수를 한꺼번에 바꾸면 업데이트가 복구되더라도 실제 원인이 무엇인지 알기 어렵습니다.

웹페이지가 반환되거나 리디렉션 또는 보안 연결 오류가 발생하는 주소라면 시스템 시간, 네트워크 로그인 상태와 인증이 필요한 상위 네트워크를 거치는지 확인하세요. 구독을 가져오려고 보안 연결 검사를 장기간 완화하지 마세요. 로그인 페이지로 리디렉션되면 정상적인 서비스 관리 경로에서 인증 상태를 확인하세요. 로그인 페이지 내용을 설정 파일로 저장해 클라이언트에 가져오지 마세요.

형식 호환성, 중복 항목과 덮어쓰기 위험 확인하기

내용을 가져왔지만 파싱에 실패한다면 제공된 형식이 현재 클라이언트와 호환되는지 확인하세요. 공유 링크 모음, 인코딩된 구독 텍스트와 일부 전용 설정 파일은 서로 자유롭게 바꿔 쓸 수 없습니다. 파일 확장자만으로 형식을 판단하거나 인코딩을 임의로 추가·삭제해 문제를 해결하려 하지 마세요. 제공자가 해당 클라이언트용으로 명시한 형식을 우선 사용하고, 프로토콜 기능이 선택한 코어와 호환되는지 확인하세요.

업데이트 전에 구독 그룹과 직접 수정한 항목을 몇 개 백업하세요. 구독을 새로 고치면 그룹 내용이 다시 만들어질 수 있으며 수동으로 수정한 별칭, 주소나 전송 항목이 새 구독 내용으로 덮어써질 수 있습니다. 계속 유지할 수동 설정은 별도 그룹에 저장하고 구분하기 쉬운 이름을 지정하세요. 같은 주소를 가리키는 그룹을 여러 개 만들지 마세요. 서버 목록이 늘어난 것처럼 보여도 같은 항목이 중복되어 문제 해결 중 잘못된 항목을 선택할 수 있습니다.

업데이트 후 항목이 보이지 않으면 전체 목록을 다시 비우기 전에 그룹 필터, 이름 필터와 구독 응답 내용을 확인하세요. 목록이 비어 보이는 이유는 필터 조건일 수도 있고 주소가 빈 데이터를 반환했기 때문일 수도 있습니다. 기존 백업을 보존한 상태에서 별도의 테스트 그룹으로 확인하면 화면 표시 문제와 원격 콘텐츠 문제를 나눌 수 있습니다. 업데이트 성공 메시지는 클라이언트가 특정 작업을 마쳤다는 뜻일 뿐, 내용이 예상과 일치한다는 보장은 아닙니다.

마지막으로 업데이트된 항목 중 명확한 서버를 활성 서버로 선택하고 접속을 다시 테스트하세요. 일부 클라이언트는 기존 활성 항목을 새로 생성된 항목으로 자동 지정하지 않으므로 구독 업데이트에 성공해도 연결되지 않는다면 활성 서버 선택이 복구되지 않았을 수 있습니다. 구독과 서버 선택의 기본 관계는 자주 묻는 질문을 참고하세요. 로그가 프로토콜 핸드셰이크 단계까지 진행됐다면 노드 시간 초과 장으로 돌아가 계속 확인하세요.

4. 속도 저하와 간헐적 끊김: 같은 조건에서 비교하기

첫 접속 지연, 계속되는 저속, 특정 사이트만 느린 경우 구분하기

페이지를 처음 열 때만 느리고 이후 전송은 정상이라면 DNS 조회, 연결 수립이나 보안 핸드셰이크가 원인일 수 있습니다. 다운로드가 시작된 뒤에도 계속 느리다면 회선 처리량, 패킷 손실, 서버 부하나 로컬 기기 문제일 가능성이 큽니다. 동영상 재생이 간헐적으로 멈추는 현상은 대상 서비스의 캐시와 전송 정책 때문일 수도 있습니다. 재현 가능한 증상을 먼저 정리하세요. 모든 지연을 ‘노드 속도가 느리다’고 단정하면 서버를 바꾸는 것만으로 실제 문제를 가리게 됩니다.

비교할 때는 기기, 네트워크, 활성 서버, 테스트 대상과 대략적인 시간을 동일하게 유지하고 클라우드 동기화, 시스템 다운로드 및 대용량 작업을 잠시 멈추세요. 범용 속도 테스트만 보는 대신 실제로 이용하는 서비스를 우선 테스트하세요. 대상마다 연결 경로와 서비스 정책이 다를 수 있으므로 속도 테스트 결과가 좋더라도 파일 다운로드, 동영상이나 실시간 통신이 모두 원활하다고 볼 수는 없습니다.

비교하기 전에 테스트 요청이 같은 라우팅 규칙을 따르는지도 확인하세요. 규칙 업데이트, 주소 조회 결과나 앱 설정 변화로 같은 도메인이 서로 다른 출구를 사용할 수 있습니다. 연결 로그에서 대상이 최종적으로 선택한 아웃바운드를 확인하세요. 한 번은 직접 연결하고 다른 한 번은 프록시를 사용했다면 두 결과를 비교할 수 없습니다. 적은 횟수로 연속 테스트하면 충분합니다. 관찰 결과에 영향을 줄 수 있는 과도한 동시 요청은 피하세요.

로컬 네트워크·원격 경로·기기 자원 순으로 원인 좁히기

먼저 프록시를 거치지 않는 일반적인 서비스도 느려졌는지 확인하세요. 똑같이 느리다면 Wi-Fi 신호, 라우터 부하와 인터넷 회선의 업로드 대역폭이 포화됐는지 살펴보세요. 업로드 혼잡은 확인 패킷과 대화형 요청을 지연시킬 수 있습니다. 다운로드 대역폭에 여유가 있어 보여도 웹페이지 응답이 늦어질 수 있습니다. 가능하다면 유선 네트워크를 사용하거나 라우터 가까이에서 비교하되, 서버를 동시에 바꾸지 마세요. 그래야 개선이 어느 구간에서 비롯됐는지 알 수 있습니다.

프록시를 사용하는 트래픽만 느리다면 같은 서버로 여러 대상을 접속해 비교하고, 같은 대상을 여러 서버로 접속해 비교하세요. 첫 번째 비교는 대상 사이트와 출구의 처리 방식을, 두 번째 비교는 서버별 경로 차이를 살펴보는 데 도움이 됩니다. 네트워크 경로는 시간에 따라 바뀌므로 짧은 테스트는 현재 상태만 보여줍니다. 저녁 시간대 혼잡, 서버 측 속도 제한이나 원격 리소스 부족은 같은 조건으로 여러 차례 기록해야 판단할 수 있습니다. 한 번의 최고 속도만으로 결론 내리지 마세요.

시스템 작업 관리자나 리소스 모니터도 확인하세요. 클라이언트나 다른 프로세스가 CPU를 계속 많이 사용하거나 메모리가 부족해 페이지 교체가 잦다면 병목은 기기 자체에 있을 수 있습니다. 동시 연결이 너무 많거나 로그가 지나치게 상세하거나 속도 테스트를 자주 실행해도 부하가 커집니다. 불필요한 작업을 줄이고 일반 로그 수준을 유지하세요. CPU가 한 번 치솟았다는 이유만으로 보안 소프트웨어를 끄거나 시스템 네트워크 설정을 바꾸지 마세요.

전송·다중화·트래픽 가로채기 설정은 신중하게 조정하기

연결 다중화가 모든 프로토콜과 네트워크에서 속도 향상을 보장하지는 않습니다. 조합에 따라 앞선 응답을 기다리는 시간이 길어질 수 있으며 일부 기능은 코어나 프로토콜에 제한이 있습니다. 설정 제공자가 지원한다고 안내하고 변경 전후를 비교할 수 있을 때만 관련 옵션을 조정하세요. 인터넷에서 찾은 ‘속도 향상 설정’을 모든 서버에 통째로 복사하지 마세요. 잘못된 다중화, 흐름 제어 또는 전송 설정은 속도를 높이지 못할 뿐 아니라 정상 연결까지 불안정하게 만들 수 있습니다.

간단한 페이지는 열리지만 용량이 큰 페이지나 장시간 연결이 자주 멈춘다면 트래픽 가로채기 모드, 경로 MTU 또는 UDP 동작을 추가로 확인할 수 있습니다. 다만 MTU 확인은 후속 단계이지 첫 번째 조치는 아닙니다. 먼저 수동 프록시와 현재 트래픽 가로채기 방식의 결과를 비교하세요. 가로채기 방식에 따라 문제가 달라질 때만 네트워크 인터페이스와 관련 설정을 살펴보세요. 변경 전 원래 값을 기록하고 한 번에 하나씩 조정한 뒤 복구 여부를 확인하세요. 임의의 값 여러 개를 적용해 원인을 더 만들지 마세요.

특정 웹사이트 하나만 느리다면 브라우저 개발자 도구나 앱 메시지를 확인해 기본 문서, 이미지, 스크립트와 API 요청을 구분하세요. 페이지가 여러 도메인에 의존하는 경우 하나만 잘못 라우팅되거나 DNS 조회에 실패해도 페이지 전체가 멈춘 것처럼 보일 수 있습니다. 이때는 모든 트래픽을 장기간 같은 출구로 강제하지 말고 해당 규칙의 적용 범위를 바로잡으세요. 대상 서비스가 속도 제한이나 계정 제한을 반환한다면 클라이언트 설정으로 해결할 수 없습니다.

변경이 끝나면 첫 접속, 지속 전송, 유휴 상태 후 재연결을 모두 테스트해 한 가지 상황만 개선되고 다른 상황이 나빠지지 않았는지 확인하세요. 유효한 변경 사항과 되돌리는 방법을 기록하고 임시 속도 테스트 작업은 종료하세요. 안드로이드에서 주로 화면을 끈 뒤 느려진다면 모바일 장 관련 안내로 이동하세요. 백그라운드 제한과 회선 처리량 부족은 비슷하게 보일 수 있지만, 전자는 시스템의 앱 실행 정책을 확인해야 하며 연결 수를 무작정 늘리는 것으로 해결되지 않습니다.

5. DNS 문제: 실제 조회가 수행되는 위치 확인하기

시스템·브라우저·코어의 DNS 조회 구분하기

DNS 문제는 도메인이 열리지 않거나 간헐적으로만 성공하는 현상, 잘못된 주소로 연결되는 현상, 첫 요청이 오래 걸리는 현상으로 나타날 수 있습니다. 같은 기기에서도 시스템 리졸버, 브라우저 보안 DNS, 클라이언트 코어 DNS와 앱 자체 조회 기능을 동시에 사용할 수 있습니다. 이들은 서로 다른 DNS 서버를 사용하거나 다른 경로를 거칠 수 있습니다. 먼저 요청을 누가 조회하는지 파악한 뒤 해당 설정을 변경하세요. 시스템 DNS만 바꾸면 모든 앱이 이를 따를 것이라고 가정하지 마세요.

Windows에서는 아래 명령으로 시스템의 DNS 조회 결과를 확인할 수 있습니다. 이 결과는 시스템의 조회 경로만 보여주며 클라이언트 코어나 브라우저가 최종적으로 얻은 결과를 뜻하지 않습니다. 반환된 주소, 오류 유형과 조회 시각을 기록하고 클라이언트 로그와 대조하세요. IP 주소로 웹사이트를 여는 방법도 일반적인 확인 수단은 아닙니다. 많은 사이트가 호스트 이름, 보안 핸드셰이크와 가상 호스트에 의존하므로 IP 접속 실패만으로 네트워크가 끊겼다고 단정할 수 없습니다.

Resolve-DnsName example.com

시스템 DNS 조회는 정상이지만 브라우저에서 접속되지 않으면 브라우저에서 별도 보안 DNS를 사용하는지, 선택한 DNS 서비스에 연결할 수 있는지 확인하세요. 반대로 브라우저는 정상인데 특정 앱만 실패한다면 둘의 DNS 조회 경로가 다를 수 있습니다. 테스트할 때는 한 곳의 설정만 잠시 통일하고 원래 값을 기록하세요. 브라우저, 시스템과 코어의 DNS를 동시에 바꾸면 어떤 변경이 영향을 줬는지 알 수 없습니다.

DNS 조회 순환과 초기 연결 의존성 확인하기

원격 DNS 서비스 자체가 도메인을 사용하는 경우 해당 도메인을 먼저 조회해야 합니다. 모든 조회를 해당 서비스에 맡겼는데 그 서비스에 접속하려면 아직 연결되지 않은 프록시가 필요하다면 초기 연결 의존성이 생깁니다. 서버 주소가 도메인인데 DNS 요청도 해당 서버를 거쳐야 하는 경우에도 순환이 발생할 수 있습니다. 각 단계가 다음 단계의 성공에 의존하지 않도록 설정에 명확하게 접근 가능한 초기 조회 경로를 남겨 두세요.

아래는 DNS 주소와 조회 정책의 관계를 설명하는 코어 설정 일부입니다. 완성된 클라이언트 설정이 아니므로 그래픽 클라이언트가 자동 생성한 파일을 그대로 덮어쓰지 마세요. 실제 설정은 클라이언트에서 지원하는 옵션을 사용하고, 선택한 코어의 문서를 확인해 각 항목의 동작을 검증하세요. 이 예시는 일반 DNS 조회를 보여줍니다. 현재 네트워크와 개인정보 보호 요구사항에 적합한지는 별도로 판단해야 합니다.

{
  "dns": {
    "servers": [
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

DNS 서버에 접속할 수 있는지, 조회 트래픽이 어떤 경로를 사용하는지, 조회 결과로 연결을 어떻게 수립하는지는 서로 다른 문제입니다. DNS 서버가 응답하더라도 반환된 주소가 현재 아웃바운드에 적합하다는 뜻은 아닙니다. 직접 연결과 프록시를 구분해야 하는 환경에서는 도메인 규칙, 조회 정책과 아웃바운드 선택이 서로 맞아야 합니다. ‘조회가 더 빠르다’고 해서 대상 연결도 빨라지는 것은 아닙니다. 지역별 응답으로 선택된 주소가 이후 경로에 영향을 줄 수도 있습니다.

IPv6·캐시·규칙 적용 확인하기

IPv4와 IPv6를 함께 사용하는 네트워크에서는 도메인이 두 유형의 주소를 모두 반환할 수 있습니다. 로컬에서 IPv6 주소를 받았지만 실제 출구가 완전하게 구성되지 않았다면 앱이 도달할 수 없는 경로를 먼저 시도해 지연이 발생할 수 있습니다. 조회 정책이나 연결 방식을 바꾸기 전에 두 유형의 주소에 각각 연결할 수 있는지 확인하세요. IPv6 결과가 보인다는 이유만으로 시스템 전체에서 IPv6를 끄지 마세요. 특정 설정만 조정하면 되돌리기 쉽고 다른 기능에 미치는 영향도 줄일 수 있습니다.

DNS 설정을 바꾼 뒤에도 이전 결과가 운영체제, 브라우저와 코어의 캐시에 남아 있을 수 있습니다. 필요한 경우 Windows에서 ipconfig /flushdns를 실행해 시스템 캐시를 비울 수 있지만, 모든 앱의 자체 캐시까지 지워지지는 않습니다. 먼저 테스트 요청을 멈춘 다음 필요한 앱이나 코어를 재시작하고 다시 조회하세요. 설정을 확인하지 않은 채 캐시만 반복해서 지우면 증상만 바뀌고 실제 원인은 그대로 남습니다.

일부 도메인에서만 문제가 발생하면 hosts 파일, 클라이언트의 사용자 지정 도메인 매핑, 광고 차단이나 보안 소프트웨어가 결과를 변경하는지 확인하세요. 규칙의 도메인 일치와 IP 일치는 서로 다른 단계에서 적용될 수 있으며 조회 후 얻은 주소가 다른 규칙에 걸릴 수도 있습니다. 규칙 목록 순서만 보고 추측하지 말고 연결 로그에서 최종 아웃바운드를 확인하세요. 테스트 규칙을 추가해야 한다면 대상 도메인을 한정하고 삭제 조건을 기록하세요.

검증 결과에는 시스템 조회, 실제 앱 접속과 클라이언트 로그가 모두 포함되어야 합니다. DNS 조회 성공은 한 단계일 뿐이며 보안 핸드셰이크와 페이지 요청도 완료됐는지 확인해야 합니다. 설정 변경 후 브라우저만 정상화됐다면 다른 앱이 자체 DNS를 사용하는지 계속 확인하세요. 모든 도메인 조회가 정상이지만 연결이 시간 초과된다면 전송 및 핸드셰이크 장으로 돌아가세요. 문제를 나눠야 서버 포트 오류가 있을 때 DNS만 반복해서 바꾸는 일을 피할 수 있습니다.

6. 시스템 프록시가 작동하지 않을 때: 앱이 프록시를 사용하는지 확인하기

시스템 프록시와 기기 전체 트래픽의 차이 이해하기

시스템 프록시는 앱이 읽어 사용할 수 있도록 제공되는 네트워크 설정이지, 운영체제의 모든 트래픽을 클라이언트로 강제 전송하는 기능은 아닙니다. 브라우저는 보통 해당 설정을 따르지만 명령줄 도구, 게임, 백그라운드 서비스와 별도 네트워크 구성요소를 사용하는 앱은 무시할 수 있습니다. 시스템 프록시를 켰는데도 프로그램 하나가 직접 연결한다면 반드시 v2rayN 설정 실패라고 볼 수는 없습니다. 먼저 해당 앱이 지원하는 프록시 방식을 확인하고 적절한 연결 방법을 선택하세요.

먼저 v2rayN의 현재 시스템 프록시 상태가 프록시 해제나 기존 설정 유지로 되어 있지 않은지 확인하세요. 운영체제의 네트워크 프록시 설정에서도 주소, 포트와 자동 구성 스크립트를 확인합니다. 프록시 방식의 우선순위는 시스템과 앱에 따라 달라집니다. 수동 프록시와 자동 스크립트가 동시에 설정되어 있으면 잘못 판단하기 쉽습니다. 문제를 해결하는 동안 확실한 방식 하나만 사용하고 원래 값을 기록해 업무 네트워크에 필요한 설정을 잃지 않도록 하세요.

기기의 앱은 보통 루프백 주소를 사용해 로컬 인바운드에 연결합니다. 127.0.0.1은 현재 기기 자체를 가리킵니다. 휴대전화의 프록시 주소에 이 값을 입력하면 컴퓨터에 연결되지 않습니다. LAN 공유에는 호스트의 로컬 네트워크 주소와 올바른 인바운드 포트가 필요하며 접근 범위도 설정해야 합니다. 이는 기기 자체의 시스템 프록시와 다른 경로입니다. 로컬 브라우저 문제를 해결하려고 LAN 리슨을 무작정 개방하지 마세요.

프로토콜·포트·앱 자체 설정 확인하기

수동 프록시 테스트는 성공했지만 앱에서 적용되지 않는다면 먼저 앱에 ‘직접 연결’, ‘시스템 설정 사용’ 또는 별도의 프록시 옵션이 있는지 확인하세요. 어떤 도구는 환경 변수를 읽고 다른 도구는 시스템 설정을 읽습니다. 같은 터미널 창에서 실행해도 동일하게 동작한다고 보장할 수 없습니다. 프록시를 변경한 뒤에는 기존 연결을 닫거나 앱을 재시작하세요. 이미 수립된 장시간 연결은 새 출구로 즉시 전환되지 않을 수 있습니다.

포트는 인바운드 프로토콜과 일치해야 합니다. HTTP 프록시 주소를 SOCKS만 받는 포트에 임의로 지정하지 마세요. 혼합 인바운드가 두 종류의 요청을 모두 받는지는 현재 클라이언트 설정으로 확인해야 합니다. SOCKS를 통해 프록시 측에서 대상 도메인을 조회하려면 해당 문법을 지원하는 도구에서 socks5h를 사용할 수 있습니다. 이는 로컬에서 먼저 조회하는 방식과 다르므로 테스트할 때 차이를 확인하세요.

curl --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com

위 포트는 예시일 뿐이므로 먼저 SOCKS 요청을 실제로 받는지 확인하세요. HTTP 테스트는 성공하고 SOCKS 테스트는 실패한다고 해서 곧바로 서버 문제라고 판단하면 안 됩니다. 두 테스트가 서로 다른 로컬 인바운드 기능을 사용했을 수 있습니다. 앱의 프록시 우회 목록도 확인하세요. 로컬 주소, 특정 도메인이나 네트워크 대역이 제외되어 있다면 해당 요청은 원래 프록시를 거치지 않습니다.

여러 도구의 충돌과 남은 설정 확인하기

네트워크 도구를 여러 개 동시에 실행하면 시스템 프록시 설정을 서로 덮어쓸 수 있습니다. 설정 직후 값이 다시 바뀌거나 클라이언트 종료 후 다른 앱까지 인터넷에 연결되지 않는 현상이 나타날 수 있습니다. 먼저 프록시 관리 기능이 있는 다른 프로그램을 종료하고 시스템 설정이 유지되는지 확인하세요. 브라우저 확장 프로그램도 시스템 설정을 덮어쓸 수 있으므로 트레이 메뉴의 선택 항목만 보지 말고 시스템과 브라우저 설정을 각각 확인해야 합니다.

클라이언트가 비정상 종료되면 시스템 프록시가 로컬 포트를 가리킨 채 남아 있는데 해당 포트에는 더 이상 리슨 중인 프로세스가 없을 수 있습니다. 클라이언트를 다시 실행해 시스템 프록시를 정상적으로 해제하거나 운영체제의 네트워크 설정에서 사용할 수 없는 수동 프록시를 삭제하세요. 라우터를 반복해서 재시작할 필요는 없습니다. 요청이 로컬 기기를 떠나기도 전에 이미 실패한 것입니다. 직접 접속을 복구한 뒤 클라이언트가 비정상 종료된 원인도 확인해 재발을 방지하세요.

LAN 공유를 설정한다면 필요한 네트워크 범위만 허용하고 방화벽에서 해당 포트와 네트워크 프로필을 제한하세요. 편의를 위해 방화벽 전체를 끄거나 로컬 프록시 인바운드를 공용 인터넷에 노출하지 마세요. 공유 설정 절차는 v2rayN LAN 연결 허용 안내를 참고하세요. 호스트가 다른 네트워크로 이동하면 LAN 주소가 바뀔 수 있으므로 다른 기기의 설정도 함께 확인해야 합니다.

최종 확인에는 프록시 켜기, 앱 재연결, 프록시 끄기와 클라이언트 종료의 네 단계가 포함되어야 합니다. 프록시를 켠 뒤 로그에서 요청이 올바른 아웃바운드에 들어가는지 확인하고, 끈 뒤 직접 접속이 복구되는지, 종료 후 사용할 수 없는 인바운드가 시스템에 남지 않는지 살펴보세요. 시스템 프록시를 지원하지 않는 앱만 계속 연결되지 않는다면 앱이 지원하는 방식에 맞춰 별도 프록시나 적절한 트래픽 가로채기 방식을 사용하세요. 같은 시스템 프록시 주소를 계속 다시 설정하지 마세요.

7. 클라이언트 충돌과 코어 종료: 가장 먼저 발생한 오류 보존하기

그래픽 인터페이스 종료와 코어 시작 실패 구분하기

창이 사라지는 현상, 트레이 아이콘이 남는 현상, 서버 연결 실패와 코어의 반복 재시작은 서로 다른 계층의 문제입니다. 그래픽 프로그램이 종료된 것인지 코어 하위 프로세스가 멈춘 것인지 먼저 확인하세요. 인터페이스는 정상인데 로그에 설정 오류가 표시된다면 생성된 설정과 기능 호환성을 확인해야 합니다. 프로그램 자체가 열리지 않으면 설치 파일의 아키텍처, 시스템 요구사항, 실행 종속성 및 파일 접근 권한을 확인하세요. 처음부터 설정 디렉터리 전체를 삭제하지 마세요.

실행하자마자 종료되는지, 구독 업데이트 뒤 종료되는지, 코어를 바꾼 뒤 실패하는지, 특정 설정 페이지를 열 때 충돌하는지 등 문제를 유발한 동작을 기록하세요. 그런 다음 클라이언트 로그와 운영체제 이벤트 기록에서 해당 시각 전후를 확인합니다. 최초로 발생한 오류와 그 직전·직후의 내용을 보존하세요. 이후 연결 실패는 프로그램이 이미 중단된 결과일 수 있습니다. 로그가 너무 많다면 먼저 사본을 만든 뒤 정리하고 문제를 다시 재현해 유효한 정보가 덮어써지지 않도록 하세요.

진단 자료를 공유하기 전에 경로, 사용자 이름, 구독 인증 정보와 전체 설정이 포함되어 있는지 확인하세요. 사용자 디렉터리 전체를 공개하거나 서버 인증 정보가 들어 있는 충돌 첨부 파일을 업로드하지 마세요. 대개 클라이언트 이름, 시스템 아키텍처, 재현 단계와 민감 정보를 가린 오류만으로도 조사를 시작할 수 있습니다. 추가 자료가 필요하다면 수집 범위를 명확히 하고 신뢰할 수 있는 경로로 전달하세요. 로컬 파일을 전부 그대로 공개하지 마세요.

설치 환경·권한·포트 사용 여부 확인하기

시스템과 프로세서 아키텍처에 맞는 설치 파일을 클라이언트 다운로드 페이지에서 선택하세요. Windows 데스크톱 버전과 클래식 WPF 버전은 인터페이스 기술과 실행 조건이 다릅니다. 전환하기 전에 설정을 백업하고 서로 다른 설치 파일을 한 디렉터리에 섞어 덮어쓰지 마세요. 두 버전의 선택 방법은 Avalonia 데스크톱 버전과 WPF 버전 비교를 참고하세요. 인터페이스 문제를 해결하려고 출처를 알 수 없는 실행 구성요소를 임의로 복사하지 마세요.

휴대용 디렉터리는 현재 사용자에게 정상적인 읽기·쓰기 권한이 있는 위치에 두세요. 권한이 제한된 경로, 읽기 전용 매체나 동기화가 자주 발생하는 폴더는 피하는 것이 좋습니다. 로그에 권한 거부가 표시되면 장기간 관리자 권한으로 실행해 문제를 가리지 말고 구체적인 경로와 권한을 확인하세요. 보안 소프트웨어가 차단했다면 차단 기록과 출처를 확인한 뒤 시스템에서 제공하는 절차에 따라 처리하세요. 모든 보호 기능을 끄는 것을 표준 설치 절차로 삼지 마세요.

코어에서 포트가 사용 중이라고 표시되면 다른 클라이언트 인스턴스가 계속 실행 중이거나 다른 서비스가 같은 포트를 사용하고 있을 수 있습니다. 트레이와 프로세스 목록을 확인해 중복 인스턴스를 종료한 뒤 리슨 상태를 다시 확인하세요. 포트를 바꿔야 한다면 시스템 프록시와 앱의 별도 프록시 주소도 함께 수정해야 합니다. 클라이언트 한 곳만 바꾸면 포트 충돌이 앱의 로컬 인바운드 연결 실패로 바뀔 뿐입니다. 증상은 여전히 네트워크 오류처럼 보일 수 있습니다.

별도 설정으로 손상 및 호환성 문제 구분하기

설정 변경 직후 시작 오류가 발생했다면 해당 변경부터 취소하세요. 인터페이스를 열 수 없다면 설정 위치를 확인하고 백업한 뒤 별도의 테스트 디렉터리나 새 사용자 설정으로 검증할 수 있습니다. 원래 디렉터리를 바로 삭제하지 마세요. 구독 그룹, 수동 서버와 라우팅 규칙이 들어 있을 수 있습니다. 테스트 환경에는 정상 작동이 확인된 설정 하나만 두면 프로그램 환경과 기존 설정 손상을 구분하는 데 도움이 됩니다.

새 환경에서는 정상이고 기존 환경에서만 실패한다면 서버, 구독과 라우팅 설정을 하나씩 옮기고 매번 재시작해 확인하세요. 규칙을 가져온 뒤 오류가 시작되면 규칙 파일 경로, 필드 형식과 코어 지원 여부를 확인하세요. 그래픽 클라이언트에 항목을 저장할 수 있다고 해서 최종 생성된 코어 설정이 유효하다는 뜻은 아닙니다. 시작 로그의 필드 오류와 실제 적용 결과를 기준으로 판단하세요.

최소 설정을 사용해도 깨끗한 환경에서 프로그램이 종료된다면 시스템 자원, 디스크 공간, 실행 종속성과 소프트웨어 충돌을 확인하세요. 업데이트하거나 재설치할 때는 원본을 백업하고 테스트 중 기존 설정 전체를 한꺼번에 복구하지 마세요. 특정 기능의 호환성 문제가 명확히 확인된 경우에만 대체 기능을 선택하세요. 재설치 후 일시적으로 정상화됐다고 해서 기존 문제의 재현 조건을 무시하지 마세요.

문제를 해결한 뒤 프로그램을 완전히 종료하고 다시 시작해 코어가 한 번만 실행되는지, 로컬 인바운드가 정상인지, 종료 시 시스템 프록시가 복구되는지 확인하세요. 구독 업데이트와 자주 사용하는 라우팅도 테스트해 임시로 비어 있는 설정이 문제를 가린 것은 아닌지 살펴보세요. ‘재설치로 해결’이라고만 기록하기보다 문제를 유발한 단계와 해결 방법을 함께 남기면 이후 환경이 바뀌었을 때 같은 문제인지 빠르게 판단할 수 있습니다.

8. 안드로이드 연결 끊김과 배터리 소모: 권한과 백그라운드 정책 확인하기

VpnService 권한과 단일 실행 상태 확인하기

안드로이드에서는 서비스가 시작되지 않는 경우, 서비스는 시작됐지만 트래픽이 없는 경우, 화면을 끈 뒤 서비스가 중지되는 경우를 먼저 구분하세요. v2rayNG와 v2flyNG는 시스템이 제공하는 VpnService로 해당 트래픽을 처리하며, 처음 연결할 때 시스템 권한을 허용해야 합니다. 권한 허용은 로컬 가상 네트워크 인터페이스를 만들 수 있다는 뜻일 뿐 서버 핸드셰이크에 성공했다는 뜻은 아닙니다. 실행 중으로 표시되지만 접속되지 않으면 로그에서 활성 서버, DNS와 아웃바운드 설정을 확인하세요.

일반적으로 같은 사용자 환경에서는 이러한 VPN 서비스를 하나만 활성 상태로 실행할 수 있습니다. 다른 네트워크 필터, 업무용 네트워크나 프록시 앱이 시작되면 현재 서비스를 대체할 수 있습니다. 시스템 설정에서 실제로 실행 중인 앱이 무엇인지 확인하고 상시 알림이 있는지도 살펴보세요. 속도를 비교하려고 v2rayNG와 v2flyNG를 동시에 실행하지 마세요. 한쪽을 완전히 종료한 뒤 다른 쪽을 테스트해야 서비스 가로채기 상태 변화가 결과에 섞이지 않습니다.

클라이언트를 바꿔도 기존 설정과 반드시 호환되는 것은 아닙니다. v2rayNG는 Xray 코어를 사용하고, v2flyNG는 V2Fly 코어를 대안으로 제공합니다. 설정에 필요한 기능에 따라 선택하세요. 설정이 REALITY나 특정 흐름 제어에 의존한다면 코어가 이를 지원하는지 먼저 확인하세요. 핸드셰이크 실패를 시스템 권한 문제로 오인하지 마세요. 최초 권한 요청, 백그라운드 설정과 앱별 프록시의 관계는 v2rayNG 안드로이드 설정 안내를 참고하세요.

화면을 끈 뒤 연결 끊김과 네트워크 전환 문제 해결하기

화면이 켜져 있을 때는 정상인데 한동안 화면을 끄면 연결이 끊긴다면 앱의 배터리 사용 정책, 백그라운드 실행 권한과 제조사 자동 시작 관리부터 확인하세요. 시스템마다 메뉴 이름은 다를 수 있으므로 앱 정보 페이지에서 배터리 설정을 찾아보세요. 필요한 백그라운드 활동을 허용한 뒤 화면을 잠그고 다시 테스트하세요. 모든 앱의 제한을 무작정 풀지 마세요. 상시 알림은 서비스가 실행 중임을 나타내므로 알림을 숨기려고 백그라운드 실행 조건을 해치지 않는 것이 좋습니다.

백그라운드 제한을 완화하면 배터리 소모가 늘 수 있으므로 실제 연결 안정성에 필요한 수준으로 조정하세요. 정해진 간격으로 화면을 끄기 전후의 로그와 시스템 배터리 사용량을 확인해 프로세스 종료, 네트워크 동결 또는 원격 연결 중단 중 무엇이 원인인지 구분하세요. 서비스 알림은 계속 표시되지만 요청이 실패한다면 연결을 다시 수립해야 할 수 있으며, 앱이 시스템에 의해 종료된 것은 아닐 수 있습니다. 강제 종료와 백그라운드 정리를 반복하면 유지하려던 실행 상태가 오히려 깨질 수 있습니다.

Wi-Fi와 모바일 네트워크를 전환하면 주소, 라우팅과 연결 가능성이 달라져 기존 연결이 중단될 수 있습니다. 새 요청을 보내기 전에 클라이언트가 재연결을 완료할 때까지 기다리세요. 전환 전부터 열려 있던 페이지로 현재 상태를 판단하지 마세요. 전환할 때마다 연결에 실패한다면 시스템이 백그라운드 모바일 데이터를 제한하는지, 데이터 절약 모드가 켜져 있는지, 클라이언트의 재연결 동작은 어떤지 확인하세요. 두 네트워크에서는 각각 정상인데 전환 후에만 실패할 때 연결 전환 과정에 집중해 살펴보세요.

앱별 프록시와 비정상적인 배터리 소모 확인하기

일부 앱만 프록시를 사용하지 않는다면 앱별 모드가 ‘선택한 앱만 프록시 사용’인지 ‘선택한 앱 우회’인지 확인하세요. 두 모드는 목록의 의미가 서로 반대입니다. 앱을 선택했는데도 원하는 결과가 나오지 않는다면 모드를 잘못 이해했을 수 있습니다. 변경한 뒤 서비스를 중지했다가 다시 시작하고 대상 앱의 기존 연결도 닫은 다음 테스트하세요. 시스템 구성요소, 업무 프로필의 앱과 같은 이름의 복제 앱은 서로 다른 앱으로 취급될 수 있습니다. 홈 화면의 아이콘 이름만 보고 올바른 앱을 선택했다고 판단하지 마세요.

배터리 소모가 크다면 먼저 통계 기간, 전체 실행 시간과 백그라운드·포그라운드 사용 비율을 확인하세요. 시스템은 VPN 서비스를 통해 전달된 네트워크 활동을 VPN 앱의 사용량으로 집계할 수 있으므로 배터리 화면의 비율이 모두 클라이언트 자체의 추가 소모를 뜻하지는 않습니다. 변경 전후를 비교할 때는 사용량을 비슷하게 유지하세요. 한쪽은 동영상을 계속 재생하고 다른 쪽은 대기한 결과는 비교할 수 없습니다. 신호 약화, 테더링과 다른 앱의 잦은 네트워크 접속도 함께 확인하세요.

유휴 상태에서도 로그에 재연결이 계속 기록되면 서버 연결 가능성, DNS 조회 실패와 네트워크 불안정을 확인하세요. 잦은 핸드셰이크, 자동 테스트와 지나치게 빈번한 업데이트 작업은 기기를 깨울 수 있으므로 불필요한 주기적 요청을 줄이세요. 모든 시간 초과를 무작정 늘리는 것으로 해결하지 마세요. 반대로 제한 시간이 너무 짧으면 일시적인 혼잡을 연결 끊김으로 오인해 재시도가 늘어날 수 있습니다. 기본값이나 근거가 명확한 정책을 유지하고 하나씩 비교하는 편이 ‘배터리 절약 설정’을 통째로 적용하는 것보다 안전합니다.

포그라운드 접속, 화면을 끈 상태의 대기, 네트워크 전환과 앱별 접속의 네 가지 상황을 각각 확인하고 서비스 상태와 오류 시각을 기록하세요. 배터리 문제가 주된 원인이라면 v2rayNG 배터리 소모 및 백그라운드 실행 문제 해결을 참고하세요. 모든 상황에서 같은 핸드셰이크 단계에 실패한다면 노드 시간 초과 장으로 돌아가세요. 시스템 백그라운드 정책, 코어 호환성과 원격 연결은 서로 다른 단서이므로 따로 해결해야 재현 가능한 결과를 얻을 수 있습니다.