v2rayN 전체 플랫폼 설치 및 설정 가이드: 시스템 프록시, 구독, TUN

준비 / 클라이언트와 네트워크의 범위

공통 준비 사항: 설정 출처와 트래픽 처리 방식 파악

클라이언트, 코어, 연결 설정 구분하기

v2rayN은 서버 정보를 저장하고 구독을 관리하며 실행 설정을 생성하고 시스템 프록시 등의 기능을 제어하는 데스크톱 GUI 클라이언트입니다. 실제 연결은 v2rayN이 호출하는 코어가 담당합니다. Project V는 관련 프록시 기술의 배경 프로젝트이며, V2Fly와 Xray는 대표적인 코어 계열입니다. Android에서는 Xray 코어를 사용하는 v2rayNG 또는 V2Fly 코어를 사용하는 v2flyNG를 선택할 수 있습니다. 클라이언트 이름이 비슷하다고 지원하는 설정까지 완전히 같은 것은 아닙니다. 연결 정보를 받으면 먼저 프로토콜, 전송 방식, 보안 설정을 확인한 뒤 선택한 클라이언트와 코어가 이를 처리할 수 있는지 살펴보세요.

클라이언트를 설치해도 사용할 수 있는 서버가 자동으로 제공되지는 않습니다. 시작하기 전에 신뢰할 수 있는 출처의 구독 주소, 단일 공유 링크 또는 전체 서버 설정을 준비해야 합니다. 구독 주소에는 계정 식별 정보가 포함되는 경우가 많아, 주소를 읽을 수 있는 사람은 같은 연결 정보를 얻을 수 있습니다. 따라서 스크린샷, 포럼, 공유 메모에 공개하지 마세요. 시스템 날짜와 시간대가 정확한지, 네트워크에서 필요한 서비스에 정상적으로 접속할 수 있는지도 확인하세요. 시간이 크게 어긋나면 인증서 검증이나 시간 기반 인증이 실패해 노드를 사용할 수 없는 것처럼 보일 수 있습니다.

아키텍처를 확인한 뒤 설치 파일 선택

데스크톱에서는 v2rayN을 우선 사용하고 다운로드 페이지에서 운영체제와 프로세서 아키텍처에 맞는 파일을 선택하세요. Mac은 ‘이 Mac에 관하여’에서 칩을 확인하고, Windows는 ‘시스템 정보’에서 시스템 종류를 확인합니다. Linux에서는 프로세서 아키텍처와 배포판의 패키지 형식을 모두 확인하세요. Android는 일반적으로 arm64를 선택하며, 기기 아키텍처가 확실하지 않거나 설치할 때 호환성 오류가 발생하는 경우에만 범용 패키지를 고려하세요. 파일 이름에 익숙한 단어가 있다고 아키텍처를 짐작하거나 다른 운영체제용 패키지를 섞어 사용하지 마세요. 이미 클라이언트를 사용 중이라면 현재 작동 모드와 필요한 설정을 먼저 기록한 다음 업그레이드하세요. 업그레이드와 네트워크 변경을 한 번에 진행하지 않는 것이 좋습니다.

방식	트래픽 처리 경로	주요 제한 사항
시스템 프록시	운영체제의 프록시 설정	앱이 해당 설정을 읽고 사용해야 합니다
앱에서 직접 설정하는 프록시	앱 자체의 HTTP 또는 SOCKS 설정	설정한 앱에만 적용됩니다
TUN	가상 네트워크 인터페이스 및 라우팅	권한, 제외 규칙, 코어 구현에 따라 달라집니다

문제가 생겨도 되돌릴 수 있는 초기 상태 만들기

처음에는 시스템 프록시부터 설정하고 TUN, 서드파티 네트워크 가속기, 다른 프록시 클라이언트, 사용자 지정 DNS를 동시에 켜지 마세요. 시스템 프록시는 설정을 따르는 앱의 트래픽을 로컬 수신 포트로 전달할 뿐, 모든 네트워크 연결을 프록시로 보내지는 않습니다. TUN은 가상 인터페이스를 통해 규칙에 해당하는 트래픽을 처리하므로 라우팅과 권한까지 고려해야 해 문제를 진단할 범위가 넓어집니다. 브라우저 연결만 필요하다면 시스템 프록시부터 사용하세요. 시스템 프록시를 따르지 않는 앱이 있을 때 수동 프록시나 TUN을 검토하면 됩니다. 필요한 기능과 모드를 맞춰야 어떤 현상이 정상적인 제한인지 구분할 수 있습니다.

클라이언트에 표시된 실제 수신 주소, 포트, 현재 서버를 기록하세요. 예시 포트를 내 기기의 실제 포트라고 간주하지 마세요. 이 기기에서만 사용할 경우에는 루프백 주소로 수신하도록 설정해 로컬 네트워크 전체에 포트를 공개하지 않는 것이 좋습니다. 테스트할 HTTPS 페이지 하나와 비교할 별도의 서비스를 준비하세요. 특정 웹사이트의 계정 제한, 지역 정책, 서비스 장애만으로 클라이언트 전체의 문제를 판단할 수는 없습니다. 설정은 한 번에 하나씩 바꾸고 저장한 뒤 로그와 접속 결과를 확인하세요. 이후에 변경 사항을 유지할지 되돌릴지 결정하면 됩니다.

설치 전에는 저장 위치에 쓰기 권한이 있는지, 기존 프로세스가 수신 포트를 사용 중인지, 회사나 학교 기기에서 관리 정책으로 네트워크를 제어하는지 확인하세요. 관리 기기의 프록시, 인증서, 가상 네트워크 권한은 직접 변경할 수 없을 수 있습니다. 이때는 기기 관리 규정을 따르고 정책을 우회하려고 반복해서 시도하지 마세요. 이미 작동하는 설정이 있다면 필요한 정보를 먼저 내보내 안전하게 보관하세요. 설정 내보내기 파일에는 접속 정보가 포함될 수 있으므로 민감한 정보가 없는 일반 설정 파일처럼 공유해서는 안 됩니다.

플랫폼 / macOS

macOS: v2rayN 설치 및 시스템 프록시 설정

칩에 맞는 설치 파일을 선택하고 앱 위치 지정

