V2Ray 용어집: 프로토콜, 코어 및 라우팅 개념

VMess는 Project V 생태계에서 클라이언트와 서버 간 통신에 사용하는 프로토콜로, 인증, 시간 검증과 데이터 전송 방식을 포함합니다. 설정을 가져올 때는 일반적으로 서버 주소, 포트, 사용자 식별자, 전송 방식과 보안 매개변수가 필요합니다.

시스템 시간 오차가 크거나 사용자 식별자가 일치하지 않거나 전송 계층 설정이 맞지 않으면 연결 구성에 실패할 수 있습니다. VMess는 연결 설정의 일부만 정의하므로 TLS, WebSocket 등의 외부 옵션도 별도로 확인해야 합니다.

VLESS는 구조가 간결한 연결 프로토콜로, 전송 콘텐츠를 추가로 암호화하지 않으며 보안 기능은 일반적으로 TLS 또는 REALITY 같은 외부 메커니즘에 맡깁니다. 일반적인 설정 필드에는 사용자 식별자, 전송 유형, 흐름 제어와 서버 이름이 포함됩니다.

VLESS와 VMess는 필드 구조가 다르므로 프로토콜 이름만 바꿔 변환할 수 없습니다. 문제를 점검할 때는 인증 정보, 외부 보안 방식과 전송 매개변수를 각각 확인해야 합니다.

Trojan은 비밀번호로 연결을 인증하고 일반적으로 TLS와 함께 전송 채널을 구성합니다. 클라이언트 설정에서는 서버 주소, 포트, 비밀번호, 서버 이름과 인증서 관련 옵션을 확인해야 합니다.

비밀번호가 맞아도 연결이 반드시 성립하는 것은 아닙니다. 도메인, 포트와 TLS 매개변수도 서버와 일치해야 합니다. 핸드셰이크 오류가 발생하면 클라이언트 로그의 인증서 이름과 연결 단계 메시지를 먼저 확인하세요.

REALITY는 Xray 생태계의 전송 보안 구현으로, VLESS와 함께 사용하는 경우가 많습니다. 설정에는 일반적으로 공개 키, 짧은 식별자, 서버 이름, 지문과 흐름 제어 등의 필드가 포함됩니다.

각 필드는 서로 다른 역할을 하므로 일반 TLS 설정으로 대체할 수 없습니다. 노드를 가져온 뒤 연결에 실패하면 공개 키, 짧은 식별자와 서버 이름을 항목별로 대조해 클라이언트가 자동 입력한 값이 원래 설정과 다른지 확인해야 합니다.

Project V는 네트워크 프록시 코어, 프로토콜과 도구를 중심으로 형성된 오픈 소스 기술 생태계를 의미합니다. V2Ray 설정 모델에는 인바운드, 아웃바운드, 라우팅, DNS와 전송 등의 모듈이 포함되며 이후 여러 코어와 클라이언트가 이 개념을 이어받았습니다.

특정 그래픽 클라이언트의 이름이 아닙니다. 문서를 읽을 때 생태계 이름, 코어 이름과 클라이언트 이름을 구분해야 인터페이스 기능을 프로토콜 자체의 능력으로 오해하지 않을 수 있습니다.

V2Fly는 V2Ray의 기술 계보를 이어가는 커뮤니티 유지 코어와 관련 프로젝트 모음입니다. 일부 클라이언트는 V2Fly 코어로 설정을 해석하고 연결을 구성하며 라우팅 규칙을 실행합니다.

같은 기본 설정이라도 코어 버전에 따라 지원되는 필드가 다를 수 있습니다. 클라이언트 업그레이드 후 기존 설정에 문제가 생기면 먼저 현재 사용하는 코어와 해당 설정 문법을 확인해야 합니다.

Xray는 V2Ray 설정 체계와 높은 호환성을 가진 코어 계열로, VMess, VLESS, Trojan과 REALITY 등의 프로토콜 또는 보안 메커니즘을 지원합니다. v2rayN과 v2rayNG는 Xray 코어를 사용해 연결을 처리할 수 있습니다.

호환된다고 해서 모든 필드가 완전히 같은 것은 아닙니다. 흐름 제어, 전송 보안 또는 실험적 기능을 사용할 때는 현재 코어가 인식할 수 있는 설정 구조를 기준으로 해야 합니다.

v2ray-core는 실제 네트워크 처리를 담당하는 핵심 프로그램으로, 설정을 해석하고 인바운드·아웃바운드를 생성하며 DNS 조회와 라우팅 규칙 매칭을 수행합니다. 그래픽 클라이언트는 일반적으로 시작 매개변수나 설정 파일을 통해 코어를 제어합니다.

인터페이스가 정상적으로 열렸다는 것은 클라이언트 프로세스가 실행될 수 있다는 의미일 뿐, 코어가 성공적으로 시작되었다는 뜻은 아닙니다. 연결 문제를 점검하려면 클라이언트 상태, 코어 로그와 로컬 수신 포트를 함께 확인해야 합니다.

