V2RAY / TERMINOLOGY

V2Ray 용어집

프로토콜, 코어, 설정 항목, 진단 지표를 계층별로 찾아보세요. 트래픽 가로채기 방식, 프록시 프로토콜, 전송 보안을 혼동하지 않도록 정리했습니다.

이 페이지에는 자주 쓰이는 용어 30개를 모았습니다. 용어의 의미를 확인한 다음 클라이언트에서 실제로 사용하는 코어와 버전을 살펴보세요. 이름이 같은 옵션이라도 동일한 설정을 만드는 것은 아니며, 예시 항목만으로 완전한 연결 설정이 되지는 않습니다.

문제별 용어 찾기

노드 매개변수가 낯설다면 프로토콜과 전송 방식부터 확인하세요. JSON을 수정하려면 설정 구조를 먼저 살펴보세요. 연결은 되지만 앱 동작이 다르다면 라우팅, DNS, 시스템 프록시를 점검하세요. 사용 순서는 사용 가이드에서, 설정 예시는 설정 전체 보기에서 확인할 수 있습니다.

01 / PROTOCOLS

프로토콜과 전송 방식

프록시 프로토콜은 인증과 데이터 교환 방식을 정하고, 전송 방식은 연결을 전달합니다. TLS와 REALITY 같은 방식은 전송을 보호합니다. 설정할 때는 각 계층을 따로 확인해야 합니다.

프로토콜과 전송 방식

VMess

Project V 생태계의 프록시 프로토콜로 UUID를 사용해 사용자를 식별하며 자체 데이터 보호 기능을 제공합니다. 현재 일반적인 설정은 AEAD를 사용합니다. 이전 가이드에 나오는 alterId 값을 임의로 늘리지 마세요. 최신 설정에서는 보통 0으로 설정합니다. 인증에 실패하면 UUID와 전송 매개변수뿐 아니라 기기 시간이 정확한지도 확인하세요.

"protocol": "vmess"
프로토콜과 전송 방식

VLESS

UUID로 인증하는 경량 프록시 프로토콜입니다. VMess의 암호화 옵션 중 하나로 보면 안 됩니다. 일반적으로 TLS나 REALITY 같은 외부 보안 계층으로 전송을 보호하며, 보안 계층과 전송 계층의 매개변수를 모두 확인해야 합니다. 일부 최신 기능은 코어 버전에 따라 지원 여부가 달라지므로 링크 접두어만 보고 클라이언트 호환성을 판단할 수 없습니다.

"protocol": "vless"
프로토콜과 전송 방식

Trojan

일반적으로 TLS 연결을 통해 사용하는 프록시 프로토콜로, 비밀번호로 인증합니다. 비밀번호는 사용자를 인증하고 인증서 검증은 TLS 상대방의 신원을 확인하므로 서로 대체할 수 없습니다. 인증서 오류가 발생하면 검증을 끄기보다 서버 이름, 인증서 유효 기간, 기기 시간을 확인하세요.

"protocol": "trojan"
프로토콜과 전송 방식

Shadowsocks

정해진 암호화 방식과 키로 프록시 트래픽을 보호하는 프로토콜입니다. 노드에는 보통 서버 주소, 포트, 암호화 방식, 비밀번호가 포함됩니다. 암호화 방식마다 키 형식과 코어 지원 조건이 다르므로 기존 방식과 2022 계열의 매개변수를 섞어 쓰지 마세요. 프로토콜 이름이 같더라도 모든 버전의 클라이언트에서 노드를 불러올 수 있는 것은 아닙니다.

"protocol": "shadowsocks"
프로토콜과 전송 방식

REALITY

Xray 생태계의 전송 보안 방식으로 VLESS와 함께 자주 사용되며, 독립적인 프록시 프로토콜은 아닙니다. 클라이언트에서 서버 이름, 공개 키, shortId, 핑거프린트 등의 매개변수를 확인해야 합니다. 구체적인 필드 이름은 현재 코어의 설정 형식을 따르세요. 일반 TLS와 같은 기능이 아니므로 보안 유형 이름 하나만 바꿔서는 설정이 완성되지 않습니다.