Apple 메뉴에서 ‘이 Mac에 관하여’를 열어 칩을 확인하세요. Apple 계열 칩이면 Apple Silicon용 파일을, Intel 프로세서면 Intel용 파일을 선택합니다. macOS 다운로드에서 맞는 설치 파일을 받은 다음 디스크 이미지를 열고 v2rayN을 ‘응용 프로그램’으로 드래그하세요. 이후 해당 폴더에서 실행합니다. 디스크 이미지 안에서 계속 실행하거나 정리될 수 있는 임시 폴더에 프로그램을 두지 마세요. 앱 위치를 고정하면 권한과 향후 업데이트를 관리하기 쉽습니다. 처음 실행한 뒤 설치 디스크 이미지를 추출해도 복사된 앱에는 영향이 없습니다.

시스템에서 앱을 열 수 없다는 메시지가 표시되면 먼저 다운로드 출처, 칩 선택, 설치 완료 여부를 확인하세요. 그런 다음 ‘시스템 설정 → 개인정보 보호 및 보안’에 이번 실행을 허용하는 옵션이 있는지 살펴보세요. 출처를 확인한 경우에만 시스템이 제공하는 일회성 허용 방법을 사용하고, 앱 하나를 열기 위해 시스템 보호 기능 전체를 끄지 마세요. 조직에서 관리하는 기기라면 권한이 정책에 따라 제한될 수 있습니다. 반복해서 더블 클릭해도 해결되지 않는 경우가 많습니다. 메시지 전체를 기록해 시스템의 보안 차단, 앱 손상, 프로세서 비호환 중 어떤 문제인지 구분하세요. 각각 해결 방법이 다릅니다.

구독을 가져온 뒤 현재 서버부터 확인

구독 그룹 설정에서 새 그룹을 만들고 전체 구독 주소를 입력하세요. 그룹을 저장한 뒤 구독 업데이트도 실행해야 합니다. 그룹 이름이 나타났다고 서버를 정상적으로 가져온 것은 아닙니다. 업데이트가 끝나면 서버 목록을 확인하고 그중 하나를 현재 서버로 선택하세요. 프로토콜 접두사로 시작하는 단일 공유 링크를 받았다면 원격 구독 주소 입력란이 아니라 클립보드 가져오기 기능을 사용하세요. 빌드에 따라 메뉴 배치가 달라질 수 있지만 작업 순서는 ‘구독 출처 저장 → 업데이트 → 서버 선택’입니다. 스크린샷에 나온 버튼 위치만 따라가지 마세요.

이어서 ‘시스템 프록시 자동 설정’을 켜고 클라이언트 코어가 실행 중인지 확인하세요. 이 작업은 시스템 네트워크 프록시 설정을 변경해 해당 설정을 따르는 앱이 로컬 프록시에 연결하도록 합니다. Wi-Fi를 바꾸거나 유선 네트워크에 연결하거나 새 네트워크 서비스를 만든 뒤 접속 결과가 달라지면 현재 활성화된 네트워크 서비스의 프록시 설정을 확인하세요. 클라이언트가 실제로 수신 중인 주소와 포트를 가리켜야 합니다. 모든 프록시 프로토콜을 무작정 선택하지 마세요. HTTP, HTTPS, SOCKS를 설정해야 하는지는 클라이언트의 자동 설정과 사용하는 앱의 요구 사항을 따르세요.

TUN, 절전 모드 해제 후 연결, 종료 뒤 네트워크

시스템 프록시가 작동하는지 확인한 다음 TUN이 필요한지 검토하세요. TUN을 켜기 전에 현재 빌드의 권한 안내를 읽고 보조 구성 요소나 네트워크 관련 권한을 필요한 대로 허용하세요. 다른 가상 네트워크 도구가 기본 경로를 동시에 처리하고 있지 않은지도 확인해야 합니다. TUN을 켠 뒤 일반 네트워크가 오히려 작동하지 않으면 먼저 TUN을 끄고 시스템 프록시 모드가 여전히 정상인지 확인하세요. 스위치가 켜졌다는 이유만으로 가상 인터페이스, 라우팅, DNS가 모두 정상적으로 설정됐다고 볼 수는 없습니다. 로그에서 코어의 권한 부족, 인터페이스 생성 실패, 라우팅 설정 실패 여부를 확인하세요.

Mac이 절전 모드에서 깨어나거나 네트워크 핫스팟이 바뀌거나 외장 도크를 연결한 뒤에는 기존 연결이 끊겼을 수 있습니다. 먼저 현재 네트워크가 작동하는지 확인한 다음 클라이언트를 다시 연결하세요. 특정 앱만 문제가 있다면 완전히 종료했다가 다시 열어 끊긴 연결을 계속 사용하는 상황을 피하세요. 브라우저는 정상인데 터미널은 실패하는 경우도 흔합니다. 많은 명령줄 프로그램은 시스템 프록시를 따르지 않으므로 프록시 인수를 별도로 지정해야 할 수 있습니다. 반대로 터미널이 작동한다고 브라우저의 별도 프록시 설정이나 확장 프로그램이 영향을 주지 않는 것은 아닙니다. 테스트할 때 접속 경로를 구분하세요.

정상적으로 종료하기 전에 시스템 프록시를 해제하고 TUN을 끄세요. 앱이 비정상 종료된 뒤 웹페이지가 열리지 않으면 현재 네트워크 서비스의 프록시 설정을 열어 중지된 로컬 포트를 가리키는지 확인하세요. 이번 클라이언트가 설정한 항목임을 확인한 다음 제거하세요. 출처를 모르는 조직 관리 프록시 설정은 삭제하지 마세요. 같은 네트워크의 기기와 연결을 공유하려면 상대 기기에 이 기기의 루프백 주소만 알려줘서는 안 됩니다. 수신 범위와 방화벽도 별도로 설정해야 합니다. 자세한 내용은 LAN 연결 허용 안내를 참고하세요.

플랫폼 / Windows

Windows: 데스크톱 버전, WPF, 프록시 적용

인터페이스 버전을 선택하고 실행 데이터 폴더 분리

