설정 작업을 기준으로 주요 용어를 이해해 보세요. 먼저 프로토콜과 코어를 확인한 뒤 구독, 라우팅, DNS 및 프록시 모드를 점검하면 이름이 비슷하지만 기능이 다른 설정을 혼동하는 일을 줄일 수 있습니다.
프로토콜은 클라이언트와 서버가 정보를 교환하는 방식을 정하고, 전송 방식과 보안 계층은 연결이 전달되는 방식을 결정합니다. 노드를 가져올 때는 이 매개변수들을 하나의 조합으로 확인해야 합니다.
vmess
VMess는 Project V 생태계에서 클라이언트와 서버가 통신할 때 사용하는 프로토콜입니다. 노드에는 일반적으로 사용자 식별자, 서버 주소, 포트 및 암호화 관련 설정이 포함됩니다. 클라이언트는 VMess를 TCP, WebSocket 등의 전송 방식과 함께 사용하므로 프로토콜 이름만 확인해서는 설정을 완료할 수 없습니다. 가져오기에 실패하면 전송 유형, 경로, 서버 이름 및 포트를 계속 점검해야 합니다.
vless
VLESS는 구조가 간결한 통신 프로토콜로, 인증 정보, 암호화 채널 및 하위 전송 방식이 서로 다른 설정 항목으로 설명되는 경우가 많습니다. TLS, REALITY, TCP, WebSocket 또는 gRPC와 함께 사용하는 경우가 많습니다. 클라이언트의 흐름 제어, 서버 이름, 공개 키 및 짧은 식별자는 항상 필수인 항목이 아니므로 실제 노드 조합에 따라 확인해야 합니다.
trojan
Trojan은 비밀번호로 클라이언트 인증을 수행하며, 일반적으로 TLS와 함께 연결을 설정합니다. 설정할 때 비밀번호, 서버 이름, 포트 및 인증서 검증 관련 옵션을 함께 확인해야 합니다. 프로토콜 이름이 같아도 설정을 서로 바꿔 쓸 수 있다는 뜻은 아니며, 전송 계층 매개변수는 서버 측과 일치해야 합니다.
security: reality
REALITY는 Xray 코어가 지원하는 전송 보안 방식으로, VLESS와 함께 사용하는 경우가 많습니다. 클라이언트 설정에는 공개 키, 짧은 식별자, 서버 이름 및 지문 등의 필드가 포함되는 경우가 많으며, 이 값들이 함께 연결 설정에 사용됩니다. 현재 코어 버전이나 클라이언트가 해당 필드를 인식하지 못한다면 매개변수를 임의로 삭제하기보다 먼저 코어 유형과 설정 형식을 확인해야 합니다.
network: ws
WebSocket은 HTTP 업그레이드 메커니즘으로 양방향 연결을 설정하며, 클라이언트에서는 보통 WS로 줄여 씁니다. 노드에서 WS 전송 외에 경로와 Host를 지정해야 할 수도 있습니다. 경로의 슬래시, 대소문자 및 추가 매개변수가 연결 결과에 영향을 줄 수 있으므로 직접 입력할 때 항목별로 정확히 옮겨야 합니다.
network: grpc
gRPC는 HTTP/2 기반 원격 프로시저 호출 프레임워크이며, VLESS 같은 프로토콜의 하위 전송 방식으로 사용할 수 있습니다. 클라이언트 설정에는 서비스 이름과 멀티플렉싱 관련 옵션이 자주 포함됩니다. WebSocket과는 연결 모델이 다르므로 전송 이름만 바꾸고 기존 매개변수를 그대로 유지해서는 안 됩니다.
security: tls
TLS는 연결 암호화와 서버 인증을 제공합니다. 클라이언트의 서버 이름은 일반적으로 인증서 검증에 사용됩니다. 노드 주소가 IP인 경우에도 인증서와 일치하는 도메인을 별도로 입력해야 할 수 있습니다. 인증서 이름 불일치나 핸드셰이크 오류가 발생하면 시스템 시간, 서버 이름 및 노드가 제공한 보안 계층 설정부터 확인해야 합니다.
그래픽 클라이언트는 사용자 인터페이스와 설정 관리를 담당하고, 코어는 프로토콜 처리, DNS, 라우팅 및 실제 연결을 담당합니다. 두 구성 요소의 역할을 이해해야 특정 프로토콜 지원 여부가 클라이언트 버전 때문인지 코어 기능 때문인지 판단할 수 있습니다.
ecosystem
Project V는 네트워크 프록시 프로토콜, 코어 및 관련 도구를 중심으로 형성된 오픈소스 기술 생태계입니다. 일상적으로 말하는 V2Ray는 초기 프로젝트를 가리키기도 하고 관련 코어와 클라이언트를 통칭하기도 하므로 문맥에 따라 판단해야 합니다. 설정 설명을 볼 때는 생태계 이름, 구체적인 코어 및 그래픽 클라이언트의 세 계층을 구분해야 합니다.
v2fly-core
V2Fly는 커뮤니티가 지속적으로 유지 관리하는 Project V 코어 계열로, 설정을 해석하고 프로토콜, DNS 및 라우팅 로직을 실행합니다. 고유한 기능 범위와 설정 변경 주기를 가집니다. v2flyNG 같은 클라이언트를 선택할 때는 구독에 포함된 프로토콜이 현재 V2Fly 코어의 기능과 호환되는지 확인해야 합니다.
xray-core
Xray는 Project V 생태계에서 발전한 코어 분기로, VLESS, REALITY 등의 프로토콜과 전송 기능을 지원합니다. v2rayN과 v2rayNG는 실제 연결 처리에 Xray를 사용하는 경우가 많습니다. 코어마다 설정 필드가 항상 동일하게 대응하는 것은 아니므로 코어를 바꾸기 전에 프로토콜 지원 여부와 라우팅 문법을 확인해야 합니다.
desktop client
v2rayN은 Windows, macOS 및 Linux용 데스크톱 그래픽 클라이언트로, 구독, 서버, 시스템 프록시, 라우팅 및 여러 코어를 관리할 수 있습니다. 클라이언트 인터페이스는 사용자의 설정을 코어가 읽을 수 있는 설정으로 정리합니다. 문제를 해결할 때는 v2rayN의 동작 상태와 선택한 코어의 실행 로그를 나누어 확인해야 합니다.
Android client
v2rayNG는 Android용 그래픽 클라이언트로, 일반적으로 Xray 코어를 사용해 노드 연결과 라우팅을 처리합니다. 활성화하면 클라이언트가 시스템에서 제공하는 VPN 서비스를 통해 처리 대상 트래픽을 가로챕니다. 구독 가져오기, 노드 선택 및 앱별 규칙은 인터페이스에서 관리하지만, 구체적인 프로토콜 기능은 코어에 따라 달라집니다.
Android client
v2flyNG는 Android용 그래픽 클라이언트로 V2Fly 코어 계열을 사용합니다. V2Fly 코어 호환성이 명확히 필요한 설정 환경에 적합합니다. v2rayNG와 전환할 때는 인터페이스만 비교하지 말고 구독 프로토콜, 라우팅 필드 및 코어 지원 범위를 함께 확인해야 합니다.
구독은 설정을 일괄 제공하고 노드는 실제로 선택할 수 있는 개별 연결 기록입니다. 업데이트, 필터링 및 테스트는 서로 다른 작업이므로 목록에 표시된다고 해서 노드에 연결할 수 있는 것은 아닙니다.
subscription
구독은 서버에서 제공하고 클라이언트가 정기적으로 업데이트할 수 있는 노드 설정 모음으로, 보통 구독 URL을 통해 가져옵니다. 주소를 추가하는 것은 출처를 등록하는 단계일 뿐이며, 서버 목록을 받으려면 클라이언트에서 업데이트를 실행해야 합니다. 업데이트에 실패하면 주소가 완전한지, 네트워크에 연결할 수 있는지, 구독 그룹에서 필터 조건을 사용 중인지 확인해야 합니다.
server profile
노드는 클라이언트에 저장된 하나의 서버 연결 설정으로, 주소, 포트, 프로토콜, 인증 정보 및 전송 매개변수를 포함합니다. 노드 이름은 주로 식별을 위한 것이며 실제 연결 가능 여부를 결정하지 않습니다. 같은 이름의 노드가 서로 다른 구독에서 올 수 있으므로 수정하기 전에 소속 그룹과 전체 매개변수를 확인해야 합니다.
subscription group
구독 그룹은 서로 다른 출처나 용도의 노드를 분리해 관리하는 기능이며, 각 그룹을 독립적으로 업데이트하고 활성화하거나 필터링할 수 있습니다. 여러 구독을 동시에 사용할 때 그룹을 이용하면 같은 이름의 노드로 인한 혼동을 줄일 수 있습니다. 그룹을 삭제하면 해당 출처에서 생성된 노드도 함께 삭제되는 경우가 많으므로, 수동 설정을 보존할지 먼저 확인해야 합니다.
filter
서버 필터는 노드 이름의 키워드, 정규식 또는 기타 조건에 따라 목록을 정리합니다. 포함 조건은 일치하는 항목을 남기고 제외 조건은 필요하지 않은 항목을 숨깁니다. 구독 업데이트 후 목록이 비어 있으면 먼저 필터를 잠시 끄고 원본 구독에서 노드를 반환했는지 확인해야 합니다.
latency
지연 시간은 클라이언트가 데이터를 보낸 후 응답을 받을 때까지 걸리는 시간입니다. 그러나 테스트 대상과 방법에 따라 측정값의 의미가 달라집니다. TCP 핸드셰이크, ICMP 응답 및 전체 프록시 요청은 서로 다른 단계를 측정합니다. 노드를 선택할 때는 연결 성공률, 대상 서비스의 응답 및 지속 사용 성능도 함께 고려해야 합니다.
real delay
실제 연결 지연 시간은 프록시 연결을 실제로 설정하고 테스트 대상에 요청을 보내 가용성과 응답 시간을 확인합니다. 서버 포트만 확인하는 방식보다 프로토콜 핸드셰이크, 전송 보안 계층 및 프록시 요청 등 더 많은 단계를 포함합니다. 테스트 실패가 곧 서버 오프라인을 의미하지는 않으므로 DNS, 라우팅 및 코어 로그도 확인해야 합니다.
라우팅 모듈은 구독을 설정하는 역할이 아니라 요청이 코어에 들어온 뒤 사용할 출구를 결정합니다. 규칙은 일반적으로 위에서 아래로 매칭되므로 순서, 조건 범위 및 기본 출구가 최종 결과에 영향을 줍니다.
routing.rules
라우팅 규칙은 도메인, IP, 포트, 네트워크 유형, 프로토콜 또는 인바운드 태그에 따라 트래픽이 사용할 아웃바운드를 결정합니다. 여러 규칙이 있으면 코어는 일반적으로 설정 순서대로 처리해 먼저 일치한 결과를 적용합니다. 규칙을 추가하기 전에 더 앞에 있고 범위가 넓은 규칙에 의해 덮어쓰이지 않는지 확인해야 합니다.
traffic routing
트래픽 분할은 서로 다른 대상이나 유형의 네트워크 요청을 프록시, 직접 연결 또는 차단 아웃바운드로 나누어 보내는 설정 방식입니다. 일반적인 조건에는 도메인 분류, 대상 IP, 포트 및 앱이 생성한 인바운드 태그가 있습니다. 분할 결과는 요청이 코어에 들어오는지, 도메인 조회 결과를 규칙에서 사용할 수 있는지에 따라 달라집니다.
geoip:cn
GeoIP는 IP 주소의 지역이나 네트워크 유형에 따라 정리한 규칙 데이터로, 라우팅 모듈에서 대상 IP를 일괄 매칭하는 데 사용할 수 있습니다. 로컬 규칙 파일의 내용과 업데이트 시점에 의존하므로 분류 결과를 실시간 위치 정보로 이해해서는 안 됩니다. 도메인 요청은 대상 IP를 얻은 뒤에야 해당 IP 규칙의 판단 대상이 될 수 있습니다.
geosite:cn
GeoSite는 사이트 유형별로 정리한 도메인 규칙 모음으로, 라우팅 설정에서 여러 도메인을 한 번에 참조할 수 있습니다. 서버 IP가 아닌 도메인을 매칭하므로 조회 전에 분류하기에 적합합니다. 규칙 이름은 데이터 파일에서 정의하며, 존재하지 않는 분류명을 입력하면 코어가 설정을 불러오는 단계에서 바로 오류를 낼 수 있습니다.
outbounds
아웃바운드는 코어가 요청을 처리한 뒤 트래픽을 내보내는 출구이며, 일반적인 유형에는 프록시, 직접 연결 및 차단이 있습니다. 라우팅 규칙은 보통 태그로 특정 아웃바운드를 참조하므로 태그 이름이 설정에 정의된 아웃바운드와 일치해야 합니다. 기본 아웃바운드는 다른 규칙과 일치하지 않은 요청을 처리합니다.
freedom / direct
직접 연결은 선택한 프록시 노드를 거치지 않고 현재 기기의 네트워크에서 대상에 직접 접속하는 방식입니다. 클라이언트나 코어에 따라 direct, freedom 또는 ‘직접 연결’로 표시될 수 있습니다. 직접 연결 요청도 시스템 DNS, 네트워크 라우팅 및 기기 방화벽 설정의 영향을 받습니다.
이 용어들은 트래픽이 클라이언트로 들어오는 방식, 도메인이 조회되는 방식, 오류 발생 시 단서를 확인할 위치를 결정합니다. 먼저 트래픽 인계 방식을 확인하고 DNS와 라우팅을 점검한 다음 연결 단계에 따라 로그를 읽어야 합니다.
system proxy
시스템 프록시는 클라이언트가 운영체제의 프록시 설정을 수정해 해당 설정을 따르는 앱의 요청을 로컬 프록시 포트로 보내는 기능입니다. 모든 프로세스를 자동으로 가로채지는 않으며, 일부 앱은 별도의 네트워크 설정을 사용하거나 직접 연결합니다. 클라이언트를 종료하기 전에 시스템 프록시를 원래대로 복원하면 로컬 수신이 중단된 뒤 앱이 작동하지 않는 포트를 계속 가리키는 문제를 막을 수 있습니다.
tun
TUN 모드는 가상 네트워크 인터페이스를 통해 시스템 네트워크 트래픽을 가로채므로 시스템 프록시 설정을 읽지 않는 앱에도 적용할 수 있습니다. 라우팅 테이블, DNS 및 가상 네트워크 어댑터를 처리해야 하므로 시스템 프록시보다 더 많은 시스템 수준 설정이 필요합니다. 활성화에 실패하면 권한, 가상 네트워크 어댑터 상태 및 트래픽을 중복으로 가로채는 프로그램이 있는지 확인해야 합니다.
fakedns
FakeDNS는 앱에 매핑 주소를 반환하는 동시에 코어가 해당 주소와 원래 도메인의 관계를 유지하도록 합니다. 요청이 코어에 들어오면 도메인을 복원해 도메인 라우팅 규칙을 계속 적용할 수 있습니다. TUN 모드와 함께 사용하는 경우가 많으며, 주소 풀 범위와 DNS 흐름을 통일해 기존 로컬 네트워크 대역과 충돌하지 않도록 해야 합니다.
dns.servers
DNS는 도메인을 IP 주소로 변환하는 기본 네트워크 서비스입니다. 클라이언트에서 도메인별 DNS 서버와 조회 정책을 지정할 수 있습니다. 조회가 시스템, 앱 또는 프록시 코어 중 어느 계층에서 이루어지는지에 따라 도메인 라우팅 적용 여부가 달라집니다. DNS를 변경할 때는 기존 설정을 기록하고 도메인 조회와 노드 연결을 각각 테스트해야 합니다.
DNS path
DNS 누수는 DNS 조회가 예상한 경로나 규칙에 따라 처리되지 않아 조회 요청이 다른 해석 경로로 전송되는 현상입니다. 흔한 원인으로 앱 자체 조회 기능, DNS를 인계하지 않는 시스템 프록시, 불완전한 TUN 규칙 또는 먼저 응답하는 보조 DNS가 있습니다. 문제를 해결할 때는 각 도메인 유형을 누가 조회해야 하는지 정한 뒤 시스템, 클라이언트 및 코어 설정을 계층별로 확인해야 합니다.
allow LAN
로컬 네트워크 공유를 사용하면 같은 로컬 네트워크의 다른 기기가 클라이언트가 연 로컬 프록시 포트에 연결할 수 있습니다. 활성화 후에는 수신 주소, 포트, 방화벽 및 기기 간 네트워크 연결 가능성을 함께 확인해야 합니다. 신뢰할 수 있는 네트워크에서만 열고, 기기별로 올바른 호스트 주소와 프록시 유형을 명확히 설정하세요.
log
실행 로그는 코어 시작, 설정 로드, DNS 조회, 라우팅 매칭, 연결 설정 및 오류 정보를 기록합니다. 로그를 읽을 때는 먼저 처음 발생한 오류를 찾고, 시간 순서에 따라 조회, 핸드셰이크 또는 대상 연결 중 어느 단계에서 발생했는지 판단하세요. 로그 수준을 높이면 세부 정보가 늘어나지만, 문제 해결 후에는 일반적인 수준으로 되돌려 불필요한 출력을 줄일 수 있습니다.
노드 프로토콜과 코어를 확인했다면 사용 가이드로 이동해 구독 가져오기, 노드 선택, 시스템 프록시 및 연결 검증을 진행하세요. GeoSite, TUN, FakeDNS 또는 여러 구독 그룹을 설정해야 한다면 고급 설정 매뉴얼을 참고하세요.