V2Ray 설치·설정 가이드

설정 전 확인 사항

공통 준비 사항: 플랫폼과 설정 출처 확인

클라이언트, 코어, 서버 설정 구분하기

데스크톱에서는 Windows, macOS, Linux를 지원하는 v2rayN을 우선 고려하세요. Android에서는 Xray 코어를 사용하는 v2rayNG를 권장하며, V2Fly 코어 생태계가 필요할 때 v2flyNG를 선택할 수 있습니다. 그래픽 클라이언트는 설정 저장, 구독 업데이트, 실행 매개변수 생성, 코어 제어를 담당하고 실제 연결은 코어 프로세스가 처리합니다. 클라이언트를 설치해도 사용할 수 있는 서버나 구독이 자동으로 제공되지는 않습니다. 시작하기 전에 합법적으로 제공받았고 유효 기간이 남은 설정을 준비하고, 지원되는 프로토콜과 전송 방식 조합을 확인하세요.

서버 주소, 포트, 사용자 식별자, 전송 방식, 보안 설정은 한 세트로 맞춰야 합니다. 프로토콜 이름이 같다는 이유로 다른 설정의 TLS, 경로 또는 서버 이름을 임의로 조합하면 안 됩니다. 특히 VLESS, Trojan 등의 설정에서 인증 항목과 외부 보안 매개변수는 각각 역할이 다르므로 하나라도 빠지면 연결 시간 초과가 발생할 수 있습니다. 가져오지 못하는 링크가 있다면 먼저 단일 서버 공유 링크인지, 구독 주소인지, 전체 설정 파일인지 확인한 다음 알맞은 메뉴를 사용하세요. 같은 입력란에 반복해서 붙여 넣지 마세요.

기기 아키텍처, 시간, 네트워크 기본 상태 확인

다운로드 전에 시스템 정보를 확인하세요. Windows에서는 ‘시스템 종류’, macOS에서는 ‘이 Mac에 관하여’의 칩 정보를 확인하고, Linux에서는 프로세서 아키텍처와 배포판의 패키지 형식을 모두 확인하세요. 최신 Android 기기는 대체로 arm64를 사용하지만 실제 지원 ABI를 기준으로 판단해야 하며, 출시 연도만으로 단정할 수 없습니다. 설치 패키지 형식과 프로세서 아키텍처는 서로 다른 기준입니다. deb와 rpm은 패키지 관리 방식을, x64와 arm64는 실행 가능 여부를 결정합니다. 다운로드 페이지에서 두 조건이 모두 맞는 항목을 선택하세요.

시스템 자동 시간 동기화를 켜고 시간대가 올바른지 확인하세요. 시스템 시간이 틀리면 인증서 유효 기간 확인에 영향을 주고 시간 기반 인증이 실패할 수도 있습니다. 그런 다음 프록시를 끈 상태에서 평소 이용하는 웹사이트를 열어 기본 네트워크가 정상인지 확인하세요. 기본 연결에 문제가 있으면 먼저 Wi-Fi, 게이트웨이 또는 네트워크 로그인 페이지를 점검해야 합니다. 테스트 중에는 다른 프록시와 VPN 도구를 잠시 종료해 동일한 시스템 설정이 여러 번 덮어쓰이지 않도록 하세요. 회사 기기에는 관리자가 배포한 프록시 정책이 적용될 수 있으므로 버튼을 반복해서 전환하는 것으로 해결되지 않습니다.

되돌릴 수 있는 초기 상태 만들기

처음 실행할 때는 설정 하나만 가져오고 서버 하나만 선택한 뒤 클라이언트의 기본 라우팅을 사용하세요. TUN, 사용자 지정 DNS, 원격 규칙, 실험 옵션을 한꺼번에 켜지 마세요. 설정을 하나씩 바꿀 때마다 같은 테스트 대상을 확인하고 변경 전후의 차이를 기록하세요. 이렇게 하면 문제 원인을 방금 변경한 계층으로 좁힐 수 있습니다. 본격적으로 조정하기 전에 현재 설정을 저장하거나 화면을 캡처하되, 구독 주소와 사용자 식별자, 인증 항목은 가리세요. 링크처럼 보이는 정보도 계정 접근 권한을 포함할 수 있습니다.

마지막으로 검증 기준을 정하세요. 브라우저에서 대상 페이지가 열리는지, 클라이언트 로그에 해당 연결이 기록되는지, 직접 연결해야 하는 사이트는 계속 이용할 수 있는지 확인합니다. 지연 시간 테스트가 한 번 성공했다고 해서 웹페이지, DNS 또는 모든 앱의 설정까지 완료된 것은 아닙니다. 아래 플랫폼별 안내는 ‘설치, 가져오기, 트래픽 처리, 검증’ 순서로 구성되어 있습니다. 해당 플랫폼 섹션으로 바로 이동할 수 있지만, 기본 상태 확인은 생략하지 마세요.

데스크톱 / Windows

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

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

Windows 다운로드 페이지에서 v2rayN을 선택하세요. 데스크톱 버전은 최신 크로스 플랫폼 인터페이스를 사용하고 클래식 WPF 버전은 기존 Windows 데스크톱 인터페이스를 사용합니다. 사용 습관과 실제 호환성을 고려해 하나를 선택하고, 연결 상태를 비교하려고 두 버전을 동시에 실행하지 마세요. 다운로드 페이지에서 제공하는 x64 설치 파일은 해당 시스템 아키텍처에 맞습니다. 실행 전에 설치 프로그램의 안내를 읽고, 시스템에 실행 구성 요소가 없으면 클라이언트나 설치 프로그램의 설명에 따라 추가하세요. 출처가 불분명한 곳에서 같은 이름의 동적 링크 파일을 내려받아 프로그램 파일을 덮어쓰지 마세요.

