V2Ray / 설정 용어

V2Ray 용어집

프로토콜은 연결 방식을 정하고 코어는 이를 실행하며 클라이언트는 설정을 관리합니다. 다섯 가지 범주에서 용어를 찾아 각 설정의 역할을 구분하고 실제 매개변수를 확인하세요.

용어 26개 프로토콜·코어 · 연결·트래픽 분기 · 테스트·DNS 조회

클라이언트를 설정 중인가요? 먼저 시스템 프록시와 라우팅 규칙을 확인하세요. 설정을 가져오려면 구독 링크와 공유 링크부터 살펴보세요.

PROTOCOL / TRANSPORT

프로토콜·전송 방식

노드 유형은 설정의 한 부분일 뿐입니다. 프록시 프로토콜, 전송 방식, 연결 보안은 각각 서버 설정과 일치해야 합니다.

프로토콜·전송 방식VMess: VMess는 Project V 생태계의 프록시 프로토콜로, 인증과 데이터 암호화 기능을 포함하며 UUID로 사용자를 식별하는 경우가 많습니다. VMess와 TCP, WebSocket 같은 전송 방식은 서로 다른 계층이므로 설정을 가져올 때 프로토콜 이름만 확인해서는 안 됩니다. 일부 인증 과정은 시간에 의존하므로 시스템 시각이 맞지 않으면 연결에 실패할 수 있습니다. 새 설정은 보통 AEAD 방식을 사용하므로 오래된 가이드의 매개변수를 그대로 적용하지 않는 것이 좋습니다.
프로토콜·전송 방식VLESS: VLESS는 Xray 생태계에서 널리 쓰이는 경량 프록시 프로토콜입니다. 일반적으로 VLESS 자체만으로 연결을 보호하지 않고 TLS 또는 REALITY를 함께 사용합니다. UUID, 전송 방식, 서버 이름, 필요한 경우 flow까지 서버 설정과 일치해야 합니다. VLESS 유형이 같아도 설정을 서로 바꿔 쓸 수 있는 것은 아니므로, 코어가 해당 매개변수 조합을 모두 인식하는지 확인해야 합니다.
프로토콜·전송 방식Trojan: Trojan은 일반적으로 TLS 연결 위에서 동작하며 프록시 계층의 인증에 비밀번호를 사용합니다. 비밀번호는 사용자를 인증하고, 서버 이름과 인증서 검증은 TLS 연결 대상이 맞는지 확인하므로 서로 대체할 수 없습니다. 인증서 오류가 발생하면 도메인, 시스템 시각, 인증서 설정부터 확인하세요. 인증서 검증을 건너뛰는 설정을 상시 사용해서는 안 됩니다.
프로토콜·전송 방식Shadowsocks (SS): Shadowsocks는 암호화 프록시를 중심으로 한 프로토콜 계열이며, 클라이언트에서는 흔히 SS로 줄여 부릅니다. 암호화 방식과 비밀번호는 서버 요구 사항에 맞아야 하며, AEAD와 최신 프로토콜 변형도 서로 혼용할 수 없습니다. 암호화 방식, UDP, 확장 기능의 지원 여부는 코어 구현에 따라 다르므로 SS 유형을 확인한 뒤에도 나머지 필드를 점검해야 합니다.
프로토콜·전송 방식REALITY: REALITY는 Xray의 연결 보안 방식으로 VLESS와 함께 사용하는 경우가 많습니다. 프록시 프로토콜을 단독으로 대체하는 노드 유형은 아닙니다. 공개 키, 서버 이름, shortId 등의 매개변수는 서버 설정과 일치해야 하며, 다른 설정에서 임의로 가져와 조합해서는 안 됩니다. 클라이언트에 관련 입력란이 표시된다고 해서 현재 실행 중인 코어가 해당 조합을 지원하는 것은 아닙니다.

프로토콜 및 코어 선택 가이드 보기 →

PROJECT / CORE

코어·생태계

그래픽 클라이언트와 프록시 코어는 별개의 프로그램입니다. 인터페이스가 비슷하더라도 지원 기능과 설정 형식까지 모두 같다는 뜻은 아닙니다.

