v2rayN 설치 및 설정 가이드

설치 전 준비 및 클라이언트 선택

먼저 플랫폼, 프로세서 아키텍처, 사용 범위를 확인하세요

설치 전에 세 가지를 확인해야 합니다. 기기의 운영체제, 프로세서 아키텍처, 그리고 클라이언트가 제공하는 로컬 프록시를 통해 네트워크에 접속해야 하는 프로그램의 범위입니다. 플랫폼은 설치 패키지 형식을, 아키텍처는 바이너리 실행 가능 여부를, 적용 범위는 시스템 프록시와 TUN 중 어떤 방식을 선택할지 결정합니다. 데스크톱에서는 Windows, macOS, Linux를 지원하고 구독 관리, 코어 전환, 라우팅 규칙, 시스템 프록시 제어를 제공하는 v2rayN을 우선 사용하세요. Android에서는 v2rayNG를 우선 사용합니다. V2Fly 코어 동작이 명확히 필요하거나 기존 V2Fly 설정과 일치시켜야 할 때는 v2flyNG를 사용할 수 있습니다.

Windows의 일반적인 기기는 x64 아키텍처를 사용합니다. macOS에서는 Apple Silicon과 Intel을 구분해야 합니다. 시스템 정보의 하드웨어 개요에서 칩 또는 프로세서 이름을 확인하세요. Linux에서는 터미널에서 uname -m을 실행할 수 있습니다. x86_64는 x64, aarch64 또는 arm64는 ARM64에 해당합니다. 최근 Android 기기는 대개 arm64를 사용하지만, 아키텍처를 확인할 수 없거나 설치 중 호환되지 않는다는 메시지가 표시되면 범용 설치 패키지를 사용하세요. 설치 경로와 아키텍처 안내는 다운로드 페이지에 모아 두었습니다. 다른 플랫폼용 패키지를 교차 설치하지 마세요.

클라이언트, 코어, 노드 설정 구분하기

그래픽 클라이언트, 프록시 코어, 노드 설정은 서로 다른 계층입니다. v2rayN, v2rayNG, v2flyNG는 인터페이스, 구독, 실행 제어와 시스템 네트워크 적용을 담당합니다. Xray 또는 V2Fly 코어는 프로토콜을 해석하고 아웃바운드 연결을 수립하며 라우팅과 DNS를 처리합니다. 노드 설정은 서버 주소, 포트, 사용자 식별자, 전송 방식과 TLS, REALITY 등의 연결 매개변수를 제공합니다. 클라이언트 설치가 완료되었다는 것은 인터페이스가 실행된다는 뜻일 뿐, 연결 가능한 서버 설정이 이미 있다는 의미는 아닙니다. 반대로 구독에 노드가 포함되어 있어도 코어가 해당 노드의 모든 매개변수를 지원한다는 보장은 없습니다.

예를 들어 REALITY 또는 XTLS Vision 매개변수가 포함된 설정은 일반적으로 해당 기능을 지원하는 Xray 코어로 처리해야 합니다. 일반적인 VMess, VLESS, Trojan 설정도 주소, 포트, 전송 계층과 보안 계층 매개변수가 정확히 일치해야 합니다. “가져오기는 성공했지만 연결되지 않음” 문제가 발생하면 시스템 프록시 모드를 바로 반복해서 바꾸지 마세요. 먼저 현재 클라이언트가 호출하는 코어 유형을 확인한 다음 노드 요구 사항을 대조하세요. 두 코어의 기능 범위는 Xray 코어와 V2Fly 코어의 차이에서 자세히 확인할 수 있습니다.

구독 자료를 준비하고 복구 경로 남겨 두기

처음 설정하기 전에 유효한 구독 링크, 단일 공유 링크, QR 코드 또는 설정 파일을 준비하세요. 구독은 여러 노드를 일괄 관리할 때 적합하고, 단일 링크는 임시로 하나의 설정을 가져올 때 편리합니다. QR 코드는 데스크톱과 Android 기기 사이에서 소량의 설정을 전달하기 좋으며, 파일 가져오기는 복잡한 전체 매개변수를 보존할 때 유용합니다. 구독 링크는 일반적으로 접속 자격 증명과 같으므로 공개 문서, 스크린샷, 여러 사람이 공유하는 로그에 넣지 마세요. 복사할 때는 전체 문자를 유지하고 메신저가 양끝에 공백을 넣거나 내용을 자동으로 잘라내지 않았는지 확인하세요.

시스템 프록시, TUN, DNS 또는 사용자 지정 라우팅을 변경하기 전에 작동하는 기본 설정을 하나 보관하는 것이 좋습니다. 데스크톱에서는 현재 설정을 내보내거나 기존 라우팅 모드를 기록하고, Android에서는 설정을 복사한 뒤 편집하세요. 문제를 해결할 때는 한 번에 변수 하나만 바꾸세요. 먼저 노드 자체를 확인하고, 다음으로 시스템 적용을 활성화한 뒤, 마지막에 라우팅과 DNS를 조정합니다. 처음부터 코어, 노드, 라우팅, TUN을 동시에 변경하면 실패 원인이 어느 계층에 있는지 판단하기 어렵습니다.

Windows: v2rayN 설치 및 시스템 프록시 적용

데스크톱 버전과 클래식 WPF 버전 선택

Windows 다운로드 영역에서는 v2rayN 데스크톱 버전과 클래식 WPF 버전을 제공합니다. 데스크톱 버전은 최신 크로스 플랫폼 인터페이스를 사용하므로 새로 설치하거나 여러 데스크톱 시스템에서 비슷한 방식으로 사용하려는 경우에 적합합니다. WPF 버전은 Windows에서 오랫동안 사용된 클래식 인터페이스로, 메뉴 위치와 트레이 조작, 설정 관리 방식에 익숙한 환경에 알맞습니다. 두 버전 모두 구독, 노드, 라우팅, 시스템 프록시를 중심으로 동작하므로 동시에 실행해 동일한 로컬 포트를 사용하게 하지 마세요. 처음 설치할 때는 한 버전만 선택하고, 검증을 마친 뒤 이전할지 결정하세요.

다운로드한 뒤 설치 패키지의 안내에 따라 설치를 완료하세요. 압축 해제형 패키지를 사용한다면 현재 사용자가 쓰기 권한을 가진 고정 폴더에 압축을 풀어야 합니다. 압축 파일 미리보기 창에서 바로 실행하거나 자주 정리되는 임시 폴더에 넣지 마세요. 프로그램은 설정, 로그, 코어 파일을 저장해야 합니다. 폴더에 쓸 수 없으면 인터페이스는 열리더라도 구독 업데이트나 코어 실행이 실패할 수 있습니다. 처음 실행한 뒤 시스템 트레이를 확인하세요. 기본 창을 닫으면 프로그램이 종료되지 않고 트레이로 최소화되는 경우가 일반적입니다. 완전히 중지하려면 트레이 메뉴에서 종료를 선택하세요.