설치 후에는 일반 사용자 권한으로 먼저 실행하세요. 기본 창이 열린다고 코어까지 실행된 것은 아닙니다. 로그 영역에서 설정 로드 및 로컬 인바운드 리스닝 상태를 확인하세요. 프로그램 파일과 사용자 데이터는 서로 다른 디렉터리에 저장될 수 있으므로 업데이트하거나 옮기기 전에 클라이언트가 지원하는 내보내기 기능으로 설정을 보존하세요. 임시 압축 해제 폴더에서 실행한 뒤 임의로 삭제하거나, 프로그램 실행 중 디렉터리 전체를 이동하지 마세요. 다음 실행 때 코어, 규칙 파일 또는 저장된 설정을 찾지 못할 수 있습니다.

구독 가져오기 및 활성 서버 지정

구독 그룹 또는 구독 관리 메뉴를 열고 알아보기 쉬운 그룹 이름을 추가하세요. 전체 구독 주소를 주소 입력란에 넣어 저장한 다음 업데이트를 실행합니다. 단일 공유 링크라면 클립보드에서 가져오기 등 해당 기능을 사용하고 구독 그룹을 만들 필요는 없습니다. 업데이트 후 목록에 원하는 설정이 나타나는지 확인한 다음 더블 클릭하거나 활성 서버로 지정하는 메뉴를 사용하세요. 목록에 서버가 있다는 것과 실제로 사용 중인 것은 다릅니다. 활성 표시와 코어 실행 상태를 함께 확인하세요.

구독 업데이트에 실패하면 로그에서 파싱 오류, 인증 실패, 요청 시간 초과 중 무엇인지 먼저 확인하세요. 첫 연결을 아직 설정하지 못한 상태에서 프록시를 통해 업데이트하면 순환 의존성이 생길 수 있습니다. 이때는 직접 연결로 업데이트하거나 설정 제공자가 허용하는 다른 가져오기 방법을 시도하세요. 목록을 채우려고 모든 보안 검사를 끄지 마세요. 업데이트는 성공했지만 목록이 비어 있다면 그룹 필터, 계정 유효성, 응답 형식을 확인하고, 복사 과정에서 구독 주소에 줄바꿈이나 끝 문장부호가 들어가지 않았는지도 살펴보세요.

시스템 프록시부터 사용하고 TUN은 필요할 때 켜기

서버를 선택한 뒤 시스템 프록시를 ‘시스템 프록시 자동 설정’ 또는 실제 화면에서 같은 의미를 가진 옵션으로 설정하세요. Windows 시스템 프록시 설정을 따르는 앱은 로컬 프록시를 이용하지만 모든 네트워크 프로그램이 처리되는 것은 아닙니다. 브라우저는 확장 프로그램이나 자체 프록시 설정의 영향을 받을 수 있고, 명령줄 도구는 시스템 프록시를 읽지 않는 경우가 많습니다. 이때 바로 서버를 바꾸지 말고 요청을 보낼 때 클라이언트 로그에 연결이 기록되는지 확인해 요청이 로컬 인바운드에 들어왔는지 살펴보세요.

더 많은 앱의 트래픽을 처리해야 할 때 TUN을 켜고 프로그램 안내에 따라 필요한 권한을 부여하세요. TUN은 가상 네트워크 인터페이스, 라우팅, DNS를 다루며 시스템 프록시 버튼과 같은 기능이 아닙니다. 첫 테스트에서는 시스템 프록시를 끄고 한 가지 트래픽 처리 방식만 유지해 확인한 다음, 클라이언트 권장에 따라 조합 설정을 사용하세요. 드라이버, 가상 네트워크 어댑터, 라우팅 오류가 발생하면 로그를 기록하고 권한과 다른 VPN 소프트웨어를 확인하세요. 문제를 찾는 대신 방화벽 전체를 끄지 마세요.

확인 및 종료 후 복구

브라우저에서 프록시가 필요한 대상과 직접 연결해야 하는 대상을 차례로 열고 로그의 아웃바운드 선택을 비교하세요. 브라우저는 되지만 터미널은 안 된다면 시스템 프록시와 터미널을 따로 점검하는 방법을 확인하세요. 앱별 차이를 서버 문제로 단정하지 마세요. 사용을 마치기 전에 시스템 프록시를 해제한 다음 클라이언트를 종료하세요. 비정상 종료 후 브라우저에 프록시 연결 오류가 표시되면 Windows 네트워크 프록시 설정에서 중지된 로컬 포트를 가리키고 있는지 확인하세요. 설정을 복구한 뒤 클라이언트를 다시 시작해 테스트합니다.

데스크톱 / macOS

macOS: 칩 선택, 권한 및 네트워크 서비스

칩에 맞는 v2rayN 설치

macOS 다운로드 페이지에서 Apple Silicon 기기는 arm64, Intel 기기는 x64를 선택하세요. 칩 정보는 ‘이 Mac에 관하여’에서 확인할 수 있습니다. 제품 외관이나 모델명만 보고 판단하지 마세요. DMG 파일을 다운로드해 디스크 이미지를 연 다음 설치 화면의 안내에 따라 앱을 ‘응용 프로그램’ 폴더로 옮기고, 설치된 위치에서 실행하세요. 디스크 이미지 안에서 계속 실행하면 이미지를 추출하거나 프로그램을 업데이트하거나 재시동한 뒤 경로 및 권한 문제가 생기기 쉽고, 유지 관리도 어려워집니다.

