V2Ray 설정 개념 색인

V2Ray 용어 가이드: 프로토콜, 코어, 구독 및 라우팅

VMess, VLESS와 REALITY부터 구독, 노드, TUN 모드, GeoSite와 실행 로그까지, 설정 흐름에 따라 자주 쓰이는 용어를 설명합니다. 각 항목에서 개념의 범위, 해당 계층과 문제 해결 시의 실제 용도를 다루므로 v2rayN, v2rayNG와 v2flyNG의 화면 및 문서를 쉽게 연결해 이해할 수 있습니다.

6개 분류 28개 용어 프로토콜과 설정을 함께 설명

READING GUIDE

먼저 용어가 속한 계층을 확인하세요

그래픽 클라이언트, 코어, 프로토콜, 전송, 구독과 라우팅은 서로 같은 개념이 아닙니다. 연결 문제가 발생하면 설정 가져오기, 코어 시작, 프로토콜 핸드셰이크, DNS 확인, 트래픽 가로채기 중 어느 단계에서 문제가 생겼는지 먼저 판단한 뒤 관련 용어를 확인하는 편이 설정을 무작정 바꾸는 것보다 범위를 좁히기 쉽습니다.

설정 관리 계층

클라이언트, 구독 및 노드

그래픽 클라이언트는 설정을 저장하고 정리하며, 구독은 여러 노드를 제공하고, 노드는 하나의 구체적인 연결 기록입니다. 목록 업데이트가 성공했다는 것은 설정 데이터가 클라이언트에 들어왔다는 뜻일 뿐이며, 코어 로드와 실제 연결 확인이 추가로 필요합니다.

연결 실행 계층

코어, 프로토콜 및 전송

Xray 또는 V2Fly 코어가 클라이언트가 생성한 설정을 읽은 뒤 VMess, VLESS, Trojan 등의 프로토콜로 연결을 수립합니다. REALITY, TLS와 기타 전송 매개변수는 연결 구성의 일부이므로 관련 필드를 한 묶음으로 맞춰야 합니다.

트래픽 판단 계층

인바운드, 라우팅 및 아웃바운드

애플리케이션 트래픽은 먼저 시스템 프록시나 TUN 등을 통해 클라이언트로 들어오고, 라우팅 규칙이 대상을 판단한 뒤 직접 연결·프록시·차단 아웃바운드로 전달됩니다. 어느 한 계층이라도 예상대로 작동하지 않으면 최종 접속 결과에 영향을 줍니다.

PROTOCOLS

프로토콜 및 암호화

프로토콜은 클라이언트와 서버가 인증하고 데이터를 교환하는 방식을 결정하며, 전송 보안 방식은 핸드셰이크와 외부 연결 매개변수를 보완합니다. 설정을 가져올 때는 전체 필드 묶음을 하나의 구성으로 봐야 하며, 프로토콜 이름만으로 두 설정이 같은지 판단해서는 안 됩니다.

VMess: Project V 생태계에서 클라이언트와 서버가 통신할 때 사용하는 프로토콜입니다. 양쪽에서 사용자 식별자, 전송 방식, 포트와 보안 관련 매개변수를 일치시켜야 합니다. 클라이언트가 공유 내용을 인식한다고 해서 모든 매개변수가 유효하다는 뜻은 아니므로 사용 전에 연결 테스트를 완료해야 합니다.

VLESS: 구조가 비교적 간단한 프로토콜로, 보통 TLS, REALITY 또는 다른 전송 계층 설정과 함께 사용합니다. VLESS 자체가 완전한 연결 구성은 아니므로 주소, 포트, 사용자 식별자, 전송 유형과 외부 보안 필드를 함께 확인해야 합니다. 한 필드만 수정하면 기존 조합이 깨질 수 있습니다.

Trojan: 비밀번호를 주요 인증 정보로 사용하는 프록시 프로토콜이며, TLS와 함께 설정하는 경우가 많습니다. 클라이언트의 서버 주소, 포트, 비밀번호, 서버 이름과 전송 매개변수는 서버 설정과 일치해야 합니다. 인증서 이름, 시간 또는 인증 정보가 맞지 않으면 연결 수립 단계에서 중단될 수 있습니다.

REALITY: Xray 생태계의 전송 보안 방식으로, VLESS와 함께 사용하는 경우가 많습니다. 설정할 때 서버 이름, 공개 키, 짧은 ID, 지문 등의 필드를 확인해야 하며 주소와 포트만 입력해서는 충분하지 않습니다. 공유 링크가 불완전하게 해석되거나 클라이언트 코어가 너무 오래된 경우 관련 매개변수가 제대로 로드되지 않을 수 있습니다.