구독 가져오기 및 활성 노드 선택

구독 그룹 관리에서 새 구독을 추가하고 알아보기 쉬운 메모와 전체 링크를 입력한 다음 현재 구독 업데이트 또는 모든 구독 업데이트를 실행하세요. 업데이트가 끝나면 기본 목록에 노드가 표시되어야 합니다. 목록에 변화가 없다면 현재 보고 있는 그룹과 방금 업데이트한 그룹이 같은지 먼저 확인한 뒤, 로그에서 네트워크 요청 실패인지, 콘텐츠 파싱 실패인지, 응답 내용이 비어 있는지 확인하세요. 같은 구독을 반복해서 추가하면 여러 그룹 사본이 생겨 이후 업데이트 대상을 잘못 선택하기 쉽습니다. 하나의 출처에는 명확한 이름의 그룹 하나만 유지하는 편이 좋습니다.

노드를 선택한 뒤 활성 서버로 지정하세요. 노드 목록의 “선택됨”과 코어의 “실행 중”은 서로 다른 상태입니다. 전자는 사용할 설정을 지정할 뿐이고, 후자여야 로컬 프록시 포트를 수신 대기합니다. 서비스를 시작한 뒤 하단 상태 표시줄과 로그를 확인하세요. 정상이라면 로컬 수신 대기가 설정되었다는 내용이 표시됩니다. 그때 클라이언트의 실제 연결 테스트를 사용하거나 시스템 프록시를 명확히 사용하는 브라우저 페이지를 열어 보세요. 노드 속도 측정 결과는 비교를 돕는 자료일 뿐 실제 연결 테스트를 대신할 수 없습니다. 세 가지 속도 지표의 차이는 지연 시간 측정값 읽는 법에서 확인할 수 있습니다.

시스템 프록시의 작동 방식

Windows 시스템 프록시는 시스템 프록시 설정을 읽는 앱에 주로 영향을 줍니다. “시스템 프록시 자동 설정”을 선택하면 v2rayN이 시스템 프록시를 로컬 수신 포트로 지정하고 클라이언트 상태에 맞춰 갱신합니다. 브라우저와 많은 데스크톱 프로그램은 이 설정을 읽지만, 일부 게임, 명령줄 도구, 스토어 앱 또는 자체 네트워크 스택을 구현한 소프트웨어는 무시할 수 있습니다. 브라우저는 접속되는데 다른 프로그램이 되지 않는다면 먼저 해당 프로그램이 시스템 프록시를 지원하는지 확인하고, 문제를 곧바로 노드 탓으로 돌리지 마세요.

라우팅 모드는 로컬 프록시 포트로 들어온 요청을 프록시 아웃바운드와 직접 연결 아웃바운드 중 어디로 보낼지 결정합니다. 일반적인 “LAN 및 중국 본토 우회”는 일상적인 규칙 기반 분할에 적합합니다. LAN 주소와 직접 연결 규칙에 해당하는 요청은 원격 노드를 거치지 않고 나머지는 규칙에 따라 처리합니다. 전역 모드는 특정 도메인이 규칙에 의해 잘못 분류되었는지 임시로 확인할 때 유용하지만, 영향을 이해하지 못한 채 장기간 문제 해결용 지름길로 사용해서는 안 됩니다. 라우팅을 전환한 뒤에는 현재 노드에 다시 연결해 코어가 규칙을 다시 불러오게 하세요.

관리자 권한, 포트 사용 및 시작 프로그램

일반적인 시스템 프록시는 계속 관리자 권한으로 실행할 필요가 없지만, 네트워크 구성 요소 설치, 특정 TUN 구현 활성화 또는 보호된 설정 변경 시 권한 상승을 요구할 수 있습니다. 해당 작업을 수행할 때만 권한을 승인하세요. 코어가 시작 직후 종료되면 로그에서 “address already in use” 또는 유사한 포트 사용 메시지를 우선 확인하세요. 다른 v2rayN 인스턴스, 다른 프록시 클라이언트 또는 남아 있는 코어 프로세스가 같은 포트를 수신 중인 것이 흔한 원인입니다. 중복 프로그램을 먼저 종료한 뒤 현재 클라이언트를 다시 시작하고, 충돌을 숨기려고 여러 포트를 무작정 바꾸지 마세요.

시작 프로그램 등록은 고정 기기에 적합하지만 기본 설정이 안정된 뒤 활성화해야 합니다. “클라이언트 시작 시 실행”과 “시작 후 자동 연결”을 동시에 켜면 로그인 직후 프록시 상태가 바뀝니다. 구독이 만료되었거나 네트워크가 아직 준비되지 않았거나 이전 노드를 사용할 수 없으면 부팅 직후 인터넷이 되지 않는 것처럼 보일 수 있습니다. 더 안정적인 순서는 클라이언트만 먼저 시작하고 네트워크가 준비된 뒤 연결하는 것입니다. 트레이에서 “시스템 프록시 해제”를 실행할 경로도 남겨 두세요. 비정상 종료 후 브라우저가 계속 로컬 포트에 연결하려 하면 Windows 프록시 설정에서 프록시를 끈 다음 v2rayN을 다시 시작하세요.

로컬 포트가 수신 대기 중인지 확인:
netstat -ano | findstr LISTENING

특정 프로세스 ID에 해당하는 프로그램 확인:
tasklist /fi "PID eq 프로세스 ID"

macOS: v2rayN 설치, 권한 승인 및 프록시 설정

칩 유형에 맞는 설치 패키지 선택

macOS용 v2rayN 설치 패키지는 Apple Silicon과 Intel용으로 나뉩니다. 시스템 정보를 열고 하드웨어 개요에서 “칩” 또는 “프로세서” 항목을 확인하세요. Apple 계열 칩이면 ARM64 패키지를, Intel이라고 표시되면 x64 패키지를 선택합니다. 아키텍처가 잘못되면 시스템이 실행을 거부하거나 호환 계층에서 실행되면서 추가 문제가 생길 수 있습니다. 설치 전에 macOS 다운로드 경로에서 맞는 파일을 받으세요. 기기를 구입한 연도만으로 칩 유형을 판단하지 마세요.