처음 실행할 때 시스템 보안 정책에 의해 차단될 수 있습니다. 앱 출처와 선택한 플랫폼이 맞는지 확인한 다음 시스템 설정의 ‘개인정보 보호 및 보안’에서 열기 허용 항목이 있는지 살펴보세요. 관리 대상 기기에서는 사용자가 직접 허용할 수 없으므로 관리자에게 문의해야 합니다. 프로그램 하나를 실행하려고 기기 전체의 보안 기능을 끄거나, 이해하지 못하는 시스템 속성을 무더기로 삭제하지 마세요. 프로그램 아키텍처가 맞지 않는다는 알림이 표시되면 권한 문제로 단정하지 말고 다운로드 페이지에서 올바른 패키지를 다시 선택하세요.

설정 가져오기 및 코어 상태 확인

v2rayN에서 구독 그룹을 만들고 주소를 저장해 업데이트한 뒤 설정 하나를 활성 서버로 지정하세요. 단일 공유 링크는 클립보드에서 가져오기 메뉴를 사용하고, 전체 파일을 가져올 때는 현재 클라이언트에 맞는 파일인지 먼저 확인하세요. 코어 전용 JSON 파일을 구독 주소로 입력하면 안 됩니다. 설정을 가져온 뒤 실행 로그에서 코어가 곧바로 종료되지 않는지 확인하세요. 일부 문제는 백그라운드 프로세스에만 영향을 주어 기본 창을 계속 사용할 수 있으므로, ‘화면이 열림’만으로 설치가 완료됐다고 판단할 수 없습니다.

기본 또는 초기 라우팅으로 먼저 연결을 테스트한 다음 DNS와 분할 라우팅을 하나씩 조정하세요. 코어를 바꾸기 전에 선택한 프로토콜과 전송 방식이 해당 코어에서 지원되는지 확인하세요. 설정 표시 이름이 같아도 생성되는 매개변수가 완전히 호환되는 것은 아닙니다. 전환 후 알 수 없는 필드나 설정 파싱 오류가 발생하면 기존 코어로 되돌리고 클라이언트가 생성한 설정 관련 안내를 확인하세요. 사용자 인터페이스와 수동 설정을 번갈아 덮어쓰면 다음 저장 때 변경 사항이 취소될 수 있습니다.

시스템 프록시와 네트워크 서비스의 관계

macOS 프록시 설정은 네트워크 서비스별로 적용됩니다. 시스템 프록시를 켠 뒤 현재 Wi-Fi, 유선 네트워크 또는 다른 서비스 중 무엇을 사용 중인지 확인하세요. 인터페이스를 전환한 후 일부 앱만 직접 연결로 돌아온다면 새 네트워크 서비스에 해당 설정이 없을 수 있습니다. 시스템 설정의 HTTP, HTTPS, SOCKS 프록시 항목도 각각 의미가 다릅니다. 주소가 모두 로컬이라고 해서 포트를 바꿔 써도 되는 것은 아닙니다. 클라이언트가 자동으로 설정할 때는 먼저 자동 생성된 값을 유지하고 연결을 확인한 뒤 필요한 부분만 수동 조정하세요.

브라우저는 시스템 프록시를 따를 수 있지만 확장 프로그램이나 앱 자체의 네트워크 옵션이 이를 덮어쓸 수도 있습니다. 터미널 프로그램은 대개 자체 프록시 매개변수나 환경 변수가 필요하며, 메뉴 막대에 프록시가 켜져 있다고 동작이 자동으로 바뀌지는 않습니다. 네트워크를 전환한 뒤에는 기존 연결이 이전 경로를 계속 사용할 수 있으므로 테스트 연결을 새로 시작하세요. 같은 대상으로 새 요청을 보내고 로그를 확인해 페이지 캐시, 기존 연결, 앱의 백그라운드 재시도를 현재 설정이 적용된 것으로 오인하지 않도록 하세요.

TUN 권한, 잠자기 및 복구

TUN이 필요하면 클라이언트 안내에 따라 권한을 요청하세요. 가상 인터페이스 생성과 라우트 변경에는 추가 권한이 필요한 경우가 많으며, 구체적인 방법은 현재 프로그램 구현에 따라 달라집니다. 활성화 후 네트워크 전체가 끊기면 먼저 TUN을 꺼서 연결을 복구하고, 로그에서 인터페이스 생성, 라우트 등록, DNS 오류를 확인하세요. 다른 VPN의 전체 트래픽 처리 기능을 함께 켜서 해결하려고 하지 마세요. 기본 경로를 두 서비스가 놓고 경쟁하면 문제를 재현하기 더 어려워질 수 있습니다. 업무용 기기의 보안 소프트웨어가 이런 네트워크 작업을 제한할 수도 있습니다.

종료하기 전에 시스템 프록시를 해제하고 브라우저가 직접 연결로 돌아오는지 확인하세요. 앱을 종료했는데도 웹페이지에 로컬 프록시 연결 오류가 표시되면 현재 네트워크 서비스의 프록시 설정에 남은 항목이 있는지 살펴보세요. 첫 단계부터 네트워크 서비스를 삭제하거나 전체 네트워크 설정을 재설정하지 마세요. 구독과 라우팅 설정은 보존하고 트래픽 처리 설정만 복구하면 영향을 최소화할 수 있습니다. 복구를 확인한 뒤 클라이언트 기능을 하나씩 다시 켜서 테스트하세요.

데스크톱 / Linux

Linux: 패키지, 데스크톱 프록시 및 실행 권한

아키텍처와 배포판 패키지 형식 맞추기

Linux에서 v2rayN 데스크톱 클라이언트를 사용하려면 먼저 Linux 다운로드 페이지에서 deb와 rpm 중 하나를 고른 뒤 x64 또는 arm64를 선택하세요. Debian, Ubuntu 계열은 보통 deb를 사용하고 Fedora 계열은 대개 rpm을 사용하지만, 실제 패키지 관리 시스템을 기준으로 확인해야 합니다. 다음 읽기 전용 명령으로 아키텍처와 시스템 정보를 확인할 수 있습니다. 출력의 x86_64는 일반적으로 x64, aarch64는 일반적으로 arm64에 해당합니다. 다른 형식으로 설치해 보려고 파일 확장자를 바꾸지 마세요.