"security": "reality"
프로토콜과 전송 방식

XTLS Vision

Xray에서 VLESS와 함께 자주 쓰이는 흐름 제어 방식으로, 조건에 맞는 TLS 트래픽 처리를 최적화해 불필요한 중복 캡슐화와 암호화 부담을 줄입니다. flow로 선택하며 전송 프로토콜 이름은 아닙니다. 모든 요청이 더 빨라지는 것도 아닙니다. 클라이언트와 서버에서 호환되는 흐름 제어, 보안 계층, 전송 방식 조합을 사용해야 합니다.

"flow": "xtls-rprx-vision"

02 / CORE & CLIENT

코어와 클라이언트

클라이언트 인터페이스는 관리하고 코어는 실제 처리를 담당합니다. 기능을 사용할 수 있는지 확인하려면 클라이언트 지원 여부와 실제 실행 중인 코어를 모두 살펴봐야 합니다.

코어와 클라이언트

Project V

V2Ray를 중심으로 형성된 모듈형 네트워크 프록시 프로젝트이자 생태계 개념입니다. 접속, 전송, 라우팅 등의 기능을 조합해 사용합니다. V2Ray, V2Fly, Xray, GUI 클라이언트는 서로 다른 계층에 있으므로 한 소프트웨어의 여러 이름처럼 다루면 안 됩니다. 가이드를 읽을 때는 생태계 배경, 코어 설정, 인터페이스 조작 중 무엇을 설명하는지 먼저 확인하세요.

코어와 클라이언트

Xray 코어

V2Ray 코드 기반에서 발전한 프록시 코어로, 연결 설정, 프로토콜 처리, 라우팅, DNS 등의 작업을 담당합니다. REALITY와 Vision 설정은 Xray의 구체적인 지원 범위를 확인해야 합니다. 클라이언트에 옵션이 표시되더라도 기본 포함된 코어나 직접 선택한 코어에서 실행할 수 있다는 뜻은 아닙니다.

코어와 클라이언트

V2Fly

V2Ray 관련 핵심 구현을 지속적으로 관리하는 커뮤니티 프로젝트로, Project V 생태계의 주요 구성 요소입니다. V2Fly와 Xray는 기술적 배경을 공유하지만 기능, 버전 업데이트 주기, 설정 형식은 서로 다릅니다. 설정을 옮길 때는 대상 코어의 문서를 확인하고, 한쪽에서만 쓰는 항목을 다른 쪽에 그대로 추가하지 마세요.

코어와 클라이언트

GUI 클라이언트

노드 목록, 구독 업데이트, 라우팅 설정, 실행 로그를 제공하는 앱입니다. v2rayN, v2rayNG, v2flyNG 등이 있습니다. 클라이언트는 보통 설정을 생성해 코어를 실행하며, 화면에 표시된 항목 이름이 JSON 필드와 정확히 일치하지 않을 수 있습니다. 앱을 선택할 때는 운영체제와 노드에 필요한 기능을 확인한 뒤 클라이언트 다운로드 페이지에서 해당 항목을 선택하세요.

03 / CONFIGURATION

설정 구조

일반적으로 설정은 트래픽 수신, 출구 선택, 연결 설정 순서로 살펴보면 이해하기 쉽습니다. 필드 이름을 외우는 것보다 어느 계층에 속하는지 파악하는 것이 중요합니다.

설정 구조

JSON 설정

객체, 배열, 키와 값으로 코어 실행 매개변수를 표현하는 텍스트 형식입니다. 키 이름과 문자열에는 큰따옴표를 쓰고, 불리언 값은 true 또는 false로 표기합니다. 엄격한 JSON은 주석이나 마지막 항목 뒤의 쉼표를 허용하지 않습니다. 일부 도구가 이를 느슨하게 처리하더라도 일반 규칙으로 볼 수는 없습니다. 문법 검사를 통과한 뒤에도 현재 코어와 설정 버전에서 해당 항목을 사용할 수 있는지 확인해야 합니다.

