v2rayN 전체 플랫폼 설정 가이드

준비 사항: 설치 파일과 구독 정보

클라이언트, 코어, 서버의 차이부터 확인하세요

v2rayN은 서버, 구독 그룹, 프록시 모드, 라우팅 규칙을 관리하는 데스크톱 GUI 클라이언트입니다. 실제 연결은 클라이언트가 실행하는 프록시 코어가 처리합니다. Windows·macOS·Linux에서는 v2rayN을, Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 선택할 수 있으며 V2Fly 코어를 사용하는 v2flyNG도 대안입니다. GUI 클라이언트 자체는 서비스를 제공하지 않으며, 설치한다고 사용할 서버가 자동으로 생성되거나 구독 권한이 생기는 것은 아닙니다. 설정을 시작하기 전에 서비스 제공업체가 발급한 유효한 구독 주소나 연결 정보가 모두 포함된 공유 링크를 준비하세요.

구독은 업데이트할 수 있는 설정 모음이지 웹사이트 계정이나 비밀번호가 아닙니다. 서비스 이용 기간이 남아 있는지, 트래픽 제한이 있는지, 동시 접속 기기 수에 제한이 있는지 확인하세요. 서버 주소와 포트만으로는 설정을 복원하기 어려운 경우가 많으며 사용자 식별자, 전송 방식, TLS 매개변수, 서비스 이름 등이 추가로 필요할 수 있습니다. 온라인에서 찾은 예시를 보고 누락된 항목을 임의로 채우지 마세요. 잘못된 조합은 클라이언트에 저장되더라도 원격 핸드셰이크에 실패할 수 있습니다. 구독 주소에는 접속 정보가 포함되어 있으므로 복사할 때 전체 내용을 보존하고, 화면을 공유할 때는 주소 전체를 가리세요.

시스템 아키텍처를 확인하고 복구 경로를 확보하세요

설치 파일 페이지에서 운영체제에 맞는 다운로드 항목을 선택한 뒤 프로세서 아키텍처를 확인하세요. Windows에는 x64 데스크톱 버전과 클래식 WPF 버전이 있습니다. macOS는 Apple Silicon과 Intel용으로 나뉘며, Linux는 deb·rpm 패키지와 x64·arm64를 구분합니다. Android에는 arm64와 범용 버전이 제공됩니다. 파일을 다운로드할 수 있다고 해서 기기에서 실행된다는 뜻은 아닙니다. 운영체제 버전과 실행 환경 요구사항은 설치 파일 안내를 확인하세요. 오래된 시스템은 호환성을 먼저 확인하고, 클라이언트 이름이 같다는 이유만으로 기존 버전을 덮어 설치하지 마세요.

처음 설정하기 전에 다른 프록시, VPN, 수동 DNS 또는 브라우저 프록시 확장 프로그램이 활성화되어 있는지 기록하세요. 트래픽을 처리하는 도구가 여러 개 겹치면 우회되거나 순환 경로가 생길 수 있습니다. 문제를 진단하는 동안에는 프록시 경로를 하나만 명확하게 유지하세요. 기존 클라이언트가 설치된 기기라면 필요한 설정을 먼저 내보내고 기존 로컬 포트, 구독 그룹, 사용자 지정 라우팅을 기록하세요. 백업에도 접속 정보가 포함될 수 있으므로 접근이 제한된 로컬 폴더에 보관해야 합니다. 업그레이드와 UI 버전 변경은 따로 진행하세요. 설정을 계속 덮어쓰기보다 복구 가능한 이전 설정을 보관하는 편이 문제를 찾기 쉽습니다.

최소 연결 확인 순서

먼저 TUN을 켜지 않은 상태에서 클라이언트를 실행해 코어가 시작되는지 확인하세요. 구독을 가져와 서버 목록을 업데이트하고 사용할 설정을 선택한 다음 시스템 프록시를 활성화합니다. 시스템 프록시를 지원하는 브라우저로 대상 사이트에 접속해 보세요. 기본 경로가 작동하는 것을 확인한 뒤에 TUN, 사용자 지정 DNS 또는 복잡한 분할 라우팅을 추가하세요. 이 순서로 진행하면 설치, 구독, 트래픽 처리 문제를 분리할 수 있어 여러 설정을 한꺼번에 바꾼 뒤 원인을 찾지 못하는 상황을 예방할 수 있습니다.

시스템 시간도 설정 전에 확인해야 합니다. 날짜, 시간대 또는 시간 동기화가 잘못되면 인증서 검증이나 일부 프로토콜 인증에 실패할 수 있습니다. 테스트할 때는 평소 직접 접속할 수 있는 페이지를 직접 연결 기준으로 삼고, 프록시를 통해 접속할 대상도 하나 정해 각각 결과를 기록하세요. 속도 테스트에 성공했다고 해서 모든 사이트와 앱이 프록시를 사용한다는 뜻은 아닙니다. 이후에는 코어 로그, 실제 페이지 접속, 외부 IP 정보를 함께 확인하세요. 트레이 아이콘이나 연결 버튼의 색상만 보고 판단해서는 안 됩니다.

Windows: v2rayN 설치와 초기 설정

UI 버전을 선택하고 코어 실행을 확인하세요

Windows 다운로드에서 v2rayN을 선택하세요. 데스크톱 버전은 크로스 플랫폼 UI를 사용하고, WPF 버전은 클래식 Windows UI를 사용하므로 메뉴 위치와 설정 폴더가 다를 수 있습니다. 처음이라면 데스크톱 버전을 선택하고, 기존 WPF UI에 익숙하다면 해당 버전을 계속 사용해도 됩니다. 설치 프로그램의 안내에 따라 설치하세요. 압축 해제형 배포 파일을 받은 경우에는 고정된 폴더에 전체 압축을 푼 뒤 실행해야 합니다. 압축 파일 미리보기에서 바로 실행하거나 필요한 파일을 빼고 메인 프로그램만 복사하지 마세요.

