Windows
Windows 데스크톱에서는 v2rayN을 우선 선택하는 것이 좋습니다. 다운로드 페이지에서 차세대 데스크톱 인터페이스와 기존 WPF 인터페이스의 차이도 확인할 수 있습니다. 처음 실행한 뒤에는 “구독 추가—목록 업데이트—노드 선택—시스템 프록시 설정” 순서로 진행하면 각 단계가 완료되었는지 확인하기 쉽습니다.
다운로드 페이지로 이동클라이언트의 핵심 차이는 설치 화면뿐 아니라 구독을 정리하는 방식, 트래픽에 규칙을 적용하는 방식, 문제가 생겼을 때 원인을 빠르게 찾는 방법에 있습니다. 아래에서 실제 사용 순서에 따라 나누어 설명합니다.
구독 주소는 여러 노드의 설정을 일괄 전달하고, 클라이언트는 이를 해석해 해당 그룹에 넣습니다. 가져오기 전에 링크가 완전한지 확인한 뒤 출처별로 알아보기 쉬운 이름을 지정하세요. 업데이트할 때는 먼저 구독을 새로 고친 다음 현재 사용할 노드를 선택해야 이전 목록을 계속 사용하는 일을 피할 수 있습니다. v2rayN은 데스크톱에서 여러 구독을 독립 그룹으로 나누어 관리하기 좋고, v2rayNG와 v2flyNG는 모바일에서 간결한 목록을 유지하는 데 적합합니다. 자동 업데이트 간격은 구독 제공자의 갱신 주기에 맞추면 되며, 같은 주소를 매번 수동으로 가져올 필요는 없습니다.
업데이트 후 기존 선택이 사라졌다면 먼저 노드를 다시 선택하고 상태를 확인한 다음, 구독 내용에서 그룹이나 노드 이름이 변경되었는지 살펴보세요. 모든 설정을 바로 삭제하는 것보다 이 순서가 유효한 설정을 보존하기 쉽고, 문제가 구독 응답에서 비롯되었는지 로컬 선택 상태에서 비롯되었는지도 판단하기 좋습니다.
시스템 프록시는 애플리케이션이 요청을 클라이언트에 전달할지 결정하고, 라우팅 규칙은 요청이 클라이언트에 들어온 뒤 프록시, 직접 연결, 차단 중 어디로 보낼지 결정합니다. 서로 다른 계층에 있으므로 문제를 확인할 때 혼동해서는 안 됩니다. 일반적인 브라우저와 시스템 설정을 따르는 데스크톱 프로그램은 먼저 시스템 프록시 자동 구성을 사용해 보세요. 대상별로 더 세밀하게 매칭해야 한다면 로컬 네트워크 및 중국 본토 우회 또는 수동 규칙을 선택하면 됩니다. 규칙을 바꾼 뒤에는 새 연결을 만들어 다시 테스트해야 하며, 기존 연결은 변경 전 경로를 계속 사용할 수 있습니다.
수동 규칙은 도메인, 주소 대역, 프로세스별 특수 요구를 처리할 때 유용하지만 규칙 순서가 최종 결과에 영향을 줍니다. 더 구체적인 범위의 규칙은 보통 앞에 두고, 일반적인 기본 규칙은 뒤에 배치합니다. 처음부터 낯선 규칙을 대량으로 가져오기보다 규칙 수를 관리 가능한 수준으로 유지한 뒤 하나씩 추가하는 편이 관리하기 쉽습니다.
domain:geosite-cn → direct
ip:geoip-private → direct
final → proxy
연결에 문제가 생겼을 때는 스위치를 반복해서 바꾸는 것보다 로그가 판단에 더 유용합니다. 구독 업데이트 단계에서는 네트워크 요청, 응답 형식, 파싱 결과를 확인하고, 노드 연결 단계에서는 도메인 확인, 핸드셰이크, 전송 매개변수 및 원격 응답을 확인하세요. 일부 애플리케이션만 접속되지 않는다면 시스템 프록시 또는 TUN이 트래픽을 가로채는 범위도 점검해야 합니다. 문제를 단계별로 나누면 구독 주소 문제를 노드 문제로 잘못 판단하는 일을 줄일 수 있습니다.
로그의 시간 순서도 중요합니다. 먼저 이전 출력을 지운 뒤 구독 업데이트나 대상 페이지 열기처럼 명확한 동작을 한 번 실행하고, 해당 동작에서 생성된 기록만 관찰하세요. 재시도가 계속될 때는 마지막 요약 줄만 보지 말고 가장 먼저 발생한 오류부터 처리해야 합니다.
INFO load routing rules
INFO apply system proxy
INFO subscription parsed
INFO outbound configuration ready
데스크톱에서는 v2rayN을 공통으로 확인하고, Android 기기에서는 v2rayNG와 v2flyNG 중에서 선택할 수 있습니다. 플랫폼 바로가기는 해당 다운로드 섹션으로 이동하는 역할만 하며, 구체적인 설치 패키지 종류, 프로세서 아키텍처 및 설치 안내는 다운로드 페이지에 항목별로 정리되어 있습니다.
Windows 데스크톱에서는 v2rayN을 우선 선택하는 것이 좋습니다. 다운로드 페이지에서 차세대 데스크톱 인터페이스와 기존 WPF 인터페이스의 차이도 확인할 수 있습니다. 처음 실행한 뒤에는 “구독 추가—목록 업데이트—노드 선택—시스템 프록시 설정” 순서로 진행하면 각 단계가 완료되었는지 확인하기 쉽습니다.
다운로드 페이지로 이동macOS에서는 v2rayN 데스크톱 클라이언트를 사용합니다. 설치 패키지를 선택하기 전에 기기가 Apple Silicon인지 Intel 프로세서인지 확인하세요. 두 아키텍처에는 각각 맞는 파일이 필요합니다. 설치가 끝나면 구독을 가져오고, 평소 사용하는 애플리케이션이 시스템 프록시를 따르는지에 따라 TUN 모드 활성화 여부를 결정하세요.
다운로드 페이지로 이동Android에서는 v2rayNG를 우선 선택하고, 코어 선호도에 따라 v2flyNG를 선택할 수도 있습니다. 비교적 최신 기기라면 먼저 arm64 설치 패키지를 확인하고, 아키텍처를 알 수 없다면 범용 버전 안내를 참고하세요. 두 클라이언트 모두 구독 가져오기와 라우팅 설정을 지원하지만 코어 계열과 인터페이스 구성 방식은 다릅니다.
다운로드 페이지로 이동Linux 데스크톱에서는 v2rayN을 사용하며, 배포판의 패키지 체계에 따라 deb 또는 rpm을 선택하고 프로세서 아키텍처에 맞는 파일을 받아야 합니다. 설치 후에는 먼저 클라이언트에서 구독과 프록시를 설정한 다음, 부팅 시 자동 실행이나 데스크톱 환경의 프록시 동기화 같은 일상적인 관리 항목을 검토하는 것이 좋습니다.
다운로드 페이지로 이동처음 설정할 때 자주 생기는 문제는 고급 옵션 자체보다 작업 순서가 뒤섞이는 데서 발생합니다. 먼저 구독을 가져오고, 다음으로 노드와 프록시 모드를 확인한 뒤, 마지막에 새로운 네트워크 요청으로 결과를 검증하면 문제 범위를 빠르게 좁힐 수 있습니다.
완전한 구독 주소를 복사해 클라이언트의 구독 관리에서 새 항목으로 추가하고, 알아보기 쉬운 이름을 지정하세요. 저장한 뒤 업데이트를 실행해 선택 가능한 노드가 목록에 나타나는지 확인합니다. 업데이트 결과가 없으면 링크의 앞뒤가 잘리지 않았는지 먼저 확인한 다음 로그의 네트워크 요청과 파싱 안내를 살펴보세요. 가져오기에 실패했다고 바로 라우팅이나 TUN 설정을 바꾸지는 마세요. 이 옵션들은 구독 응답 문제를 해결하지 못합니다.
업데이트된 그룹에서 노드를 하나 선택한 다음 현재 애플리케이션에 맞는 시스템 프록시 모드를 활성화하세요. 브라우저와 대부분의 데스크톱 애플리케이션은 시스템 프록시를 읽지만, 일부 프로그램은 독립적인 네트워크 스택을 사용하므로 별도 설정이나 TUN이 필요할 수 있습니다. 첫 테스트에서는 라우팅 규칙을 단순하게 유지하고 기본 연결이 확인된 뒤 분할 라우팅 요구를 단계적으로 추가하세요.
설정을 바꾼 뒤 기존 페이지나 연결을 닫고 새로운 접속 요청을 보내세요. 연결되지 않으면 해당 동작 중 생성된 로그를 확인해 문제가 도메인 확인, 프로토콜 핸드셰이크, 전송 매개변수 또는 시스템 프록시 인계 단계 중 어디에 있는지 판단합니다. 한 번에 하나의 변수만 조정하고 즉시 다시 테스트해야 어떤 설정이 실제 결과에 영향을 주었는지 알 수 있습니다.
먼저 주소가 완전한지, 기기 네트워크에서 해당 주소로 요청을 보낼 수 있는지 확인한 뒤 클라이언트 로그에서 네트워크 오류와 콘텐츠 파싱 오류를 구분하세요. 구독 문제를 해결하기 전에는 노드를 계속 바꿀 필요가 없습니다.
구독 가져오기 단계 보기먼저 해당 프로그램이 시스템 프록시를 따르는지 확인하세요. 독립적인 네트워크 스택을 사용한다면 프로그램 자체의 프록시 옵션을 확인하거나 현재 기기 환경에 TUN 모드가 적합한지 검토할 수 있습니다.
연결 설정 보기기존 연결이 이전 경로를 계속 사용할 수 있습니다. 대상 프로그램의 현재 연결을 닫고 요청을 다시 보낸 뒤, 새 로그가 변경한 규칙에 매칭되었는지 확인하세요.
라우팅 분할 장 읽기데스크톱에서는 v2rayN을 사용하고, Android에서는 v2rayNG 또는 v2flyNG를 선택할 수 있습니다. 구독 내용은 같아도 클라이언트마다 메뉴 위치와 코어 계열이 다를 수 있습니다.
클라이언트 목록 보기코어, 클라이언트, 구독의 역할을 구분하면 기능의 출처를 정확히 판단하는 데 도움이 됩니다. 그래픽 인터페이스는 설정과 관리를 담당하고, 코어는 실제 네트워크 처리를 담당하며, 구독은 클라이언트가 로컬 설정으로 변환할 수 있는 연결 매개변수 묶음을 제공합니다.
Project V는 프록시 프로토콜, 전송 방식, 라우팅 규칙 및 설정 구조를 중심으로 오픈 소스 생태계를 발전시켰습니다. VMess와 VLESS 같은 프로토콜 이름은 연결 설정의 일부이며, TCP, WebSocket, gRPC 같은 전송 방식은 데이터를 전달하고 routing 규칙은 대상별로 어느 아웃바운드에 맡길지 결정합니다. 클라이언트는 이러한 필드를 조작 가능한 인터페이스로 구성하지만, 기본 개념은 여전히 같은 종류의 설정 모델에서 비롯됩니다.
따라서 “클라이언트 이름”과 “프로토콜 이름”은 서로 대신 사용할 수 없습니다. v2rayN, v2rayNG, v2flyNG는 사용자가 직접 조작하는 그래픽 클라이언트이고, VMess, VLESS, Trojan은 노드 매개변수에 포함될 수 있는 프로토콜 유형입니다. V2Fly와 Xray는 설정 실행을 담당하는 코어 계열입니다. 연결 문제가 발생하면 바로 재설치하기보다 먼저 어느 계층의 문제인지 확인하는 편이 효과적입니다.
V2Fly는 Project V의 커뮤니티 유지 관리 흐름을 이어받아 프로토콜 구현, 전송 계층, 라우팅 및 인바운드·아웃바운드 구조를 계속 발전시키고 있습니다. Xray는 유사한 설정 모델을 바탕으로 자체 기능을 확장해 왔습니다. 두 코어 모두 일반적인 구독 노드를 처리할 수 있지만, 지원하는 프로토콜 필드, 전송 옵션 및 새 기능이 항상 일치하는 것은 아닙니다. 구독 제공자가 필요한 코어를 명시했다면 요구 사항에 맞는 클라이언트와 코어를 선택해 필드 비호환을 구독 오류로 오해하지 않도록 하세요.
라우팅 설정의 인바운드, 아웃바운드 및 규칙 매칭은 두 코어 계열을 이해하는 공통 기반입니다. 인바운드는 로컬 애플리케이션이 트래픽을 코어에 전달하는 방식을 설명하고, 아웃바운드는 트래픽이 어떤 연결 방식으로 나가는지 설명하며, routing은 그 사이에서 경로를 선택합니다. 그래픽 클라이언트는 많은 JSON 필드를 숨기지만, 고급 설정의 시스템 프록시, TUN, 분할 라우팅 규칙 및 DNS 옵션은 결국 이러한 구조에 매핑됩니다.
v2rayN은 Windows, macOS, Linux용 데스크톱 클라이언트로, 여러 구독 관리, 시스템 프록시 전환, 라우팅 규칙 편집 및 상세 로그 확인에 적합합니다. v2rayNG는 Android 기기용이며 일반적으로 Xray 코어와 함께 사용되고, 모바일 네트워크, VPN 인계 및 구독 목록을 중심으로 인터페이스가 구성됩니다. v2flyNG 역시 Android용이지만 V2Fly 코어를 사용하므로 특정 코어를 선호하거나 명확한 설정 요구가 있을 때 선택할 수 있습니다.
클라이언트 간에 인터페이스를 완전히 동일하게 맞출 필요는 없습니다. 구독 출처, 노드 매개변수 및 라우팅 대상이 일관된지 확인하고, 각 클라이언트에서 같은 기능이 어디에 배치되어 있는지 이해하는 것이 더 중요합니다. 예를 들어 데스크톱에서는 애플리케이션의 접속 방식을 “시스템 프록시”로 설명하는 경우가 많고, Android에서는 시스템이 제공하는 VPN 인터페이스로 트래픽을 인계합니다. 진입점은 달라도 목적은 대상 요청을 로컬 코어로 보내는 것입니다.
이러한 클라이언트와 코어는 오픈 소스 방식으로 유지 관리되며, 기능 논의, 버그 수정 및 호환성 조정은 여러 커뮤니티 참여자가 진행합니다. 공개된 유지 관리 방식은 기술 담당자가 설정 생성 과정을 이해하기 쉽게 하고, 프로토콜 구현과 플랫폼 대응이 계속 발전하도록 돕습니다. 실제로 사용할 때는 클라이언트와 코어의 호환 관계를 계속 확인해야 하며, 특히 새 프로토콜 필드, 전송 방식 및 운영체제 네트워크 인터페이스가 변경될 때 주의해야 합니다.
클라이언트를 업데이트하기 전에 현재 구독 이름, 프록시 모드, 라우팅 선택 및 TUN 상태를 기록해 두세요. 업데이트가 끝나면 원래 순서대로 설정을 확인하고 명확한 연결 테스트를 한 번 실행해 로그를 살펴봅니다. 새 버전에서 메뉴 위치가 바뀌었다면 오래된 스크린샷만 보고 버튼을 찾기보다 기능 이름과 설정 의미를 기준으로 확인하세요. 이 방법이 장기적인 관리에 적합하고 인터페이스 변경으로 인한 오작동도 줄일 수 있습니다.
클라이언트 선택, 최초 설정 및 지연 시간 테스트를 중심으로 재사용할 수 있는 작업 방법을 정리했습니다.
지원 플랫폼, 코어 계열, 구독 관리, 라우팅 분할 기능의 네 가지 관점에서 세 클라이언트를 비교하고 데스크톱과 Android에서의 선택 기준을 제시합니다.
전체 글 읽기 →실행 환경, 시스템 프록시, 구독 가져오기 순서, 부팅 시 자동 실행 및 업데이트 간격을 차례로 확인해 최초 설정에서 빠뜨리는 항목을 줄입니다.
전체 글 읽기 →세 가지 테스트가 각각 연결의 어느 구간을 측정하는지 설명하고, 단일 지연 시간 수치만으로는 노드의 실제 사용 성능을 완전히 판단할 수 없는 이유를 다룹니다.
전체 글 읽기 →