설정 이름 · 개념 구분 · 사용 위치

V2Ray 용어 정리

클라이언트의 설정 필드 이름을 기준으로 프록시 프로토콜, 전송 보안, 코어, 라우팅을 구분합니다. 각 용어에는 바로 이동할 수 있는 앵커가 있어 설정과 로그를 대조하기 편리합니다.

설정 주제 6개 자주 쓰는 용어 26개 단계별 설정 방법 →

연결 설정의 프로토콜 유형

전송 프로토콜

이 분류의 이름은 보통 ‘서버 추가’ 또는 ‘프로토콜’ 항목에 표시됩니다. 프로토콜을 선택한 뒤에는 전송 방식과 보안 계층도 확인해야 합니다.

VMess
Project V 생태계의 프록시 프로토콜로, 사용자 ID를 사용해 인증하며 기존 구독 설정에서 자주 볼 수 있습니다. VMess의 프로토콜 인증은 TCP, WebSocket 등의 전송 방식과 별개의 설정입니다. 사용자 ID를 입력했다고 해서 다른 매개변수까지 모두 설정된 것은 아닙니다. 가져온 뒤에는 서버가 요구하는 전송 방식과 보안 계층, 기기 시간을 확인하세요. 구형 설정 필드의 사용 가능 여부는 현재 코어의 지원에 따라 달라집니다.
VLESS
간결하게 설계된 프록시 프로토콜로, 사용자 ID를 사용해 인증하며 자체적으로 페이로드를 암호화하지 않습니다. 실제 연결에는 보통 TLS 또는 REALITY를 함께 사용하므로 ‘VLESS 선택’만으로 보안 계층 설정을 대신할 수 없습니다. 구독에 flow 같은 확장 필드가 포함되어 있다면 서버가 제공한 값을 유지하고, 이름만 보고 호환성을 추측하기보다 현재 코어가 해당 조합을 지원하는지 확인하세요.
Trojan
일반적으로 TLS 위에서 작동하며 비밀번호로 인증하는 프록시 프로토콜입니다. 클라이언트에서는 주소, 포트, 비밀번호뿐 아니라 서버 이름과 인증서 검증 설정도 확인해야 합니다. 핸드셰이크 오류가 발생하면 인증서 검증을 바로 건너뛰기보다 이름, 인증서 신뢰 여부, 기기 시간을 먼저 확인하세요. 인증 성공과 보안 연결 수립은 서로 연관되어 있지만 별개의 단계입니다.
Shadowsocks SS
암호화 방식과 비밀번호를 주요 연결 매개변수로 사용하는 프록시 프로토콜 계열이며, 공유 링크에는 ss:// 접두사가 자주 쓰입니다. 암호화 방식과 프로토콜 세대에 따라 호환성이 다르므로 현재 코어가 서버에서 지정한 방식을 지원해야 합니다. 비밀번호만 확인하지 말고 방식 이름도 살펴보세요. 일부 방식에는 별도의 키 형식 요구사항도 있습니다.

화면 인터페이스와 실제 연결을 처리하는 구성 요소

코어 및 생태계

그래픽 클라이언트는 설정을 관리하고, 코어는 연결을 실행합니다. 클라이언트 이름, 코어 계열, 프로토콜 이름은 서로 바꿔 쓸 수 없습니다.