일반적인 시스템 프록시 사용에는 관리자 권한으로 계속 실행할 필요가 없습니다. 처음 실행할 때 런타임 환경이 필요하다는 안내가 나오면 프로그램 지침에 따라 해당 구성 요소를 설치하세요. 구성 요소 누락을 노드 문제로 오해하지 마세요. 로그 창을 열어 클라이언트가 실행한 코어가 즉시 종료되지 않는지 확인하세요. 시작에 실패하면 보안 소프트웨어의 차단 기록, 폴더 쓰기 권한, 같은 이름의 프로세스가 남아 있는지부터 살펴보세요. 문제를 해결하려고 시스템 보호 기능을 전부 끄지 말고, 파일 출처와 오류 안내를 확인해 필요한 조치만 하세요. 프로그램을 임시 다운로드 폴더에 두면 정리 과정에서 설정이나 종속 파일이 사라질 수 있으므로 안정적인 위치에 설치하는 것이 좋습니다.

구독 그룹, 서버, 시스템 프록시 설정

구독 그룹 설정을 열고 출처를 알 수 있는 이름으로 새 그룹을 만든 다음 전체 구독 주소를 입력하고 저장하세요. 메인 화면으로 돌아와 구독을 업데이트합니다. 업데이트 방식이 여러 가지라면 처음에는 현재 프록시를 거치지 않는 방법을 우선 시도하세요. 아직 연결되지 않은 상태에서 클라이언트가 자기 자신을 통해 설정을 가져오게 하는 상황을 피할 수 있습니다. 업데이트가 끝나면 서버가 올바른 그룹에 들어왔는지 확인하고 사용할 서버를 선택하세요. 목록에서 한 줄을 강조 표시하는 것만으로 활성화되지 않을 수 있으므로 현재 UI의 활성 서버 지정 기능을 사용하고 상태가 바뀌었는지 확인하세요.

실제 연결 테스트를 실행해 목록 순서만 보지 말고 실패 원인을 확인하세요. 사용할 서버를 선택한 뒤 시스템 프록시를 '시스템 프록시 자동 설정'으로 지정하고 일반 브라우저로 테스트합니다. 초기 설정을 간단히 하려면 기존 '중국 본토 우회' 프리셋을 선택할 수 있습니다. 접속 경로를 명확히 비교해야 한다면 같은 대상에 전역 프록시 규칙을 임시로 적용해 보세요. 다만 시스템 프록시와 라우팅은 서로 다른 단계입니다. 시스템 프록시는 어떤 앱이 요청을 로컬 프록시에 보낼지 정하고, 라우팅은 코어가 요청을 받은 뒤 어떤 출구를 사용할지 결정합니다. 브라우저 프록시 확장 프로그램이 시스템 설정을 덮어쓸 수 있으므로 테스트 전에 일시 중지하세요.

TUN 권한과 Windows 관련 문제

시스템 프록시 경로가 정상인 것을 확인했는데 대상 앱이 시스템 프록시를 따르지 않는 경우에만 Tun 모드를 고려하세요. 현재 클라이언트의 안내에 따라 관리자 권한을 요청하고 필요한 구성 요소를 설치하거나 서비스를 시작한 뒤 가상 네트워크 어댑터와 코어 로그를 확인하세요. 권한을 허용했더라도 시작 오류를 무시해서는 안 됩니다. TUN이 제대로 설정되지 않아도 클라이언트 창은 정상적으로 보일 수 있습니다. 가상 어댑터 생성에 실패하거나 권한이 부족하면 남아 있는 프로세스를 종료하고 일반 시스템 프록시로 다시 테스트하세요. 네트워크 어댑터 구성 요소를 반복해서 설치하거나 물리 네트워크 어댑터와 시스템 라우팅을 임의로 삭제하지 마세요.

로컬 포트가 이미 사용 중이면 코어에 수신 대기 실패가 기록되는 경우가 많습니다. 클라이언트 설정에서 실제 포트 번호를 확인한 다음 시스템에서 포트를 사용하는 프로세스를 찾아 다른 클라이언트 인스턴스가 실행 중인지 확인하세요. 포트를 변경했다면 프록시를 수동 설정한 앱의 포트도 함께 바꿔야 합니다. 컴퓨터가 절전 모드에서 깨어나거나 유선·무선 네트워크를 전환한 뒤 연결이 끊기면 TUN을 비활성화하고 연결을 다시 설정하세요. 먼저 네트워크 자체가 복구됐는지 확인한 뒤 프록시를 점검합니다. 수동 연결이 안정된 다음에 시작 시 자동 실행을 켜고, 로그인 후 서로 다른 UI 버전 두 개가 동시에 프록시를 처리하지 않는지 확인하세요.

정상적으로 종료하기 전에 TUN을 비활성화하고 '시스템 프록시 해제'를 사용해 일반 네트워크 설정으로 복구하세요. 비정상 종료 뒤 모든 웹페이지가 열리지 않으면 Windows 프록시 설정이 이미 종료된 로컬 수신 포트를 가리키고 있는지 확인합니다. 정리할 것은 남아 있는 프록시 설정이지 네트워크 설정 전체가 아닙니다. 조직 정책으로 관리되는 기기라면 조직에서 지정한 프록시를 덮어쓰지 마세요. 자세한 첫 설치 안내는 v2rayN 첫 설치와 초기 설정을 참고하고, 문제 해결 시 폴더와 시작 항목 점검 방법을 확인하세요.

macOS: 칩 선택, 권한, 프록시 복구

