프로토콜 이름부터 설정 항목까지, 사용 위치에 따라 찾아보세요. 클라이언트와 코어, 연결 매개변수를 먼저 구분한 뒤 옵션을 앱에서 설정할지 config.json에서 지정할지 확인할 수 있습니다.
프로토콜은 데이터 교환 방식을, 전송 방식은 연결 전달 수단을 정의합니다. 보안 계층은 핸드셰이크와 보호 기능을 담당하며, 세 계층을 각각 서버 설정에 맞춰야 합니다.
VMess는 Project V 생태계의 프록시 프로토콜입니다. 사용자 식별 정보 등의 매개변수로 인증하므로 연결 설정이 서버와 일치해야 합니다. 인증에 실패하면 주소, 포트, UUID뿐 아니라 기기의 시스템 시간도 확인하세요. 시간 차이로 핸드셰이크가 실패할 수 있습니다. VMess와 WebSocket은 같은 종류의 옵션이 아닙니다. VMess는 프록시 프로토콜이고 WebSocket은 VMess 데이터를 전달할 수 있는 전송 방식입니다.
아웃바운드 항목 보기 →VLESS는 경량 프록시 프로토콜로, 자체적으로 데이터를 암호화하지 않습니다. 일반적으로 TLS나 REALITY 같은 보안 계층과 함께 사용합니다. VLESS를 선택한 뒤에도 전송 방식, 서비스 이름, 보안 매개변수를 별도로 확인해야 합니다. UUID만 입력했다고 설정이 완성되는 것은 아닙니다. 관련 조합과 확장 기능의 지원 여부는 코어마다 다르므로 실제 코어 버전을 기준으로 확인하세요.
VLESS와 REALITY의 차이 →Trojan은 일반적으로 TLS 연결을 통해 프록시 데이터를 전달하며 비밀번호를 인증 정보로 사용합니다. 비밀번호가 맞아도 핸드셰이크가 반드시 성공하는 것은 아닙니다. 서버 이름, 인증서 신뢰 여부, 전송 설정도 올바르게 지정해야 합니다. 인증서 오류가 발생하면 인증서 검증을 건너뛰기보다 도메인과 기기 시간을 먼저 확인하세요.
연결 매개변수 확인 →REALITY는 Xray 생태계의 전송 보안 방식으로, 독립적인 프록시 프로토콜도 노드 주소도 아닙니다. VLESS와 함께 사용하는 경우가 많으며, 클라이언트에는 서버에 맞는 공개 키, 서버 이름, 짧은 식별자 등의 매개변수를 설정해야 합니다. 인터페이스에서 REALITY를 선택할 수 있어도 모든 코어가 해당 조합을 실행할 수 있는 것은 아닙니다. 실제로 연결을 처리하는 코어도 이를 지원해야 합니다.
Xray 정의 보기 →전송 계층은 프록시 데이터가 어떤 연결 방식으로 전달되는지 나타냅니다. 대표적인 방식은 TCP, WebSocket, gRPC입니다. WebSocket의 경로, gRPC의 서비스 이름 등은 각 전송 방식의 매개변수이므로 서버 및 중간 전달 설정과 일치해야 합니다. 전송 방식의 이름이 같아도 연결이 보장되지는 않으므로 TLS 등의 보안 계층 설정도 확인해야 합니다.
전송 설정 위치 보기 →프로젝트 이름, 실제 연결을 처리하는 코어, 그래픽 클라이언트는 서로 다른 계층에 속합니다. 클라이언트 이름만으로 실제 코어를 알 수는 없습니다.
Project V는 네트워크 프록시와 통신 도구를 중심으로 형성된 프로젝트 생태계이며, V2Ray는 이 기술 체계를 이해하는 주요 출발점입니다. 인바운드, 아웃바운드, 라우팅 모델은 이 설정 방식에서 비롯됐으며 이후 다양한 프로젝트와 포크로 발전했습니다. 오래된 안내를 참고할 때 Project V나 V2Ray라는 이름만으로 새로운 설정 항목을 사용할 수 있다고 판단해서는 안 됩니다.
프로젝트와 클라이언트 구분하기 →V2Fly는 V2Ray 관련 코어 구현과 문서를 꾸준히 유지 관리하는 커뮤니티 프로젝트입니다. 흔히 말하는 V2Fly-core는 이 프로젝트의 핵심 프로그램을 가리킵니다. Android 클라이언트 v2flyNG는 V2Fly 코어를 연결 처리 기반으로 사용하므로 해당 설정 체계가 필요한 경우에 적합합니다. 버전마다 설정 형식과 지원 범위가 다르므로 각각 확인해야 하며, 다른 코어의 새 매개변수를 그대로 복사해서는 안 됩니다.
Android 클라이언트 보기 →Xray는 V2Ray 기술 체계에서 발전한 코어 프로젝트로, 프로토콜·보안 계층·설정 항목을 자체적으로 구현합니다. v2rayNG는 Xray 코어를 기반으로 하며, v2rayN에서 실제로 사용할 수 있는 기능은 선택한 코어에 따라 달라집니다. 두 코어는 일부 설정 개념을 공유하지만 모든 JSON 조각을 서로 바꿔 쓸 수 있는 것은 아닙니다.
코어 선택 안내 읽기 →코어는 연결 설정, 라우팅, DNS 요청 처리를 담당하고, 클라이언트는 설정 편집, 구독 관리, 실행 제어를 맡습니다. v2rayN, v2rayNG, v2flyNG는 클라이언트 이름입니다. 인터페이스 설정은 코어 설정으로 변환될 수도 있고 클라이언트 자체에만 적용될 수도 있습니다. 기능 지원 여부를 확인하려면 인터페이스와 코어가 모두 지원하는지 살펴봐야 합니다. 어떤 클라이언트를 설치했는지만으로 판단할 수는 없습니다.
클라이언트·플랫폼 보기 →config.json의 최상위 항목 이름으로 각 설정의 역할을 확인하세요. 먼저 연결이 어디로 들어오고 나가는지 살펴본 다음 라우팅이 아웃바운드를 어떻게 선택하는지 확인하면 됩니다.
config.json은 코어 설정에 흔히 사용하는 JSON 파일 이름입니다. 보통 인바운드, 아웃바운드, 라우팅, DNS, 정책 등의 설정 항목으로 구성됩니다. JSON은 따옴표, 쉼표, 괄호의 형식이 엄격하므로 일반 JSON 파일에 설명용 주석을 넣을 수 없습니다. 클라이언트가 생성하는 실행 설정은 클라이언트 자체 설정 파일과 다를 수 있으며, 생성된 파일을 직접 수정해도 다음 실행 때 덮어써질 수 있습니다.
inbounds는 인바운드 설정 배열로, 로컬 SOCKS 또는 HTTP 프록시가 연결을 받는 방식 등을 정의합니다. 각 인바운드에는 수신 주소, 포트, 프로토콜, 식별자를 설정할 수 있습니다. 127.0.0.1은 일반적으로 로컬 기기에서만 접속을 허용합니다. 수신 주소를 모든 인터페이스로 변경하면 접근 가능한 범위가 넓어지므로 인증과 방화벽 제한도 함께 고려해야 합니다.
outbounds는 아웃바운드 설정 배열로, 연결을 다음에 어떤 방식으로 보낼지 지정합니다. 프록시, 직접 연결, 차단 등을 설정할 수 있습니다. 아웃바운드의 tag는 라우팅에서 참조하는 식별자이며 고정된 프로토콜 이름이 아닙니다. 설정에 맞게 이름을 정할 수 있습니다. 아웃바운드를 선언하는 것만으로는 충분하지 않습니다. 라우팅 규칙이 해당 아웃바운드를 선택하는지, 규칙에 일치하지 않을 때 어떻게 처리하는지도 확인해야 합니다.
routing은 도메인, 대상 IP, 포트, 인바운드 식별자 등의 조건에 따라 아웃바운드를 선택합니다. 규칙은 보통 순서대로 적용됩니다. 앞쪽에 지나치게 광범위한 조건을 두면 뒤에 있는 구체적인 규칙이 적용되지 않을 수 있습니다. 같은 규칙에서 서로 다른 유형의 조건은 모두 충족해야 하는 경우가 많으므로, 모든 항목을 하나라도 맞으면 적용되는 조건으로 해석해서는 안 됩니다.
policy는 연결 처리 정책을 설정하는 항목으로, 사용자 레벨에 따라 핸드셰이크 시간 제한, 유휴 시간 제한, 버퍼 등의 동작을 지정할 수 있습니다. routing과 역할이 다르며 특정 도메인의 연결을 프록시로 보낼지 직접 연결할지 결정하지 않습니다. 시간 제한이나 버퍼를 무작정 늘린다고 속도가 빨라지는 것은 아닙니다. 변경하기 전에 해당 항목의 단위와 기본값, 코어 지원 여부를 확인하세요.
도메인 조회와 연결 전달은 서로 영향을 주지만 같은 처리 과정은 아닙니다. 규칙 데이터, DNS 요청, 최종 트래픽 경로를 각각 확인해야 합니다.
DNS는 도메인을 IP 주소로 변환합니다. V2Ray 설정의 dns 항목은 일반적으로 내장 DNS 해석기의 동작을 지정합니다. 운영체제, 브라우저, 코어가 각각 DNS 조회를 요청할 수 있으므로 내장 DNS를 변경해도 모든 앱이 이를 사용한다고 볼 수는 없습니다. 문제를 확인할 때는 먼저 어느 계층에서 도메인을 조회하는지 파악한 다음 DNS 서버, 요청 경로, 관련 라우팅을 살펴보세요.
GeoIP는 식별자를 기준으로 구성된 IP 주소 모음을 뜻하며 geoip:cn 같은 표현식으로 라우팅 규칙에 사용할 수 있습니다. 대상 IP가 지정된 주소 모음에 속하는지 판별하는 기능이지, 웹페이지 언어나 서버의 실시간 물리적 위치를 확인하는 기능은 아닙니다. 매칭 결과는 로컬 데이터 파일에 따라 달라집니다. 도메인 정보만 있는 경우 후속 DNS 조회 정책도 영향을 줄 수 있습니다.
GeoSite는 분류 식별자를 기준으로 구성된 도메인 규칙 모음입니다. 라우팅 분기나 지원되는 DNS 설정에서 조회 범위를 제한하는 데 사용할 수 있습니다. 설정의 geosite:cn은 데이터 파일에 있는 분류를 참조하며, 인터넷에서 항목을 자동으로 검색해 추가하지 않습니다. 분류 이름과 포함 범위는 데이터 출처에 따라 달라집니다. 분류가 없거나 파일 경로가 잘못되면 로드에 실패할 수 있습니다.
FakeDNS는 도메인 조회에 가상 IP를 응답하고, 이후 연결 처리에서 도메인 정보를 복원할 수 있도록 IP와 도메인의 매핑을 내부에 저장합니다. 일반적인 공용 DNS 주소가 아니므로 트래픽 가로채기, 매핑 복원, 라우팅 설정과 함께 사용해야 합니다. 앱이 저장한 가상 IP가 해당 처리 과정에서 벗어나면 연결이 실패할 수 있습니다. 모드를 전환한 뒤 관련 캐시를 지워야 할 수도 있습니다.
DNS 설정 범위 보기 →DNS 누수는 도메인 조회가 예상한 경로를 따르지 않는 현상입니다. 예를 들어 프록시를 통해 조회하려 했지만 시스템이 다른 DNS 서버로 요청을 보낼 수 있습니다. 테스트 페이지에 표시된 DNS 서버 위치는 참고 정보일 뿐, 모든 트래픽의 경로를 증명하지는 않습니다. 브라우저의 보안 DNS, 시스템 DNS 설정, 코어 로그를 함께 확인하세요. 암호화 DNS를 사용한다고 해서 요청이 예상한 아웃바운드를 거치는 것도 아닙니다.
DNS 라우팅 분기 안내 읽기 →라우팅 분기는 조건에 따라 서로 다른 연결을 다른 경로로 보내는 기능입니다. 예를 들어 특정 도메인은 직접 연결하고 나머지는 프록시 아웃바운드로 보낼 수 있습니다. 자동 속도 측정과 같지 않으며 노드 장애 시 자동 전환을 반드시 포함하는 것도 아닙니다. 이런 기능에는 별도의 지원이 필요합니다. 라우팅 결과는 규칙 순서, 도메인 정보 확인 가능 여부, 규칙에 일치하지 않을 때 사용할 기본 아웃바운드에 따라 달라집니다.
라우팅 설정 예시 보기 →이 용어는 주로 클라이언트 인터페이스에서 사용합니다. 설정 가져오기, 앱 트래픽 가로채기, 연결 테스트는 서로 다른 단계입니다.
구독은 여러 연결 설정을 가져오고 갱신하는 주소 또는 데이터 소스입니다. 클라이언트가 구독을 읽으면 선택 가능한 노드로 변환합니다. 구독 주소에 접근 자격 정보가 포함될 수 있으므로 민감한 정보로 취급하고 공개 스크린샷이나 로그에 노출하지 마세요. 구독을 갱신하면 설정 목록이 새로고침될 뿐 시스템 프록시, DNS, 로컬 네트워크 설정이 자동으로 수정되지는 않습니다.
구독 가져오기 방법 보기 →노드는 클라이언트에서 서버 연결 정보 묶음을 부르는 일반적인 명칭입니다. 보통 주소, 포트, 프로토콜, 인증 정보, 전송 설정을 포함합니다. 표시 이름은 제공자나 사용자가 바꿀 수 있으므로 서버 위치, 회선 종류, 성능을 증명하지 않습니다. 노드를 가져올 수 있다는 것은 클라이언트가 해당 데이터 형식을 받아들였다는 뜻일 뿐입니다. 실제 연결을 확인하려면 코어를 실행하고 연결을 테스트해야 합니다.
아웃바운드 매개변수 확인 →시스템 프록시는 운영체제가 앱에 제공하는 프록시 설정이며, 보통 클라이언트가 로컬에서 연결을 받는 주소와 포트를 가리킵니다. 이 설정을 따르는 앱만 해당 연결을 전달하므로 시스템 프록시를 켜도 기기의 모든 트래픽이 가로채지는 않습니다. 앱에서 프록시를 별도로 설정하거나 직접 연결하는 경우, 또는 독립적인 네트워크 구성 요소를 사용하는 경우에는 실제 경로를 각각 확인해야 합니다.
TUN 모드와 비교하기 →TUN 모드는 가상 네트워크 인터페이스와 라우팅 설정을 통해 네트워크 트래픽을 받아 시스템 프록시를 사용하지 않는 앱도 클라이언트의 처리 경로로 전달할 수 있게 합니다. 실제 적용 범위는 관리자 권한, 라우팅, 제외 규칙, 다른 네트워크 소프트웨어의 영향을 받습니다. 기능을 켰다고 모든 트래픽이 프록시를 통과하는 것은 아닙니다. TUN 모드는 클라이언트와 운영체제의 연동 기능이므로, 임의의 코어 JSON에 같은 이름의 항목을 추가하는 것만으로 활성화되지 않습니다.
TUN 설정 안내 보기 →지연 시간은 특정 테스트 방법으로 측정한 소요 시간으로, ICMP 왕복 시간, TCP 연결 수립 시간, 전체 요청 처리 시간 등을 가리킬 수 있습니다. 측정 방법마다 포함되는 네트워크 단계가 다르므로 이름이 다른 수치를 그대로 비교해서는 안 됩니다. 지연 시간이 짧다고 다운로드 속도가 빠른 것은 아닙니다. 처리량, 패킷 손실, 지속적인 안정성은 따로 확인해야 합니다.
실제 연결 지연 시간 구분하기 →실제 연결 지연 시간은 일반적으로 클라이언트가 선택한 설정으로 테스트 대상에 접속해 측정한 시간입니다. 서버 포트만 확인하는 것보다 실제 요청에 가까운 측정입니다. DNS, TLS 등 어느 단계까지 포함하는지는 클라이언트 구현과 테스트 방식에 따라 다르므로 이름만으로 일률적으로 해석할 수 없습니다. 시간 초과는 테스트 대상이나 라우팅 규칙 때문에 발생할 수도 있으니 일반 접속 결과와 함께 확인하세요.
연결 확인 절차 보기 →