코어·생태계Project V: Project V는 모듈형 네트워크 프록시 도구를 중심으로 형성된 프로젝트 및 기술 생태계이며, V2Ray는 그 주요 구성 요소입니다. 특정 데스크톱 또는 Android 클라이언트의 이름도 아니고, 노드 유형에 직접 입력할 수 있는 프로토콜도 아닙니다. 문서를 볼 때는 어떤 코어와 설정 형식, 그래픽 클라이언트의 설정 화면을 기준으로 하는지 확인해야 합니다.
코어·생태계V2Fly: V2Fly는 V2Ray의 개발을 이어가는 커뮤니티 프로젝트이며, 코어가 프로토콜 연결, 라우팅, DNS 등을 처리합니다. v2flyNG는 이 코어 생태계를 기반으로 만든 Android 클라이언트입니다. 프로젝트와 클라이언트 이름을 구분해서 이해해야 합니다. V2Fly와 Xray는 일부 설정 개념을 공유하지만, 독자적으로 발전한 필드와 기능까지 호환된다고 단정해서는 안 됩니다.
코어·생태계Xray: Xray는 V2Ray 기술 기반에서 출발해 독자적인 기능과 설정으로 발전했으며, REALITY 같은 기능에는 이를 지원하는 코어가 필요합니다. v2rayNG는 Xray 코어를 사용하며, v2rayN의 실제 처리 기능은 선택한 코어와 버전을 확인해야 합니다. 코어를 바꾸면 연결 매개변수, 라우팅 동작, 로그 내용이 달라질 수 있으므로 인터페이스가 같은지만 비교해서는 안 됩니다.
코어·생태계코어 (Core): 코어는 프록시 프로토콜, 연결 처리, 라우팅, DNS 설정을 실제로 실행하는 프로그램이며, 그래픽 클라이언트는 설정을 정리해 코어를 호출합니다. 문제를 해결할 때 설정이 인터페이스에 저장되었다는 사실만으로는 충분하지 않습니다. 코어가 정상적으로 시작되는지도 확인해야 합니다. 클라이언트 버전과 코어 버전은 별개의 정보이므로 호환성 문제를 제보할 때 둘 다 기록하세요. 인터페이스에 항목이 없는 문제와 코어 오류를 혼동하지 않도록 주의해야 합니다.

CLIENT / INBOUND

클라이언트 기능

앱 트래픽이 처리 경로에 어떻게 들어오는지 먼저 확인하세요. 시스템 프록시, 가상 네트워크 인터페이스, 앱별 설정은 각각 적용 범위가 다릅니다.

클라이언트 기능시스템 프록시: 시스템 프록시는 운영체제에 로컬 프록시 주소를 등록하며, 주로 해당 설정을 따르는 앱에 적용됩니다. 모든 네트워크 트래픽을 가로채는 것은 아닙니다. v2rayN의 시스템 프록시 자동 설정과 해제는 연결 진입점을 변경하는 기능이지 서버 자체를 바꾸는 기능이 아닙니다. 앱 자체의 프록시 설정이 시스템 설정을 덮어쓸 수도 있습니다. 코어에 들어온 연결을 프록시로 보낼지 직접 연결할지는 라우팅 규칙에서 결정됩니다.
클라이언트 기능TUN 모드: TUN 모드는 가상 네트워크 인터페이스를 통해 IP 패킷을 받아 시스템 프록시 설정을 따르지 않는 앱의 트래픽 일부도 처리할 수 있습니다. 실제 적용 범위는 시스템 라우팅, 실행 권한, 제외 규칙, 클라이언트 구현에 따라 달라지므로 스위치 상태만으로 판단할 수 없습니다. 활성화 후 DNS 문제가 생기면 DNS 가로채기 설정과 다른 가상 네트워크 인터페이스도 함께 확인해 여러 구성 요소가 같은 경로를 두고 충돌하지 않도록 하세요.
클라이언트 기능VpnService: VpnService는 Android에서 가상 네트워크 인터페이스를 제공하는 서비스 방식입니다. v2rayNG는 이를 통해 앱 트래픽을 받아 코어로 전달할 수 있습니다. 시스템의 VPN 권한 안내는 해당 인터페이스를 만들도록 허용하는 것이며, 모든 연결이 원격 서버로 전달된다는 뜻은 아닙니다. 같은 기기의 다른 VPN 서비스와 충돌할 수 있으며, 백그라운드 연결이 끊기면 시스템의 배터리 절약 제한도 확인해야 합니다.
클라이언트 기능앱별 프록시: 앱별 프록시는 앱 트래픽을 클라이언트의 프록시 처리 경로에 포함할지 정하는 기능입니다. 선택한 앱만 처리하거나 선택한 앱을 우회하는 방식이 일반적입니다. 목록의 의미는 현재 모드에 따라 달라지므로 앱을 선택하기 전에 화면 안내를 확인하세요. 앱을 처리 대상으로 지정해도 라우팅 규칙에 따라 직접 연결될 수 있습니다. 따라서 앱별 목록과 도메인 트래픽 분기 규칙은 따로 점검해야 합니다.
클라이언트 기능인바운드 (Inbound): 인바운드는 코어가 연결을 받는 진입 지점입니다. 일반적으로 로컬 HTTP 또는 SOCKS 리스너를 설정하며, 주소와 포트, 프로토콜에 따라 앱의 연결 방식이 결정됩니다. 앱에 입력하는 로컬 프록시 포트는 실제 인바운드 설정과 일치해야 하며, 서버 포트를 입력해서는 안 됩니다. 루프백 주소로 수신하면 보통 해당 기기에서만 접속할 수 있습니다. 다른 네트워크 인터페이스에 공개하기 전에는 접근 제어와 네트워크 노출 범위를 고려하세요.