디스크 이미지를 연 뒤 애플리케이션을 “응용 프로그램” 폴더로 드래그하고 해당 폴더에서 실행하세요. 디스크 이미지 안에서 직접 실행하면 저장, 업데이트, 권한 관리에 불리합니다. 처음 실행할 때 시스템은 앱 출처를 확인하고 승인 안내를 표시합니다. 시스템 설정의 앱 보안 화면에서 명시적으로 실행을 허용하세요. 권한 승인은 시스템이 앱 실행을 허용하는 문제만 해결합니다. 인터페이스가 열린 뒤 코어가 실행되지 않으면 클라이언트 로그와 코어 파일 상태를 별도로 확인해야 합니다.

설정 가져오기 및 코어 실행

구독 관리 절차는 Windows와 비슷합니다. 구독 메모와 링크를 추가하고 구독을 업데이트한 다음 대상 그룹에서 노드를 선택하고 서비스를 시작하세요. macOS 클립보드는 서식 있는 페이지에서 복사한 링크에 줄바꿈을 포함할 수 있으므로 붙여넣은 뒤 앞뒤를 확인해야 합니다. QR 코드는 다른 기기에서 단일 설정을 전달할 때 적합하지만, 여러 노드는 이후 일괄 업데이트가 가능한 구독을 권장합니다. 구독 업데이트는 성공했는데 노드 목록이 비어 있다면 그룹 필터와 구독 콘텐츠 유형을 확인하세요. 로그에 파싱 오류가 표시되면 알 수 없는 매개변수를 수동으로 추가하지 말고 구독 출처에서 형식을 확인하세요.

코어가 시작되면 로컬에서 HTTP, SOCKS 또는 혼합 프록시 포트를 수신 대기합니다. 클라이언트 인터페이스에서 활성 노드, 코어 상태, 시스템 프록시 상태를 각각 확인해야 합니다. 노드가 선택되었다고 시스템 네트워크가 적용된 것은 아니며, 시스템 프록시가 켜져 있다고 코어가 반드시 수신 중인 것도 아닙니다. 가장 흔한 오류 상태는 시스템 프록시는 로컬 포트를 가리키는데 클라이언트는 종료된 경우입니다. 이때 브라우저는 존재하지 않는 서비스에 계속 연결을 시도합니다. 클라이언트를 다시 시작하거나 시스템 프록시를 끄면 기본 네트워크를 복구할 수 있습니다.

시스템 프록시와 앱별 동작 차이

macOS 시스템 프록시는 Wi-Fi와 유선 네트워크처럼 네트워크 서비스별로 저장됩니다. v2rayN이 현재 시스템 프록시를 변경하면 이를 따르는 브라우저와 앱이 요청을 로컬 포트로 보냅니다. 터미널 도구가 프록시를 사용하는지는 도구마다 다릅니다. 일부는 환경 변수를 읽고, 일부는 시스템 네트워크 설정을 읽으며, 별도 매개변수가 필요한 도구도 있습니다. 따라서 “브라우저는 정상인데 터미널 요청은 직접 연결”되는 것은 모순이 아닙니다. 브라우저와 일반 앱만 필요하다면 시스템 프록시가 더 직관적이고, 시스템 프록시를 읽지 않는 프로그램까지 적용하려면 TUN을 검토하세요.

Wi-Fi를 바꾸거나 유선 네트워크에 연결하거나 핫스팟을 사용한 뒤에는 현재 네트워크 서비스의 프록시 상태를 다시 확인하세요. 절전 모드에서 깨어난 뒤 클라이언트는 실행 중으로 표시되지만 요청이 실패한다면 현재 노드 연결을 끊었다가 다시 연결해 하위 연결을 재구성해 보세요. 네트워크가 바뀔 때마다 구독을 삭제할 필요는 없습니다. 구독은 설정을 저장하고 네트워크 전환은 기기와 서버 사이의 경로만 바꿉니다. 회사 네트워크, 인증이 필요한 네트워크 또는 웹 로그인형 공용 네트워크에서는 먼저 적용을 끄고 시스템 인증을 완료한 뒤 프록시 서비스를 시작하세요.

TUN 권한, DNS 및 종료 후 복구

TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 조정하므로 시스템 프록시보다 적용 범위가 넓습니다. 처음 활성화할 때 시스템 권한이 필요할 수 있습니다. 승인 후에도 가상 인터페이스가 생성되었는지, 기본 라우팅이 예상대로 바뀌었는지, DNS 요청을 어느 계층이 처리하는지 확인하세요. 활성화 후 모든 요청이 실패하면 먼저 TUN을 끄고 시스템 프록시 모드가 작동하는지 확인하세요. 이 단계로 “노드 또는 코어 문제”와 “가상 네트워크 적용 문제”를 빠르게 구분할 수 있습니다.

DNS 문제는 도메인으로 접속할 수 없지만 대상 주소로 직접 연결하거나 클라이언트 연결 테스트에는 반응이 있는 형태로 나타나는 경우가 많습니다. 우선 클라이언트 라우팅과 DNS의 기본 조합을 사용하고 여러 시스템 수준 DNS 도구를 동시에 활성화하지 마세요. 사용자 지정 설정이 꼭 필요하다면 직접 연결 도메인과 프록시 도메인을 각각 어느 리졸버가 처리하는지 먼저 정해 DNS 결과와 라우팅 방향이 충돌하지 않도록 하세요. 클라이언트를 종료하기 전에는 시스템 프록시 또는 TUN을 먼저 끄세요. 프로그램이 갑자기 종료되었다면 시스템 네트워크 설정에서 현재 네트워크 서비스의 프록시 항목을 확인하고 로컬 포트를 계속 가리키는 설정을 해제하세요.

프로세서 아키텍처 확인:
uname -m

현재 네트워크 서비스 목록 확인:
networksetup -listallnetworkservices

Wi-Fi 웹 프록시 상태 확인:
networksetup -getwebproxy Wi-Fi

Linux: v2rayN 설치, 데스크톱 프록시 및 TUN

배포판, 아키텍처 및 설치 형식 확인

Linux 다운로드 영역에서는 v2rayN의 deb 및 rpm 설치 패키지를 제공하며 x64와 ARM64로 구분합니다. Debian, Ubuntu 및 주요 파생 배포판은 일반적으로 deb를 사용하고, Fedora, Rocky Linux, AlmaLinux 등 rpm 계열 배포판은 rpm을 사용합니다. uname -m으로 아키텍처를 확인한 다음 /etc/os-release로 배포판 정보를 확인하세요. 설치 형식과 프로세서 아키텍처가 모두 일치해야 하며, 하나만 맞아도 설치 프로그램 오류나 바이너리 실행 불가가 발생할 수 있습니다.