uname -m
cat /etc/os-release

다운로드한 패키지는 데스크톱 소프트웨어 설치 프로그램으로 열거나 배포판 문서에 따라 패키지 관리자로 설치할 수 있습니다. 의존성이 없다는 오류가 나면 패키지 관리자가 표시한 항목을 확인한 다음 현재 데스크톱 환경과 시스템 버전이 요구 사항을 충족하는지 판단하세요. 다른 배포판의 시스템 라이브러리를 시스템 디렉터리에 복사하지 마세요. 설치 실패와 클라이언트 설정 실패는 서로 다른 단계입니다. 먼저 패키지, 의존성, 아키텍처 문제를 해결하고, 이후 구독과 코어 매개변수를 확인하세요. 두 문제를 한꺼번에 다루면 변수가 더 늘어납니다.

일반 사용자로 실행하고 설정 가져오기

설치 후 앱 메뉴에서 v2rayN을 실행하고 일반 사용자 권한으로 구독 그룹, 주소 저장, 업데이트를 진행하세요. 업데이트가 끝나면 활성 서버를 선택하고 코어 로그가 리스닝 상태에 들어갔는지 확인하세요. 데스크톱 아이콘을 눌러도 기본 창이 열리지 않으면 데스크톱 환경의 앱 로그 메뉴에서 오류를 확인하세요. 곧바로 관리자 권한으로 전체 인터페이스를 실행하지 마세요. 실행 권한이 달라지면 데이터 디렉터리와 파일 소유자가 달라져 이후 일반 사용자가 기존 설정을 수정하지 못할 수 있습니다.

높은 권한으로 실행해 설정 파일을 쓸 수 없게 됐다면 프로그램을 종료하고 실제 데이터 디렉터리를 확인한 뒤 시스템 관리 방법에 따라 해당 디렉터리의 소유자를 수정하세요. 홈 디렉터리 전체에 재귀적으로 권한을 넓게 부여하지 마세요. 구독 주소와 내보낸 설정은 민감한 데이터이므로 필요한 계정만 디렉터리에 접근할 수 있도록 제한하세요. 클라이언트를 업데이트할 때 사용자 데이터는 보존하고, 업데이트 후 코어 경로와 규칙 파일을 찾을 수 있는지 확인하세요. 그래픽 프로그램이 정상적으로 업데이트되어도 기존 외부 경로가 계속 유효하다는 보장은 없습니다.

데스크톱 시스템 프록시의 적용 범위 이해

Linux에는 모든 프로그램이 공유하는 단일 시스템 프록시 스위치가 없습니다. GNOME, KDE 등의 데스크톱 환경은 자체 프록시 설정을 사용하고 앱에 따라 환경 변수, 별도 설정 파일 또는 실행 매개변수만 읽을 수도 있습니다. v2rayN이 데스크톱 프록시를 정상적으로 변경해 브라우저에서는 연결되더라도 터미널 요청은 직접 연결될 수 있습니다. 이때는 먼저 앱별 동작 차이를 확인하세요. 요청이 클라이언트로 들어오는지 확인한 뒤 개별 도구를 설정할지, 더 많은 트래픽을 처리하는 TUN을 사용할지 결정하세요.

아래 명령은 로컬 SOCKS 인바운드를 통해 예시 사이트에 요청하므로 ‘도구에서 로컬 프록시까지’의 연결을 확인할 수 있습니다. 포트는 클라이언트 설정에 표시된 실제 리스닝 포트로 바꾸세요. 예시의 socks5h는 대상 도메인 이름을 프록시 측에서 해석한다는 뜻입니다. 테스트가 성공해도 지정한 인바운드를 통한 해당 요청만 확인된 것이며, 데스크톱 시스템 프록시나 다른 터미널, 모든 앱에 설정이 적용됐다고 볼 수는 없습니다. 연결 거부 오류가 나오면 먼저 코어 실행 여부와 포트가 일치하는지 확인하세요.

curl --proxy socks5h://127.0.0.1:10808 --head https://example.com

TUN 권한 및 네트워크 관리 기능 충돌

TUN은 가상 네트워크 장치에 접근하고 관련 라우트를 관리해야 합니다. 권한 부여 방법은 클라이언트 패키징과 시스템 정책에 따라 다르므로 프로그램에서 제공하는 권한 절차를 우선 사용하세요. 설치 디렉터리 전체에 임의로 높은 권한을 부여하지 마세요. 활성화에 실패하면 가상 장치 사용 가능 여부, 권한 거부 여부, 기본 라우트가 다른 VPN과 충돌하는지 각각 확인하세요. 컨테이너나 제한된 데스크톱 세션에는 필요한 장치나 권한이 없을 수 있습니다. 스위치를 반복해서 누르는 것만으로는 해결할 수 없으며 기기 전체의 보안 경계를 완화해서도 안 됩니다.

Linux에서는 시스템 이름 해석 서비스와 클라이언트 DNS의 경계도 확인해야 합니다. 시스템은 로컬 스텁 리졸버로 쿼리를 처리할 수 있고, TUN은 또 다른 해석 경로를 인계받을 수 있습니다. 도메인 접속만 실패하면 시스템 이름 해석과 프록시 요청을 먼저 비교하세요. 네트워크 관리자, 이름 해석 서비스, 클라이언트 설정을 동시에 바꾸지 마세요. 종료 후 데스크톱 프록시와 임시 환경 변수가 복구됐는지 확인하세요. 특정 터미널에서만 문제가 생기면 클라이언트를 재설치하는 대신 해당 터미널의 세션 변수를 확인하세요.

모바일 / Android

Android: VPN 권한 및 백그라운드 실행