설정 구조

inbounds 인바운드

코어가 앱 트래픽을 받아들이는 방식을 정의합니다. 수신 주소와 포트, SOCKS나 HTTP 같은 연결 프로토콜이 포함됩니다. 로컬 수신 포트와 원격 서버 포트는 역할이 다릅니다. 현재 기기에서만 사용할 때는 보통 루프백 주소에 바인딩합니다. LAN에 공개하기 전에는 접근 제어와 기기 방화벽 설정을 먼저 확인하세요.

"listen": "127.0.0.1"
설정 구조

outbounds 아웃바운드

코어가 외부로 연결하는 방식을 정의하며, 프록시, 직접 연결, 차단 등의 출구를 설정할 수 있습니다. 아웃바운드의 tag는 라우팅에서 참조하는 태그이지 프로토콜 이름이 아닙니다. proxy라는 태그를 붙인다고 프록시 연결이 자동으로 생성되지는 않습니다. 규칙을 점검할 때는 참조 태그와 대상 아웃바운드가 정확히 일치하는지 확인하세요.

"outboundTag": "proxy"
설정 구조

policy 정책

연결 시간 초과, 사용자 레벨별 제한, 일부 통계 기능 등 실행 정책을 설정합니다. 구체적인 항목은 코어마다 다릅니다. 여기서 말하는 정책은 특정 웹사이트를 특정 출구로 보내는 설정이 아닙니다. 그 설정은 routing에 해당합니다. 시간 초과를 조정하기 전에 로그를 보고 실패 지점을 확인하세요. 대기 시간을 무작정 늘려도 인증이나 라우팅 오류는 해결되지 않습니다.

설정 파일 항목별 참고 보기

04 / ROUTING & DNS

라우팅과 DNS

트래픽 분기에는 목적지 정보를 식별할 수 있어야 합니다. 도메인, DNS 조회 결과, 트래픽 가로채기 경로가 서로 맞지 않으면 규칙을 올바르게 작성해도 적용되지 않을 수 있습니다.

라우팅과 DNS

routing 라우팅 규칙

도메인, IP, 포트, 네트워크 유형, 인바운드 태그 등의 조건에 따라 요청이 사용할 아웃바운드를 선택합니다. 일반적인 필드 규칙은 목록 순서대로 확인하며, 먼저 일치하는 유효 규칙이 출구를 결정합니다. 한 규칙 안의 여러 조건은 보통 모두 충족해야 합니다. 문제를 확인할 때는 규칙 순서를 살펴본 다음 outboundTag를 확인하세요. 도메인 철자만 점검해서는 부족합니다.

"type": "field"
라우팅과 DNS

GeoIP 및 GeoSite

GeoIP는 IP 주소 집합을, GeoSite는 도메인 집합을 기준으로 분류해 라우팅 규칙의 중복을 줄이는 데 사용합니다. 분류 이름, 포함된 항목, 업데이트 상태는 실제로 불러온 데이터 파일에 따라 달라지므로 이름만 보고 모든 대상을 포함한다고 판단하면 안 됩니다. 도메인 집합과 IP 주소 집합은 서로 대체할 수 없습니다. 규칙이 적용되지 않으면 DNS 조회 결과와 데이터 출처를 따로 확인하세요.

"ip": ["geoip:private"]
라우팅과 DNS

트래픽 분기

규칙에 따라 요청마다 서로 다른 출구를 사용하도록 하는 방식입니다. 예를 들어 특정 도메인은 프록시로 보내고 LAN 주소는 직접 연결할 수 있습니다. 시스템 프록시는 일부 앱 트래픽이 클라이언트로 들어오는지를 정하고, 트래픽 분기는 들어온 요청의 경로를 정하므로 서로 다른 설정입니다. 클라이언트에 표시된 모드 이름은 규칙 조합을 선택하는 시작점일 뿐입니다. 실제로 생성된 라우팅 규칙을 확인하세요.