그래픽 클라이언트는 데스크톱 세션, 알림 영역 및 일부 런타임 라이브러리에 의존합니다. 서버 환경은 패키지를 설치할 수 있더라도 v2rayN 인터페이스를 표시할 조건이 없을 수 있습니다. 이 가이드는 데스크톱 환경이 있는 Linux 기기를 대상으로 합니다. Wayland와 X11에서는 트레이 구현이 다를 수 있습니다. 창을 닫은 뒤 트레이 아이콘이 보이지 않으면 앱 메뉴에서 다시 열거나 데스크톱 환경의 상태 아이콘 지원을 확인하세요. 트레이가 보이지 않는다고 여러 인스턴스를 반복 실행하지 마세요. 중복 실행은 포트 충돌을 일으키기 쉽습니다.

시스템 패키지 관리자로 설치

터미널에서 다운로드 디렉터리로 이동한 뒤 패키지 관리자로 로컬 파일을 설치할 수 있습니다. 직접 압축을 푸는 것보다 패키지 관리자를 사용하면 의존성 처리와 이후 제거가 쉽습니다. 아래 와일드카드 방식은 다운로드 디렉터리에 해당 아키텍처의 v2rayN 설치 패키지가 하나만 있을 때 사용하세요. 여러 파일이 있다면 실제 파일명을 입력해 이전 패키지를 잘못 선택하지 않도록 합니다. 의존성을 충족할 수 없다는 메시지가 표시되면 먼저 배포판 저장소를 갱신하고 시스템 버전이 여전히 지원되는지 확인한 뒤 다시 설치하세요.

시스템 및 아키텍처 확인:
cat /etc/os-release
uname -m

Debian 또는 Ubuntu 계열 설치:
cd ~/Downloads
sudo apt install ./v2rayN*.deb

Fedora 또는 rpm 호환 배포판 설치:
cd ~/Downloads
sudo dnf install ./v2rayN*.rpm

설치가 완료되면 데스크톱 앱 메뉴에서 v2rayN을 실행하세요. 터미널 실행 중 공유 라이브러리 누락 메시지가 나타나면 배포판 패키지 관리자로 필요한 의존성을 보충하세요. 출처를 알 수 없는 곳에서 라이브러리 하나를 복사해 시스템 디렉터리를 덮어쓰지 마세요. 프로그램은 시작되지만 코어가 실행되지 않는다면 코어 파일의 실행 권한, 프로그램 데이터 디렉터리의 쓰기 권한, 보안 정책의 하위 프로세스 차단 여부를 확인하세요. 업그레이드할 때는 실행 중인 클라이언트를 먼저 종료한 뒤 새 패키지를 설치하세요.

구독 가져오기 및 데스크톱 시스템 프록시 설정

구독 추가, 그룹 업데이트, 노드 선택, 코어 실행 순서는 다른 데스크톱 시스템과 같습니다. Linux의 차이는 모든 데스크톱 환경이 동일한 시스템 프록시 인터페이스를 사용하지 않는다는 점입니다. GNOME, KDE 및 기타 데스크톱 환경은 프록시 설정 저장 방식이 다르며, v2rayN이 현재 데스크톱 프록시에 자동으로 기록할 수 있는지는 환경 지원 여부에 달려 있습니다. 활성화한 뒤 데스크톱 네트워크 설정에서 프록시 주소가 로컬 호스트를 가리키는지, 포트가 클라이언트 상태 표시줄과 일치하는지 확인하세요.

많은 터미널 프로그램은 데스크톱 프록시를 자동으로 읽지 않습니다. 현재 터미널 세션의 도구가 로컬 HTTP 프록시를 임시로 사용하게 하려면 환경 변수를 설정할 수 있습니다. 포트는 클라이언트에 실제로 표시된 값을 사용하세요. 환경 변수는 현재 셸과 하위 프로세스에만 적용되고 터미널을 닫으면 사라집니다. 포트가 고정되었는지 확인하기 전에는 전역 시작 파일에 기록하지 말고 테스트 용도로 사용하세요.

현재 터미널 세션에 로컬 프록시 설정:
export http_proxy=http://127.0.0.1:10809
export https_proxy=http://127.0.0.1:10809

테스트 후 해제:
unset http_proxy
unset https_proxy

TUN, 권한 및 네트워크 관리자의 범위

TUN 모드는 가상 네트워크 인터페이스, 라우팅 테이블 및 적절한 권한에 의존합니다. 활성화하기 전에 /dev/net/tun이 존재하는지 확인하고 기본 라우팅을 변경하는 다른 네트워크 도구를 동시에 실행하지 마세요. 클라이언트에서 권한 부족이 표시되면 클라이언트가 제공하는 로컬 승인 절차를 따르세요. 데스크톱 세션 전체를 장기간 root로 실행하지 마세요. 권한 승인의 목적은 필요한 네트워크 작업을 허용하는 것이지 모든 클라이언트 파일에 최고 권한을 부여하는 것이 아닙니다.

Linux의 DNS는 systemd-resolved, NetworkManager, 데스크톱 네트워크 관리자 또는 다른 로컬 서비스가 관리할 수 있습니다. TUN 시작 후 도메인 해석에 문제가 생기면 먼저 ip route로 라우팅이 생성되었는지 확인하고, 이어 resolvectl status로 현재 DNS 관리 주체를 확인하세요. 해당 명령이 없다면 배포판에서 사용하는 네트워크 관리자를 기준으로 점검합니다. 문제를 해결할 때는 먼저 시스템 프록시 모드로 돌아가 노드를 검증하고, 노드가 정상인 뒤 TUN을 별도로 활성화하세요. 그러면 데스크톱 프록시, 코어 연결, 시스템 라우팅 문제를 섞지 않을 수 있습니다.

Android: v2rayNG 및 v2flyNG 설정

클라이언트 선택 및 설치 아키텍처

Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 권장합니다. VLESS, VMess, Trojan, REALITY 등 일반적인 설정이 포함된 환경에 적합합니다. v2flyNG는 V2Fly 코어를 사용하며 해당 코어 동작이 필요할 때 대안으로 사용할 수 있습니다. 두 클라이언트를 같은 기기에 설치할 수는 있지만 한 번에 VPN 서비스를 만드는 앱은 하나뿐입니다. 클라이언트를 전환하기 전에 현재 연결을 먼저 끊어 상태 표시줄에 이전 서비스가 남거나 새 클라이언트가 적용 권한을 얻지 못하는 상황을 피하세요.

