설정 참고 · 용어 28개

V2Ray 용어집

프로토콜, 코어, 구독, DNS. 클라이언트 설정에서 실제로 어떤 의미인지 확인하고, 먼저 개념을 구분한 뒤 설정값을 점검하세요.

프로토콜 안내서 읽기 설정 단계 보기 →

프록시 프로토콜

먼저 양쪽에서 사용하는 프로토콜 유형을 확인하세요. 보안 계층과 전송 방식은 별도로 맞춰야 합니다. REALITY도 함께 설명하지만 독립적인 프록시 프로토콜은 아닙니다.

VMess: Project V 생태계의 프록시 프로토콜로, 사용자 ID를 사용해 인증하며 최신 설정은 보통 AEAD를 사용합니다. 클라이언트와 서버의 사용자 ID, 보안 설정, 시스템 시간이 일치해야 합니다. 예전 안내서의 추가 인증 설정을 그대로 적용하지 마세요. VMess를 선택한 뒤에는 전송 방식과 TLS 설정도 확인해야 합니다. 프로토콜 이름이 같아도 전체 연결 설정은 다를 수 있습니다.

VLESS: 가벼운 프록시 프로토콜로, 자체적으로 데이터를 암호화하지 않으며 보통 TLS 또는 REALITY와 함께 사용합니다. 설정의 사용자 ID, 전송 방식, 보안 계층, flow를 각각 확인해야 합니다. flow 지원 여부는 양쪽 코어와 연결 조합에 따라 달라집니다. 인터페이스에 표시된 “암호화: none”만 보고 전체 연결이 암호화되지 않았다고 판단하지 말고 외부 보안 설정도 확인하세요.

Trojan: 비밀번호로 인증하고 보통 TLS로 연결을 보호하는 프록시 프로토콜입니다. 서버 주소, 포트, 비밀번호, TLS 서버 이름은 서로 다른 항목이므로 비밀번호만 복사해서는 연결할 수 없습니다. 인증서 오류가 발생하면 인증서 검증을 바로 끄기보다 이름, 인증서 유효기간, 시스템 시간을 먼저 확인하세요.

Shadowsocks（SS）: 공유 키 또는 비밀번호와 암호화 방식으로 설정하는 프록시 프로토콜입니다. 공유 링크는 보통 ss://로 시작합니다. 기존 AEAD와 Shadowsocks 2022는 설정값과 키 요구사항이 다르며, 클라이언트 지원 여부도 각각 확인해야 합니다. 프로토콜 유형, 암호화 방식, 키를 한 세트로 맞추고 서로 다른 방식의 설정 필드를 섞지 마세요.

REALITY: Xray 생태계의 전송 보안 방식으로, VLESS와 함께 사용하는 경우가 많습니다. VLESS를 대체하는 독립 프록시 프로토콜은 아닙니다. 설정에는 보통 서버 이름, 공개 키, shortId, 클라이언트 지문 등의 항목이 포함되며, 정확한 필드는 현재 코어와 클라이언트 인터페이스를 기준으로 확인해야 합니다. 가져온 뒤에도 정보가 모두 유지되었는지 점검하세요. 서버 주소만으로는 설정이 올바른지 판단할 수 없습니다.

전송 및 위장

이 계층은 데이터 전달 방식과 핸드셰이크 방식을 정합니다. 전송 방식 이름이 같더라도 경로, 호스트 이름, 전달 설정을 생략할 수 있는 것은 아닙니다.

TCP: 신뢰성 있고 순서가 보장되는 바이트 스트림을 제공하는 전송 계층 프로토콜로, 많은 프록시 연결의 기반으로 사용됩니다. 클라이언트의 TCP 테스트는 보통 지정된 포트에 연결하는 데 걸리는 시간만 확인하며 프록시 인증이나 이후 요청은 검증하지 않습니다. 따라서 TCP 테스트는 성공했지만 웹페이지가 열리지 않는 상황도 가능합니다. 이때는 프로토콜 핸드셰이크, TLS, DNS를 확인하세요.

