01 / CLIENT SHELF
먼저 운영체제와 프로세서 아키텍처를 확인한 다음 설치 파일을 선택하세요. 데스크톱에서는 v2rayN을 사용하고, Android에서는 v2rayNG를 우선 살펴보세요. V2Fly 코어가 필요하다면 v2flyNG와 비교하면 됩니다. 설치 파일 선택과 연결 매개변수 확인은 별개의 과정입니다. 클라이언트를 설치한 뒤에도 사용할 수 있는 설정을 가져와야 합니다.
v2rayN / Desktop · WPF
데스크톱 버전은 크로스 플랫폼 인터페이스를 제공하며, WPF 버전은 기존 데스크톱 방식의 조작 환경을 유지합니다. 다운로드하기 전에 패키지 종류를 확인하세요. 두 다운로드 항목을 서로 다른 프로토콜로 오해해서는 안 됩니다. 이미 설정을 사용 중이라면 이전하기 전에 구독 그룹, 라우팅 설정, 로컬 수신 포트를 기록해 두세요.
처음 사용하는 경우 설정 하나를 가져오고 활성 서버를 선택한 뒤 시스템 프록시를 설정하세요. 브라우저는 연결되지만 다른 프로그램은 연결되지 않는다면 서버를 계속 바꾸기보다 해당 프로그램이 시스템 프록시를 사용하는지 먼저 확인하세요. 두 버전은 인터페이스 세부 사항이 다를 수 있으므로 현재 메뉴 이름을 기준으로 조작하세요.
다운로드 Windows 클라이언트v2rayN / Apple Silicon · Intel
시스템의 ‘이 Mac에 관하여’에서 칩 정보를 확인하세요. Apple Silicon과 Intel은 서로 다른 설치 파일을 사용하므로 파일 확장자만 보고 판단해서는 안 됩니다. 앱을 응용 프로그램 폴더로 옮긴 다음 시스템의 실행 확인 및 네트워크 권한 안내를 처리하세요. 임시 위치에서 앱을 반복 실행하지 않는 것이 좋습니다.
시스템 프록시와 트래픽 처리 권한을 각각 확인하세요. 업데이트 후 연결 동작이 달라졌다면 클라이언트에서 코어가 실행 중인지, 시스템 프록시가 현재 수신 포트를 가리키는지 차례로 살펴보세요. 개발자 관련 알림이 표시되면 시스템 설정의 보안 안내에 따라 처리하세요. 앱을 실행하기 위해 시스템 보안 기능을 통째로 끄는 것은 권장하지 않습니다.
다운로드 macOS 클라이언트v2rayNG / v2flyNG
v2rayNG는 주로 Xray 코어를 사용하며, v2flyNG에서는 V2Fly 코어를 선택할 수 있습니다. 두 앱은 이름이 비슷해도 지원하는 프로토콜 항목이 같다고 볼 수 없습니다. 선택하기 전에 설정에 REALITY, 특정 전송 방식 또는 코어별 매개변수가 포함되어 있는지 확인하세요.
기기 아키텍처에 맞춰 arm64 또는 범용 패키지를 선택하세요. 설치한 뒤 구독을 가져오고 시스템 VPN 권한을 승인해야 합니다. 이 권한은 앱이 기기의 트래픽을 처리하는 데 필요하며, 원격 서비스를 앱이 제공한다는 뜻은 아닙니다. 백그라운드로 전환한 뒤 연결이 끊긴다면 배터리 최적화, 백그라운드 활동 제한, 다른 VPN 앱과의 충돌을 확인하세요.
다운로드 Android 클라이언트v2rayN / deb · rpm
먼저 배포판의 패키지 관리 방식을 확인한 다음 x64와 arm64를 구분하세요. deb와 rpm은 설치 패키지 형식이지 연결 프로토콜이 아닙니다. 잘못 선택하면 일반적으로 라우팅이 아니라 설치 단계에서 문제가 발생합니다. 그래픽 환경의 프록시 설정은 데스크톱 환경에 영향을 받을 수 있으므로 모든 앱이 자동으로 설정을 가져온다고 가정하지 마세요.
설치 후 로컬 수신 포트와 코어 실행 상태를 확인한 다음 브라우저나 데스크톱의 시스템 프록시를 설정하세요. 터미널 프로그램은 별도로 프록시 매개변수를 지정해야 할 수 있습니다. 특정 프로그램만 실패한다면 해당 프로그램의 프록시 설정 위치부터 확인하세요. 더 넓은 범위의 트래픽을 처리해야 한다면 현재 클라이언트의 TUN 지원 여부와 권한 요구 사항을 살펴보세요.
다운로드 Linux 클라이언트02 / CONFIG INSPECTOR
클라이언트는 인터페이스 설정을 관리하고 코어는 연결과 라우팅을 실행합니다. 아래에서는 두 종류의 설정을 나누어 설명합니다. 구독 그룹은 클라이언트가 관리하는 데이터이며, 인바운드, 아웃바운드, 라우팅, DNS는 코어 설정에 흔히 포함되는 항목입니다. 코드는 일부 항목을 설명하기 위한 예시이며 전체 실행 설정을 그대로 덮어쓰면 안 됩니다.
구독은 여러 연결 설정을 한꺼번에 가져오는 데 사용하고, 그룹은 클라이언트에서 출처별로 구분하는 데 사용합니다. 먼저 그룹을 만든 뒤 구독 주소를 입력하고 업데이트하여 현재 클라이언트가 가져온 내용을 해석할 수 있는지 확인하세요. 업데이트 후에는 노드 이름, 프로토콜, 전송 항목을 살펴봐야 합니다. 목록에 항목이 나타나는지만 확인해서는 충분하지 않습니다. 그룹 이름과 자동 업데이트 주기는 클라이언트 설정이며 일반적인 코어 항목은 아닙니다. 아래는 가져오기 후 생성될 수 있는 아웃바운드 구조의 예시입니다. 원격 인증 정보가 없으므로 이 예시만으로 프록시 연결을 만들 수는 없습니다. 여러 출처를 정리하려면 필터 조건을 설정하고 원본 그룹은 보존하세요.
{
"outbounds": [
{ "tag": "direct", "protocol": "freedom" },
{ "tag": "block", "protocol": "blackhole" }
]
}라우팅은 규칙 순서에 따라 트래픽을 어느 아웃바운드로 보낼지 결정하며, 일반적으로 먼저 일치하는 규칙이 적용됩니다. 먼저 사설 주소를 처리하고 명확한 도메인 또는 주소 규칙을 추가한 뒤, 어떤 규칙에도 일치하지 않는 트래픽의 기본 경로를 확인하세요. 규칙의 아웃바운드 태그는 아웃바운드 목록의 태그와 정확히 일치해야 합니다. 그렇지 않으면 규칙이 있어도 예상대로 작동하지 않습니다. 아래 예시는 사설 주소를 직접 연결 아웃바운드로 보내며, 해당하는 지리 데이터 파일이 필요합니다. 전역 모드만 전환하는 것과 달리 규칙 기반 라우팅은 로컬 네트워크 접근 경로를 유지할 수 있지만, 도메인 해석 시점과 규칙 적용 범위도 확인해야 합니다.
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
]
}
}코어는 클라이언트 이름만 보고 선택하지 말고 연결 매개변수를 기준으로 선택하세요. 프로토콜, 전송 방식, 보안 계층을 확인한 뒤 현재 코어가 해당 항목을 지원하는지 살펴보세요. 특정 확장 기능이 포함된 경우 다른 코어가 같은 설정을 그대로 읽을 수 있다고 가정해서는 안 됩니다. 전환하기 전에 기존 설정을 보관하고, 전환 후에는 시작 로그와 생성된 설정을 확인해 실제로 어떤 코어가 실행되는지 점검하세요. 아래의 로그 수준은 초기 문제 해결에 사용할 수 있습니다. 자세한 로그가 필요해 일시적으로 수준을 높였다면 확인 후 원래대로 되돌리세요. 실행 로그에는 주소와 연결 정보가 포함될 수 있으므로 공유하기 전에 민감한 내용을 삭제해야 합니다.
{
"log": {
"loglevel": "warning"
}
}시스템 프록시는 해당 설정을 사용하는 앱에만 영향을 주며 전체 트래픽 처리와 같지 않습니다. 먼저 로컬 프록시 인바운드로 연결을 확인한 뒤 TUN이 필요한지 검토하세요. TUN 지원 여부는 클라이언트, 관련 구성 요소, 코어, 시스템 권한에 따라 달라집니다. 임의의 설정에 스위치 하나를 추가한다고 사용할 수 있는 기능이 아닙니다. 아래는 로컬에서만 수신하는 SOCKS 인바운드 예시로, 앱에 프록시 주소를 직접 입력해 사용할 수 있습니다. TUN 설정은 아닙니다. 모드를 전환할 때 다른 프록시 프로그램, 가상 네트워크 어댑터, DNS 설정을 확인해 트래픽이 중복 처리되어 순환하지 않도록 하세요.
{
"inbounds": [
{
"tag": "local-socks",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": { "auth": "noauth", "udp": true }
}
]
}DNS 설정은 앱, 시스템, 코어의 세 계층을 함께 확인해야 합니다. 클라이언트에 리졸버를 입력했다고 해서 모든 앱의 조회 요청이 코어를 거치는 것은 아닙니다. 도메인을 어느 단계에서 해석하는지 확인하고, 리졸버에 접근하는 경로가 아직 연결되지 않은 프록시에 의존하는지도 살펴보세요. 아래는 로컬 환경에서 이름을 해석하는 기본적인 예시입니다. 항목의 위치를 설명하기 위한 것으로 모든 네트워크에 적합하다는 뜻은 아닙니다. IP 주소로는 접속되지만 도메인으로는 실패한다면 리졸버만 바꾸기 전에 해석 결과와 라우팅 정책을 비교하고 조회 트래픽이 코어에 전달되지 않는 문제인지 확인하세요.
{
"dns": {
"servers": ["localhost"]
},
"routing": {
"domainStrategy": "AsIs"
}
}로컬 네트워크 공유를 사용하려면 수신 주소, 시스템 방화벽, 다른 기기의 프록시 설정이 모두 올바르게 구성되어야 합니다. 루프백 주소에서만 수신하면 다른 기기에서는 연결할 수 없습니다. 모든 인터페이스에서 수신하도록 열었다면 접근 가능한 출처도 제한해야 합니다. 아래는 인증을 사용하는 HTTP 인바운드의 일부 예시이며, 자격 증명은 설명용 값이므로 실제 사용 전에 반드시 바꾸세요. 다른 기기에는 루프백 주소가 아닌 컴퓨터의 로컬 네트워크 주소를 입력해야 합니다. 신뢰할 수 있는 네트워크에서만 공유하고 프록시 포트를 공용 인터넷에 노출하지 마세요. 공유가 끝나면 수신을 중지하거나 로컬 기기에서만 접근하도록 되돌리세요.
{
"inbounds": [
{
"tag": "lan-http",
"listen": "0.0.0.0",
"port": 10809,
"protocol": "http",
"settings": {
"accounts": [
{ "user": "example-user", "pass": "your-password" }
]
}
}
]
}03 / OPEN-SOURCE ECOSYSTEM
클라이언트, 코어, 프로토콜, 원격 서비스는 서로 다른 계층입니다. 각 요소의 역할을 이해하면 같은 구독이 앱마다 다르게 작동하는 이유를 파악하는 데 도움이 됩니다. 권한, 이름 해석, 서버 매개변수 문제를 한데 섞어 점검하는 일도 줄일 수 있습니다.
ORIGIN / PROJECT V
Project V는 V2Ray 생태계를 이해하는 출발점입니다. V2Ray는 인바운드, 아웃바운드, 전송, 라우팅, 도메인 이름 해석을 중심으로 프록시 기능을 구성하며, 설정 파일에서 각 모듈을 연결합니다. 일상적인 검색에서 ‘V2Ray 클라이언트’는 보통 이러한 기능을 관리하는 그래픽 앱을 뜻하며, 항상 특정 코어 하나만을 가리키는 것은 아닙니다. 클라이언트를 다운로드하기 전에 관리 인터페이스를 선택하는 것인지 연결을 실행하는 프로그램을 선택하는 것인지 구분하세요.
V2Fly는 V2Ray의 커뮤니티 개발 흐름을 이어가고 있으며, Xray는 별도의 코어 분기로 발전해 자체 프로토콜과 전송 확장 기능을 갖추었습니다. 두 코어는 공통된 배경이 있고 기본 설정 개념이 비슷한 경우도 있지만, 모든 항목이 호환된다고 볼 수는 없습니다. 설명을 비교할 때는 항목 이름뿐 아니라 예시가 어느 코어에 해당하는지, 클라이언트가 실제로 어떤 코어를 사용하는지도 확인하세요.
CLIENT / THREE APPLICATIONS
v2rayN은 데스크톱용 클라이언트로 구독 관리, 서버 선택, 라우팅 편집, 로컬 프록시 설정 등을 담당합니다. 크로스 플랫폼 인터페이스 덕분에 데스크톱에서 비슷한 방식으로 조작할 수 있지만 운영체제 권한, 설치 방법, 시스템 프록시 작동 방식에는 차이가 있습니다. 기기를 옮길 때는 필요한 설정부터 이전한 다음 수신 포트와 트래픽 처리 모드를 확인하세요. 다른 기기의 환경 설정을 통째로 적용해서는 안 됩니다.
v2rayNG와 v2flyNG는 Android용 클라이언트로, 각각 주로 Xray와 V2Fly 코어를 사용합니다. 둘 다 오픈 소스 클라이언트이며 주요 차이는 코어 기능, 인식 가능한 설정 항목, 앱 설정을 기준으로 살펴봐야 합니다. 구독 주소를 가져올 수 있다고 해서 모든 연결이 작동하는 것은 아닙니다. 구독을 읽은 뒤에도 프로토콜, 보안 계층, 전송 매개변수, 시스템 권한을 확인해야 합니다. 데스크톱과 휴대폰에서 같은 구독을 사용하더라도 각각 따로 테스트하세요.
LICENSE / SOURCE CODE
V2Fly 코어는 MIT 라이선스를, Xray-core는 MPL-2.0 라이선스를 사용합니다. 클라이언트와 코어, 함께 제공되는 구성 요소에 적용되는 라이선스는 각각 확인해야 합니다. 오픈 소스 라이선스는 코드를 사용하고 배포할 때의 조건을 설명할 뿐, 원격 서비스의 요금이나 모든 네트워크 환경에서의 성능을 보장하지 않습니다. 클라이언트는 무료로 사용할 수 있으며 연결에 필요한 서버와 구독은 사용자가 직접 준비해야 합니다.
오픈 소스 생태계의 장점은 구현 방식을 논의하고 검토하며 개선할 수 있다는 데 있습니다. 문제도 구체적인 모듈을 중심으로 살펴볼 수 있습니다. 하지만 코드가 공개되어 있다고 해서 설정의 출처, 네트워크 권한, 데이터 처리 경로를 판단할 책임까지 없어지는 것은 아닙니다. 설정을 가져오기 전에 서버 제공자가 누구인지 확인하세요. 문제 정보를 공유할 때는 구독 주소, 식별 정보, 인증 매개변수를 삭제하고 재현에 필요한 설정 구조만 남기세요.
UPDATE / COMPATIBILITY
클라이언트 업데이트, 코어 업데이트, 구독 업데이트는 각각 서로 다른 내용을 변경합니다. 클라이언트 업데이트는 인터페이스, 설정 생성 방식, 시스템 연동에 영향을 줄 수 있습니다. 코어 업데이트는 프로토콜 지원이나 설정 항목 처리에 변화를 줄 수 있으며, 구독 업데이트는 주로 원격 연결 정보를 바꿉니다. 문제가 생기면 먼저 어느 계층에서 변경이 있었는지 기록한 뒤 로그 확인, 설정 복원, 구독 재가져오기 중 적절한 조치를 선택하세요. 여러 작업을 한꺼번에 실행하면 원인을 파악하기 어려워집니다.
업데이트 전에 복원할 수 있도록 클라이언트 설정과 사용자 지정 규칙을 보관하고, 업데이트 후에는 기존에 작동하던 연결 하나부터 테스트하세요. 기본 연결이 정상이라면 라우팅, 도메인 이름 해석, 로컬 네트워크 공유를 차례로 확인합니다. 화면에 ‘실행 중’이라고 표시되는 것만으로 정상 여부를 판단하지 마세요. 코어가 시작되었다는 것은 프로세스가 동작한다는 뜻일 뿐입니다. 요청이 예상한 아웃바운드로 전달되는지는 앱의 프록시 설정과 로그의 라우팅 결과를 함께 확인해야 합니다.
READING / CONFIGURATION PATH
처음 설정할 때는 정해진 순서대로 진행하는 것이 좋습니다. 먼저 원격 주소, 포트, 인증 매개변수를 확인하고 프로토콜, 전송 방식, 보안 계층을 점검하세요. 그런 다음 로컬 인바운드를 시작하고 연결 하나를 선택해 테스트합니다. 기본 연결이 작동한 뒤에 복잡한 라우팅을 추가하세요. 이 순서를 따르면 연결 자체의 실패와 요청이 잘못된 아웃바운드로 전달되는 문제를 구분할 수 있으며, 잘못된 DNS 결과를 프로토콜 비호환으로 오해하는 일도 줄어듭니다.
JSON을 읽을 때는 먼저 인바운드와 아웃바운드의 태그를 찾고 라우팅 규칙에서 서로 어떻게 연결되는지 확인하세요. 규칙에 사용된 도메인 및 주소 목록은 외부 데이터 파일에 의존할 수 있습니다. 파일이 없는 문제와 규칙 작성 오류는 서로 다른 원인입니다. 항목별로 비교하려면 전체 설정 가이드를 확인하세요. 처음 가져오기와 연결만 완료하려면 빠른 시작을 따라 하면 됩니다. 고급 기능을 처음부터 모두 활성화할 필요는 없습니다.
04 / FIELD NOTES
사용 상황에 맞는 안내를 확인하세요. 수정하기 전에 현재 문제가 수신 설정, 권한, 설정 파일 생성, 원격 연결 중 어느 단계에 해당하는지 파악한 다음 관련 문서로 이동하세요. 문서의 일부 설정 예시는 항목 간 관계를 설명하기 위한 것이며, 실제 매개변수는 사용하는 환경에 맞춰야 합니다.
로컬 네트워크 연결을 허용한 뒤 수신 주소와 포트를 확인하고 시스템 방화벽에서 허용하세요. 그런 다음 다른 기기에 HTTP 또는 SOCKS 프록시를 설정하면 같은 네트워크에서 공유할 수 있습니다.
로컬 네트워크 공유 설정 읽기 →코어 시작 로그의 오류를 읽고 JSON 문법 오류, 포트 사용 중, 알 수 없는 프로토콜 항목, geo 파일 누락 등 자주 발생하는 원인을 유형별로 찾아보세요.
코어 시작 오류 해결 방법 읽기 →여러 구독을 가져올 때 출처별 그룹을 만들고 키워드로 노드를 필터링하는 방법, 자동 업데이트 간격을 설정해 노드 목록을 깔끔하게 관리하는 방법을 알아보세요.
구독 그룹 관리 방법 읽기 →