최근 출시된 대부분의 기기는 arm64 설치 패키지를 선택하면 됩니다. 기기 아키텍처를 확인할 수 없거나 arm64 패키지 설치 중 호환되지 않는다는 메시지가 표시되면 범용 버전을 사용하세요. 설치 후 처음 실행할 때 필요한 네트워크 연결 권한을 허용합니다. 알림 권한은 연결 상태를 확인하기 쉽게 만들지만 노드 매개변수의 정확성을 결정하지는 않습니다. Android에서 VPN 연결을 만들라는 확인 대화상자가 표시되는 것은 앱 트래픽을 로컬 VPN 인터페이스를 통해 클라이언트가 처리하도록 넘기는 표준 절차입니다.

구독, 클립보드 및 QR 코드 가져오기

구독을 가져올 때 구독 그룹에 이름과 전체 링크를 추가한 뒤 구독을 업데이트하세요. 일부 시스템은 앱의 백그라운드 클립보드 읽기를 제한하므로 클립보드 가져오기에 실패하면 추가 화면에서 직접 붙여넣을 수 있습니다. QR 코드는 단일 공유 설정을 가져올 때 적합합니다. 스캔하기 전에 신뢰할 수 있는 출처의 QR 코드인지 확인하고, 가져온 뒤 프로토콜, 주소, 포트, 전송 매개변수가 완전한지 점검하세요. QR 코드가 흐리거나 잘려 있으면 클라이언트가 인식하지 못할 수 있지만 구독 링크를 통한 가져오기에는 영향을 주지 않습니다.

구독 업데이트가 완료되면 노드 목록에서 설정 하나를 선택하고 기본 화면으로 돌아가세요. 그룹이 여러 개라면 현재 노드가 방금 업데이트한 그룹에 속하는지 확인합니다. 노드 메모는 식별용일 뿐 연결에는 사용되지 않습니다. 실제 연결을 결정하는 것은 주소, 포트, 사용자 식별자, 프로토콜, 전송 계층, 보안 계층, 서버 이름 등의 매개변수입니다. 수동 편집 시 앞부분의 몇 개 필드만 비교하지 마세요. 특히 WebSocket 경로, gRPC 서비스 이름, TLS 서버 이름, REALITY 공개 키와 짧은 식별자가 하나라도 빠지면 핸드셰이크 단계에서 연결이 실패할 수 있습니다.

VPN 서비스, 앱별 프록시 및 백그라운드 제한

연결 버튼을 누르면 v2rayNG 또는 v2flyNG가 로컬 VPN 서비스를 시작합니다. 데스크톱 시스템 프록시와 달리 앱 트래픽은 시스템 가상 네트워크 인터페이스로 들어간 뒤 클라이언트가 라우팅 규칙에 따라 직접 연결 또는 프록시를 결정합니다. 시스템 상태 표시줄의 VPN 아이콘은 인터페이스가 생성되었다는 뜻일 뿐 원격 노드가 정상이라는 의미는 아닙니다. 연결 후 클라이언트 로그를 확인하거나 대상 서비스에 실제로 접속해 검증하세요. 즉시 연결이 끊기면 설정 파싱과 코어 시작 로그를 중점적으로 확인합니다.

앱별 프록시는 어떤 앱을 클라이언트에 연결할지 제한하는 기능입니다. 화이트리스트 모드는 선택한 앱만 처리하고, 블랙리스트 모드는 제외되지 않은 앱을 처리합니다. 잘못 설정하면 브라우저는 작동하지만 대상 앱은 프록시를 거치지 않거나, 시스템 구성 요소가 실수로 포함되어 이상 동작할 수 있습니다. 처음 연결할 때는 복잡한 앱별 규칙을 사용하지 말고 기본 연결을 확인한 뒤 앱을 하나씩 추가하세요. 앱 목록을 변경한 뒤에는 다시 연결해 VPN 라우팅을 재구성하세요.

Android의 배터리 절약 정책은 백그라운드 프로세스를 제한할 수 있습니다. 화면이 꺼진 뒤 일정 시간이 지나 연결이 끊기거나 앱으로 돌아왔을 때만 복구된다면 시스템 배터리 설정에서 클라이언트의 백그라운드 실행을 허용하고 강제 절전 목록에서 제외하세요. 제조사마다 설정 이름은 다르지만, 화면 잠금 후 클라이언트 프로세스가 종료되는지가 판단 기준입니다. 상시 알림은 시스템과 사용자가 연결 상태를 확인하는 데 도움을 줍니다. 강제 종료로 연결을 끊지 말고 클라이언트에서 연결 해제를 눌러 VPN 인터페이스와 라우팅을 정상적으로 해제하세요.

앱별 규칙, LAN 및 DNS

LAN 기기에 접속하려면 사설 주소 대역이 직접 연결되도록 해야 합니다. 가정용 라우터, 프린터, 저장 장치는 일반적으로 192.168.0.0/16, 10.0.0.0/8 또는 172.16.0.0/12에 있습니다. 전역 프록시를 켠 뒤 이런 기기에 접근할 수 없다면 기기마다 원격 규칙을 추가하지 말고 LAN 직접 연결 규칙이 포함된 라우팅 모드로 변경하세요. 모바일 네트워크와 Wi-Fi를 전환하면 하위 연결이 바뀌므로 클라이언트를 다시 연결해야 할 수 있습니다. 이는 네트워크 경로 재구성이며 구독을 다시 가져올 필요는 없습니다.

Android의 비공개 DNS, 클라이언트 DNS 설정, 노드 도메인 해석은 서로 영향을 줄 수 있습니다. 주소로는 연결되지만 도메인으로는 실패한다면 먼저 클라이언트 기본 DNS로 되돌리고 추가 시스템 DNS 설정을 잠시 끈 상태에서 비교하세요. 일부 도메인만 잘못된 방향으로 연결되면 라우팅 규칙이 도메인 기준인지 해석된 주소 기준인지 확인합니다. 비공개 DNS, 클라이언트 DNS, 라우팅 모드, 노드 보안 매개변수를 동시에 변경하지 마세요. 그러면 비교 결과를 해석할 수 없습니다.

구독, 노드 및 여러 기기의 설정 관리

구독 업데이트는 클라이언트 업그레이드가 아닙니다

구독 업데이트, 클라이언트 업그레이드, 코어 업데이트는 서로 독립적인 작업입니다. 구독 업데이트는 기존 링크에서 노드 목록을 다시 읽어 노드를 추가, 삭제 또는 수정할 수 있습니다. 클라이언트 업그레이드는 그래픽 인터페이스와 관리 로직을 갱신하고, 코어 업데이트는 프로토콜 구현과 연결 동작에 영향을 줍니다. 문제를 해결할 때 무엇이 어느 계층에서 변경되었는지 반드시 기록하세요. 구독 업데이트 후 특정 노드가 작동하지 않으면 먼저 노드 매개변수를 비교하거나 같은 구독의 다른 노드를 사용하세요. 코어 업데이트 후 기존에 작동하던 여러 설정이 동시에 이상해졌다면 코어 로그와 설정 호환성을 확인합니다.

