Windows
v2rayN으로 구독, 서버 목록, 시스템 프록시, 라우팅 규칙을 관리하세요. 다운로드 센터에는 최신 데스크톱 인터페이스와 클래식 WPF 인터페이스가 함께 있어 사용 습관에 맞게 선택할 수 있습니다.
다운로드 페이지로 이동클라이언트 다운로드 및 설정 문서
v2rayN 데스크톱 클라이언트, Android 클라이언트와 한국어 설정 경로를 한곳에 정리했습니다. 구독 가져오기부터 시스템 프록시, 라우팅, 코어 선택까지 실제 설정 항목을 기준으로 각 단계의 역할을 설명합니다.
플랫폼 입구
데스크톱에서는 v2rayN을 기본으로 사용하고, Android에서는 v2rayNG와 v2flyNG 중에서 선택할 수 있습니다. 다운로드 센터는 CPU 아키텍처, 설치 형식, 클라이언트 인터페이스에 따라 알맞은 다운로드 경로를 제공합니다.
v2rayN으로 구독, 서버 목록, 시스템 프록시, 라우팅 규칙을 관리하세요. 다운로드 센터에는 최신 데스크톱 인터페이스와 클래식 WPF 인터페이스가 함께 있어 사용 습관에 맞게 선택할 수 있습니다.
다운로드 페이지로 이동v2rayN 데스크톱 인터페이스로 구독, 프록시, 라우팅 설정을 관리합니다. 다운로드 센터에서 기기가 Apple Silicon인지 Intel 프로세서인지 확인한 뒤 알맞은 설치 패키지를 선택하세요.
다운로드 페이지로 이동v2rayNG는 Xray 코어를 사용해 일반적인 프로토콜과 라우팅 설정에 적합합니다. v2flyNG는 V2Fly 코어를 사용하므로 다른 코어 생태계를 선택할 수 있습니다. 최신 기기에서는 대체로 arm64 아키텍처를 우선 선택합니다.
다운로드 페이지로 이동v2rayN은 주요 데스크톱 배포판에 필요한 설치 형식을 제공하며 x64와 arm64 아키텍처를 구분합니다. 설치 후에는 통합 인터페이스에서 구독, 코어, 라우팅, 시스템 프록시를 관리할 수 있습니다.
다운로드 페이지로 이동핵심 설정
실제 설정 순서에 맞춰 기능 입구를 구성했습니다. 아래 태그를 선택하면 각 설정의 용도, 조작 경로, 혼동하기 쉬운 차이를 확인할 수 있습니다.
구독 관리
구독 기능은 서버에서 제공하는 노드 목록을 클라이언트로 가져온 뒤 같은 그룹에서 업데이트, 필터링, 전환을 수행할 수 있게 합니다. 처음 추가할 때는 링크가 완전한지 확인하고 식별하기 쉬운 그룹 이름을 지정하세요. 노드가 자주 바뀌는 구독에는 자동 업데이트가 유용하지만 간격을 지나치게 짧게 설정하지 않는 것이 좋습니다. 요청이 실패하면 링크에 계속 접속할 수 있는지, 업데이트 요청이 현재 프록시를 거쳐야 하는지부터 확인하세요.
v2rayN에서는 구독 그룹 설정에서 그룹별 업데이트 동작을 따로 관리할 수 있어 모든 그룹에 같은 정책을 적용하지 않아도 됩니다. 직접 수정한 노드는 덮어쓰기 관계에 유의해야 합니다. 구독을 다시 업데이트하면 서버에서 내려온 내용이 로컬 사본을 대체할 수 있습니다. 중요한 사용자 설정은 구독에서 생성된 항목을 직접 수정하기보다 별도 저장하는 편이 안전합니다.
라우팅 분할
라우팅 규칙은 특정 요청을 직접 연결, 프록시 또는 차단 출구로 보낼지 결정합니다. 일반적으로 먼저 명확한 로컬 네트워크와 지역 도메인 집합을 처리한 다음, 일치하지 않는 트래픽을 기본 출구로 넘깁니다. 규칙은 보통 순서대로 매칭되므로 더 구체적인 조건을 포괄적인 조건보다 앞에 배치해야 합니다. 수정 후에는 이전 규칙이 연결을 처리하지 않도록 설정을 다시 불러와야 합니다.
v2rayN의 그래픽 설정은 일반적인 규칙을 관리하기에 적합하며, 복잡한 환경에서는 생성된 설정의 routing 부분을 추가로 확인할 수 있습니다. geosite는 도메인 집합, geoip는 주소 집합, network는 TCP 또는 UDP를 매칭하는 데 사용됩니다. 라우팅 분할은 시스템 프록시 모드의 대체 기능이 아닙니다. 시스템 프록시는 트래픽이 클라이언트로 들어오는 과정을, 라우팅은 코어에 들어온 뒤 어떤 출구를 사용할지를 각각 담당합니다.
코어 관리
그래픽 클라이언트는 설정을 입력, 변환, 관리하고, 실제 프로토콜·전송·라우팅 처리는 코어가 담당합니다. Xray와 V2Fly는 공통된 생태계에서 출발했지만 각각 기능과 호환 경로를 관리합니다. REALITY, XTLS 또는 특정 프로토콜 확장을 사용할 때는 선택한 코어가 해당 필드를 지원하는지 먼저 확인해야 합니다. 일반 설정도 이름만 보고 호환성을 판단해서는 안 됩니다.
코어를 전환하기 전에는 현재 연결을 중지하고 클라이언트가 코어 파일을 인식했는지 확인한 뒤 설정을 다시 시작하세요. 전환 후 시작에 실패하면 노드를 반복해서 바꾸기보다 로그의 필드 해석 메시지를 먼저 확인해야 합니다. Android에서는 보통 클라이언트 종류에 따라 주 코어가 결정됩니다. v2rayNG는 Xray에, v2flyNG는 V2Fly에 기반합니다.
프록시 연결 제어
시스템 프록시를 활성화하면 운영체제의 프록시 설정을 따르는 앱이 클라이언트의 수신 포트로 요청을 전달합니다. 이는 트래픽이 클라이언트로 들어오는 방식을 정할 뿐 모든 프로그램이 자동으로 연결된다는 뜻은 아닙니다. 일부 앱은 독립적인 네트워크 스택을 사용하거나 시스템 설정을 무시하므로 앱 자체의 프록시 설정을 확인하거나 플랫폼에서 지원하는 다른 연결 방식을 선택해야 합니다.
전역, 규칙, 우회 모드는 클라이언트가 트래픽을 받은 뒤 처리하는 방식을 설명합니다. 일상적인 웹 사용에는 명확한 대상이 라우팅 조건에 따라 분할되는 규칙 모드를 우선 사용하는 편이 좋습니다. 진단할 때는 잠시 처리 모드를 전환해 문제가 노드, 규칙, 시스템 프록시 입구 중 어디에 있는지 판단할 수 있습니다. 클라이언트를 종료하기 전 시스템 프록시 상태를 복원하면 이후 앱이 이전 포트를 계속 사용하는 일을 줄일 수 있습니다.
빠른 시작
가장 짧은 설정 경로를 먼저 완료한 뒤 자동 업데이트, 라우팅 규칙, 코어 설정을 단계적으로 추가하세요. 그러면 문제가 발생한 계층을 더 쉽게 파악할 수 있습니다.
구독 그룹 관리를 열고 새 그룹을 만든 다음 완전한 V2Ray 구독 링크를 붙여 넣으세요. 여러 그룹을 함께 사용할 때 빠르게 찾을 수 있도록 이름에는 용도를 반영하는 것이 좋습니다. 저장한 뒤 수동으로 한 번 업데이트하여 서버 항목이 정상적으로 생성되는지 확인하세요. 목록이 비어 있다면 먼저 라우팅이나 코어를 수정하지 말고 구독 계층으로 돌아가 링크, 접근 조건, 응답 형식을 확인해야 합니다.
처음 가져올 때는 기본 업데이트 정책을 유지하고 “링크를 읽을 수 있는지, 클라이언트가 해석할 수 있는지, 목록에 내용이 있는지” 세 가지 결과만 확인하는 것이 좋습니다. 자동 업데이트 간격은 연결이 성공한 후 설정할 수 있습니다. 이렇게 하면 구독 읽기 문제, 프록시 문제, 예약 작업 문제를 한꺼번에 처리하는 일을 피할 수 있습니다.
서버 목록에서 사용할 항목을 선택해 활성 설정으로 지정한 뒤 코어를 시작하세요. 이어서 앱 사용 범위에 맞게 시스템 프록시를 활성화하고 일상적인 트래픽에는 먼저 규칙 모드를 사용합니다. 시스템 프록시는 앱이 요청을 클라이언트로 보낼지를, 라우팅 규칙은 요청이 코어에 들어온 뒤 어느 출구로 갈지를 결정하므로 두 항목을 따로 확인해야 합니다.
특정 앱이 응답하지 않으면 먼저 해당 앱이 시스템 프록시를 따르는지 확인하세요. 특정 도메인에서만 문제가 발생한다면 라우팅 매칭 순서를 점검합니다. 입구가 정상 작동하는지 확인하기 전에 코어, 구독, 규칙을 연속해서 바꾸면 로그의 원인이 여러 설정 변경에 가려질 수 있습니다.
연결 후에는 먼저 클라이언트 로그를 확인해 설정이 코어에 정상적으로 로드되었고 필드 해석, 포트 충돌, 라우팅 형식 오류가 없는지 점검하세요. 그런 다음 시스템 프록시를 따르는 앱으로 접속을 확인하고, 직접 연결 규칙과 프록시 규칙이 예상대로 작동하는지 각각 검사합니다. 로그에는 설정 처리 결과가 기록되므로 화면 상태만 보는 것보다 문제 위치를 파악하기에 적합합니다.
기본 연결이 안정된 후 구독 자동 업데이트와 시작 시 자동 실행 같은 장기 설정을 활성화하세요. 한 번에 하나의 변수만 조정하고 라우팅이나 코어를 수정한 뒤에는 설정을 다시 불러옵니다. 작동하는 설정은 별도 사본으로 보관해 두면 새 규칙을 추가할 때 검증된 기준 상태로 빠르게 돌아갈 수 있습니다.
오픈 소스 생태계
클라이언트, 코어, 설정 형식은 서로 다른 계층에 속합니다. 각자의 역할을 이해하면 프로토콜 호환성, 기능 차이, 업데이트 영향을 판단하는 데 도움이 됩니다.
Project V는 설정 중심 네트워크 코어를 기반으로 기술 생태계를 형성했습니다. 커뮤니티의 유지보수 경로가 발전하면서 V2Fly는 V2Ray 코어와 관련 구성 요소를 이어받았고, Xray는 유사한 설정 체계 위에서 독자적인 기능 분기를 발전시켰습니다. 두 프로젝트는 인바운드, 아웃바운드, 라우팅, 전송, DNS 같은 개념을 많이 공유하지만 모든 필드, 프로토콜 확장, 실행 동작이 항상 완전히 동일한 것은 아닙니다.
따라서 “V2Ray 클라이언트”는 대개 생태계 범주를 가리키는 표현이며, 클라이언트 내부에서 하나의 고정 코어만 사용한다는 뜻은 아닙니다. 기능을 판단하려면 그래픽 관리 기능을 담당하는 클라이언트, 탑재된 코어의 특성, 구독 콘텐츠에 사용된 프로토콜 필드를 함께 확인해야 합니다. 클라이언트 이름만 비교해서는 실제 호환성을 완전히 설명할 수 없습니다.
v2rayN은 주로 데스크톱의 서버 목록, 구독 그룹, 시스템 프록시, 라우팅 설정, 로그 확인, 코어 관리를 담당합니다. 사용자가 인터페이스에서 설정을 완료하면 클라이언트가 코어가 읽을 수 있는 실행 설정으로 정리하고, Xray 또는 V2Fly가 연결을 처리합니다. 인터페이스에 “시작됨”으로 표시되는 것은 프로세스 상태만 의미하므로 프로토콜 핸드셰이크, DNS 조회, 라우팅 매칭은 코어 로그를 함께 확인해야 합니다.
이러한 계층형 설계의 장점은 설정 관리와 네트워크 처리가 각각 발전할 수 있다는 점입니다. 클라이언트 업데이트는 인터페이스, 구독 해석, 설정 생성 로직을 바꿀 수 있고, 코어 업데이트는 프로토콜 지원, 전송 구현, 필드 검증에 영향을 줄 수 있습니다. 업데이트 후 이상이 발생하면 먼저 변화가 어느 계층에서 일어났는지 구분한 다음 설정 복원, 코어 전환, 구독 내용 수정 여부를 결정해야 합니다.
v2rayN은 Windows, macOS, Linux 데스크톱 환경을 대상으로 하며 여러 구독을 통합 관리하고 라우팅 규칙을 편집하고 시스템 프록시를 전환하며 상세 로그를 확인해야 하는 상황에 적합합니다. 데스크톱 플랫폼마다 시스템 프록시 동작과 설치 형식은 다르지만 클라이언트의 구독, 서버, 코어 개념은 대체로 동일합니다. 다른 플랫폼으로 옮길 때는 로컬 경로와 플랫폼 권한을 다시 확인해야 합니다.
v2rayNG는 Android용으로 Xray 코어를 주로 사용하며 모바일 네트워크 전환, 구독 업데이트, 라우팅, 연결 제어를 중심으로 인터페이스가 구성됩니다. v2flyNG도 Android용이지만 코어 선택의 차이를 통해 다른 설정 경로를 제공합니다. 두 앱 모두 오픈 소스 커뮤니티에서 유지보수되는 그래픽 클라이언트이며, 선택할 때는 이름이 아니라 구독 프로토콜, 코어 요구 사항, 설정 습관을 기준으로 판단해야 합니다.
오픈 소스 프로젝트는 커뮤니티가 코드를 확인하고 구현을 논의하며 기능을 지속적으로 유지보수할 수 있게 합니다. 일반 사용자에게 오픈 소스의 직접적인 의미는 설정 동작과 문제 기록을 기술 커뮤니티가 분석할 수 있고, 클라이언트와 코어가 독립적으로 수정 버전을 배포할 수 있다는 점입니다. 그러나 기본적인 버전 선택, 권한 관리, 설정 검토를 대신하지는 않으므로 기기 플랫폼과 실제 요구에 맞는 소프트웨어 입구를 선택해야 합니다.
업데이트할 때는 먼저 기능 변경 사항을 읽고 기존 설정을 보존한 다음 구독 해석, 코어 시작, 시스템 프록시 세 가지 기본 단계를 확인하세요. 현재 설정이 안정적이고 명확한 기능 요구가 없다면 변경 내용을 파악한 뒤 업데이트를 진행해도 됩니다. 새 프로토콜 필드가 특정 코어 기능에 의존한다면 클라이언트의 설정 생성 능력과 코어 지원 여부를 함께 고려해야 합니다. 사이트의 가이드는 이러한 계층 구분에 따라 조작 단계와 문제 해결 경로를 정리합니다.
자주 묻는 질문
문제가 구독, 코어, 시스템 프록시, 라우팅 중 어느 계층에 있는지 먼저 판단한 뒤 해당 설정을 점검하세요.
먼저 구독 링크가 완전하고 여전히 접속 가능한지 확인한 다음 업데이트 요청에 프록시가 필요한지, 응답 내용이 클라이언트에서 해석할 수 있는 구독 형식인지 점검하세요. 목록이 생성되기 전에는 시스템 프록시 모드를 바꾸거나 라우팅 규칙을 수정해도 구독 읽기 문제가 해결되지 않는 경우가 많습니다. 빠른 시작 가이드에서 가져오기 순서에 따라 다시 확인할 수 있습니다.
먼저 코어 로그에서 설정이 정상적으로 로드되었는지 확인하고 대상 앱이 시스템 프록시를 따르는지 점검하세요. 다른 앱은 연결되는데 특정 앱만 문제가 있다면 해당 앱의 네트워크 설정을 확인해야 합니다. 모든 앱이 연결되지 않는다면 시스템 프록시 포트와 클라이언트의 수신 상태를 점검하세요. 자세한 절차는 문제 진단에서 증상별로 확인할 수 있습니다.
시스템 프록시는 앱이 요청을 클라이언트로 보낼지를 결정하고, 전역 또는 규칙 모드는 클라이언트가 요청을 받은 뒤 출구를 선택하는 방식을 결정합니다. 구체적인 라우팅 규칙은 도메인, 주소, 네트워크 유형을 매칭합니다. 세 개념은 서로 다른 처리 단계에 있으므로 문제를 점검할 때 “앱이 클라이언트에 들어오지 않음”과 “라우팅 선택이 예상과 다름”을 같은 문제로 취급해서는 안 됩니다.
설정에 특정 프로토콜 확장이 포함되어 있거나, 코어 로그에서 지원되지 않는 필드가 표시되거나, 특정 기능의 코어 호환성을 확인해야 할 때 전환을 고려하세요. 일반적인 연결 문제라면 먼저 구독 내용, 시간 설정, 시스템 프록시, 라우팅을 점검해야 합니다. 전환 전에는 현재 연결을 중지하고, 전환 후에는 설정을 다시 불러온 다음 로그에서 실제 실행 코어와 필드 해석 결과를 확인하세요.
가이드 업데이트
문서 영역에서는 홈페이지에서 다루지 않은 설정 원리, 선택 기준, 배포 범위를 보충합니다. 기본 연결을 완료한 후 이어서 읽기에 적합합니다.
자주 사용하는 세 가지 형식의 구조, 클라이언트 지원 범위, 변환 한계를 살펴보고 가져오기에 실패했을 때 어느 계층부터 확인해야 하는지 설명합니다.
전체 글 읽기 →기본 라우터와 우회 라우터의 연결 방식을 비교하고 투명 프록시, DNS 처리, 적용 기기 범위, 성능 제약을 정리합니다.
전체 글 읽기 →두 코어의 유지보수 경로를 정리하고 프로토콜 기능, 설정 필드, 세 가지 그래픽 클라이언트 사이의 대응 관계를 설명합니다.
전체 글 읽기 →