Windows 다운로드에서 v2rayN 데스크톱 버전과 클래식 WPF 버전을 받을 수 있습니다. 데스크톱 버전은 새로운 크로스 플랫폼 인터페이스를 사용하고 WPF 버전은 기존 Windows 인터페이스를 유지합니다. 두 버전 모두 GUI 클라이언트이며, 인터페이스가 다르다고 서버 프로토콜까지 본질적으로 다른 것은 아닙니다. 기기 아키텍처와 설치 파일 안내에 맞춰 선택하고, 실행 구성 요소가 없다는 명확한 메시지가 표시될 때 해당 안내에 따라 처리하세요. 다른 사용자의 스크린샷만 보고 내 기기에 특정 종속성이 반드시 없다고 판단하지 마세요. 출처가 불분명한 런타임 구성 요소 모음을 테스트 목적으로 한꺼번에 설치하지도 마세요.

설치하거나 압축을 푸는 위치에 쓰기 권한이 있는지 확인하고 읽기 전용 폴더나 압축 파일의 임시 보기에서 직접 실행하지 마세요. 두 인터페이스를 비교해야 한다면 각각 별도의 프로그램 및 데이터 위치를 사용하세요. 필요한 설정을 먼저 내보내고 두 프로세스가 같은 데이터를 동시에 수정하게 두지 마세요. 작업 표시줄이나 트레이에 이전 인스턴스가 남아 있는지도 확인하세요. 프로그램을 여러 번 실행하면 포트 충돌이 생길 수 있고, 실제로 시스템 프록시를 적용하는 인스턴스가 다른데도 변경 사항이 반영되지 않은 것처럼 보일 수 있습니다. 창을 닫으면 프로그램이 종료되는지는 트레이와 프로세스 상태로 확인하세요.

구독 업데이트와 시스템 프록시 설정은 별개의 단계

구독 그룹을 추가한 뒤 업데이트하고 서버 목록에서 현재 서버를 선택하세요. 먼저 업데이트 로그에서 콘텐츠를 정상적으로 가져왔는지 확인한 다음 서버 연결을 확인해야 합니다. 다른 기기에서 링크를 복사했다면 줄바꿈, 공백, 마지막 쿼리 매개변수가 빠지지 않았는지 특히 주의하세요. 메신저에서는 표시되는 텍스트와 실제 링크가 다를 때도 있습니다. 가져온 항목의 이름은 정상인데 연결에 실패하면 프로토콜, 보안 계층, 전송 항목이 모두 있는지 확인하세요. 서버 이름만으로 설정이 동일하다고 판단하지 마세요. 직접 수정하기 전에 원본 정보를 저장해 두세요.

‘시스템 프록시 자동 설정’을 켜면 Windows 사용자 프록시 설정을 따르는 앱이 로컬 프록시를 사용합니다. 브라우저에서 접속할 수 있어도 시스템 서비스, 백그라운드 업데이트 프로그램, 모든 명령줄 도구가 같은 경로를 사용하는 것은 아닙니다. 일부 프로그램은 별도 프록시 설정이나 다른 네트워크 인터페이스를 사용합니다. 처음 테스트할 때는 기본 사용자 권한을 유지하세요. TUN 또는 시스템에서 명확히 권한을 요청하는 작업에만 더 높은 권한을 허용하세요. 관리자 권한으로 계속 실행해도 잘못된 구독이나 맞지 않는 서버 설정은 해결되지 않으며, 오히려 권한 문제와 설정 문제를 혼동하게 됩니다.

방화벽, TUN, 포트 충돌 문제 해결

로그에 포트 바인딩 실패가 표시되면 다른 프록시 프로그램을 종료하고 이전 v2rayN 프로세스가 남아 있는지 확인한 뒤 로컬 포트를 변경할지 검토하세요. 포트를 바꾸면 프록시를 직접 입력한 앱도 모두 함께 수정해야 하며 시스템 프록시도 다시 적용해야 합니다. 방화벽 허용 여부는 프로그램 출처, 네트워크 유형, 사용 범위를 고려해 판단하세요. 한 기기에서만 사용할 때는 일반적으로 LAN에 대한 인바운드 접속을 열 필요가 없습니다. 문제를 확인한다고 방화벽 전체를 끄지 말고 차단된 프로그램이나 연결을 찾은 다음 범위를 제한한 규칙을 추가하세요.

TUN은 가상 네트워크 인터페이스, 라우팅, 권한을 사용하므로 먼저 시스템 프록시 모드가 정상인지 확인하세요. 기기에서 다른 가상 네트워크 도구도 실행 중이면 기본 경로, DNS, 네트워크 대역이 충돌할 수 있습니다. TUN을 켠 뒤 네트워크가 모두 끊기면 TUN을 중지해 일반 연결을 복구하고 인터페이스 생성 및 라우팅 관련 로그를 확인하세요. 다른 도구를 끈 뒤 정상으로 돌아온다면 클라이언트를 반복해서 재설치하지 말고 각 도구가 처리하는 트래픽 범위를 하나씩 비교하세요. 원격 데스크톱 환경에서는 라우팅 변경으로 현재 관리 연결이 끊길 수 있으니 더욱 주의해야 합니다.

네트워크를 복구할 때는 클라이언트에서 시스템 프록시를 해제한 다음 프로그램을 종료하세요. 클라이언트가 충돌한 경우 Windows 프록시 설정에서 수동 프록시가 남아 있는지 확인할 수 있습니다. 자동 구성 스크립트와 수동 프록시는 별도의 설정 경로입니다. 조직에서 제공한 스크립트를 사용하는 기기라면 이를 함께 지우지 마세요. 시스템 절전이나 네트워크 전환 뒤 문제가 생겨도 앱을 재설치하기 전에 연결을 다시 시작해 보세요. 업그레이드 전에는 구독 출처와 사용자 지정 라우팅을 저장하세요. 업그레이드 후에는 먼저 기존 시스템 프록시 흐름을 확인하고 추가 기능을 켜세요. 그래야 문제가 업그레이드 때문인지 새 설정 때문인지 알 수 있습니다.

플랫폼 / Linux

Linux: 패키지, 데스크톱 프록시, 권한 범위

아키텍처와 배포판 패키지 형식을 모두 확인