구독은 출처별로 그룹화하고 알아보기 쉬운 메모를 사용하세요. 여러 출처를 추적할 수 없는 하나의 목록으로 합치거나 “기본”, “테스트”처럼 구분하기 어려운 이름으로 사본을 쌓지 마세요. 업데이트 전에 대상 그룹을 확인하고, 업데이트 후 노드 수와 메모가 예상과 일치하는지 살펴보세요. 일부 구독 업데이트는 서버에서 삭제된 노드를 제거하므로 구독 노드를 수동으로 수정해도 다음 업데이트에서 덮어써질 수 있습니다. 장기간 유지할 개인 설정은 로컬 독립 설정으로 복사한 뒤 사본을 편집하세요.

네 가지 가져오기 방식의 사용 범위

구독 링크는 여러 노드와 지속적인 관리에 적합하고, 공유 링크는 단일 노드를 빠르게 전달할 때 유용합니다. QR 코드는 가까운 기기 사이에서 소량의 설정을 가져올 때, 설정 파일은 인바운드, 아웃바운드, 라우팅, DNS 구조를 비교적 완전하게 전달할 때 적합합니다. 공유 링크는 보통 하나의 아웃바운드 노드만 설명하며 클라이언트 수준의 라우팅 정책까지 포함하지는 않습니다. 데스크톱에서 Android로 복사하면 노드 매개변수는 유지되지만 시스템 프록시, 앱별 프록시, TUN 같은 플랫폼 설정은 자동으로 이전되지 않습니다.

설정 파일을 가져올 때는 “클라이언트 백업”과 “코어 설정”을 구분해야 합니다. 클라이언트 백업에는 그룹, 인터페이스 설정, 로컬 경로가 포함될 수 있어 동일한 클라이언트 체계에서만 적합합니다. 코어 JSON은 인바운드, 아웃바운드, 라우팅 같은 하위 구조를 설명하지만 그래픽 클라이언트가 모든 사용자 지정 필드를 허용하지는 않습니다. 가져오기에 실패하면 먼저 파일 유형을 판단하고, 임의의 JSON을 노드 파일로 취급하지 마세요. 여러 기기 동기화의 세 가지 일반적인 방법과 선택 기준은 V2Ray 설정을 여러 기기에서 동기화하는 세 가지 방법에서 확인할 수 있습니다.

노드 매개변수의 의존 관계 이해하기

프로토콜 필드는 단독으로 판단할 수 없습니다. VLESS와 VMess는 모두 서버 주소, 포트, 사용자 식별자가 필요하고 Trojan은 비밀번호 계열 자격 증명으로 인증합니다. 전송 계층은 TCP, WebSocket, gRPC 등이 될 수 있으며 보안 계층은 TLS 또는 REALITY를 사용할 수 있습니다. TLS를 사용할 때 서버 이름은 일반적으로 인증서 검증에 사용됩니다. WebSocket은 경로와 요청 호스트가 서버와 일치해야 하고, gRPC는 서비스 이름이 같아야 합니다. REALITY 설정에는 공개 키, 서버 이름, 짧은 식별자 등의 매개변수도 필요합니다. 프로토콜 이름만 바꾸고 맞지 않는 전송 매개변수를 그대로 두어서는 작동하는 설정을 만들 수 없습니다.

노드 메모, 그룹 이름, 속도 측정 정렬은 클라이언트 관리 정보이며 프로토콜 핸드셰이크에 관여하지 않습니다. 주소는 도메인이나 네트워크 주소일 수 있습니다. 도메인은 먼저 해석되어야 하므로 DNS 문제는 실제 서버 연결 전에 발생합니다. 연결 로그에 도메인 해석 실패가 표시되면 DNS부터 처리하세요. 연결 거부나 시간 초과가 표시되면 주소, 포트, 네트워크 경로를 확인합니다. TLS 또는 REALITY 핸드셰이크 이후 실패한다면 보안 계층 매개변수를 중점적으로 확인하세요. 막연히 “모드를 바꾸는 것”보다 단계별로 로그를 읽는 편이 효과적입니다.

안전한 보관 및 업데이트 주기

구독 링크와 공유 링크에는 접속에 필요한 전체 정보가 포함될 수 있습니다. 제어된 비밀번호 관리 도구나 기기의 보안 저장소에 보관하고 공개 메모, 포럼 게시물, 화면 녹화, 전체 로그에는 기록하지 마세요. 다른 사람에게 문제 해결 정보를 제공할 때는 프로토콜 유형, 전송 방식, 오류 단계는 남길 수 있지만 서버 주소, 사용자 식별자, 비밀번호, 공개 키 관련 설정, 구독 링크는 가리세요. 클라이언트 로그에 대상 주소가 기록될 수 있으므로 공유하기 전에 내용을 확인하세요.

업데이트 주기는 실제 사용 방식에 맞춰 정하세요. 구독을 자주 새로 고친다고 연결 품질이 좋아지지는 않으며, 오히려 서버가 일시적으로 이상할 때 현재 목록을 덮어쓸 수 있습니다. 클라이언트의 예약 업데이트 기능을 사용하거나 노드가 작동하지 않거나 설정 변경 알림을 받았을 때 수동으로 업데이트하세요. 업데이트 후에는 기존 선택을 유지하고 새 목록이 정상인지 확인한 뒤 전환하세요. 여러 기기에서 같은 구독을 사용하더라도 모든 기기를 동시에 새로 고칠 필요는 없지만, 어느 한 기기가 이미 제거된 이전 매개변수를 장기간 사용하지 않도록 하세요.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

시스템 프록시, TUN, 라우팅 분할 및 DNS

시스템 프록시와 TUN의 본질적인 차이

시스템 프록시는 운영체제에 로컬 프록시 주소를 알리는 방식이며, 이 설정을 적극적으로 읽는 앱만 요청을 클라이언트에 전달합니다. 설정이 간단하고 영향 범위가 분명해 브라우저와 일반 데스크톱 앱에 적합합니다. TUN은 가상 네트워크 인터페이스로 더 넓은 범위의 트래픽을 받은 뒤 코어가 직접 연결 또는 프록시를 결정하게 합니다. 시스템 프록시를 지원하지 않는 프로그램까지 적용할 수 있지만 라우팅 테이블, DNS, 권한, 가상 인터페이스가 함께 관여하므로 문제 해결 계층이 더 많습니다.