v2rayNG 또는 v2flyNG 선택

Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 권장하며, V2Fly 코어 생태계가 필요하면 v2flyNG를 선택할 수 있습니다. 두 클라이언트는 Android 다운로드 페이지에서 arm64 및 범용 설치 패키지를 제공합니다. 최신 기기는 대부분 arm64에 적합하지만 시스템 비트 수와 기기 지원 여부를 실제로 확인해야 합니다. 판단하기 어렵다면 범용 패키지를 고려하세요. 두 앱의 인터페이스가 비슷하다고 설정 기능까지 동일한 것은 아닙니다. 지원되는 프로토콜, 전송 방식, 보안 매개변수는 각 코어에 따라 달라집니다.

APK를 설치할 때 Android에서 브라우저나 파일 관리자가 앱을 설치하도록 허용해야 할 수 있습니다. 이번에 사용하는 출처에 필요한 권한만 부여하고 설치를 마친 뒤에는 취소할 수 있습니다. 앱을 설치할 수 없다는 알림이 나오면 먼저 기기 아키텍처, 저장 공간, 기존 앱과의 서명 충돌을 확인하세요. 덮어쓰기 설치 실패가 항상 패키지 손상을 의미하지는 않습니다. 재설치하기 전에 클라이언트 기능으로 필요한 설정을 백업하세요. 앱을 삭제하면 그룹, 라우팅, 앱 선택이 지워질 수 있으므로 재설치 후 자동으로 복구된다고 가정하지 마세요.

구독 가져오기 및 첫 VPN 권한 승인

구독 설정을 열어 그룹을 추가하고 전체 주소를 입력한 뒤 저장하세요. 목록으로 돌아와 구독을 업데이트하고 사용할 서버를 선택합니다. 단일 공유 링크는 클립보드나 QR 코드 메뉴에서 가져올 수 있지만, QR 코드에도 계정 정보가 포함될 수 있으므로 공개 플랫폼에 공유하지 마세요. 가져온 뒤 프로토콜과 필수 항목을 확인하고 메모 이름만 보지 마세요. 그룹이 여러 개라면 현재 필터가 새로 가져온 설정을 숨기지 않는지 확인하세요. 업데이트가 끝나도 활성 서버가 자동으로 바뀌는 것은 아닙니다.

연결을 누르면 시스템에 VPN 연결 승인 화면이 표시됩니다. 승인해야 클라이언트가 Android VpnService를 통해 트래픽을 처리할 수 있습니다. VPN 아이콘이 나타난다는 것은 시스템 인터페이스가 만들어졌다는 뜻일 뿐, 원격 서버 인증이 완료됐거나 웹페이지가 반드시 열린다는 뜻은 아닙니다. 클라이언트 로그를 확인하고 테스트 대상에 직접 접속해 보세요. 일반 앱은 시스템 VPN 연결을 하나만 활성화할 수 있는 경우가 많습니다. 다른 VPN, 광고 차단 또는 네트워크 보호 앱이 이를 사용 중일 수 있으므로 먼저 사용할 앱을 정한 다음 다시 연결하세요.

라우팅, 앱별 프록시 및 로컬 인바운드

먼저 클라이언트의 기본 라우팅으로 연결한 뒤 필요한 경우 앱별 프록시를 설정하세요. 화면마다 ‘선택한 앱을 프록시로 연결’과 ‘선택한 앱 우회’의 의미가 반대로 표시될 수 있으므로 저장 전에 현재 모드를 확인해야 합니다. 브라우저를 선택할 때는 페이지가 외부 앱, 다운로드 관리자, 시스템 서비스를 호출하는지도 고려하세요. 이 구성 요소들이 브라우저와 같은 앱으로 처리되지 않을 수 있습니다. 특정 앱 문제를 확인할 때는 잠시 트래픽 처리 범위를 넓혀 보세요. 이때 정상 작동한다면 범위를 하나씩 줄이며 누락된 항목을 찾을 수 있습니다.

Android의 VPN 트래픽 처리는 데스크톱의 시스템 HTTP 프록시와 다르므로 일반적으로 Wi-Fi 고급 설정에 로컬 프록시를 다시 입력할 필요가 없습니다. Wi-Fi 프록시를 추가로 설정하면 클라이언트가 중지된 뒤 네트워크에 문제가 생길 수 있습니다. 클라이언트에 표시된 로컬 SOCKS 포트는 프록시를 명시적으로 설정해야 하는 프로그램을 위한 것이며, 로컬 네트워크의 다른 기기에서 기본적으로 접근할 수 있다는 뜻은 아닙니다. 테스트 편의를 위해 수신 주소를 모든 인터페이스로 바꾸지 마세요. 기기 간 공유에는 접근 제어, 네트워크 분리, 권한과 관련된 새로운 문제가 생깁니다.

배터리 관리, 네트워크 전환 및 연결 복구

화면이 켜져 있을 때는 정상인데 잠금 상태로 일정 시간 지난 뒤 연결이 끊기면 배터리 최적화와 백그라운드 실행 제한부터 확인하세요. 제조사와 시스템 버전에 따라 메뉴 위치가 다를 수 있습니다. 앱 정보에서 필요한 백그라운드 실행을 허용하고, 필요하면 알림을 계속 표시하도록 설정하세요. 절전 예외에 추가하면 백그라운드에서 정리될 가능성은 낮아지지만 잘못된 서버나 DNS 설정까지 해결되는 것은 아닙니다. 화면이 꺼졌을 때 로그가 멈추고 앱을 다시 열자마자 복구된다면 백그라운드 관리가 원인일 가능성이 높습니다. 지속적인 핸드셰이크 오류와 구분하세요.

