VMess
Project V 생태계의 프록시 프로토콜로, 사용자 인증과 데이터 보호 기능을 포함하며 일반적으로 UUID로 사용자를 식별합니다. VMess는 여러 전송 방식과 조합할 수 있으므로 프로토콜 이름만 보고 WebSocket이나 TLS 사용 여부를 판단할 수 없습니다. 인증 오류가 발생하면 사용자 식별자뿐 아니라 시스템 시간과 현재 코어에 맞는 설정 형식인지도 확인하세요.
더 읽기: WebSocket 전송 방식 →설정 항목 참고 · 자주 쓰는 용어 26개
V2Ray 용어 정리
먼저 프로토콜, 코어, 전송 방식을 구분한 뒤 라우팅과 테스트 결과를 살펴보세요. 클라이언트에서 만나는 용어를 찾아보고, 각 항목의 앵커로 바로 이동할 수 있습니다.
읽는 순서
클라이언트가 설정을 관리하고 → 코어가 연결을 처리하며 → 프로토콜이 요청을 구성하고 → 전송 및 보안 설정이 데이터를 전달합니다. 구독은 설정을 업데이트하지만 연결 품질을 결정하지는 않습니다.
요청 형식과 사용자 인증
프록시 프로토콜
프로토콜 이름은 연결 설정의 일부일 뿐입니다. 전송 방식, 보안 계층, 서버 측 매개변수도 각각 확인해야 합니다.
VLESS
가벼운 프록시 프로토콜로, 자체적으로 애플리케이션 데이터를 암호화하지 않습니다. 연결은 보통 TLS나 REALITY 같은 외부 보안 계층으로 보호합니다. UUID, 전송 방식, 보안 설정, flow를 함께 확인해야 하며 서버 주소만 바꿔서는 안 됩니다. 설정의 flow는 속도 단계가 아닙니다. 클라이언트 코어와 서버가 해당 조합을 모두 지원할 때만 입력하세요.
더 읽기: REALITY 보안 설정 →Trojan
일반적으로 TLS 연결을 통해 프록시 요청을 전달하고 비밀번호로 인증하는 프로토콜입니다. 비밀번호가 맞아도 연결 설정 전체가 올바르다는 뜻은 아닙니다. 서버 이름, 인증서 검증, 연결 포트도 일치해야 합니다. TLS 핸드셰이크 오류가 발생하면 먼저 보안 계층을 확인하고, 핸드셰이크가 성공한 뒤 인증 매개변수를 점검하는 편이 효율적입니다.
더 읽기: TLS와 인증서 검증 →Shadowsocks
정해진 암호화 방식과 키로 프록시 트래픽을 보호하는 프로토콜 계열이며, 방식과 확장 기능에 따라 호환되지 않을 수 있습니다. 클라이언트의 방식 이름과 비밀번호, 확장 매개변수가 있다면 원래 설정과 일치시켜야 합니다. 노드를 가져올 수 있다는 것은 설정 형식을 읽었다는 뜻일 뿐, 선택한 코어가 해당 방식을 지원하는지는 별도로 확인해야 합니다.
더 읽기: 노드에 포함된 매개변수 →화면은 관리하고, 코어는 실행합니다
코어와 클라이언트
문제를 문의할 때는 클라이언트 이름과 버전, 실행 중인 코어를 각각 기록해 화면 문제와 연결 문제를 구분하세요.
V2Ray
Project V 생태계의 네트워크 프록시 도구 이름으로, 일상적인 대화에서는 관련 클라이언트와 설정 체계를 통칭하기도 합니다. 따라서 “V2Ray에 연결할 수 없다”는 말만으로는 어느 계층에 문제가 있는지 알기 어렵습니다. 문제를 진단하려면 사용 중인 그래픽 클라이언트와 실제 실행 중인 코어, 각각의 버전을 확인한 뒤 로그를 살펴보세요.
단계별 문제 해결 보기 →V2Fly
V2Ray 관련 개발을 이어가는 커뮤니티 프로젝트로, 프록시 코어가 연결, 라우팅, DNS 등을 처리합니다. 클라이언트 화면의 “v2fly”는 일반적으로 코어 선택을 가리키며 구독 형식이나 특정 노드 프로토콜을 뜻하지 않습니다. 구독에 다른 코어 전용 설정이 포함되어 있다면 V2Fly로 전환한 뒤 그대로 사용할 수 없을 수 있으므로 기능 호환 범위를 먼저 확인하세요.
함께 읽기: Xray 코어 →Xray
V2Ray와 기술적 뿌리를 공유하는 프록시 코어 프로젝트로, 프로토콜 연결, 라우팅, 전송을 처리합니다. V2Fly와 기능, 설정 항목, 지원 조합이 다르므로 이름만 다를 뿐 완전히 호환된다고 볼 수 없습니다. REALITY나 특정 flow를 사용한다면 코어 종류와 실행 중인 버전이 서버 측 요구 사항을 지원하는지 모두 확인하세요.
더 읽기: REALITY와 코어 지원 →v2rayN
프록시 설정과 구독 그룹을 관리하고 코어를 실행하는 데스크톱 그래픽 클라이언트입니다. Windows, macOS, Linux를 지원합니다. 화면 옵션, 권한, 코어 지원 여부는 버전과 배포 패키지에 따라 다르며 기존 인터페이스와 크로스 플랫폼 인터페이스도 다를 수 있습니다. 사용법을 참고할 때는 버튼 위치보다 설정 이름과 기능을 확인하세요.
데스크톱 클라이언트 빠른 시작 보기 →v2rayNG
Android용 그래픽 프록시 클라이언트로, 연결 처리에 주로 Xray 코어를 사용합니다. 시작할 때 요청하는 VPN 서비스 권한은 로컬 트래픽을 가로채는 통로를 만드는 데 쓰이며, 트래픽이 원격 노드에 도달했다는 뜻은 아닙니다. 요청이 프록시를 통하는지는 앱별 설정, 라우팅 규칙, 노드 사용 가능 여부에도 영향을 받습니다.
권한 및 앱별 설정 보기 →v2flyNG
Android에서 V2Fly 코어를 사용하는 그래픽 클라이언트로, 관련 설정에 대한 대안으로 사용할 수 있습니다. 이름과 사용 방식이 비슷해도 v2rayNG가 지원하는 코어 기능과 완전히 같지는 않습니다. 노드를 옮길 때는 프로토콜과 전송 설정을 다시 확인하고, 시스템 권한과 백그라운드 실행 제한도 별도로 점검하세요.
Android 클라이언트 안내 보기 →데이터 전송과 보호 방식
전송 계층과 암호화
클라이언트 설정에서 쓰이는 방식에 따라 분류했습니다. TLS와 REALITY는 보안 방식이고, WebSocket과 gRPC는 주로 전송 방식으로 사용되므로 같은 계층에 속하지 않습니다.
TLS
전송 연결을 보호하고 상대방의 신원을 확인하는 보안 프로토콜입니다. 프록시 프로토콜은 TLS로 만든 보안 채널을 통해 데이터를 전달할 수 있습니다. 서버 이름은 보통 인증서 검증과 핸드셰이크에 사용되므로 다른 도메인으로 임의 변경하면 안 됩니다. 인증서 오류가 발생하면 시스템 시간, 이름, 인증서 유효 기간, 신뢰 체인을 확인하고 인증서 검증 건너뛰기를 무작정 켜지 마세요.
함께 읽기: Trojan의 보안 계층 →WebSocket（ws）
HTTP 핸드셰이크로 양방향 통신을 설정하는 전송 방식으로, 설정에서 ws라고 줄여 쓰기도 합니다. 프록시 프로토콜은 아니며, 사용한다고 해서 TLS까지 자동으로 활성화되는 것은 아닙니다. 하나의 프록시 프로토콜을 여러 전송 방식으로 구성할 수 있습니다. 경로, Host, TLS 서버 이름은 각각 별도 설정이므로 리버스 프록시를 사용할 때는 서버 설정과 하나씩 대조해야 합니다.
더 읽기: TLS 서버 이름 →gRPC
주로 HTTP/2를 기반으로 하는 통신 프레임워크로, 프록시 코어에서 전송 방식으로 사용할 수 있습니다. 클라이언트의 서비스 이름은 서버 및 리버스 프록시 설정과 일치해야 하며 WebSocket 경로로 대신할 수 없습니다. 리버스 프록시를 통해 전달한다면 중간 구간이 HTTP/2와 gRPC 요청을 올바르게 처리하는지도 확인하세요.
연결 및 전송 오류 해결 방법 보기 →REALITY
Xray 생태계의 전송 보안 방식으로, VLESS와 함께 쓰이는 경우가 많지만 독립적인 프록시 프로토콜은 아닙니다. 서버 이름, 공개 키, shortId 등의 값이 일치해야 하며 세부 항목과 지원 조합은 코어 버전에 따라 다릅니다. 클라이언트에 필요한 공개 키와 서버의 개인 키를 혼동하지 마세요. 화면에서 REALITY를 선택했다는 것만으로 설정이 완성된 것도 아닙니다.
함께 읽기: VLESS와 flow →요청이 프록시로 들어오는지, 들어온 뒤 어디로 가는지
라우팅과 DNS
트래픽 분기를 진단하기 전에 앱 트래픽이 클라이언트로 전달되는지 확인하세요. DNS 문제를 살펴보기 전에는 앱, 시스템, 코어 중 어디에서 도메인을 해석하는지 확인해야 합니다.
라우팅 규칙과 트래픽 분기
도메인, IP, 포트 등의 조건에 따라 요청을 직접 연결, 프록시 또는 차단으로 보내는 규칙 체계입니다. 규칙의 적용 순서, 하나의 규칙 안에서 여러 조건을 조합하는 방식, 일치하는 규칙이 없을 때 사용할 기본 출구가 함께 결과를 결정합니다. 클라이언트의 “전역”은 보통 라우팅 사전 설정의 이름일 뿐이며, 모든 앱의 트래픽이 자동으로 클라이언트에 전달된다는 뜻은 아닙니다.
구분해서 읽기: 시스템 프록시 →GeoIP
라우팅에서 IP 주소 범위를 기준으로 매칭하는 규칙 데이터로, 보통 지역이나 용도별로 분류합니다. 실시간 위치 확인 서비스가 아니며 네트워크 배치에 따라 주소의 소속이 바뀔 수 있고, 매칭 정확도는 데이터 업데이트 상태에도 영향을 받습니다. 대상 서비스가 여러 IP를 사용한다면 실제 연결된 IP에 따라 적용되는 규칙이 달라질 수 있습니다.
함께 읽기: 도메인 기반 GeoSite →GeoSite
도메인을 사이트, 서비스, 범주별로 정리해 이름을 기준으로 출구를 선택하는 규칙 데이터입니다. 범주를 사용할 수 있는지는 클라이언트가 실제로 불러온 데이터 파일에 따라 달라지므로 임의의 태그를 입력해서는 안 됩니다. 도메인 분류와 IP 분류가 일대일로 대응하지 않을 수 있습니다. 규칙을 추가한 뒤에는 매칭 로그로 결과를 확인하세요.
더 읽기: 규칙 순서와 기본 출구 →DNS
도메인을 IP 주소 등의 레코드로 변환하는 시스템으로, 도메인 접속 과정의 한 단계입니다. 앱, 운영체제, 프록시 코어가 각자 DNS 조회에 관여할 수 있으므로 클라이언트의 DNS 주소 하나를 바꿔도 모든 조회가 같은 경로로 전환되는 것은 아닙니다. 문제를 진단할 때는 누가 조회를 시작했는지, 어떤 출구를 사용했는지, 결과가 캐시에서 왔는지 확인해야 합니다.
더 읽기: DNS 조회 경로 →FakeDNS
가상 IP와 도메인 매핑을 이용해 트래픽을 처리하는 방식으로, 반환된 주소는 대상 서버의 실제 주소가 아닙니다. 이후 요청이 코어에 들어오면 저장된 매핑을 바탕으로 도메인을 복원한 뒤 라우팅과 연결을 진행해야 합니다. DNS 응답과 트래픽 가로채기 범위가 맞지 않거나 기존 매핑이 사라졌는데 앱에 캐시가 남아 있으면 접속에 실패할 수 있습니다.
FakeDNS 원리와 사용 사례 보기 →DNS 누출
DNS 조회가 의도한 해석 경로를 거치지 않고 다른 경로로 전송되는 현상입니다. 누출 여부를 판단하기 전에 먼저 기대하는 정책을 명확히 해야 합니다. 조회가 직접 연결되더라도 명시적으로 설정한 로컬 해석 규칙이라면 문제가 아닐 수 있습니다. 문제를 진단할 때 시스템 DNS, 브라우저 보안 DNS, 앱 내장 DNS, 코어 DNS를 각각 확인하세요. 한 번의 테스트 결과만으로 판단해서는 안 됩니다.
DNS 해석 흐름으로 돌아가기 →시스템 프록시
운영체제가 앱에 제공하는 프록시 주소 설정입니다. 앱이 이 설정을 따를지는 자체 구현에 따라 다르며, 일부 프로그램은 별도의 네트워크 설정을 사용합니다. 이 설정은 요청이 로컬 프록시로 들어갈지 결정하고, 코어 라우팅은 요청을 받은 뒤 사용할 출구를 결정합니다. 수신 포트를 바꾼 뒤에는 시스템 프록시가 가리키는 주소도 확인하세요. 클라이언트를 종료하기 전에는 프록시 설정이 올바르게 복원됐는지 확인해야 합니다.
함께 읽기: TUN 트래픽 가로채기 →TUN 모드
가상 네트워크 인터페이스와 시스템 라우팅을 이용해 IP 트래픽을 가로채는 방식으로, 시스템 프록시를 사용하지 않는 일부 앱에 적합합니다. 일반적으로 추가 권한이 필요하며 DNS 설정, 라우팅 테이블, 다른 네트워크 소프트웨어와 상호작용하지만 모든 앱이나 프로토콜을 가로채는 것은 아닙니다. 시작 후 기존 네트워크에 문제가 생기면 라우팅 충돌과 DNS 경로를 확인하세요. 여러 트래픽 가로채기 도구를 동시에 겹쳐 사용하지 않는 것이 좋습니다.
시스템 네트워크 및 권한 문제 해결 보기 →설정 가져오기와 연결 테스트
구독과 노드
업데이트 성공, 노드 사용 가능, 적절한 속도는 서로 다른 판단입니다. 테스트할 때는 동일한 방식과 대상을 유지한 뒤 결과를 비교하세요.
구독
링크를 통해 여러 노드 설정을 가져오고 업데이트하는 배포 방식이며, 클라이언트에서는 보통 구독 그룹으로 관리합니다. 업데이트 성공은 내용을 가져와 파싱했다는 뜻일 뿐, 모든 노드에 연결할 수 있다는 의미는 아닙니다. 구독 링크에는 접근 권한 정보가 포함될 수 있으므로 스크린샷, 공개 로그, 문의 글에 전체 링크를 노출하지 마세요.
구독 가져오기 절차 보기 →노드
클라이언트에서 선택해 연결할 수 있는 원격 연결 설정입니다. 보통 서버 주소, 포트, 프로토콜, 인증, 전송 매개변수가 포함됩니다. 표시 이름은 메모일 뿐이므로 서버 위치, 네트워크 경로, 실제 성능을 알 수 없습니다. 이름이 같은 노드도 설정이 다를 수 있으므로 문제를 진단할 때는 목록의 이름이 아니라 구체적인 항목을 비교하세요.
노드 연결 시간 초과 해결 순서 보기 →지연 시간 테스트
특정 테스트 작업에 걸리는 시간을 측정하는 절차입니다. ICMP 응답, TCP 연결 설정, 프록시를 통한 요청까지 걸리는 시간 등이 측정 대상일 수 있습니다. 테스트 방식마다 확인하는 구간이 달라 결과를 직접 비교할 수 없습니다. 지연 시간이 낮다고 지속적인 다운로드 속도가 빠른 것도 아닙니다. 다운로드 속도는 대역폭, 혼잡도, 대상 서비스, 기기 부하에도 영향을 받습니다.
더 읽기: 실제 연결 지연 →실제 연결 지연
일반적으로 클라이언트가 선택한 프록시를 통해 지정된 테스트 주소에 실제 요청을 보내고 걸린 시간을 측정한 값입니다. 구체적인 측정 방식은 클라이언트 버전에 따라 다릅니다. 단순 포트 연결 테스트보다 많은 구간을 확인하지만 해당 대상과 측정 당시의 조건만 반영합니다. 시간 초과는 테스트 주소, DNS, 핸드셰이크, 라우팅 문제 때문일 수 있습니다. 로그와 실제 접속 결과를 함께 확인해야 하며 서버가 중단됐다고 단정해서는 안 됩니다.
테스트 시간 초과 및 접속 오류 해결 보기 →문제에 맞는 항목 찾아보기
직접 설정하려면 가이드에 따라 가져오기, 모드 선택, 연결 확인을 차례로 진행하세요. 오류가 발생했다면 증상에 맞는 문제 해결 문서를 참고하세요. 이 문서는 개념을 설명하며 클라이언트 버전별 기본 포트나 화면 위치를 통일해 안내하지 않습니다.