V2Ray 용어집

그래픽 클라이언트는 구독을 가져오고 노드를 선택하며 프록시 모드를 조정하고 실행 상태를 확인하는 인터페이스입니다. 보통 설정을 생성하고 프록시 코어를 시작하지만, 하위 연결 구현 자체와 동일하지는 않습니다. 문제 해결 시 클라이언트 설정과 코어 실행 여부를 따로 확인해야 합니다.

프록시 코어는 설정을 읽고 프로토콜 핸드셰이크, DNS 조회, 라우팅 판단 및 연결 전달을 수행합니다. 그래픽 클라이언트에서 여러 코어를 선택할 수 있으므로 같은 화면에서 사용할 수 있는 기능도 코어의 역량에 따라 달라집니다. 코어 오류가 발생하면 시스템 프록시만 조정하지 말고 프로토콜 매개변수와 설정 문법을 확인해야 합니다.

v2rayN은 Windows, macOS 및 Linux용 그래픽 클라이언트로, 구독·노드·라우팅·로컬 프록시 설정을 관리합니다. 호환되는 프록시 코어를 호출해 연결을 처리할 수 있습니다. 클라이언트의 “시스템 프록시”와 “TUN”은 애플리케이션 연결 방식이며 노드 프로토콜 이름이 아닙니다.

Xray는 프록시 코어 계열 중 하나로, v2rayN 및 v2rayNG 같은 호환 클라이언트에서 호출할 수 있습니다. 프로토콜, 전송, 보안 계층 및 라우팅 설정을 실행하는 역할은 코어가 맡고, 클라이언트는 조작 화면을 제공합니다. 선택할 때는 필요한 프로토콜과 기능을 현재 코어가 지원하는지 확인해야 하며 클라이언트 이름만으로 판단해서는 안 됩니다.

V2Fly는 Project V 생태계의 커뮤니티 프로젝트이자 코어 구현 중 하나입니다. v2flyNG 같은 클라이언트 이름에 포함된 V2Fly는 보통 해당 코어 계열을 사용한다는 의미지만, 클라이언트 자체는 여전히 설정 관리 도구입니다. 설정을 가져오기 전에 서버 매개변수가 선택한 코어의 지원 범위와 맞는지 확인해야 합니다.

VMess는 인증 정보와 연결 매개변수를 포함하는 프록시 프로토콜입니다. 설정에서는 사용자 식별자, 주소, 포트 및 전송 관련 필드가 서로 맞아야 합니다. 프로토콜 이름만 바꾼다고 호환되지 않는 매개변수가 다른 프로토콜 설정으로 변환되지는 않습니다.

VLESS는 인증과 전송 계층의 역할을 분리한 프록시 프로토콜로, TLS·REALITY 또는 다양한 전송 방식과 함께 사용됩니다. VLESS 자체가 암호화된 전송을 의미하거나 애플리케이션의 로컬 프록시 연결 방식을 결정하지는 않습니다. 연결 문제를 해결할 때는 사용자 식별자, 흐름 제어, 보안 계층 및 전송 매개변수를 함께 확인해야 합니다.

Trojan은 일반적으로 TLS와 함께 사용하며 비밀번호로 인증합니다. 도메인, 포트, 비밀번호, SNI 및 인증서 관련 설정이 서버 구성과 맞아야 합니다. 시스템 프록시 활성화 여부는 일부 애플리케이션이 로컬 진입점을 사용할지만 결정할 뿐, 프로토콜 매개변수 불일치를 해결하지는 않습니다.

REALITY는 Xray 생태계의 연결 보안 메커니즘으로, 흔히 공개 키, 짧은 식별자, 서버 이름 및 클라이언트 지문을 설정합니다. 독립적인 그래픽 클라이언트나 시스템 프록시 모드가 아닙니다. 필드가 누락되거나 서로 맞지 않으면 보통 연결 수립 단계에서 실패합니다.

전송 방식은 프록시 프로토콜 데이터를 전달하는 연결 형식이며 TCP, WebSocket, HTTP/2 또는 gRPC 등이 있습니다. 전송 방식에 따라 경로, 서비스 이름 또는 요청 헤더 같은 추가 필드가 필요할 수 있습니다. 클라이언트와 서버는 호환되는 설정을 사용해야 하며 포트가 같은지만 비교해서는 안 됩니다.

구독은 서버에서 제공하며 하나 이상의 노드 설정을 포함하는 업데이트 가능한 주소입니다. 클라이언트가 구독을 요청하면 내용을 해석해 로컬 설정 목록에 기록합니다. 구독 자체는 프록시 코어가 아니며 브라우저나 터미널이 자동으로 프록시를 사용하게 만들지도 않습니다.

