설정 용어와 연결 개념

V2Ray 용어집

프로토콜과 코어부터 라우팅 필드까지 설정 계층별로 살펴보세요. 먼저 ‘연결 수신’, ‘출구 선택’, ‘연결 생성’을 구분한 뒤 클라이언트 메뉴와 로그를 대조해 구체적인 설정을 찾을 수 있습니다.

같은 이름의 메뉴도 클라이언트 버전에 따라 다를 수 있습니다. 프로토콜과 필드의 지원 여부는 실제 실행 중인 코어와 버전을 기준으로 확인하세요. 용어 설명이 코어 간 설정 복사를 보장하지는 않습니다.

프로토콜과전송 방식

프록시 프로토콜은 연결 동작을 정의하고, 전송 방식과 보안 계층은 연결을 전달하고 보호합니다. 각 항목을 따로 확인해야 합니다.

VMess

VMess

Project V 생태계의 프록시 프로토콜로, 인증과 데이터 보호 기능을 제공하며 UUID를 인증 정보로 사용하는 경우가 많습니다. VMess는 특정 하위 전송 방식에 고정되지 않으며 여러 전송 설정과 함께 사용할 수 있습니다. 연결 문제를 확인할 때는 노드 이름만 비교하지 말고 프로토콜 매개변수, 전송 방식, 보안 계층을 각각 살펴보세요.

VLESS

VLESS

가벼운 프록시 프로토콜로, 전송 데이터를 자체적으로 암호화하지 않아 보통 적절한 보안 계층과 함께 사용합니다. UUID는 사용자 식별에 쓰이며 TLS, REALITY 등의 설정은 연결의 보안 수준에 영향을 줍니다. 노드에 VLESS가 표시되어도 모든 코어 버전이 같은 flow나 전송 조합을 지원하는 것은 아닙니다.

Trojan

Trojan

일반적으로 TLS와 함께 사용하며 비밀번호로 인증하는 프록시 프로토콜입니다. 인증 비밀번호와 TLS 서버 이름은 서로 다른 매개변수이므로 대체할 수 없습니다. 핸드셰이크에 실패하면 비밀번호가 맞는지만 볼 것이 아니라 인증서 검증, 서버 이름, 전송 설정을 함께 확인해야 합니다.

Transport Layer Security

TLS

전송 데이터의 암호화와 무결성 보호, 상대방 인증을 제공하는 보안 프로토콜입니다. 설정의 serverName은 보통 인증서 이름 검증에 사용되며 SNI를 통해 서버에 전달될 수도 있습니다. 서버 주소와 서버 이름은 다를 수 있지만, 명확한 근거가 있어야 합니다. 인증서 검증을 건너뛰는 방법은 일반적인 문제 해결책으로 사용하지 마세요.

REALITY / streamSettings

REALITY

Xray 생태계의 전송 보안 메커니즘으로, VMess나 VLESS와 같은 프록시 프로토콜은 아닙니다. 사용하려면 지원되는 코어와 공개 키, 서버 이름, 짧은 ID 등의 매개변수를 맞춰야 합니다. TLS와 관련은 있지만 설정 필드를 서로 바꿔 쓸 수는 없습니다. 클라이언트가 공유 링크를 인식하더라도 현재 코어에서 해당 조합이 실행된다는 뜻은 아닙니다.

코어와 클라이언트

클라이언트는 화면과 관리를 담당하고, 코어는 네트워크 설정을 실행합니다. 제품을 선택할 때는 두 가지를 모두 확인해야 합니다.

Project V

Project V

네트워크 프록시와 통신 도구를 중심으로 형성된 오픈 소스 프로젝트 생태계이며, V2Ray는 그중 중요한 구성 요소입니다. 일상적인 대화에서 ‘V2Ray’는 관련 생태계 전체를 가리키는 말로도 쓰입니다. 가이드를 볼 때는 V2Fly와 Xray 중 어느 쪽을 대상으로 하는지 확인해 생태계 이름을 개별 실행 프로그램과 혼동하지 마세요.

V2Fly / v2fly-core

V2Fly