Project V
V2Ray와 관련된 네트워크 도구 생태계를 가리키는 배경 용어로, 프록시, 라우팅, 확장 가능한 설정 등의 설계를 아우릅니다. 클라이언트에서 직접 선택할 수 있는 연결 프로토콜이 아니며, 관련 소프트웨어가 모두 같은 기능을 제공한다는 뜻도 아닙니다. 문서를 읽을 때는 ‘어떤 클라이언트를 사용하는가, 어떤 코어를 호출하는가, 어떤 프로토콜로 연결하는가’를 차례로 확인해 생태계 이름을 구체적인 기능 목록과 혼동하지 않도록 하세요.
V2Fly
V2Ray 개발을 이어가는 커뮤니티 프로젝트로, 코어는 흔히 v2fly-core라고 부르며 v2flyNG는 관련 안드로이드 클라이언트 중 하나입니다. V2Fly와 Xray는 공통된 역사를 갖지만 기능과 설정 필드에는 차이가 있습니다. 설정을 옮길 때는 해당 코어의 문서를 확인하세요. 둘 다 JSON을 읽을 수 있다고 해서 모든 프로토콜 확장과 라우팅 동작이 같다고 볼 수는 없습니다.
Xray
V2Ray 프로젝트의 포크에서 발전한 네트워크 프록시 코어로, 흔히 Xray-core라고 부르며 v2rayNG가 이 코어 계열을 사용합니다. 프로토콜 연결, 라우팅, 관련 DNS 처리를 담당하고 그래픽 인터페이스는 설정을 생성하고 관리합니다. 특정 REALITY, 전송 방식, flow 옵션의 지원 여부는 실제 코어 버전을 기준으로 확인해야 하며 클라이언트 버전 이름만으로 판단할 수 없습니다.
코어 전환
클라이언트에서 지원하는 범위 안에서 실제 연결을 처리하는 코어를 변경합니다. 모든 클라이언트가 같은 전환 메뉴를 제공하는 것은 아닙니다. 코어를 바꾸면 동일한 연결 설정도 프로토콜 확장이나 필드 해석 차이로 실행되지 않을 수 있습니다. 로그와 설정 결과를 다시 확인하고 라우팅 데이터베이스가 새 코어와 호환되는지도 살펴보세요. 코어 전환은 모든 연결 문제를 해결하는 만능 방법이 아닙니다.

핸드셰이크, 인증, 보안 계층 매개변수

보안 전송 계층

프로토콜 유형이 맞아도 핸드셰이크 매개변수가 올바르다는 뜻은 아닙니다. 서버 이름, 공개 키 관련 매개변수, 지문 등의 필드는 서버에서 제공한 정보에 따라 입력해야 합니다.

TLS
전송 암호화와 인증을 제공하는 보안 프로토콜로, 여러 프록시 프로토콜과 조합할 수 있습니다. 일반적인 인증서 검증에서는 신뢰 체인, 이름 일치 여부, 유효 기간을 확인하므로 기기 시간이 맞지 않아도 연결에 실패할 수 있습니다. 오류가 발생하면 서버 이름과 인증서 설정을 먼저 확인하고, ‘안전하지 않은 연결 허용’을 일상적인 해결 방법으로 사용하지 마세요.
REALITY
Xray 생태계의 전송 보안 방식으로, VLESS와 함께 쓰이는 경우가 많습니다. 흔히 말하는 ‘REALITY 프로토콜’은 VLESS와 같은 계층에서 서로 대체할 수 있다는 뜻이 아닙니다. 설정에는 서버 이름, 서버 공개 키 관련 필드, short ID, 지문 등의 매개변수가 포함되는 경우가 많으며, 필드 이름은 인터페이스 버전에 따라 다를 수 있습니다. 서버가 제공한 매개변수를 빠짐없이 유지하고 일반 TLS 설정 방식을 그대로 적용하지 마세요.
SNI Server Name Indication
TLS 핸드셰이크에서 대상 서버 이름을 나타내는 확장 정보입니다. 클라이언트 인터페이스에서는 관련 필드를 ‘서버 이름’ 또는 serverName으로 표시할 수 있습니다. 실제 연결 IP 주소와 다를 수 있지만 서버의 요구사항 및 해당 검증 방식과 일치해야 합니다. 접속 가능한 웹사이트 도메인을 임의로 입력해도 원래 맞지 않던 설정으로 연결할 수 있는 것은 아닙니다.
클라이언트 지문
TLS 핸드셰이크에서 사용하는 특성 조합을 뜻하며, 일부 코어는 브라우저 이름을 딴 사전 설정을 제공합니다. 특정 지문을 선택해도 브라우저가 바뀌거나 웹페이지에 표시되는 브라우저 정보가 직접 수정되지는 않습니다. 이 옵션의 적용 여부는 코어, 연결 유형, 설정 위치에 따라 다릅니다. 문제를 진단할 때는 구독에서 가져온 원래 값을 유지하고 여러 핸드셰이크 매개변수를 동시에 바꾸지 않는 편이 좋습니다.

설정 출처, 저장 형식, 테스트 결과

구독 및 노드

가져오기, 업데이트, 선택, 테스트는 서로 다른 작업입니다. 목록에 항목이 표시된다는 것은 클라이언트가 설정을 읽었다는 뜻일 뿐입니다.

