설정 참고 · 용어 한눈에 보기

V2Ray 용어와 설정 개념

구독 주소부터 라우팅 아웃바운드까지, 각 설정이 어느 계층을 담당하는지 먼저 살펴보세요. v2rayN, v2rayNG, v2flyNG에서 자주 접하는 용어를 6개 범주로 정리했습니다. 각 카드는 고유 앵커로 바로 연결할 수 있습니다.

처음 설정한다면 ‘구독과 서버’부터 확인하세요. 연결에 문제가 생기면 클라이언트 설정, 코어 실행, 서버 매개변수를 구분한 뒤 해당 항목을 살펴보세요.

설정 가이드 보기 증상별 문제 해결 →

프로토콜과 전송

프로토콜은 양쪽이 프록시 데이터를 주고받는 방식을, 전송 설정은 데이터를 전달하는 방식을 정합니다. 프로토콜 이름이 같아도 주소, 인증 정보, 전송 매개변수를 생략할 수 있는 것은 아닙니다.

VMess프록시 프로토콜
VMess는 인증과 암호화 기능을 갖춘 프록시 프로토콜입니다. 일반적인 설정에는 서버 주소, 포트, 사용자 ID가 포함됩니다. 클라이언트와 서버의 전송 방식 및 보안 설정도 서로 맞아야 하므로 사용자 ID만 정확히 입력한다고 연결이 보장되지는 않습니다. 인증에 실패하면 시스템 시간이 동기화되어 있는지 확인하세요. 시간 차이가 크면 인증에 영향을 줄 수 있습니다. 이전 설정 필드의 지원 여부는 실제 코어 버전에서 확인해야 합니다.
VLESS프록시 프로토콜
VLESS는 인증과 데이터 전송을 분리하며, 프로토콜 자체로는 데이터를 암호화하지 않습니다. 보통 TLS나 REALITY 같은 보안 계층과 함께 사용합니다. 사용자 ID, 보안 계층, 전송 설정은 서버 측 정보와 일치해야 합니다. VMess 설정에서 프로토콜 이름만 바꿔 그대로 사용할 수는 없습니다. 특정 조합의 지원 여부는 GUI에 같은 이름의 옵션이 있는지가 아니라 코어와 버전에 따라 결정됩니다.
TrojanTLS 프록시 프로토콜
Trojan은 일반적으로 TLS로 연결을 보호하고 비밀번호로 인증합니다. 비밀번호가 맞는데도 핸드셰이크에 실패하면 서버 이름, 인증서 신뢰 여부, 전송 설정을 추가로 확인하세요. 비밀번호만 반복해서 바꾸는 것은 해결책이 아닙니다. 노드의 연결 주소와 TLS에 사용하는 도메인은 다를 수 있으므로 서버에서 제공한 매개변수를 그대로 유지해야 합니다. 추가 전송 방식의 지원 여부도 사용 중인 코어에서 확인하세요.
ShadowsocksSS · 암호화 프록시 프로토콜
Shadowsocks는 양쪽이 합의한 암호화 방식과 비밀번호 또는 키를 사용해 프록시 연결을 구성합니다. 프로토콜 버전에 따라 필요한 키 형식이 다를 수 있고, 선택한 암호화 방식도 클라이언트 코어에서 지원해야 합니다. 목록의 다른 항목으로 임의 변경하지 마세요. 공유 링크를 가져온 뒤에는 서버 주소, 포트, 암호화 방식이 모두 입력되었는지 확인하세요. 실제 사용 가능 여부는 서버 상태와 네트워크 경로에도 달려 있습니다.

코어와 생태계

GUI 클라이언트는 설정을 관리하고 코어는 연결을 실행합니다. 이 관계를 이해하면 기능을 어디서 설정하고 오류를 어디서 확인해야 하는지 파악하기 쉽습니다.