V2Ray 프로젝트의 개발과 유지보수를 이어가는 커뮤니티입니다. 핵심 프로그램은 보통 v2fly-core라고 합니다. 코어는 설정을 해석하고 인바운드 연결을 받아 라우팅한 뒤 아웃바운드 연결을 생성합니다. Xray와 관련 기술 기반을 공유한다고 해서 새 프로토콜, 설정 형식, 필드가 항상 호환되는 것은 아닙니다.

Xray / Xray-core

Xray 코어

V2Ray에서 발전한 독립 코어 브랜치로 자체 프로토콜과 전송 기능을 포함합니다. 클라이언트 화면에서 선택한 코어에 따라 필드의 허용 여부와 연결 방식의 사용 가능 여부가 달라집니다. 알 수 없는 필드나 지원되지 않는 프로토콜 오류가 나타나면 앱 이름만 확인하지 말고 실제로 실행된 코어부터 확인하세요.

v2rayN / Desktop client

v2rayN

Windows, macOS, Linux용 데스크톱 그래픽 클라이언트로 노드, 구독, 라우팅 설정과 코어 실행을 관리합니다. 화면에서 저장한 설정은 변환된 뒤 코어에 전달될 수 있으므로 설정 파일이 실제 실행 설정과 같지 않을 수 있습니다. 데스크톱 버전과 클래식 WPF 버전은 메뉴 구성이 다르므로 현재 화면을 기준으로 조작하세요.

v2rayNG / Android / Xray

v2rayNG

Xray 코어로 프록시 연결을 처리하며 시스템 VPN 인터페이스를 통해 선택한 앱의 트래픽을 받는 Android 그래픽 클라이언트입니다. 앱 버전과 코어 버전은 별개의 정보이므로 호환성 문제를 확인할 때 둘 다 살펴볼 수 있습니다. 특정 앱이 프록시 경로를 이용할 수 있는지는 앱별 설정과 시스템 권한 상태에도 달려 있습니다.

v2flyNG / Android / V2Fly

v2flyNG

V2Fly 코어를 사용하는 Android 그래픽 클라이언트로, 해당 코어의 동작이 필요한 경우 대안으로 사용할 수 있습니다. 이름이 v2rayNG와 비슷하다고 해서 프로토콜 기능이나 설정 호환 범위까지 같다고 단정할 수는 없습니다. 노드를 가져오기 전에 필요한 프로토콜과 보안 계층, 관련 필드가 실제 코어에서 지원되는지 확인하세요.

설정 구조

아래 이름은 일반적인 JSON 설정 개념을 가리킵니다. 배열, 객체, 태그 참조는 각각 쓰임이 있으므로 필드 이름만 보고 조각을 이어 붙이지 마세요.

JavaScript Object Notation

JSON

객체, 배열, 키-값 쌍으로 데이터를 표현하는 텍스트 형식으로, 코어 실행 설정을 작성할 때 자주 사용합니다. 표준 JSON에서는 키와 문자열에 큰따옴표를 사용하며 마지막 쉼표나 주석을 허용하지 않습니다. 문법이 올바르더라도 포트 자료형, 프로토콜 이름, 필드 계층은 사용 중인 코어의 규칙에 맞아야 합니다.

inbounds / listen / port / tag

인바운드

inbounds는 코어가 연결을 받아들이는 방식을 정의하며, 수신 주소와 포트, 프로토콜, 태그 등이 포함됩니다. 루프백 주소에서 수신하면 보통 로컬 프로그램만 연결할 수 있으므로 다른 주소로 바꾸기 전에 접근 범위를 확인하세요. 클라이언트가 정상적으로 시작됐는데 앱 트래픽이 없다면 앱이 사용하는 프록시 포트와 해당 인바운드 설정이 일치하는지 확인해야 합니다.

outbounds / protocol / tag

아웃바운드

outbounds는 코어가 외부 연결을 만드는 방식을 정의하며 프록시, 직접 연결, 차단 등의 처리 방식을 포함할 수 있습니다. 아웃바운드의 tag는 라우팅에서 참조하는 식별자이지 원격 서버 주소가 아닙니다. 태그를 바꾼 뒤에는 outboundTag 등의 참조도 함께 확인해야 규칙이 원하는 출구를 가리킵니다.

routing / rules / domainStrategy

routing 설정 섹션