구독
하나의 주소로 여러 연결 설정을 받아오는 배포 방식이며, 클라이언트는 보통 결과를 지정된 그룹에 저장합니다. 구독 업데이트는 설정을 다시 가져오는 작업이지 계정을 갱신하는 것이 아니며, 현재 연결이 즉시 바뀌는 것도 아닙니다. 구독 주소에 접근 인증 정보가 포함될 수 있으므로 민감 정보로 취급하세요. 스크린샷, 로그, 문의 내용을 공유하기 전에 전체 주소와 인증 정보를 지워야 합니다.
노드
클라이언트 목록에서 선택할 수 있는 연결 설정 항목으로, 보통 주소, 포트, 프로토콜, 인증, 전송 매개변수를 포함합니다. 표시 이름은 구분을 위한 라벨일 뿐 위치, 성능, 사용 가능 여부를 확실하게 보여주지 않습니다. 이름이 다른 두 항목이 같은 서버를 가리킬 수도 있습니다. 중복 여부를 판단할 때는 이름만 비교하지 말고 실제 연결 필드를 확인하세요.
실제 연결 지연 시간
프록시 연결을 통해 테스트 주소에 요청했을 때 걸리는 응답 시간으로, 프록시 핸드셰이크, DNS, TLS, 대상 사이트 응답 등의 시간이 포함될 수 있습니다. 주소와 포트만 확인하는 TCP 연결 테스트와 다르며 다운로드 속도로 바로 환산할 수도 없습니다. 결과를 비교할 때는 테스트 주소, 방식, 네트워크 환경을 동일하게 유지하세요. 테스트 실패가 설정을 전혀 사용할 수 없다는 뜻은 아니며 테스트 대상 자체의 문제일 수도 있습니다.

연결 경로와 도메인 조회 경로

라우팅

트래픽 분리는 규칙, 데이터베이스, DNS 조회 결과가 함께 작동해야 합니다. 규칙이 존재하는 것만 확인해서는 실제 연결이 해당 규칙에 일치했는지 알 수 없습니다.

라우팅 규칙 및 트래픽 분리
도메인, IP, 포트, 인바운드 등의 조건에 따라 연결을 직접 연결, 프록시 또는 차단된 아웃바운드로 보내는 방식입니다. 일반적인 Xray 라우팅 설정에서는 규칙을 순서대로 확인하고 처음 조건에 맞는 규칙에 따라 연결 경로가 결정되므로, 조건이 너무 넓으면 뒤에 있는 예외 규칙이 적용되지 않을 수 있습니다. 변경한 뒤에는 로그로 실제 아웃바운드를 확인하고 어떤 규칙에도 일치하지 않을 때의 기본 처리 방식도 살펴보세요.
GeoIP
라우팅에 사용할 IP 주소를 분류별로 모아 둔 데이터로, 보통 geoip.dat 등의 데이터베이스를 불러와 사용합니다. 데이터베이스의 지역 또는 용도 태그는 실시간 위치 정보가 아니며, 특정 도메인이 어느 서비스에 속하는지를 직접 나타내지도 않습니다. 도메인 조회로 얻은 주소와 규칙을 대조해야 한다면 도메인 조회 정책도 확인하세요. 데이터베이스만 업데이트해도 현재 연결의 판정이 바뀌지 않을 수 있습니다.
GeoSite
라우팅에 사용할 도메인을 분류별로 모아 둔 데이터로, 흔히 사용하는 데이터베이스 파일 이름은 geosite.dat입니다. 예를 들어 geosite:cn은 분류를 참조하는 형식이지만, 구체적인 태그와 포함 범위는 사용 중인 데이터베이스에 따라 다르므로 출처마다 내용이 같다고 가정하면 안 됩니다. 태그가 없으면 설정을 불러오지 못할 수 있고, 분류가 존재하더라도 새 도메인이 이미 포함되어 있다는 뜻은 아닙니다.
FakeDNS
도메인을 예약된 주소 풀에 매핑한 뒤 후속 연결에서 도메인 정보를 복원하는 방식으로, IP 트래픽을 가로챈 뒤에도 도메인을 라우팅 기준으로 유지하는 데 도움이 됩니다. 매핑에 쓰이는 주소는 대상 사이트의 실제 공인 IP가 아니며 사이트 위치를 판단하는 데 사용해서도 안 됩니다. DNS, 트래픽 처리, 관련 라우팅 설정이 함께 작동해야 하므로 스위치 하나만 켜면 조회 결과를 제대로 복원하지 못할 수 있습니다.
DNS 누수
DNS 조회가 예상한 경로를 통해 전송되지 않는 현상입니다. 예를 들어 연결은 프록시를 거치지만 도메인 조회는 시스템의 다른 DNS 서버로 전달될 수 있습니다. 시스템 DNS, 브라우저의 보안 DNS, 앱 내부 조회, 클라이언트 DNS 라우팅을 모두 확인해야 합니다. 출구 IP가 바뀐 것만으로 조회 경로도 바뀌었다고 볼 수 없으며, 테스트 사이트에 표시되는 DNS 서버 이름도 실제 설정과 함께 살펴봐야 합니다.
스니핑 Sniffing
연결 초기 단계에서 확인할 수 있는 프로토콜 특성으로부터 도메인 등의 정보를 추출해 라우팅이나 대상 식별에 활용합니다. 스니핑은 트래픽을 임의로 복호화하지 않으며, 얻을 수 있는 정보는 연결 프로토콜, 암호화 방식, 코어 구현에 따라 제한됩니다. 라우팅 판단에만 사용하는 설정과 연결 대상을 덮어쓰는 설정도 구분해야 합니다. 후자는 실제 접속 동작을 바꿀 수 있으므로 모든 상황에서 기능을 많이 켜는 것이 좋은 것은 아닙니다.