Project V모듈형 프록시 생태계
Project V는 모듈형 프록시 기능을 중심으로 구성된 프로젝트 생태계이며, V2Ray는 그중 널리 쓰이는 핵심 프로젝트입니다. 인바운드, 아웃바운드, 라우팅, 전송 등의 개념은 여러 구성 요소를 조합할 수 있도록 설계된 구조에서 비롯됩니다. 특정 데스크톱 앱의 다른 이름이 아닙니다. v2rayN에서 노드를 가져오면 클라이언트가 설정을 정리한 뒤 선택한 코어에 전달해 실행합니다.
V2FlyV2Ray 커뮤니티 코어 계열
V2Fly는 V2Ray 코어의 발전을 이어가는 커뮤니티 프로젝트입니다. 관련 프로그램은 프로토콜 처리, 라우팅, DNS 등의 기반 기능을 담당합니다. v2flyNG는 이 코어 계열을 사용하며, 기존 설정과 기능이 맞는 경우에 적합합니다. V2Fly와 Xray는 기술적 연관성이 있지만 이후 기능은 각각 발전했습니다. 설정을 사용하기 전에 대상 코어가 해당 프로토콜, 필드, 보안 전송 조합을 지원하는지 확인하세요.
Xray독립 프록시 코어
Xray는 V2Ray와 기술적 연관성이 있지만 독립적으로 발전한 코어 프로젝트입니다. REALITY와 XTLS Vision은 Xray에서 자주 다루는 기능입니다. v2rayNG는 Xray 코어를 사용하며, 데스크톱용 v2rayN은 현재 버전과 설정에 따라 실제 호출되는 코어를 확인해야 합니다. 프로토콜 이름이 비슷해도 설정이 완전히 호환되는 것은 아닙니다. 설정을 복사할 때는 보안 계층, 흐름 제어 매개변수, 버전 요구 사항을 특히 확인하세요.
코어core
코어는 실제 연결을 구성하고 프록시 프로토콜을 처리하며 라우팅과 DNS 정책을 실행하는 프로그램입니다. GUI 클라이언트는 주로 인터페이스를 제공하고 설정을 생성합니다. 화면이 실행 중이라고 코어도 정상적으로 동작하는 것은 아닙니다. 포트 충돌이나 잘못된 설정 필드로 인해 연결이 시작 단계에서 멈출 수 있습니다. 문제를 확인할 때는 트레이 아이콘보다 코어 시작 로그와 요청 로그를 살펴보는 편이 정확합니다.

라우팅

라우팅은 ‘이 연결을 어느 아웃바운드로 보낼지’를 결정합니다. 매칭 조건, 규칙 순서, 어떤 규칙에도 해당하지 않는 트래픽의 기본 경로를 함께 확인해야 합니다.

라우팅routing
라우팅은 도메인, IP 주소 또는 기타 연결 정보를 기준으로 트래픽을 서로 다른 아웃바운드로 보냅니다. direct, proxy, block은 각각 직접 연결, 프록시, 차단을 나타내는 흔한 태그지만, 실제 동작은 해당 아웃바운드 정의에 따라 결정됩니다. 라우팅은 시스템 프록시 설정과 다릅니다. 트래픽이 먼저 코어에 들어와야 규칙을 적용할 수 있습니다.
GeoSite도메인 분류 목록
GeoSite는 도메인을 범주별로 정리합니다. 라우팅에서는 geosite:cn 또는 geosite:category-ads-all 같은 형식으로 목록을 참조합니다. 이 기능은 도메인 범주를 매칭하며 대상 서버의 지리적 위치를 판별하지 않습니다. 결과는 사용하는 데이터 파일에 따라 달라집니다. 규칙이 적용되지 않으면 해당 목록의 존재 여부, 데이터 업데이트 상태, 코어가 매칭에 사용할 도메인을 확보했는지 확인하세요.
GeoIPIP 주소 대역 목록
GeoIP는 IP 주소 대역을 범주별로 정리합니다. 예를 들어 geoip:private는 사설 IP 주소 등의 대상을 판별하는 데 사용됩니다. GeoSite와는 판단 기준이 다릅니다. GeoIP는 주소 대역을, GeoSite는 도메인 목록을 기준으로 하며 두 기능을 함께 사용할 수도 있습니다. 도메인 요청이 IP 매칭에 포함되는지는 도메인 해석 정책에도 영향을 받으므로 사이트 이름만 보고 특정 GeoIP 범주에 반드시 해당한다고 판단할 수 없습니다.
라우팅 규칙routing rule
라우팅 규칙은 매칭 조건과 대상 아웃바운드로 구성되며, 조건에는 도메인, 주소, 포트, 프로토콜 정보 등이 포함될 수 있습니다. 규칙은 보통 순서대로 확인하므로 구체적인 조건을 먼저 배치하고 포괄적인 조건은 뒤에 둬야 합니다. 어떤 규칙에도 해당하지 않을 때 사용할 기본 아웃바운드도 확인하세요. 같은 규칙 안의 여러 필드가 어떻게 조합되는지, 도메인 목록이 어떻게 매칭되는지는 코어 문법을 기준으로 이해해야 합니다. 화면에 표시된 순서만으로 동작을 추측하지 마세요.

구독과 서버

