Xray · V2Fly 코어 / 데스크톱·모바일 4개 플랫폼
운영체제에 맞는 오픈 소스 클라이언트를 선택하고, 구독 가져오기부터 config.json 항목 레퍼런스까지 확인하세요. 로컬 포트, 아웃바운드 프로토콜, 라우팅 규칙을 하나씩 점검할 수 있습니다.
설정 작업대는 일부 항목만 추린 예시입니다. 인증 정보, 서버 포트, 직접 연결 아웃바운드 정의가 생략되어 있어 완전한 설정으로 실행할 수 없습니다.
CONFIGURATION / 설정 항목 색인
클라이언트 UI는 설정을 생성하고, 코어는 설정에 따라 연결을 처리합니다. 트래픽 유입, 아웃바운드 선택, 도메인 조회가 각각 어디서 처리되는지 먼저 파악한 뒤 해당 항목을 수정하세요. 모든 매개변수를 한꺼번에 펼쳐 볼 필요는 없습니다.
{
"inbounds": [{
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": { "udp": true }
}]
}인바운드는 애플리케이션의 연결을 코어로 전달하는 방식을 정의합니다. 로컬에서만 사용할 경우 수신 주소는 보통 루프백 주소로 설정하며, 포트는 브라우저나 호출 프로그램의 설정과 일치해야 합니다. 예시는 SOCKS 인바운드이므로 이 포트를 HTTP 프록시 포트로 사용할 수 없습니다. 시작에 실패하면 먼저 포트가 사용 중인지 확인한 다음, 클라이언트가 같은 이름의 인바운드를 생성했는지 살펴보세요. 시스템 프록시 스위치만 확인하는 것보다 인바운드를 점검하면 애플리케이션이 트래픽을 보내지 않는 경우와 코어가 수신 대기에 실패한 경우를 구분할 수 있습니다. 수신 범위를 변경하기 전에는 어떤 기기가 이 연결 지점에 접근할 수 있는지도 확인해야 합니다.
설정 레퍼런스에서 보기 →{
"outbounds": [{
"tag": "direct",
"protocol": "freedom",
"settings": {}
}]
}아웃바운드는 연결이 코어를 빠져나가는 방식을 정의합니다. 프록시 아웃바운드에는 서버 주소·포트·인증 정보가 필요하고, 직접 연결 아웃바운드에는 freedom을 사용할 수 있습니다. VLESS 같은 프로토콜 이름만으로는 노드 설정을 모두 알 수 없으므로 전송 방식과 TLS 또는 REALITY 관련 매개변수도 확인해야 합니다. 라우팅은 tag를 통해 아웃바운드를 참조하므로 이름이 정확히 일치해야 합니다. 노드를 다시 가져오기보다 프로토콜·전송 방식·보안 계층을 차례로 확인하면 누락된 항목을 더 쉽게 찾을 수 있습니다. 예시에는 직접 연결 아웃바운드만 표시되어 있습니다. 실제 프록시 프로토콜을 사용할 때는 서버에서 제공한 매개변수와 선택한 코어의 지원 범위를 기준으로 설정하세요.
설정 레퍼런스에서 보기 →{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}]
}
}라우팅 규칙은 위에서 아래로 적용되며, 규칙이 일치하면 지정된 아웃바운드를 선택합니다. 범위가 넓은 규칙보다 구체적인 예외를 앞에 두고, outboundTag가 아웃바운드에 정의되어 있는지 확인하세요. domainStrategy는 라우팅 매칭 중 도메인 조회를 시도하는 시점을 결정하며, 시스템 DNS 설정과는 다릅니다. 예시에서는 사설 주소를 direct로 전달합니다. 지리 정보 규칙을 사용하려면 해당 데이터 파일을 사용할 수 있는지도 확인해야 합니다. 전역 모드를 바꾸는 대신 명시적인 규칙을 쓰면 로컬 네트워크 접근을 유지하면서 특정 도메인에 별도의 경로를 지정할 수 있습니다. 문제를 찾을 때는 규칙 수를 줄인 뒤 하나씩 다시 추가하세요.
설정 레퍼런스에서 보기 →{
"dns": {
"servers": ["localhost"]
}
}DNS 설정은 코어가 도메인을 조회할 때 사용할 리졸버에 영향을 주지만, 기기의 모든 애플리케이션 요청을 자동으로 처리하지는 않습니다. 예시의 localhost는 본 기기의 조회 방식을 사용한다는 뜻이지, 공개 DNS 주소를 직접 입력한다는 뜻이 아닙니다. 설정 전에는 애플리케이션 자체 조회, 시스템 조회, 코어 조회의 세 경로를 구분한 뒤 라우팅 정책과 함께 실제 요청이 어느 계층에서 처리되는지 확인하세요. 리졸버 주소만 바꾸는 것보다 조회 요청이 어디로 전달되는지 살펴보는 편이 문제를 찾는 데 도움이 됩니다. 클라이언트에 DNS 라우팅이나 조회 정책 옵션이 있다면 현재 코어에서 해당 설정이 의미하는 바도 확인해야 합니다.
설정 레퍼런스에서 보기 →클라이언트 구독 그룹
메모 일상 설정
자동 업데이트 필요할 때 사용
업데이트 후 선택한 노드 확인
내보내기 전 구독 주소와 인증 정보 삭제구독 주소는 클라이언트가 읽어 노드를 일괄 업데이트하는 데 사용하며, config.json의 공통 최상위 항목은 아닙니다. 용도별 그룹을 만들고 알아보기 쉬운 메모를 남겨 가져오세요. 업데이트 후에는 기존에 선택한 노드가 남아 있는지, 수동으로 변경한 매개변수가 다시 생성되었는지 확인해야 합니다. 구독은 공유 링크를 하나씩 복사하는 것보다 관리하기 편리하지만, 클라이언트마다 구독 형식과 확장 매개변수 지원 여부가 다를 수 있습니다. 스크린샷·설정 파일·문제 해결 로그를 공유하기 전에는 구독 주소와 인증 정보를 삭제하세요. 기기를 옮길 때는 노드 정보와 해당 기기 전용 설정을 구분하는 것이 좋습니다.
설정 레퍼런스에서 보기 →DOWNLOADS / 플랫폼별 다운로드
데스크톱에서는 v2rayN을 사용하고, Android에서는 먼저 v2rayNG를 확인하세요. V2Fly 코어가 필요하다면 v2flyNG도 비교해 볼 수 있습니다. 설치 경로와 설정 문서를 분리해 두어 시스템 아키텍처를 먼저 확인한 뒤 가이드로 돌아와 설정을 마칠 수 있습니다.
데스크톱 버전은 크로스 플랫폼 UI를 제공하며, WPF 버전은 익숙한 클래식 데스크톱 조작 방식을 유지합니다. 먼저 사용 습관에 맞는 UI를 선택한 뒤 설치 요구 사항을 확인하세요. 기존 설정이 있다면 구독 그룹, 사용자 지정 라우팅, 로컬 포트를 먼저 백업해야 합니다. 프로그램 폴더 전체를 다른 UI 버전 위에 그대로 덮어쓰는 것은 피하세요.
처음 실행한 뒤에는 설정에서 로컬 수신 포트를 확인하고 시스템 프록시를 사용할지 결정하세요. 프로그램이 정상적으로 열려도 코어가 실행 중이라는 뜻은 아닙니다. 실행 환경 관련 안내가 표시되면 설치 페이지의 설명에 따라 필요한 구성 요소를 설치한 다음 노드를 가져오세요.
‘이 Mac에 관하여’에서 칩 정보를 확인하고 해당 아키텍처에 맞는 설치 경로를 선택하세요. 시스템 프록시 설정과 클라이언트 라우팅은 서로 다른 계층입니다. 시스템 프록시는 애플리케이션이 연결을 클라이언트에 전달할지 결정하고, 라우팅은 전달된 연결에 어떤 아웃바운드를 사용할지 정합니다.
처음 실행할 때 시스템 안내 창의 설명을 확인하고, 문제를 찾겠다며 여러 권한을 동시에 변경하지 마세요. 브라우저에서는 접속되지만 다른 애플리케이션은 여전히 기존 경로로 연결된다면 해당 앱이 시스템 프록시를 따르는지, 별도의 네트워크 옵션을 설정했는지 확인하세요.
먼저 v2rayNG의 arm64 및 범용 버전 다운로드 경로를 확인하세요. 기기 아키텍처를 모른다면 시스템 정보를 참고해 선택하면 됩니다. v2flyNG는 다른 코어 계열을 사용하는 대안입니다. 기존 노드에 적합한지는 앱 이름만 비교하지 말고 프로토콜과 확장 매개변수를 기준으로 판단하세요.
연결할 때 시스템의 VPN 연결 권한을 확인해야 합니다. 앱별 트래픽 분할, 백그라운드 실행 제한, 배터리 관리가 모두 사용 결과에 영향을 줄 수 있습니다. 앱을 켜 둔 동안에는 연결되지만 화면을 잠그면 끊긴다면 같은 구독을 반복해서 가져오기 전에 시스템의 백그라운드 활동 제한부터 확인하세요.
배포판의 패키지 형식에 따라 deb 또는 rpm을 선택한 다음 x64와 arm64를 구분하세요. 데스크톱 환경마다 시스템 프록시 지원이 다를 수 있습니다. 설치 후에는 코어 실행 상태, 데스크톱 프록시 설정, 대상 애플리케이션의 네트워크 설정을 각각 확인하세요.
로컬 포트 충돌, 권한 부족, 종속성 누락은 서로 다른 문제이므로 로그의 구체적인 오류에 따라 처리해야 합니다. GUI 클라이언트와 다른 프록시 프로그램을 함께 실행한다면 먼저 대상 포트를 어느 프로그램이 수신 중인지 확인하세요. 다른 프로그램의 응답을 현재 설정이 적용된 것으로 착각하지 않도록 주의해야 합니다.
QUICKSTART / 설정 순서
첫 설정에서는 원인을 설명할 수 있는 연결 경로 하나만 구성하세요. 먼저 가져오기를 마치고, 트래픽 처리 방식을 선택한 다음 결과를 확인하면 됩니다. 한 번에 변수 하나만 바꾸는 편이 고급 옵션을 여러 개 동시에 켜는 것보다 문제를 찾기 쉽습니다.
01 / 가져오기
클라이언트의 구독 관리 메뉴에서 구독 주소를 추가하고, 그룹을 알아볼 수 있는 메모를 입력한 뒤 업데이트하세요. 공유 링크가 하나만 있다면 클립보드나 QR 코드로 가져올 수 있습니다. 두 방법은 관리 범위가 다릅니다. 구독 업데이트는 그룹 내용을 다시 가져오지만, 개별 공유 링크는 보통 로컬 항목 하나만 만듭니다.
가져오기가 끝나면 먼저 노드 편집 화면을 열어 프로토콜, 서버 주소, 포트, 전송 설정을 확인하세요. 구독 이름은 연결 매개변수가 아니며, 노드 표시 이름만으로 설정이 완전하다고 볼 수 없습니다. 형식을 인식할 수 없다는 메시지가 나오면 복사한 내용에 불필요한 공백·설명·웹 주소가 포함되지 않았는지 확인한 뒤 클라이언트의 형식 지원 여부를 살펴보세요.
구독 주소에는 접속 자격 증명이 포함될 수 있으므로 공개 스크린샷이나 게시판에 올리지 마세요. 문제 해결에 필요한 경우 프로토콜 종류와 오류 메시지만 기록하고 인증 정보는 비공개로 유지하세요. 업데이트 실패와 노드 연결 실패는 서로 다른 단계의 문제입니다. 구독을 가져오지 못했다면 아웃바운드 프로토콜을 바꾸기보다 먼저 구독을 가져오는 과정을 확인해야 합니다.
02 / 트래픽 전달
노드를 선택한 뒤 트래픽을 클라이언트로 전달할 방식을 설정하세요. 데스크톱에서는 시스템 프록시부터 사용해 보고, Android에서는 화면 안내에 따라 VPN 연결 권한을 확인할 수 있습니다. 시스템 프록시는 해당 설정을 따르는 애플리케이션에만 영향을 줍니다. 라우팅 모드는 코어에 이미 전달된 연결에 적용되므로 두 설정은 서로 대체할 수 없습니다.
처음에는 클라이언트의 기본 라우팅 설정을 유지하고 로컬 네트워크 리소스가 계속 작동하는지 확인한 뒤 특정 도메인 규칙을 추가하세요. 앱 하나를 연결하려고 로컬 네트워크 수신을 곧바로 허용하거나, 모든 라우팅 문제를 노드 탓으로 돌리지 마세요. 먼저 애플리케이션의 요청이 클라이언트로 전달되는지 확인하면 점검 범위를 좁힐 수 있습니다.
로컬 포트를 변경해야 한다면 해당 포트를 사용하는 애플리케이션 설정도 함께 수정하세요. HTTP와 SOCKS는 서로 다른 프록시 인터페이스이므로 수신 주소가 같더라도 임의로 바꿔 쓸 수 없습니다. 클라이언트에 혼합 포트 옵션이 있다면 해당 옵션의 실제 설명을 따르고, 다른 기기의 포트 번호를 그대로 복사하지 마세요.
03 / 연결 확인
연결을 시작한 다음 먼저 코어가 정상적으로 실행되는지 확인하고 대상 애플리케이션에서 요청을 보내세요. 노드 테스트 결과는 특정 테스트 방식만 반영하므로 실제 앱에서의 연결 확인을 대신할 수 없습니다. ‘코어 시작 성공’, ‘앱 요청 전달’, ‘예상 아웃바운드 규칙 매칭’, ‘원격 연결 완료’를 각각 나누어 판단하세요.
인증서 관련 오류라면 시스템 시간, 서버 이름, 전송 보안 매개변수를 확인하고, 주소가 사용 중이라는 메시지가 나오면 로컬 포트 설정으로 돌아가세요. 문제를 해결할 때는 기존 매개변수를 백업하고 변경 내용과 그에 따른 증상을 기록하세요. 그래야 설정을 복구할 명확한 근거가 생기며 여러 차례 시도하는 동안 원래 설정을 잃지 않습니다.
연결 동작을 확인한 뒤 자동 업데이트, 시작 시 실행, 앱별 트래픽 분할을 검토하세요. 네트워크 전환, 기기 재시작, 화면 잠금 해제 후에도 같은 방법으로 다시 확인할 수 있습니다. 특정 앱에서만 문제가 생긴다면 전역 설정을 수정하기 전에 앱 자체의 DNS 및 프록시 설정부터 확인하세요.
PROJECT V / 코어와 클라이언트
V2Ray·V2Fly·Xray와 GUI 클라이언트는 같은 계층의 소프트웨어가 아닙니다. 각 이름이 가리키는 대상을 구분하면 기능을 제공하는 구성 요소와 오류가 발생한 위치를 파악하고, 설정을 옮길 때 필요한 내용을 판단하기 쉬워집니다.
Project V는 네트워크 프록시 구성 요소를 중심으로 형성된 오픈 소스 생태계이며, V2Ray는 널리 사용되는 핵심 구현 중 하나입니다. V2Fly는 V2Ray의 커뮤니티 개발을 이어가고, Xray는 관련 코드 기반에서 자체적인 코어 개발 방향을 발전시켜 왔습니다. 두 코어는 일부 설정 개념을 공유하지만 프로토콜 확장, 항목 지원, 기본 동작은 각각의 발전에 따라 달라질 수 있습니다. 이를 모두 같은 코어로 보면 설정을 가져오거나 문서를 확인할 때 적용 범위를 놓치기 쉽습니다.
코어는 프로토콜 처리, 전송 연결, 라우팅 매칭, 도메인 조회 등을 담당하고, GUI 클라이언트는 이 기능을 노드 목록·구독 그룹·설정 화면으로 구성합니다. 화면에 특정 옵션이 있다고 해서 모든 코어가 그 옵션을 같은 방식으로 해석하는 것은 아닙니다. 호환성 문제를 확인할 때는 공유 링크 앞부분만 보고 전체 설정을 판단하지 말고 현재 클라이언트와 사용 중인 코어를 먼저 기록한 뒤 해당 항목의 설명을 확인하세요.
v2rayN은 데스크톱용 오픈 소스 GUI 클라이언트로, 노드 가져오기, 구독 업데이트, 라우팅 관리, 시스템 프록시 설정을 지원합니다. 자주 사용하는 설정을 UI에서 관리하면서 사용자 지정 설정도 활용할 수 있습니다. 코어를 바꾸거나 노드 유형을 변경한 뒤에는 생성된 전송 및 보안 계층 매개변수를 다시 확인하세요. 노드 항목이 저장되어 있다고 해서 원격 서버가 해당 기능을 지원한다는 뜻은 아닙니다.
v2rayNG는 Xray 코어를 사용하는 Android용 오픈 소스 클라이언트입니다. v2flyNG는 V2Fly 코어를 사용하며, 다른 호환 경로를 위한 대안입니다. 두 앱의 UI 조작 방식이 비슷해도 모든 확장 항목을 서로 바꿔 쓸 수 있다고 볼 수는 없습니다. 선택할 때는 기존 설정의 요구 사항, 구독 형식, 앱별 트래픽 분할, 백그라운드 실행 경험을 함께 살펴보세요. 데스크톱과 모바일에서 같은 구독을 사용하더라도 로컬 수신 및 시스템 트래픽 처리 설정은 기기별로 따로 관리해야 합니다.
V2Fly 코어는 MIT 라이선스를, Xray 코어는 MPL 2.0 라이선스를 따릅니다. 클라이언트와 종속성에도 각각 해당 라이선스가 적용됩니다. 오픈 소스란 라이선스 범위 내에서 코드를 열람·사용·수정할 수 있다는 뜻이지, 모든 구성 요소의 릴리스 주기가 같다는 의미는 아닙니다. 라이선스 안내는 소프트웨어의 사용 및 배포 조건을 이해하는 데 도움이 되지만 구체적인 기능, 실행 환경, 설정 내용을 확인하는 절차를 대신하지는 않습니다.
클라이언트는 연결 도구를 제공할 뿐, 사용할 수 있는 원격 서비스를 자동으로 만들어 주지는 않습니다. 서버 주소와 인증 정보 및 관련 매개변수는 사용자가 직접 준비해야 합니다. 홈페이지에 표시된 예시 주소는 설정 항목을 설명하기 위한 것이고, 라우팅 예시도 매칭 로직만 보여 줍니다. 예시를 학습에 사용할 때는 구조 설명과 실제 서비스의 값으로 교체해야 하는 항목을 구분해, 데모 설정을 완전한 노드로 오해하지 않도록 하세요.
클라이언트 UI, 코어, 라우팅 데이터 파일은 서로 독립적으로 변경될 수 있습니다. 클라이언트를 업데이트하면 일부 항목이 다시 생성될 수 있고, 규칙 데이터를 업데이트하면 같은 분류 이름에 포함되는 도메인이나 주소가 달라질 수 있습니다. 따라서 설정의 출처와 사용자 지정 내용을 각각 기록하고 중요한 규칙에는 알아보기 쉬운 메모를 남겨 두세요. 동작이 달라지면 생성된 설정과 로그를 먼저 비교한 뒤 특정 설정을 되돌릴지 결정하세요.
구독은 원격 매개변수를 일괄 업데이트하는 데 적합하고, 백업에는 이 기기의 설정이 포함되어야 합니다. 두 방식은 서로 대체할 수 없습니다. 구독에 시스템 프록시 기본 설정, 앱별 트래픽 분할 목록, 수동 라우팅 규칙이 포함된다고 보장할 수 없습니다. 기기를 바꿀 때는 재사용할 수 있는 노드 정보와 기기별 수신 주소·권한·시작 설정을 나누어 정리하세요. 이 사이트의 설정 레퍼런스는 항목별로, 가이드는 작업 순서대로 구성되어 있으니 현재 문제에 맞는 쪽을 선택해 읽을 수 있습니다.
NOTES / 사용 팁
첫 설치부터 규칙 우선순위와 인증서 오류까지, 구체적인 문제에 맞춰 살펴보세요. 각 문서의 매개변수 설명은 설정 레퍼런스와 함께 참고할 수 있습니다. 수정 전에는 사용 중인 코어와 클라이언트 설정의 적용 범위를 확인하세요.
시스템 시간 불일치, SNI와 인증서 도메인 불일치, 잘못된 위장 도메인 등 TLS 인증서 오류의 주요 원인을 정리하고 클라이언트에서 확인할 위치를 항목별로 안내합니다.
문서 읽기 →domain·full·regexp·geosite·geoip 등 매칭 접두사의 작성법을 설명하고, routing 규칙의 위에서 아래로 적용되는 순서와 domainStrategy가 매칭 결과에 미치는 영향을 안내합니다.
문서 읽기 →v2rayN 압축 해제 및 실행, 시스템 프록시 모드, 로컬 포트, 시작 시 자동 실행 등 첫 설정 항목을 설명하고 런타임 누락, 포트 충돌, 권한 안내 창과 같은 문제의 해결 방법을 안내합니다.
문서 읽기 →