CORE & CLIENT

코어 및 클라이언트

클라이언트는 사용자가 조작하는 인터페이스이고 코어는 네트워크 작업을 실행하는 프로그램입니다. 두 구성 요소는 독립적으로 업데이트될 수 있으므로 인터페이스 버전, 코어 버전과 설정 형식을 각각 확인해야 하며, 모든 이상을 하나의 클라이언트 버전 문제로 볼 수는 없습니다.

Xray: V2Ray 생태계의 코어 구현 중 하나로, 설정을 해석하고 연결을 수립하며 라우팅과 DNS 처리를 담당합니다. v2rayN과 v2rayNG 같은 그래픽 클라이언트는 화면 설정을 코어가 읽을 수 있는 설정으로 변환합니다. 프로토콜 사용 가능 여부는 인터페이스에서 해당 필드를 제공하는지뿐 아니라 설정한 코어가 이를 지원하는지에도 달려 있습니다.

V2Fly: 커뮤니티에서 유지 관리하는 Project V의 후속 프로젝트이자 코어 계열입니다. Xray와 공통된 기술적 기반을 공유하지만, 프로토콜 지원 범위와 기능 구현, 업데이트 주기는 각각 확인해야 합니다. v2flyNG는 주로 V2Fly 코어 경로에 해당하며, 해당 코어를 명시적으로 요구하는 기존 설정에 적합합니다.

그래픽 클라이언트: 구독, 노드, 라우팅과 시스템 프록시를 관리하는 데스크톱 또는 모바일용 인터페이스 프로그램입니다. 그래픽 클라이언트가 모든 네트워크 처리를 직접 수행하는 것은 아니며 설정을 생성한 뒤 코어를 호출합니다. v2rayN은 데스크톱 플랫폼용이고 v2rayNG와 v2flyNG는 Android용이므로 화면 이름과 메뉴 위치가 다를 수 있습니다.

코어: 인바운드 리스닝, 아웃바운드 연결, DNS 조회와 라우팅 매칭을 실제로 수행하는 핵심 프로그램입니다. 클라이언트 인터페이스와 코어 버전은 별개의 계층이므로 인터페이스가 정상적으로 열려도 설정 오류로 코어 시작에 실패할 수 있습니다. 실행 로그를 확인하면 설정이 코어에 전달되어 수락되었는지 알 수 있습니다.

SUBSCRIPTION

구독 및 노드

구독은 설정을 일괄 배포하고 업데이트하는 문제를 해결하며, 노드는 선택할 수 있는 하나의 연결 기록입니다. 업데이트, 선택, 속도 측정과 연결은 이어지는 과정이지만 서로 다른 작업이므로 한 단계의 성공 표시가 다음 단계의 검증을 대신하지는 않습니다.

구독: 설정 제공자가 배포하는 노드 정보 묶음으로, 클라이언트가 구독 주소를 통해 가져와 업데이트합니다. 구독을 업데이트하면 로컬 노드 목록은 바뀌지만 현재 선택된 노드가 자동으로 전환되지는 않을 수 있습니다. 업데이트 전후의 그룹 이름이 같더라도 내부 노드 내용이 바뀌지 않았다고 단정할 수 없습니다.

노드: 클라이언트에 저장된 서버 연결 설정 하나로, 보통 주소, 포트, 프로토콜, 인증 정보와 전송 매개변수를 포함합니다. 목록에 노드가 표시된다는 것은 설정을 읽었다는 뜻일 뿐 연결 가능성을 보장하지 않습니다. 노드를 선택한 뒤 해당 프록시 모드를 시작하고 실제 요청으로 트래픽 경로를 확인해야 합니다.

구독 그룹: 여러 구독 출처와 노드를 분류해 관리하는 클라이언트 구조입니다. 그룹을 사용하면 설정 출처를 구분하고 업데이트, 활성화 또는 필터링 작업을 별도로 수행할 수 있습니다. 그룹을 삭제하면 해당 그룹의 로컬 노드도 함께 제거되는 경우가 많으므로 작업 전에 노드 출처를 확인해야 합니다.

구독 링크: 클라이언트가 구독 내용을 가져올 때 사용하는 주소입니다. 가져올 때 전체 문자열을 유지해야 하며, 일부가 누락되거나 앞뒤에 공백이 들어가거나 주소가 만료되면 업데이트에 실패합니다. 브라우저에서 주소가 열리는데 클라이언트 업데이트가 실패한다면 클라이언트의 네트워크 경로와 로그의 구체적인 응답도 확인해야 합니다.

ROUTING

라우팅 및 트래픽 분기

