구독 가져오기, 라우팅, 프로토콜 선택을 중심으로 클라이언트 설정과 코어 지원 기능의 관계를 설명합니다.
클라이언트 설정은 세 부분으로 나눌 수 있습니다. 구독과 노드는 연결 대상을 정하고, 시스템 프록시나 TUN 모드는 어떤 앱의 트래픽을 클라이언트로 보낼지 결정합니다. 라우팅과 DNS는 들어온 트래픽을 처리하는 방식을 정합니다. 설치를 마쳤다고 연결이 바로 되는 것은 아닙니다. 사용할 수 있는 설정을 가져와 노드를 선택하고, 트래픽 진입점을 지정한 다음 로그와 실제 접속 결과를 확인하세요. 이 순서대로 점검하면 문제가 발생한 단계를 찾기 쉽습니다.
아래 패널은 설정 항목의 구성을 보여 주는 예시입니다. 필드 이름은 클라이언트 업데이트에 따라 달라질 수 있으니 실제 작업은 현재 화면을 기준으로 하세요. 구독, 전송, DNS, 라우팅 설정을 한꺼번에 바꾸지 마세요. 정상 작동하는 설정을 따로 보관하고 한 번에 한 종류씩 변경한 뒤 결과를 확인하는 편이 안전합니다. 문제가 생겨도 쉽게 되돌릴 수 있고, 노드 자체의 문제를 앱 프록시 문제로 오인하는 일도 줄어듭니다.
구독을 사용하면 여러 노드를 한곳에서 관리할 수 있어 주소나 설정이 바뀌는 경우 편리합니다. 구독 그룹에 이름과 전체 주소를 입력해 저장한 뒤 업데이트하고, 실제로 사용할 노드를 선택하세요. 주소를 추가하는 것만으로 연결이 설정되지는 않습니다. 공유 링크를 하나씩 붙여 넣는 것보다 그룹 구독이 일괄 관리에 편리하지만, 업데이트 과정에서 직접 수정한 내용이 덮어써질 수도 있습니다. 직접 만든 노드는 별도 그룹으로 관리하는 편이 좋습니다. 구독 주소에 접속 정보가 포함될 수 있으므로 공개하지 마세요. 업데이트에 실패하면 먼저 주소가 유효한지 확인하고 업데이트 요청의 연결 경로를 점검하세요.
domain:example.com192.168.0.0/16geosite:private라우팅은 도메인, IP 또는 분류 데이터를 기준으로 연결을 직접 연결, 프록시 또는 차단 중 어디로 보낼지 결정합니다. 일반적으로 로컬 네트워크와 명확한 예외를 먼저 처리하고, 일반 규칙을 추가한 다음 마지막에 기본 정책을 설정합니다. 조건에 맞는 규칙을 어떤 순서로 적용할지는 코어의 매칭 방식을 확인하세요. 모든 트래픽을 같은 아웃바운드로 보내는 것보다 규칙을 설정하는 방식이 로컬 기기와 원격 서비스에 함께 접속할 때 유용합니다. 규칙을 추가하기 전에 클라이언트가 생성한 아웃바운드 이름을 확인하고, 분류 규칙에서 참조하는 데이터 파일도 준비해야 합니다. 규칙이 적용되지 않으면 웹페이지의 표시만으로 판단하지 말고 실제 도메인과 로그를 확인하세요.
TUN 모드는 가상 네트워크 인터페이스로 트래픽을 받아 시스템 프록시 설정을 따르지 않는 앱에도 사용할 수 있습니다. 시스템 프록시와는 별도의 트래픽 진입점이며 노드 프로토콜을 바꾸는 기능은 아닙니다. 켜기 전에 일반 프록시로 노드가 작동하는지 확인하고, 클라이언트에서 사용하는 TUN 구현과 권한, DNS 설정을 점검하세요. 시스템 프록시를 따르는 앱만 처리하는 것보다 더 많은 트래픽을 제어할 수 있지만, 다른 가상 네트워크 어댑터나 프록시 프로그램과 충돌할 가능성도 커집니다. 켠 뒤 로컬 네트워크 접속에 문제가 생기면 우회 규칙부터 확인하세요. 트래픽을 가로챌 필요가 없다면 이후 연결에 영향을 주지 않도록 TUN을 꺼 두세요.
DNS 설정은 도메인을 IP 주소로 변환하지만 코어의 DNS를 바꿔도 모든 앱의 조회 경로가 달라지는 것은 아닙니다. 시스템 프록시, TUN, 브라우저 자체의 암호화 DNS는 서로 다른 경로를 사용할 수 있습니다. 먼저 DNS 요청을 어느 구성 요소가 처리하는지 확인한 뒤 접속 가능한 DNS 서버를 선택하고, 조회 요청에 사용할 아웃바운드도 점검하세요. 서버 주소만 바꾸는 것보다 DNS 조회와 라우팅을 함께 설정하는 것이 중요합니다. 특히 IP 주소로 매칭하는 규칙은 DNS 조회 결과에 영향을 받습니다. 예시 주소는 형식을 설명하기 위한 것이며 일반적인 권장 주소가 아닙니다. 도메인으로는 접속할 수 없지만 IP로는 접속되는 경우 노드 설정을 바꾸기 전에 DNS부터 확인하세요.
그래픽 클라이언트는 설정을 관리하고 코어는 실제 연결을 처리합니다. 여러 코어를 지원하면 하나의 화면에서 다양한 기능 조합을 사용할 수 있지만, 모든 설정이 공통으로 호환되는 것은 아닙니다. 코어를 바꾸기 전에 프로토콜, 전송, 보안 계층, 라우팅 옵션을 대상 코어에서 지원하는지 확인하세요. 특히 VLESS와 REALITY 조합은 실제 구현을 점검해야 합니다. 화면 테마만 바꾸는 것과 달리 코어 전환은 설정의 의미와 로그 내용에 영향을 줍니다. 연결이 안정적이라면 자주 바꿀 필요가 없습니다. 새 기능을 사용하거나 호환성 문제를 해결하려는 경우 먼저 설정을 백업하고 노드 하나로 시험한 뒤 나머지를 조정하세요.
VMess, VLESS, Trojan, Shadowsocks는 프록시 프로토콜이고 WebSocket 등은 전송 방식입니다. TLS와 REALITY는 전송 보안 관련 설정입니다. 각각 서로 다른 계층에 해당합니다. VLESS 노드를 사용할 때는 전송 유형, TLS 또는 REALITY 사용 여부, flow 지정 여부도 확인해야 합니다. 프로토콜 이름만 선택하고 저장하면 충분하지 않습니다. 위 카드는 항목 구성을 보여 주는 예시이며 바로 연결할 수 있는 완전한 노드 설정은 아닙니다.
VLESS의 encryption에는 보통 none을 입력하지만, 그렇다고 보안 계층을 생략해도 되는 것은 아닙니다. Trojan은 올바른 비밀번호와 서버 인증 설정이 필요합니다. 인증서 오류가 발생하면 인증서 검증을 건너뛰도록 설정하는 대신 시스템 시간, SNI, 서버 인증서를 확인하세요. Shadowsocks의 암호화 방식은 서버 설정과 일치해야 합니다. 연도가 붙은 암호화 방식에는 별도의 키 요구 사항이 있으므로 일반 문자열 비밀번호를 모든 방식에 임의로 적용하면 안 됩니다.
노드를 선택할 때는 제공된 전체 매개변수를 그대로 사용하는 것이 좋습니다. 직접 입력해야 한다면 주소, 포트, 사용자 인증 정보, 전송 방식, 보안 계층 순으로 확인한 뒤 연결을 테스트하세요. 클라이언트에 노드 이름이 표시된다고 해서 설정이 저장되었다는 뜻일 뿐, 코어가 모든 항목을 해석하거나 원격 서버에 접속할 수 있다는 의미는 아닙니다. 프로토콜별 설계 차이와 모바일 기기 배터리 사용량, 설정 호환성을 더 알아보려면 프로토콜 및 코어 기술 안내를 참고하세요.
데스크톱에서는 v2rayN을, 안드로이드에서는 Xray 코어를 사용하는 v2rayNG를 우선 확인하세요. V2Fly 설정과의 호환성이 필요하다면 v2flyNG를 고려할 수 있습니다. 이름은 비슷하지만 지원 플랫폼, 코어, 설치 파일 형식은 서로 다릅니다. 다운로드 전에 운영체제와 프로세서 아키텍처를 확인하세요. 설치한 다음 구독과 노드를 설정하면 설치 파일의 호환성 문제와 연결 문제를 구분하기 쉽습니다.
아래 링크를 누르면 해당 플랫폼의 다운로드 페이지로 이동합니다. 홈에서 설치 파일을 바로 내려받지는 않습니다. 다운로드 페이지에서 설치 파일 유형별 용도를 확인하고 데스크톱 버전, 클래식 인터페이스, 프로세서 아키텍처, 배포판 형식을 비교할 수 있습니다. 기기를 바꿀 때 구독 출처는 그대로 사용할 수 있지만, 기존 기기의 시스템 프록시, 권한, 라우팅 설정은 구독과 함께 옮겨지지 않으므로 다시 확인해야 합니다.
Windows 사용자는 v2rayN 데스크톱 버전과 클래식 WPF 버전 중에서 선택할 수 있습니다. 데스크톱 버전은 크로스 플랫폼 인터페이스를 사용하고, WPF 버전은 익숙한 클래식 데스크톱 조작 방식을 유지합니다. 먼저 시스템 아키텍처를 확인한 다음 인터페이스와 기존 사용 방식에 맞는 버전을 고르세요. 버전별 설정 폴더와 마이그레이션 방법이 다를 수 있으므로 파일 이름만 보고 기존 버전을 덮어써도 된다고 판단하지 마세요.
처음 사용할 때는 클라이언트를 실행하고 구독을 가져온 뒤 시스템 프록시를 켜세요. 시스템 프록시 설정을 읽지 않는 앱은 앱 자체 프록시나 TUN을 사용해야 할 수 있습니다. 클라이언트를 바꾼 뒤에도 브라우저가 이전 포트를 사용한다면 시스템 설정에 다른 프록시 프로그램의 설정이 남아 있는지 확인하고, 예상한 프로그램 하나만 트래픽 진입점을 관리하도록 하세요.
macOS 설치 파일은 Apple Silicon과 Intel 칩에 따라 나뉩니다. 시스템의 ‘이 Mac에 관하여’에서 칩 또는 프로세서 정보를 확인할 수 있습니다. Apple Silicon은 arm64, Intel은 x64를 선택하세요. 호환 모드로 실행할 수 있다고 해서 이를 기본 선택으로 삼지 말고, 다운로드 페이지의 시스템 요구 사항도 확인하세요.
데스크톱 클라이언트에서 구독을 관리하는 것과 시스템 네트워크 권한을 설정하는 것은 별개의 단계입니다. 구독을 가져온 뒤에도 현재 선택된 노드, 프록시 진입점, 앱의 실제 연결 경로를 확인해야 합니다. TUN을 사용하려면 화면과 운영체제 안내에 따라 필요한 권한을 부여하세요. 조직에서 관리하는 기기라면 네트워크 설정을 변경하기 전에 기기 관리 정책을 따르세요.
안드로이드에서는 v2rayNG를 우선 선택하고, V2Fly 코어가 필요한 경우 v2flyNG를 대안으로 고려하세요. 최신 주류 기기 대부분은 arm64 패키지가 적합합니다. 아키텍처를 모르겠다면 기기 정보를 확인하거나 범용 패키지를 선택하세요. 두 앱은 이름과 아이콘이 비슷해 혼동하기 쉬우므로 설치 전에 앱 이름을 확인하고, 가져온 뒤 프로토콜 지원 여부를 점검하세요. 두 앱의 설정 경로가 완전히 같다고 가정하면 안 됩니다.
연결을 시작할 때 요청되는 VpnService 권한은 로컬 트래픽을 제어할 인터페이스를 만드는 데 필요합니다. 이 권한만으로 구독을 바로 사용할 수 있는 것은 아닙니다. 장시간 대기한 뒤 연결이 끊긴다면 노드 상태와 함께 백그라운드 제한 및 배터리 절전 설정도 확인하세요. 앱별 프록시는 트래픽을 제어할 범위를 지정할 때 유용합니다. 목록이 포함 대상인지 제외 대상인지 먼저 확인해 필요한 앱을 잘못된 쪽에 넣지 않도록 하세요.
Linux에서는 v2rayN의 deb 및 rpm 패키지를 확인하고 x64와 arm64 중 알맞은 아키텍처를 선택하세요. 패키지 형식은 배포판의 패키지 관리 방식에, 아키텍처는 프로세서에 맞춰야 하므로 둘 다 확인해야 합니다. 파일을 내려받을 수 있다고 해서 현재 시스템에 맞는 것은 아닙니다. 설치 의존성, 데스크톱 환경, 권한 요구 사항을 다운로드 페이지의 안내에 따라 확인하세요.
Linux에서 시스템 프록시가 작동하는지는 데스크톱 환경과 앱 자체 설정에도 좌우됩니다. 브라우저는 연결되지만 다른 프로그램이 연결되지 않는다면 노드를 바꾸기 전에 해당 프로그램이 프록시 설정을 읽는지 확인하세요. TUN을 켜기 전에 권한과 라우팅 제어 범위를 점검하고, 특히 로컬 네트워크, 컨테이너 네트워크, 기존 가상 인터페이스에 주의하세요. 설정을 바꾸기 전에 되돌릴 수 있도록 기존 설정을 보관하세요.
설정을 옮겨도 일부 매개변수만 재사용할 수 있습니다. 새 기기에서는 코어 지원 여부, 트래픽 진입점, DNS 경로를 다시 확인해야 합니다. 자세한 내용은 빠른 시작 가이드를 참고하세요.
v2rayN · v2rayNG · v2flyNG
구독 관리, 화면 조작, 설정 생성Xray · V2Fly
연결 수립, 프로토콜 처리, 라우팅 실행Project V는 프록시 및 네트워크 도구를 중심으로 형성된 오픈 소스 프로젝트 생태계이며, V2Ray는 그 안에서 널리 사용되는 핵심 이름입니다. 특정 프로토콜 하나만을 뜻하는 것이 아니라 인바운드, 아웃바운드, 라우팅, 전송 설정을 하나의 구성 체계로 묶는 것이 특징입니다. 클라이언트 화면에 표시되는 ‘노드’는 대개 원격 아웃바운드 하나를 보여 주는 방식입니다. 시스템 프록시, 로컬 리스닝, DNS는 별도의 구성 요소이므로 노드 이름 하나만으로 전체 실행 환경을 설명할 수는 없습니다.
일상적인 대화에서는 V2Ray를 생태계 전체를 가리키는 말로 쓰기도 하므로, 다운로드할 때는 구체적인 앱 이름을 확인해야 합니다. v2rayN은 그래픽 클라이언트이며 V2Ray 코어 자체와는 다릅니다. v2rayNG와 v2flyNG는 안드로이드 기기용입니다. 이 관계를 이해하면 문서에서 ‘인터페이스에 기능이 추가된 것’과 ‘코어에 프로토콜 기능이 추가된 것’을 구분할 수 있습니다. 문제를 살펴볼 때 클라이언트 로그를 확인할지 프로토콜 매개변수를 확인할지도 판단하기 쉬워집니다.
V2Fly는 V2Ray의 커뮤니티 개발을 이어 왔고, Xray는 관련 코드 기반에서 출발해 자체 기능을 발전시켜 왔습니다. 두 코어는 공통된 배경이 있지만 각각 별도로 유지·개발되므로 같은 프로그램의 테마만 다른 버전으로 보면 안 됩니다. 일부 설정 항목이 비슷해도 새로운 전송 방식, 보안 기능, 라우팅 옵션, 기본 동작에는 차이가 있을 수 있습니다. 이름이나 출시일만 비교하지 말고 현재 노드가 요구하는 기능과 실제 호환성을 기준으로 코어를 선택하세요.
VLESS, Vision, REALITY 조합을 사용할 때는 Xray의 지원 범위와 서버에서 제공한 flow, 서버 이름, 공개 키, shortId를 꼼꼼히 확인하세요. REALITY는 보안 전송 방식이며 VMess나 Trojan과 같은 계층의 독립 프록시 프로토콜로 볼 수 없습니다. 기존 V2Fly 설정을 다른 코어로 한꺼번에 옮기지 마세요. 먼저 노드 하나의 항목을 확인하고 라우팅과 DNS를 테스트한 뒤 전체 설정을 이전하세요.
v2rayN, v2rayNG, v2flyNG는 모두 오픈 소스 클라이언트로, 노드 편집, 구독 관리, 연결 제어 등의 그래픽 기능을 제공합니다. 오픈 소스라는 것은 소스 코드와 라이선스를 확인할 수 있다는 뜻이지, 실행 권한이나 설정 출처를 따로 검토하지 않아도 된다는 뜻은 아닙니다. 구독 제공자, 원격 서버, 클라이언트는 서로 다른 역할을 맡습니다. 클라이언트를 설치한다고 서버 계정이 자동으로 생기거나 가져온 노드가 모두 작동하는 것은 아닙니다.
v2rayN은 데스크톱용으로, 한 화면에서 구독과 라우팅을 관리하고 지원 범위에 맞는 코어를 선택할 수 있습니다. v2rayNG는 주로 Xray 코어를 기반으로 하며 안드로이드에서 관련 프로토콜 기능을 사용하기에 적합합니다. v2flyNG는 V2Fly 코어를 기반으로 하며 해당 설정과의 호환성이 필요한 경우에 유용합니다. 앱 사이에서 설정을 옮길 때는 화면에 표시된 메모만 복사하지 말고 전체 공유 링크나 구독을 다시 가져온 뒤 연결 모드를 확인하세요.
Project V 관련 프로젝트, 그래픽 클라이언트, 코어, 패키지 의존성에는 서로 다른 오픈 소스 라이선스가 적용될 수 있습니다. 생태계에 속한 한 프로젝트의 라이선스를 모든 구성 요소에 공통으로 적용하면 안 됩니다. 개인 사용, 재배포, 수정본 공개에는 각각 다른 조건이 적용될 수 있으므로 해당 프로젝트의 라이선스 파일과 안내를 따로 확인하세요. 페이지에서 말하는 ‘오픈 소스’는 개발 및 배포 특성을 나타낼 뿐 구독 내용이나 원격 서비스의 품질을 보장하지 않습니다.
일반 사용자는 앱 이름, 플랫폼 아키텍처, 사용 중인 코어를 기록하고 설정의 출처를 보관하며 클라이언트가 요청하는 권한을 확인하는 것이 좋습니다. 설정에 포함된 비밀번호, 사용자 식별자, 구독 주소는 주의해서 다루세요. 문제 해결을 위해 화면을 공유할 때는 이런 정보를 가려야 합니다. 노드 주소, SNI, 공개 키는 용도가 서로 다르지만 개인 설정 전체를 공개해서는 안 됩니다. 문제를 파악하는 데는 설정 항목이 서로 일치하는지만 설명해도 충분한 경우가 많습니다.
클라이언트 업데이트는 주로 인터페이스와 설정 관리에 영향을 주고, 코어 업데이트는 연결 구현에 영향을 줍니다. 구독 업데이트는 설정 제공자가 노드 목록을 변경하는 작업입니다. 업데이트의 출처와 결과는 각각 다릅니다. 구독을 새로 고친 뒤 노드 수나 매개변수가 바뀌었다고 해서 반드시 클라이언트 업데이트 때문인 것은 아닙니다. 클라이언트를 업데이트한 뒤 설정을 불러오지 못해도 구독 주소가 잘못된 것은 아닐 수 있습니다. 먼저 어떤 계층이 바뀌었는지 확인한 다음 되돌릴지, 다시 가져올지, 항목을 조정할지 결정하세요.
업데이트 전에 현재 설정을 보관하고 사용 중인 노드와 라우팅 모드를 기록하세요. 업데이트 후에는 자주 사용하는 노드 하나로 테스트한 뒤 로컬 네트워크 접속, 도메인 조회, 프록시가 필요한 앱을 확인하세요. 자동 업데이트 간격은 구독 제공자의 제한에 맞추면 되며 자주 새로 고칠 필요는 없습니다. 계속 실패한다면 요청을 반복하기보다 주소 유효성, 요청 경로, 시스템 시간, 오류 로그를 차례로 확인하세요. 여러 설정을 한꺼번에 바꾸면 처음 원인을 찾기 어려워질 수 있습니다.
가져오기는 성공했지만 접속되지 않으면 먼저 노드가 선택되어 있고 코어가 정상적으로 실행 중인지 확인하세요. 그런 다음 앱의 트래픽이 실제로 프록시를 통과하는지 점검합니다. 브라우저는 연결되지만 다른 프로그램은 연결되지 않는다면 트래픽 진입점을 확인하세요. 도메인으로만 접속할 수 없다면 DNS 경로부터 점검하고, 모든 앱에서 연결이 안 된다면 노드 매개변수와 원격 서버 접속 가능 여부를 확인하세요. 지연 시간 테스트는 특정 요청의 결과일 뿐 모든 프로토콜과 앱 트래픽이 정상이라는 증거는 아닙니다.
용어를 확인하려면 용어집에서 구독, 공유 링크, 인바운드, 아웃바운드의 차이를 살펴보세요. 증상별 해결 방법은 자주 묻는 질문을 참고하세요. 프로토콜을 무작정 바꾸기보다 오류가 발생한 시각, 최근 변경한 설정, 로그 유형을 정리하는 편이 효과적입니다. 코어 선택은 서버의 지원 기능과 앱의 요구 사항을 함께 고려해야 합니다. 특정 프로토콜 이름을 좇기보다 설정 항목을 일관되게 맞추는 것이 중요합니다.
기본 연결을 마친 뒤 필요에 따라 주제별 안내를 확인하세요. 구독 형식은 가져오기 방식에 영향을 주고, 업데이트 실패는 요청 경로를 점검해야 합니다. 라우터 배포는 데스크톱 클라이언트와 다른 네트워크 역할을 고려해야 합니다. 각 글은 한 가지 문제를 집중적으로 다루므로 변경 전에 적용 조건을 확인하기 쉽고, 보조 라우터, 안드로이드 권한, 데스크톱 시스템 프록시 설정을 혼동하지 않도록 도와줍니다.
메인 라우터나 보조 라우터에서 Xray/V2Fly 코어를 직접 실행하는 방법을 소개합니다. 하드웨어 아키텍처와 메모리 요구 사항, 투명 프록시 방식의 장단점, DNS 라우팅 설정의 핵심을 다룹니다.
클라이언트의 트래픽 진입점을 이해하고 적용 범위를 로컬 네트워크까지 넓히려는 사용자에게 적합합니다. 먼저 게이트웨이와 DNS 서버가 각각 맡는 역할을 파악한 다음 배포 위치를 정하세요.
배포 가이드 읽기 →Base64 구독, 기본 JSON 설정, vmess:// 및 vless:// 공유 링크의 구조 차이를 비교하고 클라이언트별 호환성과 형식 변환 방법을 설명합니다.
가져오는 과정에서 형식 오류가 표시되거나 다른 클라이언트로 설정을 옮기려는 사용자에게 적합합니다. 변환 전에 입력 형식을 확인하고 전송 및 보안 매개변수가 변환 과정에서 누락될 수 있는지 살펴보세요.
형식 가이드 읽기 →구독 주소 오류, 업데이트 요청의 프록시 경유 여부, 시스템 시간 차이, 인증서 문제를 차례로 점검하고 자동 업데이트 간격과 그룹 구독 권장 설정을 안내합니다.
노드 연결은 되지만 구독이 갱신되지 않는 경우에 적합합니다. 구독 가져오기와 노드 사용을 따로 테스트하고, 사용 가능한 설정을 보관한 뒤 업데이트 경로를 점검하세요.
문제 해결 가이드 읽기 →