노드는 클라이언트에 저장된 서버 연결 설정 묶음으로, 보통 주소·포트·프로토콜·인증·보안 계층 및 전송 매개변수를 포함합니다. 노드 선택은 코어가 사용할 설정 묶음을 지정할 뿐입니다. 애플리케이션은 시스템 프록시, 수동 프록시 또는 TUN 등을 통해 별도로 연결되어야 합니다.

구독 업데이트는 클라이언트가 구독 내용을 다시 요청해 로컬 노드 목록을 갱신하는 작업입니다. 실패하면 주소 접속 불가, 인증 만료, 응답 형식 오류 및 로컬 네트워크 문제를 먼저 구분해야 합니다. 업데이트 성공은 목록을 가져왔다는 뜻일 뿐, 모든 노드가 연결된다는 의미는 아닙니다.

지연 시간은 특정 측정 방식으로 얻은 응답 소요 시간이며 테스트 대상, 조회 과정, 네트워크 경로 및 당시 부하의 영향을 받습니다. 클라이언트나 측정 방식이 다르면 결과를 직접 비교하기 어렵습니다. 측정값이 낮아도 실제 연결 테스트를 대신할 수는 없습니다.

실제 연결 지연 시간은 보통 프록시 연결을 실제로 수립하고 지정된 대상에 접속해 얻은 소요 시간을 뜻합니다. 단순 네트워크 연결 테스트보다 많은 프로토콜 및 핸드셰이크 과정을 포함하므로 현재 프록시 경로 상태를 더 잘 반영합니다. 테스트 실패 시 코어 오류를 함께 확인해 노드 매개변수, DNS 또는 TLS 단계의 문제인지 판단해야 합니다.

시스템 프록시는 운영체제가 이 설정을 지원하는 애플리케이션에 프록시 주소와 포트를 알려 주는 연결 방식입니다. 일반적인 브라우저는 이를 읽지만 일부 터미널 프로그램, 독립 네트워크 스택 또는 프록시를 자체 관리하는 애플리케이션은 무시할 수 있습니다. 브라우저는 되지만 터미널이 되지 않는다면 두 애플리케이션의 프록시 출처를 따로 확인해야 합니다.

로컬 리스너는 프록시 코어가 로컬 주소와 포트에서 애플리케이션 연결을 기다리는 진입점입니다. HTTP, SOCKS 또는 혼합 리스너가 흔히 사용됩니다. 시스템 프록시와 애플리케이션 프록시 설정은 보통 이곳을 가리킵니다. 리스너 포트를 바꾸면 이전 포트를 수동으로 입력한 모든 애플리케이션도 함께 수정해야 합니다.

애플리케이션 프록시 설정은 브라우저, 다운로드 도구, 개발 도구 또는 다른 프로그램 내부에 프록시 주소와 포트를 별도로 입력하는 방식입니다. 시스템 프록시를 덮어쓰거나 현재 애플리케이션에만 적용될 수 있습니다. 문제를 해결할 때는 프록시 유형과 로컬 리스너 유형이 일치하는지, 이전 포트를 계속 참조하지 않는지 확인해야 합니다.

TUN 모드는 가상 네트워크 인터페이스로 시스템 트래픽을 받아 시스템 프록시를 읽지 않는 일부 애플리케이션까지 연결할 수 있습니다. 그래도 라우팅, DNS 및 권한을 올바르게 설정해야 하며 다른 가상 네트워크 인터페이스와 충돌할 수 있습니다. TUN 활성화 여부는 애플리케이션 연결 요구에 따라 결정해야 하며 모든 연결 문제의 만능 해결책으로 보아서는 안 됩니다.

HTTP_PROXY, HTTPS_PROXY 및 ALL_PROXY 같은 환경 변수는 터미널 프로그램에서 사용하는 프록시 진입점 설정입니다. 변수를 읽는 프로세스에만 영향을 주며 새 설정은 보통 새 터미널 세션에서 적용됩니다. 입력할 때 HTTP와 SOCKS 리스너를 구분하고 클라이언트가 현재 사용하는 실제 포트를 지정해야 합니다.

라우팅 규칙은 도메인, 주소, 포트, 프로토콜 또는 프로세스 등의 조건에 따라 출구를 선택합니다. 이미 프록시 코어에 들어온 트래픽을 처리하므로 시스템 프록시를 읽지 않는 애플리케이션을 자동으로 연결하지는 않습니다. 여러 규칙이 있으면 매칭 순서와 기본 출구도 확인해야 합니다.

