GUI 클라이언트로 시작하고, 실제 JSON 설정으로 인바운드·아웃바운드·라우팅을 익혀 보세요. 한국어 사용 설명도 확인할 수 있습니다.
CONFIGURATION / 설정 섹션
요청이 어디로 들어와 어떤 조건과 일치하고, 마지막으로 어떤 아웃바운드에 전달되는지 먼저 파악하세요. 그다음 매개변수를 조정하면 문제를 더 명확히 좁힐 수 있습니다.
인바운드는 앱에서 전달된 요청을 받는 역할이며, 원격 서버 주소와는 다릅니다. 데스크톱 앱은 로컬 SOCKS 포트로 코어에 연결하거나, 지원되는 경우 시스템 프록시를 사용할 수 있습니다. 예시는 루프백 주소에서만 수신하므로 로컬 사용에 적합합니다. 포트는 클라이언트 화면 및 앱 설정과 일치해야 합니다. UDP를 켜면 해당 인바운드에서 관련 요청을 처리할 수 있지만, 실제 전달 여부는 앱·아웃바운드·서버에도 달려 있습니다. GUI 클라이언트는 전체 설정을 직접 관리하는 방식과 달리 대부분의 인바운드 항목을 생성합니다. 직접 편집하기 전에 현재 설정이 다시 생성되는 파일인지 확인하세요.
{
"inbounds": [
{
"tag": "local-socks",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": {
"auth": "noauth",
"udp": true
}
}
]
}라우팅은 요청이 코어에 들어온 뒤 적용되며, 앱이 시스템 프록시를 사용하는지와는 별개의 문제입니다. 규칙은 일반적으로 순서대로 검사하고, 일치하면 지정된 태그의 아웃바운드로 전달합니다. 예시는 사설 IP 주소를 직접 연결 아웃바운드로 보내 LAN 접속의 기본 범위를 설명합니다. 완전한 지역별 분할 설정은 아닙니다. 클라이언트 내장 모드는 규칙과 데이터 파일을 조합하므로, 모드 이름만 보고 각 도메인의 처리 경로를 단정할 수 없습니다. 규칙을 모두 직접 작성하는 것보다 프리셋으로 시작하는 편이 쉽습니다. 정밀하게 분할하려면 태그·조건·규칙 위치를 확인하세요.
{
"outbounds": [
{ "tag": "direct", "protocol": "freedom" }
],
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
]
}
}DNS 설정은 요청이 들어오는 경로와 함께 살펴봐야 합니다. 앱이 먼저 주소를 조회해 코어에 전달할 수도 있고, 도메인을 코어에 넘겨 라우팅 또는 연결 단계에서 조회하게 할 수도 있습니다. 예시는 설정 구조를 보여 주기 위해 로컬 리졸버를 사용한 것으로, 모든 환경에서 최선이라는 뜻은 아닙니다. DNS 서버를 바꾸기 전에 조회 경로와 네트워크 연결 상태, 라우팅 정책을 확인해 여러 조건을 한꺼번에 바꾸지 않도록 하세요. 시스템 DNS만 조정하는 것보다 코어 DNS의 적용 범위는 명확하지만, 모든 앱의 조회를 자동으로 가로채지는 않습니다. 브라우저 자체 DNS 설정도 따로 확인해야 합니다.
{
"dns": {
"hosts": {
"docs.example.com": "192.0.2.10"
},
"servers": ["localhost"]
}
}로그는 요청이 어느 단계에서 실패했는지 파악하는 데 유용하지만, 오류 한 줄만으로 모든 연결 문제를 판단할 수는 없습니다. 먼저 문제를 한 번 재현한 다음 시간순으로 DNS 조회, 연결, 핸드셰이크 관련 기록을 확인하세요. 예시는 로그 수준을 경고로 설정했습니다. 일시적으로 문제를 진단할 때는 클라이언트가 지원하는 범위에서 로그 상세도를 높이고, 진단이 끝나면 원래대로 되돌리세요. 설정 전체를 계속 바꾸기보다 오류 유형별로 하나씩 확인하면 유효한 결론을 남기기 쉽습니다. 로그를 공유하기 전에 구독 주소, 사용자 식별 정보, 접속 대상은 삭제하세요. 설정 구문이 정상적으로 해석된다고 해서 원격 서버에 연결할 수 있는 것은 아닙니다.
{
"log": {
"loglevel": "warning"
}
}CLIENTS / 플랫폼 선택
데스크톱에서는 v2rayN을 선택하세요. Android에서는 먼저 v2rayNG를 살펴보고, 코어 호환성이 필요하다면 v2flyNG를 고려할 수 있습니다. 운영체제와 프로세서 아키텍처를 확인한 다음 다운로드 페이지에서 설치 파일을 선택하세요.
v2rayN은 데스크톱 버전과 클래식 WPF 버전을 제공합니다. 데스크톱 버전은 크로스 플랫폼 GUI를 사용하고, WPF 버전은 익숙한 기존 인터페이스를 선호하는 사용자에게 적합합니다. 두 버전은 GUI 프레임워크가 다릅니다. 실제 기능은 릴리스 정보와 선택한 코어를 기준으로 확인해야 하며, 화면 차이를 프로토콜 차이로 여겨서는 안 됩니다.
기존 설정이 있다면 프로그램 디렉터리를 바꾸기 전에 구독 그룹·라우팅·DNS 설정을 보존하세요. 처음 사용하는 경우 한 가지 인터페이스에서 가져오기와 연결을 먼저 완료하는 편이 좋습니다. 클라이언트 두 개를 동시에 실행하면 수신 포트가 충돌하거나 시스템 프록시 설정이 반복해서 바뀔 수 있습니다.
다운로드 페이지로 이동v2rayN은 Apple Silicon과 Intel용 다운로드를 구분합니다. 시스템의 ‘이 Mac에 관하여’에서 칩 정보를 확인한 뒤 해당 아키텍처에 맞는 설치 파일을 선택하세요. 크로스 플랫폼 GUI의 설정 방식은 비슷하지만 권한 안내, 메뉴 위치, 시스템 프록시 설정 경로는 다른 데스크톱 운영체제와 다를 수 있습니다.
실행 후 프로그램이 설정 디렉터리를 읽을 수 있는지 확인한 다음 구독을 가져오세요. 시스템 프록시를 켰는데도 앱에서 프록시가 작동하지 않는다면 앱 자체의 네트워크 설정을 확인하세요. 시스템 프록시를 사용하지 않는 도구는 안내에 따라 로컬 주소와 포트를 별도로 지정해야 합니다.
다운로드 페이지로 이동v2rayNG는 Xray 코어를 사용하므로 관련 프로토콜과 전송 기능이 필요한 환경에 적합합니다. v2flyNG는 V2Fly 코어를 사용하는 대안입니다. 최신 기기 대부분은 arm64 다운로드를 먼저 확인하고, 아키텍처를 알 수 없다면 범용 패키지를 살펴보세요. 구체적인 호환 조건은 다운로드 페이지와 기기 정보를 기준으로 확인하세요.
처음 연결을 시작하면 시스템에서 VPN 인터페이스 사용 권한을 요청합니다. 이 권한은 클라이언트가 기기 트래픽을 받는 진입점을 설정하는 것이며, 원격 서버에 연결되었다는 뜻은 아닙니다. 백그라운드 실행 제한, 앱별 분할 설정, 같은 시스템 인터페이스를 사용하는 다른 프로그램이 연결 상태에 영향을 줄 수 있습니다.
다운로드 페이지로 이동v2rayN은 deb 및 rpm 패키지를 제공하며 x64와 arm64 아키텍처를 구분합니다. Debian·Ubuntu 계열은 보통 deb를, Fedora 등은 보통 rpm을 선택합니다. 패키지 형식은 시스템의 패키지 관리 방식에 맞아야 하고, 프로세서 아키텍처는 현재 기기와 일치해야 합니다.
데스크톱 환경마다 시스템 프록시 지원 방식이 다를 수 있습니다. 브라우저는 접속되지만 터미널 도구는 안 될 때는 각 도구의 프록시 설정을 먼저 확인하고, 원격 노드를 바로 바꾸지 마세요. 시작 프로그램 설정, 설정 디렉터리 쓰기 권한, 로컬 포트 사용 여부도 각각 확인해야 합니다.
다운로드 페이지로 이동FIRST CONNECTION / 빠른 시작
시작하기 전에 사용할 수 있는 구독 주소나 개별 노드 매개변수를 준비하세요. 클라이언트는 설정을 저장하고 코어를 실행하지만, 설치 프로그램이 원격 연결 정보를 제공하지는 않습니다. 아래 단계는 GUI 사용을 기준으로 합니다. 먼저 최소한의 연결 경로를 만든 뒤 분할 설정과 사용자 지정 항목을 차례로 추가하세요.
v2rayN의 구독 그룹에 주소를 추가하고 알아보기 쉬운 이름을 입력한 다음 업데이트하세요. Android 클라이언트도 먼저 구독 그룹을 저장한 뒤 노드 목록을 업데이트해야 합니다. 단일 공유 링크는 클립보드에서 가져올 수 있지만, 공유 링크와 구독 주소는 입력 형식이 다릅니다. 잘못된 메뉴에 넣으면 파싱에 실패할 수 있습니다.
목록에 항목이 나타나면 프로토콜·서버 주소·포트·전송 방식·보안 설정이 제대로 유지되었는지 확인하세요. 노드 이름은 화면에 표시되는 라벨일 뿐, 실제 매개변수 확인을 대신할 수 없습니다. 구독을 업데이트하면 수동 변경 사항이 덮어써질 수 있습니다. 계속 유지할 수정 사항은 별도 설정이나 클라이언트의 덮어쓰기 기능으로 관리하고, 변경 출처를 기록하세요.
구독 주소에 접속 인증 정보가 포함될 수 있으므로 문제를 진단할 때 전체 주소가 보이는 스크린샷을 공유하지 마세요. 목록이 비어 있다면 주소에 접속할 수 없는지, 응답 형식이 호환되지 않는지, 파싱 오류인지 먼저 확인한 뒤 다시 가져올지 결정하세요.
활성 노드를 지정한 다음 시스템 프록시 진입점과 라우팅 모드를 선택하세요. 시스템 프록시는 시스템 설정을 따르는 앱이 요청을 클라이언트로 전달할지 결정합니다. 라우팅 모드는 요청이 코어에 들어온 뒤 직접 연결과 프록시 중 어느 아웃바운드를 사용할지 결정합니다. 둘 다 ‘프록시’라는 표현을 쓰더라도 같은 계층의 기능은 아닙니다.
처음 연결을 확인할 때는 규칙이 적고 경로가 명확한 설정부터 사용하세요. LAN 리소스에 접속해야 한다면 사설 주소 규칙이 우선 적용되는지 확인하세요. ‘중국 본토 우회’ 모드는 일반적으로 도메인 및 IP 규칙 데이터에 의존합니다. 모드 이름만 보고 모든 앱이 예상대로 분할된다고 단정하지 마세요. 설정을 바꾼 뒤에는 새 연결을 만들어 실제 동작을 확인하세요.
Android에서는 앱별 프록시 적용 범위도 확인해야 합니다. 선택한 앱만 프록시하는 것과 선택한 앱을 우회하는 것은 반대 의미입니다. 문제를 진단하는 동안 한 번에 설정 하나만 바꾸고, 앞 단계에서 작동을 확인한 노드는 그대로 유지하세요. 진입점 문제와 노드 문제를 섞지 않는 것이 좋습니다.
연결을 시작한 뒤 먼저 클라이언트에서 설정 오류가 즉시 보고되지 않는지 확인하고, 대상 앱에서 새 요청을 보내 보세요. 목록에 표시되는 테스트 결과는 특정 테스트 방법만 반영합니다. 브라우저 페이지 접속, 파일 전송, 실시간 통신이 모두 가능하다는 뜻은 아닙니다. 실제 사용 중인 앱과 접속 대상을 기준으로 판단하세요.
연결에 실패하면 로컬 진입점, 도메인 조회, 원격 연결, 프로토콜 핸드셰이크 순서로 확인하세요. 앱의 요청이 로컬 진입점을 거치지 않는다면 원격 매개변수를 반복해서 바꿔도 도움이 되지 않습니다. 요청이 원격 서버에 도달했지만 핸드셰이크가 실패한다면 프로토콜 항목·보안 매개변수·시스템 시간을 확인하세요. 로그의 오류 유형을 보면 두 상황을 구분하는 데 도움이 됩니다.
연결 확인을 마친 다음 사용자 지정 라우팅, 백그라운드 실행, 자동 시작 설정을 추가하세요. 클라이언트를 종료하기 전에 더 이상 사용하지 않는 시스템 프록시를 해제해야 합니다. 그렇지 않으면 앱이 이미 수신을 중단한 로컬 포트를 계속 가리킬 수 있습니다. 전체 사용법에서는 각 단계의 메뉴 위치와 자주 발생하는 분기를 자세히 설명합니다.
PROJECT V / 코어 및 클라이언트
클라이언트는 설정을 관리하고 코어는 연결을 처리합니다. 프로젝트 간 기술적 계보가 이어지더라도 프로토콜 지원, 필드 의미, 업데이트 주기는 각각 확인해야 합니다.
Project V는 V2Ray의 기술적 배경을 이해하기 위한 출발점입니다. V2Ray는 프록시 기능을 인바운드·아웃바운드·전송·라우팅 등의 모듈로 나누어 로컬 앱 진입점과 원격 연결 방식을 각각 설정할 수 있게 합니다. V2Fly는 V2Ray의 커뮤니티 유지보수를 이어가고, Xray는 관련 기술을 바탕으로 자체 구현과 확장 기능을 발전시켰습니다. 두 프로젝트는 설정 개념 일부를 공유하지만 모든 필드와 프로토콜 조합을 서로 바꿔 쓸 수 있는 것은 아닙니다.
자료를 읽을 때는 먼저 어떤 코어를 대상으로 한 설명인지 확인한 뒤, 클라이언트가 해당 설정을 생성할 수 있는지 살펴보세요. 예를 들어 REALITY는 보안 전송과 관련된 기술 조합으로, 모든 프록시 프로토콜과 나란히 놓이는 단일 옵션으로 보면 안 됩니다. 클라이언트에 관련 설정 메뉴가 있더라도 원격 매개변수와 실제 코어가 모두 맞아야 연결할 수 있습니다.
v2rayN은 데스크톱에서 노드 목록·구독·라우팅 프리셋·코어 실행을 관리합니다. v2rayNG는 Android의 시스템 VPN 인터페이스와 Xray 코어를 이용해 트래픽을 처리하고, v2flyNG는 V2Fly 기반의 또 다른 설정 경로를 제공합니다. 세 클라이언트는 모두 오픈소스 프로젝트지만, 비슷한 이름만으로 GUI 조작 방식·설정 생성 절차·호환 범위를 판단할 수는 없습니다.
GUI에서 저장이 완료되었다는 것은 매개변수가 기록되었다는 의미일 뿐입니다. 코어가 생성된 설정을 읽고 파싱한 다음 원격 서버와 협상해야 합니다. 사용자 지정 설정 모드와 일반 노드 모드는 생성 과정이 다를 수 있으므로, 생성된 파일을 직접 수정해도 변경 사항이 계속 유지된다고 보장할 수 없습니다. 수정하기 전에 해당 파일이 설정 원본인지, 클라이언트가 실행 중 생성한 결과물인지 확인하세요.
연결만 필요하다면 빠른 시작부터 읽고, ‘노드’·‘구독’·‘전송’ 같은 용어를 이해하려면 용어 안내서를 살펴보세요. 동작을 직접 설정하려면 JSON 안내서에서 해당 설정 섹션을 확인하면 됩니다. 예제 코드는 일부 구조를 설명하기 위한 것이므로 아웃바운드 정보가 빠진 조각을 완전한 연결 설정으로 사용하면 안 됩니다. 여러 조각을 조합할 때는 태그 참조, 배열 계층, 규칙 순서도 확인하세요.
READING NOTES / 주제별 글
기본 연결을 설정한 뒤에는 구체적인 문제에 맞는 글을 찾아보세요. 설치 파일은 운영체제와 GUI 프레임워크를 기준으로 선택하고, 속도 문제는 회선과 로컬 진입점을 확인하세요. 프로토콜 선택은 원격 설정과 코어 기능을 살펴봐야 합니다. 문제를 나누어야 어떤 설정을 조정할지 판단할 수 있습니다.
크로스 플랫폼 데스크톱 버전과 클래식 WPF 버전의 GUI 프레임워크, 시스템 지원, 사용 방식 차이를 비교합니다. 설치 파일의 지원 범위를 확인한 뒤 기존 설정을 옮길지 결정하세요. GUI 차이와 코어 기능은 구분해서 살펴봐야 합니다.
글 읽기 →속도 문제를 노드 부하·연결 회선·로컬 설정 세 단계로 나누어 살펴봅니다. DNS, 스니핑, MTU, 라우팅 규칙을 확인하고 재현 가능한 테스트 조건을 만든 뒤 변경 전후 결과를 하나씩 비교하세요.
글 읽기 →암호화 방식·핸드셰이크·전송 조합·클라이언트 지원 범위로 프로토콜 차이를 살펴보세요. TLS·REALITY와 프록시 프로토콜의 조합 관계도 구분하고, 이름만 비교하기보다 실제 호환 조건에 맞춰 선택하세요.
글 읽기 →특정 설정 키를 찾으려면 JSON 안내서로 바로 이동하세요. 구독·노드·코어의 차이를 확인하려면 용어 안내서부터 살펴보세요.