클라이언트 설치 및 연결 방법 보기 →

SUBSCRIPTION / TEST

구독·노드

구독은 설정을 가져오는 출처이고, 노드는 개별 설정 항목이며, 테스트 결과는 특정 조건에서 측정한 값입니다. 서로 대체할 수 없습니다.

구독·노드구독 링크: 구독 링크는 서버 설정 목록을 가져오는 주소입니다. 클라이언트에서 구독을 업데이트하면 내용을 다시 요청하고 자체 규칙에 따라 노드를 정리합니다. 구독 서비스가 반환하는 형식은 클라이언트에서 인식할 수 있어야 하며, 아무 웹 주소나 구독으로 가져올 수 있는 것은 아닙니다. 주소에 접근 자격 증명이 포함될 수 있으므로 민감 정보로 취급하세요. 업데이트 전에 직접 수정한 노드 매개변수가 덮어써지는지도 확인해야 합니다.
구독·노드노드: 노드는 클라이언트에서 선택할 수 있는 서버 설정을 흔히 부르는 말입니다. 주소, 포트, 인증 정보, 전송 방식, 연결 보안 매개변수가 포함됩니다. 표시 이름 하나가 서버 한 대를 뜻한다고 볼 수 없으며, 같은 주소에서도 포트나 매개변수에 따라 서로 다른 연결 지점을 제공할 수 있습니다. 설정의 중복이나 오류를 판단하려면 이름만 보지 말고 실제 필드와 연결 로그를 비교해야 합니다.
구독·노드공유 링크: 공유 링크는 보통 vmess://, vless:// 등의 형식으로 서버 설정 하나를 담아 복사하거나 QR 코드로 가져올 수 있게 합니다. 설정을 계속 가져오는 구독 주소와 달리, 한 번 가져오면 이후 변경 사항이 자동으로 반영되지 않습니다. 링크에 인증 정보가 포함될 수 있으므로 전달 전에 접근 권한을 확인하세요. 다른 클라이언트로 가져온 뒤에는 확장 매개변수가 온전히 유지되었는지도 점검해야 합니다.
구독·노드지연 시간: 지연 시간은 테스트를 시작해 지정된 응답을 받기까지 걸린 시간입니다. 측정 방법과 함께 봐야 의미가 있습니다. ICMP ping은 네트워크 계층의 왕복 시간을 측정하고, TCP 테스트는 주로 포트 핸드셰이크를 확인하며, 앱 요청 테스트에는 프로토콜 협상과 대상 서버의 응답도 포함될 수 있습니다. 지연 시간이 짧다고 다운로드 속도가 빠른 것은 아닙니다. 노드를 비교할 때는 테스트 대상과 방법, 시간을 가능한 한 동일하게 맞추세요.
구독·노드실제 연결 지연: 실제 연결 지연은 현재 프록시 설정으로 테스트 대상에 실제 요청을 보낼 때 걸리는 시간을 뜻하는 경우가 많습니다. 구체적인 측정 범위는 클라이언트 구현에 따라 다릅니다. 도메인 조회, 프로토콜 핸드셰이크, 대상 사이트 응답, 연결 재사용 여부의 영향을 받을 수 있으므로 순수한 회선 지연으로 볼 수 없습니다. 테스트에 실패해도 노드가 반드시 작동하지 않는 것은 아닙니다. 먼저 테스트 대상과 로컬 설정의 영향을 확인하세요.

ROUTING / RESOLUTION

라우팅·DNS