UDP: 데이터그램 단위로 전송하며 전달 여부와 순서를 보장하지 않습니다. DNS나 실시간 통신 등에 자주 사용됩니다. 앱에서 UDP가 필요하다고 해서 시스템 프록시를 켜면 요청이 자동으로 처리되는 것은 아닙니다. 로컬 입구, 코어, 서버, 실행 모드가 모두 지원해야 합니다. 문제를 확인할 때는 UDP와 TCP를 따로 테스트하고, 웹페이지 접속 성공만으로 UDP 사용 가능 여부를 판단하지 마세요.

WebSocket（WS）: 프록시 데이터를 전달하는 데 사용할 수 있는 양방향 통신 방식이지만, 프록시 프로토콜의 사용자 인증을 대신하지는 않습니다. 클라이언트의 경로, Host, TLS 서버 이름은 용도가 다르므로 서버 및 리버스 프록시 설정과 일치해야 합니다. TLS 핸드셰이크가 정상이어도 경로나 전달 규칙이 잘못되면 연결이 실패할 수 있습니다.

gRPC: HTTP/2 기반 원격 호출 프레임워크로, 일부 프록시 코어에서 전송 방식으로 사용합니다. 설정의 서비스 이름을 서버와 일치시켜야 하며, 리버스 프록시가 있다면 HTTP/2와 해당 전달 방식도 올바르게 지원해야 합니다. 프록시 프로토콜이 아니며 어떤 네트워크나 트래픽에서도 다른 전송 방식보다 빠르다고 보장하지 않습니다.

TLS와 SNI: TLS는 연결을 암호화하고 인증하며, SNI는 핸드셰이크 중 접속하려는 서버 이름을 알립니다. 실제 연결 주소, SNI, HTTP Host는 서로 다를 수 있지만 각 항목은 서버 요구사항에 맞게 입력해야 하며 임의로 바꿔 쓸 수 없습니다. 인증서는 설정된 대상 이름에 맞게 검증해야 합니다. 임의의 도메인을 입력한다고 올바른 보안 연결이 만들어지는 것은 아닙니다.

코어 및 클라이언트

코어는 프로토콜과 라우팅을 처리하고, 그래픽 클라이언트는 설정을 관리하고 코어를 호출합니다. 인터페이스에 특정 항목을 저장할 수 있다고 해서 현재 코어가 해당 기능을 지원하는 것은 아닙니다.

Project V: V2Ray 등의 네트워크 도구를 중심으로 형성된 프로젝트 생태계를 뜻하며, 특정 데스크톱이나 모바일 앱의 이름은 아닙니다. 문서를 읽을 때 생태계 이름, 코어 프로젝트, 개별 클라이언트를 구분해야 코어 설정을 인터페이스 조작 방법으로 오해하지 않습니다. 이 사이트의 설정 안내는 v2rayN, v2rayNG, v2flyNG를 중심으로 구성되어 있습니다.

V2Fly: V2Ray 프로젝트의 발전을 이어가는 커뮤니티 및 코어 프로젝트로, 프록시 프로토콜, 전송, 라우팅, DNS 등의 기능을 제공합니다. Xray와 공통된 역사를 갖지만 이후 기능, 설정 형식, 필드 지원에 차이가 생겼습니다. 설정을 옮길 때는 실제 사용하는 코어의 문서를 확인하세요. 두 파일이 모두 JSON 형식이라고 해서 그대로 호환되는 것은 아닙니다.

Xray 코어: V2Ray에서 분리된 프록시 코어 프로젝트로, REALITY 등의 기능을 제공하며 자체 설정 및 프로토콜 구현을 발전시키고 있습니다. v2rayNG는 Xray 코어를 사용합니다. 데스크톱 클라이언트의 실제 동작은 선택한 코어에 따라 달라집니다. 기능 지원 여부는 설치된 버전과 설정 조합에 달려 있습니다. 그래픽 인터페이스 업데이트와 코어 업데이트는 별개입니다.