모바일 데이터와 Wi-Fi를 전환한 뒤에는 먼저 기본 네트워크에 로그인이 완료됐는지 확인하고 연결을 다시 설정하세요. 네트워크에 따라 UDP, 도메인 해석, 대상 포트 처리가 다를 수 있으므로 한 네트워크의 결과만으로 서버 상태를 단정하지 마세요. 백그라운드에서만 연결이 끊긴다면 v2rayNG 배터리 최적화 및 앱별 설정을 확인하세요. 두 네트워크에서 모두 페이지가 열리지 않으면 앱을 계속 재설치하지 말고 문서 끝의 로그 계층별 점검 방법을 따르세요.

크로스 플랫폼 / 설정 관리

구독 관리: 업데이트, 선택, 백업

구독 주소와 공유 링크 구분하기

구독 주소는 일반적으로 네트워크 요청을 통해 여러 서버 설정을 반환하고, 단일 공유 링크는 서버 하나를 직접 설명합니다. 둘 다 클립보드에 복사할 수 있지만 처리 방식은 다릅니다. 구독은 업데이트할 수 있도록 그룹에 저장하고, 공유 링크는 해당 링크를 가져오는 메뉴로 파싱하세요. 웹페이지 주소가 항상 구독 주소인 것은 아닙니다. 계정 관리 페이지, 안내 페이지, 로그인 리디렉션 주소는 설정 출처로 바로 사용할 수 없습니다. 업데이트 후 파싱 오류가 로그에 표시되면 주소의 용도와 반환 형식을 설정 제공자에게 먼저 확인하세요.

구독 주소에는 접근 자격 정보가 포함되는 경우가 많으므로 이를 얻은 사람이 같은 계정의 리소스에 접근할 수 있습니다. 전체 주소를 공개 피드백, 온라인 파서, 스크린샷에 올리지 마세요. 문제를 설명할 때는 오류 유형, 클라이언트 이름, 민감하지 않은 필수 매개변수만 남기세요. QR 코드, 내보낸 파일, 백업 디렉터리도 같은 원칙으로 다뤄야 합니다. 주소가 유출됐다면 설정 제공자가 지원하는 관리 메뉴에서 새 주소를 만들거나 기존 주소를 폐기하세요. 로컬 기록만 삭제해도 외부에 복사된 주소는 무효화되지 않습니다.

업데이트 경로와 실제 사용 경로 구분하기

직접 연결 업데이트와 프록시를 통한 업데이트는 구독 요청이 어떤 경로로 전송되는지를 결정할 뿐, 서버의 라우팅 모드를 뜻하지는 않습니다. 사용할 수 있는 서버가 없는 초기 상태에서는 프록시 업데이트를 시작하지 못할 수 있습니다. 기존 연결은 되지만 구독 서비스에 직접 접속할 수 없는 경우에 프록시 업데이트가 필요할 수 있습니다. 선택할 때는 요청 시간 초과, 인증 거부, 콘텐츠 파싱 실패를 구분하세요. 인증 오류가 명확히 반환되면 업데이트 경로를 바꿔도 해결되지 않는 경우가 많으므로 계정 권한과 주소 유효성을 먼저 확인하세요.

업데이트에 실패해도 기존 목록을 곧바로 지우지 마세요. 계속 쓸 수 있는 설정은 남겨 두고 그룹과 오류 정보를 기록한 다음 현재 네트워크에서 구독 서비스에 접근할 수 있는지 확인하세요. 일부 클라이언트는 이전 설정을 유지하지만 업데이트 과정에서 그룹 항목을 새로 만들 수도 있으므로 화면 안내와 실제 결과를 확인해야 합니다. 구독으로 생성된 항목을 직접 수정할 때는 특히 주의하세요. 다음 업데이트 때 변경 사항이 덮어써질 수 있습니다. 장기간 사용자 지정 매개변수가 필요하다면 클라이언트가 지원하는 복사 기능이나 별도 관리 방식을 사용하세요.

업데이트 후에도 활성 항목 확인

구독 업데이트 성공은 가져오기와 파싱이 완료됐다는 의미일 뿐, 현재 활성 서버가 여전히 존재하거나 네트워크에 연결할 수 있다는 보장은 아닙니다. 업데이트 뒤 활성 표시, 프로토콜 유형, 그룹 필터를 확인하고 실제 요청을 보내세요. 메모 이름은 중복되거나 변경될 수 있으므로 이름만 보고 같은 설정인지 판단하지 마세요. 구독과 함께 항목의 포트, 전송 경로, 보안 매개변수가 바뀔 수도 있습니다. 업데이트 후 문제가 생기면 클라이언트가 새 실행 설정을 다시 불러왔는지 우선 확인하세요.

지연 시간 테스트, 연결 테스트, 실제 웹페이지 로딩은 서로 다릅니다. 테스트 대상, 이름 해석 방식, 탐색 프로토콜이 다르면 결과도 달라질 수 있습니다. 테스트에 응답한 서버라도 특정 사이트에 접속하지 못할 수 있습니다. 목록 정렬 후 첫 번째 항목이 모든 상황에 가장 적합하다고 가정하지 마세요. 설정 하나를 선택해 고정된 대상으로 페이지 로딩, 도메인 해석, 직접 연결 예외를 확인한 뒤 실제 사용 결과를 바탕으로 유지 여부를 결정하는 편이 낫습니다. 단일 테스트 수치에 의존하지 마세요.

설정 경계를 고려한 백업 및 이전

기기를 옮길 때는 클라이언트가 지원하는 설정과 환경 설정을 우선 내보내세요. 다른 플랫폼의 프로그램 디렉터리 전체를 그대로 덮어쓰지 마세요. 구독 주소는 다시 가져올 수 있지만 로컬 포트, 라우팅 규칙, 앱별 선택, 시스템 트래픽 처리 권한은 함께 이전되지 않을 수 있습니다. 특히 Android 앱 목록은 데스크톱 앱 경로와 직접 대응하지 않으므로 기기를 바꾼 뒤 다시 확인해야 합니다. 백업 파일은 접근 제어가 적용되는 위치에 보관하고, 개인 메모라는 이유로 전체 인증 정보를 공개 동기화 콘텐츠에 저장하지 마세요.