라우팅 매칭 정책과 규칙 목록을 담는 설정 객체로, 코어에 들어온 트래픽이 어떤 출구를 이용할지 결정합니다. domainStrategy는 도메인을 언제 IP로 조회하고 매칭할지에 영향을 주므로 DNS 설정과 함께 살펴봐야 합니다. 운영체제 프록시 설정을 대신하지 않으며 코어에 들어오지 않은 앱 트래픽을 처리할 수도 없습니다.

policy / levels / system

policy 정책

연결 시간 초과, 사용자 수준별 동작, 통계 기능 등의 코어 매개변수를 설정합니다. 도메인이나 주소에 따라 출구를 선택하는 라우팅 규칙과는 역할이 다릅니다. 시간 초과를 변경하기 전에 문제가 DNS 조회, 핸드셰이크, 데이터 전송 중 어디에서 발생하는지 확인하세요. 대기 시간만 늘려서는 연결 매개변수 불일치를 해결할 수 없습니다.

라우팅과 DNS

도메인 조회 방식, 규칙이 사용하는 대상 정보, 출구 선택은 하나의 연결 경로를 이루는 서로 다른 단계입니다.

routing.rules / outboundTag

라우팅 규칙

도메인, IP, 포트, 인바운드 태그 등의 조건으로 트래픽을 매칭해 아웃바운드나 밸런서를 지정합니다. 일반적으로 규칙은 목록 순서대로 적용되므로 앞쪽의 범위가 넓은 규칙이 뒤의 세부 규칙을 먼저 덮어쓸 수 있습니다. 문제를 확인할 때는 도메인이 목록에 있는지만 보지 말고 규칙 조건과 순서, 태그 참조를 함께 살펴보세요.

Split routing

트래픽 분기

조건에 따라 서로 다른 트래픽을 각기 다른 출구로 보내는 방식입니다. 예를 들어 내부 주소는 직접 연결하고 지정 도메인은 프록시로 보낼 수 있습니다. 분기 결과는 규칙 순서, 사용할 수 있는 도메인 정보, DNS 조회 결과, 기본 출구에 따라 달라집니다. 클라이언트의 ‘전역’이나 ‘규칙’ 모드는 서로 다른 계층을 가리킬 수 있으므로 메뉴 이름만으로 모든 앱의 실제 경로를 판단하지 마세요.

GeoIP / geoip:cn

GeoIP

라우팅 매칭에 사용하는 IP 주소 집합 데이터이며 보통 분류 태그로 참조합니다. IP 주소 집합만 매칭하므로 그 결과만으로 웹사이트 운영 주체나 도메인 소속 지역을 직접 판단할 수는 없습니다. DNS 결과 변경, 콘텐츠 전송 네트워크 사용 여부, 데이터 파일 차이에 따라 실제 매칭 결과가 달라질 수 있습니다.

GeoSite / geosite:cn

GeoSite

도메인 매칭에 사용하는 분류 데이터 집합으로, 관련 도메인을 하나의 규칙에 묶을 때 유용합니다. 분류 태그와 포함 항목은 실제로 불러온 데이터 파일에 따라 달라지므로 특정 태그가 항상 있다고 가정하면 안 됩니다. GeoSite는 도메인, GeoIP는 IP를 대상으로 합니다. 두 데이터는 함께 쓸 수 있지만 의미는 서로 다릅니다.

Domain Name System / dns.servers

DNS

도메인을 IP 주소 등의 레코드로 변환하는 시스템입니다. 코어 내장 리졸버와 운영체제 리졸버는 서로 다른 경로로 조회할 수 있습니다. dns.servers는 코어에서 사용할 수 있는 DNS 서버를 지정하지만 실제 호출 여부는 라우팅과 아웃바운드 정책에도 달려 있습니다. DNS 주소를 변경해도 앱의 모든 조회가 해당 리졸버를 자동으로 이용하는 것은 아닙니다.

FakeDNS / Synthetic IP

FakeDNS

도메인에 가상 IP를 할당하고 이후 연결이 들어오면 도메인 정보를 복원하는 메커니즘입니다. 가상 주소는 대상 서버의 실제 공인 IP가 아니므로 후속 트래픽도 매핑 정보를 이해하는 처리 경로를 거쳐야 합니다. DNS 응답만 바꾸고 연결을 함께 처리하지 않으면 주소에 연결할 수 없거나 매핑이 무효화될 수 있습니다.

