공통 준비: 설치 파일과 연결 정보
클라이언트, 코어, 노드 구분하기
v2rayN은 서버 정보를 저장하고 구독을 업데이트하며 실행 설정을 생성하고 프록시 연결을 관리하는 데스크톱 GUI 클라이언트입니다. 실제 연결 처리는 코어가 담당하며, 노드는 원격 서버의 주소와 인증 정보를 뜻합니다. 클라이언트를 설치해도 연결 가능한 노드가 자동으로 제공되지는 않습니다. 구독을 받았더라도 모든 항목이 현재 코어와 호환되는 것은 아닙니다. 시작하기 전에 제공받은 정보가 구독 주소인지, 단일 공유 링크인지, 전체 설정 파일인지 확인하고 지원 프로토콜과 클라이언트 범위도 알아두세요.
데스크톱에서는 Windows, macOS, Linux를 지원하는 v2rayN을 우선 고려하세요. Android에서는 일반적으로 Xray 코어를 사용하는 v2rayNG를 이용하고, 기존 V2Fly 설정이 필요하다면 v2flyNG를 검토하세요. 코어 이름이 비슷하다고 프로토콜 필드까지 동일한 것은 아닙니다. 특히 REALITY, 흐름 제어, 전송 설정은 현재 앱에서 제공하는 옵션을 기준으로 확인하세요. 한 클라이언트가 내보낸 실행 설정을 다른 앱에서도 쓸 수 있는 일반 구독으로 간주해서는 안 됩니다.
시스템 아키텍처와 설치 조건 확인
클라이언트 다운로드 페이지에서 운영체제에 맞는 설치 파일을 고른 뒤 프로세서 아키텍처를 확인하세요. Windows용 다운로드는 이 사이트에서 x64를 제공합니다. Mac은 ‘이 Mac에 관하여’에서 칩을 확인하고 Apple Silicon과 Intel용 설치 파일을 구분하세요. Linux는 아키텍처와 패키지 형식을 모두 확인해야 합니다. Android는 기기 아키텍처를 확인해 arm64를 우선 선택하고, 확인이 어렵거나 아키텍처가 맞지 않는다는 안내가 표시될 때만 범용 패키지를 살펴보세요. 파일 확장자만으로 호환성을 판단하거나 아키텍처가 다른 비슷한 이름의 패키지를 반복 설치하지 마세요.
설치 전에 앱과 설정을 저장할 공간을 확보하고 현재 계정으로 소프트웨어를 설치할 수 있는지 확인하세요. 일반 시스템 프록시는 보통 관리자 권한으로 계속 실행할 필요가 없습니다. 다만 TUN, 가상 네트워크 어댑터, 라우팅 변경에는 추가 권한이 필요할 수 있습니다. 회사 관리 기기는 네트워크 확장, VPN, 프록시 변경이 제한될 수 있으므로 관리 정책에 차단되면 먼저 기기 사용 규정을 확인하세요. 시스템 날짜와 시간도 정확해야 합니다. 시간이 크게 어긋나면 정상적인 암호화 연결도 핸드셰이크 단계에서 실패할 수 있습니다.
최소한의 검증 환경 준비
처음 설정할 때는 네트워크를 제어하는 다른 프록시나 VPN을 잠시 끄고 테스트할 클라이언트 하나만 남겨두세요. 복구할 수 있도록 기존 시스템 프록시와 DNS 설정을 기록해두세요. 먼저 시스템 프록시로 브라우저 연결을 확인한 뒤 TUN을 검토하고, 노드·라우팅·DNS·네트워크 어댑터를 한꺼번에 변경하지 마세요. 여러 설정을 동시에 바꾸면 연결이 복구되어도 어떤 변경이 원인이었는지 파악하기 어렵습니다. 이후 네트워크를 바꿀 때 같은 문제가 반복될 수도 있습니다.
구독 주소에는 계정 식별 정보나 액세스 토큰이 포함될 수 있으므로 민감한 정보로 취급하세요. 전체 링크를 공개 스크린샷이나 온라인 변환 도구, 문제 해결 게시물에 올리지 말고 로그를 공유할 때도 인증 정보를 가리세요. 직접 연결 확인용으로 정상적으로 열리는 일반 웹페이지 하나와 현재 노드를 통해 접속해야 하는 페이지 하나를 준비하세요. 테스트할 때 앱 이름, 시스템 프록시 사용 여부, TUN 활성화 여부를 함께 알려주면 ‘인터넷이 안 된다’는 설명만 하는 것보다 원인을 좁히기 쉽습니다.
이 가이드는 설정 순서와 구성 간 관계를 설명하며 메뉴 이름은 앱 업데이트에 따라 달라질 수 있습니다. 같은 이름의 메뉴가 보이지 않으면 ‘구독 관리’, ‘시스템 프록시’, ‘라우팅 설정’ 등 기능을 기준으로 찾아보세요. 다른 플랫폼의 스크린샷과 메뉴 위치가 완전히 같을 필요는 없습니다. 이미 연결할 수 있다면 필요한 항목으로 바로 이동하세요. 가져오기와 활성화 순서가 익숙하지 않다면 먼저 빠른 시작 가이드를 완료한 다음 돌아와 분할 라우팅과 TUN을 추가하세요.
Windows: v2rayN 설치 및 시스템 프록시
데스크톱 버전 또는 클래식 WPF 버전 선택
Windows 다운로드에서 필요에 따라 v2rayN 데스크톱 버전이나 클래식 WPF 버전을 선택하세요. 데스크톱 버전은 크로스 플랫폼 UI를 사용하므로 여러 데스크톱 운영체제에서 비슷한 방식으로 사용하려는 경우 적합합니다. WPF는 Windows용 클래식 UI입니다. 두 버전은 메뉴 구성이 다를 수 있으므로 문제를 보고할 때 어떤 버전을 사용하는지 알려주세요. 클라이언트 두 개를 동시에 실행해 로컬 수신 포트를 놓고 경쟁하게 하지 마세요. 나중에 시작한 코어가 포트를 열지 못할 수 있습니다.
설치 프로그램의 안내에 따라 설치를 마친 뒤, 처음 실행할 때는 노드를 가져오기 전에 메인 창이 정상적으로 표시되는지 확인하세요. 프로그램이 바로 종료되면 네트워크 설정을 바꾸기보다 시스템 알림과 앱 로그부터 살펴보세요. 실행 환경이 없다면 앱에서 요구하는 런타임을 설치해야 합니다. 클래식 WPF UI에는 데스크톱 구성 요소가 필요하므로 다른 용도의 런타임으로 대체할 수 없습니다. 필요한 구성 요소는 설치 안내를 따르세요. 프로그램이 이미 정상 실행된다면 관련 없는 구성 요소를 추가로 설치할 필요는 없습니다.
구독을 가져와 현재 서버 확인
구독 그룹 설정에서 새 그룹을 만들고 알아보기 쉬운 이름을 입력한 다음 전체 구독 주소를 주소 입력란에 붙여넣으세요. 저장 후 현재 구독을 업데이트합니다. 그룹을 저장하는 것만으로는 출처가 기록될 뿐 노드가 실제로 가져와지지 않을 수 있습니다. 업데이트가 끝나면 해당 그룹으로 전환해 서버 항목이 표시되는지 확인하고 하나를 현재 서버로 선택하세요. 브라우저에서 주소를 복사할 때 계정 페이지나 주문 페이지 URL이 아니라 정보 제공자가 준 구독 링크인지 확인하세요.
단일 공유 링크를 사용할 때는 클립보드에서 가져오기와 구독 업데이트가 서로 다른 작업입니다. 가져온 뒤 서버 주소, 포트, 프로토콜, 전송 방식을 확인하고 링크 끝의 설명을 서버 주소로 착각하지 마세요. 처음 연결을 확인할 때는 확실히 사용할 수 있는 항목 하나만 남겨 자동 전환과 일괄 테스트로 인한 변수를 줄이세요. 목록의 지연 시간은 특정 테스트 방식의 결과일 뿐, 실제 웹페이지 요청을 대신하지 않으며 프로토콜 설정이 완전히 올바르다는 증거도 아닙니다.
시스템 프록시를 켠 뒤 라우팅 확인
코어가 정상적으로 시작되면 시스템 프록시 메뉴에서 자동으로 시스템 프록시를 설정하는 옵션을 선택하세요. Windows 시스템 프록시 설정을 따르는 앱은 클라이언트의 로컬 진입점을 사용하게 됩니다. 시스템 프록시는 요청을 클라이언트로 전달하고 라우팅은 요청을 직접 연결할지 프록시로 보낼지 결정합니다. 두 기능은 서로 다릅니다. 중국 본토 우회 규칙을 선택해도 시스템 프록시가 자동으로 켜지는 것은 아니며, 시스템 프록시를 켜도 모든 앱이 이를 따르는 것은 아닙니다. 터미널, 개발 도구, 일부 다운로드 프로그램은 자체 프록시 설정이 필요할 수 있습니다.
테스트 페이지를 다시 열고 이전 연결을 유지하는 앱은 필요한 경우 재시작하세요. 브라우저는 정상인데 명령줄은 계속 직접 연결된다면 구독을 다시 가져오기 전에 명령줄 도구의 프록시 설정부터 확인하세요. 브라우저의 프록시 확장 프로그램이 시스템 설정을 덮어쓸 수도 있습니다. 모드별 차이는 시스템 프록시와 라우팅 모드 안내에서 확인하세요. 플랫폼 UI는 달라도 진입점 설정과 출구 선택은 서로 다른 단계입니다.
TUN 권한 부여 및 종료 후 복구
시스템 프록시를 따르지 않는 앱을 연결하거나 더 폭넓게 네트워크를 제어해야 할 때만 TUN을 켜세요. 다른 가상 네트워크 어댑터 제어 도구를 먼저 끄고, 클라이언트 안내에 따라 필요한 권한을 부여한 뒤 코어 로그에서 네트워크 진입점이 정상적으로 만들어졌는지 확인하세요. 보안 소프트웨어가 네트워크 구성 요소를 차단하면 차단된 대상과 용도를 확인하세요. 모든 보호 기능을 바로 끄지는 마세요. 조직 정책이 적용된 기기에서는 관리자 권한으로도 제한을 해제하지 못할 수 있습니다.
종료하기 전에 TUN을 끄고 클라이언트가 설정한 시스템 프록시를 해제하세요. 비정상 종료 후 클라이언트를 실행하지 않은 상태에서 브라우저가 전혀 연결되지 않는다면 Windows 프록시 설정에 로컬 주소를 가리키는 수동 프록시가 남아 있는지 확인하세요. 네트워크를 복구할 때는 이번에 변경한 설정만 되돌리세요. 알 수 없는 네트워크 어댑터를 삭제하거나 전체 네트워크를 초기화하지 마세요. 시작 문제는 런타임 및 시작 권한 문제 해결에서 확인하고, 프로그램 시작 실패와 노드 연결 실패를 구분해 처리하세요.
macOS: 칩에 맞는 설치 파일, 설치 권한 및 프록시
칩에 맞는 설치 파일 선택
Mac의 ‘이 Mac에 관하여’에서 칩 정보를 확인한 뒤 macOS 다운로드로 이동하세요. Apple Silicon에는 해당 arm64 설치 파일을, Intel에는 x64 설치 파일을 선택하세요. 호환성 계층으로 실행되는지를 확인하기보다 기기 아키텍처에 맞는 빌드를 우선 사용하세요. 다운로드가 끝나면 디스크 이미지를 열고 안내에 따라 v2rayN을 ‘응용 프로그램’ 폴더로 옮긴 뒤 해당 폴더에서 실행하세요. 임시로 마운트된 위치에서 계속 실행하지 마세요.
처음 실행하면 출처 확인이나 권한 안내가 표시될 수 있습니다. 먼저 파일이 예상한 다운로드 경로에서 받은 것이 맞는지 확인한 다음 시스템 설정의 ‘개인정보 보호 및 보안’에서 열기를 허용하세요. 앱이 손상되었거나 확인할 수 없다는 안내, 접근 권한 오류가 표시되면 다운로드가 완료되었는지, 설치 위치에 쓰기 권한이 있는지, 시스템 정책이 차단했는지를 각각 확인하세요. 모든 알림을 같은 원인으로 단정하지 말고 앱 하나를 실행하려고 macOS의 앱 검사 기능 전체를 끄지도 마세요.
가져온 뒤 먼저 실행하고 시스템 프록시 설정
v2rayN의 구독 그룹 설정을 열어 이름과 전체 구독 주소를 입력하고 저장한 뒤 현재 그룹을 업데이트하세요. 노드 목록이 나타나면 현재 서버를 선택하고 코어가 시작되는지 확인합니다. 구독은 저장되지만 업데이트가 실패한다면 주소에 불필요한 공백이 있는지, 주소가 만료되었는지, 현재 네트워크에서 구독 서비스에 접속할 수 있는지 확인하세요. 구독 업데이트와 노드 연결은 서로 다른 경로를 사용합니다. 전자가 성공해도 후자가 된다는 뜻은 아니며, 전자가 실패했다고 이미 저장한 노드가 반드시 사용할 수 없는 것도 아닙니다.
이어서 시스템 프록시 메뉴에서 자동 시스템 프록시 설정을 켜세요. Mac의 시스템 프록시는 네트워크 서비스와 연결되어 있으므로 Wi-Fi, 유선 어댑터 또는 다른 네트워크 서비스로 전환한 뒤 현재 서비스의 프록시 상태를 다시 확인해야 합니다. 시스템 프록시 메뉴의 ‘시스템 프록시 변경 안 함’은 시스템 설정을 더 이상 수정하지 않겠다는 의미일 뿐, 기존 프록시 설정이 사라졌다는 뜻은 아닙니다. 직접 연결로 복구하려면 시스템 프록시를 지우고 시스템 네트워크 설정에서 결과를 확인하세요. ‘변경 안 함’으로 전환하는 것만으로는 충분하지 않습니다.
브라우저 연결과 앱 연결 구분
시스템 프록시를 따르는 브라우저로 대상 페이지를 열고 요청이 클라이언트 로그에 나타나는지 확인하세요. 브라우저는 되지만 개발 도구가 연결되지 않는다면 도구 자체의 프록시 옵션과 프로세스 환경 변수를 살펴보세요. 일부 앱은 시작할 때만 프록시 설정을 읽으므로 시스템 설정을 바꾼 뒤 다시 실행해야 합니다. 브라우저에 별도 프록시 확장 프로그램이나 사용자 지정 DNS 설정이 있을 수도 있습니다. 이런 차이로 같은 Mac에서도 앱마다 동작이 달라질 수 있으므로 노드만 반복해서 바꾸지 마세요.
중국 본토 우회, 전역 라우팅 등의 사전 설정은 대상에 맞게 선택하세요. ‘시스템 프록시 자동 설정’을 모든 연결이 원격 서버를 거친다는 뜻으로 해석하지 마세요. 시스템 프록시가 켜져 있어도 코어는 규칙에 따라 특정 도메인이나 주소를 직접 연결할 수 있습니다. 개발 환경의 로컬 서비스에서는 루프백 주소와 LAN 대상이 어떻게 처리되는지 특히 주의하세요. 원래 로컬에서 접근해야 할 요청을 원격으로 보내지 않도록 해야 합니다. 프린터, LAN 서비스, 내부 도메인에 접근해야 한다면 적절한 직접 연결 범위를 유지하세요.
TUN 및 잠자기 후 복구 순서
시스템 프록시를 읽지 않는 앱을 연결해야 할 때 TUN을 시험하세요. 클라이언트 안내에 따라 권한을 높이거나 보조 구성 요소를 승인하고, 관련 네트워크 기능을 허용하라는 macOS 안내가 표시되는지 확인하세요. TUN을 켠 뒤 일반 웹페이지를 먼저 확인하고 LAN과 대상 앱도 점검하세요. 페이지 하나만 확인하면 LAN 라우팅이나 DNS 문제를 놓칠 수 있습니다. 기본 경로를 관리하는 도구를 여러 개 동시에 실행하지 마세요. 창을 닫아도 백그라운드 네트워크 기능이 반드시 중지되는 것은 아닙니다.
Mac이 잠자기에서 깨어나거나 네트워크를 전환하면 기존 연결이 끊길 수 있습니다. 먼저 기본 네트워크가 동작하는지 확인한 뒤 현재 노드에 다시 연결하세요. 문제가 계속되면 TUN을 끄고 시스템 프록시를 기존 상태로 복구한 다음 처음 순서대로 다시 활성화하세요. 앱을 종료하기 전에 프록시를 직접 해제하고, 비정상 종료 후에는 현재 네트워크 서비스의 프록시 설정에 남은 항목이 있는지 확인하세요. 작업 중에는 macOS 시스템 프록시 모드 자세히 보기를 참고하세요. 시작 단계 문제는 권한 및 격리 속성 문제 해결을 확인하세요.
Linux: 패키지, 데스크톱 프록시 및 권한
배포판과 프로세서 아키텍처 모두 확인
Linux 다운로드에서 배포판에 맞는 패키지가 deb인지 rpm인지 확인한 다음 기기 아키텍처가 x64인지 arm64인지 확인하세요. 확장자를 바꿔 다른 패키지 형식으로 만들거나 프로세서 아키텍처와 배포판 이름을 혼동하지 마세요. 시스템 정보 화면에서 확인할 수 있습니다. 터미널을 사용한다면 아래 명령은 시스템 정보만 읽으며 소프트웨어를 설치하거나 네트워크를 변경하지 않습니다. 출력된 아키텍처가 다운로드 페이지 안내와 일치하는지 확인한 뒤 진행하세요.
uname -m
cat /etc/os-release
배포판의 소프트웨어 설치 도구로 다운로드한 패키지를 열고 의존성 안내를 확인한 다음 설치하세요. 구성 요소가 없다는 메시지가 표시되면 현재 배포판의 공식 저장소를 사용해 의존성을 해결하세요. 다른 배포판의 패키지를 섞지 마세요. 설치는 되었지만 창이 표시되지 않으면 터미널에서 설치된 프로그램을 실행해 오류 출력을 확인하세요. 그래픽 세션, 데스크톱 구성 요소, 파일 권한 문제를 구분해 살펴보세요. 이 단계는 노드 연결 전이므로 구독을 수정해도 도움이 되지 않습니다.
일반 계정으로 실행하고 수신 주소 확인
GUI 앱은 일반 계정으로 실행하세요. 한 번이라도 높은 권한으로 실행한 뒤 설정 폴더 소유권이 바뀌면 일반 계정으로 쓸 수 없게 될 수 있습니다. 처음 실행할 때 구독과 앱 설정을 저장할 수 있는지 확인하고, 종료 후 다시 열어 저장 상태를 확인하세요. 변경 사항이 매번 사라진다면 설정 폴더 권한과 디스크 상태를 확인하고 임시 위치에서 실행하고 있지는 않은지 살펴보세요. 백업과 이전 시에도 폴더 전체의 권한을 무작정 완화하는 대신 적절한 파일 소유자를 유지하세요.
구독 그룹을 만들고 주소를 입력해 저장한 뒤 업데이트하세요. 노드를 선택하고 코어 로그를 살펴봅니다. 주소가 이미 사용 중이라는 메시지는 다른 코어나 프록시 도구가 같은 로컬 포트를 점유하고 있다는 뜻일 수 있습니다. 먼저 점유 중인 프로세스를 확인한 뒤 중복 실행을 종료하거나 클라이언트 수신 포트를 변경하세요. 포트를 바꾸면 해당 진입점을 사용하는 앱 설정도 함께 수정해야 합니다. 클라이언트만 바꾸고 브라우저, 터미널, 데스크톱 프록시는 그대로 두면 ‘코어는 정상인데 요청이 들어오지 않는’ 상황이 발생할 수 있습니다.
데스크톱 환경마다 시스템 프록시가 다름
Linux의 데스크톱 프록시 동작은 데스크톱 환경과 앱 구현에 따라 다릅니다. 클라이언트에서 시스템 프록시를 설정하더라도 데스크톱의 네트워크 프록시 설정에 실제로 반영되었는지 확인하세요. 일부 GUI 앱은 데스크톱 설정을 읽지만 명령줄 프로그램은 환경 변수나 자체 설정 파일을 사용할 수 있습니다. 이미 실행 중인 프로세스는 설정 변경을 자동으로 반영하지 않을 수도 있습니다. 먼저 프록시를 지원하는 앱 하나가 로컬 진입점을 사용하는지 확인해 노드 연결을 검증하면 다른 프로그램의 문제도 더 쉽게 좁힐 수 있습니다.
터미널에 프록시를 설정하기 전에 도구가 지원하는 프록시 프로토콜과 클라이언트에서 실제로 사용 중인 수신 유형을 확인하세요. HTTP 진입점과 SOCKS 진입점은 둘 다 로컬에 있다고 서로 바꿔 쓸 수 있는 것이 아닙니다. 임시 환경 변수는 보통 현재 터미널과 하위 프로세스에만 적용되며 데스크톱 전체를 자동으로 수정하지 않습니다. 설정을 해제할 때도 해당 환경 변수를 되돌리세요. 그렇지 않으면 클라이언트를 종료한 뒤에도 새 명령이 존재하지 않는 로컬 포트에 연결을 시도해 시스템 네트워크 문제처럼 보일 수 있습니다.
TUN, 라우팅 및 네트워크 관리 서비스
TUN은 가상 네트워크 장치에 접근하고 관련 라우팅을 변경해야 하므로 권한이 부족하다면 클라이언트 안내에 따라 필요한 권한을 설정하세요. TUN을 시작하려고 데스크톱 앱 전체를 계속 높은 권한으로 실행하지 마세요. 활성화 후 네트워크 진입점이 만들어졌는지, 다른 VPN이 기본 경로를 제어하는지, LAN 대상에 계속 접근할 수 있는지 확인하세요. 데스크톱 네트워크 관리 서비스는 네트워크 전환 후 설정을 다시 적용할 수 있으므로 처음 시작에 성공했다고 해서 전환 후에도 같은 상태라고 단정할 수 없습니다.
DNS는 데스크톱 환경, 네트워크 관리 서비스, 로컬 DNS 서비스가 각각 관리할 수 있습니다. 먼저 어느 계층이 관리하는지 확인한 다음 클라이언트 DNS를 조정하세요. 시스템이 관리하는 DNS 설정 파일을 바로 덮어쓰지 마세요. 주소를 찾을 수 없다면 TUN을 끄고 기준 상태로 돌아가 시스템 DNS가 복구되는지 확인하세요. 기본 네트워크가 복구되면 가상 진입점과 규칙을 단계별로 살펴보세요. 종료 전에 이번에 설정한 프록시만 해제하고 기존 네트워크 설정은 유지하세요. 특히 원격으로 관리하는 기기는 복구 방법이 없는 상태에서 기본 경로를 바꾸지 마세요.
Android: 구독 가져오기 및 VPN 권한
v2rayNG 또는 v2flyNG 선택
Android 다운로드에서 클라이언트를 선택하세요. 일반적인 Xray 설정에는 v2rayNG를 우선 사용하고, 기존 설정이 명확하게 V2Fly 기반이라면 v2flyNG를 검토하세요. 두 앱 모두 노드를 관리할 수 있지만 기능과 프로토콜 지원이 완전히 같다고 이름만으로 판단할 수는 없습니다. 서비스 설정에 REALITY나 특정 흐름 제어가 필요하다면 가져오기 전에 현재 클라이언트에 해당 필드가 있는지 확인하세요. 실행할 때 지원하지 않는다는 사실을 뒤늦게 알게 되는 상황을 피할 수 있습니다.
설치 파일은 arm64와 범용 버전으로 제공됩니다. 최신 주류 기기는 보통 arm64를 선택할 수 있지만 실제 프로세서 아키텍처를 기준으로 확인하세요. 호환되지 않는다는 안내가 표시되면 다른 출처의 패키지를 계속 덮어 설치하지 말고 아키텍처와 시스템 요구 사항부터 확인하세요. 브라우저에서 설치하는 경우 Android에서 현재 출처의 앱 설치를 허용하라는 메시지가 표시될 수 있습니다. 이번에 사용할 출처에 필요한 권한만 허용하세요. 설치가 끝나면 앱 목록에서 클라이언트를 열어 메인 화면에 진입할 수 있고 설정을 저장할 수 있는지 먼저 확인하세요.
주소를 붙여넣고 구독 업데이트
전체 구독 주소를 복사해 앱의 구독 설정 또는 구독 그룹 관리에서 새 출처를 추가하세요. 이름을 입력하고 저장한 다음 구독을 업데이트합니다. UI에 따라 업데이트 메뉴가 기본 목록에 있을 수 있으므로 구독 설정 화면에 주소가 보인다는 사실만으로 업데이트까지 완료된 것은 아닙니다. 업데이트 후 노드 목록으로 돌아가 사용할 항목을 선택하세요. 단일 공유 링크만 있다면 클립보드 가져오기 기능을 사용하세요. 구독 주소만 입력할 수 있는 필드에 단일 노드 링크를 붙여넣으면 안 됩니다.
휴대폰에서 정보를 복사할 때 줄바꿈, 공백, 메신저가 덧붙인 설명이 함께 들어갈 수 있으니 가져오기 전에 프로토콜 표기와 전체 내용을 확인하세요. QR 코드 가져오기는 인코딩된 정보를 읽을 뿐 설정이 여전히 유효한지 확인하지 않습니다. 노드 이름은 표시되지만 시작되지 않는다면 전송 유형, 암호화 연결 매개변수, 코어 지원 여부를 확인하고 로그를 살펴보세요. 형식별 차이는 구독, 기본 JSON 및 공유 링크 안내에서 확인하세요. 모든 텍스트를 같은 방식으로 가져오지 마세요.
Android의 VPN 네트워크 제어 방식 이해
연결을 누르면 일반적으로 시스템의 VPN 연결 요청이 표시됩니다. 확인해야 앱이 로컬 가상 네트워크 진입점을 통해 트래픽을 받을 수 있습니다. 이는 Android가 이러한 클라이언트에 제공하는 네트워크 제어 방식이며 노드 정보가 시스템에서 자동으로 채워진다는 뜻은 아닙니다. VPN 상태 아이콘은 로컬 트래픽 제어 경로가 만들어졌다는 의미일 뿐, 원격 연결 성공 여부는 로그와 대상 요청으로 확인해야 합니다. 시스템 권한 요청을 거부한 상태라면 노드를 바꿔도 권한 문제가 해결되지 않습니다.
일반적으로 같은 시스템 사용자에서 일반 VPN 앱 두 개가 동시에 트래픽을 제어할 수 없습니다. 이미 다른 VPN이나 필터링 도구, VPN 인터페이스를 사용하는 네트워크 앱이 있다면 먼저 중지하고 테스트하세요. 앱별 프록시는 어떤 앱을 네트워크 제어 대상으로 삼을지 선택하는 기능입니다. 설정에 따라 ‘선택한 앱만 프록시’ 또는 ‘선택한 앱 제외’를 의미할 수 있으므로 현재 모드를 읽고 조작하세요. 목록에서 앱을 선택했다고 반드시 해당 앱이 프록시를 사용한다는 뜻은 아니며 동작 방향은 모드 정의에 달려 있습니다.
백그라운드 제한, 네트워크 전환 및 복구
앱을 화면에 열어둘 때는 정상인데 화면을 잠근 뒤 연결이 자주 끊긴다면 먼저 시스템의 배터리 최적화, 백그라운드 실행, 자동 시작 제한을 확인하세요. 기기 설정에서 필요한 백그라운드 동작만 허용하면 됩니다. 관련 없는 앱을 한꺼번에 허용할 필요는 없습니다. 시스템이 프로세스를 종료했는지, Wi-Fi에서 모바일 네트워크로 전환되며 기존 연결이 끊겼는지도 확인하세요. 전자는 백그라운드 제한이 원인일 수 있고, 후자는 현재 설정으로 다시 연결한 뒤 로그를 살펴봐야 합니다.
처음 연결을 확인할 때는 항상 VPN 사용이나 VPN 미사용 연결 차단 같은 시스템 옵션을 바로 켜지 마세요. 클라이언트 연결이 실패했을 때 다른 요청까지 차단되어 기본 네트워크 상태를 파악하기 어려울 수 있습니다. 이런 기능이 필요하다면 정상 연결, 연결 해제, 재시작 후 동작을 먼저 검증하세요. 문제 해결을 마친 뒤 앱에서 직접 연결을 끊고 시스템 VPN 상태도 해제되었는지 확인하세요. 다른 클라이언트로 바꾸기 전에도 기존 네트워크 제어를 중지해야 이전 앱의 잔여 상태를 새 앱의 문제로 오해하지 않습니다.
구독 관리: 형식, 업데이트 및 설정 이전
정보 유형을 확인하고 맞는 가져오기 방식 선택
구독 주소는 반복해서 요청할 수 있는 리소스 경로이며 클라이언트는 업데이트할 때 해당 주소에서 노드 정보를 가져옵니다. 공유 링크는 보통 단일 노드를 설명하고 기본 JSON은 인바운드, 아웃바운드, 라우팅, DNS 전체를 정의할 수 있습니다. 확장자만 바꾼다고 서로 호환되는 파일이 되지는 않습니다. 가져오기에 실패하면 먼저 입력 유형을 확인한 다음 클라이언트가 해당 유형을 지원하는지 살펴보세요. 웹페이지를 텍스트 파일로 저장하거나 인코딩된 내용을 다시 인코딩해도 유효한 설정으로 바뀌지 않습니다.
Base64 구독은 여러 공유 링크를 모아 인코딩할 때 흔히 사용되며, 디코딩 후에도 클라이언트가 인식할 수 있는 링크 형식이어야 합니다. 일부 구독 서비스는 요청 방식에 따라 다른 구조를 반환하므로 브라우저에 보이는 내용과 클라이언트가 실제로 받는 내용이 다를 수 있습니다. 문제를 해결할 때는 주소가 브라우저에서 열리는지만 보고 판단하지 말고 업데이트 로그의 응답 내용과 파싱 오류를 확인하세요. 로그인 페이지, 오류 메시지, 빈 응답이 반환되면 가져올 노드가 없을 수 있습니다.
| 정보 유형 | 주요 용도 | 먼저 확인할 항목 |
|---|---|---|
| 구독 주소 | 노드 일괄 가져오기 및 업데이트 | 유효 기간, 접근 권한, 응답 형식 |
| 공유 링크 | 단일 노드 매개변수 가져오기 | 프로토콜, 전송, 인증 필드 |
| 기본 JSON | 코어 실행 설정 설명 | 코어 유형, 필드 구조, 인바운드 및 라우팅 |
그룹 업데이트와 노드 선택 분리
구독 그룹에는 출처와 용도를 구분할 수 있는 이름을 사용하세요. 현재 그룹을 업데이트하면 해당 출처만 새로고침하지만 전체 구독 업데이트는 여러 그룹의 항목을 동시에 바꿀 수 있습니다. 구독 노드를 직접 수정했다면 업데이트 전에 백업하세요. 클라이언트가 출처 기준으로 항목을 다시 생성하면서 수동 변경 사항을 유지하지 않을 수 있습니다. 오래 관리할 사용자 지정 노드는 구독 기록 하나를 매번 수정하는 대신 별도로 저장하는 편이 좋습니다.
업데이트가 끝나면 현재 선택된 노드가 여전히 있는지 확인하세요. 노드 이름, 서버 주소, 설정 내용이 바뀌었을 수 있으므로 그룹 업데이트 성공만 보고 지나가지 마세요. 자동 업데이트 간격은 구독 제공자의 제한에 맞추고 실패할 때는 짧은 간격으로 계속 새로고침하지 마세요. 구독 서비스에 일시적으로 접속할 수 없어도 기존 노드가 연결된다면 저장된 설정을 계속 사용하면서 구독 요청 경로를 확인할 수 있습니다. 모든 항목을 삭제하고 다시 만들 필요는 없습니다.
앱 내 백업 기능으로 이전
같은 클라이언트 간 이전은 앱에서 제공하는 백업 및 복원 기능을 우선 사용하거나 안내에 따라 설정 폴더를 백업하세요. 데이터베이스에 쓰는 동안 복사하지 않도록 이전 전에 앱을 종료하고, 복원하기 전에 대상 기기의 기존 정보를 별도로 저장하세요. 백업에는 전체 구독 주소, 인증 정보, 로컬 사용 기록이 포함될 수 있으므로 접근이 제한된 위치에 보관해야 합니다. 새 기기에서 복원한 뒤 로컬 수신 포트, 시스템 프록시, TUN 설정을 다시 확인하세요. 특정 기기에 종속된 옵션이 다른 기기에서도 그대로 동작한다고 가정하지 마세요.
플랫폼 간 이전에서는 파일 경로, 권한 처리 방식, 네트워크 서비스 차이에 특히 주의하세요. Windows 경로를 Mac에서 그대로 쓸 수 없고 Linux 권한 설정을 Android에 그대로 적용할 수도 없습니다. 클라이언트 간 이전은 양쪽에서 지원하는 공유 형식을 사용하고 핵심 매개변수를 하나씩 확인하세요. 전체 실행 설정에는 특정 코어 전용 필드가 포함될 수 있으므로 모두 JSON이라는 이유만으로 호환된다고 판단하지 마세요. 가져오기 오류가 없더라도 실제 연결과 라우팅 결과를 검증해야 합니다.
REALITY 및 전송 매개변수 확인
VLESS 노드는 서버 주소, 포트, 사용자 ID, 전송 방식, 연결 보안, 흐름 제어를 각각 확인해야 합니다. REALITY의 서버 이름, 공개 키, 짧은 ID는 서버 측 요구 사항과 일치해야 하며 다른 노드의 값을 임의로 조합해서는 안 됩니다. 서버 이름이 실제 연결 주소와 같은 것도 아닙니다. 매개변수가 빠져 있다면 검증을 끄고 운에 맡기기보다 정보 제공자에게 확인하세요. 원리는 REALITY 및 XTLS Vision 안내에서 확인할 수 있습니다.
이전 후 두 차례 검증하세요. 먼저 새 기기에서 최소 설정으로 연결하고, 이후 기존 분할 라우팅, 자동 업데이트, 백그라운드 옵션을 다시 추가합니다. 안정적으로 작동하는 것을 확인한 뒤 이전 기기의 정보를 정리하세요. 새 기기에서 아직 연결을 검증하지 못했다면 기존 설정을 유지해야 정보 문제와 플랫폼 환경 문제를 구분하는 데 도움이 됩니다. 형식 변환의 구체적인 범위는 구독 형식 자세히 보기를 참고하세요.
시스템 프록시, TUN, 라우팅 및 DNS
요청이 어디에서 클라이언트로 들어오는지 확인
시스템 프록시는 앱과 시스템이 연동하는 방식입니다. 시스템에 프록시 진입점을 기록하면 해당 설정을 읽는 앱이 요청을 그 진입점으로 보냅니다. TUN은 네트워크 계층에 가상 진입점을 만들고 라우팅을 통해 조건에 맞는 데이터를 클라이언트로 전달합니다. 두 방식은 우선 트래픽을 받아들이는 문제를 해결하며 모든 요청의 최종 출구를 직접 결정하지는 않습니다. 앱이 시스템 프록시를 따르지 않는다면 요청이 코어로 들어오지 않은 것이므로 노드 분할 규칙을 바꿔도 효과가 없습니다.
진입점이 작동하는지 확인하려면 명확한 요청을 한 번 보내고 로그에서 대상 도메인, 연결 시간, 앱 동작이 서로 맞는지 살펴보세요. 로그가 없다면 프록시 진입점과 앱 설정을 먼저 확인하세요. 기록은 있지만 연결이 실패한다면 노드, 라우팅, DNS를 확인합니다. 로그 수준을 오랫동안 지나치게 상세하게 설정하지 말고 문제 해결이 끝나면 평소 수준으로 되돌린 뒤 민감한 정보가 담긴 기록을 삭제하세요. 연결 재사용으로 페이지를 새로고침해도 새 연결이 만들어지지 않을 수 있으므로 필요한 경우 앱을 다시 열어 확인하세요.
라우팅 규칙은 순서대로 출구를 선택
중국 본토 우회는 보통 도메인과 주소 규칙에 따라 관련 요청을 직접 연결하고 나머지는 설정된 방식으로 처리합니다. 규칙 순서가 중요합니다. 범위가 넓은 규칙을 앞에 두면 뒤에 있는 구체적인 규칙이 적용되지 않을 수 있습니다. LAN 주소, 특정 개발 도메인, 원격 대상을 각각 고려하고 모든 주소를 포괄하는 규칙 하나만 추가하지 마세요. 회사 네트워크의 내부 도메인은 내부 DNS에서만 확인될 수 있으므로 모든 요청을 원격으로 보내서는 안 됩니다.
아래는 데이터베이스 규칙과 출구 태그의 관계를 설명하는 Xray 라우팅 구조 예시입니다. 기존 설정에 병합해야 하며 완전한 클라이언트 설정으로 바로 실행할 수는 없습니다. 이 예시는 direct 및 proxy라는 아웃바운드와 사용 가능한 규칙 데이터베이스가 이미 있다고 가정합니다. GUI 클라이언트는 실행 설정을 다시 생성할 수 있으므로 일상적인 수정에는 임시 생성 파일을 직접 편집하기보다 클라이언트의 라우팅 UI를 사용하세요.
{
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
},
{
"type": "field",
"ip": ["geoip:private", "geoip:cn"],
"outboundTag": "direct"
},
{
"type": "field",
"network": "tcp,udp",
"outboundTag": "proxy"
}
]
}
}
DNS는 주소 하나 입력으로 끝나지 않음
도메인 조회는 앱, 시스템, 클라이언트, 원격 서버에서 이루어질 수 있으며 프록시 방식에 따라 조회 위치도 다릅니다. 브라우저에서 암호화 DNS를 사용하면 시스템 DNS를 바꿔도 영향을 받지 않을 수 있습니다. 문제를 확인할 때 먼저 대상 앱이 어느 계층에서 이름을 조회하는지 파악하고 클라이언트 규칙이 도메인 정보를 볼 수 있는지 확인하세요. 요청이 들어올 때 이미 IP 주소만 남아 있다면 도메인 기반 규칙이 예상대로 적용되지 않을 수 있습니다. 웹페이지가 열리지 않는다고 여러 계층의 DNS를 한꺼번에 바꾸지 마세요.
클라이언트 DNS, 직접 연결 출구, 프록시 출구 사이에 의존 관계가 생길 수 있습니다. 예를 들어 노드 서버 주소를 조회할 때 아직 연결되지 않은 바로 그 노드를 거쳐야 한다면 연결 시작이 순환할 수 있습니다. 먼저 서버 연결에 필요한 기본 DNS 조회를 보장한 뒤 대상 도메인의 분할 DNS를 설정하세요. TUN을 사용할 때는 DNS 요청이 설계대로 제어되는지도 확인해야 합니다. 시스템과 클라이언트가 서로 다른 결과를 사용하면 같은 도메인도 일관되지 않게 동작할 수 있습니다.
데이터베이스와 UDP를 따로 검증
GeoSite는 도메인 분류를, GeoIP는 IP 주소 범위를 관리하므로 서로 바꿔 쓸 수 있는 규칙 데이터가 아닙니다. 규칙 문법은 맞는데 분류가 적용되지 않는다면 데이터베이스가 존재하는지, 정상적으로 로드되었는지, 현재 코어가 어떤 데이터 형식을 지원하는지 확인하세요. 데이터베이스를 업데이트한 뒤에는 코어가 다시 불러왔는지 확인해야 합니다. 다운로드 완료만으로 적용되었다고 판단하지 마세요. 규칙 적용 순서는 GeoIP 및 GeoSite 업데이트 가이드에서 확인할 수 있습니다.
브라우저 웹페이지가 열린다고 UDP 앱도 반드시 작동하는 것은 아닙니다. UDP 전달 여부는 앱 진입점, 클라이언트 설정, 프로토콜 지원, 노드 서비스, 네트워크 환경에 따라 달라집니다. 음성, 실시간 통신, 다른 전송 방식을 사용하는 앱이 실패하면 해당 트래픽을 따로 살펴보세요. 웹페이지 결과만으로 판단하지 마세요. 설정 복잡도는 단계별로 높이세요. 시스템 프록시를 확인한 뒤 라우팅, TUN, DNS 및 특정 앱 요구 사항을 차례로 테스트하고 매 단계에서 복구할 수 있도록 이전 설정을 보관하세요.
자주 발생하는 설정 문제: 실패 단계별 확인
프로그램이 열리지 않거나 코어가 시작되지 않음
먼저 메인 창이 표시되는지 확인하세요. 메인 창조차 열리지 않으면 설치 아키텍처, 시스템 의존성, 앱 권한, 보안 알림을 우선 확인하세요. 이 단계에서는 구독 내용이 주된 원인일 가능성이 낮습니다. 창은 열리지만 코어가 종료된다는 메시지가 나오면 코어 로그에서 설정 파싱 실패, 로컬 포트 점유, 파일 접근 실패, 미지원 필드를 확인하세요. 오류가 발생한 단계를 기록하면 앱 시작 문제를 노드 교체로 해결하려 하거나 설정 오류를 전체 클라이언트 재설치로 해결하려는 일을 피할 수 있습니다.
설정을 바꾼 직후 시작에 실패했다면 가장 최근 변경 하나를 먼저 되돌리세요. 백업이 있다면 정상적으로 시작되던 설정을 복원하세요. 로그와 유효한 정보가 남아 있을 수 있으므로 설정 폴더 전체를 바로 삭제하지 마세요. 포트 충돌은 중복 실행 중인 클라이언트를 확인하고, 권한 오류는 문제가 난 파일의 위치를 살펴보세요. 플랫폼별 시작 문제는 v2rayN 강제 종료 및 권한 문제 해결을 참고하고 네트워크를 테스트하기 전에 프로그램을 정상 상태로 복구하세요.
구독 업데이트 실패와 연결 실패
구독 업데이트가 실패하면 구독 서비스에 접속할 수 있는지 먼저 확인한 다음 반환 내용을 클라이언트가 인식할 수 있는지 살펴보세요. 시간 초과, 인증 만료, 형식 미지원은 서로 다른 문제입니다. 주소가 완전하고 접근 권한도 있는지 확인한 뒤 현재 네트워크에서 로그인 페이지나 접근 제한이 나타나는지 확인하세요. 기존 노드는 사용할 수 있지만 구독에 접속할 수 없다면 클라이언트에서 적절한 업데이트 요청 방식을 제공하는지 살펴보세요. 민감한 구독 정보를 온라인 변환 서비스에 함부로 입력하지 마세요. 접근 정보 유출로 문제가 커질 수 있습니다.
노드를 가져왔지만 연결되지 않으면 원격 주소, 포트, 프로토콜, 전송 방식, 보안 매개변수를 차례로 확인하세요. 시간 초과가 발생하면 접근 가능 여부와 서버 상태를 살펴보세요. 인증이나 핸드셰이크 오류라면 설정 내용, 시스템 시간, 서버 요구 사항에 더 주의를 기울여야 합니다. 오류 메시지만으로 원인을 단정하지 말고 발생 단계를 함께 고려하세요. 여러 노드를 한꺼번에 바꾸기 전에 정보가 명확한 설정 하나를 검증하세요. 모든 설정이 같은 단계에서 실패한다면 항목별 매개변수보다 공통 환경을 먼저 확인하세요.
연결되었는데 웹페이지나 앱이 작동하지 않음
클라이언트에 실행 중이라고 표시되는 것은 로컬 프로세스가 작동 중이라는 뜻일 뿐입니다. 먼저 요청이 로그에 들어오는지 확인하고, 이어서 어떤 출구 규칙이 적용되었는지, 마지막으로 DNS 조회와 원격 응답을 살펴보세요. 브라우저는 되지만 다른 앱이 실패하면 진입점과 앱 프록시 설정을 비교하는 것이 좋습니다. 모든 앱이 실패한다면 코어와 노드를 다시 확인하세요. 일부 도메인만 문제가 있다면 라우팅 분류, DNS 결과, 대상 서비스 자체를 살펴보세요. 바로 더 광범위한 트래픽 제어를 켤 필요는 없습니다.
웹페이지 일부만 로드되거나 다운로드가 끊기고 영상이 멈춰도 곧바로 ‘노드가 느리다’고 단정하지 마세요. 페이지는 여러 도메인에서 리소스를 요청할 수 있으며 일부 요청만 잘못 라우팅되어도 부분적인 오류가 발생합니다. 실패한 리소스의 대상과 출구를 확인해 예상한 경로로 전달되는지 살펴보세요. 지연 시간 테스트는 특정 연결만 측정하므로 처리량, 장시간 전송, 모든 프로토콜의 성능을 나타내지 않습니다. 노드를 비교할 때는 같은 대상, 같은 네트워크, 같은 프록시 방식을 사용해 서로 다른 조건의 결과를 섞지 마세요.
종료 후에도 인터넷에 연결되지 않음 및 문제 보고
클라이언트를 종료한 뒤 연결이 끊기면 시스템 프록시가 여전히 로컬 진입점을 가리키는지 먼저 확인하고, 이어서 TUN이나 시스템 VPN이 트래픽을 제어하고 있는지 살펴보세요. 복구할 때는 클라이언트가 변경한 항목부터 되돌린 뒤 직접 연결 확인 페이지를 테스트하세요. Linux에서는 터미널 환경 변수와 데스크톱 프록시가 각각 남아 있는지 확인하고, Mac은 현재 네트워크 서비스를 확인하세요. Android에서는 VPN 미사용 연결 차단 옵션이 켜져 있는지 살펴보세요. ‘종료 후 인터넷이 안 된다’는 이유만으로 전체 네트워크를 초기화하지 말고 이번 작업과 직접 관련된 설정부터 처리하세요.
추가 지원을 요청하려면 운영체제와 아키텍처, 클라이언트 이름, 정보 유형, 연결 방식, 재현 절차를 정리하고 민감한 필드를 가린 오류 내용을 첨부하세요. 모든 대상에서 실패하는지 일부 대상만 실패하는지, 직접 연결은 정상인지, 설치 직후 시작된 문제인지 네트워크 전환 후 발생했는지도 알려주세요. 가설은 한 번에 하나씩 검증하고 결과를 기록하세요. 일반적인 내용은 자주 묻는 질문에서 확인할 수 있습니다. 연결 과정을 처음부터 다시 진행하려면 사용 가이드로 돌아가 가져오기, 선택, 활성화, 검증 순서로 기준 상태를 설정하세요.