칩에 맞는 설치 파일을 선택하세요

먼저 시스템의 '이 Mac에 관하여'에서 프로세서 정보를 확인하세요. Apple 칩이 표시되면 Apple Silicon 설치 파일을, Intel 프로세서가 표시되면 Intel 설치 파일을 선택합니다. 해당 파일은 macOS 설치 파일에서 받을 수 있습니다. 디스크 이미지 파일을 다운로드해 연 다음 안내에 따라 앱을 응용 프로그램 폴더로 옮기고 고정된 위치에서 실행하세요. 임시로 마운트한 이미지에서 앱을 계속 실행하지 마세요. 이미지 마운트를 해제한 뒤 로그인 항목이나 바로 가기가 존재하지 않는 위치를 가리킬 수 있습니다. 설치를 마친 다음 첫 실행 안내를 처리해 설치, 업데이트, 권한 변경을 한꺼번에 진행하지 않도록 하세요.

시스템 보안 경고가 나타나면 먼저 선택한 다운로드 페이지에서 받은 파일인지 확인하고, '개인정보 보호 및 보안'에 표시된 구체적인 안내에 따라 실행을 허용할지 결정하세요. 앱을 실행하려고 시스템 보안 기능 전체를 끄거나 출처가 불분명한 터미널 명령으로 제한을 해제하지 마세요. 설치 파일 아키텍처 불일치, 운영체제 버전 미지원, 앱 손상 경고는 서로 다른 문제이므로 각각 확인해야 합니다. 창이 열린 뒤에도 코어가 시작되는지 확인하세요. GUI가 실행된다고 코어 프로세스나 TUN 구성 요소에 필요한 실행 권한까지 확보된 것은 아닙니다.

구독을 가져오고 시스템 프록시를 확인하세요

v2rayN에서 구독 그룹을 만들고 메모와 전체 구독 주소를 입력한 뒤 저장하고 업데이트하세요. 업데이트에 실패하면 TUN을 켜지 않은 상태에서 현재 네트워크와 주소 유효성을 먼저 확인합니다. 구독 링크를 일반 서버 주소 입력란에 붙여 넣지 마세요. 업데이트에 성공하면 활성 서버를 선택해 실제 연결을 테스트한 다음 시스템 프록시 자동 설정을 켭니다. 브라우저 테스트 전에는 별도의 프록시 설정이나 확장 프로그램이 요청을 처리하고 있지 않은지 확인하세요. 네트워크를 전환하기 전후에 같은 페이지를 테스트해 대상이 달라서 클라이언트 상태를 잘못 판단하지 않도록 합니다.

macOS 프록시 설정은 일반적으로 특정 네트워크 서비스에 연결되어 있습니다. 유선, 무선, 기타 네트워크 인터페이스마다 설정이 다를 수 있으므로 인터페이스를 바꾼 뒤에는 현재 사용 중인 서비스가 올바른 로컬 포트를 가리키는지 다시 확인하세요. 업무용 기기에는 구성 프로파일이나 관리 정책이 적용될 수도 있습니다. 클라이언트가 설정을 변경할 수 없다면 제한이 어디에서 비롯됐는지 먼저 확인하세요. 시스템 프록시는 해당 설정을 따르는 앱에만 영향을 줍니다. 터미널 도구와 일부 앱은 별도의 연결 방식을 사용하므로 브라우저가 작동한다고 터미널의 모든 프로그램도 같은 프록시 경로를 사용한다고 가정하지 마세요.

TUN, 절전 모드 복귀, 종료 처리

트래픽 처리 범위를 넓혀야 할 때만 UI 안내에 따라 TUN 권한이나 보조 서비스를 설정하세요. 패키징 방식에 따라 권한 절차가 다를 수 있으므로 다른 플랫폼의 관리자 권한 절차를 그대로 따라 하지 말고 현재 프로그램의 안내를 확인합니다. 설정한 뒤 코어가 계속 실행되는지, 라우팅·장치 접근·DNS 관련 오류가 있는지 살펴보세요. 다른 VPN이 기본 경로나 DNS 설정을 사용 중이면 해당 연결을 종료한 뒤 테스트하세요. 여러 도구를 겹쳐 사용하고 기본 출구를 반복해서 바꾸면 클라이언트 로그와 실제 트래픽 경로를 대조하기 어려워집니다.

덮개를 닫아 잠자기 상태가 된 뒤에는 네트워크 인터페이스, 게이트웨이, DNS가 바뀔 수 있습니다. 먼저 직접 연결이 되는지 확인한 다음 프록시 연결을 다시 설정하세요. TUN 모드에서만 실패하고 시스템 프록시가 정상이라면 구독을 다시 가져오기보다 가상 인터페이스와 라우팅이 복구됐는지 확인해야 합니다. 로그인이 필요한 공용 네트워크에 연결할 때는 보통 트래픽 처리를 잠시 중단하고 네트워크 인증을 완료한 뒤 프록시를 다시 켭니다. 인증 페이지가 열리지 않는다고 반드시 서버 문제인 것은 아닙니다. 로컬 네트워크가 인터넷 접속을 허용하기 전일 수 있으므로 이때 서버를 반복해서 바꿔도 해결되지 않습니다.

창을 닫아도 클라이언트가 종료되지 않을 수 있으므로 메뉴 막대 상태와 백그라운드 프로세스를 확인하세요. 일반 네트워크로 복구해야 한다면 TUN을 먼저 끄고 클라이언트가 설정한 시스템 프록시를 해제합니다. 클라이언트가 비정상 종료됐다면 현재 네트워크 서비스의 프록시 설정에 로컬 프록시 주소가 남아 있는지 확인하세요. 이번 클라이언트가 설정한 항목만 삭제하고 기존 조직 설정은 유지해야 합니다. 연결 절차가 안정된 뒤 로그인 항목을 추가하세요. 업그레이드 후 이전 프로그램이 백그라운드에 남아 있으면 먼저 종료하고 새로 설치한 앱을 실행해 같은 포트를 여러 프로세스가 동시에 사용하지 않도록 합니다.