Linux에 설치하기 전 두 가지를 확인해야 합니다. 프로세서가 x86_64인지 aarch64인지, 배포판에서 deb와 rpm 중 어떤 패키지를 사용하는지 확인하세요. 첫 번째는 프로그램 실행 가능 여부를, 두 번째는 시스템 패키지 관리자로 설치할 수 있는지를 결정하며 서로 대신할 수 없습니다. Linux 다운로드에서 아키텍처와 형식에 맞는 v2rayN을 선택하세요. 그래픽 설치 프로그램에서 패키지를 처리하지 못하면 오류 메시지를 살펴 아키텍처 불일치, 종속성 누락, 시스템 환경 미충족을 구분하세요. 모든 설치 실패를 파일 손상으로 단정하지 마세요.

아래 읽기 전용 명령을 터미널에서 실행해 환경을 확인할 수 있습니다. uname -m의 x86_64는 일반적으로 x64, aarch64는 arm64에 해당합니다. 배포판 이름과 버전 정보는 패키지 관리 체계를 파악하는 데 도움이 되지만, 같은 형식의 패키지라면 무엇이든 호환된다는 뜻은 아닙니다. 종속성은 해당 배포판의 공식 저장소와 패키지 관리 절차를 사용해 설치하고, 출처가 불분명한 여러 곳에서 저수준 라이브러리를 모아 설치하지 마세요. 프로그램이 시작 직후 종료된다면 데스크톱 앱 실행 기록이나 터미널 출력에서 오류를 확인하고 그래픽 환경 문제인지 코어 실행 문제인지 먼저 구분하세요.

uname -m
cat /etc/os-release

구독을 가져온 뒤 데스크톱 환경의 프록시 설정 확인

v2rayN을 실행한 뒤 구독 그룹을 만들고 주소를 저장해 서버 목록을 업데이트한 다음 현재 서버를 선택하세요. Linux의 클립보드는 데스크톱 세션에서 관리되므로 원격 세션, 디스플레이 프로토콜 변경, 권한 변화에 따라 읽기 실패가 발생할 수 있습니다. 클립보드에서 가져와도 반응이 없다면 현재 사용자 클립보드에 링크가 있는지 확인하고 필요하면 클라이언트의 직접 입력 기능을 사용하세요. 클립보드 읽기 실패를 프로토콜 미지원으로 오해하지 마세요. 이 문제 때문에 클라이언트 전체를 높은 권한으로 실행하면 데이터 소유권과 데스크톱 세션이 어긋날 수 있습니다.

데스크톱 환경마다 시스템 프록시를 구현하는 방식이 다릅니다. 클라이언트의 자동 설정이 완료된 뒤에는 모든 배포판이 같은 방식으로 작동한다고 가정하지 말고 현재 데스크톱 환경의 네트워크 프록시 설정을 확인하세요. 브라우저는 데스크톱 프록시를 읽을 수 있지만 터미널 프로그램은 자체 매개변수나 프록시 환경 변수를 사용하는 경우가 많습니다. 이미 실행 중인 프로세스가 환경 변경을 다시 읽지 않을 수도 있습니다. 테스트할 때 특정 명령에 프록시를 임시로 지정하면 ‘코어 연결이 정상인지’와 ‘데스크톱 프록시 설정이 적용되는지’를 나눠 확인할 수 있습니다. 진단 명령은 문제 해결 절에서 안내합니다.

루프백 수신과 TUN 권한 이해하기

이 기기에서만 사용할 경우 루프백 주소에 바인딩하는 것이 좋습니다. 모든 네트워크 인터페이스에 바인딩하면 기기에서 연결하기 편해질 뿐 아니라 같은 네트워크의 다른 기기에도 포트가 노출될 수 있으므로 방화벽과 접근 제어를 함께 고려해야 합니다. 서버 목록에서 선택하는 원격 주소와 로컬 연결을 받는 수신 주소는 서로 다른 설정입니다. 포트를 이미 사용 중이라면 이전 클라이언트나 다른 프록시 프로세스가 있는지 확인하세요. 포트를 바꾼 뒤에는 데스크톱 프록시를 다시 적용하고 터미널이나 앱에 직접 입력한 주소도 업데이트해야 합니다. 그렇지 않으면 새 코어는 정상적으로 수신하는데 앱은 이전 주소로 계속 접속하게 됩니다.

TUN은 일반적으로 가상 인터페이스 생성과 라우팅 변경 권한이 필요하며, 구체적인 승인 방식은 배포판과 클라이언트 빌드에 따라 다릅니다. 클라이언트의 명시적인 안내에 따라 권한을 설정하고 프로그램 폴더 전체에 광범위한 권한을 부여하지 마세요. 먼저 일반 사용자 권한으로 구독과 설정을 관리한 뒤 네트워크 기능에 명확히 필요한 권한만 처리하세요. 다른 사용자로 실행하면 데이터 폴더가 달라져 ‘서버 목록이 사라진’ 것처럼 보일 수 있습니다. 이때는 실행 사용자와 데이터 위치를 먼저 확인하고 기존 폴더를 바로 덮어쓰지 마세요. 빈 화면이 표시된다고 원래 자료가 삭제된 것은 아닙니다.

네트워크에 문제가 생기면 컨테이너 네트워크, 다른 터널, 사용자 지정 라우팅이 함께 있는지 확인하세요. TUN이 처리하는 범위와 겹칠 수 있습니다. TUN을 끈 뒤 문제가 해결되면 원격 서버 설정 대신 라우팅과 DNS부터 확인하세요. 종료 전에 데스크톱 프록시를 복구하고 비정상 종료 뒤에는 시작 스크립트에서 프록시 환경 변수를 계속 설정하는지 확인하세요. 유지 관리 시 정상적으로 작동하는 설정 사본을 보관하세요. 업데이트 후에는 프로그램 실행, 구독 업데이트, 시스템 프록시, TUN의 네 단계를 확인해 데스크톱 환경 변경을 클라이언트 자체의 문제로 오해하지 않도록 하세요.

플랫폼 / Android

Android: v2rayNG, v2flyNG, VPN 권한

먼저 코어를 고른 뒤 설치 파일 아키텍처 선택