DNS leak

DNS 누출

DNS 조회가 예상한 경로를 벗어나는 현상입니다. 예를 들어 지정한 출구를 통해 조회하려 했지만 다른 리졸버가 요청을 보낼 수 있습니다. 판단할 때는 웹페이지에 표시된 DNS 서버 위치만 보지 말고 실제 요청을 누가 어디로 보냈는지 확인하세요. 앱 자체 DNS, 암호화 DNS, 시스템 캐시, 앱별 설정도 관찰 결과에 영향을 줄 수 있습니다.

구독과 노드

설정 가져오기, 연결 테스트, 앱 트래픽 수신은 서로 다른 단계입니다. 테스트 결과는 사용한 방법과 현재 모드를 함께 고려해 해석해야 합니다.

Subscription / Subscription group

구독

링크를 통해 노드 설정을 가져와 일괄 등록하는 배포 방식입니다. 클라이언트는 보통 구독별 그룹으로 출처를 관리합니다. 업데이트하면 그룹 내 노드가 추가, 삭제 또는 교체될 수 있어 직접 수정한 노드 설정이 유지되지 않을 수도 있습니다. 구독 주소에 접속 정보가 포함될 수 있으므로 전체 링크를 스크린샷, 로그, 문의 글에 공개하지 마세요.

Node / Server profile

노드

클라이언트에서 프록시 연결을 설정하는 데 사용하는 매개변수 묶음으로, 보통 주소, 포트, 인증 정보, 프로토콜, 전송 설정이 포함됩니다. 표시 이름은 구분을 위한 메모일 뿐 서버 위치나 실제 연결 품질을 보장하지 않습니다. 노드를 가져오는 데 성공했다는 것은 클라이언트가 해당 형식을 인식했다는 뜻일 뿐이므로, 연결을 시작하고 로그를 확인해야 합니다.

Latency / TCP / ICMP

지연 시간

특정 테스트에 걸린 시간으로, 비교하려면 먼저 측정 방법을 밝혀야 합니다. TCP 연결은 포트 연결 가능성의 일부만 확인하며 ICMP 응답만으로 프록시 프로토콜의 인증 성공 여부를 알 수 없습니다. 테스트 대상과 네트워크 상태, 시간 초과 설정에 따라 결과가 달라지며 지연 시간이 짧다고 다운로드 속도가 빠른 것은 아닙니다.

Real connection latency

실제 연결 지연 시간

클라이언트에서 이 이름은 보통 노드를 통해 테스트 주소로 실제 요청을 보냈을 때 걸리는 시간을 뜻합니다. DNS 조회, 연결 재사용, 핸드셰이크가 포함되는지는 클라이언트 구현과 테스트 설정에 따라 다릅니다. 테스트에 성공하면 당시 해당 대상에 요청이 완료됐다는 의미지만 다른 웹사이트나 앱, 이후 연결까지 같은 결과를 보장하지는 않습니다.

System proxy

시스템 프록시

운영체제가 앱에 제공하는 프록시 설정으로, 보통 해당 설정을 따르는 요청을 로컬 클라이언트 포트로 보냅니다. 일부 앱은 자체 프록시 설정을 사용하거나 직접 연결하므로 시스템 프록시를 켜도 모든 트래픽이 처리되는 것은 아닙니다. 시스템 프록시는 트래픽이 클라이언트에 들어오는지를 정하며, 들어온 뒤의 출구는 코어 라우팅 등의 설정에 따라 결정됩니다.

TUN / Virtual network interface

TUN 모드

가상 네트워크 인터페이스로 IP 패킷을 처리해 시스템 프록시 설정을 따르지 않는 일부 트래픽도 다룰 수 있는 실행 방식입니다. 실제로 수신되는 범위는 시스템 라우팅, 권한, DNS 처리, 클라이언트 구현에 따라 달라집니다. 이 모드를 켜면 모든 연결이 프록시 출구를 이용한다고 볼 수는 없습니다. 사용 후 문제가 생기면 다른 가상 인터페이스, 라우팅 충돌, 앱별 설정을 확인하세요.