VMess
프로토콜과 전송Project V 생태계의 프록시 프로토콜로, 사용자 식별자와 시간 검증을 사용해 연결을 수립합니다. 설정에는 보통 서버 주소, 포트, UUID와 전송 방식이 포함됩니다. 클라이언트 매개변수는 서버 설정과 일치해야 하며, 기기 시간이 크게 어긋나도 연결에 영향을 줄 수 있습니다.
VMess, VLESS, Xray, 구독, 라우팅, DNS 등 자주 쓰이는 개념을 확인하세요. 각 설명은 클라이언트 설정의 실제 필드나 작업에 대응하며, 구체적인 서버 매개변수를 대신하지 않습니다.
프로토콜은 인증과 데이터 캡슐화 방식을 결정하고, 전송 보안 계층은 보호된 연결을 수립합니다. 설정을 가져올 때는 프로토콜, 포트, 전송 방식과 보안 매개변수를 함께 맞춰야 합니다.
Project V 생태계의 프록시 프로토콜로, 사용자 식별자와 시간 검증을 사용해 연결을 수립합니다. 설정에는 보통 서버 주소, 포트, UUID와 전송 방식이 포함됩니다. 클라이언트 매개변수는 서버 설정과 일치해야 하며, 기기 시간이 크게 어긋나도 연결에 영향을 줄 수 있습니다.
가벼운 프록시 프로토콜로, 프로토콜 자체에서 데이터 암호화를 중복 처리하지 않습니다. 전송 보안은 일반적으로 TLS 또는 REALITY 같은 외부 설정이 담당합니다. VLESS를 선택할 때는 흐름 제어, 서버 이름, 공개 키와 전송 유형 등 관련 매개변수도 함께 확인해야 합니다.
TLS로 보안 전송을 구성하는 프록시 프로토콜로, 인증에는 보통 비밀번호 필드를 사용합니다. 클라이언트의 도메인, 포트와 전송 매개변수는 서버와 일치해야 합니다. 인증서 검증 실패, 서버 이름 오류 또는 시스템 시간 이상으로 핸드셰이크가 중단될 수 있습니다.
Xray 생태계의 전송 보안 방식으로, VLESS와 함께 사용하는 경우가 많습니다. 연결 설정에는 보통 공개 키, 짧은 식별자, 지문과 서버 이름 등이 포함됩니다. 독립적인 노드 프로토콜이 아니므로 이름만 선택하고 관련 VLESS 및 전송 설정을 생략할 수 없습니다.
그래픽 클라이언트는 인터페이스와 설정 관리를 담당하고, 코어는 연결, 라우팅과 도메인 해석을 처리합니다. 이름이 비슷한 클라이언트라도 같은 코어를 사용한다는 보장은 없으며 지원하는 프로토콜 필드도 다를 수 있습니다.
V2Ray 관련 프로토콜, 코어와 도구로 이루어진 오픈 소스 기술 생태계입니다. 설정 형식, 프록시 프로토콜과 라우팅 메커니즘 등 여러 부분을 포함하며, 특정 그래픽 클라이언트 하나의 이름이 아닙니다. 프로젝트마다 일부 개념을 공유할 수 있지만 기능 범위는 완전히 같지 않습니다.
V2Ray Core의 개발 흐름을 이어 가는 커뮤니티 프로젝트 및 코어 계열입니다. 인바운드, 아웃바운드, 라우팅과 DNS 설정을 실행할 수 있습니다. 클라이언트에서 V2Fly 코어를 사용하는지는 앱 설명, 코어 선택 항목과 현재 실행 로그를 기준으로 확인해야 합니다.
V2Ray 설정 체계와 유사한 개념이 많은 코어 구현체입니다. VLESS, REALITY 등을 지원하고 라우팅, DNS와 다양한 전송 설정을 처리할 수 있습니다. 그래픽 클라이언트가 설정을 생성하고 코어를 시작하며, 코어 버전에 따라 사용 가능한 필드가 달라집니다.
프로토콜 처리, 라우팅 판단, DNS 조회와 네트워크 연결을 실제로 수행하는 프로그램 구성 요소입니다. 그래픽 클라이언트는 주로 설정 편집, 구독 관리와 실행 상태 제어를 담당합니다. 문제를 해결할 때는 인터페이스 설정 오류, 설정 필드 오류와 코어 실행 오류를 구분해야 합니다.
구독은 설정을 일괄 제공하고, 노드는 선택 가능한 연결 기록입니다. 시스템 프록시와 TUN 모드는 어떤 앱 트래픽이 클라이언트로 들어올지 결정하며 두 방식의 적용 범위는 다릅니다.
서비스 제공자가 제공하는 설정 모음 주소로, 여러 노드, 그룹 정보와 업데이트 내용을 포함할 수 있습니다. 주소를 추가하는 것은 구독 출처를 저장하는 작업일 뿐이며 이후 업데이트가 필요합니다. 업데이트에 실패하면 먼저 주소의 유효성, 네트워크 접근 경로와 그룹 선택을 확인해야 합니다.
클라이언트에 저장된 서버 연결 설정 하나로, 보통 주소, 포트, 프로토콜, 인증 정보와 전송 방식을 기록합니다. 노드는 설정 단위일 뿐 로컬 클라이언트나 코어 자체를 뜻하지 않습니다. 노드를 선택한 뒤에는 클라이언트를 시작하고 트래픽 제어 방식을 설정해야 합니다.
클라이언트가 운영체제의 프록시 설정을 변경해 시스템 프록시를 따르는 앱의 요청을 로컬 수신 포트로 전달합니다. 일부 앱은 별도의 네트워크 설정을 사용해 시스템 프록시를 우회할 수 있습니다. 클라이언트를 종료하기 전에 시스템 프록시를 복원하면 접속할 수 없는 로컬 포트 설정이 남는 것을 막을 수 있습니다.
가상 네트워크 인터페이스로 기기 트래픽을 수신하는 실행 방식으로, 일반적으로 시스템 프록시보다 적용 범위가 넓습니다. 사용하려면 시스템 권한이 필요할 수 있으며 라우팅 규칙, DNS와 가상 주소 설정을 확인해야 합니다. 다른 네트워크 도구를 사용 중이라면 인터페이스와 라우팅 충돌 여부도 점검해야 합니다.
로컬 기기에서 탐색 패킷을 보낸 뒤 응답을 받을 때까지 걸린 시간으로, 보통 밀리초 단위로 표시됩니다. 간단한 지연 시간 테스트는 주소나 포트만 확인할 수 있어 프로토콜 핸드셰이크까지 완료하지 않을 수 있습니다. 수치는 네트워크 경로, 테스트 대상과 현재 부하에 따라 달라지므로 실제 연결 상태와 함께 판단해야 합니다.
노드의 실제 프로토콜과 전송 설정으로 연결을 완료한 뒤 측정한 응답 시간입니다. 단순 포트 탐색보다 많은 연결 단계를 포함해 핸드셰이크 매개변수 오류나 연결 시간 초과를 찾는 데 유용합니다. 다만 결과는 테스트 대상의 영향을 받으므로 지속적인 전송 속도를 단독으로 나타내지는 않습니다.
라우팅 규칙은 대상 특성에 따라 아웃바운드를 선택합니다. GeoIP는 주소 모음, GeoSite는 도메인 모음을 대상으로 하며 두 데이터는 각각 올바른 파일과 유효한 태그가 필요합니다.
도메인, 주소, 포트, 프로토콜 또는 프로세스 등의 조건에 따라 트래픽의 경로를 결정하는 설정입니다. 여러 규칙이 있으면 순서가 최종 매칭 결과에 영향을 줍니다. 보통 구체적인 조건의 규칙을 먼저 배치하고 나머지 트래픽을 처리할 일반 아웃바운드를 뒤에 둡니다.
대상이나 앱별 트래픽을 서로 다른 아웃바운드로 배분하는 설정 방식입니다. 대표적인 경로는 프록시 연결, 직접 연결과 차단입니다. 분할이 적용되는지는 도메인 해석 결과, 규칙 순서와 인바운드가 충분한 대상 정보를 확보했는지에 따라 달라집니다.
주소 대역과 지리 태그별로 정리된 데이터 모음으로, 라우팅 규칙에서 대상 주소를 매칭할 때 사용합니다. 해석된 주소나 직접 접속 주소를 매칭할 뿐 도메인 해석 자체를 담당하지는 않습니다. 데이터 파일의 형식과 태그 이름은 코어가 지원하는 내용과 일치해야 합니다.
도메인 범주별로 정리된 규칙 데이터 모음으로, 관련 도메인 그룹을 일괄 매칭할 때 사용할 수 있습니다. 범주 이름은 사용하는 데이터 파일이 정의하므로 표시 이름만으로 전체 내용을 판단할 수 없습니다. 규칙이 매칭되지 않으면 태그, 도메인 형식과 데이터 업데이트 시점을 확인해야 합니다.
DNS 설정은 도메인을 어디에서 조회할지 결정하고, 라우팅 설정은 조회 요청과 해석 결과가 어떤 경로로 연결될지 결정합니다. FakeDNS는 매핑으로 도메인 정보를 보존하고, DoH는 조회 전송 방식을 바꿉니다.
도메인을 네트워크 주소로 변환하는 기본 시스템입니다. V2Ray 설정에서 조회 서버, 도메인 매칭 규칙, 예상 주소와 조회 경로를 지정할 수 있습니다. 클라이언트 내부 DNS, 운영체제 DNS와 앱 자체 해석이 동시에 존재할 수 있으므로 문제를 해결할 때 계층별로 확인해야 합니다.
먼저 앱에 예약 주소를 반환한 뒤 코어가 매핑 정보를 사용해 원래 도메인을 복원하는 처리 방식입니다. TUN 환경에서 자주 사용하며 라우팅 단계에서 도메인 정보를 유지할 수 있습니다. 활성화할 때 주소 풀, DNS 인바운드와 라우팅 설정을 함께 조정해야 합니다.
앱의 도메인 조회가 예상한 설정 경로로 전달되지 않고 다른 네트워크 인터페이스나 리졸버에서 처리되는 현상입니다. 운영체제, 브라우저, 클라이언트와 TUN 설정을 함께 점검해야 합니다. DNS 주소 하나만 바꿔서는 모든 조회 경로가 바뀌지 않을 수 있습니다.
HTTPS를 통해 DNS 조회를 보내는 해석 방식으로, 흔히 HTTPS 주소 형태로 설정합니다. 리졸버 주소로 연결되는 경로, 도메인 선행 조회와 라우팅 규칙이 완전한 연결 경로를 이루는지 확인해야 합니다. 리졸버 주소 자체에 연결할 수 없으면 이후 도메인 조회도 실패합니다.
보안 매개변수는 프로토콜 인증, 전송 암호화와 인증서 검증 등 여러 계층에 나뉘어 있습니다. 필드 이름이 올바르다고 조합까지 유효한 것은 아니므로 설정을 서버와 항목별로 맞춰야 합니다.
네트워크 연결에 암호화와 서버 인증을 제공하는 표준 보안 프로토콜입니다. 클라이언트의 서버 이름, 인증서 검증과 애플리케이션 계층 프로토콜 매개변수는 서버 설정과 대응해야 합니다. TLS 핸드셰이크는 애플리케이션 데이터 전송 전에 수행되며, 실패하면 일반적으로 프로토콜 인증 단계로 넘어가지 못합니다.
VMess, VLESS 등의 설정에서 자주 사용하는 사용자 인증 식별자입니다. 서버에 등록된 값과 일치해야 하며, 노드 이름이나 서버 주소가 아닌 연결 자격 증명으로 관리해야 합니다. 설정을 복사할 때는 전체 문자와 하이픈 구조를 그대로 보존해야 합니다.
TLS 연결에서 서버의 신원을 증명하고 신뢰 체인을 구축하는 데이터입니다. 도메인, 유효 기간과 발급 관계에 따라 클라이언트의 검증 성공 여부가 달라집니다. 인증서 오류가 발생하면 먼저 시스템 시간, 연결 도메인과 서버 이름 설정을 확인해야 합니다.
읽을 수 있는 데이터를 키나 보안 세션이 있어야 복원할 수 있는 형태로 변환하는 과정입니다. 프로토콜마다 암호화를 담당하는 계층이 다르며, 일부는 외부 TLS에 의존하고 일부는 프로토콜 자체의 처리를 포함합니다. 연결 구조를 판단할 때는 프로토콜 계층, 전송 계층과 클라이언트 코어 구현을 함께 확인해야 합니다.