Linux: 패키지, 데스크톱 환경, 실행 권한

배포판에 맞는 패키지 형식과 아키텍처를 선택하세요

Linux 다운로드에서 v2rayN을 선택하세요. deb는 해당 패키지 관리 체계를 사용하는 배포판에, rpm은 이에 맞는 패키지 관리 체계를 사용하는 배포판에 적합합니다. x64와 arm64도 확인하세요. 파일 확장자가 같다는 이유만으로 설치해서는 안 됩니다. 아래 명령을 터미널에서 실행하면 시스템 아키텍처와 정보를 확인할 수 있습니다. 일반적으로 x86_64는 x64, aarch64는 arm64에 해당합니다. 운영체제 이름과 프로세서는 별개의 정보입니다. 컨테이너, 호환 계층, 원격 세션에서는 실제 실행 환경도 함께 고려해야 합니다.

uname -m
cat /etc/os-release

배포판의 소프트웨어 설치 프로그램이나 패키지 관리 도구를 우선 사용해 로컬 패키지를 설치하세요. 그러면 시스템이 종속성을 처리합니다. GUI 런타임 구성 요소가 없다는 메시지가 표시되면 구체적인 종속 항목을 확인하고, 종속성 검사를 강제로 무시한 채 설치를 진행하지 마세요. 설치는 됐지만 창이 열리지 않으면 터미널에서 설치된 앱을 실행해 오류 출력을 확인합니다. 디스플레이 환경, 런타임 라이브러리, 코어 시작 문제를 구분해 살펴보세요. 전체 GUI 클라이언트를 슈퍼유저 세션에서 계속 실행하지 마세요. 파일 권한이 불일치할 수 있고 이후 작업의 영향 범위도 커집니다.

구독 가져오기와 데스크톱 프록시의 차이

v2rayN을 연 뒤 먼저 구독을 가져와 서버를 업데이트하고 활성 설정을 선택하세요. 코어가 로컬 포트에서 정상적으로 수신 대기하는지 확인한 다음 프록시를 설정합니다. Linux 데스크톱 환경마다 시스템 프록시 구현 방식이 다릅니다. 일부는 통합 네트워크 프록시 패널을 제공하지만, 어떤 앱은 자체 설정이나 환경 변수를 사용합니다. 따라서 '시스템 프록시 자동 설정'이 성공해도 모든 데스크톱 앱이 이를 따르는 것은 아닙니다. 선택한 프록시 유형을 명확히 지원하는 브라우저로 먼저 테스트하고, 작동하지 않는 앱의 프록시 설정을 확인하세요. 처음부터 시스템 전체로 적용 범위를 넓히지 마세요.

터미널의 HTTP 도구에서 프록시를 명시하면 프록시 경로 문제와 데스크톱 설정 문제를 구분하는 데 도움이 됩니다. 예를 들어 아래 명령은 클라이언트 설정에서 HTTP 또는 혼합 수신 포트가 10808인 것을 확인한 경우에만 사용할 수 있습니다. 실제 포트가 다르면 실행 전에 명령을 수정하세요. 이 명령은 현재 요청만 로컬 프록시를 통해 예시 사이트에 접속하며 시스템 프록시나 다른 프로그램의 트래픽은 변경하지 않습니다. 응답 상태, 연결 오류, 클라이언트 로그가 일치하는지 확인하세요. 명령이 끝났다는 이유만으로 프록시가 정상이라고 판단하지 마세요.

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

터미널에 프록시 환경 변수를 설정했다면 테스트 시 변수의 적용 범위를 기록하세요. 한 터미널 세션의 변수가 이미 열려 있는 GUI 앱에 전달되지 않을 수 있고, GUI 앱의 설정도 터미널에 적용되지 않을 수 있습니다. 클라이언트를 종료한 뒤에도 변수가 남아 있으면 명령이 중단된 로컬 포트에 계속 요청을 보낼 수 있습니다. 먼저 프록시를 명시한 테스트 결과와 비교한 뒤 현재 세션 설정을 조정하세요. 특정 명령 하나를 작동시키려고 출처가 불분명한 프록시 변수를 전역 시작 파일에 추가하지 마세요.

TUN, DNS 관리, 권한 범위

Linux TUN은 가상 네트워크 장치, 라우팅 조작 권한, 클라이언트의 현재 실행 방식에 따라 달라집니다. 클라이언트 문서나 UI에 표시된 권한 절차를 따르고, 장치가 없거나 권한이 부족하거나 라우팅 충돌이 있다는 로그가 있는지 먼저 확인하세요. 모든 프로그램의 권한을 일괄적으로 높이거나 영향을 이해하지 못한 채 실행 파일 권한을 변경하지 마세요. 컨테이너, 제한된 데스크톱 세션, 원격 환경에는 가상 장치나 네트워크 관리 권한이 없을 수 있습니다. 이럴 때는 GUI를 계속 재시작하지 말고 앱 단위 프록시로 전환하세요.

DNS는 네트워크 관리 서비스, 시스템 해석 서비스, 수동 설정 파일의 영향을 함께 받을 수 있습니다. TUN을 켠 뒤 기존 연결은 정상인데 도메인 접속만 실패하면 클라이언트 DNS 설정과 시스템의 이름 해석 경로를 확인하고 다른 서비스가 설정을 덮어쓰는지 살펴보세요. 시스템 DNS 설정을 바로 지우지 마세요. 네트워크 서비스가 자동으로 관리하는 설정일 수 있어 다시 연결하면 값이 바뀔 수 있습니다. TUN을 끈 뒤 기본 경로와 DNS가 복구됐는지 확인하세요. 클라이언트를 종료한 상태에서 일반 네트워크를 테스트하면 원격 문제와 로컬에 남은 설정을 구분하는 데 도움이 됩니다.