Android 다운로드에서는 Xray 코어를 사용하는 v2rayNG를 우선 권장합니다. V2Fly 코어를 사용하는 v2flyNG는 해당 코어와의 호환성이 필요한 경우 선택할 수 있습니다. 이름이 비슷하다는 이유로 번갈아 사용하지 말고 서버 프로토콜과 전송 설정을 기준으로 선택하세요. 최근 출시된 일반적인 기기는 대개 arm64를 선택할 수 있습니다. 범용 패키지는 더 많은 아키텍처를 지원하지만 용량이 더 큰 편입니다. 설치 프로그램에서 패키지를 분석할 수 없거나 호환되지 않는다고 표시되면 시스템 요구 사항, 다운로드 완료 여부, 아키텍처를 확인하세요. 모든 오류를 기기의 성능 부족으로 돌려서는 안 됩니다.

브라우저나 파일 관리자에서 설치 파일을 열면 Android에서 해당 출처의 앱 설치를 허용하라고 요청할 수 있습니다. 실제로 사용하는 출처에만 필요한 권한을 허용하고 설치가 끝나면 보안 설정에 따라 권한을 다시 해제할 수 있습니다. 기존 클라이언트를 업데이트할 때 서명, 설치 출처, 패키지 식별자가 달라 덮어쓰기가 거부될 수 있습니다. 먼저 필요한 구독과 사용자 지정 설정을 저장한 뒤 이전 여부를 판단하세요. 앱을 바로 삭제하면 내부 데이터가 영향을 받으므로 첫 번째 해결 방법으로 삼지 마세요. 특히 팝업의 ‘업데이트 실패’ 메시지를 보고 기존 서버 설정도 반드시 사용할 수 없다고 생각하지 마세요.

가져오기, 업데이트, 서비스 시작

v2rayNG의 구독 그룹 설정에서 주소를 추가하고 저장한 뒤 구독을 업데이트하세요. 서버 목록으로 돌아가 항목 하나를 선택합니다. 단일 공유 링크를 받았다면 클립보드 또는 QR 코드 가져오기를 사용할 수 있습니다. QR 코드는 설정을 전달하는 수단일 뿐이며 텍스트 링크보다 더 많은 매개변수를 포함하는 것은 아닙니다. 방금 가져온 서버가 현재 선택되어 있는지 확인하세요. 목록을 업데이트한 뒤 이전 항목에 계속 연결하는 경우가 있습니다. v2flyNG는 메뉴 이름이 다를 수 있지만 원격 구독 업데이트와 단일 설정 가져오기를 구분해야 합니다. 일반 웹페이지 주소를 구독 주소로 사용하지 마세요.

연결을 시작하면 Android에서 VPN 연결 권한을 요청합니다. 이 권한은 클라이언트가 Android 가상 네트워크 인터페이스를 통해 트래픽을 처리하도록 허용하지만 서버 연결 성공을 뜻하지 않으며 모든 앱이 원격 프록시를 사용한다는 의미도 아닙니다. 상태 표시줄에 연결 표시가 나타나면 트래픽 처리 기능이 작동 중이라는 뜻일 뿐입니다. 클라이언트 로그와 실제 접속 결과도 확인해야 합니다. 데스크톱에서 ‘시스템 프록시 설정’을 적용하던 방식을 그대로 사용하지 마세요. Android 클라이언트는 일반적으로 시스템 VPN 서비스를 통해 연결 경로를 만들며, 라우팅 규칙에 따라 일부 요청은 직접 연결될 수 있습니다.

앱별 라우팅과 백그라운드 유지

앱별 프록시는 ‘선택한 앱만 프록시 사용’과 ‘선택한 앱 우회’처럼 반대되는 동작을 할 수 있습니다. 실제 동작은 인터페이스 안내를 확인하세요. 설정을 바꾼 뒤에는 서비스를 중지했다가 다시 시작하고 대상 앱을 테스트해 이전 연결이 기존 경로를 계속 사용하는 상황을 피하세요. 문제를 찾을 때는 먼저 앱별 필터를 끄고 처리 범위를 명확하게 하세요. 기본 연결이 정상인지 확인한 다음 예외를 하나씩 추가합니다. 웹페이지는 열리는데 특정 앱이 작동하지 않는다면 해당 앱의 별도 DNS, 지속 연결, 계정 상태, 서비스 정책도 원인일 수 있습니다. 한 번 실패했다고 클라이언트의 프로토콜 설정 전체를 바꾸지 마세요.

화면이 켜져 있을 때는 정상인데 잠금 후 연결이 끊긴다면 배터리 최적화, 백그라운드 활동, 제조사의 자동 실행 관리 설정을 확인하세요. 필요한 클라이언트에만 제한을 완화하고 시스템 절전 기능 전체를 끌 필요는 없습니다. 시스템에서 상시 알림을 제한하면 백그라운드 서비스 유지에도 영향을 줄 수 있습니다. Wi-Fi에서 모바일 데이터로 전환한 뒤에는 시스템의 전환이 끝날 때까지 기다린 다음 연결을 다시 시작해 테스트하세요. 특정 네트워크에서만 실패한다면 구독을 바로 삭제하지 말고 네트워크 권한과 서버 접속 가능성을 비교하세요. 모바일 신호, 데이터 요금제 제한, 핫스팟 환경도 결과에 영향을 줍니다.

처음부터 항상 켜기나 VPN을 사용하지 않는 연결 차단 같은 시스템 정책을 바로 활성화하지 마세요. 재부팅, 화면 잠금, 네트워크 전환 후에도 클라이언트 연결이 복구되는지 먼저 확인해야 합니다. 그렇지 않으면 강제 차단 정책으로 일반 네트워크까지 사용할 수 없게 됩니다. 네트워크가 완전히 끊기면 먼저 연결을 중지해 시스템 네트워크를 복구하고 클라이언트 로그를 확인하세요. v2flyNG로 바꾸는 것이 모든 문제의 해결책은 아닙니다. 프로토콜이나 코어 호환성 차이가 명확한 경우에만 비교해 보세요. 이전할 때는 서버 항목만 복사하지 말고 라우팅, DNS, 앱별 규칙도 다시 확인해야 합니다.