모드는 앱의 요구 사항을 기준으로 선택하세요. 브라우저, 업무용 소프트웨어, 프록시를 명확히 지원하는 도구만 필요하다면 먼저 시스템 프록시를 사용합니다. 시스템 프록시를 무시하는 프로그램이 있거나 더 많은 트래픽을 통합 처리해야 할 때 TUN을 활성화하세요. Android 클라이언트는 시스템 VPN 서비스를 통해 트래픽을 적용하므로 데스크톱 TUN과 비슷한 면이 있지만 권한과 라우팅은 모바일 시스템이 관리합니다. 여러 클라이언트가 동시에 시스템 프록시를 변경하거나 가상 네트워크 인터페이스를 만들게 하지 마세요. 트래픽 루프, 잘못된 전달, 예측하기 어려운 출구가 발생할 수 있습니다.

라우팅 규칙의 매칭 방식

라우팅 규칙은 일반적으로 도메인, 네트워크 주소, 포트, 프로토콜 또는 인바운드 태그를 기준으로 요청을 매칭하고 프록시, 직접 연결, 차단 아웃바운드로 보냅니다. 규칙에 순서가 있다면 앞에서 이미 매칭된 요청은 뒤의 일반 규칙으로 넘어가지 않습니다. 따라서 사용자 지정 규칙은 구체적인 조건에서 포괄적인 조건 순으로 배치하고 마지막에 기본 출구를 남겨 두세요. LAN과 사설 주소는 일반적으로 직접 연결을 우선해야 라우터, 프린터, 로컬 서비스에 접속할 때 원격 노드를 거치지 않습니다.

도메인 매칭과 네트워크 주소 매칭은 서로 다른 단계에서 발생합니다. domain:, full: 또는 규칙 세트를 사용하면 코어가 요청의 도메인을 기준으로 방향을 결정할 수 있습니다. 앱이 네트워크 주소에 직접 접속하면 도메인 규칙은 적용되지 않습니다. 일부 정책은 도메인을 먼저 해석한 뒤 결과 주소로 매칭합니다. domainStrategy를 변경하면 이 과정에 영향을 주므로 현재 규칙의 출처를 먼저 이해하고, 이를 범용 가속 스위치처럼 사용하지 마세요.

DNS와 라우팅은 함께 조정해야 함

DNS는 도메인을 연결 가능한 주소로 변환하고, 라우팅은 해석 요청과 이후 연결을 각각 어느 출구로 보낼지 결정합니다. 둘이 일치하지 않으면 현재 출구에 적합하지 않은 주소로 해석되거나 DNS 요청이 잘못된 경로에서 차단될 수 있습니다. 대표적인 증상은 노드 연결 테스트에는 반응하지만 웹 도메인이 열리지 않음, 특정 도메인만 반복해서 시간 초과, 네트워크 주소로 전환하면 상태가 달라짐, TUN을 활성화한 뒤 모든 도메인이 동시에 실패함 등입니다.

DNS를 점검할 때는 먼저 클라이언트 기본 방식을 복원하고 노드와 기본 라우팅이 작동하는지 확인하세요. 이어 운영체제에 다른 DNS 도구가 있는지, 브라우저 보안 DNS나 기업 네트워크 정책이 적용되는지 살펴봅니다. 주요 제어 계층은 한 번에 하나만 남겨 두세요. 사용자 지정이 필요하다면 직접 연결 도메인은 로컬에서 접근 가능한 리졸버를 사용하고 프록시 방향 도메인은 클라이언트 방식으로 처리하게 할 수 있지만, 구체적인 규칙은 현재 코어 기능에 맞아야 합니다. 출처가 불명확한 대규모 DNS 설정을 복사하지 마세요. 수신 주소, 아웃바운드 태그, 라우팅 태그가 현재 기기 설정과 완전히 다를 수 있습니다.

트래픽의 실제 경로 확인

트래픽 분할은 클라이언트 아이콘만 보고 판단할 수 없습니다. 먼저 코어 로그에 대상 도메인 또는 주소와 선택된 아웃바운드 태그가 나타나는지 확인하고, 현재 라우팅 규칙과 대조해 예상한 조건이 매칭되었는지 살펴보세요. 로그에 대상 요청이 전혀 없다면 앱이 클라이언트에 들어오지 않은 것입니다. 시스템 프록시, 환경 변수, 앱별 프록시, TUN 적용 계층을 다시 확인하세요. 로그에 요청은 있지만 방향이 잘못되었다면 규칙 순서를 수정합니다. 방향은 맞지만 연결에 실패한다면 노드와 네트워크 경로를 확인하세요.

전역 모드로 임시 전환하는 것은 비교 방법입니다. 같은 노드가 전역 모드에서는 작동하지만 규칙 모드에서는 작동하지 않는다면 문제는 대개 라우팅 또는 DNS에 있습니다. 두 모드 모두 작동하지 않으면 노드, 코어, 기본 네트워크를 우선 점검하세요. 비교가 끝나면 원래 모드로 복원하고 현재 노드에 다시 연결합니다. 전역 모드를 장기간 해결책으로 사용하면 규칙 오류를 가릴 뿐 아니라 LAN과 일반적으로 직접 연결해야 할 요청의 경로도 바뀔 수 있습니다.

설정 관리 및 주요 문제 해결

계층별 문제 해결 순서 세우기

문제 진단은 “기본 네트워크, 클라이언트 프로세스, 코어 시작, 노드 연결, 트래픽 적용, 라우팅 및 DNS, 대상 앱” 순서로 계층별 진행해야 합니다. 먼저 기기가 현재 네트워크에 연결되고 인증 네트워크 로그인이 완료되었는지 확인하세요. 다음으로 클라이언트가 시스템에 의해 종료되지 않았고 코어 프로세스가 로컬 수신 대기를 만들었는지 확인합니다. 그 후 노드 연결을 검증하고 마지막으로 시스템 프록시, TUN, 앱별 규칙, 대상 프로그램의 동작을 점검하세요. 각 계층을 통과한 뒤 다음 단계로 넘어가야 노드가 실패했을 때 DNS를 반복해서 바꾸거나 앱이 프록시에 들어오지 않았는데 노드를 무작정 전환하는 일을 피할 수 있습니다.