구독은 설정을 가져오고, 서버 항목은 연결 정보를 담으며, 테스트는 특정 경로의 동작을 확인합니다. 업데이트 성공, 서버 항목 존재, 연결 가능 여부는 서로 다른 상태입니다.

구독subscription
구독은 주소를 통해 서버 설정 목록을 가져오고 갱신하는 방식입니다. 클라이언트가 응답 내용을 파싱해 서버 항목을 지정된 그룹에 추가합니다. 구독 업데이트 성공은 설정을 새로고침했다는 뜻일 뿐, 모든 서버에 연결할 수 있거나 현재 선택된 서버가 바뀌었다는 뜻은 아닙니다. 구독 주소에 접근 인증 정보가 포함될 수 있으므로 화면을 공유하거나 도움을 요청하거나 다른 기기와 동기화하기 전에 전체 주소를 가리세요. 클라이언트가 응답 형식을 지원하는지도 확인해야 합니다.
서버server profile
서버 항목은 클라이언트에 저장되는 연결 설정으로, 보통 주소, 포트, 프로토콜, 인증 정보, 전송 설정을 포함합니다. 목록에 표시된 이름은 설정을 구분하기 위한 메모일 뿐 서버 위치, 가용성, 실제 성능을 보장하지 않습니다. 가져온 뒤 시간 초과가 발생하면 이름만 보고 순서를 바꾸기보다 선택한 항목이 맞는지, 설정이 빠짐없이 입력되었는지, 서버에 연결할 수 있는지 확인하세요.
지연 시간latency
지연 시간은 특정 테스트 방식으로 측정한 응답 시간입니다. TCP 연결 테스트, 프로토콜 핸드셰이크, 웹 요청은 서로 다른 구간을 측정합니다. 수치가 낮아도 다운로드 속도가 반드시 빠른 것은 아니며 모든 앱이 같은 아웃바운드를 사용하는지도 알 수 없습니다. 서버를 비교할 때는 같은 테스트 방식과 대상, 비슷한 시간대를 사용하세요. 테스트에 실패하면 로그를 함께 확인해 시간 초과, DNS 조회 실패, 인증 오류를 구분해야 합니다.
실제 연결 지연 시간real connection latency
실제 연결 지연 시간은 일반적으로 지정된 프록시 아웃바운드로 테스트 주소에 요청을 보내고 완료까지 걸린 시간을 측정하는 값입니다. 세부 방식은 클라이언트 구현에 따라 다릅니다. 도메인 조회, 연결 설정, 프로토콜 핸드셰이크, 대상 서버 응답 등이 포함되므로 서버 포트만 검사하는 것보다 실제 요청에 가깝습니다. 그래도 테스트 사이트와 라우팅 경로의 영향을 받으며, 테스트에 성공해도 다른 사이트나 앱까지 반드시 사용할 수 있는 것은 아닙니다.

보안과 암호화

보안 계층 매개변수는 서버 설정과 일치해야 합니다. 핸드셰이크 오류는 항목별로 확인하고, 인증 검증을 끄는 방식으로 무조건 해결하려 해서는 안 됩니다.

TLSTransport Layer Security
TLS는 전송 데이터를 보호하고 인증서 등의 방식으로 서버 신원을 확인하며, 프록시 프로토콜의 보안 전송 계층으로 자주 사용됩니다. 인증서의 신뢰 여부와 유효 기간, 도메인 일치 여부, 시스템 시간이 모두 핸드셰이크에 영향을 줍니다. 인증서 오류가 발생하면 먼저 이 항목들을 점검하세요. 인증서 검증을 건너뛰면 신원 확인이 약해지므로 잘못된 매개변수를 바로잡는 대신 사용해서는 안 됩니다.
REALITYXray 보안 전송 방식
REALITY는 Xray 생태계의 보안 전송 방식으로, VLESS 및 XTLS Vision과 함께 사용하는 경우가 많습니다. 모든 TLS 설정을 임의로 대체하는 스위치로 이해해서는 안 됩니다. 클라이언트 공개 키, 서버 이름, shortId, 관련 지문 등의 매개변수는 서버 요구 사항에 맞아야 하며, 구체적인 필드는 사용 중인 버전에 따라 달라집니다. 핸드셰이크에 실패하면 연결 주소만 바꾸지 말고 전체 매개변수와 코어 지원 여부를 확인하세요.
SNIServer Name Indication
SNI는 TLS 핸드셰이크에서 서버 이름을 전달해 서버가 해당 사이트와 인증서를 선택하도록 돕는 확장 기능입니다. 노드의 연결 주소는 IP일 수도 있고 서버 이름과 다를 수도 있지만, 입력한 이름은 서버 설정과 인증서 요구 사항에 맞아야 합니다. 클라이언트 화면에서 관련 필드를 ‘서버 이름’ 또는 serverName으로 표시할 수 있습니다. 도메인 불일치 오류가 발생하면 임의의 흔한 도메인을 입력하지 말고 노드에서 제공한 매개변수를 확인하세요.
DNS 유출DNS leak
DNS 유출은 조회가 예상과 다른 경로로 처리되는 현상입니다. 모든 직접 연결 DNS 조회가 문제인 것은 아닙니다. 운영체제, 브라우저, 클라이언트가 각자 다른 방식으로 DNS를 처리할 수 있으므로 프록시 연결이 정상이라고 DNS 경로까지 예상대로라고 단정할 수 없습니다. 먼저 도메인별로 어떤 경로를 사용해야 하는지 정한 뒤 클라이언트 로그, 브라우저의 보안 DNS 설정, 시스템 DNS 설정을 차례로 확인하세요.