설정 / 구독 및 서버 정보

구독 관리: 형식, 업데이트, 기기 간 동기화

원격 구독, 공유 링크, 전체 설정 구분하기

원격 구독 주소는 클라이언트가 설정 내용을 요청하는 경로이며 보통 HTTPS 주소입니다. 단일 공유 링크는 vmess://, vless:// 등의 프로토콜 접두사로 시작하며 하나의 연결 정보를 나타냅니다. 전체 JSON 설정에는 인바운드, 아웃바운드, DNS, 라우팅이 함께 들어갈 수 있습니다. 이 세 가지는 서로 바꿔 쓸 수 있는 텍스트가 아닙니다. 길게 인코딩된 문자열이라고 해서 겉모습만으로 구독인지 단일 링크인지 판단할 수 없습니다. 출처 안내와 클라이언트에서 지원하는 가져오기 방법을 확인하세요. 원본 데이터가 손상될 수 있으므로 반복해서 변환하지 마세요.

일부 구독은 여러 공유 링크를 Base64로 인코딩하며, 다른 구독은 클라이언트가 이해할 수 있는 구조화된 데이터를 그대로 반환합니다. Base64는 인코딩 방식이지 접근 권한을 보호하는 암호화가 아닙니다. 구독을 처리할 수 있는지는 브라우저에서 링크가 열리는지뿐 아니라 반환 형식과 코어 호환성에 따라 달라집니다. 가져오기 방법의 자세한 비교는 구독 가져오기, Base64, URI 형식 안내를 참고하세요. 서버에서 로그인 페이지, 오류 페이지, 인증 페이지를 반환하면 클라이언트가 서버 목록으로 해석하지 못하는 경우가 많습니다.

업데이트 실패를 요청 단계와 파싱 단계로 구분

구독 그룹을 저장했다면 주소가 로컬 설정에 입력된 상태일 뿐입니다. 업데이트를 실행한 뒤 먼저 클라이언트가 원격 응답을 받았는지, 그다음 응답을 파싱할 수 있었는지 확인하세요. 연결 시간 초과와 인증서 검증 오류는 요청 단계의 문제입니다. 지원되지 않는 형식이나 빈 콘텐츠 메시지가 표시되면 응답 내용과 구독 종류를 확인해야 합니다. 업데이트에 실패했다고 기존에 작동하던 항목을 바로 삭제하지 마세요. 현재 그룹과 로그를 보관하고 주소 만료 여부, 쿼리 매개변수 누락 여부, 시스템 시간을 확인하세요. 로그를 공개적으로 공유하기 전에는 전체 구독 주소와 계정 식별 정보를 가리세요.

업데이트가 프록시를 사용하는지는 클라이언트의 업데이트 옵션과 구현에 따라 달라집니다. 현재 네트워크에서 구독 주소에 직접 연결할 수 없고 기존 프록시가 실제로 작동하는 것을 확인한 경우에만 프록시를 통한 업데이트 옵션을 시도하세요. 사용할 수 있는 서버가 없는데 이 옵션을 켜면 순환 의존성이 생길 수 있습니다. 서버를 받아오려면 업데이트가 필요한데 업데이트를 하려면 서버가 필요한 상황입니다. 이때는 직접 접속할 수 있는 업데이트 경로를 복구하거나 설정 제공자에게 현재 네트워크에 맞는 가져오기 방법을 문의하세요. 출처를 모르는 노드를 계속 바꾸며 요청을 반복하지 마세요.

구독 그룹과 수동 설정의 유지 방식

출처나 용도에 따라 구독 그룹을 나누면 각 서버를 어떤 주소에서 관리하는지 파악하기 쉽습니다. 구독 업데이트 과정에서 항목을 다시 만들거나 이름을 갱신하고 필드를 덮어쓸 수 있으므로 수동 수정한 서버 설정이 계속 유지된다고 가정하지 마세요. 매개변수를 시험해야 한다면 별도 설정으로 복사해 원래 구독을 자동으로 따라가지 않는다는 점을 표시하고 변경 이유를 기록하세요. 업데이트 후에는 현재 서버를 다시 확인해야 합니다. 이름이 같아도 주소나 전송 설정이 달라졌을 수 있습니다. 기존 연결을 다시 만드는지는 클라이언트 동작에 따라 달라집니다.

기기 간 동기화는 주로 서버 정보를 공유할 뿐 라우팅, DNS, 앱별 필터, 시스템 프록시, TUN 권한까지 함께 옮겨 주지는 않습니다. Mac의 프로세스 규칙을 Android의 앱 규칙에 그대로 적용할 수도 없습니다. QR 코드는 소량의 단일 설정 정보를 전달할 때 적합하고, 전체 내보내기 파일은 로컬 설정을 옮길 때 편리하지만 대상 클라이언트가 같은 형식을 가져올 수 있는지 확인해야 합니다. 여러 기기에서 동기화하는 방법을 참고해 서버 출처를 동기화할지 클라이언트 동작 전체를 옮길지 먼저 결정한 다음 방법을 선택하세요.

실제 필요에 맞춰 업데이트 빈도를 정하고 문제를 해결한다며 지나치게 자주 새로고침하지 마세요. 여러 기기에서 동시에 목록이 비어 있다면 출처 상태와 반환 형식을 먼저 확인한 뒤 클라이언트 호환성을 각각 살펴보세요. 한 기기에서만 실패한다면 로컬 네트워크, 프록시 업데이트 옵션, 시스템 시간을 우선 비교하세요. 설정 제공자가 항목을 취소하거나 교체해도 기존 클라이언트에 이름이 남아 있다고 연결할 수 있는 것은 아닙니다. 정리하기 전에 그룹의 소유 관계를 확인해 수동 설정까지 함께 삭제하지 않도록 하세요. 쉽게 중복될 수 있는 서버 표시 이름만 기억하지 말고 복구에 필요한 정보를 남겨 두세요.

설정 / 인바운드, 아웃바운드, 해석

라우팅 및 DNS: 요청 흐름에 따라 설정 이해하기

버튼 이름이 아니라 인바운드에서 아웃바운드까지 살펴보기