클라이언트별 구독 및 코어 지원 기능을 비교하려면 클라이언트 비교를 확인하세요. 출처와 형식을 확인하는 대신 클라이언트를 더 많이 설치하지 마세요. 구독 자체가 잘못된 콘텐츠를 반환한다면 그래픽 인터페이스를 바꿔도 같은 문제가 발생할 수 있습니다.

크로스 플랫폼 / 트래픽 경로

라우팅 및 DNS: 트래픽을 처리한 뒤 아웃바운드 결정

시스템 프록시, TUN, 코어 라우팅은 서로 다른 계층을 담당

분할 라우팅을 살펴보기 전에 요청이 클라이언트에 들어오는지 먼저 확인하세요. 시스템 프록시는 시스템 설정을 따르는 앱이 로컬 인바운드에 연결하도록 하고, TUN은 가상 네트워크 인터페이스를 통해 해당 트래픽을 처리합니다. 요청이 코어에 들어온 다음에는 라우팅 규칙에 따라 프록시, 직접 연결 또는 다른 정의된 아웃바운드가 선택됩니다. 앱이 시스템 프록시를 우회하면 코어 규칙을 바꿔도 효과가 없습니다. 반대로 요청이 코어에 들어왔지만 규칙에 따라 직접 연결된다면 브라우저 프록시 버튼을 계속 점검할 필요가 없습니다. 로그를 활용하면 두 상황을 구분할 수 있습니다.

‘전역’과 ‘규칙’은 클라이언트마다 서로 다른 계층에 표시될 수 있습니다. 시스템 프록시의 전역 설정은 보통 더 많은 요청을 로컬 프록시로 보내는 역할을 하지만, 코어는 여전히 규칙에 따라 아웃바운드를 선택할 수 있습니다. 일부 클라이언트의 전역 라우팅 모드는 코어의 분할 라우팅 자체를 변경합니다. 따라서 시스템 트래픽 처리 방식과 코어 라우팅 모드 중 무엇을 변경하는지 확인해야 합니다. 테스트할 때 트래픽 처리 방식은 고정한 채 라우팅만 비교하세요. 두 계층을 동시에 바꾸면 어떤 설정으로 요청이 복구되거나 실패했는지 알기 어렵습니다.

최소 규칙으로 매칭 순서 이해하기

아래는 Xray 형식의 일부 라우팅 예시로, 예시 도메인을 direct라는 아웃바운드로 보내는 방법만 보여 줍니다. 단독으로 실행할 수 있는 전체 설정이 아니므로 사용 전에 완성된 설정에 같은 이름의 아웃바운드를 정의해야 합니다. 실제 클라이언트는 다른 태그를 자동 생성할 수 있으니 생성된 결과에 맞춰 조정하세요. 라우팅은 보통 규칙을 순서대로 확인하며, 앞쪽의 범위가 넓은 규칙이 뒤쪽의 정밀 규칙보다 먼저 일치할 수 있습니다. 예외를 추가하기 전에 기존 규칙을 확인하고 같은 조건을 계속 반복해서 덧붙이지 마세요.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

정확한 도메인과 도메인 접미사 규칙의 적용 범위는 다릅니다. 기본 도메인에만 규칙을 추가하면 페이지에 필요한 이미지, 인증, API 도메인까지 포함되지 않을 수 있습니다. 페이지 본문은 열리지만 로그인이 실패한다면 실패한 요청의 도메인과 아웃바운드를 확인하세요. 네트워크 전체를 다른 모드로 바꾸지 마세요. IP 주소 규칙도 비슷한 한계가 있습니다. IPv4와 IPv6는 서로 다른 주소 계열이므로 한쪽만 처리해 다른 쪽 요청까지 예상대로 분할할 수는 없습니다.

시스템 이름 해석과 코어 DNS 구분하기

DNS는 도메인을 IP 주소로 변환하지만 시스템, 브라우저, 프록시 코어는 각각 다른 이름 해석 경로를 사용할 수 있습니다. 브라우저에서 자체 보안 DNS를 켜면 시스템 리졸버의 결과를 사용하지 않을 수 있습니다. 앱이 SOCKS 인바운드에 도메인 이름을 보내는지 이미 해석된 IP를 보내는지에 따라 코어에서 적용할 수 있는 도메인 조건도 달라집니다. 문제를 확인할 때는 도메인을 어느 계층에서 해석하는지, 쿼리가 어떤 아웃바운드로 전송되는지 먼저 파악한 다음 수정할 위치를 결정하세요. 모든 DNS를 한꺼번에 바꾸면 원인을 찾을 수 있었던 문제가 여러 변수에 얽히게 됩니다.

아래 예시는 코어 DNS 서버 배열과 쿼리 주소 계열 설정의 일부를 보여 줍니다. 서버 접근 가능 여부는 현재 네트워크, 라우팅, 클라이언트가 생성한 설정에 따라 달라지므로 특정 공개 DNS 주소를 모든 네트워크에서 쓸 수 있는 고정 해답으로 보지 마세요. 암호화 DNS 엔드포인트를 도메인으로 지정하는 경우 시작 시 해당 주소를 어떻게 얻을지도 고려해야 합니다. 아직 프록시 연결이 만들어지지 않았는데 이름 해석 요청이 프록시에 의존해 서로 기다리는 상황을 피하세요.

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

로컬 네트워크, IPv6, UDP 경계 확인