v2rayN: 구독, 서버, 라우팅, 프록시 모드를 관리하는 데스크톱 그래픽 클라이언트로, Windows, macOS, Linux에서 사용할 수 있습니다. 인터페이스는 설정을 만들거나 정리하고, 프로토콜 연결은 선택한 코어가 처리합니다. 문제를 확인할 때는 인터페이스 설정과 코어 로그를 함께 기록하세요. 클라이언트 이름만으로 모든 프로토콜과 모드가 활성화되었다고 판단할 수는 없습니다.

v2rayNG: Xray 코어 기반의 Android 그래픽 클라이언트로, 구독과 공유 설정을 가져올 수 있으며 보통 시스템 VPN 인터페이스를 통해 앱 트래픽을 처리합니다. 시스템 권한, 앱별 설정, 백그라운드 실행 제한에 따라 실제 처리 범위가 달라질 수 있습니다. 인터페이스에 실행 중이라고 표시되어도 서비스가 시작된 것일 뿐, 대상에 접속할 수 있는지는 실제 요청으로 확인해야 합니다.

v2flyNG: V2Fly 코어를 사용하는 Android 그래픽 클라이언트로, 해당 코어 생태계의 클라이언트로 선택할 수 있습니다. 이름이 v2rayNG와 비슷해도 코어가 다르므로 REALITY, flow 등의 확장 필드도 똑같이 지원한다고 단정할 수 없습니다. 선택 전에 서버가 요구하는 기능을 확인하고, 설정을 가져온 뒤 클라이언트가 모두 인식했는지 점검하세요.

구독 및 노드

구독은 설정 모음을 가져오는 경로이고, 노드는 그 안에 포함된 연결 설정 하나입니다. 가져오기, 업데이트, 테스트는 각각 다른 문제를 해결합니다.

구독 링크: 클라이언트가 서버 설정 목록을 가져오는 주소로, 업데이트하면 내용을 다시 가져와 파싱합니다. 클라이언트마다 지원하는 구독 형식이 다를 수 있으므로 주소가 열려도 올바르게 가져올 수 있는 것은 아닙니다. 링크에 접속 정보가 포함될 수 있으니 민감한 정보로 관리하세요. 업데이트는 보통 해당 그룹에 적용되므로 중요한 수동 설정은 별도로 저장하는 것이 좋습니다.

노드 / 서버 설정: 클라이언트 목록에서 선택할 수 있는 연결 설정 하나로, 보통 주소, 포트, 인증, 전송 방식, 보안 설정을 포함합니다. 논리적인 설정이므로 독립된 물리 서버 한 대와 반드시 일치하는 것은 아니며, 같은 주소에서 여러 연결 방식을 제공할 수도 있습니다. 메모 이름은 구분을 위한 것이므로 이름만으로 실제 위치, 성능, 프로토콜의 정확성을 판단할 수 없습니다.

지연 시간: 특정 테스트를 시작한 시점부터 응답을 받을 때까지 걸린 시간이며, 테스트 방식과 함께 해석해야 합니다. ICMP, TCP 연결, 프록시를 통한 웹사이트 접속은 서로 다른 경로와 과정을 측정하므로 목록의 숫자만 비교해서는 안 됩니다. 테스트 시간 초과가 전체 설정의 실패를 뜻하지 않을 수도 있습니다. 테스트 대상에 접속할 수 있는지, 테스트가 예상한 프록시를 통과하는지 확인하세요.

실제 연결 지연 시간: 클라이언트에서는 보통 프록시를 통해 지정된 테스트 주소에 접속하는 데 걸리는 시간을 뜻하며, 단순 포트 확인보다 더 많은 연결 과정을 포함합니다. DNS, 프로토콜 핸드셰이크, TLS, 대상 사이트, 연결 재사용의 영향을 받을 수 있고 정확한 측정 방식은 클라이언트 구현에 따라 달라집니다. 다운로드 속도와는 다르므로 설정을 비교할 때는 같은 테스트 주소와 방식을 사용하세요.

라우팅 및 DNS

트래픽이 클라이언트로 들어오는 경로, 적용되는 규칙, 도메인을 확인하는 주체는 각각 별도로 검증해야 합니다.