요청은 일반적으로 로컬 인바운드로 들어온 뒤 라우팅 규칙에 따라 아웃바운드로 전달됩니다. inbounds는 로컬 수신 방식을, outbounds는 실제 연결 경로를, routing은 둘 사이의 선택 규칙을 정의합니다. 시스템 프록시와 TUN은 트래픽이 클라이언트로 들어오는 방법을 처리하고, 라우팅은 들어온 뒤 어떻게 처리할지를 결정합니다. ‘전역’은 일반적으로 클라이언트가 처리하는 요청을 프록시 아웃바운드로 보내려는 모드이며, 모든 앱에 클라이언트를 강제로 사용하게 하는 것은 아닙니다. ‘규칙’ 모드는 조건에 따라 프록시, 직접 연결, 차단을 선택합니다. 인터페이스에 표시된 이름도 결국 실제 설정 내용에 반영됩니다.

아래는 로컬 인바운드와 태그의 관계를 확인하기 위한 최소 V2Ray 설정 예시입니다. 직접 연결 및 차단 아웃바운드만 포함하며 원격 프록시 연결을 제공하지 않고 클라이언트가 자동으로 생성한 실행 파일을 대체하기 위한 설정도 아닙니다. 두 포트는 설명을 위한 예시이므로 기기에서 이미 사용 중이라면 동시에 시작할 수 없습니다. 루프백 수신은 로컬 접근으로 제한합니다. direct와 block은 사용자 지정 태그이며 실제 동작은 각각 freedom과 blackhole 프로토콜이 결정합니다. 태그 이름을 코어의 기본 기능으로 오해하지 않도록 이 점을 이해해야 합니다.