라우팅과 DNS

DNS와 domainStrategy

DNS는 도메인을 주소로 변환하고, 라우팅의 domainStrategy는 규칙을 판단할 때 언제 조회할지 정합니다. IPIfNonMatch는 보통 도메인 규칙과 일치하지 않을 때 조회한 IP로 다시 대조하는 방식입니다. IPOnDemand는 IP 규칙을 만났을 때 조회를 시작할 수 있습니다. 다른 설정 계층의 동명 필드는 의미가 다를 수 있으므로 해당 필드가 속한 객체와 함께 확인해야 합니다.

"domainStrategy": "IPIfNonMatch"
라우팅과 DNS

FakeDNS

앱에 매핑 주소를 반환한 뒤 코어가 해당 매핑을 이용해 원래 도메인을 복원하므로 이후 처리와 라우팅 판단에 사용할 수 있습니다. 이 주소는 대상 웹사이트의 실제 주소가 아니므로 DNS 요청, 트래픽 가로채기, 인바운드 식별이 함께 맞아야 합니다. 옵션 하나만 켜고 해당 트래픽을 가로채지 않으면 앱이 매핑 주소를 받아도 연결을 설정하지 못할 수 있습니다.

라우팅과 DNS

DNS 누출

DNS 조회 요청이 예상한 경로를 벗어나 전송되는 현상을 뜻합니다. 예를 들어 클라이언트가 처리할 것으로 예상했는데 시스템이나 브라우저가 별도로 조회할 수 있습니다. 한 번의 검사 결과만 보지 말고 시스템 DNS, 브라우저의 암호화 DNS, 앱 캐시, 클라이언트 내장 DNS 조회를 각각 확인하세요. 실제로 예상 경로에서 벗어났는지는 명확히 정한 네트워크 정책을 기준으로 판단해야 합니다.

라우팅과 DNS

TUN 모드

가상 네트워크 인터페이스와 라우팅 설정으로 IP 트래픽을 받아들이는 가로채기 방식입니다. 시스템 프록시 설정을 따르지 않는 앱의 트래픽을 처리할 때 유용합니다. TUN은 프록시 프로토콜이 아니며 원격 노드나 DNS 설정을 대신하지 않습니다. 구현 방식에 따라 클라이언트가 호출하는 추가 구성 요소가 필요할 수도 있습니다. 활성화한 뒤 LAN 접속에 문제가 생기면 라우팅 제외 항목, 권한, DNS 가로채기 설정을 확인하세요.

05 / SUBSCRIPTIONS

구독과 노드

구독은 설정을 가져오는 경로이고, 노드는 연결 매개변수이며, 공유 링크는 매개변수를 텍스트로 표현한 것입니다. 가져오기에 성공해도 연결이 실제로 작동한다는 뜻은 아닙니다.

구독과 노드

구독 링크

노드 목록이나 설정을 가져오는 주소이며, 클라이언트는 업데이트를 통해 내용을 다시 불러옵니다. 응답은 인코딩된 공유 링크 목록일 수도 있고 기본 설정 파일이나 다른 형식일 수도 있으므로 가져오기 방식이 응답 형식과 맞아야 합니다. 주소에 접근 인증 정보가 포함될 수 있으므로 민감하게 취급하세요. 스크린샷, 로그, 공개 질문에 공유할 때는 주소를 가려야 합니다.

구독과 노드

노드

클라이언트에서 원격 연결 매개변수 한 묶음을 표시하는 단위입니다. 보통 서버 주소, 포트, 인증 정보, 전송 보안 설정이 포함됩니다. 노드 이름은 제공자나 사용자가 정하므로 이름에 적힌 지역이나 회선 정보가 성능 측정 결과를 뜻하지는 않습니다. 연결 문제를 확인할 때는 표시 이름이 아니라 실제 주소와 설정값을 대조하세요.

구독과 노드

구독 변환