라우팅 규칙 및 트래픽 분기: 도메인, IP, 포트 등의 조건에 따라 연결을 직접 연결, 프록시, 차단 등의 아웃바운드로 보냅니다. 일반적으로 규칙은 순서대로 적용되며 기본 아웃바운드, 도메인 확인 방식, 스니핑 설정에 따라서도 동작이 달라집니다. 인터페이스의 “규칙 모드” 표시는 선택된 설정을 뜻할 뿐입니다. 실제 경로를 확인하려면 규칙 순서와 코어 로그를 살펴보세요.

GeoIP: 지역이나 용도별로 정리한 IP 주소 모음으로, 라우팅 규칙에서 geoip:private처럼 대상 IP를 일괄 매칭할 수 있습니다. 웹사이트 이름이 아니라 IP 주소를 기준으로 하며, 도메인이 먼저 IP로 확인되는지에 따라 규칙 적용 여부가 달라집니다. 데이터 파일은 설정과 호환되어야 하며, IP 모음만으로 서비스 소유자나 실시간 네트워크 위치를 정확히 알 수는 없습니다.

GeoSite: 사이트나 용도별로 정리한 도메인 모음으로, geosite:cn처럼 도메인 규칙을 일일이 관리하는 수고를 줄여 줍니다. 분류 태그의 존재 여부는 실제로 불러온 데이터 파일에 따라 달라지므로 안내서에 나온 태그를 코어에 기본 내장된 것으로 간주하지 마세요. 앱이 IP만 전달한다면 도메인 규칙을 적용하는 데 DNS 매핑이나 스니핑을 통한 도메인 정보가 필요할 수 있습니다.

시스템 프록시: 운영체제의 프록시 설정을 변경해 해당 설정을 따르는 앱이 클라이언트의 로컬 프록시 입구에 연결되도록 합니다. 모든 프로그램의 트래픽을 자동으로 처리하는 것은 아닙니다. 자체 네트워크 스택을 사용하는 앱은 시스템 설정을 무시할 수 있으며, UDP가 전달된다고 볼 수도 없습니다. 클라이언트를 종료한 뒤 네트워크에 문제가 생기면 시스템 프록시가 더 이상 연결되지 않는 로컬 포트를 가리키는지 먼저 확인하세요.

TUN 모드: 가상 네트워크 인터페이스로 IP 트래픽을 받은 다음 프록시 구성 요소에 전달하는 실행 방식이며, 새로운 프록시 프로토콜은 아닙니다. 추가 권한, 라우팅, DNS 설정이 필요한 경우가 많고 제외 규칙에 따라 트래픽 처리 범위도 달라집니다. 활성화한 뒤에는 로컬 네트워크 접속, 도메인 확인, 대상 앱을 각각 확인하세요. “전체 트래픽 처리”가 모든 트래픽을 반드시 프록시 아웃바운드로 보낸다는 뜻은 아닙니다.

FakeDNS: 앱에 합성 IP를 반환하고 코어가 해당 주소와 원래 도메인의 매핑을 저장해, 이후 연결에서 도메인 정보를 복원하고 라우팅에 활용합니다. 합성 주소는 대상 웹사이트의 실제 주소가 아니므로 트래픽 처리 및 매핑 기능이 함께 구성되어야 합니다. 설정이 불완전하면 주소가 예상한 처리 경로를 벗어날 수 있으며, 모드를 바꾼 뒤 남은 DNS 캐시도 문제를 일으킬 수 있습니다.

DNS 누출: DNS 조회가 미리 정한 경로를 벗어나는 현상입니다. 예를 들어 프록시를 통해 처리해야 하는 조회가 로컬 DNS 리졸버로 전달될 수 있습니다. 누출 여부는 정해 둔 정책에 따라 판단해야 하며, 의도적으로 직접 연결 DNS를 설정한 경우까지 모두 문제라고 할 수는 없습니다. 문제를 확인할 때는 시스템 DNS, 앱 자체의 암호화 DNS, 코어 DNS 아웃바운드, 트래픽 분기 규칙을 함께 살펴보세요. 검사 웹페이지 하나의 결과만으로는 원인을 찾기 어렵습니다.