PROTOCOLS & TRANSPORTS
프로토콜 및 전송: 연결 매개변수 조합 방식
프로토콜은 인증과 데이터 캡슐화 방식을 정의하고, 전송 계층은 TCP, WebSocket 또는 HTTP/2 같은 채널로 데이터를 전달합니다. 두 종류의 매개변수는 서버 설정과 일치해야 하며, 프로토콜 이름만 보고 바꿀 수 없습니다.
- VMess
- VMess는 Project V 생태계의 프록시 프로토콜로, 사용자 식별자와 시간 검증 및 암호화 매개변수를 사용해 클라이언트와 서버가 통신합니다. 클라이언트 설정에는 보통 주소, 포트, 사용자 ID, 전송 방식 및 보안 계층이 함께 포함됩니다. 시간이 크게 어긋나면 인증 단계에서 연결이 실패할 수 있습니다.
- VLESS
- VLESS는 구조가 단순한 프록시 프로토콜로, 자체적으로 데이터 암호화를 중복 제공하지 않고 TLS, REALITY 같은 보안 계층과 함께 사용합니다. 설정 시 프로토콜·전송·보안 매개변수를 각각 확인해야 하며, VLESS를 완전한 전송 방식으로 보면 안 됩니다. VLESS over TCP와 VLESS over WebSocket 조합이 흔히 사용됩니다.
- Trojan
- Trojan은 TLS로 보안 연결을 설정하며, 클라이언트에 서버 주소, 포트, 인증 정보, 서버 이름 등의 매개변수가 필요합니다. 인증서 이름, 시스템 시간 및 서버 설정이 모두 핸드셰이크에 영향을 줍니다. 링크를 가져온 뒤에도 전송 보안 옵션이 빠짐없이 설정되었는지 확인해야 합니다.
- Shadowsocks
- Shadowsocks는 사전 공유 비밀번호와 지정된 암호화 방식으로 데이터를 처리합니다. 통신을 완료하려면 클라이언트와 서버에서 완전히 동일한 암호화 방식을 선택해야 합니다. 설정 필드는 비교적 단순하지만 플러그인, 전송 확장 및 포트 정보도 항목별로 일치해야 합니다.
- REALITY
- REALITY는 Xray 생태계의 전송 보안 방식으로, VLESS 및 TCP와 자주 조합됩니다. 클라이언트에서 흔히 사용하는 필드는 공개 키, 짧은 ID, 서버 이름 및 지문입니다. 어느 하나라도 서버와 다르면 연결이 핸드셰이크 단계에서 멈출 수 있습니다.
- WebSocket
- WebSocket은 HTTP 연결 업그레이드 메커니즘으로 양방향 통신을 설정하는 전송 방식이며, 설정에는 보통
ws로 입력합니다. 경로와 요청 헤더는 전송 매개변수이므로 서버와 일치해야 합니다. 리버스 프록시가 경로에 포함된다면 업그레이드 요청이 정상적으로 전달되는지도 확인해야 합니다.
- gRPC
- gRPC는 HTTP/2 기반 원격 호출 전송 방식으로, V2Ray 설정에서 프로토콜 데이터를 전달하는 데 사용됩니다. 클라이언트와 서버의 서비스 이름을 일치시키고 TLS 등 보안 옵션을 올바르게 설정해야 합니다. WebSocket과 필드 구조가 다르므로 네트워크 유형만 바꾸고 기존 매개변수를 그대로 사용할 수 없습니다.
CORE & ECOSYSTEM
코어 및 생태계: 저수준 기능과 그래픽 인터페이스
코어는 프로토콜·전송·라우팅·DNS를 담당하고, 그래픽 클라이언트는 설정 관리와 시스템 통합을 담당합니다. 인터페이스 이름과 코어 이름은 같은 개념이 아니며, 동일한 클라이언트 버전에서도 서로 다른 코어 옵션을 제공할 수 있습니다.
- Project V
- Project V는 프록시 코어, 프로토콜 및 도구를 중심으로 형성된 오픈 소스 기술 생태계를 뜻합니다. 특정 Android 앱이나 단일 설치 패키지의 이름이 아닙니다. V2Fly는 관련 코어 기능을 이어받았고, Xray는 자체 프로토콜 및 전송 확장을 발전시켰습니다.
- V2Fly
- V2Fly는 커뮤니티가 지속적으로 유지 관리하는 V2Ray 코어 프로젝트로, 프로토콜 처리, 인바운드·아웃바운드, 라우팅 및 DNS 등 저수준 기능을 담당합니다. 그래픽 클라이언트는 코어를 호출해 설정을 읽고 연결을 설정합니다. v2flyNG는 주로 이 코어를 기반으로 Android 그래픽 인터페이스를 제공합니다.
- Xray
- Xray는 V2Ray 설정 체계와 밀접한 관련이 있는 프록시 코어로, VLESS, REALITY, 라우팅, DNS 및 다양한 전송 조합을 지원합니다. v2rayNG는 일반적으로 Xray 코어를 사용하며, v2rayN도 해당 Core를 관리할 수 있습니다. 설정 필드를 인식하지 못하면 먼저 현재 코어와 버전의 지원 범위를 확인해야 합니다.
- v2rayN
- v2rayN은 Windows, macOS 및 Linux용 그래픽 클라이언트입니다. 구독, 서버, 시스템 프록시, 라우팅 모드 및 코어를 관리하며 V2Ray 코어 자체와는 다릅니다. 데스크톱에서 연결은 정상인데 애플리케이션이 프록시를 사용하지 않는다면 시스템 프록시 또는 TUN 설정도 확인해야 합니다.
- v2rayNG
- v2rayNG는 Android용 그래픽 클라이언트로, 일반적으로 Xray 코어를 사용합니다. 연결 후 시스템 VPN 인터페이스를 통해 선택한 범위의 네트워크 트래픽을 가로채고, 라우팅 설정에 따라 아웃바운드를 선택합니다. 구독 가져오기, 앱별 프록시 및 배터리 백그라운드 정책은 모두 클라이언트 계층의 설정입니다.
- v2flyNG
- v2flyNG는 Android용 V2Fly 코어 클라이언트로, 구독과 표준 공유 링크를 가져올 수 있습니다. V2Fly 설정 체계를 사용해야 하는 환경에 적합합니다. 클라이언트를 선택하기 전에 구독에서 사용하는 프로토콜과 전송 매개변수를 해당 코어가 지원하는지 확인해야 합니다.
SUBSCRIPTIONS & NODES
구독 및 노드: 설정이 클라이언트에 들어오는 방식
구독은 설정을 일괄 배포하고, 노드는 해석 후 선택할 수 있는 개별 서버 항목입니다. 속도 측정 결과는 현재 탐색 조건만 보여줄 뿐, 프로토콜 매개변수 점검이나 실제 연결 확인을 대신할 수 없습니다.
- 구독
- 구독은 서버가 제공하는 설정 모음 주소로, 클라이언트가 해당 주소에 요청을 보내 서버 항목을 해석합니다. 구독을 갱신하면 추가·변경·삭제된 설정이 동기화되지만, 일반적으로 로컬 라우팅 충돌까지 자동으로 해결하지는 않습니다. 링크 만료, 접근 거부 또는 반환 형식 오류가 있으면 갱신에 실패합니다.
- 노드
- 노드는 클라이언트에 저장된 서버 설정 항목으로, 보통 주소, 포트, 프로토콜, 인증 매개변수, 전송 및 보안 설정을 포함합니다. 노드 이름은 식별을 위한 라벨일 뿐 실제 연결 방식을 결정하지 않습니다. 사용 가능 여부를 판단하려면 전체 필드를 확인하고 실제 연결을 테스트해야 합니다.
- 지연 시간
- 지연 시간은 탐색 요청을 클라이언트에서 보낸 뒤 응답을 받기까지 걸리는 시간이며, 보통 밀리초로 표시됩니다. 클라이언트마다 TCP, HTTP 또는 다른 탐색 방식을 사용할 수 있으므로 결과를 단순 비교할 수 없습니다. 수치는 로컬 네트워크, 대상 주소 및 서버의 순간 부하에도 영향을 받습니다.
- 실제 연결 지연 시간
- 실제 연결 지연 시간은 대상 노드를 통해 실제 프록시 연결을 설정한 뒤 측정한 응답 시간입니다. 프로토콜 핸드셰이크, 전송 보안 및 프록시 아웃바운드 과정을 포함하므로 단순 포트 연결성 테스트보다 현재 설정 상태를 잘 반영합니다. 테스트 대상이 다르면 결과에도 큰 차이가 날 수 있습니다.
- 구독 그룹
- 구독 그룹은 구독 출처와 노드를 분류하는 클라이언트 관리 단위입니다. 그룹별로 갱신·필터링·활성 서버 선택을 수행할 수 있어 여러 구독을 하나의 목록에 섞지 않고 관리하기 편합니다. 그룹을 삭제하기 전 로컬 수동 설정도 작업 범위에 포함되는지 확인해야 합니다.
ROUTING & DNS
라우팅 및 분기: 연결이 최종적으로 향하는 곳
라우팅은 도메인, IP, 포트 또는 프로세스를 기준으로 아웃바운드를 매칭하고, DNS는 도메인 해석 방식과 라우팅이 올바른 대상 정보를 얻을 수 있는지에 영향을 줍니다. 규칙 순서, 데이터 파일 및 스니핑 설정이 함께 매칭 결과를 바꿉니다.
- 라우팅 규칙
- 라우팅 규칙은 도메인, IP, 포트, 네트워크 프로토콜 또는 프로세스 등의 조건에 따라 프록시, 직접 연결 또는 차단 아웃바운드를 선택합니다. 여러 규칙이 있으면 일반적으로 코어가 정한 순서대로 매칭합니다. 규칙이 일치하지 않을 때의 기본 아웃바운드도 중요하므로 예상 모드와 함께 확인해야 합니다.
- 라우팅 분기
- 라우팅 분기는 라우팅 규칙을 이용해 서로 다른 연결을 각기 다른 아웃바운드로 보내는 처리 방식입니다. 도메인 유형, 대상 IP, 포트 또는 앱 프로세스별로 범위를 나눌 수 있습니다. 문제가 생기면 먼저 클라이언트가 도메인 정보를 확보했는지 확인한 뒤 규칙 순서와 기본 아웃바운드를 점검해야 합니다.
- GeoIP
- GeoIP는 IP 주소의 지역 또는 네트워크 유형별로 구성한 규칙 데이터입니다. 코어는 대상 IP를 확인한 뒤 해당 분류를 참조해 연결의 아웃바운드를 결정할 수 있습니다. GeoIP 데이터는 코어가 지원하는 형식과 일치해야 하며, 오래된 데이터는 새 주소 대역의 분류에도 영향을 줄 수 있습니다.
- GeoSite
- GeoSite는 용도 또는 도메인 유형별로 정리한 규칙 데이터로, 라우팅 설정에서 분류 태그를 직접 참조할 수 있습니다. 도메인 집합을 처리하며 GeoIP의 주소 분류와는 다릅니다. 연결 단계에 대상 IP만 남아 있다면 도메인 매칭 조건을 복원하기 위해 스니핑이나 DNS 정보가 필요할 수 있습니다.
- TUN 모드
- TUN 모드는 가상 네트워크 인터페이스를 통해 시스템 트래픽을 수신하므로 시스템 프록시 설정을 직접 읽지 않는 프로그램도 처리할 수 있습니다. 추가 시스템 권한이 필요할 수 있으며 라우팅 테이블, DNS 및 네트워크 인터페이스 설정이 함께 관여합니다. 활성화 후에는 다른 가상 네트워크 도구가 같은 트래픽 범위를 동시에 가로채지 않도록 해야 합니다.
- FakeDNS
- FakeDNS는 예약 주소 풀의 가상 IP로 도메인 조회에 응답하고 후속 연결에서 원래 도메인을 복원합니다. 이를 통해 라우팅이 더 이른 단계에서 도메인별 분류를 수행하고 일부 중복 조회를 줄일 수 있습니다. 일반적으로 TUN, 스니핑 및 올바른 DNS 흐름과 함께 구성해야 합니다.
- DNS 누출
- DNS 누출은 일부 도메인 조회가 예상한 DNS 처리 경로를 우회해 다른 리졸버로 직접 전달되는 현상입니다. 시스템 리졸버, 브라우저 보안 DNS, TUN 설정 및 클라이언트 내장 DNS를 주로 점검합니다. 먼저 어느 앱에서 조회가 발생했는지 확인한 뒤 해석 경로를 통일해야 합니다.
CLIENT FEATURES
클라이언트 기능: 인터페이스 스위치의 실제 역할
클라이언트 스위치는 주로 트래픽이 코어로 들어가는 방식과 설정이 운영체제에 적용되는 방식을 제어합니다. 연결 상태가 정상으로 표시되어도 코어가 실행 중이라는 의미일 뿐이며, 앱이 해당 경로를 사용하는지는 시스템 프록시, TUN 또는 앱별 범위에 따라 달라집니다.
- 시스템 프록시
- 시스템 프록시는 운영체제가 애플리케이션에 제공하는 프록시 설정입니다. v2rayN은 로컬 HTTP 또는 SOCKS 리스닝 주소를 시스템 설정에 기록할 수 있으며, 시스템 프록시를 지원하는 프로그램은 이후 연결을 클라이언트로 전달합니다. 일부 프로그램은 이 설정을 무시하므로 TUN이나 프로그램 자체의 프록시 옵션을 고려해야 합니다.
- 전역 프록시
- 전역 프록시는 일반적으로 클라이언트로 들어온 연결을 모두 프록시 아웃바운드로 보내고 일반적인 분류 규칙을 적용하지 않는 모드입니다. 복잡한 라우팅이 연결 문제를 일으키는지 확인할 때 적합합니다. 이미 클라이언트에 들어온 트래픽에만 영향을 주며 모든 앱이 자동으로 시스템 프록시를 읽는다는 뜻은 아닙니다.
- 트래픽 스니핑
- 트래픽 스니핑은 연결 초기 데이터에서 대상 도메인이나 프로토콜 특성을 식별해 도메인 라우팅과 FakeDNS 매핑에 정보를 제공합니다. 전체 통신 내용을 수집하는 인터페이스 기능이 아니라, 코어가 라우팅 단계에서 사용하는 식별 메커니즘입니다. 활성화 여부는 프로토콜, DNS 및 라우팅 규칙을 함께 고려해 결정해야 합니다.
- Mux
- Mux는 하나의 하위 연결에서 여러 논리 요청을 재사용해 연결을 반복해서 설정하는 비용을 줄입니다. 모든 네트워크와 프로토콜 조합에서 성능이 향상되는 것은 아니며, 모바일 네트워크 전환이 잦으면 재연결 영향이 커질 수도 있습니다. 변경하기 전에 서버 지원 여부를 확인하고 실제 앱에서 비교 테스트를 진행해야 합니다.
- 앱별 프록시
- 앱별 프록시는 어떤 Android 앱의 연결을 클라이언트가 처리할지 지정하는 기능입니다. 설정 방식은 보통 포함 모드와 제외 모드로 나뉘며 두 방식의 논리는 서로 반대입니다. 앱 범위를 변경한 뒤에는 연결을 다시 설정하고 대상 앱에 별도의 네트워크 프로세스가 있는지 확인해야 합니다.