라우팅 규칙은 “클라이언트에 들어온 트래픽을 어디로 보낼지”를 처리합니다. 규칙 매칭과 트래픽 가로채기는 앞뒤의 별도 단계이므로 애플리케이션이 클라이언트로 들어오지 않으면 라우팅 규칙이 아무리 완전해도 판단에 참여하지 않습니다.

라우팅 규칙: 도메인, IP, 포트, 프로토콜 또는 프로세스 등의 조건에 따라 트래픽의 이동 경로를 결정하는 매칭 규칙입니다. 규칙은 일반적으로 순서대로 적용되므로 범위가 넓은 규칙을 앞에 두면 뒤의 구체적인 조건을 덮어쓸 수 있습니다. 규칙을 수정한 뒤 설정을 다시 로드하고 로그에서 어떤 아웃바운드가 매칭되었는지 확인해야 합니다.

트래픽 분기: 요청마다 직접 연결, 프록시 또는 차단 등의 아웃바운드 방식을 다르게 적용하는 설정 방법입니다. 결과는 규칙 순서, 도메인 확인 결과와 애플리케이션 트래픽이 클라이언트로 들어오는지 여부에 따라 달라집니다. 특정 사이트의 경로에 문제가 생기면 전체 설정을 다시 작성하기보다 먼저 매칭된 규칙을 찾아야 합니다.

GeoIP: IP 주소의 지리적 위치를 기준으로 매칭하는 데이터 집합입니다. 이미 확인된 IP에 적용되며, 매칭 정확도는 데이터베이스 버전과 주소 할당 변경의 영향을 받습니다. 도메인으로 요청할 때는 DNS 확인 결과도 이후 GeoIP 판단에 영향을 줍니다.

GeoSite: 도메인 범주별로 정리한 규칙 데이터 집합으로, 라우팅 규칙에서 여러 사이트 도메인을 한 번에 매칭하는 데 사용할 수 있습니다. GeoSite는 도메인 규칙을 처리하므로 IP를 기준으로 판단하는 GeoIP와 혼동해서는 안 됩니다. 코어가 원래 도메인을 전달받지 못하면 일부 도메인 기반 매칭이 예상대로 실행되지 않을 수 있습니다.

인바운드: 코어가 로컬 애플리케이션의 연결을 받는 쪽으로, 로컬 SOCKS·HTTP 리스닝 포트나 TUN 인터페이스가 그 예입니다. 애플리케이션이 먼저 적절한 인바운드로 들어와야 이후의 라우팅과 아웃바운드 규칙이 적용됩니다. 문제를 해결할 때는 로그에서 요청이 지정된 리스닝 포트에 도달했는지 확인할 수 있습니다.

아웃바운드: 코어가 처리한 트래픽을 전송하는 방식으로, 직접 연결, 선택한 노드를 통한 전달 또는 차단 등이 일반적입니다. 라우팅 규칙은 최종적으로 매칭된 요청을 특정 아웃바운드에 전달합니다. 아웃바운드 이름은 설정 식별자일 뿐이며, 실제 연결 방식은 내부에서 참조하는 노드나 동작이 결정합니다.

NETWORK

네트워크 기초

시스템 프록시, TUN과 DNS는 애플리케이션 요청을 클라이언트로 가져오고 필요한 대상 정보를 유지하는 역할을 합니다. 서로 연관되어 있지만 기능은 다르므로 프록시 적용 여부를 판단할 때 트래픽 진입점, 도메인 확인과 최종 아웃바운드를 각각 관찰해야 합니다.

TUN 모드: 가상 네트워크 인터페이스를 통해 더 많은 애플리케이션 트래픽을 가로채는 작동 모드입니다. 시스템 프록시 설정을 읽지 않는 프로그램에 유용하지만, 활성화한 뒤에는 권한, 라우팅 테이블, DNS와 다른 네트워크 도구 간의 충돌에도 주의해야 합니다. 클라이언트를 종료하기 전에 관련 설정을 복원하면 시스템 네트워크 상태가 남아 판단을 방해하는 일을 줄일 수 있습니다.

시스템 프록시: 운영 체제가 애플리케이션에 제공하는 프록시 설정입니다. 브라우저와 같은 프로그램은 보통 이 설정을 따르지만, 일부 명령줄 프로그램이나 자체 네트워크 스택을 사용하는 앱은 별도로 설정해야 할 수 있습니다. 클라이언트에 시스템 프록시가 켜져 있다고 표시되어도 리스닝 포트가 정상적으로 시작되었는지 확인해야 합니다.