TUN을 켠 뒤 프린터, 로컬 네트워크 서비스, 관리 페이지에 접근할 수 없다면 사설 주소와 기기 내 서비스에 적절한 우회 규칙이 있는지 확인하세요. 로컬 네트워크 주소 하나를 해결하려고 모든 트래픽을 직접 연결로 설정하지 마세요. IPv6 환경에서는 앱이 실제로 어떤 주소 계열을 선택하는지도 살펴봐야 합니다. IPv4 테스트만 성공했다고 듀얼 스택 요청이 모두 정상이라고 볼 수 없습니다. 음성 통화, 게임 등 UDP를 사용하는 앱은 프로토콜, 서버, 트래픽 처리 방식이 해당 트래픽을 지원하는지도 함께 확인하세요.

조정이 끝나면 코어를 다시 불러오고 새 연결로 확인하세요. 기존 연결은 이전 아웃바운드를 계속 사용할 수 있으며 앱 캐시에 이전 DNS 결과가 남을 수도 있습니다. 로그를 보지 않고 같은 페이지를 새로고침하기만 하면 캐시 차이를 규칙 오류로 오해할 수 있습니다.

일반적인 설정 문제 / 계층별 점검

설정 문제 해결: 로컬 인바운드부터 원격 연결까지

현상을 먼저 기록하고 모든 설정을 한꺼번에 초기화하지 않기

문제 해결을 시작할 때 클라이언트 이름, 운영 체제, 사용 중인 코어, 트래픽 처리 방식, 실패한 대상을 기록하세요. 모든 앱에서 실패하는지 특정 브라우저나 터미널에서만 실패하는지도 적어 둡니다. 마지막으로 성공한 뒤 구독 업데이트, 네트워크 전환, 시스템 업그레이드, 라우팅 변경 중 무엇을 했는지도 기록하세요. 이 내용을 ‘연결됨, 그런데 안 됨’ 한마디로 줄이지 마세요. 현상을 구체적으로 적으면 원인을 찾기 쉽고, 로컬 포트가 아직 리스닝하지 않는데 원격 서버를 계속 바꾸거나 계정이 만료됐는데 DNS를 계속 바꾸는 일을 줄일 수 있습니다.

먼저 TUN과 시스템 프록시를 끄고 기본 네트워크가 정상인지 확인한 다음 트래픽 처리 방식 하나만 다시 켜세요. 끈 뒤에도 인터넷에 연결할 수 없다면 시스템에 로컬 프록시 주소가 남아 있는지, Android에서 VPN 외 트래픽 차단이 켜져 있는지, 네트워크 로그인이 필요한지 확인하세요. 직접 연결 상태가 복구되어야 이후 비교가 의미가 있습니다. 설정을 복구할 때는 구독과 기존 규칙 백업을 보존하세요. 모든 데이터를 삭제하는 것을 기본 조치로 삼으면 비교에 사용할 수 있는 유효한 설정까지 잃을 수 있습니다.

로그를 기준으로 실패 지점 찾기

로그에 리스닝 포트 충돌이 표시되면 중복 실행 중인 클라이언트나 같은 포트를 사용하는 프로그램을 먼저 종료한 뒤 로컬 포트를 바꿀지 판단하세요. 포트를 변경했다면 브라우저 확장 프로그램, 터미널 매개변수, 기타 프록시 직접 설정도 함께 업데이트해야 합니다. 연결 거부는 대상 인바운드가 리스닝하지 않을 때 흔히 발생합니다. 시간 초과는 정해진 시간 안에 연결이 완료되지 않았다는 뜻일 뿐, 이 메시지만으로 DNS, 네트워크, 서버 중 무엇이 원인인지 단정할 수 없습니다. 설정 파싱 오류가 발생하면 시스템 프록시를 조정하기보다 필드와 코어의 호환성을 먼저 확인하세요.

요청이 로그에 나타나지 않으면 앱에서 클라이언트까지의 경로를 먼저 확인하세요. 시스템 프록시가 적용되는지, 브라우저 확장 프로그램이 설정을 덮어쓰는지, 앱별 목록에서 누락된 앱은 없는지 살펴봅니다. 요청은 표시되지만 핸드셰이크가 실패하면 서버 주소, 포트, 인증, 전송 및 보안 매개변수가 맞는지, 시스템 시간이 올바른지 확인하세요. 요청이 예상한 아웃바운드로 나가는데 특정 사이트에서만 문제가 생기면 해당 사이트의 이름 해석, 인증서, 네트워크 응답을 살펴보세요. 대상 하나에 실패했다고 클라이언트 전체가 실행되지 않는다고 판단하지 마세요.

일반적인 문제 해결 범위

문제를 문의할 때 필요한 증거 보존

추가 도움을 요청할 때는 재현 가능한 작업 순서, 실패 시각 전후의 로그, 이미 확인한 항목을 제공하세요. 전체 구독 주소, 사용자 식별자, 비밀번호 및 다른 인증 정보는 가리고 문제를 판단하는 데 필요한 정보만 남기세요. 로그 수준을 높이면 방문 대상이 더 많이 기록될 수 있으므로 필요한 내용을 확인한 뒤 적절한 수준으로 되돌리세요. 전체 설정 디렉터리를 공개 피드백에 업로드하거나 계정 정보가 포함된 스크린샷으로 설명을 대신하지 마세요.

연결은 정상으로 표시되는데 웹페이지가 열리지 않는다면 연결 후 인터넷이 안 될 때 확인할 체크리스트를 따라 점검하세요. 가장 짧은 설정 과정을 다시 진행하려면 빠른 시작 가이드로 돌아가세요. 다른 플랫폼의 설치 파일이 필요하면 다운로드 페이지를 이용하세요. 정상 작동이 확인된 최소 설정을 하나 보관해 두면 규칙을 계속 추가하거나 코어를 바꾸고 프로그램을 재설치하는 것보다 다음 문제의 원인을 찾기 쉽습니다.