구독은 서버에서 제공하는 설정 모음 주소로, 클라이언트가 이 주소를 통해 노드 목록을 가져올 수 있습니다. 구독을 업데이트하면 클라이언트가 원격 콘텐츠를 요청하고 지원되는 형식으로 해석해 로컬 설정으로 저장합니다.

구독 업데이트 성공은 주소에 접근할 수 있고 콘텐츠를 읽을 수 있다는 뜻일 뿐, 목록의 모든 노드에 연결할 수 있다는 의미는 아닙니다. 업데이트에 실패하면 주소의 완전성, 시스템 시간, 네트워크 경로와 클라이언트 로그를 확인해야 합니다.

노드는 클라이언트에 저장된 개별 연결 설정으로, 서버 주소, 포트, 프로토콜, 인증 정보, 전송 매개변수와 표시 이름을 기록합니다. 노드를 선택하면 코어가 이 필드에 따라 해당 아웃바운드를 구성합니다.

노드 이름은 관리하기 편하도록 붙이는 라벨일 뿐 프로토콜 유형이나 회선 품질을 직접 나타내지 않습니다. 설정을 복사할 때는 전체 필드를 보존해야 하며 이름과 서버 주소만 복사해서는 안 됩니다.

지연 시간은 데이터가 로컬에서 대상까지 갔다가 돌아오는 데 걸리는 시간으로, 일반적으로 밀리초 단위로 기록합니다. 클라이언트의 지연 테스트는 포트 탐지, 기본 네트워크 요청 또는 프록시 요청을 사용할 수 있으므로 방식이 다른 결과를 직접 비교할 수 없습니다.

지연 시간이 짧다고 반드시 다운로드 속도가 빠른 것은 아닙니다. 대역폭, 패킷 손실, 서버 부하와 대상 사이트의 응답이 실제 사용 경험에 영향을 줍니다. 노드를 선택할 때는 연결 성공률과 실제 접속 결과를 함께 확인해야 합니다.

실제 연결 지연 시간은 일반적으로 클라이언트가 선택한 노드를 통해 실제 프록시 연결을 구성한 뒤 지정된 대상에 요청을 보내 응답 시간을 기록한 값을 의미합니다. 프로토콜 핸드셰이크, 전송 구성과 대상 응답 등 더 많은 단계를 반영합니다.

테스트 결과는 테스트 주소, 네트워크 변동과 캐시 상태의 영향도 받으므로 같은 시간대의 상대적 비교에 적합합니다. 한 번의 시간 초과만으로 설정이 무효라고 판단하지 말고 로그와 함께 다시 확인해야 합니다.

라우팅 규칙은 도메인, IP, 포트, 네트워크 유형, 프로토콜 또는 프로세스 등의 조건에 따라 트래픽이 사용할 아웃바운드를 결정합니다. 일반적인 아웃바운드에는 직접 연결, 프록시와 차단이 있으며 구체적인 이름은 클라이언트나 설정 파일에서 정합니다.

규칙은 일반적으로 순서대로 매칭되므로 앞의 포괄적인 조건이 뒤의 규칙을 무효화할 수 있습니다. 규칙을 수정할 때는 먼저 기본 출구를 확인한 뒤 구체적인 조건에서 일반적인 조건 순으로 배치하고 하나씩 테스트해야 합니다.

라우팅은 서로 다른 대상, 애플리케이션 또는 네트워크 유형을 서로 다른 아웃바운드에 배분하는 과정입니다. 별도의 프로토콜이 아니라 라우팅 규칙, DNS 해석과 아웃바운드 설정이 함께 만들어 내는 결과입니다.

일반적인 라우팅 기준에는 도메인 유형, IP 지역, 포트와 프로세스 이름이 포함됩니다. 규칙이 충돌하면 실제로 적중한 조건을 확인하고 도메인이 매칭 전에 IP로 해석되었는지도 확인해야 합니다.

GeoIP는 IP 주소의 지역 또는 네트워크 유형별로 정리한 데이터 집합으로, 라우팅 규칙에서 매칭 조건으로 참조할 수 있습니다. 대상이 이미 IP 주소로 표현된 연결을 처리하는 데 적합합니다.

GeoIP 데이터는 실시간 조회 결과가 아니므로 데이터베이스 버전과 주소 소속 변경에 따라 분류가 달라질 수 있습니다. 라우팅 결과가 예상과 다르면 데이터 파일이 클라이언트에 정상적으로 로드되었는지와 규칙 태그가 존재하는지 확인해야 합니다.

GeoSite는 웹사이트 도메인 유형별로 정리한 규칙 데이터 집합으로, 도메인 수준의 라우팅 매칭에 사용할 수 있습니다. 각 분류에는 도메인, 하위 도메인 또는 매칭 표현식이 포함되며 라우팅 규칙에서 태그로 참조합니다.

GeoSite와 GeoIP는 판단 대상이 다릅니다. 전자는 도메인을 처리하고 후자는 IP를 처리합니다. 애플리케이션이 IP에 직접 연결하면 GeoSite 규칙만으로는 매칭되지 않을 수 있습니다.