부팅이나 로그인 후 자동 실행이 필요하다면 GUI 세션, 키 저장소, 네트워크가 준비됐는지 먼저 확인하세요. 로그인 시 자동 실행과 백그라운드 서비스는 서로 다른 실행 방식이므로 명확한 이유 없이 둘 다 켜지 마세요. 업그레이드 후 일반 사용자가 설정을 저장할 수 없다면 과거에 높은 권한으로 실행해 폴더 소유권이 바뀌었는지 확인하세요. 복구 전에 백업하고, 클라이언트가 실제로 사용하는 폴더만 대상으로 해야 합니다. 로그상 로컬 수신은 정상인데 브라우저가 실패한다면 서버 설정을 바꾸기 전에 데스크톱 프록시 경로부터 확인하세요.

Android: v2rayNG와 VPN 연결 관리

클라이언트를 설치하고 연결 권한을 허용하세요

Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 권장합니다. V2Fly 코어가 필요한 경우 v2flyNG를 선택할 수 있습니다. 두 앱은 별개의 클라이언트이므로 구독, 활성 서버, VPN 상태를 서로 공유한다고 가정하지 마세요. Android 다운로드에서 설치 파일을 선택하세요. 최근 기기 대부분은 arm64를 우선 확인할 수 있습니다. 아키텍처를 모르거나 arm64가 설치되지 않으면 시스템 정보를 참고해 범용 버전을 선택하세요. 범용 버전은 더 다양한 기기를 지원하지만 모든 운영체제 버전에서 실행된다는 뜻은 아닙니다. 기존 앱을 업데이트하기 전에 구독 정보와 필요한 설정을 저장하세요.

설치할 때 Android 안내에 따라 이번에 사용할 파일 출처에 설치 권한을 부여하세요. 설치가 끝나면 필요에 따라 해당 출처의 권한을 해제할 수 있습니다. 앱이 설치되지 않는다는 메시지가 표시되면 아키텍처, 저장 공간, 시스템 호환성, 기존 설치 출처를 확인하세요. 처음부터 데이터를 삭제하지 마세요. 첫 연결 시 표시되는 시스템 VPN 권한은 클라이언트가 시스템 네트워크 인터페이스를 통해 트래픽을 처리하는 데 필요한 확인 절차입니다. 권한을 허용한 뒤에도 앱 로그와 상태를 확인해야 합니다. 시스템 팝업을 승인했다고 원격 서버 연결까지 성공한 것은 아닙니다.

구독을 가져오고 서버를 선택해 연결을 확인하세요

구독 그룹 설정에서 그룹을 추가하고 전체 주소를 붙여 넣은 뒤 저장하세요. 메뉴에서 구독 업데이트를 실행합니다. 클립보드에서 공유 링크를 가져오면 단일 또는 여러 설정이 추가될 수 있지만 자동 업데이트가 가능한 구독 관계가 만들어지는 것은 아닙니다. 두 방식을 구분해 기록하지 않으면 나중에 수동으로 가져온 서버가 업데이트되지 않는 이유를 알기 어렵습니다. 구독 업데이트가 성공하면 목록에 예상한 설정이 표시되는지 확인하고 활성 서버를 선택하세요. 활성 서버가 없으면 연결 버튼을 눌러도 원격 연결이 성립하지 않습니다.

먼저 실제 연결 테스트를 실행해 사용할 수 있는 서버를 선택하고 연결 버튼을 누른 뒤 상태 변화를 확인하세요. 이어서 브라우저에서 대상 사이트에 접속하고 필요하면 외부 IP 정보와 로그도 확인합니다. 테스트는 성공했는데 특정 앱이 프록시를 사용하지 않으면 앱별 프록시 적용 범위가 설정되어 있는지 살펴보세요. 선택한 앱만 프록시를 사용하는 모드와 선택한 앱을 제외하는 모드는 의미가 반대입니다. 목록에서 앱을 선택했다고 항상 그 앱이 프록시를 사용한다는 뜻은 아니므로 현재 모드를 함께 확인해야 합니다. 앱 목록이나 라우팅을 바꾼 뒤에는 새 설정을 적용하도록 VPN 연결을 다시 시작하세요.

백그라운드 제한, 네트워크 전환, 코어 차이

Android에서는 일반적으로 같은 사용자 환경에서 활성 VPN 연결을 하나만 사용할 수 있습니다. 다른 VPN, VPN 기반 네트워크 필터링 도구, 업무 프로필이 현재 클라이언트와 충돌할 수 있습니다. 연결 직후 끊어진다면 시스템에서 다른 도구가 자동으로 다시 연결하는지 먼저 확인하세요. 앱별 라우팅과 시스템 VPN의 트래픽 적용 범위도 함께 확인해야 합니다. 코어 라우팅만 바꾼다고 모든 앱이 프록시를 사용하는 것은 아닙니다. 데스크톱의 시스템 프록시 개념을 Android에 그대로 적용하지 마세요. Android에서는 보통 클라이언트가 시스템 VPN 서비스를 통해 로컬 트래픽 처리 경로를 만듭니다.

