프로토콜 및 암호화
연결 형식과 보안 계층
프로토콜은 인증 정보와 데이터 구성 방식을 결정하고, TLS와 REALITY 같은 보안 계층은 연결 단계별로 보호 기능을 제공합니다. 노드를 가져올 때는 프로토콜 이름만 확인할 것이 아니라 전송 방식과 보안 매개변수도 서로 맞춰야 합니다.
- VMess 프로토콜
- VMess는 Project V 생태계의 애플리케이션 계층 프로토콜로, 인증, 시간 검증 및 데이터 전송 메커니즘을 포함합니다. 클라이언트에는 일반적으로 사용자 식별자, 서버 주소, 포트 및 추가 식별자 등을 입력해야 합니다. 서버 시간과 로컬 시스템 시간의 차이가 너무 크면 인증에 실패할 수 있으므로 연결 문제를 점검할 때 시스템 시계도 확인해야 합니다.
- VLESS 프로토콜
- VLESS는 구조가 간결한 프록시 프로토콜로, 암호화와 전송 보안은 TLS, REALITY 같은 외부 계층에서 처리합니다. 노드 연결 여부는 VLESS라는 이름만으로 결정되지 않으며 전송 계층, 보안 계층 및 서버 설정이 일치해야 합니다. 주요 필드로는 사용자 식별자, 흐름 제어 방식, 서버 이름 및 공개 키 정보가 있습니다.
- Trojan 프로토콜
- Trojan은 비밀번호를 인증 정보로 사용하며 일반적으로 TLS와 함께 연결을 설정합니다. 클라이언트 설정은 서버의 주소, 포트, 비밀번호, 서버 이름 및 전송 방식과 일치해야 합니다. 인증서 이름이 일치하지 않거나 핸드셰이크가 실패하면 먼저 서버 이름 필드를 확인해야 하며, 노드만 반복해서 바꾸는 것은 올바른 접근이 아닙니다.
- REALITY 보안 계층
- REALITY는 Xray 생태계의 전송 보안 방식으로, VLESS와 함께 사용하는 경우가 많습니다. 클라이언트 설정에는 일반적으로 서버 이름, 공개 키, 짧은 식별자 및 브라우저 지문 등의 필드가 포함됩니다. 핵심 필드 하나라도 누락되거나 복사 과정에서 잘리면 연결이 핸드셰이크 단계에서 멈출 수 있으므로, 이때는 코어 로그를 함께 확인해 구체적인 매개변수를 찾아야 합니다.
- TLS 전송 보안
- TLS는 암호화 연결을 설정하고 통신 상대의 신원을 확인하는 범용 보안 프로토콜입니다. 클라이언트 설정에서는 서버 이름, 인증서 검증, 애플리케이션 계층 프로토콜 협상 및 전송 포트와 관련되는 경우가 많습니다. 인증서 오류가 발생하면 시스템 시간 이상, 서버 이름 불일치 및 인증서 체인 문제를 구분해야 하며, 각각의 해결 방향은 다릅니다.
코어 및 생태계
클라이언트, 코어 및 프로젝트의 관계
그래픽 클라이언트는 인터페이스, 구독 및 설정을 관리하고 코어는 프로토콜 처리, DNS, 라우팅 및 실제 연결을 담당합니다. 둘을 구분해 이해하면 문제가 인터페이스 설정, 코어 실행 또는 원격 연결 중 어느 단계에서 발생했는지 판단하기 쉽습니다.
- Project V 기술 생태계
- Project V는 네트워크 프록시 프로토콜, 라우팅 기능 및 관련 도구를 중심으로 형성된 오픈 소스 기술 생태계입니다. V2Ray의 설정 철학, 인바운드·아웃바운드 모델 및 여러 클라이언트 도구가 이 체계와 관련되어 있습니다. 특정 그래픽 인터페이스의 이름이 아니므로 문서를 읽을 때 프로젝트 개념, 코어 이름 및 클라이언트 이름을 구분해야 합니다.
- V2Fly 코어 포크
- V2Fly는 V2Ray 기술 체계를 이어가는 커뮤니티 유지 프로젝트이자 코어 포크입니다. 프로토콜 처리, 인바운드·아웃바운드, DNS 및 라우팅 같은 기본 기능을 제공하며, 그래픽 클라이언트가 설정을 생성하고 실행할 수 있습니다. v2flyNG를 사용할 때 인터페이스의 설정은 최종적으로 코어가 읽을 수 있는 설정으로 변환됩니다.
- Xray 프록시 코어
- Xray는 V2Ray와 유사한 설정 철학을 가진 프록시 코어로, VLESS, REALITY 등의 기능을 지원합니다. v2rayN과 v2rayNG는 해당 설정에 따라 Xray를 호출해 실제 연결을 처리할 수 있습니다. 인터페이스에는 노드가 표시되지만 연결에 실패한다면 코어가 정상적으로 실행되었는지, 로그에 설정 파싱 또는 핸드셰이크 오류가 있는지 계속 확인해야 합니다.
- v2rayN 데스크톱 클라이언트
- v2rayN은 Windows, macOS 및 Linux용 데스크톱 그래픽 클라이언트입니다. 구독, 노드, 시스템 프록시, TUN 모드, 라우팅 규칙 및 코어 프로세스를 관리할 수 있습니다. 데스크톱 버전과 Windows 클래식 WPF 버전은 인터페이스 구현이 다르지만, 설정 가져오기, 노드 선택, 코어 실행 및 트래픽 인계 방식 설정이라는 핵심 흐름은 같습니다.
- v2rayNG Android 클라이언트
- v2rayNG는 Android용 그래픽 클라이언트로, 일반적으로 Xray 코어를 사용해 연결을 처리합니다. 시스템이 제공하는 VPN 서비스를 통해 앱 트래픽을 인계하며 구독 관리, 노드 전환 및 라우팅 설정도 지원합니다. 처음 연결을 시작할 때는 시스템에 표시되는 네트워크 연결 권한을 허용해야 하며, 그렇지 않으면 인터페이스 조작이 실제 데이터 통로로 이어지지 않습니다.
클라이언트 기능
트래픽 인계와 연결 테스트
시스템 프록시와 TUN 모드는 서로 다른 범위의 트래픽 인계 문제를 해결하고, FakeDNS, 로컬 네트워크 공유 및 지연 시간 테스트는 특정 상황에 사용됩니다. 기능을 많이 활성화할수록 포트, 권한 및 라우팅 사이에 충돌이 없는지 확인해야 합니다.
- 시스템 프록시 인계 모드
- 시스템 프록시는 클라이언트가 운영체제의 프록시 설정을 변경하여 시스템 설정을 따르는 앱의 트래픽을 로컬 프록시 포트로 보내는 기능입니다. 브라우저는 보통 이 설정을 읽지만 일부 터미널 프로그램, 독립 네트워크 도구 또는 자체 네트워크 스택을 구현한 앱은 자동으로 따르지 않습니다. 브라우저는 연결되지만 터미널은 연결되지 않는다면 시스템 프록시와 터미널 환경 변수를 따로 확인해야 합니다.
- TUN 모드 가상 네트워크 인터페이스
- TUN 모드는 가상 네트워크 인터페이스를 통해 더 많은 앱 트래픽을 인계하며, 일반적으로 시스템 프록시보다 적용 범위가 넓습니다. 필요한 네트워크 권한이 있어야 하고 시스템 라우팅 테이블에 규칙을 추가합니다. 기기에서 다른 가상 네트워크 도구도 실행 중이면 라우팅 충돌, DNS 경로 변경 또는 연결 반복 전환이 발생할 수 있으므로 트래픽 인계 지점을 하나로 명확히 해야 합니다.
- FakeDNS DNS 매핑
- FakeDNS는 앱에 매핑된 주소를 반환하고 클라이언트 내부에 해당 주소와 원래 도메인의 대응 관계를 저장합니다. TUN 환경에서 트래픽이 코어로 들어온 뒤에도 도메인 규칙으로 매칭되도록 하여 대상 IP만 남는 상황을 방지하는 데 사용됩니다. 활성화할 때는 FakeDNS 주소 대역이 기존 로컬 네트워크 대역과 충돌하지 않는지 확인하고 관련 DNS 요청이 예정된 처리 경로를 거치도록 해야 합니다.
- 실제 연결 지연 시간 연결 테스트
- 실제 연결 지연 시간은 프로토콜 연결을 설정해 노드 응답 시간을 측정하므로, 서버에 연결할 수 있는지만 확인하는 테스트보다 클라이언트의 실제 작동 과정에 가깝습니다. 그래도 특정 시점, 대상 및 탐색 방식에서 얻은 결과일 뿐입니다. 지연 시간이 낮다고 처리량이 반드시 높은 것은 아니므로 노드를 선택할 때 지속적인 연결 상태와 실제 사용 환경도 함께 고려해야 합니다.
구독 및 노드
설정 출처와 노드 관리
구독은 노드 설정의 출처이고, 노드는 클라이언트가 실제로 선택하고 연결하는 개별 기록입니다. 업데이트, 그룹화 및 지연 시간 테스트는 관리 작업이며 설정의 완전성이나 연결 로그 확인을 대신할 수 없습니다.
- 구독 설정 모음
- 구독은 서버가 제공하는 주소 또는 데이터 모음으로, 여러 노드 설정을 포함합니다. 클라이언트에 구독 주소를 저장하면 필요할 때 요청하여 노드를 파싱할 수 있습니다. 구독 주소는 빠짐없이 복사해야 하며, 구독 노드를 로컬에서 수정한 내용은 다음 업데이트 때 덮어써질 수 있습니다. 장기적으로 조정하려면 클라이언트의 라우팅이나 그룹 설정을 사용하는 편이 적합합니다.
- 노드 연결 설정
- 노드는 클라이언트에서 선택할 수 있는 하나의 서버 연결 설정입니다. 일반적으로 주소, 포트, 프로토콜, 인증 정보, 전송 계층 및 보안 계층 등의 필드로 구성됩니다. 노드 이름은 식별을 위한 레이블일 뿐이므로 이름을 바꿔도 보통 연결 매개변수는 바뀌지 않습니다. 하지만 사용자 식별자, 공개 키 또는 서버 이름 등이 누락되면 연결에 직접적인 영향을 줍니다.
- 지연 시간 응답 시간
- 지연 시간은 클라이언트가 탐색을 시작한 뒤 응답을 받을 때까지 걸리는 시간으로, 보통 밀리초로 표시합니다. 테스트 기능에 따라 TCP 연결 설정, 프로토콜 핸드셰이크 또는 지정된 대상 접속 등 방식이 다를 수 있으므로 결과를 단순 비교해서는 안 됩니다. 지연 시간은 응답 속도만 보여 주며 가용 대역폭, 지속적인 처리량 또는 장시간 안정성을 단독으로 나타내지 않습니다.
- 구독 그룹 출처 관리
- 구독 그룹은 클라이언트가 구독 출처별로 노드를 분류해 관리하는 방식입니다. 특정 출처의 노드를 따로 업데이트, 필터링, 활성화 또는 정리할 수 있어 여러 출처가 섞였을 때 식별하기도 쉽습니다. 그룹을 삭제하기 전에는 적용 범위를 확인해야 합니다. 클라이언트가 해당 그룹에 이미 가져온 노드 기록까지 함께 삭제할 수 있기 때문입니다.
- 구독 업데이트 동기화 작업
- 구독 업데이트는 클라이언트가 구독 주소에 다시 요청을 보내 노드 목록을 동기화하는 과정입니다. 업데이트에 실패하면 구독 주소가 완전한지, 현재 네트워크에서 해당 주소에 접근할 수 있는지, 시스템 시간이 정확한지 및 로그의 요청 상태를 순서대로 확인해야 합니다. 업데이트에 성공했지만 목록이 바뀌지 않았다면 구독 내용 자체가 그대로이거나 현재 그룹 필터가 일부 노드를 숨기고 있을 수 있습니다.
라우팅 및 트래픽 분기
매칭 조건과 트래픽 출구
라우팅 모듈은 도메인, IP, 포트 또는 프로세스 등의 정보를 읽은 뒤 규칙 순서에 따라 출구를 선택합니다. DNS 조회가 어느 계층에서 수행되는지는 도메인 규칙과 IP 규칙이 예상한 입력을 얻을 수 있는지에 직접적인 영향을 줍니다.
- 라우팅 규칙 매칭 조건
- 라우팅 규칙은 도메인, IP, 포트, 프로토콜 또는 프로세스 등의 조건에 따라 트래픽 출구를 결정합니다. 규칙은 일반적으로 순서대로 매칭하며, 일치하면 뒤의 같은 조건을 계속 판단하지 않습니다. 따라서 구체적인 규칙과 포괄적인 규칙의 위치를 적절히 배치해야 합니다. 규칙이 적용되지 않을 때는 먼저 클라이언트에서 어떤 라우팅 설정을 활성화했는지 확인한 다음, 대상이 예상한 도메인 또는 IP 형태로 코어에 들어오는지 점검해야 합니다.
- 트래픽 분기 출구 선택
- 트래픽 분기는 서로 다른 대상이나 앱의 트래픽을 프록시, 직접 연결 또는 차단 등의 출구로 배분하는 과정입니다. 단일 스위치가 아니라 라우팅 규칙, DNS 조회, 인바운드 정보 및 기본 출구가 함께 작용한 결과입니다. 분기 규칙을 변경해도 기존의 장시간 연결은 이전 경로를 계속 사용할 수 있으므로, 확인할 때는 관련 앱이나 클라이언트 연결을 다시 시작하는 것이 좋습니다.
- GeoIP IP 규칙 세트
- GeoIP는 IP 주소의 지역 또는 분류를 기준으로 매칭하는 데이터 모음입니다. 대상이 이미 IP로 해석되었거나 라우팅 모듈이 대상 IP를 직접 얻은 경우에만 판단에 사용할 수 있습니다. GeoIP 데이터에는 유효 기간이 있으므로 주소의 소속이 바뀌면 오래된 데이터가 예상과 다른 분류 결과를 낼 수 있습니다. 클라이언트를 업데이트할 때는 규칙 데이터 버전도 확인해야 합니다.
- GeoSite 도메인 규칙 세트
- GeoSite는 도메인 분류별로 정리한 규칙 데이터 모음으로, 라우팅 모듈이 대상 도메인을 매칭하는 데 사용할 수 있습니다. GeoIP와 매칭 대상이 다르며, 전자는 도메인, 후자는 IP 주소를 대상으로 합니다. 요청이 코어에 들어올 때 IP만 남아 있으면 GeoSite 규칙이 적용되지 않을 수 있으므로 DNS 정책, 스니핑 설정 및 TUN 트래픽 처리 방식을 확인해야 합니다.
- DNS 누수 조회 경로 이탈
- DNS 누수는 앱의 도메인 조회가 예정된 DNS 경로를 거치지 않고 시스템이나 다른 리졸버에서 직접 처리되는 현상입니다. 문제를 점검할 때는 클라이언트 DNS, 시스템 DNS, 브라우저 보안 DNS, TUN 라우팅 및 앱 자체의 조회 정책을 함께 확인해야 합니다. DNS 주소 하나만 바꿔서는 모든 앱의 조회 경로가 바뀌지 않을 수 있으므로, 누가 조회를 시작하고 누가 인계하며 최종적으로 어디로 전송하는지 먼저 확인해야 합니다.
- 직접 연결 아웃바운드 방식
- 직접 연결은 트래픽이 프록시 노드를 거치지 않고 현재 네트워크 연결로 대상에 직접 접속하는 방식입니다. 보통 라우팅 규칙이 명시적으로 지정하며, 매칭되지 않은 트래픽의 기본 출구로 사용되기도 합니다. 직접 연결에 실패했다고 해서 반드시 프록시 노드의 문제는 아니므로 로컬 네트워크, DNS 조회, 대상 주소 및 방화벽 설정을 각각 확인해야 합니다.