클라이언트 기능

이 기능들은 트래픽이 코어에 들어오는 방식과 코어가 대상을 식별하는 방식을 다룹니다. 기능 이름이 같더라도 클라이언트와 코어 버전에 따라 지원 범위가 다를 수 있습니다.

시스템 프록시system proxy
시스템 프록시는 운영체제가 앱에 제공하는 프록시 설정입니다. 이 설정을 따르는 앱만 요청을 지정된 프록시 주소로 보냅니다. 일부 프로그램은 별도 프록시 설정을 사용하거나 직접 연결하므로 시스템 프록시를 켜도 모든 트래픽이 처리되는 것은 아닙니다. v2rayN을 사용할 때는 코어가 실행 중인지, 로컬 수신 포트가 올바른지, 앱이 시스템 설정을 따르는지 함께 확인하세요. 클라이언트를 종료한 뒤 사용할 수 없는 프록시 주소가 남아 있지 않은지도 점검해야 합니다.
TUN 모드가상 네트워크 인터페이스
TUN 모드는 가상 네트워크 인터페이스로 트래픽을 받은 뒤 관련 프로그램이 처리하는 방식으로, 더 많은 앱의 연결을 적용해야 할 때 유용합니다. 시스템 프록시만 변경하는 방식과 달리 시스템 라우팅, 실행 권한, DNS 설정이 함께 필요합니다. 켠 뒤 네트워크에 문제가 생기면 가상 인터페이스가 만들어졌는지, 라우팅 충돌이 있는지, DNS 경로가 올바른지 확인하세요. 모드를 끈 뒤에는 기존 네트워크 상태가 복구되었는지도 점검해야 합니다.
FakeDNS합성 IP와 도메인 매핑
FakeDNS는 도메인에 합성 IP 주소를 반환하고 도메인과 주소의 매핑을 저장합니다. 코어는 이후 연결에서 이 정보를 바탕으로 원래 대상을 복원합니다. 실제 서버 주소를 무작위로 바꾸는 기능도, 광고를 자동으로 차단하는 기능도 아닙니다. 코어가 지원해야 하며 인바운드와 트래픽 가로채기 설정도 함께 구성해야 합니다. 앱이 이 DNS 경로를 우회하거나 이전 캐시를 사용하면 문제가 생길 수 있으므로 설정을 변경한 뒤 캐시와 매핑, 실제 연결 경로를 확인하세요.
트래픽 스니핑sniffing
트래픽 스니핑은 읽을 수 있는 HTTP 호스트 정보나 TLS 서버 이름처럼 일부 연결의 프로토콜 메타데이터에서 도메인 등의 정보를 식별합니다. 도메인 기반 라우팅 매칭에 도움이 되지만 모든 연결을 식별할 수 있는 것은 아니며 암호화된 본문을 복호화하지도 않습니다. 라우팅 판단에만 영향을 주는지, 대상 주소를 덮어쓰는지는 구체적인 설정을 확인해야 합니다. 호환성 문제가 생기면 일시적으로 끄고 로그를 비교해 영향을 살펴보세요.

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

먼저 노드 매개변수가 서버 설정과 일치하는지 확인하고, 다음으로 트래픽이 어느 인바운드로 들어왔는지 살펴본 뒤, 마지막으로 어떤 아웃바운드 규칙에 매칭되었는지 확인하세요. 용어집은 설정의 의미를 설명하며, 실제 단계와 오류 해결은 설정 가이드와 문제 해결 페이지에서 다룹니다.

v2rayN 다운로드