화면을 끈 뒤 연결이 끊기지만 앱으로 돌아오면 바로 복구된다면 배터리 최적화와 백그라운드 실행 제한을 확인하세요. 기기 시스템 설정에서 필요한 백그라운드 실행을 허용한 뒤 안정적으로 유지되는지 살펴보세요. 모든 앱의 권한을 한꺼번에 풀 필요는 없습니다. 상시 표시되는 알림은 실행 상태를 보여주며 알림을 숨긴다고 백그라운드 서비스가 유지되는 것은 아닙니다. Wi-Fi와 모바일 데이터 사이를 전환하면 기존 연결을 다시 설정해야 할 수 있습니다. 특히 네트워크에 웹 로그인이 필요하거나 모바일 데이터가 아직 연결되지 않았거나 기기가 절전 상태인 경우에 그렇습니다. 먼저 직접 연결을 확인한 뒤 클라이언트를 다시 연결해 로컬 네트워크 전환을 구독 만료로 오해하지 않도록 하세요.

v2rayNG와 v2flyNG는 서로 다른 코어 계열을 사용합니다. 설정 사용 가능 여부는 공유 링크를 가져올 수 있는지만이 아니라 해당 코어가 프로토콜, 전송 방식, 필드를 실제로 지원하는지에 달려 있습니다. 클라이언트를 바꿀 때는 구독을 다시 가져와 각각 테스트하고 다른 앱의 내부 파일을 그대로 복사하지 마세요. 서비스 제공업체가 특정 코어 기능을 요구한다면 그 요구사항을 기준으로 선택하세요. 호환성 문제가 명확하지 않다면 먼저 하나의 클라이언트 설정을 안정화한 뒤 대안을 검토하세요. 두 앱을 번갈아 실행하면 연결 상태가 혼란스러워질 수 있습니다.

시스템 프록시와 TUN: 트래픽 적용 범위와 로컬 포트

트래픽 진입 경로와 라우팅 출구를 구분하세요

시스템 프록시는 시스템 설정을 따르는 앱이 요청을 로컬 HTTP 또는 SOCKS 프록시로 보내도록 합니다. 모든 트래픽을 강제로 처리하는 방식은 아닙니다. TUN은 가상 네트워크 인터페이스와 라우팅을 사용해 해당 경로로 들어온 패킷을 프록시 코어가 처리하도록 합니다. 대체로 적용 범위가 넓지만 라우팅, 앱 제외 설정, 시스템 제약의 영향을 받습니다. 전역 프록시 규칙은 코어 내부에서 출구를 선택하는 설정일 뿐, 모든 앱의 트래픽이 코어에 들어왔다는 뜻은 아닙니다. 먼저 요청이 클라이언트에 도달하는지 확인한 다음 직접 연결과 프록시 중 어떤 경로를 써야 하는지 살펴보면 두 단계의 문제를 혼동하지 않을 수 있습니다.

'시스템 프록시 자동 설정'은 보통 현재 로컬 프록시 경로를 시스템에 설정하고, '시스템 프록시 해제'는 관련 설정을 제거합니다. '시스템 프록시 변경 안 함'은 현재 시스템 설정을 그대로 유지합니다. 마지막 항목을 선택해도 코어가 종료되거나 기존 설정이 자동으로 복구되는 것은 아닙니다. 문제를 진단할 때는 클라이언트가 계속 수신 대기 중인지, 시스템이 해당 포트를 가리키는지, 앱이 시스템 설정을 따르는지 확인하세요. 특히 비정상 종료 뒤에도 시스템 프록시가 남아 있으면 브라우저가 수신 프로세스가 없는 포트에 연결해 모든 사이트가 동시에 실패할 수 있습니다.

로컬 수신 대기, LAN 연결, 모드 조합

로컬 HTTP·SOCKS·혼합 포트는 앱이 클라이언트에 연결하는 진입점이며 원격 서버 포트가 아닙니다. 혼합 포트는 해당 코어가 지원하는 여러 프록시 요청을 받을 수 있지만 지원 프로토콜은 설정 안내를 확인해야 합니다. 처음에는 기본 수신 설정을 유지하세요. 로그에 주소 사용 중이라고 표시되면 충돌하는 프로세스를 찾거나 비어 있는 포트를 선택합니다. 수신 주소, 서버 주소, 구독 주소를 서로 바꿔 입력하지 마세요. 루프백 주소에서 수신 대기하면 주로 해당 기기에서만 접근할 수 있으며, 다른 기기에서는 자기 자신의 루프백 주소로 이 컴퓨터에 접속할 수 없습니다.

'LAN 연결 허용'을 켜면 접근 가능한 범위가 넓어지므로 프록시를 공유해야 하는 경우에만 활성화하세요. 활성화하면 수신 주소, 방화벽, 프록시 인증도 함께 고려해야 합니다. LAN을 신뢰한다는 이유만으로 진입점을 계속 열어 두어서는 안 됩니다. 다른 기기에서 연결하려면 클라이언트가 실행 중인 컴퓨터의 LAN 주소와 실제 수신 포트를 사용하고 접근 가능한 네트워크 범위를 제한하세요. 일반적인 단일 기기 사용에서는 로컬 접근만 허용하는 편이 관리하기 쉽습니다. 문제를 진단하는 동안 LAN 연결 허용, 포트 변경, TUN 활성화를 동시에 하지 마세요. 어떤 변경이 결과에 영향을 줬는지 구분하기 어렵습니다.

TUN 활성화와 복구 순서

TUN을 켜기 전에 작동하는 시스템 프록시 설정을 저장하고 원격 연결이 정상인지 확인하세요. 그런 다음 플랫폼 요구사항에 따라 권한, 구성 요소, 서비스를 설정합니다. 활성화 후 코어가 계속 실행되는지, 라우팅과 DNS가 예상대로 설정됐는지 확인하세요. 네트워크가 완전히 끊기면 먼저 TUN을 끄고 남은 시스템 프록시 설정을 해제한 다음 직접 연결을 확인합니다. 직접 연결이 복구되면 작동이 확인된 시스템 프록시 경로로 돌아가세요. TUN 문제를 해결하는 동안 서버 전송 설정을 계속 바꾸면 기존에 작동하던 비교 기준을 잃게 됩니다.