FakeDNS: 먼저 도메인에 예약된 범위의 매핑 주소를 반환한 다음, 코어가 원래 도메인을 복원해 라우팅을 수행하는 DNS 처리 방식입니다. 도메인 정보를 유지하는 데 도움이 되지만 TUN, DNS와 라우팅 설정을 함께 구성해야 합니다. 매핑 주소는 대상 서버의 실제 주소가 아니므로 대상의 위치를 직접 판단하는 데 사용해서는 안 됩니다.

DNS 누출: 애플리케이션의 도메인 조회가 지정된 DNS 경로로 들어가지 않고 다른 리졸버에서 처리되는 현상입니다. 시스템 DNS, 브라우저 보안 DNS, TUN 적용 범위와 클라이언트 규칙을 함께 점검해야 합니다. 노드만 바꾸는 것으로는 확인 경로 설정이 서로 맞지 않는 문제를 해결하기 어렵습니다.

지연 시간: 로컬 장치에서 대상까지 한 번의 테스트를 완료하는 데 걸리는 시간으로, 보통 밀리초 단위로 표시합니다. 측정 방법마다 확인하는 구간이 다르므로 단순 네트워크 테스트 결과만으로 프로토콜 연결과 실제 요청 성능을 완전히 판단할 수는 없습니다. 지연 시간이 짧아도 처리량, 안정성 및 대상 접근성이 더 좋다는 뜻은 아닙니다.

실제 연결 지연 시간: 노드 프로토콜로 실제 연결을 수립하고 대상 요청까지 완료한 뒤 측정한 소요 시간입니다. 단순히 서버에 도달할 수 있는지만 확인하는 테스트보다 클라이언트 사용 경로에 가깝지만, 로컬 네트워크와 테스트 대상, 당시 경로 상태의 영향을 받습니다. 노드를 선택할 때 참고 자료로 활용하고 실제 접속 결과로 다시 확인하세요.

LOGS

로그 및 문제 해결

로그에 표시되는 영어 단어 하나는 대개 결과만 보여줄 뿐 원인을 단독으로 확정하기에는 부족합니다. 앞뒤 로그를 함께 확인하고 대상 주소, 아웃바운드 이름, 발생 시간과 방금 수정한 설정 항목을 기록해야 합니다.

로그 수준: 코어가 기록하는 정보의 상세도를 조절하는 설정으로, 일반 정보·경고·오류를 구분하는 데 사용합니다. 문제를 해결할 때는 DNS, 라우팅과 연결 과정을 확인할 수 있도록 일시적으로 상세도를 높이세요. 원인을 찾은 뒤에는 일반 수준으로 되돌려 불필요한 세부 정보가 중요한 오류를 가리지 않게 해야 합니다.

timeout: 특정 연결이나 요청이 제한 시간 안에 완료되지 않았다는 뜻입니다. 서버에 도달할 수 없거나 포트가 차단된 경우, DNS 이상, 전송 매개변수 불일치 또는 대상 응답 지연 때문에 발생할 수 있습니다. timeout 앞의 작업 단계를 함께 확인해 DNS 확인, 연결 수립, 응답 읽기 중 어느 과정에서 시간이 초과되었는지 판단해야 합니다.

rejected: 클라이언트 규칙, 원격 서비스 또는 대상 서버가 연결을 명확히 거부했다는 뜻입니다. 원인을 판단할 때는 해당 로그 앞뒤의 아웃바운드 이름, 대상 주소와 더 구체적인 오류 내용을 함께 확인해야 합니다. 특정 차단 규칙이 매칭되었다는 로그가 있다면 프로토콜 매개변수를 바로 바꾸기보다 먼저 라우팅을 점검해야 합니다.

invalid user: 일반적으로 서버가 인증 정보를 받아들이지 않았다는 뜻입니다. 사용자 식별자, 비밀번호, 시간 설정과 관련 프로토콜 필드를 확인해야 하며, 시스템 프록시 모드만 계속 바꾸는 것으로는 해결되지 않습니다. 구독 업데이트 후 기존 노드를 수동으로 남겨두면 이미 변경된 인증 정보를 계속 사용할 수도 있습니다.

NEXT STEP

용어를 실제 설정 흐름에 적용하기

용어를 확인한 뒤 “구독 가져오기—노드 선택—시스템 프록시 또는 TUN 설정—라우팅 확인—연결 검증—로그 확인” 순서로 설정을 진행할 수 있습니다. 개념과 작업을 연결해야 합니다. 구독 문제는 업데이트 로그를, 트래픽 가로채기 문제는 시스템 프록시나 TUN을, 대상 경로가 예상과 다르면 라우팅과 DNS를 확인하세요.

설정 가이드 보기 전체 문서 읽기