v2rayN
v2rayN은 Windows, macOS, Linux용 그래픽 클라이언트로 구독 가져오기, 노드 선택, 시스템 프록시, TUN, 라우팅과 로그 확인 기능을 제공합니다. 클라이언트 자체는 주로 설정 관리와 조작 화면을 담당하며, 실제 프로토콜 연결은 선택한 코어가 처리합니다. 문제를 점검할 때는 화면 설정, 생성된 설정과 코어 실행 상태를 나누어 확인해야 합니다.
클라이언트 화면, 구독 내용과 고급 설정에서 반복해서 등장하는 기술 용어를 한곳에 정리했습니다. 각 항목은 개념의 범위, 설정 위치와 실제 역할을 설명해 튜토리얼을 읽거나 연결 문제를 해결할 때 빠르게 확인할 수 있도록 구성했습니다.
클라이언트는 그래픽 인터페이스, 구독과 시스템 설정을 담당하고, 코어는 설정을 해석해 연결을 수립하고 라우팅을 실행합니다. 둘을 구분하면 버전 선택과 문제 원인 파악이 훨씬 명확해집니다.
v2rayN은 Windows, macOS, Linux용 그래픽 클라이언트로 구독 가져오기, 노드 선택, 시스템 프록시, TUN, 라우팅과 로그 확인 기능을 제공합니다. 클라이언트 자체는 주로 설정 관리와 조작 화면을 담당하며, 실제 프로토콜 연결은 선택한 코어가 처리합니다. 문제를 점검할 때는 화면 설정, 생성된 설정과 코어 실행 상태를 나누어 확인해야 합니다.
v2rayNG는 Android 플랫폼용 그래픽 클라이언트로, 일반적으로 Xray 코어를 사용해 연결을 처리합니다. 구독이나 단일 공유 링크를 가져올 수 있으며, 현재 연결에 사용할 라우팅, DNS와 앱 범위를 설정할 수 있습니다. 휴대폰의 배터리 절약 정책, 백그라운드 제한과 VPN 권한도 클라이언트의 지속 실행에 영향을 줍니다.
v2flyNG 역시 Android용이지만 주로 V2Fly 코어를 사용합니다. 해당 코어 구현이 필요하거나 기존 V2Fly 설정에 익숙한 환경에 적합합니다. v2rayNG와 v2flyNG 중 무엇을 선택할지는 화면 이름보다 노드 프로토콜, 설정 필드와 코어 호환성을 기준으로 판단해야 합니다.
Xray는 Project V 생태계를 이루는 코어 제품군 중 하나로, 프로토콜 핸드셰이크, 전송 계층, 보안 계층, DNS와 라우팅 규칙을 처리합니다. 클라이언트는 화면 설정을 코어가 읽을 수 있는 설정으로 변환한 뒤 해당 프로세스를 실행합니다. 특정 프로토콜 필드를 사용할 수 있는지는 보통 클라이언트 버전과 코어 버전이 모두 지원하는지에 따라 달라집니다.
V2Fly는 커뮤니티가 지속적으로 유지 관리하는 Project V 코어 구현으로, 설정을 읽고 인바운드와 아웃바운드를 구성한 뒤 라우팅을 실행합니다. Xray와 일부 개념 및 설정 구조를 공유하지만, 실제 기능과 필드, 기본 동작은 다를 수 있습니다. 설정을 가져오기 전에는 클라이언트가 사용하는 코어 제품군을 확인해 다른 코어 전용 매개변수를 그대로 적용하지 않도록 해야 합니다.
프로토콜은 클라이언트와 서버가 연결 정보를 교환하는 방식을 정하고, 전송 계층과 보안 계층은 데이터의 전달 및 보호 방식을 정합니다. 세 요소는 서로 다른 설정 계층이므로 하나의 명칭으로 혼동해서는 안 됩니다.
VMess는 식별 정보와 시간 검증机制을 사용하는 프록시 프로토콜입니다. 일반적인 설정에는 서버 주소, 포트, 사용자 ID와 전송 방식이 포함됩니다. 클라이언트와 서버의 핵심 매개변수가 일치해야 하며, 로컬 시간 오차가 너무 커도 인증에 실패할 수 있습니다. VMess는 프로토콜 계층일 뿐이므로 실제 연결에는 TCP, WebSocket 등의 전송 설정도 필요합니다.
VLESS는 구조가 간결한 프록시 프로토콜로, 전송 보안을 TLS나 REALITY 같은 독립적인 방식에 맡기는 경우가 많습니다. 주소, 포트와 사용자 ID 외에도 흐름 제어, 전송 유형과 보안 계층 매개변수를 확인해야 합니다. VLESS라는 이름만으로 양쪽의 호환성을 판단할 수 없으며, 전체 조합을 항목별로 맞춰야 합니다.
Trojan은 TLS 사용 방식을 기반으로 설계된 프록시 프로토콜로, 일반적인 설정에는 서버 주소, 포트, 인증 정보와 인증서에 대응하는 도메인이 포함됩니다. 연결에 실패하면 프로토콜 인증 실패, TLS 핸드셰이크 실패와 도메인 조회 실패를 구분해야 합니다. 세 문제는 증상이 비슷할 수 있지만 로그에 나타나는 오류 단계는 대체로 다릅니다.
REALITY는 Xray 생태계에서 사용하는 전송 보안 방식으로, VLESS와 함께 쓰는 경우가 많습니다. 클라이언트 설정에는 일반적으로 서버 이름, 공개 키, 짧은 ID와 지문 등의 필드가 필요하며, 값은 서버 설정과 일치해야 합니다. REALITY는 노드 이름도, 독립적인 그래픽 클라이언트도 아니며 연결 보안 계층에서 작동합니다.
전송 계층은 프록시 프로토콜 데이터가 어떤 연결 방식으로 전달되는지를 나타내며, 일반적인 유형으로 TCP, WebSocket, gRPC와 HTTP 계열 전송이 있습니다. 전송 방식에 따라 경로, 호스트 이름 또는 서비스 이름처럼 사용하는 필드가 달라집니다. 노드를 가져온 뒤 전송 유형을 잘못 인식하면 주소와 인증 정보가 올바르더라도 연결할 수 없습니다.
구독은 일괄 업데이트에 사용하고, 노드는 하나의 연결 설정을 나타내며, 속도 측정 결과는 특정 테스트 조건만 설명합니다. 데이터의 출처를 이해해야 업데이트, 필터링과 전환 작업이 실제로 적용됐는지 판단할 수 있습니다.
구독은 서버가 제공하고 클라이언트가 정기적으로 읽는 노드 모음의 진입점입니다. 구독을 업데이트하면 보통 내용을 다시 가져온 뒤 클라이언트 규칙에 따라 노드를 추가, 덮어쓰기 또는 정리합니다. 구독 주소 자체는 연결 가능한 노드가 아니며, 클라이언트가 먼저 구체적인 설정으로 해석해야 선택해 사용할 수 있습니다.
노드는 클라이언트에 저장된 하나의 서버 연결 설정으로, 일반적으로 서버 주소, 포트, 프로토콜, 인증 매개변수, 전송 방식과 보안 설정을 포함합니다. 노드 이름은 식별을 위한 것일 뿐 연결 품질을 결정하지 않습니다. 노드 사용 가능 여부는 로그, 실제 연결 테스트와 실제 접속 결과를 함께 확인해야 합니다.
공유 링크는 하나의 노드 주요 매개변수를 특정 링크 형식으로 인코딩해 설정을 빠르게 가져올 때 사용합니다. 프로토콜마다 링크 구조가 다르며, 복잡한 라우팅이나 DNS 설정은 단일 링크에 포함되지 않을 수도 있습니다. 가져온 뒤 주소, 포트, 전송과 보안 필드가 제대로 인식됐는지 확인해야 합니다.
지연 시간은 탐색 요청이 왕복하는 데 걸리는 시간을 뜻하지만, 클라이언트마다 TCP 탐색, 프로토콜 핸드셰이크 또는 대상 접속 등 측정 방식이 다를 수 있습니다. 탐색 수치가 낮다고 다운로드 속도가 반드시 빠른 것은 아니며 회선 안정성도 단독으로 판단할 수 없습니다. 결과를 비교할 때는 측정 방식과 대상을 동일하게 유지해야 합니다.
실제 연결 지연 시간은 실제로 프로토콜 연결을 수립하거나 테스트 대상에 접속해 걸린 시간을 기록하므로, 단순히 포트만 확인하는 것보다 클라이언트의 실제 사용 과정에 가깝습니다. DNS, 핸드셰이크, 전송 계층과 대상 응답의 영향을 함께 받습니다. 포트 탐색은 정상인데 실제 연결에 실패한다면 인증과 전송 매개변수를 추가로 확인해야 합니다.
라우팅 규칙은 매칭을 담당하고 아웃바운드는 실행을 담당합니다. 규칙 순서, 도메인 조회 방식과 데이터 파일 상태에 따라 최종 매칭 결과가 달라집니다.
라우팅 규칙은 도메인, IP, 포트, 네트워크 유형, 프로토콜 또는 프로세스 등의 조건에 따라 트래픽을 어느 아웃바운드로 보낼지 결정합니다. 여러 규칙이 있으면 일반적으로 설정 순서대로 판단하며 먼저 매칭된 규칙이 먼저 실행됩니다. 규칙을 수정한 뒤에는 설정을 저장하고 해당 코어를 다시 실행해 이전 설정이 계속 사용되지 않도록 해야 합니다.
트래픽 분기는 대상이나 앱별 트래픽을 직접 연결, 프록시, 차단 또는 사용자 지정 아웃바운드로 나누는 과정입니다. 독립적인 프로토콜이 아니라 여러 라우팅 규칙이 함께 만드는 처리 전략입니다. 분기를 설계할 때는 먼저 기본 출구를 정한 뒤 범위가 명확한 예외 규칙을 추가해 규칙 간 충돌을 줄여야 합니다.
GeoIP는 IP 주소의 지역이나 용도별로 정리한 매칭 데이터로, 라우팅 규칙에서 특정 분류를 참조할 수 있습니다. 사용자가 입력한 도메인이 아니라 연결 대상 IP를 매칭합니다. 도메인을 먼저 조회한 뒤 IP를 판단해야 하는 규칙이라면 DNS 결과와 도메인 정책도 최종 매칭에 영향을 줍니다.
GeoSite는 분류별로 정리한 도메인 모음으로, 클라이언트나 코어가 라우팅 규칙에서 해당 분류를 참조할 수 있습니다. 도메인을 하나씩 관리하는 작업을 줄여 주지만 분류 내용은 데이터 버전에 따라 달라집니다. 도메인 매칭 결과가 예상과 다르면 분류 이름, 데이터 파일과 규칙 순서를 함께 확인해야 합니다.
아웃바운드는 트래픽이 코어를 빠져나갈 때 사용하는 처리 출구를 뜻하며, 일반적인 유형으로 프록시 연결, 직접 연결과 차단 처리가 있습니다. 라우팅 규칙은 아웃바운드를 선택할 뿐 실제 서버 연결은 해당 아웃바운드 설정이 수립합니다. 고급 설정에서는 여러 프록시 아웃바운드를 구성하고 규칙별로 호출할 수도 있습니다.
DNS는 도메인 조회 경로를 정하고 시스템 프록시와 TUN은 트래픽이 클라이언트로 들어오는 방식을 정합니다. 연결은 정상인데 트래픽 분기가 이상하다면 이 계층을 별도로 점검해야 합니다.
DNS는 도메인을 IP 주소로 변환하는 기본 네트워크 서비스입니다. V2Ray 클라이언트는 시스템 리졸버를 사용하거나 코어에 설정한 원격 또는 로컬 리졸버로 조회를 전달할 수 있습니다. 조회 결과는 실제 연결 주소뿐 아니라 GeoIP, 도메인 규칙과 FakeDNS의 판단 과정에도 영향을 줍니다.
DNS 유출은 도메인 조회가 예상한 경로로 처리되지 않고 설정에 없는 리졸버로 전달되는 현상입니다. 흔한 원인으로 앱이 직접 암호화 DNS를 요청하는 경우, 시스템 프록시가 DNS를 가로채지 못하는 경우, TUN 규칙 범위가 부족한 경우와 DNS 설정 우선순위 충돌이 있습니다. 점검할 때는 앱, 운영체제와 클라이언트 코어의 조회 경로를 각각 확인해야 합니다.
TUN 모드는 가상 네트워크 인터페이스로 더 넓은 범위의 시스템 트래픽을 가로챈 뒤 클라이언트 코어가 라우팅을 실행하도록 데이터를 전달합니다. 시스템 프록시 설정을 직접 읽지 않는 앱에 적합하지만 운영체제 권한과 올바른 라우팅 및 DNS 설정이 필요합니다. 활성화 후 LAN 접속이나 조회에 문제가 생기면 우회 범위와 DNS 가로채기 설정부터 확인해야 합니다.
FakeDNS는 앱에 매핑 주소를 반환하는 동시에 코어에 해당 주소와 원래 도메인의 관계를 저장합니다. 이후 앱이 매핑 주소에 연결해도 코어는 원래 도메인을 기준으로 라우팅을 매칭할 수 있습니다. TUN 모드와 함께 사용하는 경우가 많지만 주소 풀 범위와 제외 규칙을 잘못 설정하면 LAN이나 특정 앱에 영향을 줄 수 있습니다.
시스템 프록시는 프록시 서버 주소를 운영체제 설정에 기록하고, 해당 설정을 따르는 앱이 요청을 클라이언트로 전달하게 하는 방식입니다. 설정이 간단해 브라우저와 대부분의 시스템 네트워크 인터페이스 사용 소프트웨어에 적합하지만 모든 앱의 트래픽을 자동으로 포함하지는 않습니다. 특정 프로그램이 시스템 프록시를 읽지 않는다면 프로그램 자체 설정을 확인하거나 필요에 따라 TUN 모드를 검토해야 합니다.