서로 다른 구독 또는 설정 형식을 파싱해 항목을 대응시키는 과정으로, 파일 확장자만 바꾸는 작업이 아닙니다. 대상 형식에서 표현할 수 없는 옵션은 누락될 수 있으며, 대상 코어가 지원하지 않는 기능이 변환으로 추가되지는 않습니다. 변환 후에는 보안 계층, flow, 서버 이름, 전송 매개변수를 하나씩 확인하세요. 민감한 내용을 처리할 때는 로컬에서 변환하는 방법을 우선 고려하세요.

06 / MEASUREMENT

속도 측정·진단

먼저 테스트가 연결 경로의 어느 구간을 측정하는지 확인한 뒤 수치를 비교하세요. 포트 연결 가능 여부, 프록시 요청 성공 여부, 지속적인 다운로드 속도는 서로 다른 결과입니다.

속도 측정·진단

시스템 프록시

운영체제가 앱에 제공하는 프록시 연결 설정이며, 보통 클라이언트의 로컬 HTTP 또는 SOCKS 수신 주소를 가리킵니다. 이 설정을 따르는 앱만 해당 프록시를 사용하므로 시스템 프록시를 켜도 모든 트래픽이 가로채지는 않습니다. 클라이언트를 종료한 뒤 브라우저가 인터넷에 연결되지 않으면 중지된 포트를 가리키는 프록시 설정이 남아 있는지 확인하세요.

속도 측정·진단

지연 시간과 TCPing

지연 시간은 특정 작업에 걸리는 시간으로, 무엇을 측정했는지 함께 밝혀야 합니다. 일반 ping은 보통 ICMP 왕복 시간을 측정하고, TCPing은 대상 포트에 TCP 연결을 설정하는 시간을 측정합니다. TCPing에 성공해도 테스트 조건에서 포트에 연결할 수 있다는 뜻일 뿐, 프록시 인증이나 TLS 매개변수가 올바르다는 의미는 아닙니다. 특정 탐지에 응답이 없더라도 모든 연결 방식이 작동하지 않는다고 단정할 수는 없습니다.

속도 측정·진단

실제 연결 지연

프록시를 통해 테스트 주소에 요청을 보내 측정한 시간으로, 단순한 포트 탐지보다 실제 접속 상황에 가까운 범위를 측정합니다. 결과는 DNS, 핸드셰이크, 연결 재사용, 서버 응답, 테스트 주소의 영향을 받으며 구체적인 측정 방식은 클라이언트 구현에 따라 다릅니다. 노드를 비교할 때는 같은 테스트 주소와 비슷한 시간대를 사용하고 실제 앱 요청 결과도 함께 살펴보세요.

속도 측정·진단

다운로드 속도 측정과 처리량

테스트 데이터를 전송해 단위 시간당 받은 유효 데이터량을 추정하는 지표입니다. 요청 한 번에 응답을 받기까지 기다리는 시간과는 다릅니다. 테스트 서버 용량, 회선 혼잡, 기기 성능, 동시 연결 방식에 따라 결과가 달라지며 지연 시간이 짧다고 처리량이 높은 것은 아닙니다. 속도 측정은 데이터를 사용하므로 먼저 연결과 지연 시간을 확인한 뒤 후보 노드 몇 개만 다운로드 테스트를 진행하세요.

속도 측정·진단

sniffing 트래픽 탐지

연결 초기 데이터에서 프로토콜이나 도메인 정보를 식별해 라우팅 등 후속 처리에 활용합니다. 예를 들어 일반 텍스트로 전송되는 HTTP 호스트 이름이나 TLS 핸드셰이크 정보를 읽을 수 있습니다. 트래픽을 완전히 복호화하는 기능은 아니며 모든 앱 트래픽에서 대상 도메인을 알아낼 수도 없습니다. 대상 주소를 바꾸는지, 라우팅에만 사용하는지, FakeDNS와 함께 쓰는지는 구체적인 옵션을 확인해야 합니다. 전체 활성화 스위치만 보고 판단하지 마세요.

"sniffing": {"enabled": true}