로그가 가장 중요한 근거입니다. 시작 단계의 설정 파싱 오류는 보통 필드나 형식 문제를 가리킵니다. 수신 실패는 포트 사용 또는 권한 부족이 흔한 원인이고, 도메인 해석 오류는 연결 대상에 도달하기 전에 발생합니다. 연결 시간 초과는 주소, 포트, 회선 또는 원격 상태 때문일 수 있으며, TLS, REALITY, WebSocket, gRPC 핸드셰이크 오류는 해당 보안 계층과 전송 계층 매개변수를 확인해야 합니다. 마지막 한 줄만 잘라내기보다 오류가 발생한 단계를 기록하는 편이 훨씬 유용합니다.

구독 업데이트 실패 또는 노드가 표시되지 않음

구독 업데이트에 실패하면 먼저 구독 설정에서 링크가 완전한지, 공백이나 줄바꿈이 포함되지 않았는지 확인한 다음 업데이트 로그의 응답 상태와 파싱 결과를 확인하세요. 현재 네트워크에서 구독 주소에 접근할 수 없다면 기본 네트워크와 DNS를 먼저 확인합니다. 콘텐츠는 가져왔지만 파싱에 실패했다면 콘텐츠 형식이 클라이언트의 예상과 맞지 않는 것입니다. 일반 웹페이지 주소를 구독 링크로 사용하거나 이해하지 못하는 인코딩 내용을 수동으로 수정하지 마세요.

로그에는 업데이트 성공으로 표시되지만 목록에 노드가 없다면 현재 그룹 필터, 검색창, 구독 그룹 선택을 확인하세요. 이전 검색어가 새 노드를 모두 숨기고 있을 수 있습니다. 노드가 나타난 뒤 곧 사라진다면 다음 업데이트에서 서버가 새 목록을 반환하며 이전 항목을 제거했을 가능성이 있습니다. 수동으로 보관할 설정은 로컬 그룹으로 복사해 구독 동기화에 덮어써지지 않게 하세요. 여러 기기의 결과가 다르면 각 기기의 마지막 업데이트 시각과 사용 중인 클라이언트 코어를 비교하고 노드 메모만 비교하지 마세요.

연결은 성공했지만 앱이 접속하지 못함

클라이언트에 연결됨으로 표시되어도 대상 앱이 반드시 프록시에 들어간 것은 아닙니다. 데스크톱 시스템 프록시 모드에서는 시스템 프록시를 따르는 브라우저로 먼저 확인하세요. 명령줄 도구는 환경 변수나 자체 프록시 매개변수를 확인하고, Android는 앱별 프록시 목록을 점검해야 합니다. TUN 모드에서는 가상 인터페이스와 라우팅을 확인하세요. 로그에 대상 앱의 요청이 전혀 없으면 문제는 적용 계층에 있습니다. 로그에 요청이 나타나 프록시 아웃바운드로 향한다면 대상 도메인 해석, 노드 회선, 앱 프로토콜을 계속 확인합니다.

일부 웹사이트만 이상할 때는 전역 모드로 임시 비교하세요. 전역 모드가 정상이라면 규칙 매칭과 DNS를 확인하고, 여전히 이상하면 같은 구독의 다른 노드로 테스트해 노드와 로컬 설정을 구분합니다. 속도가 느릴 때는 노드 자체, 중간 회선, 로컬 설정의 세 계층으로 나누어 처리하고 여러 “최적화” 옵션을 동시에 켜지 마세요. 전체적인 계층별 방법은 V2Ray 속도 저하 단계별 문제 해결에서 확인할 수 있습니다.

시작 실패, 포트 충돌 및 남은 프록시 설정

코어가 시작 직후 중지되면 먼저 로컬 포트 사용 여부를 확인하세요. 다른 프록시 클라이언트와 중복 실행된 v2rayN 인스턴스를 종료한 뒤 이전 코어 프로세스가 남아 있는지 확인합니다. 포트를 변경했다면 시스템 프록시나 환경 변수에서 참조하는 포트도 함께 변경해야 합니다. 한쪽만 바꾸면 시스템은 계속 이전 주소에 연결합니다. 권한 오류가 있으면 프로그램 디렉터리 쓰기 권한, 코어 파일 실행 권한, TUN 작업에 필요한 승인 여부를 확인하세요. 설정 디렉터리를 읽기 전용 매체나 자동으로 되돌아가는 임시 위치에 두지 마세요.

클라이언트가 비정상 종료된 뒤에도 시스템 프록시가 로컬 수신 포트를 가리킬 수 있습니다. 시스템 프록시를 따르는 모든 프로그램이 접속하지 못하다가 프록시를 끄면 즉시 복구되는 것이 대표적인 증상입니다. 이때 운영체제 네트워크 설정에서 프록시를 해제하거나 클라이언트를 다시 연 뒤 “시스템 프록시 해제”를 실행하세요. TUN이 남아 있다면 가상 인터페이스와 라우팅이 해제되었는지 확인하고, 필요하면 클라이언트를 정상적으로 시작한 뒤 연결을 끊으세요. 기기를 재부팅하면 일부 임시 상태를 정리할 수 있지만, 복구 후에는 비정상 종료의 로그 원인을 계속 찾아야 합니다.

클라이언트, 코어 및 설정 업데이트 주기

관리할 때 세 가지 업데이트를 동시에 진행하지 마세요. 현재 작동하는 노드, 라우팅 모드, 적용 방식을 기록한 뒤 클라이언트만 업데이트하고 실행을 확인합니다. 그 다음 필요에 따라 코어를 업데이트하고 기존 노드를 검증한 뒤 마지막으로 구독을 업데이트하세요. 어느 단계에서 문제가 생겼는지 명확해져 이전 단계로 돌아가 점검할 수 있습니다. 클라이언트 업데이트 전에는 프로그램을 정상 종료하고, Android 업데이트 전에는 VPN 서비스를 먼저 끊으세요. 데스크톱에서 복구용으로 여러 버전을 보관한다면 서로 다른 디렉터리를 사용하고 동시에 하나의 인스턴스만 실행해야 합니다.

이미 만료된 로컬 사본, 중복 구독, 장기간 사용하지 않는 사용자 지정 규칙을 정기적으로 정리하세요. 규칙이 많을수록 우선순위 충돌을 판단하기 어렵습니다. 안정적인 설정은 설명 가능하게 유지해야 합니다. 각 구독의 출처, 현재 코어를 선택한 이유, 시스템 프록시나 TUN을 켠 이유, 직접 연결을 담당하는 규칙을 알고 있어야 합니다. 처음 설치와 기본 설정은 v2rayN 최초 설치 설정 가이드와 함께 확인할 수 있습니다. 가장 짧은 절차를 다시 진행하고 싶다면 빠른 시작 가이드로 돌아가세요.