분할 라우팅은 서로 다른 대상이나 애플리케이션에 서로 다른 출구를 사용하도록 설정하는 방식입니다. 도메인, 주소, 프로세스 또는 기타 조건으로 분류할 수 있지만 관련 트래픽이 먼저 클라이언트나 코어에 도달해야 합니다. 예상과 다르게 분기되면 먼저 연결 범위를 확인한 뒤 규칙 매칭 결과를 점검해야 합니다.

GeoIP는 주소 대역과 지역 분류 결과를 바탕으로 라우팅 매칭을 돕는 리소스입니다. 데이터 파일을 기준으로 판단하며 현재 연결을 실시간 위치 추적하지는 않습니다. 주소 소속 변경이나 데이터 버전 차이로 규칙 결과가 달라질 수 있으므로 도메인 규칙과 주소 규칙을 함께 고려해야 합니다.

GeoSite는 용도나 분류별로 도메인 집합을 정리한 규칙 리소스로, 도메인을 일괄 매칭하는 데 사용됩니다. 도메인 분류를 설명하며 GeoIP의 주소 대역 분류와는 다릅니다. 규칙이 매칭되지 않으면 코어가 도메인 정보를 유지하는지, 사용 중인 데이터에 대상 도메인이 포함되어 있는지 확인해야 합니다.

DNS는 도메인을 연결 가능한 주소로 변환합니다. 프록시 설정에 따라 시스템, 클라이언트 또는 지정한 리졸버가 조회를 처리하도록 할 수 있으며 도메인별로 서로 다른 조회 경로를 선택할 수도 있습니다. DNS가 결과를 반환해도 프록시 프로토콜 연결이 성공한다는 뜻은 아니므로 두 단계를 나누어 확인해야 합니다.

FakeDNS는 애플리케이션에 예약된 범위의 매핑 주소를 반환하고 프록시 구성 요소가 원래 도메인을 복원하도록 합니다. 투명 연결에서 도메인 정보를 유지해 이후 도메인 라우팅이 정상적으로 판단하도록 할 때 사용됩니다. 활성화할 때는 주소 풀, 라우팅 및 DNS 처리 흐름이 서로 맞물리는지 확인해야 합니다.

DNS 누수는 도메인 조회가 예상한 설정 경로를 거치지 않고 다른 네트워크 인터페이스나 리졸버에서 수행되는 현상입니다. 문제를 해결할 때는 애플리케이션이 독립 DNS를 사용하는지, TUN이 조회를 가로채는지, 시스템에 다른 네트워크 구성 요소가 함께 존재하는지 확인해야 합니다. 노드만 바꾸기보다 실제 조회 경로를 복원하는 것이 핵심입니다.

TLS는 연결에 암호화와 서버 인증을 제공합니다. 핸드셰이크를 완료하려면 클라이언트와 서버가 호환되는 매개변수를 지원하고 인증서, 도메인 및 유효 기간 검사를 통과해야 합니다. TLS 연결이 실패했을 때 시스템 프록시를 켜거나 라우팅 규칙을 바꾸는 것만으로는 핸드셰이크 매개변수 점검을 대신할 수 없습니다.

SNI는 TLS 핸드셰이크에서 대상 서버 이름을 지정하는 정보입니다. 설정값은 보통 서버가 예상하는 값 및 인증서가 적용되는 도메인과 일치해야 합니다. 주소에는 연결되지만 핸드셰이크가 실패한다면 SNI도 별도로 확인해야 합니다.

인증서 체인은 사이트 인증서부터 신뢰할 수 있는 발급 기관까지 이어지는 검증 관계를 설명합니다. 체인 누락, 인증서 만료 또는 도메인 불일치로 TLS 핸드셰이크가 실패할 수 있습니다. 일상적인 문제 해결에서는 인증서나 도메인 설정을 수정하고 인증서 검증을 장기간 건너뛰지 않아야 합니다.

시스템 시간은 장치가 인증서의 유효 기간 여부를 판단하는 중요한 기준이며 일부 연결 보안 메커니즘에도 영향을 줍니다. 시간이나 시간대가 크게 어긋나면 정상 인증서도 아직 유효하지 않거나 이미 만료된 것으로 판단될 수 있습니다. 여러 노드에서 동시에 인증서 오류가 발생하면 먼저 시스템 자동 시간 동기화 상태를 확인해 보세요.