클라이언트 설치부터 시작해 구독 가져오기, 라우팅 분할, 문제 원인 파악까지 데스크톱과 Android에서 자주 사용하는 절차를 안내합니다.
클라이언트 설정은 서로 무관한 스위치의 모음이 아닙니다. 구독은 노드 정보를 제공하고, 라우팅은 트래픽의 경로를 결정하며, 시스템 프록시 또는 TUN 모드는 애플리케이션 요청을 넘겨받습니다. 로그와 연결 테스트는 각 단계가 예상대로 작동하는지 확인하는 데 사용됩니다.
구독 링크는 클라이언트가 노드 설정을 가져오는 시작점입니다. 데스크톱에서는 보통 구독 그룹에 주소를 추가한 뒤 업데이트를 실행하고, Android 클라이언트에서는 클립보드로 가져오거나 신뢰할 수 있는 출처의 QR 코드를 스캔할 수 있습니다. 가져오기가 완료되었다고 연결까지 정상인 것은 아닙니다. 먼저 노드 목록이 표시되는지, 이름이 올바른지, 그룹이 예상한 출처와 일치하는지 확인하세요. 목록이 비어 있다면 시스템 프록시를 반복해서 바꾸기보다 주소가 완전한지, 네트워크 요청이 성공했는지, 클라이언트 로그의 응답 상태가 어떤지부터 점검해야 합니다.
구독을 업데이트하면 클라이언트가 원격 콘텐츠를 다시 읽으며 같은 그룹의 기존 노드를 덮어쓸 수 있습니다. 장기간 보관할 수동 설정은 별도 그룹에 저장해 구독 업데이트와 섞이지 않도록 하세요. 노드가 나타난 뒤에는 연결 테스트를 한 번 더 실행해 ‘구독 읽기 성공’과 ‘특정 노드 연결 가능’이라는 두 결과를 구분해야 합니다. 이 순서대로 확인하면 문제를 입력, 파싱 또는 연결 단계로 좁힐 수 있어 DNS, 포트, 라우팅 규칙을 목적 없이 바꾸는 일을 줄일 수 있습니다.
라우팅 분할은 요청을 프록시 출구로 보낼지, 직접 연결할지, 차단할지를 결정합니다. 규칙은 보통 도메인, 대상 IP, 포트, 네트워크 유형 또는 프로세스 정보를 읽고 현재 클라이언트 설정 순서에 따라 매칭됩니다. 라우팅 결과를 점검할 때는 먼저 요청이 클라이언트에 인계되었는지 확인한 다음 매칭된 규칙과 최종 아웃바운드를 살펴보세요. 웹페이지가 열리는지만으로는 요청이 실제로 어떤 경로를 사용했는지 판단할 수 없습니다. 규칙이 많을수록 우선순위를 명확히 해야 하며, 범위가 좁고 목적이 분명한 규칙은 일반적으로 포괄적인 규칙보다 앞에 배치해야 합니다.
도메인 규칙은 이름이 안정적인 서비스에 적합하고, IP 규칙은 알려진 주소 대역에 적합하며, 프로세스 규칙은 데스크톱 애플리케이션을 지정해 처리할 때 사용할 수 있습니다. 새 규칙 세트를 활성화한 뒤에는 대표적인 대상을 몇 개 골라 직접 연결, 프록시, 차단 결과를 각각 확인하고 로그의 라우팅 기록도 살펴보세요. 예상과 다르면 최근 추가한 규칙을 일시적으로 끈 뒤 하나씩 다시 활성화하세요. 노드, DNS, 프록시 모드를 동시에 바꾸면 어떤 설정이 경로를 변경했는지 확인하기 어렵습니다.
시스템 프록시는 운영체제의 프록시 설정을 따르는 브라우저와 일반적인 데스크톱 애플리케이션에 적합하며, 설정이 명확하고 끈 뒤 복구하기도 쉽습니다. 일부 프로그램은 시스템 프록시를 우회하거나 직접 네트워크 연결을 생성하므로 이런 경우 TUN 모드를 고려할 수 있습니다. TUN은 가상 네트워크 어댑터로 더 넓은 범위의 트래픽을 받은 뒤 커널이 라우팅과 아웃바운드 처리를 수행하도록 전달합니다. 따라서 네트워크 권한, 라우팅 테이블, DNS 조회, 로컬 방화벽 등 더 많은 요소가 관련됩니다. 처리 방식을 선택할 때는 모든 옵션을 기본으로 동시에 켜기보다 애플리케이션의 동작에 맞춰 결정해야 합니다.
시스템 프록시에서 TUN으로 전환하기 전 현재 로컬 수신 포트와 프록시 상태를 기록하고, 가상 네트워크 어댑터를 만들 수 있는 다른 네트워크 도구를 종료하세요. 활성화한 뒤에는 브라우저, 대상 애플리케이션, 도메인 조회를 각각 확인합니다. 클라이언트를 종료한 후에도 네트워크가 복구되지 않으면 시스템 프록시 잔여 설정, 가상 네트워크 어댑터 상태, DNS 설정을 먼저 점검하세요. 데스크톱에서 TUN을 처음 활성화할 때는 권한 상승이 필요할 수 있으며, 모바일에서는 시스템 수준 네트워크 연결 확인 메시지가 표시됩니다. 전체 절차와 되돌리기 방법은 사용 문서에서 플랫폼별로 확인할 수 있습니다.
문제 원인은 ‘클라이언트 프로세스, 로컬 입력 지점, 노드 연결, 원격 출구, 도메인 조회’ 순서로 따라가며 찾아야 합니다. 클라이언트가 시작되지 않으면 포트 점유와 권한부터 확인하세요. 클라이언트는 실행되지만 애플리케이션이 연결되지 않으면 시스템 프록시와 처리 범위를 점검합니다. 노드 테스트가 시간 초과될 때는 노드 매개변수, 네트워크 환경, 전송 설정을 확인하세요. 도메인 접속만 이상하고 IP 직접 접속은 정상일 때에만 DNS에 초점을 맞추면 됩니다. 증상을 연결 단계에 대응시키는 것이 노드를 계속 바꾸거나 클라이언트를 재설치하는 것보다 효과적입니다.
로그의 시간, 수준, 오류 위치는 수행한 동작과 함께 읽어야 합니다. 구독 업데이트, 연결 시작 또는 대상 애플리케이션 실행을 한 번 수행한 직후 새로 추가된 로그를 확인하면 이전 기록의 방해를 줄일 수 있습니다. 포트 충돌은 대개 로컬 수신 단계의 문제이고, 연결 시간 초과는 노드 또는 전송 단계에서 발생하는 경우가 많으며, 조회 실패는 DNS 요청의 경로를 확인해야 합니다. 수정한 뒤에는 같은 동작을 다시 수행해 오류 기록이 더 이상 나타나지 않는지 확인하고 시스템 프록시가 예상한 상태로 복구되었는지도 점검하세요.
데스크톱 플랫폼은 모두 v2rayN을 사용하며, Android에서는 커널 요구 사항에 따라 v2rayNG와 v2flyNG 중에서 선택할 수 있습니다. 플랫폼入口는 다운로드 페이지의 해당 탭으로 이동하며, 설치 패키지 유형, 시스템 요구 사항, 칩셋 선택 안내가 한곳에 정리되어 있습니다.
Windows 사용자는 차세대 데스크톱 인터페이스와 클래식 WPF 인터페이스 중에서 선택할 수 있습니다. 설치가 끝나면 먼저 구독을 가져오고 노드를 선택한 다음 시스템 프록시를 설정하세요. 시작할 때 로컬 포트가 이미 사용 중이라는 메시지가 표시되면 점유 프로세스를 확인하거나 수신 포트를 변경한 뒤 프록시 설정도 함께 업데이트해야 합니다. 다운로드 페이지에는 두 인터페이스의 용도 차이도 안내되어 있어 현재 시스템 환경에 맞게 선택할 수 있습니다.
다운로드 페이지로 이동macOS를 다운로드하기 전 프로세서 아키텍처를 확인해야 하며, Apple Silicon과 Intel에는 서로 다른 설치 파일이 제공됩니다. 처음 실행할 때 시스템 보안 확인이나 네트워크 접근 권한 요청이 나타날 수도 있습니다. 시스템 설정에서 권한을 승인한 뒤 클라이언트로 돌아와 구독을 가져오세요. 연결 후에는 먼저 메뉴 막대 상태와 시스템 프록시를 확인하고 애플리케이션 접속을 테스트해 권한 문제를 노드 이상으로 오해하지 않도록 하세요.
다운로드 페이지로 이동Android의 기본 선택지는 Xray 커널을 사용하는 v2rayNG이며, V2Fly 커널을 선호한다면 v2flyNG를 선택할 수 있습니다. 최신 기기 대부분은 arm64 아키텍처를 사용하지만 아키텍처를 확인하기 어렵다면 다운로드 페이지에서 범용 설치 파일을 확인하세요. 구독을 가져온 뒤 노드를 선택하고 시스템 네트워크 연결을 시작해야 합니다. 이후 연결 상태, 앱별 설정, 배터리 백그라운드 제한을 각각 점검해 화면이 잠긴 뒤 클라이언트가 시스템에 의해 중지되지 않도록 하세요.
다운로드 페이지로 이동Linux 데스크톱에서는 배포판에 맞춰 deb 또는 rpm 설치 파일을 선택하고 x64와 arm64 아키텍처도 확인해야 합니다. 설치 후에는 그래픽 인터페이스로 구독, 노드, 라우팅 규칙을 관리할 수 있습니다. 시스템 프록시가 대상 애플리케이션에 영향을 주지 않는다면 데스크톱 환경의 프록시 설정과 애플리케이션이 자체 네트워크 설정을 사용하는지 확인하세요. 더 넓은 처리 범위가 필요할 때 TUN 권한과 가상 네트워크 어댑터 상태를 검토하면 됩니다.
다운로드 페이지로 이동클라이언트, 커널, 프로토콜의 역할을 구분하면 설정 문제가 어느 계층에서 발생했는지 판단하기 쉽고, 그래픽 인터페이스 이름과 구독 형식, 전송 프로토콜을 혼동하는 일도 줄일 수 있습니다.
V2Ray는 Project V 생태계에서 시작되었으며, 인바운드, 라우팅, 아웃바운드, 하위 전송 계층을 조합 가능한 설정 모듈로 나누는 설계를 핵심으로 삼았습니다. 커뮤니티의 유지보수 방향이 발전하면서 V2Fly는 v2ray-core 체계를 이어갔고, Xray는 유사한 설정 철학을 바탕으로 별도의 커널 계열로 발전했습니다. 두 커널 모두 다양한 프록시 프로토콜과 전송 방식을 처리할 수 있지만 구체적인 필드, 기능 지원 범위, 기본 동작은 다를 수 있습니다. 따라서 설정을 가져오기 전에 클라이언트가 사용하는 커널과 구독 내용에 해당 커널이 인식할 수 있는 매개변수가 포함되어 있는지 확인해야 합니다.
그래픽 클라이언트는 커널 위에서 작동하며 구독 관리, 노드 선택, 시스템 프록시, 로그 확인, 업데이트 설정을 담당합니다. v2rayN은 데스크톱 플랫폼용으로 소프트웨어에서 제공하는 옵션에 따라 해당 커널을 호출할 수 있고, v2rayNG는 주로 Xray 커널을 사용하며, v2flyNG는 V2Fly 커널 계열을 대상으로 합니다. 클라이언트 이름은 프로토콜 이름과 같지 않으며, 특정 클라이언트를 선택했다고 해서 모든 노드가 같은 프로토콜을 사용하는 것도 아닙니다. 실제 연결 경로는 노드 설정, 전송 계층, TLS 설정, 라우팅 규칙, 클라이언트 처리 방식이 함께 결정합니다.
V2Fly 코어, Xray 코어, 세 가지 그래픽 클라이언트는 각각 자체 코드와 라이선스 파일을 관리합니다. 핵심 프로젝트와 클라이언트는 서로 다른 오픈 소스 라이선스를 사용할 수 있으며, 배포 패키지에는 각자의 의존 구성 요소도 포함됩니다. 라이선스를 확인할 때는 생태계 전체를 하나의 프로젝트로 간주하지 말고 해당 소프트웨어 배포물에 포함된 안내를 기준으로 삼아야 합니다. 공개된 코드와 설정 형식은 커뮤니티가 구현을 검토하고 호환성을 논의하며 문제를 지속적으로 수정하는 데 도움이 됩니다.
그래픽 인터페이스와 네트워크 커널은 서로 다른 출시 주기를 가집니다. 클라이언트 업데이트는 구독 관리, 화면 상호작용, 시스템 통합을 조정할 수 있고, 커널 업데이트는 프로토콜 구현, 전송 기능, 라우팅, 네트워크 동작에 더 중점을 둡니다. 업그레이드 후 이상이 발생하면 먼저 변화가 클라이언트에서 왔는지 커널에서 왔는지 구분한 다음 로그와 설정 마이그레이션 안내를 함께 확인하세요. 다운로드 페이지에는 현재 설치入口를 모아 제공하며, 홈페이지에는 빠르게 바뀔 수 있는 출시 정보를 고정해 표시하지 않습니다.
VMess, VLESS, Trojan 등의 이름은 프로토콜 계층 설정을 가리키고, WebSocket, gRPC 등은 전송 방식을 의미합니다. TLS와 REALITY는 연결 인증 및 보안 전송과 관련되며, 라우팅 규칙은 요청이 어떤 아웃바운드를 사용할지 결정합니다. 문제를 점검할 때는 계층별로 확인해야 합니다. 도메인 조회가 실패했다고 바로 프로토콜 매개변수를 바꾸거나, 애플리케이션이 로컬 프록시에 들어오지 않는데 원격 노드를 반복해서 조정해서는 안 됩니다.
Windows, macOS, Linux에서 구독, 노드, 라우팅, 시스템 프록시, TUN 설정을 한곳에서 관리합니다. 데스크톱 환경에서 로그를 확인하고 여러 구독 그룹을 관리하며 트래픽 처리 방식을 세밀하게 조정해야 하는 사용자에게 적합합니다.
모바일 사용 흐름을 중심으로 구독 가져오기, 노드 선택, 앱별 프록시, 라우팅, 시스템 네트워크 연결을 관리할 수 있습니다. 백그라운드에서 연결이 끊기면 기기의 배터리 정책과 백그라운드 실행 권한도 함께 확인해야 합니다.
V2Fly 커널 구현이 필요한 모바일 설정을 대상으로 하며, Android 플랫폼에서 선택할 수 있는 또 다른 커널입니다. 가져오기 전에 구독 매개변수와 커널 지원 범위를 확인해 커널 차이를 구독 주소 오류로 오해하지 않도록 하세요.
구체적인 증상과 설정 단계를 중심으로 원리, 조작 절차, 결과 확인, 되돌리기 방법을 설명합니다. 먼저 기본 설치와 구독 가져오기를 완료한 뒤 실제 문제에 맞는 주제를 읽는 것을 권장합니다.
TUN 모드와 시스템 프록시의 본질적인 차이를 설명하고, 가상 네트워크 어댑터, 라우팅 테이블, DNS, 애플리케이션 트래픽의 관계를 정리합니다. 또한 v2rayN과 v2rayNG에서 활성화하는 단계와 권한 부족, 네트워크 미복구, 다른 가상 네트워크 어댑터 충돌 시 점검 방법을 안내합니다.
전체 문서 읽기클라이언트 시작 시 포트 충돌이 발생하면 먼저 수신 포트와 점유 프로세스를 확인한 뒤 기존 프로세스를 종료할지 설정을 변경할지 결정해야 합니다. 주요 데스크톱 시스템에서 확인하는 방법과 포트를 변경한 뒤 시스템 프록시 및 애플리케이션 프록시 설정도 반드시 함께 업데이트해야 하는 이유를 설명합니다.
전체 문서 읽기도메인 조회 경로를 바탕으로 클라이언트가 이미 연결된 상태에서도 조회 요청이 다른 네트워크 인터페이스로 전송될 수 있는 이유를 설명합니다. 점검 방법과 v2rayN, v2rayNG의 DNS 설정 확인 항목을 제시하고, 변경 전후 요청 경로를 비교해 해결 여부를 검증합니다.
전체 문서 읽기