Windows
v2rayN은 데스크톱 버전과 클래식 WPF 버전을 제공합니다. 데스크톱 버전은 크로스 플랫폼 인터페이스를 사용하고, WPF 버전은 기존 조작 방식을 유지합니다. 먼저 시스템 요구 사항을 확인한 뒤 사용 방식에 맞춰 선택하세요.
다운로드 페이지로 이동 →운영체제에 맞는 클라이언트를 선택하고 구독 가져오기로 설정을 불러오세요. 라우팅 분기로 직접 연결과 프록시 연결을 구분한 다음, 필요에 따라 코어·Tun·DNS를 조정하면 됩니다.
CLIENT SELECTION
먼저 운영체제와 프로세서 아키텍처를 확인한 뒤 설치 파일을 선택하세요. 데스크톱에서는 v2rayN, Android에서는 v2rayNG를 우선 추천합니다. 기존 V2Fly 설정을 사용한다면 v2flyNG도 살펴볼 수 있습니다. 클라이언트는 설정을 관리하며, 실제로 연결하려면 유효한 서버 정보가 필요합니다.
v2rayN은 데스크톱 버전과 클래식 WPF 버전을 제공합니다. 데스크톱 버전은 크로스 플랫폼 인터페이스를 사용하고, WPF 버전은 기존 조작 방식을 유지합니다. 먼저 시스템 요구 사항을 확인한 뒤 사용 방식에 맞춰 선택하세요.
다운로드 페이지로 이동 →v2rayN 데스크톱 버전을 선택하세요. 먼저 ‘이 Mac에 관하여’에서 칩 종류를 확인해야 합니다. Apple Silicon과 Intel은 설치 파일이 다르므로 기기 외형만 보고 판단하지 마세요.
다운로드 페이지로 이동 →Xray 코어를 사용하는 v2rayNG를 우선 추천하며, v2flyNG는 V2Fly 코어를 사용하는 대안입니다. 일반적으로 arm64 설치 파일을 먼저 확인하고, 아키텍처가 확실하지 않다면 범용 버전 안내를 살펴보세요.
다운로드 페이지로 이동 →v2rayN 데스크톱 버전을 사용하고 배포판에 맞춰 deb 또는 rpm을 선택한 다음 x64와 arm64를 구분하세요. 패키지 형식과 프로세서 아키텍처는 별개의 조건이므로 둘 다 맞아야 합니다.
다운로드 페이지로 이동 →설치 파일은 클라이언트가 현재 기기에서 실행되는지를 결정할 뿐, 서버에서 사용하는 프로토콜을 정하지 않습니다. 구독이 있다면 먼저 안내된 코어와 프로토콜을 확인한 뒤 설치 파일을 선택하세요. 다른 데스크톱 아키텍처용 설치 파일이 실행되지 않는다고 구독에 문제가 있다고 단정하지 마세요.
전체 클라이언트 보기 →CONFIGURATION WORKSPACE
구독은 서버 정보를 제공하고, 라우팅은 트래픽의 경로를 정하며, 코어는 설정을 실행합니다. 먼저 각 역할을 구분한 다음 세부 옵션을 조정하세요. 아래 예시는 필드 설명을 위한 일부 설정이며 기존 파일을 통째로 대체할 수 있는 완성본이 아닙니다. 그래픽 인터페이스의 메뉴 이름은 클라이언트 업데이트에 따라 달라질 수 있습니다.
구독 링크는 서버 설정을 가져오는 주소이며, 개별 서버의 공유 링크와는 다릅니다. 클라이언트에서 출처별 그룹을 만들고 구독 주소를 입력한 뒤 업데이트를 실행해 결과를 확인하세요. 서버 정보를 하나씩 직접 추가하는 것보다 연결 설정을 한곳에서 관리하기 편리하지만, 직접 수정한 항목은 다음 업데이트 때 다시 생성될 수 있습니다. 출처를 알아보기 쉽도록 그룹에 메모를 남기고, 먼저 수동 업데이트를 한 번 완료한 다음 자동 업데이트를 설정하는 것이 좋습니다. 구독에는 연결 인증 정보가 포함되므로 문제를 확인할 때 전체 주소를 가리고 공개 스크린샷에 노출하지 마세요.
{
"inbounds": [
{
"tag": "socks-in",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": { "udp": true }
},
{
"tag": "http-in",
"listen": "127.0.0.1",
"port": 10809,
"protocol": "http",
"settings": {}
}
]
}
구독은 클라이언트에서 관리하며 공통 코어 설정 필드가 아닙니다. 여기서는 구독 설정을 가져온 뒤 사용할 수 있는 로컬 인바운드 구조를 보여 줍니다. 포트는 실제 설정과 일치해야 합니다.
구독 가져오기 단계 보기 →라우팅 규칙은 순서대로 확인하며, 조건에 맞으면 지정된 아웃바운드로 전달됩니다. 먼저 로컬 네트워크와 특정 도메인 규칙을 배치하고, 범위가 넓은 규칙은 뒤에 두며, 나머지 트래픽은 마지막에 처리하세요. 전체 모드만 전환하는 것과 달리 라우팅 분기를 사용하면 직접 연결·프록시·차단을 각각 지정해 서로 영향을 덜 주도록 구성할 수 있습니다. 설정 전에 아웃바운드 태그가 실제로 존재하는지, 도메인 및 주소 규칙 데이터가 유효한지 확인하세요. 한 규칙 안의 여러 조건은 일반적으로 모두 충족해야 하므로, 각각 따로 적용하려는 조건을 한 규칙에 함께 넣지 마세요. 변경 후에는 로그에서 실제로 적용된 규칙을 확인하세요.
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
},
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
},
{
"type": "field",
"network": "tcp,udp",
"outboundTag": "proxy"
}
]
}
}
이 예시는 direct 및 proxy 아웃바운드와 해당 규칙 데이터가 이미 있어야 합니다. 기본 처리 규칙은 구체적인 규칙 뒤에 배치해야 합니다.
라우팅 분기 안내서 보기 →코어는 프로토콜 처리와 연결을 담당하고, 클라이언트는 인터페이스와 설정을 관리합니다. 코어는 이름만 보고 선택하지 말고 서버의 프로토콜 및 전송 요구 사항을 확인해야 합니다. REALITY와 XTLS Vision을 사용하려면 해당 기능을 지원하는 Xray 설정 구성이 필요하며, 기존 V2Fly 설정은 대상 코어의 필드 안내를 확인해야 합니다. 두 코어는 일부 설정 개념을 공유하지만 모든 필드를 서로 바꿔 쓸 수 있는 것은 아닙니다. 전환 전에 기존 설정을 저장하고, 전환 후에는 시작 로그와 실제 연결을 확인해 필드 호환성 문제를 서버 장애로 오해하지 않도록 하세요.
{
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
},
{
"tag": "block",
"protocol": "blackhole",
"settings": {}
}
]
}
두 코어 계열에서 흔히 볼 수 있는 기본 아웃바운드 구조입니다. 코어 전환 명령이 아니며 프록시 서버 아웃바운드는 포함하지 않습니다.
코어 차이 비교 보기 →시스템 프록시는 운영체제의 프록시 설정을 따르는 앱에 적합합니다. Tun 모드는 가상 네트워크 어댑터를 통해 트래픽을 처리하므로 시스템 프록시를 사용하지 않는 일부 프로그램에도 적용할 수 있습니다. 다만 라우팅 규칙을 대체하지는 않으며, 처리된 트래픽도 직접 연결할지 프록시로 보낼지 정해야 합니다. 사용 전에 일반 프록시 연결이 정상인지 확인하고 필요한 권한을 허용하세요. 다른 가상 네트워크 어댑터나 프록시 프로그램이 동시에 실행 중인지도 점검해야 합니다. Android 클라이언트는 일반적으로 시스템 VPN 인터페이스로 트래픽 처리 경로를 만들며, 데스크톱 구현과 동일하게 볼 수 없습니다. 문제가 생기면 먼저 트래픽 처리를 중지하고 기본 연결을 복구한 뒤 항목별로 확인하세요.
{
"routing": {
"rules": [
{
"type": "field",
"inboundTag": ["socks-in", "http-in"],
"network": "tcp,udp",
"outboundTag": "proxy"
}
]
}
}
이 예시는 트래픽 처리 계층과 라우팅 계층의 차이를 설명하며, 가상 네트워크 어댑터를 만드는 용도가 아닙니다. Tun의 구체적인 설정은 클라이언트와 함께 사용하는 구성 요소에 따라 달라집니다.
프록시 모드 선택 방법 보기 →DNS 이름 해석은 도메인을 IP 주소로 변환하는 과정이며, 이름 해석 경로와 연결 경로를 함께 고려해야 합니다. 직접 연결할 도메인은 현재 네트워크에서 접근할 수 있는 DNS 서비스를 사용하고, 프록시를 사용할 도메인은 원격 이름 해석 경로가 정상인지 확인하세요. DNS 주소 하나만 바꿨다고 모든 앱의 이름 해석 방식이 같아지는 것은 아닙니다. 브라우저의 보안 DNS, 시스템 캐시, 클라이언트 내장 DNS가 각각 적용될 수 있습니다. 작동하는 기본 설정은 유지한 채 도메인 해석과 대상 서버 연결을 따로 테스트하는 것이 좋습니다. 암호화된 DNS를 사용할 때는 DNS 서버의 도메인을 처음 해석하는 과정에도 유의하세요.
{
"dns": {
"servers": [
{
"address": "223.5.5.5",
"domains": ["geosite:cn"]
},
"https://1.1.1.1/dns-query"
]
}
}
DNS 서비스 주소는 예시입니다. 이 설정만으로 DNS 요청의 아웃바운드 경로가 정해지지 않으므로 라우팅 규칙과 현재 코어의 동작을 함께 확인해야 합니다.
DNS 설정 안내 보기 →FIRST CONNECTION
먼저 연결을 확인할 수 있는 기본 구성을 만들고, 그다음 라우팅 분기와 트래픽 처리 설정을 추가하세요. 데스크톱에서는 주로 v2rayN, Android에서는 주로 v2rayNG를 사용합니다. 인터페이스의 버튼 위치는 다르지만 가져오기, 선택, 연결, 확인 순서는 같습니다.
STEP 01
구독 관리에서 그룹을 만들고 전체 구독 주소를 붙여 넣은 다음 저장하고 수동으로 업데이트하세요. 개별 공유 링크를 받은 경우에는 구독 주소 입력란이 아니라 클립보드 가져오기나 해당 공유 링크 가져오기 기능을 사용해야 합니다.
업데이트가 끝나면 먼저 선택 가능한 설정이 목록에 표시되는지 확인하고, 프로토콜 종류·포트·전송 필드가 모두 있는지 살펴보세요. 목록이 비어 있다면 주소가 온전히 복사되었는지, 구독이 유효한지, 현재 네트워크에서 구독 서비스에 접속할 수 있는지부터 확인하세요. 클라이언트를 반복해서 재설치해도 구독 주소 문제는 해결되지 않는 경우가 많습니다.
STEP 02
사용할 서버 설정을 선택하고 현재 코어가 해당 프로토콜을 지원하는지 확인하세요. 데스크톱을 처음 사용한다면 시스템 프록시를 먼저 켜고 필요에 맞는 라우팅 모드를 선택할 수 있습니다. Android에서는 시스템 안내에 따라 VPN 연결 권한을 허용하세요.
시스템 프록시 설정은 어떤 앱이 요청을 클라이언트로 전달할지 결정하고, 라우팅 모드는 클라이언트가 요청을 받은 뒤 어떻게 전달할지 결정합니다. 서로 대체할 수 없습니다. 먼저 이해하기 쉬운 기본 설정으로 연결을 확인한 다음 도메인 규칙을 추가하세요. 여러 옵션을 한꺼번에 바꾸면 문제를 추적하기 어려워집니다.
STEP 03
연결을 시작한 뒤 직접 연결될 것으로 예상하는 사이트와 프록시를 사용할 것으로 예상하는 사이트에 각각 접속하고, 클라이언트 로그에서 실제 아웃바운드를 확인하세요. 한 번의 연결 테스트가 성공했다고 해서 브라우저·다운로드 프로그램·다른 앱도 모두 같은 경로를 사용한다는 뜻은 아닙니다.
브라우저는 되지만 다른 앱이 연결되지 않는다면 먼저 해당 앱이 시스템 프록시를 따르는지 확인하세요. 사용을 마칠 때는 시스템 프록시나 가상 네트워크 어댑터를 통한 트래픽 처리를 먼저 끈 뒤 클라이언트를 종료하세요. 종료 후 네트워크에 문제가 생기면 네트워크 설정을 전부 바꾸기 전에 시스템 프록시가 이미 중지된 로컬 포트를 가리키고 있지 않은지 확인하세요.
구독 업데이트 실패, 코어 시작 실패, 앱 연결 실패는 서로 다른 단계의 문제입니다. 문제가 발생한 단계를 기록하고 해당 단계와 관련된 설정 하나만 바꾼 뒤 같은 테스트를 반복하세요. 이렇게 하면 정상 작동하는 설정을 보존하고 DNS·권한·서버 매개변수 문제를 혼동하지 않을 수 있습니다.
PROJECT V ECOSYSTEM
V2Ray는 널리 쓰이는 생태계 명칭이지, 인터페이스가 모두 동일한 하나의 앱을 뜻하지 않습니다. 클라이언트·코어·프로토콜의 관계를 이해해야 설치 파일을 바꿀지, 설정을 수정할지, 서버 요구 사항을 확인할지 판단할 수 있습니다.
Project V는 모듈형 네트워크 프록시 도구를 중심으로 하며, 설정에는 보통 인바운드·아웃바운드·라우팅·DNS 등이 포함됩니다. V2Fly는 V2Ray 관련 코어를 커뮤니티 중심으로 이어서 개발하고, Xray는 관련 코드 기반에서 독자적인 프로토콜 및 전송 기능을 발전시켰습니다. 두 계열은 공통된 배경이 있지만 설정도 각기 발전해 왔으므로 항상 같은 실행 프로그램이라고 볼 수 없습니다.
실제 선택은 서버 요구 사항부터 확인하세요. 프로토콜을 확인한 다음 전송 방식과 보안 계층을 살펴보고 마지막으로 코어 지원 여부를 점검해야 합니다. 예를 들어 VLESS·REALITY·Vision은 각각 서로 다른 설정 개념과 관련되어 있습니다. 이름 하나만 보고 연결 구성이 모두 호환된다고 판단해서는 안 됩니다. 클라이언트에 특정 옵션이 표시되어도 서버에서 해당 기능을 사용 중이라는 뜻은 아닙니다.
코어 이름은 속도 순위가 아닙니다. 연결 성능은 서버 회선, 대상 사이트, DNS 응답, 로컬 네트워크에도 영향을 받습니다. 문제가 생기면 작동하는 기존 구성을 보존하고 같은 조건에서 설정 변경을 비교하세요. 모든 구성 요소를 한꺼번에 바꾸는 것보다 신뢰할 만한 원인을 찾기 쉽습니다.
v2rayN은 데스크톱 설정 관리 인터페이스를 제공해 서버 정보·구독 그룹·라우팅 옵션을 정리하고, 연결 실행은 함께 사용하는 코어에 맡깁니다. v2rayNG는 Android용 Xray 코어 클라이언트이고, v2flyNG는 Android용 V2Fly 코어 클라이언트입니다. 세 클라이언트 모두 오픈 소스 프로젝트지만 인터페이스 기능, 코어 구성, 플랫폼 연동 방식은 서로 다릅니다.
데스크톱 인터페이스가 여러 플랫폼을 지원한다고 해서 시스템 권한이나 트래픽 처리 방식까지 모두 같은 것은 아닙니다. 운영체제마다 프록시 설정, 가상 네트워크 어댑터 권한, 패키지 형식이 다르므로 각각 확인해야 합니다. 설정을 옮길 때는 먼저 서버 매개변수나 구독 출처처럼 명확한 항목을 이전한 뒤 로컬 포트·파일 경로·시스템별 옵션을 점검하세요.
클라이언트는 서버 서비스가 아닙니다. 설치 후에도 유효한 정보를 가져와야 하며, 구독 유효 기간·서버 연결 상태·클라이언트 실행 상태를 각각 확인해야 합니다. 이 사이트에서는 클라이언트 설치와 설정을 중심으로 안내하며, 다운로드 경로와 입문 단계는 해당 페이지에서 확인할 수 있습니다.
오픈 소스는 라이선스 조건에 따라 소스 코드를 공개해 커뮤니티가 확인·연구하고 유지 관리에 참여할 수 있도록 한다는 뜻입니다. V2Fly 코어는 MIT 라이선스, Xray-core는 MPL 2.0 라이선스를 사용하며, 그래픽 클라이언트와 종속 구성 요소에는 각각 다른 라이선스 조건이 적용될 수 있습니다. 사용·수정·재배포 전에는 대상 프로젝트와 종속 구성 요소의 라이선스를 각각 확인해야 합니다. 생태계 이름 하나로 모든 라이선스 조건을 뭉뚱그릴 수는 없습니다.
오픈 소스 여부와 서버 서비스 요금은 별개의 문제입니다. 클라이언트는 무료로 사용할 수 있지만 외부 서비스의 요금, 연결 제한, 이용 기간은 서비스 제공자가 정합니다. 클라이언트 설치에 성공했다고 구독이 반드시 유효한 것은 아니며, 구독 서비스의 제한을 클라이언트 기능 제한으로 오해해서도 안 됩니다.
연결 정보는 민감한 설정입니다. 로그를 공유할 때는 구독 전체 주소·사용자 식별 정보·인증 내용을 삭제하고 오류 유형, 관련 설정 계층, 재현 절차만 남기세요. 설정 파일 전체를 공개하기보다 문제 상황을 명확히 설명하는 편이 원인을 찾는 데 도움이 됩니다.
인터페이스 업데이트, 코어 업데이트, 규칙 데이터 업데이트, 구독 업데이트는 서로 다른 작업입니다. 인터페이스 업데이트는 메뉴와 기본 동작을 바꿀 수 있고, 코어 업데이트는 프로토콜 구현과 필드 호환성에 영향을 줍니다. 규칙 데이터 업데이트는 도메인이나 주소 목록을 바꾸며, 구독 업데이트는 서버 정보를 다시 가져옵니다. 문제를 살펴볼 때는 먼저 최근에 변경된 계층이 무엇인지 확인하세요.
업데이트 전에 구독 그룹, 필요한 사용자 지정 규칙, 정상 작동하는 설정을 저장하세요. 업데이트 후에는 먼저 기존 기본 연결을 확인한 다음 새 기능을 활성화하세요. 자동 생성된 실행 설정은 재시작이나 저장 시 덮어써질 수 있으므로 장기간 유지할 규칙은 임시 생성 파일을 직접 수정하기보다 클라이언트의 영구 설정 기능으로 관리하는 것이 좋습니다.
설정을 관리할 때는 현재 사용하는 코어 계열, 프록시 트래픽 처리 방식, DNS 정책, 사용자 지정 아웃바운드 태그를 간단히 기록해 두세요. 연결 인증 정보는 기록하지 않아도 됩니다. 이런 메모만으로도 ‘설정이 덮어써짐’, ‘규칙이 매칭되지 않음’, ‘서버에 접속할 수 없음’을 구분하기 쉽고, 심화 가이드를 따라 단계별로 조정할 때도 편리합니다.
먼저 인바운드가 앱 요청을 어떻게 받는지 확인하고, 다음으로 라우팅이 아웃바운드를 선택하는 방식을 살펴본 뒤 아웃바운드의 프로토콜과 이름 해석 경로를 점검하세요. 예제를 읽을 때는 전체 설정과 일부 설정을 구분해야 합니다. 해당 아웃바운드 태그 없이 라우팅 규칙만 복사해도 실행 가능한 연결 설정이 되지는 않습니다.
프로토콜 및 고급 설정 보기 →CONFIGURATION NOTES
첫 연결을 완료한 뒤 실제로 겪은 문제에 맞춰 자세한 내용을 확인하세요. 프록시 모드, 데스크톱 인터페이스 차이, 서버 설정 선택은 각각 별도의 판단이 필요하므로 나누어 살펴보면 됩니다. 처음 설치할 때 모든 내용을 한꺼번에 익힐 필요는 없습니다.
시스템 프록시 설정과 라우팅 모드가 서로 다른 계층임을 설명하고, 전역 모드와 중국 본토 우회 모드의 분기 방식을 살펴봅니다. 모든 트래픽을 처리하기 위해 Tun 모드로 전환해야 하는 경우도 안내합니다.
“브라우저는 되는데 다른 앱은 달라진 게 없다”와 같은 문제를 해결하는 데 적합합니다. 먼저 트래픽이 클라이언트에 들어오는지 확인하고, 들어온 뒤 어떤 규칙과 매칭되는지 살펴보세요. 모드 이름만 반복해서 바꾸지 않아도 됩니다.
글 읽기 →두 가지 인터페이스 프레임워크로 만든 v2rayN의 데스크톱 운영체제별 호환성, 외관, 종속성 차이를 비교하고 시스템에 맞는 버전을 안내합니다.
다운로드 전에 설치 경로를 결정하는 데 도움이 됩니다. 인터페이스 프레임워크는 사용 경험과 플랫폼 지원 범위에 영향을 주지만 프로토콜을 뜻하지는 않습니다. 인터페이스를 선택한 뒤에도 함께 사용할 코어와 서버 요구 사항을 확인해야 합니다.
글 읽기 →클라이언트의 지연 시간 측정이 의미하는 바와 한계를 설명하고, 트래픽 배수를 계산하는 방법을 안내합니다. 용도에 따라 지역과 프로토콜을 선택하는 순서도 소개해 초보자의 시행착오를 줄입니다.
구독을 가져온 뒤 어떤 설정을 선택할지 고민될 때 유용합니다. 테스트 결과는 특정 조건에서만 유효하므로 한 가지 수치에 의존하지 말고 실제 대상 사이트, 연결 안정성, 서비스 안내를 함께 고려하세요.
글 읽기 →주제별 글은 특정 설정 선택을 설명하며, 연속된 조작 절차는 입문 가이드부터 확인하는 것이 좋습니다. 여러 구독 그룹, 사용자 지정 아웃바운드, 복잡한 이름 해석 정책을 관리해야 한다면 고급 설정 안내서로 넘어가 항목별로 검증한 뒤 저장하세요.
전체 글 보기 →