{
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": { "udp": true }
    },
    {
      "tag": "http-in",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ],
  "outbounds": [
    { "tag": "direct", "protocol": "freedom", "settings": {} },
    { "tag": "block", "protocol": "blackhole", "settings": {} }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

규칙은 순서대로 적용되며 리소스 파일도 결과에 영향을 줍니다

일반적인 라우팅 설정은 규칙을 위에서부터 검사해 처음 일치한 규칙을 적용합니다. 따라서 구체적인 예외를 광범위한 조건보다 앞에 두는 것이 보통입니다. outboundTag는 실제로 존재하는 아웃바운드 태그와 일치해야 하며 철자가 틀려도 자동으로 수정되지 않습니다. 어떤 규칙에도 일치하지 않을 때 사용할 기본 경로는 코어 설정과 클라이언트의 생성 방식에 따라 확인해야 합니다. config.json 구조 해설을 읽을 때는 한 줄만 잘라 최종 연결 경로를 판단하지 말고 전체 아웃바운드 목록과 규칙을 함께 살펴보세요.

geosite는 도메인 목록, geoip는 IP 주소 목록을 뜻합니다. 어떤 대상에도 자동으로 적용되는 마법의 키워드는 아닙니다. 관련 규칙을 사용하기 전에 현재 코어가 해당 문법을 지원하고 필요한 리소스 파일을 불러올 수 있는지 확인하세요. 도메인 목록이나 IP의 지리적 위치 정보만으로 특정 서비스의 정책을 대신할 수도 없습니다. 여러 주소를 사용하는 서비스, 콘텐츠 전송, 규칙 데이터 변경에 따라 일치 결과가 달라집니다. 중국 본토 내 직접 연결 같은 설정을 구성하려면 먼저 대상 범위를 명확히 정하고 geosite·geoip 라우팅 규칙 안내를 참고한 뒤 로그에서 실제 결과를 확인하세요.

시스템 DNS, 코어 DNS, 원격 DNS 구분

DNS 조회는 앱, 운영체제, 클라이언트 코어, 원격 연결 상대편에서 이루어질 수 있습니다. 시스템 DNS만 변경해도 모든 프록시 요청의 조회 경로가 바뀌는 것은 아닙니다. 앱이 별도의 암호화 DNS를 사용하면 시스템 설정을 우회할 수도 있습니다. domainStrategy는 라우팅 판단에서 언제 도메인 조회가 필요한지를 정하는 옵션이지, 특정 값으로 설정하면 모든 DNS 요청이 원격에서 처리되는 전역 스위치가 아닙니다. 일반적인 IPIfNonMatch는 도메인 규칙에 일치하지 않을 때 조회를 통해 IP 규칙과의 추가 일치를 시도하지만 구체적인 동작은 사용하는 코어의 설정 의미를 확인해야 합니다.

DNS 문제를 진단할 때는 도메인이 먼저 정상적으로 조회됐는지 확인한 다음 주소를 얻은 뒤 연결이 이루어졌는지 살펴보세요. 인증서 이름이 일치하지 않는다고 인증서 검증을 꺼서 문제를 숨기지 마세요. 대상 도메인, 보안 계층의 서버 이름, 네트워크에서 인증 페이지가 뜨는지 확인해야 합니다. TUN을 사용하는 경우 DNS 요청이 처리 대상에 포함되는지, DNS 서버에 접속할 수 있는지, 순환 의존성이 생기지 않는지도 살펴보세요. DNS 경로는 한 번에 하나씩 변경하고 변경 전후 로그를 기록하세요. DNS, 규칙, 서버를 동시에 바꾸면 연결이 복구되더라도 원인을 알 수 없습니다.

문제 해결 / 현상에서 원인 단계 찾기

설정 문제 해결: 단계별 확인 및 복구

기본 네트워크와 로컬 수신부터 확인

접속할 수 없다면 먼저 TUN을 끄고 시스템 프록시를 해제한 다음 다른 트래픽 처리 도구도 중지해 일반 네트워크가 정상인지 확인하세요. 호텔이나 공용 네트워크에서는 웹페이지 인증을 먼저 완료해야 할 수 있습니다. 기본 네트워크 자체가 연결되지 않은 상태라면 서버를 계속 바꾸는 것은 의미가 없습니다. 일반 네트워크가 복구되면 클라이언트를 시작해 코어 실행 상태를 확인하세요. ‘연결 거부’가 로컬 루프백 주소에서 발생했다면 원격 서버 암호보다 수신 여부와 포트 오류를 먼저 확인하는 것이 좋습니다. 같은 오류 문구라도 대상 주소에 따라 진단 방향이 다릅니다.

클라이언트가 실행 중으로 표시되는데 모든 앱에서 연결할 수 없다면 로컬 수신 포트를 확인한 뒤 프록시를 직접 지정한 요청으로 시스템 설정의 영향을 분리하세요. 아래 명령은 curl을 사용할 수 있는 데스크톱 환경용이며 로컬 SOCKS 포트가 10808이라고 가정합니다. 실행하기 전에 클라이언트에 표시된 실제 포트로 바꾸세요. socks5h는 도메인 조회를 프록시 측에서 처리하도록 합니다. 명령에 사용한 사이트는 일반 HTTPS 테스트 대상입니다. 테스트에 성공해도 이 연결 경로가 작동한다는 뜻일 뿐 모든 앱이나 프로토콜이 트래픽을 처리한다는 의미는 아닙니다.

curl --proxy socks5h://127.0.0.1:10808 \
  --connect-timeout 10 \
  --max-time 20 \
  --head https://example.com/

프록시를 직접 지정한 요청은 성공하지만 브라우저가 실패한다면 현재 네트워크에 시스템 프록시가 적용됐는지, 브라우저에 별도 프록시 설정이 있는지, 확장 프로그램이 설정을 덮어쓰는지 확인하세요. 직접 지정한 요청도 실패한다면 코어 로그를 확인해 로컬 연결, 원격 서버 연결, 핸드셰이크 중 어느 단계에서 오류가 발생했는지 구분하세요. 터미널에서 성공했다고 Android에도 그대로 적용되는 것은 아닙니다. 모바일에서는 클라이언트 로그와 앱별 접속 결과를 비교하세요. 테스트 중에는 같은 서버와 같은 대상을 유지한 채 변수를 먼저 통제하고 비교 항목을 바꿔야 네트워크 변동을 문제 원인으로 오해하지 않습니다.

오류 유형에 따라 다음 단계 결정

연결 시간 초과가 발생하면 대상 주소와 포트, 현재 네트워크의 연결 가능 여부, 서버 상태를 우선 확인하세요. 인증 실패라면 인증 정보와 프로토콜 항목을 확인합니다. TLS 핸드셰이크 실패는 시스템 시간, 보안 계층의 서버 이름, 전송 설정, 서버 측 요구 사항을 살펴보세요. 필드가 비어 있다고 반드시 잘못된 것은 아니며 다른 설정에서 값을 임의로 복사해 넣어서도 안 됩니다. 전송 매개변수는 서로 맞춰 사용하는 값이므로 하나만 바꾸면 오히려 원인을 더 파악하기 어려운 오류가 발생할 수 있습니다. 로그는 문제 범위를 좁히는 데 도움이 되지만 한 줄만으로 단일 원인을 확정하기는 어렵습니다. 변경 기록과 비교 테스트를 함께 살펴보세요.

구독 업데이트는 성공하는데 모든 서버 연결이 실패한다면 설정을 가져오는 경로가 적어도 일부 작동한다는 뜻이지 프록시 연결 설정까지 검증됐다는 뜻은 아닙니다. 일부 서버만 실패할 때는 해당 항목의 프로토콜과 전송 설정 차이를 먼저 비교하세요. 모든 서버가 동시에 실패한다면 시스템 시간, 코어 실행, 네트워크 환경 같은 공통 요소를 확인합니다. 특정 웹사이트만 문제가 있다면 DNS, 라우팅 규칙 일치 여부, 대상 서비스 상태, 계정 제한을 각각 살펴보세요. 한 서비스 때문에 전체 트래픽 모드를 바꾸거나 클라이언트의 연결 테스트를 실제 서비스 접속의 완전한 대체 수단으로 간주하지 마세요.

TUN 문제와 네트워크 복구를 따로 처리

시스템 프록시는 정상인데 TUN만 실패한다면 원격 연결 정보는 우선 의심할 대상이 아닙니다. 권한, 가상 인터페이스, 라우팅, DNS, 다른 터널과의 중복 여부를 먼저 확인하세요. TUN을 끄자마자 연결이 복구된다면 이 비교 결과를 기록해 두세요. 원격으로 기기를 관리하고 있다면 기본 경로를 바로 바꾸지 말고 로컬에서 복구할 방법을 먼저 준비하세요. 네트워크를 바꾼 뒤 문제가 생겼다면 설정 전체를 지우기 전에 트래픽 처리 서비스를 중지했다가 다시 시작해 볼 수 있습니다. 재설치해도 일부 데이터가 유지되거나 바뀔 수 있으므로 설정이 올바른지 확인하는 신뢰할 만한 방법은 아닙니다.

정상적으로 종료한 뒤 네트워크가 끊기면 시스템 프록시가 남아 있는지 확인하세요. TUN을 중지한 뒤에도 문제가 있다면 다른 네트워크 도구가 계속 실행 중인지 살펴보고 시스템의 일반 네트워크 연결부터 복구하세요. 문의를 작성하기 전 운영체제와 아키텍처, 클라이언트 이름, 트래픽 처리 모드, 오류 발생 시간, 재현 여부, 최근 변경 사항을 기록하세요. 로그에는 문제와 관련된 부분만 남기고 구독 주소, 사용자 식별 정보, 서버 인증 정보는 가리세요. ‘프록시 직접 지정은 성공하지만 시스템 프록시는 실패’처럼 비교 결과를 제공하면 ‘작동하지 않음’이라고만 쓰는 것보다 진단 경로를 찾기 쉽습니다.

기본 사용 순서를 다시 확인하려면 사용 설명서로 돌아가 가져오기, 모드 선택, 연결 확인 순으로 진행하세요. 다른 플랫폼에 설치하려면 클라이언트 다운로드 페이지에서 운영체제와 칩에 맞는 파일을 확인하세요. 구독 업데이트, 클라이언트 업그레이드, 네트워크 정책 변경은 따로 진행하고 되돌릴 수 있도록 기록을 남기세요. 설정끼리 미치는 영향을 줄이고 문제가 생겼을 때 원인이 발생한 단계를 파악할 수 있습니다. 반복적인 재설치나 여러 스위치를 동시에 바꾸는 방식에 의존하지 않아도 됩니다.