구현에 따라 두 모드를 반드시 함께 사용할 수 없는 것은 아니지만, 처음 문제를 진단할 때는 한 가지 경로만 사용하세요. 일부 환경에서는 앱이 로컬 프록시에 직접 연결한 뒤 그 연결이 다시 TUN에 의해 처리될 수 있습니다. 예외 설정과 루프백 처리가 올바르지 않으면 순환하거나 중복 처리될 수 있습니다. 클라이언트 프리셋을 따르고, 프록시 서버 주소 자체를 같은 프록시 출구로 다시 보내도록 임의 설정하지 마세요. UDP 앱, 게임, 실시간 통신에 문제가 생기면 앱 트래픽이 코어에 들어가는지, 원격 서버가 해당 전달을 지원하는지, 현재 네트워크에서 관련 통신이 허용되는지 각각 확인하세요. 웹페이지 테스트만으로 모든 기능을 판단해서는 안 됩니다.

설정을 마친 뒤 연결, 중지, 재연결 순서로 전체 작동을 확인하세요. 연결 중에는 대상 사이트에 접속할 수 있고, 중지 후에는 직접 연결이 복구되며, 다시 시작할 때 포트나 라우팅 충돌이 없어야 합니다. 세 단계가 모두 안정적으로 작동한 다음에 자동 연결이나 상시 백그라운드 실행을 설정하세요. 시스템 네트워크를 변경하기 전에 기존 값을 기록하고, 관리 기기의 제한을 강제로 덮어쓰지 마세요. 모드는 적용 범위를 크게 하는 것이 아니라 실제 앱의 요구에 맞춰 선택해야 합니다.

라우팅과 DNS: 규칙 순서와 분할 라우팅 확인

프리셋으로 시작해 규칙 적용 순서를 확인하세요

라우팅은 도메인, 대상 IP, 포트 또는 다른 조건에 따라 출구를 선택합니다. 단, 트래픽이 프록시 코어에 들어온 상태여야 합니다. 처음에는 클라이언트 프리셋을 선택하고 일반 접속이 안정적인지 확인한 뒤 사용자 지정 규칙을 하나씩 추가하세요. 일반적인 '중국 본토 우회' 프리셋은 규칙 데이터를 바탕으로 직접 연결과 프록시 범위를 나누지만 실제 동작은 현재 코어와 규칙 파일에 따라 달라집니다. '전역'도 해당 클라이언트 프리셋의 출구 정책을 뜻하며 운영체제의 모든 앱이 프록시로 연결된다는 의미는 아닙니다. 설정 전에 직접 연결할 서비스와 프록시를 사용할 서비스를 분명히 정하세요.

규칙은 일반적으로 설정 순서에 따라 평가되며 먼저 일치한 규칙이 결과를 결정합니다. 따라서 범위가 넓은 규칙보다 구체적인 예외를 앞에 배치해야 합니다. 범위가 큰 직접 연결 규칙이 있으면 뒤에 있는 세부 프록시 규칙이 적용되지 않을 수 있습니다. 규칙은 한 번에 하나씩 바꾸고 테스트 도메인, 예상 출구, 실제 로그를 기록하세요. 서로 다른 코어의 규칙 조각을 그대로 합치지 마세요. 필드 이름이 비슷해도 리소스 형식, 태그 이름, 기본 동작이 다를 수 있습니다. GUI 라우팅 편집기와 코어의 원시 설정은 서로 다른 계층이므로 UI가 지원하는 가져오기 방식을 사용하세요.

도메인, IP, 규칙 리소스의 관계

도메인 규칙은 사이트나 서비스의 소속을, IP 규칙은 특정 네트워크 대역과 확인된 주소를 처리하는 데 적합합니다. 연결이 코어에 들어올 때 이미 IP만 남은 경우 도메인 규칙이 적용되는지는 앱의 요청 방식, DNS 경로, 스니핑 설정에 따라 달라집니다. geosite와 geoip를 사용하려면 해당 규칙 리소스가 존재하고 코어와 호환되는지 확인해야 합니다. 리소스가 없거나 태그 이름이 잘못되면 시작에 실패하거나 예상과 다르게 일치할 수 있습니다. 규칙 리소스 업데이트와 구독 업데이트는 서로 다른 항목이므로 혼동하지 말고 각각 결과를 확인하세요.

아래는 정확한 도메인 접미사와 사설 IPv4 대역을 직접 연결하는 방식을 보여주는 Xray/V2Ray 형식의 라우팅 예시입니다. 완전한 연결 설정은 아니며, 기존 설정에 direct라는 태그의 직접 연결 출구가 정의되어 있어야 합니다. 해당 출구가 없다면 그대로 사용할 수 없습니다. 예시에는 프록시 서버가 정의되어 있지 않고 일치하지 않는 트래픽의 기본 경로도 지정하지 않습니다. GUI에서 규칙을 하나씩 입력해야 한다면 각 필드에 나누어 입력하세요. 전체 객체를 도메인 입력란에 붙여 넣거나 클라이언트가 생성한 전체 설정을 덮어쓰지 마세요.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"],
        "outboundTag": "direct"
      }
    ]
  }
}

DNS 문제와 분할 라우팅 문제를 따로 확인하세요