규칙을 적용하려면 매칭할 정보가 필요합니다. 도메인이 유지되는지, 언제 IP로 조회되는지, 조회 요청이 어디서 전송되는지가 모두 트래픽 분기 결과에 영향을 줍니다.

라우팅·DNS라우팅 규칙: 라우팅 규칙은 도메인, IP, 포트 등의 조건에 따라 연결의 아웃바운드를 선택합니다. V2Ray와 Xray의 일반적인 규칙은 위에서 아래 순서로 매칭됩니다. 규칙의 outboundTag는 정의된 아웃바운드 태그와 일치해야 합니다. 한 규칙 안의 여러 조건은 보통 모두 충족해야 합니다. 규칙을 조정하기 전에 순서와 매칭 대상을 확인해 범위가 넓은 규칙이 연결을 먼저 가져가는 일을 방지하세요.
라우팅·DNS트래픽 분기: 트래픽 분기는 연결마다 프록시, 직접 연결, 차단 등의 아웃바운드를 선택하는 처리 방식이지 별도의 프로토콜이 아닙니다. 실제 결과는 트래픽 유입 범위, 규칙 순서, 도메인 정보, DNS 설정에 따라 달라집니다. 특정 앱이 잘못된 경로로 나갈 때는 먼저 앱 트래픽이 코어에 들어오는지 확인한 뒤 적용된 규칙을 살펴보세요. 노드만 바꿔서는 기존 직접 연결 규칙이 바뀌지 않습니다.
라우팅·DNSGeoIP: GeoIP는 태그로 분류된 IP 주소 집합을 뜻하며, 라우팅에서 geoip:private 같은 표현식으로 해당 데이터를 참조할 수 있습니다. 태그의 존재 여부와 포함된 주소는 규칙 데이터와 코어 지원에 따라 달라집니다. IP의 등록 위치가 회선 품질을 뜻하는 것은 아니며 서비스의 실제 운영 위치와 다를 수도 있습니다. 도메인 연결이 IP 매칭에 사용되는지는 DNS 조회 방식에도 영향을 받습니다.
라우팅·DNSGeoSite: GeoSite는 태그별로 구성한 도메인 집합으로, IP 주소로 매칭하는 GeoIP와 다릅니다. 표현식에 사용할 태그는 규칙 데이터 파일에 정의되어 있으므로 웹사이트 이름만 보고 태그를 짐작해도 적용된다고 볼 수 없습니다. 규칙이 대상 IP만 확인하고 도메인을 전달받지 못하면 도메인 집합과 매칭되지 않을 수 있습니다. 인바운드가 제공하는 정보와 스니핑 설정을 함께 확인하세요.
라우팅·DNSDNS: DNS는 도메인을 IP 등의 레코드로 변환하며, 앱, 운영체제, 프록시 코어가 각각 조회를 요청할 수 있습니다. 코어의 DNS 설정이 시스템의 모든 조회를 처리하는 것은 아닙니다. 브라우저에 내장된 암호화 DNS가 별도의 조회 경로를 만들 수도 있습니다. 문제를 확인할 때는 DNS 주소만 보지 말고 요청 주체, 조회 대상 서버, 조회 연결에 적용되는 아웃바운드를 각각 확인해야 합니다.
라우팅·DNSFakeDNS: FakeDNS는 앱에 매핑된 주소를 반환하고 내부적으로 해당 주소와 원래 도메인의 대응 관계를 보존해 이후 연결에서 도메인을 복원합니다. 트래픽 가로채기와 매핑 식별 절차가 함께 작동해야 하며, 임의의 공용 DNS 서버 주소처럼 입력하는 기능이 아닙니다. 앱에 매핑 주소가 캐시된 상태에서 관련 기능이 꺼지거나 매핑 정보가 사라지면 연결에 문제가 생길 수 있습니다.
라우팅·DNSDNS 누수: DNS 누수는 조회 요청이 예상한 해석 경로를 거치지 않는 현상입니다. 예를 들어 지정된 경로에서 처리해야 할 요청이 로컬 네트워크의 DNS 서버로 전달될 수 있습니다. 이상 여부는 실제 정책을 기준으로 판단해야 하며, 검사 결과에 여러 DNS 서버가 표시된다고 반드시 문제가 있는 것은 아닙니다. 시스템 DNS, 앱의 암호화 DNS, 트래픽 가로채기 범위, 코어 로그를 함께 확인하세요. 노드만 바꿔서는 모든 DNS 조회 경로가 자동으로 수정되지 않습니다.

프로토콜 및 코어 가이드 더 읽기 → 문제별 FAQ 찾기 →