오픈 소스 클라이언트 설치 경로, 구독 가져오기, JSON 설정 참고 자료를 정리했습니다. 시스템 프록시부터 라우팅 규칙까지 트래픽 흐름에 따라 설명합니다.
먼저 운영체제를 확인한 다음 프로세서 아키텍처를 선택하세요. 데스크톱에서는 v2rayN, Android에서는 v2rayNG를 우선 살펴보세요. 기존 V2Fly 설정을 사용한다면 v2flyNG의 호환성도 비교해 볼 수 있습니다.
Windows용 v2rayN 데스크톱 버전은 크로스 플랫폼 인터페이스를 사용하며, WPF 버전은 클래식 데스크톱 환경을 유지합니다. 메뉴 위치는 다를 수 있지만 구독 가져오기, 서버 선택, 시스템 프록시 설정의 기본 순서는 같습니다. 처음 사용할 때는 한 가지 인터페이스를 정해 사용하세요. 두 인스턴스에서 포트와 시스템 프록시를 번갈아 변경하면 혼란이 생길 수 있습니다. 설치 전에 시스템 요구 사항을 확인하세요. 설정을 옮길 때는 기존 설정을 먼저 내보낸 뒤 새 인스턴스에서 사용하는 코어와 작업 디렉터리를 확인하세요.
macOS에서는 ‘이 Mac에 관하여’에서 칩 정보를 확인할 수 있습니다. Apple Silicon과 Intel은 설치 경로가 다릅니다. Linux에서는 배포판의 패키지 형식과 기기 아키텍처를 각각 확인해야 합니다. Debian·Ubuntu 계열은 보통 deb, Fedora 등은 대체로 rpm 패키지를 사용합니다. 패키지 형식과 프로세서 아키텍처는 별개의 조건이므로 파일 확장자만 보고 적합 여부를 판단하면 안 됩니다. 데스크톱 실행 방법과 의존성 처리는 플랫폼 설치 안내를 참고하세요.
Android용 v2rayNG는 Xray 코어를 사용하므로 Xray 필드 설명을 기준으로 연결 매개변수를 확인할 수 있습니다. v2flyNG는 V2Fly 코어를 사용하는 대안입니다. 대부분의 최신 기기는 arm64를 선택할 수 있으며, 아키텍처를 확인하기 어렵다면 범용 패키지 안내를 살펴보세요. 클라이언트 이름이 비슷해도 지원하는 전송 조합까지 같은 것은 아닙니다. 기존 설정을 가져오기 전에 프로토콜, 전송 계층, 보안 설정을 확인하세요. 특정 코어의 확장 필드를 모든 클라이언트가 인식하는 공통 필드로 간주하지 마세요.
설치가 끝났다는 것은 프로그램을 실행할 수 있다는 뜻일 뿐, 사용할 수 있는 원격 설정이 준비됐다는 의미는 아닙니다. 구독 주소, 서버 주소, 인증 정보는 직접 준비해야 합니다. 처음 설정을 가져온 뒤에는 목록에 유효한 항목이 표시되는지 확인하고 코어 로그를 살펴보세요. 프록시 클라이언트를 여러 개 동시에 실행하지 마세요. 목록이 비어 있다면 라우팅 규칙을 바로 수정하기보다 가져오기 형식이나 구독 응답에 문제가 있는지 먼저 확인하세요. 클라이언트별 차이는 세 가지 클라이언트 비교에서 확인할 수 있습니다.
트래픽 흐름에 따라 항목을 찾아보세요. 앱이 먼저 인바운드에 연결되고, 라우팅이 출구를 선택한 뒤, 아웃바운드가 연결을 완료합니다. 구독과 시스템 프록시는 클라이언트 관리 기능이며, JSON 루트 객체에 반드시 같은 이름의 필드가 있는 것은 아닙니다.
인바운드는 코어가 연결을 수신하는 방식을 정의합니다. 앱에서 SOCKS 프록시를 사용하려면 주소와 포트를 해당 인바운드에 지정해야 합니다. 코어만 실행한다고 모든 앱이 자동으로 이 진입점을 사용하지는 않습니다. 예시는 루프백 주소에서 수신하므로 로컬 기기에서만 접근할 수 있으며, tag로 출처를 표시해 이후 라우팅에서 참조할 수 있습니다. 연결이 거부되면 먼저 포트가 수신 중인지, 다른 프로세스가 사용 중인지 확인한 다음 앱에 입력한 프록시 유형을 살펴보세요. 클라이언트가 생성하는 포트는 다를 수 있으니 실제 설정을 기준으로 확인하고 예시 숫자를 그대로 사용하지 마세요.
{
"inbounds": [{
"tag": "socks-in",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": { "udp": true }
}]
}아웃바운드는 코어가 대상에 연결하는 방식을 정의합니다. 원격 프록시를 사용하거나 직접 연결하거나 차단할 수 있습니다. 라우팅의 outboundTag는 이미 선언된 tag와 일치해야 하며, 철자와 대소문자도 같아야 합니다. 예시에는 직접 연결과 차단만 있으며 원격 연결 매개변수는 포함되지 않으므로 완전한 프록시 설정을 대신할 수 없습니다. 문제를 확인할 때는 서버 주소, 인증 정보, 전송 계층, 보안 설정을 나누어 점검하세요. 그래픽 클라이언트는 보통 서버 항목을 바탕으로 원격 아웃바운드를 생성합니다. 원본 JSON을 수정하기 전에 설정을 저장할 때 수동으로 입력한 내용이 덮어써지는지 확인하세요.
{
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
},
{
"tag": "block",
"protocol": "blackhole",
"settings": {}
}
]
}라우팅은 코어에 들어온 트래픽을 아웃바운드로 전달합니다. 규칙은 위에서 아래로 검사하므로 조건이 지나치게 포괄적인 규칙을 앞에 두면 뒤의 세부 규칙이 적용되지 않을 수 있습니다. 예시에서는 사설 주소를 direct 아웃바운드로 보내며, 해당 아웃바운드 태그와 지리 데이터 파일이 필요합니다. domainStrategy는 라우팅에서 도메인 조회가 필요한 시점을 정하는 설정이지, 시스템 DNS 설정이 아닙니다. 규칙을 확인할 때는 앱 연결이 실제로 클라이언트에 들어왔는지 먼저 확인한 뒤 적용된 대상과 출구를 살펴보세요. 인바운드에 들어오지 않은 트래픽은 이 규칙의 영향을 받지 않습니다.
{
"routing": {
"domainStrategy": "AsIs",
"rules": [{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}]
}
}dns 항목은 코어에서 사용할 리졸버를 설정하지만 모든 앱의 DNS 경로를 자동으로 바꾸지는 않습니다. 브라우저의 암호화 DNS, 시스템 DNS 캐시, 앱이 직접 보내는 쿼리는 서로 다른 경로를 사용할 수 있습니다. 예시는 servers 배열 구조만 보여 주며 모든 네트워크 환경에 적합한 설정은 아닙니다. 도메인별 리졸버 규칙을 추가하려면 domains, expectIPs, 라우팅의 관계도 이해해야 합니다. 도메인 접속에 문제가 생기면 리졸버만 바꾸지 말고 조회 결과, 연결 대상, 실제 출구를 함께 비교해 잘못된 라우팅 조건이 있는지 확인하세요.
{
"dns": {
"servers": [
"1.1.1.1",
"8.8.8.8"
]
}
}구독 그룹은 클라이언트에서 관리하며 설정 출처와 업데이트 범위를 구분하는 데 사용됩니다. 일반적인 코어 JSON에 공통으로 적용되는 구독 필드는 아닙니다. 업데이트가 실패하면 주소가 유효한지, 응답이 지원되는 형식인지 먼저 확인한 뒤 기존 프록시를 거쳐 업데이트해야 하는지 살펴보세요. 구독을 업데이트하면 보통 서버 항목이 바뀌며, 모든 라우팅과 DNS 설정이 자동으로 수정되는 것은 아닙니다. 아래 JSON은 구독 설정이 아니라 가져온 뒤의 시작 상태를 확인할 때 참고하는 코어 로그 예시입니다. 로그나 스크린샷을 공유하기 전에 구독 주소와 인증 정보를 삭제하세요.
{
"log": {
"loglevel": "warning"
}
}시스템 프록시는 시스템 설정을 따르는 앱에 로컬 프록시 주소를 알리는 기능입니다. 코어의 라우팅 모드가 아니며 모든 프로그램의 트래픽을 처리한다고 보장하지도 않습니다. 클라이언트의 ‘시스템 프록시 설정’과 ‘시스템 프록시 해제’는 시스템 진입점에 영향을 주고, 분할 라우팅 규칙은 트래픽이 들어온 뒤의 경로를 결정합니다. 예시에는 HTTP 프록시 요청을 받을 수 있는 로컬 인바운드가 표시되어 있지만, 이 JSON만으로 시스템 설정을 바꿀 수는 없습니다. 브라우저에서는 접속되는데 다른 앱에서 실패한다면 서버를 바로 바꾸기보다 해당 앱이 시스템 프록시를 읽는지, 주소를 별도로 입력해야 하는지 확인하세요.
{
"inbounds": [{
"tag": "http-in",
"listen": "127.0.0.1",
"port": 10809,
"protocol": "http",
"settings": {}
}]
}이 예시들은 각 항목의 역할을 파악하기 위한 것이며, 그대로 이어 붙여 원격 서버에 연결할 수 있는 완성 설정은 아닙니다. 전체 파일에는 유효한 원격 아웃바운드와 서로 일치하는 태그, 현재 코어에 맞는 매개변수가 필요합니다. 같은 루트 항목은 하나의 객체나 배열에 합쳐야 하며 JSON 객체 여러 개를 그대로 이어 붙일 수 없습니다. 표준 JSON은 주석과 마지막 쉼표를 허용하지 않습니다. 편집기에서 보기 좋게 정리되어 있어도 코어가 해당 항목을 인식한다는 뜻은 아닙니다.
그래픽 클라이언트를 사용할 때는 먼저 해당 설정 화면에서 자주 쓰는 옵션을 바꾸고 생성 결과를 확인하세요. 실행 디렉터리의 설정 파일을 직접 편집하면 이번 실행에만 적용될 수 있으며, 다음에 서버를 바꾸거나 설정을 저장할 때 다시 생성될 수 있습니다. 사용자 지정 설정을 사용하려면 파일 관리 주체, 로드 시점, 오류 기록 위치를 먼저 확인하세요. 설정 참고 자료는 전체 구조, 인바운드, 아웃바운드, 라우팅, DNS, 정책 순으로 설명합니다. 첫 연결을 마친 뒤 더 자세히 살펴볼 때 유용합니다.
JSON 설정 참고 자료 열기먼저 최소한의 작동 설정을 만들고 분할 라우팅 조건을 하나씩 추가하세요. 연결에 영향을 주는 설정은 한 번에 하나씩만 바꾸고, 되돌릴 수 있도록 설정 사본을 보관하세요.
사용 가능한 구독 주소나 클라이언트가 지원하는 공유 링크를 준비하세요. v2rayN의 ‘구독 그룹 설정’에서 출처를 추가하고 저장한 뒤 구독을 업데이트합니다. 개별 공유 링크는 클립보드에서 가져올 수 있습니다. 메뉴 위치는 실제 인터페이스를 기준으로 확인하세요. 가져온 뒤 서버 목록이 비어 있거나 일반 웹페이지 내용이 표시되지 않는지 확인하세요.
v2rayNG에서는 추가 메뉴에서 클립보드 가져오기 또는 구독 관리를 선택할 수 있습니다. 설정에 입력하는 주소, 포트, 사용자 ID, 전송 매개변수는 모두 하나의 유효한 설정에서 가져와야 합니다. 여러 가이드에서 일부씩 가져와 조합하면 연결되지 않을 수 있습니다. 구독 주소에는 보통 접근 정보가 포함되므로 공개 스크린샷이나 문의 내용에 노출하지 마세요.
목록에서 사용할 서버를 선택하고 코어가 정상적으로 시작되는지 확인하세요. 데스크톱에서는 앱 요구 사항에 맞게 시스템 프록시를 설정하고, 라우팅은 우선 이해하기 쉬운 명확한 프리셋을 사용하세요. 시스템 프록시는 앱이 클라이언트에 들어오는 방식을 제어하고, 라우팅 모드는 들어온 뒤의 출구를 정합니다. 이름이 비슷해도 같은 설정으로 여기지 말고 각각 확인하세요.
Android에서 처음 연결할 때는 시스템의 VPN 권한 요청을 확인해야 합니다. 권한을 허용하면 클라이언트가 로컬 트래픽 진입점을 만들 수 있지만 원격 연결까지 성공했다는 뜻은 아닙니다. 기기에 다른 VPN 연결이 있다면 먼저 충돌을 해결하세요. 처음 연결을 확인하는 동안에는 복잡한 사용자 지정 규칙을 동시에 추가하지 않아야 문제 범위를 좁힐 수 있습니다.
실제로 사용할 앱에서 요청을 보내면서 클라이언트 로그를 확인하세요. 코어 시작 성공, 서버 연결 가능 여부, 특정 앱의 트래픽이 실제로 프록시를 통과하는지는 각각 별도의 확인 항목입니다. 로그에 해당 요청이 없다면 앱 진입점을 먼저 확인하세요. 요청은 표시되지만 연결이 실패한다면 서버 매개변수, DNS 조회 결과, 네트워크 연결 상태를 살펴보세요.
목록에 표시된 테스트 결과만으로 모든 앱이 정상이라고 판단하지 마세요. 요청에 따라 사용하는 프로토콜과 DNS 경로가 다를 수 있습니다. 기본 연결을 확인한 뒤 도메인 분할, 앱별 규칙, 자동 업데이트를 하나씩 활성화하세요. 테스트가 끝나 데스크톱 클라이언트를 종료할 때는 시스템 프록시가 해제됐는지 확인하세요. 그렇지 않으면 앱이 더 이상 수신하지 않는 로컬 포트에 계속 연결할 수 있습니다.
설정을 가져올 수 있는지 확인한 다음 코어가 시작되는지, 요청이 들어오는지, 대상에 연결되는지 순서대로 살펴보세요. 이 순서대로 확인하면 형식, 프로세스, 진입점, 원격 연결 문제를 구분할 수 있습니다. 예를 들어 ‘포트 사용 중’은 로컬 시작 문제이므로 구독 업데이트로 해결되지 않습니다. 인증서 오류는 시스템 시간, 서버 이름, 관련 보안 매개변수를 확인해야 하며 라우팅 문제로 단정할 수 없습니다. ‘사용할 수 없음’이라고만 설명하기보다 오류 원문을 보관하면 문제를 찾는 데 도움이 됩니다.
변경 후 새 문제가 생기면 마지막으로 정상 작동했던 설정을 복원한 뒤 변경 사항을 하나씩 다시 적용해 보세요. 로그에 서버 주소와 접속 기록이 포함될 수 있으므로 문의를 등록하기 전에 민감한 정보를 가리세요. 자주 발생하는 오류와 설정 범위는 자주 묻는 질문에서 확인할 수 있습니다. 익숙하지 않은 프로토콜, 코어, 전송 용어는 용어집을 먼저 살펴보세요. 클라이언트 인터페이스의 이름과 기반 프로토콜의 이름을 혼동하지 않는 것이 좋습니다.
프로젝트, 코어, 그래픽 클라이언트는 서로 다른 계층입니다. 필요한 프로토콜과 설정을 확인한 뒤 운영체제와 관리 방식을 기준으로 선택하세요.
Project V는 네트워크 통신을 위한 도구와 구성 요소를 개발하는 프로젝트이며, V2Ray는 그중 널리 쓰이는 코어 이름입니다. 코어는 연결을 수신하고 프로토콜을 해석하며 라우팅 규칙을 적용해 아웃바운드 연결을 만듭니다. 그래픽 클라이언트는 이러한 기능을 조작하기 쉬운 설정 화면으로 제공합니다. 일상적으로 말하는 ‘V2Ray 설치’는 실제로 코어를 관리하는 클라이언트를 설치한다는 뜻인 경우가 많습니다. 따라서 메뉴나 구독 작업에 문제가 생기면 V2Ray라는 포괄적인 이름만으로 버튼을 찾기보다 사용 중인 클라이언트부터 확인하세요.
이러한 계층 구조를 이해하면 같은 기술 문서라도 인터페이스별 안내가 필요한 이유를 알 수 있습니다. 코어 문서는 필드가 유효한지 다루고, 클라이언트 문서는 인터페이스에서 필드를 어떻게 생성하는지 다룹니다. 두 문서가 해결하는 문제는 다릅니다. 클라이언트 하나에서 코어를 선택하고 설정을 생성해 프로세스를 실행할 수 있지만, 그렇다고 서로 다른 코어의 기능이 모두 같아지는 것은 아닙니다. 이 사이트에서는 처음 설치하고 자주 쓰는 작업은 사용 가이드에, 원본 필드와 상호 의존성은 설정 참고 자료에 정리해 문제에 맞는 계층을 찾아볼 수 있도록 했습니다.
V2Fly는 V2Ray 커뮤니티에서 유지 관리하는 중요한 프로젝트이며, Xray는 관련 코드를 바탕으로 발전한 코어 분기입니다. 두 코어는 일부 역사와 설정 개념을 공유하지만 프로토콜 구현, 전송 기능, 필드 제약은 각자 발전해 왔습니다. JSON 예시를 읽을 때는 inbounds, outbounds, routing 같은 공통 구조로 각 항목의 역할을 파악한 다음, 구체적인 필드가 현재 코어에서 지원되는지 확인하세요. 루트 항목 이름이 같다고 내부 옵션까지 자유롭게 서로 바꿔 쓸 수 있는 것은 아닙니다.
코어 선택은 분기 이름에 대한 일반적인 성능 평가가 아니라 현재 설정의 요구 사항을 기준으로 해야 합니다. 서버에서 요구하는 프로토콜, 보안 계층, 전송 조합을 클라이언트 코어가 각각 지원해야 합니다. 하나라도 빠지면 인터페이스에서 항목을 저장할 수 있어도 연결되지 않습니다. 특정 분기의 확장 기능을 사용할 때는 해당 문서를 우선 확인하고 실제 실행 중인 코어 정보를 기록하세요. 호환성 문제가 생겼을 때 ‘필드를 인식하지 못함’과 ‘매개변수는 인식했지만 연결 실패’를 구분하면 불필요한 수정을 줄일 수 있습니다.
v2rayN은 Windows, macOS, Linux 데스크톱용 클라이언트로 서버 관리, 구독 그룹, 시스템 프록시, 라우팅 설정 기능을 제공합니다. 선택할 수 있는 코어는 클라이언트 기능에 따라 달라집니다. v2rayNG는 Android용 Xray 코어 클라이언트이며, v2flyNG는 Android용 V2Fly 코어 클라이언트입니다. 세 가지 모두 오픈 소스지만 그래픽 인터페이스, 권한 모델, 설정 저장 방식은 서로 다릅니다. 데스크톱 설정 스크린샷을 Android 메뉴의 기준으로 삼지 마세요. 설정을 옮길 때는 작업 디렉터리 전체를 복사하기보다 연결 매개변수를 확인하는 편이 좋습니다.
오픈 소스는 구현과 라이선스 조건을 검토할 수 있다는 뜻이지, 설정 검토를 대신하지 않습니다. 클라이언트 소프트웨어, 코어 프로그램, 실행 중 사용하는 데이터 파일은 각각 다른 오픈 소스 라이선스를 따를 수 있습니다. V2Fly의 v2ray-core는 MIT 라이선스를, Xray-core는 MPL-2.0 라이선스를 사용합니다. 클라이언트와 종속 항목의 재배포 조건도 해당 라이선스 원문을 각각 확인해야 합니다. 사용자는 오픈 소스라는 표시만으로 모든 구성 요소의 조건이 같다고 판단하기보다 출처, 기능 범위, 설정 호환성을 살펴봐야 합니다.
클라이언트 업데이트는 인터페이스와 설정 생성 방식에 영향을 줄 수 있고, 코어 업데이트는 프로토콜 구현과 필드 요구 사항을 바꿀 수 있습니다. 구독 업데이트는 주로 원격 서버 정보를 새로 고칩니다. 각 업데이트는 대상이 다르므로 ‘구독 업데이트 완료’를 프로그램 업데이트로 여기면 안 되며, 클라이언트 업데이트가 만료된 구독 주소를 자동으로 복구해 주지도 않습니다. 업데이트 전에 현재 설정을 기록하고 필요한 구성을 내보내세요. 업데이트 후에는 시작 로그, 코어 선택, 라우팅 데이터 로드를 확인하고 실제 앱에서 요청을 보내 검증하세요.
다운로드 페이지에서는 플랫폼별 다운로드 경로와 설치 안내를 제공하며, 홈페이지는 안정적인 사용 안내를 중심으로 구성하고 특정 클라이언트 버전을 고정해 표시하지 않습니다. 설정 문제를 다룰 때는 실제 설치한 클라이언트, 현재 실행 중인 코어, 서버 요구 사항을 함께 고려하세요. 문서의 JSON 예시는 구조를 설명하기 위한 것이며, 실행 환경의 기본값과 생성 방식, 지원 범위는 각각 확인해야 합니다. 이러한 차이를 이해하면 설치, 이전, 문제 해결을 명확한 대상을 기준으로 진행할 수 있고 여러 설정 화면을 오가며 무작정 바꿀 필요가 없습니다.
데스크톱 배포, 구독 관리, DNS 분할 설정을 위한 작업 내용을 정리했습니다. 기본 연결을 먼저 완료한 뒤 필요한 주제의 안내를 살펴보세요.
Ubuntu, Debian, Fedora 등에서 deb 또는 rpm 패키지로 v2rayN을 설치하고 의존성과 권한을 설정한 뒤, 데스크톱 자동 시작 항목을 사용해 로그인 후 자동으로 실행하는 방법을 안내합니다.
글 읽기 →구독 업데이트 실패의 주요 원인인 링크 만료, 업데이트 요청의 프록시 미사용, 인증서와 시간 불일치를 살펴보고 v2rayN 및 v2rayNG에서 자동 업데이트를 설정하는 방법을 안내합니다.
글 읽기 →dns 항목의 servers, domains, expectIPs 필드와 geosite 규칙을 함께 사용해 중국 본토와 해외 도메인을 서로 다른 DNS 서버로 조회하고 잘못된 DNS 응답을 줄이는 방법을 설명합니다.
글 읽기 →