DNS는 도메인을 주소로 변환하지만, 이름을 조회하는 경로와 웹페이지 연결에 사용하는 출구가 같지 않을 수 있습니다. 시스템 DNS, 클라이언트 내장 DNS, 브라우저의 암호화 DNS가 모두 관여할 수 있습니다. 브라우저에서 별도의 DNS 조회를 사용하면 클라이언트 로그의 도메인 정보와 시스템 조회 결과가 다르게 보일 수 있습니다. 먼저 어떤 구성 요소가 DNS를 처리하는지 확인한 뒤 필요한 설정을 바꾸세요. 시스템 리졸버, 브라우저 설정, 코어 DNS를 한꺼번에 변경하지 마세요. 고정 IP를 이용한 비교 테스트는 범위를 좁히는 데만 도움이 됩니다. TLS와 가상 호스트에는 올바른 호스트명이 필요하므로 정상적인 도메인 테스트를 대신할 수 없습니다.

일부 사이트만 문제가 있고 대부분 정상이라면 출구가 잘못됐는지, 예상하지 못한 규칙이 적용됐는지, DNS 결과가 올바른지 비교하세요. 규칙을 바꾼 뒤 문제가 생겼다면 구독을 교체하기보다 이전에 작동하던 규칙으로 되돌려 확인하는 편이 원인을 찾는 데 효과적입니다. IPv6도 함께 살펴보세요. 시스템에서 IPv6 주소를 우선 사용하지만 현재 트래픽 처리 경로나 원격 경로가 이를 지원하지 않으면 연결이 불안정할 수 있습니다. 실제 네트워크 지원 여부에 맞춰 IPv4와 IPv6 경로를 설정하세요. 근거 없이 모든 IPv6 기능을 문제 원인으로 단정하지 마세요.

규칙을 테스트할 때는 오래 연결된 페이지를 새로고침하는 것보다 새 연결을 만드는 편이 정확합니다. 브라우저 캐시, 연결 재사용, 앱 내부 캐시 때문에 이전 출구가 계속 사용될 수 있습니다. 필요하면 해당 앱을 완전히 종료하고 다시 열어 코어 로그에 표시되는 규칙 적용 결과를 확인하세요. 규칙 구조가 익숙하지 않다면 domain, ip와 분할 라우팅 규칙 활용을 참고하세요. 여러 구독을 함께 사용한다면 그룹을 먼저 정리하고 다중 구독 그룹 관리를 확인해 서버 필터를 트래픽 라우팅 규칙과 혼동하지 않도록 하세요.

설정 관련 자주 묻는 질문: 문제 유형별 연결 복구

먼저 어느 단계에서 실패하는지 확인하세요

문제 해결은 로컬부터 시작하세요. 프로그램이 열리는지, 코어가 계속 실행되는지, 로컬 포트에서 수신 대기하는지, 앱이 요청을 클라이언트로 보내는지, 원격 연결이 성립하는지 차례로 확인한 뒤 라우팅과 DNS를 살펴봅니다. 각 단계의 결과를 하나씩 기록하는 편이 프로그램을 재설치하고 구독을 바꾸는 것보다 효과적입니다. 로그에 표시된 오류 유형과 발생 시간을 저장하되, 외부에 공유하기 전에 구독 주소, 사용자 식별자, 기타 접속 정보를 삭제하세요. 진단하는 동안에만 필요한 수준으로 로그 상세도를 높이고 문제가 해결되면 일반 수준으로 되돌리세요. 불필요한 연결 기록이 계속 쌓이는 것을 방지할 수 있습니다.

모든 서버가 동시에 실패하면 로컬 네트워크, 시스템 시간, 코어 실행 상태, 구독 유효 기간, 프록시 모드처럼 공통 요소부터 확인하세요. 일부 서버만 실패하면 해당 설정의 주소, 포트, 전송 방식, TLS 매개변수를 확인합니다. 구독 업데이트는 서비스 제공업체가 설정을 변경한 경우 도움이 될 수 있지만 로컬 포트 충돌이나 권한 문제는 해결하지 못합니다. 단계별 점검 방법은 노드 시간 초과와 연결 실패 해결 순서를 참고하고, 간단한 문답은 자주 묻는 질문에서 확인하세요.

구독, 연결 테스트, 브라우저 접속

종료 후 복구, 업데이트, 설정 백업

업그레이드하기 전에 설치 방식, 설정 폴더, 사용 중인 UI 버전을 기록하세요. 구독 그룹과 사용자 지정 라우팅을 내보내고 백업은 접근이 제한된 위치에 보관합니다. 설정 백업에는 서버 접속 정보가 들어갈 수 있으므로 공개 게시판에 그대로 올리지 마세요. 업그레이드 후 기존의 최소 연결 경로가 작동하는지 먼저 확인한 다음 새 설정을 살펴봅니다. 설정 마이그레이션에 문제가 생기면 같은 폴더에서 여러 버전을 번갈아 실행하고 저장하지 마세요. 설정을 다시 만들어야 한다면 전체 구독에서 서버를 먼저 복원한 뒤 수동 라우팅과 앱 규칙을 하나씩 옮겨 잘못된 상태를 한꺼번에 복사하지 않도록 합니다.

복구를 마친 뒤 연결, 중지, 재연결을 차례로 테스트하고 최종 모드와 포트를 기록하세요. 다음에 같은 문제가 생기면 모든 매개변수를 처음부터 바꾸지 않고 확인된 정상 상태로 돌아갈 수 있습니다. 처음 사용하는 분은 빠른 시작 가이드에서 전체 절차를 확인하세요. 플랫폼과 아키텍처를 알고 있다면 설치 파일 페이지에서 해당 클라이언트를 바로 선택할 수 있습니다. 이 가이드는 설정의 적용 범위를 설명하며, 실제 메뉴와 권한 안내는 현재 클라이언트와 운영체제에 표시되는 내용을 기준으로 합니다.