앱 트래픽을 클라이언트로 전달하는 방법

클라이언트 기능

시스템 프록시, 가상 인터페이스, 로컬 인바운드는 각각 다른 문제를 해결합니다. 설정이 완료되면 연결 스위치만 확인하지 말고 실제로 사용할 앱에서 테스트하세요.

시스템 프록시
운영체제에 프록시 주소를 등록해 해당 설정을 따르는 앱이 로컬 프록시 엔드포인트에 연결하도록 합니다. 켜도 모든 앱의 트래픽이 클라이언트로 들어오는 것은 아니며, 자체 네트워크 설정을 사용하거나 직접 연결하는 프로그램도 있습니다. 브라우저에서는 작동하지만 다른 프로그램에서는 안 된다면, 앱이 시스템 프록시를 읽는지 먼저 확인한 뒤 앱 내부 프록시나 다른 트래픽 처리 방식을 고려하세요.
TUN 모드
가상 네트워크 인터페이스와 관련 시스템 라우팅을 사용해 IP 트래픽을 처리하는 방식으로, 시스템 프록시를 따르지 않는 일부 앱도 지원할 수 있습니다. 시스템 프록시와는 별개의 설정이며, 구현 방식과 필요한 권한은 플랫폼과 클라이언트에 따라 달라집니다. 활성화한 뒤 DNS, 로컬 네트워크 접속, 기존 가상 인터페이스와의 충돌 여부를 확인하세요. 안드로이드 클라이언트의 VPN 권한 화면에서 반드시 ‘TUN’이라는 이름을 사용하는 것은 아닙니다.
SOCKS 인바운드
앱이 클라이언트의 로컬 프록시 엔드포인트에 연결할 때 사용하며, 흔히 SOCKS5 주소와 포트로 표시됩니다. 일부 설정에서는 로컬 10808 포트를 사용하지만 실제 값은 클라이언트 설정을 기준으로 확인해야 합니다. 로컬 인바운드 포트를 원격 서버 포트로 입력해서는 안 됩니다. UDP 지원 여부는 앱, 코어, 서버 연결 경로에 따라 달라집니다. 일반적으로 로컬에서만 수신하도록 설정하고, 로컬 네트워크에 공개하기 전에 접근 제어를 고려하세요.
HTTP 프록시 인바운드
앱이 HTTP 프록시 프로토콜로 요청을 클라이언트에 전달하도록 하는 로컬 엔드포인트이며, 지원되는 경우 CONNECT 메서드로 HTTPS 터널을 만들 수 있습니다. 일부 설정에서는 로컬 10809 포트를 사용하지만 버전에 따라 별도 포트나 혼합 인바운드가 제공될 수 있으므로 현재 설정을 확인하세요. SOCKS와는 통신 방식이 다르므로 앱에서 선택한 프록시 유형이 입력한 포트에서 제공하는 프로토콜과 일치해야 합니다.

문제에 따라 더 알아보기

필드의 의미를 확인한 뒤 구체적인 작업으로 돌아가세요. 설정을 수정할 때는 한 번에 한 항목만 바꾸고 되돌릴 수 있도록 기존 설정을 보관하면 결과를 비교하기 쉽습니다.