v2rayN은 Windows, macOS와 Linux에서 사용하는 그래픽 클라이언트로, 구독, 노드, 시스템 프록시, TUN 모드, DNS와 라우팅 설정을 관리할 수 있습니다. 자주 사용하는 설정 작업을 인터페이스로 구성하고 선택한 코어를 호출해 실제 연결을 처리합니다.

문제를 점검할 때는 인터페이스 설정, 코어 시작 여부와 시스템 프록시 상태를 구분해야 합니다. 클라이언트에 노드가 선택되어 있어도 애플리케이션 트래픽이 해당 로컬 프록시 입구로 들어갔다는 뜻은 아닙니다.

TUN 모드는 가상 네트워크 인터페이스로 시스템 트래픽을 받은 뒤 라우팅 및 DNS 설정에 따라 코어에서 처리합니다. 시스템 프록시 설정을 읽지 않는 일부 프로그램에도 적용할 수 있어 트래픽을 통합적으로 관리해야 하는 환경에 적합합니다.

TUN 모드를 활성화하려면 일반적으로 시스템 권한, 가상 인터페이스, 라우팅 테이블과 DNS 설정이 필요합니다. 인터넷이 끊기면 먼저 모드를 꺼서 기본 네트워크를 복구한 뒤 권한, 인터페이스 충돌과 우회 규칙을 확인해야 합니다.

시스템 프록시는 운영체제가 애플리케이션에 제공하는 프록시 주소와 포트 설정입니다. 브라우저와 일부 데스크톱 프로그램은 이 설정을 따라 클라이언트가 연 HTTP 또는 SOCKS 입구로 요청을 전달합니다.

모든 프로그램이 시스템 프록시를 읽는 것은 아니므로 활성화 후에도 직접 연결하는 애플리케이션이 있을 수 있습니다. 적용 여부를 확인하려면 시스템 설정, 로컬 포트와 대상 프로그램 자체의 프록시 옵션을 함께 확인해야 합니다.

FakeDNS는 애플리케이션에 매핑된 주소를 반환하고 코어에 해당 주소와 원래 도메인 사이의 대응 관계를 보존합니다. 이를 통해 투명 프록시 또는 TUN 환경에서도 코어가 도메인에 따라 라우팅을 판단할 수 있습니다.

FakeDNS는 DNS 인바운드, 주소 풀과 라우팅 설정을 함께 구성해야 합니다. 주소 풀 충돌, 코어에 조회가 전달되지 않는 문제 또는 매핑 정보 손실로 인해 해석이나 연결 오류가 발생할 수 있습니다.

DNS는 도메인을 IP 주소로 변환하는 기본 네트워크 서비스입니다. V2Ray 코어는 여러 DNS 서버, 조회 프로토콜, 도메인 규칙과 주소 선택 정책을 설정할 수 있으며 해석 결과를 라우팅 판단에 사용합니다.

DNS 조회가 성공했다고 해서 대상 연결까지 반드시 성공하는 것은 아닙니다. 두 작업은 서로 다른 단계입니다. 문제를 점검할 때는 도메인 해석 가능 여부, 결과가 예상과 맞는지와 어떤 아웃바운드로 연결했는지를 각각 확인해야 합니다.

DNS 누수는 지정된 클라이언트 경로 또는 DNS 서버에서 처리해야 할 도메인 조회가 실제로 다른 해석 경로로 전달되는 현상입니다. 흔한 원인으로 애플리케이션 자체 DNS, 시스템 대체 경로, 브라우저의 독립 설정과 라우팅 우회가 있습니다.

점검할 때는 시스템 DNS, 클라이언트 수신 창구, TUN 설정, 브라우저 구성과 로그에 기록된 조회 경로를 함께 확인해야 합니다. DNS 주소 하나만 바꾼다고 모든 애플리케이션이 같은 경로를 사용하는 것은 아닙니다.

SOCKS는 범용 프록시 인터페이스 프로토콜로, 애플리케이션이 TCP 또는 UDP 연결을 지정된 서버에 전달할 수 있습니다. V2Ray 클라이언트는 수동 프록시 설정을 지원하는 소프트웨어를 위해 로컬에 SOCKS 인바운드를 여는 경우가 많습니다.

SOCKS 주소는 일반적으로 로컬 루프백 주소와 수신 포트를 가리킵니다. 애플리케이션에 잘못된 포트를 입력했거나 클라이언트가 실행되지 않았거나 포트가 점유된 경우, 노드 프로토콜에 도달하기 전에 연결이 실패합니다.

로컬 수신 포트는 클라이언트가 로컬에서 열어 애플리케이션 연결을 받는 포트입니다. 예를 들어 SOCKS 또는 HTTP 프록시 포트가 있습니다. 시스템 프록시 설정의 포트는 클라이언트가 실제로 수신 중인 값과 일치해야 합니다.

포트를 다른 프로그램이 사용 중이면 코어가 해당 인바운드를 시작하지 못할 수 있습니다. 시작 로그를 확인하고 사용하지 않는 포트로 변경한 뒤 해당 포트를 참조하는 모든 애플리케이션 설정도 업데이트해야 합니다.