V2Ray 프로토콜·코어·클라이언트 선택 가이드

01 / DECISION MODEL

먼저 프로토콜 선택의 판단 모델을 세우세요

프로토콜, 전송 방식, 보안 계층, 클라이언트는 서로 다른 계층입니다

노드 정보를 확인할 때는 먼저 네 계층으로 나눠 보세요. 첫 번째는 VMess, VLESS, Trojan, Shadowsocks 같은 프록시 프로토콜입니다. 클라이언트 인증 방식, 연결 구성, 서버의 요청 식별 방법을 정합니다. 두 번째는 TCP, WebSocket, gRPC 같은 전송 방식으로, 네트워크 연결에서 데이터를 전달하는 방법을 결정합니다. 세 번째는 TLS나 REALITY 같은 보안 계층으로, 핸드셰이크 인증, 암호화된 채널, 특정 연결 검증을 담당합니다. 네 번째가 클라이언트와 코어입니다. v2rayN, v2rayNG, v2flyNG는 인터페이스를 제공하고 V2Fly 또는 Xray가 실제로 설정을 해석해 연결을 수립합니다.

이 네 계층은 조합할 수 있지만 마음대로 서로 바꿀 수는 없습니다. VLESS는 프로토콜이고 REALITY는 Xray 생태계에서 구현되어 특정 전송 형태와 함께 사용하는 보안 방식이므로, ‘VLESS’와 ‘REALITY’는 완전히 나란한 두 선택지가 아닙니다. 마찬가지로 WebSocket은 프록시 프로토콜이 아니며 TLS도 노드 유형이 아닙니다. 클라이언트 구독에서 흔히 보는 ‘VLESS + TCP + REALITY’는 실제로 세 계층의 조합입니다. 가져온 뒤 필드가 많다면 하나씩 추측하기보다 계층별로 확인하는 편이 정확합니다.

선택은 호환성부터 확인해야 합니다

프로토콜 선택에서 가장 먼저 볼 것은 이론상 속도가 아니라 서버와 클라이언트 코어가 모두 지원하는지입니다. 서버가 VMess만 제공한다면 클라이언트에서 VLESS의 처리 비용을 논해도 의미가 없습니다. 구독에 REALITY 파라미터가 있다면 현재 클라이언트의 코어가 해당 필드를 인식하는지 확인해야 합니다. 호환성이 확인된 다음 네트워크 환경, 기기 리소스, 연결 수, 유지 관리 난이도를 비교하세요. 극한의 처리량은 마지막에 살펴보면 됩니다. 일상적인 차이는 대개 프로토콜 이름보다 회선 품질, 핸드셰이크 재시도, 도메인 확인, 전송 계층 설정에서 발생합니다.

안전한 확인 순서는 링크 스킴 이름을 식별하고, 클라이언트 코어를 확인한 다음 전송 및 보안 필드를 살펴보고, 마지막으로 주소·포트·인증 정보를 점검하는 것입니다. 노드 표시 이름만 보고 프로토콜을 판단하지 마세요. 표시 이름은 구독 제공자가 입력한 라벨이므로 어떤 문구든 포함할 수 있습니다. 실제 해석 방식을 결정하는 것은 링크 스킴과 설정의 protocol, network, security 같은 필드입니다.

안정성은 전체 경로의 결과입니다

같은 프로토콜도 설정에 따라 결과가 크게 달라질 수 있습니다. TCP 직접 연결은 구조가 단순하고 추가 처리가 적습니다. WebSocket은 일반적인 웹 서비스 배포 방식과 결합하기 쉽지만 프레임 캡슐화 비용이 있습니다. gRPC는 HTTP/2 기반이라 연결 관리 능력이 뛰어난 편이지만 파라미터 관계가 더 복잡합니다. TLS에서는 인증서 이름, 시스템 시간, SNI가 서로 맞아야 합니다. 그렇지 않으면 프로토콜 설정이 올바르더라도 핸드셰이크를 완료할 수 없습니다. REALITY는 클라이언트와 서버가 짧은 식별자, 공개 키, 서버 이름 등의 필드에 같은 값을 사용해야 합니다.

따라서 선택할 때는 ‘프로토콜 + 전송 + 보안 계층 + 코어’의 전체 조합을 기록하고 약어 하나만 남기지 마세요. 문제를 해결할 때도 같은 순서로 되짚어야 합니다. 가져오기는 성공했지만 연결되지 않는다면 먼저 클라이언트가 프로토콜을 인식했는지 확인하고, 전송 필드가 완전한지 살펴본 뒤 보안 계층 파라미터를 확인하세요. 모든 필드가 일치한다면 DNS, 시스템 프록시, 로컬 포트를 점검합니다. 구체적인 오류 증상은 문제 해결에서 항목별로 확인할 수 있습니다.

02 / VMESS

VMess: 완성도 높은 인증 체계와 폭넓은 호환성

설계 배경과 프로토콜의 역할

VMess는 Project V 초기 생태계를 대표하는 프로토콜입니다. 사용자 식별자, 요청 정보, 시간 기반 인증 절차를 프로토콜 설계에 포함하며, 클라이언트와 서버는 UUID 등의 정보로 사용자를 식별합니다. 핵심 특징은 특정 암호화 알고리즘 하나가 아니라 인증, 요청 캡슐화, 연결 협상을 포함한 완성도 높은 메커니즘입니다. 비교적 일찍 등장한 만큼 많은 V2Ray 설정, 구독 생성기, 그래픽 클라이언트가 VMess를 인식해 호환 범위가 넓습니다.

VMess 설정에는 보통 서버 주소, 포트, 사용자 UUID, alterId, 전송 방식, 보안 계층이 포함됩니다. 현재 설정에서 자주 보이는 alterId 값은 대부분 0이지만, 오래된 구독에는 다른 값이 남아 있을 수 있습니다. 서버와 클라이언트의 설정이 일치해야 하므로 가져올 때 임의로 이 필드를 바꾸면 안 됩니다. 암호화 옵션은 대개 auto이며 실제 동작은 코어가 설정에 따라 처리합니다. 구독은 정상적으로 갱신되지만 VMess 노드가 모두 연결되지 않는다면 먼저 시스템 시간을 확인하세요. 시간 차이가 인증 단계에 직접 영향을 줄 수 있습니다.

VMess의 장점과 비용

VMess의 장점은 자료와 설정 도구가 풍부하고, V2Fly와 Xray가 일반적인 조합을 대체로 처리한다는 점입니다. 여러 클라이언트 사이에서 설정을 옮겨야 하거나, 서버가 기존 V2Ray 설정을 사용하거나, 구독 형식이 이미 안정적으로 운영되는 상황이라면 굳이 프로토콜을 바꾸기보다 VMess를 유지하는 편이 편리합니다. TCP, WebSocket 같은 전송 방식과 조합할 수 있고 TLS도 추가할 수 있습니다. 기존 배포가 안정적이라면 새 프로토콜이 나왔다는 이유만으로 즉시 이전할 필요는 없습니다.

비용은 비교적 복잡한 프로토콜 처리에서 주로 발생하며 인증과 캡슐화 단계가 가벼운 설계보다 많습니다. 컴퓨팅 성능이 충분한 데스크톱에서는 차이가 거의 드러나지 않지만, 저전력 기기나 동시 연결이 많거나 자주 깨어나는 모바일 환경에서는 추가 처리가 더 쉽게 체감될 수 있습니다. 다만 실제 배터리 소모와 속도는 여전히 네트워크 품질의 영향을 크게 받습니다. 연결이 반복해서 실패하며 재시도하면 한 번의 프로토콜 계산보다 훨씬 많은 리소스를 사용할 수 있으므로, 이론상의 비용보다 핸드셰이크를 안정적으로 완료하는 설정이 중요합니다.

주요 필드 확인 방법

먼저 주소와 포트가 완전히 가져와졌는지 확인한 뒤 UUID가 원본 그대로인지 살펴보세요. UUID는 표준 구분 형식이어야 하며 복사할 때 불필요한 공백이 들어가면 안 됩니다. 다음으로 전송 계층을 확인합니다. 서버가 WebSocket을 사용한다면 클라이언트의 경로와 Host가 일치해야 합니다. TLS를 추가했다면 SNI 또는 serverName이 인증서에 포함된 이름과 일치해야 합니다. 클라이언트에 표시되는 메모는 연결에 사용되지 않으므로 자유롭게 바꿔도 되지만, 다른 필드는 더 간단해 보인다는 이유로 삭제하지 마세요.

{
  "protocol": "vmess",
  "settings": {
    "vnext": [
      {
        "address": "server.example.com",
        "port": 443,
        "users": [
          {
            "id": "11111111-2222-4333-8444-555555555555",
            "alterId": 0,
            "security": "auto"
          }
        ]
      }
    ]
  }
}

위의 예시는 VMess 아웃바운드의 핵심 계층만 보여 줍니다. 완전한 설정에는 트래픽 인바운드, 전송 파라미터, 라우팅도 필요합니다. 직접 입력할 때 화면의 필드명과 JSON 이름이 다를 수 있습니다. 예를 들어 ‘사용자 ID’는 id, ‘추가 ID’는 alterId에 해당합니다. 의미가 같다면 충분하므로 화면 문구와 하위 필드명을 글자 그대로 맞출 필요는 없습니다.

VMess를 유지하는 것이 좋은 경우

서버가 안정적으로 운영되고 구독을 여러 기기에서 사용하며 클라이언트에 V2Fly와 Xray 코어가 함께 있다면 VMess는 보수적인 호환성 선택입니다. 특히 기존 설정이 WebSocket과 TLS 조합이고 운영 목표가 이전 변수를 줄이는 것이라면 현재 구성을 유지하는 편이 적절합니다. 새 설정을 만들고 클라이언트와 서버가 모두 VLESS를 명확히 지원한다면 인증 비용과 보안 계층을 추가로 비교할 수 있지만, 그렇다고 VMess의 가치가 사라지는 것은 아닙니다.

VMess 문제를 해결할 때는 ‘가져오기 실패’와 ‘핸드셰이크 실패’를 먼저 구분하세요. 가져오기 실패는 보통 링크 인코딩, 구독 내용, 클라이언트 해석 문제와 관련됩니다. 핸드셰이크 실패는 시간, UUID, 전송 경로, TLS 이름, 포트와 더 관련이 깊습니다. 두 단계를 오가며 모든 파라미터를 한꺼번에 바꾸지 마세요. 한 번에 하나만 수정하고 변경 전후 결과를 기록해야 실제 문제 지점을 확인할 수 있습니다.

03 / VLESS + REALITY

VLESS와 REALITY: 가벼운 프로토콜과 보안 계층의 조합

VLESS가 더 가벼운 설계를 택한 이유

VLESS는 프로토콜 인증과 전송 보안을 더 명확하게 분리합니다. UUID로 사용자를 식별하지만 VMess와 같은 암호화 역할을 프로토콜 내부에서 모두 담당하지 않고, 채널 보안을 TLS나 REALITY 같은 외부 계층에 맡깁니다. 이 계층화 덕분에 프로토콜 자체가 간결해지고 코어가 전송 및 보안 계층 조합에 따라 기능을 구성하기도 쉬워집니다. 다만 ‘프로토콜 자체가 가볍다’고 해서 보안 계층을 생략해도 된다는 뜻은 아닙니다. TLS나 REALITY가 필요한지는 전체 배포 구성을 기준으로 결정해야 합니다.

클라이언트에서 VLESS 노드에는 주소, 포트, UUID, 흐름 제어, 전송 네트워크, 보안 유형, 서버 이름, 핑거프린트 등의 필드가 포함되는 경우가 많습니다. 필드 사이에는 조합 제약이 있습니다. 예를 들어 일부 흐름 제어 값은 특정 전송 및 보안 계층에서만 사용할 수 있습니다. REALITY는 공개 키, 짧은 식별자, serverName 등의 정보를 추가로 요구합니다. 구독에서 하나라도 빠지면 클라이언트가 노드를 만들 수는 있어도 핸드셰이크 단계에서 실패할 수 있습니다. 따라서 목록에 노드가 표시되는지만으로 가져오기가 완전한지 판단하면 안 됩니다.

REALITY의 위치와 파라미터 관계

REALITY는 독립적인 프록시 프로토콜이 아니라 Xray 생태계의 보안 및 핸드셰이크 메커니즘이며, VLESS와 함께 사용하는 경우가 많습니다. 클라이언트는 해당 필드를 해석할 수 있는 Xray 코어를 사용해야 합니다. 설정의 publicKey는 클라이언트 검증에 사용되고, shortId는 서버 설정과의 일치 여부를 확인하며, serverName은 핸드셰이크 대상 선택에 관여합니다. fingerprint는 클라이언트 핸드셰이크 핑거프린트 정책을 지정합니다. 이 필드들은 서로 대신 사용할 수 있는 별칭이 아니므로 서버 설정에 각각 대응해야 합니다.

REALITY 설정에서 가장 흔한 문제는 필드는 있지만 값이 잘못 배치된 경우입니다. 서버 주소를 serverName에 넣거나, 노드 UUID를 공개 키로 착각하거나, 짧은 식별자를 복사하면서 일부 문자를 빠뜨리는 사례가 있습니다. 구독 링크에 파라미터가 포함되어 있어도 오래된 코어가 인식하지 못하는 필드를 무시하면 화면상으로는 가져오기가 성공한 것처럼 보여도 실제 설정은 불완전할 수 있습니다. 이때는 먼저 현재 클라이언트의 코어 유형을 확인한 뒤 다시 가져오세요. 기존 노드에서 시스템 프록시만 반복해서 전환하지 마세요.

성능 기대치는 구체적으로 설정하세요

VLESS는 프로토콜 처리가 가벼워 높은 처리량, 많은 동시 연결, 저전력 기기에서 이론적으로 유리할 수 있습니다. 하지만 사용자가 체감하는 연결 속도는 여러 요소가 함께 결정합니다. 왕복 지연 시간은 핸드셰이크 시간에, 패킷 손실은 재전송에, 서버 CPU와 대역폭은 지속 전송에, 전송 방식은 추가 캡슐화에, DNS는 첫 접속에 영향을 줍니다. 회선 자체의 변동이 크다면 VMess와 VLESS를 바꿔도 안정적으로 눈에 띄는 차이가 없을 수 있습니다.

REALITY는 핸드셰이크 파라미터가 많아 처음 설정할 때 일반적인 VLESS + TLS보다 필드 누락으로 실패하기 쉽습니다. 하지만 값이 올바르면 일상적으로 계속 조정할 필요는 없습니다. 유지 관리에서는 코어 지원 여부와 구독 필드의 완전성을 중점적으로 확인하세요. 클라이언트를 업그레이드한 뒤 기존 노드가 정상이라면 다시 만들 필요가 없습니다. 구독 갱신 후 갑자기 실패한다면 클라이언트를 전부 재설치하기보다 갱신 전후의 serverName, 공개 키, 짧은 식별자, 흐름 제어 필드를 비교하는 편이 효과적입니다.

이 조합을 사용하기에 적합한 조건

새 노드를 만들고 서버가 VLESS + REALITY를 명확히 제공하며 데스크톱에서 v2rayN을 사용하거나 Android에서 Xray 코어가 포함된 v2rayNG를 사용한다면 지원 경로가 분명합니다. Android에서 v2flyNG를 사용한다면 구독의 프로토콜과 보안 계층이 V2Fly 지원 범위에 속하는지 먼저 확인해야 합니다. 이름이 비슷하다고 바로 호환된다고 가정해서는 안 됩니다. 여러 코어에서 같은 구독을 공유해야 한다면 일반적인 VLESS + TLS 또는 호환성이 검증된 VMess 조합이 일관성을 유지하기 쉬운 경우도 있습니다.

최종 판단 기준은 ‘더 앞선 기술인가’가 아니라 서버, 코어, 구독이 같은 파라미터 조합을 안정적으로 표현할 수 있는지입니다. 선택한 뒤 세 가지를 확인하세요. 클라이언트에 보안 필드가 완전히 표시되는지, 연결 로그에 알 수 없는 설정 항목이 없는지, 연결이 여러 번 끊겼다 다시 연결된 뒤에도 복구되는지 확인합니다. 이 세 가지를 통과한 노드를 자주 사용하는 설정으로 지정하세요.

04 / TROJAN + SHADOWSOCKS

Trojan과 Shadowsocks: 서로 다른 두 가지 간소화 경로

Trojan의 설계 방향

Trojan은 비밀번호로 사용자를 인증하고 TLS에 의존해 보안 연결을 수립합니다. 설정 개념은 비교적 간단합니다. 서버 주소, 포트, 비밀번호, SNI, 인증서 검증, 전송 설정이 주요 항목입니다. VMess의 시간 기반 인증과 달리 Trojan은 TLS 계층이 올바른지에 더 크게 의존합니다. VLESS와 비교하면 보통 UUID가 아니라 비밀번호 필드를 사용합니다. 클라이언트 화면에 ‘비밀번호’와 ‘사용자 ID’가 모두 있다면 현재 노드 유형을 확인해 인증 정보를 잘못된 위치에 입력하지 않도록 하세요.

Trojan 연결 문제는 TLS에 집중되는 경우가 많습니다. 시스템 시간 오차, 인증서 이름과 SNI 불일치, 잘못된 포트, 인증서 체인 문제는 프록시 요청이 시작되기 전에 연결을 종료할 수 있습니다. 설정의 allowInsecure는 인증서 검증 동작을 제어하는 필드이며 일반적인 해결 스위치로 사용하면 안 됩니다. 정상적인 인증서 설정에서는 엄격한 검증을 유지하세요. 서버 인증서 구성을 정확히 이해하고 단시간 진단을 수행하는 경우에만 변경을 고려하고, 진단이 끝나면 원래 설정으로 되돌려야 합니다.

Shadowsocks의 핵심 구조

Shadowsocks는 흔히 SS라고 줄여 부르며, 핵심 설정은 서버, 포트, 비밀번호, 암호화 방식으로 구성됩니다. VMess나 VLESS의 UUID 모델을 사용하지 않으므로 서버와 클라이언트가 완전히 같은 암호화 방식을 선택해야 합니다. 설정 항목이 적고 프로토콜 처리가 직접적이어서 리소스가 제한된 기기나 단순한 연결 환경에서 관리 부담이 낮은 편입니다. 반면 기능 범위도 명확합니다. 복잡한 전송 조합이 필요하다면 사용 중인 코어와 서버가 추가 메커니즘으로 이를 지원하는지 확인해야 하며, 다른 프로토콜의 필드를 SS에 그대로 옮겨서는 안 됩니다.

암호화 방식을 이름만 보고 추측하지 마세요. 구독에서 제공한 값은 클라이언트에서도 그대로 유지해야 합니다. 가져온 뒤 방식이 비어 있거나 알 수 없는 값으로 바뀌었다면 클라이언트 코어가 해당 방식을 지원하지 않거나 구독 변환 과정에서 필드가 누락되었을 가능성이 큽니다. 먼저 클라이언트 로그에서 ‘unknown method’ 또는 유사한 해석 오류를 확인한 뒤 코어를 바꾸거나 구독 출력 형식을 호환되게 조정하세요. 비밀번호를 반복해서 바꿔도 암호화 방식 불일치는 해결되지 않습니다.

연결 속도와 리소스 사용량을 보는 방법

SS는 처리 경로가 대체로 짧아 설정 복잡도와 계산 비용을 낮추고 싶은 환경에 적합합니다. Trojan은 TLS 핸드셰이크가 필요하므로 첫 연결에 비용이 들지만, 연결 재사용과 안정적인 유지로 반복 핸드셰이크의 영향을 줄일 수 있습니다. 애플리케이션이 짧은 연결을 자주 만들면 DNS, TLS 세션 복구, 전송 재사용이 체감에 큰 영향을 줍니다. 지속적인 전송이 중심이라면 회선 대역폭과 서버 부하가 더 중요합니다.

웹페이지를 한 번 열어 본 속도만으로 프로토콜을 평가하지 마세요. 같은 서버, 같은 시간대, 같은 애플리케이션을 고정한 뒤 첫 연결, 지속 전송, 대기 후 복구, 네트워크 전환 후 재연결을 각각 관찰하는 방식이 더 정확합니다. 여러 번 반복하고 실패에 따른 재시도도 결과에 포함하세요. 특정 프로토콜이 가끔 더 높은 최고 속도를 보여도 모바일 네트워크나 약한 신호에서 더 안정적이라는 뜻은 아닙니다.

둘 중 하나를 선택하는 방법

서버가 표준 Trojan 설정을 제공하고 인증서와 도메인의 관계가 명확하며 클라이언트 코어가 완전히 지원한다면, 분명한 TLS 모델을 원하는 사용자에게 Trojan이 적합합니다. 서버가 SS를 제공하고 기기 리소스가 제한적이며 필드와 유지 관리 단계를 줄이는 것이 목표라면 SS가 더 직접적입니다. 둘 다 VMess나 VLESS의 ‘간소화 대체품’은 아닙니다. 인증 모델과 보안 경계가 다르기 때문입니다. 이전할 때는 서버가 해당 프로토콜을 함께 제공해야 하며 클라이언트 드롭다운에서 유형만 바꿔서는 안 됩니다.

하나의 구독에서 여러 프로토콜을 제공한다면 이미 안정성을 검증한 노드 하나를 기준으로 남겨 두고 새 프로토콜 조합을 테스트하세요. 기준 노드는 로컬 네트워크 문제와 새 설정 문제를 구분하는 데 도움이 됩니다. 모든 노드가 동시에 실패하면 시스템 프록시, DNS, 네트워크 연결을 먼저 확인하고, 특정 유형만 실패할 때 해당 프로토콜의 인증 및 보안 필드로 돌아가세요.

05 / PERFORMANCE

연결 속도, 리소스 사용량, 모바일 배터리

속도는 네 단계로 나눠 관찰해야 합니다

‘속도’에는 최소한 DNS 확인, 핸드셰이크, 첫 패킷, 지속 전송의 네 단계가 포함됩니다. 도메인 확인은 클라이언트가 대상 주소를 얻는 시점을 결정하고, 프로토콜 및 보안 계층 핸드셰이크는 연결을 사용할 수 있게 되는 시점을 결정합니다. 첫 패킷 시간은 애플리케이션 요청과 원격 응답을 반영하며, 지속 전송이 일반적으로 말하는 대역폭에 가깝습니다. VMess, VLESS, Trojan, SS는 프로토콜 처리에서 차이가 있지만 DNS가 느리거나 회선 손실이 심하면 더 큰 네트워크 변수가 차이를 덮어버립니다.

테스트할 때는 노드 주소, 전송 방식, 보안 계층을 먼저 고정하고 변수 하나만 바꾸세요. VMess + WebSocket + TLS와 VLESS + TCP + REALITY를 직접 비교하면 프로토콜, 전송, 보안 계층의 차이가 한꺼번에 포함되어 어느 한 요소의 영향으로 볼 수 없습니다. 서버가 제공하는 비교 가능한 조합을 사용해 같은 네트워크에서 반복 테스트하는 것이 더 합리적입니다. 최고 처리량만 기록하지 말고 연결 성공률과 복구 능력도 기록하세요.

CPU와 메모리 비용은 어디에서 발생하는가

CPU는 주로 암호화, 프로토콜 캡슐화, TLS 핸드셰이크, 데이터 복사, 압축, 추가 전송 처리에 사용됩니다. 메모리는 연결 수, 버퍼, 라우팅 규칙, DNS 캐시, 로그 수준과 관련이 있습니다. 프로토콜 자체가 가볍다고 해서 전체 클라이언트 사용량도 반드시 낮은 것은 아닙니다. 그래픽 인터페이스, 코어 프로세스, 규칙 집합, TUN 모드가 주요 비용이 될 수 있습니다. 데스크톱의 v2rayN은 보통 인터페이스 프로세스가 코어 프로세스를 관리하므로 리소스를 확인할 때 관련 프로세스를 합산해 살펴봐야 합니다.

로그 수준도 비용에 영향을 줍니다. 문제를 해결할 때는 일시적으로 로그 상세도를 높일 수 있지만, 평상시에는 일반 수준으로 되돌려 과도한 디스크 쓰기를 피하세요. 라우팅 규칙이 많을수록 매칭 과정과 메모리 사용량이 늘어나지만, 합리적으로 분류된 규칙이 보통 첫 번째 병목은 아닙니다. 실제로는 중복 규칙, 지나치게 큰 도메인 목록, 반복되는 DNS 조회 실패, 지속적인 연결 재시도를 확인하는 것이 중요합니다.

모바일 배터리를 좌우하는 주요 요인

Android에서 v2rayNG 또는 v2flyNG를 사용할 때 배터리 소모는 프로토콜만으로 결정되지 않습니다. 백그라운드 연결 유지, Wi-Fi와 모바일 네트워크 전환, 절전 정책에 따른 프로세스 종료, 잦은 DNS 요청, 실패한 재연결, 많은 동시 연결이 모두 영향을 줍니다. 이론상 비용이 낮지만 자주 끊기는 설정은 조금 더 복잡해도 안정적인 설정보다 배터리를 더 많이 사용할 수 있습니다. 재연결할 때마다 DNS 확인, 핸드셰이크, 애플리케이션 연결 복구가 다시 필요하기 때문입니다.

배터리를 확인할 때는 먼저 클라이언트가 계속 실행되는 데 필요한 시스템 권한을 얻었는지 확인하고, 기기 설정에서 적절한 절전 예외 목록에 추가하세요. 그런 다음 대기 상태에서 연결 로그가 자주 발생하는지 살펴봅니다. 화면을 끈 뒤 연결이 계속 끊긴다면 바로 프로토콜을 바꾸기보다 시스템 백그라운드 제한을 먼저 확인하세요. Android의 VpnService 권한, 절전 예외 목록, 앱별 프록시에 대해서는 v2rayNG Android 사용 팁에서 더 알아볼 수 있습니다.

TUN 모드는 리소스 기준값을 바꿉니다

데스크톱에서 TUN 모드를 켜면 일반 시스템 프록시보다 클라이언트가 처리하는 트래픽 범위가 넓어지는 경우가 많습니다. 코어가 더 많은 연결을 맡고 추가 DNS 및 라우팅 판단을 수행할 수도 있습니다. 따라서 일반 시스템 프록시와 TUN 모드의 프로토콜 비용을 비교하는 것은 직접적인 의미가 없습니다. 먼저 프록시 모드를 고정한 뒤 프로토콜 차이를 관찰하세요. TUN으로 전환한 후 사용량이 크게 늘었다면 라우팅 범위, DNS 설정, 트래픽 루프백 여부를 먼저 확인하세요.

v2rayN의 TUN 모드는 시스템 프록시 설정을 따르지 않는 애플리케이션까지 일괄 처리해야 할 때 적합하지만, 연결 실패의 첫 해결책으로 사용해서는 안 됩니다. 일반 시스템 프록시에서 연결되지 않는 노드는 TUN으로 바꿔도 변수만 늘어나는 경우가 많습니다. 먼저 클라이언트 내장 테스트로 노드를 확인하고, 시스템 프록시를 켜 브라우저에서 검증한 다음, 애플리케이션 요구에 따라 TUN 사용 여부를 결정하세요.

반복 가능한 테스트 기록 만들기

각 후보 조합에 프로토콜, 전송, 보안 계층, 코어, 프록시 모드, 테스트 네트워크를 기록하는 것이 좋습니다. 한 번에 하나만 변경하고 첫 연결, 10분간의 지속 사용, 대기 후 복구, 네트워크 전환을 연속으로 관찰하세요. 최고 속도는 조금 높더라도 재연결 실패가 많다면 성공률이 안정적인 조합을 우선해야 합니다. 일상적인 체감은 한 번의 최고 결과가 아니라 대부분의 시간 동안 사용할 수 있는지로 결정됩니다.

리소스가 비정상적으로 높다면 변수를 순서대로 줄이세요. 상세 로그를 끄고, 간단한 라우팅으로 되돌리고, TUN을 종료하고, 노드 하나만 남긴 뒤 코어 프로세스를 관찰합니다. 사용량이 정상으로 돌아오면 기능을 하나씩 다시 활성화하세요. 이렇게 하면 프로토콜, 규칙, 프록시 모드 중 어느 비용인지 구분할 수 있어 모든 문제를 노드 유형 탓으로 돌리는 일을 피할 수 있습니다.

06 / CORE FAMILY

V2Fly와 Xray 코어 계열 및 설정 호환성

공통 기반과 서로 다른 발전 방향

V2Fly와 Xray는 모두 Project V 생태계의 설정 개념을 이어받아 일반적인 인바운드, 아웃바운드, 라우팅, DNS, 전송 계층 구조가 상당 부분 비슷합니다. 둘은 그래픽 클라이언트가 아니라 설정을 해석하고 연결을 처리하는 핵심 프로그램입니다. v2rayN은 해당 코어를 관리할 수 있는 데스크톱 그래픽 클라이언트이고, v2rayNG는 주로 Xray 코어를 사용하며, v2flyNG는 V2Fly 코어를 대상으로 합니다. 클라이언트를 선택한다는 것은 실제로 기본 코어의 기능도 선택하는 셈입니다.

공통 기반 덕분에 많은 VMess, Shadowsocks, Trojan, 일반 VLESS, 일반적인 라우팅 규칙은 비슷한 방식으로 표현할 수 있습니다. 하지만 ‘비슷하다’고 해서 모든 필드가 양방향 호환되는 것은 아닙니다. Xray는 VLESS, XTLS, REALITY 등의 방향으로 자체 기능을 추가했고 V2Fly는 기존 설정 체계를 따라 발전해 왔습니다. 한 코어가 받아들이는 설정 파일이라고 해서 다른 코어가 모든 확장 필드를 이해한다는 뜻은 아닙니다.

기능 차이는 필드 단위로 확인해야 합니다

호환성을 판단할 때 ‘VLESS를 지원하는가’에서 멈추지 말고 보안 계층, 흐름 제어, 전송 방식, 확장 파라미터까지 확인하세요. 예를 들어 일반 VLESS + TLS와 VLESS + REALITY는 코어 요구 사항이 다릅니다. 같은 TCP 전송이라도 특정 흐름 제어를 켰는지에 따라 지원 범위가 달라집니다. 구독 이름에는 VLESS만 표시되어 있어도 실제 코어 선택에 영향을 주는 파라미터는 쿼리 문자열이나 하위 JSON에 들어 있을 수 있습니다.

Xray 전용 필드를 V2Fly에서 사용하면 가져오기 과정에서 무시되거나, 시작 시 알 수 없는 필드 오류가 발생하거나, 노드는 저장되지만 연결되지 않을 수 있습니다. 반대로 이전할 때도 기본값이나 필드명이 달라 문제가 생길 수 있습니다. 가장 안전한 방법은 오류 항목을 바로 삭제하는 것이 아니라 그 항목이 어떤 기능을 담당하는지 먼저 확인하는 것입니다. 보안 계층에 필요한 파라미터라면 삭제 후 설정이 시작되더라도 동일한 연결을 얻을 수 없습니다.

설정 이전 확인 순서

한 코어에서 다른 코어로 바꾸기 전에 현재 노드 유형, 전송 방식, 보안 계층, 라우팅 설정을 내보내거나 기록하세요. 두 번째로 설정에 대상 코어가 인식하지 못하는 확장 필드가 있는지 확인합니다. 세 번째로 대상 클라이언트에 노드 하나만 가져와 코어가 시작되는지 확인합니다. 네 번째로 DNS와 라우팅 로그를 점검해 요청이 예상한 아웃바운드로 실제 전달되는지 확인합니다. 마지막으로 전체 구독을 이전하세요. 모든 노드를 한 번에 옮기면 오류 원인을 찾기 어렵습니다.

그래픽 인터페이스만 업그레이드하고 코어 계열이 바뀌지 않았다면 보통 설정을 다시 작성할 필요가 없습니다. 코어를 바꾼 뒤 일반 VMess 노드는 작동하지만 REALITY 노드만 실패한다면 네트워크 드라이버를 재설치하기보다 Xray 확장 기능과 보안 필드로 확인 범위를 좁혀야 합니다. 반대로 모든 노드가 시작되지 않는다면 먼저 클라이언트가 코어 파일을 올바르게 호출하는지, 로컬 수신 포트가 사용 중인지, 설정 문법을 통과하는지 확인하세요.

라우팅과 DNS에도 호환성 범위가 있습니다

프록시 프로토콜이 작동한다고 해서 전체 설정이 완전히 호환되는 것은 아닙니다. 라우팅 규칙의 도메인 분류, 규칙 집합 참조, DNS 조회 정책, 아웃바운드 태그에도 차이가 있을 수 있습니다. 이전 후 노드 테스트는 성공했지만 일부 웹사이트에서 동작이 이상하다면 존재하지 않는 태그를 라우팅 규칙이 참조하는지, DNS 아웃바운드가 올바른 객체를 가리키는지, 규칙 순서가 바뀌었는지 확인하세요. 하위 설정은 보통 순서대로 매칭되므로 앞의 포괄적인 규칙이 뒤의 구체적인 규칙을 덮을 수 있습니다.

설정을 단순화하는 것은 호환성을 검증하는 효과적인 방법입니다. 로컬 인바운드 하나, 프록시 아웃바운드 하나, 최소 DNS 설정만 남겨 기본 연결을 확인한 뒤 분할 라우팅을 추가하세요. 최소 테스트 설정에서 복잡한 규칙, TUN, 여러 백업 아웃바운드를 동시에 켜지 마세요. 기능을 한 계층 추가할 때마다 연결을 확인하면 어느 계층에서 차이가 생겼는지 명확히 알 수 있습니다.

기본 코어 선택 방법

구독이 VMess, 일반 VLESS, Trojan, SS 위주이고 기존 V2Fly 설정이 안정적이라면 기존 코어를 유지할 수 있습니다. 구독에 REALITY, 특정 흐름 제어, Xray 확장 필드가 명확히 포함되어 있다면 Xray 지원 경로를 선택하세요. 데스크톱에서는 우선 v2rayN을 사용하고 노드 요구 사항에 따라 코어를 지정합니다. Android에서는 구독 기능에 맞춰 v2rayNG와 v2flyNG 중에서 선택하세요.

코어 선택은 영구적으로 고정되는 결정이 아니지만, 바꿀 때마다 명확한 이유가 있어야 합니다. 이름이 더 익숙하다는 이유만으로 코어를 바꾸면 설정 해석 차이만 늘어납니다. 구체적인 기능 비교는 Xray 코어와 V2Fly 코어의 차이에서 확인할 수 있습니다. 프로토콜 지원, 성능, 설정 이전의 경계를 더 자세히 설명합니다.

07 / SUBSCRIPTION

구독 형식, 공유 링크, 클라이언트 호환성

구독은 설정 컨테이너이지 프로토콜이 아닙니다

구독 링크는 하나 이상의 노드 설정을 클라이언트에 제공하지만, 그 자체가 VMess, VLESS, Trojan, SS 중 어떤 프로토콜을 사용할지 결정하지는 않습니다. 클라이언트가 구독을 갱신하면 텍스트나 구조화된 내용을 내려받고, 그 안의 공유 링크, 필드, 메모를 내부 설정으로 변환합니다. 따라서 ‘구독 갱신 성공’은 내용이 받아들여졌다는 뜻일 뿐, 모든 노드가 완전히 해석되었거나 연결된다는 의미는 아닙니다.

일반적인 공유 링크는 vmess://, vless://, trojan://, ss://처럼 서로 다른 스킴 이름으로 프로토콜을 구분합니다. VMess 공유 내용은 JSON을 포함한 채 인코딩되는 경우가 많습니다. VLESS와 Trojan은 URI 사용자 정보와 쿼리 파라미터로 전송 방식, 보안 계층, 추가 필드를 표현하는 경우가 많고, SS 링크에는 암호화 방식, 비밀번호, 주소, 포트가 들어갑니다. 클라이언트는 해당 스킴과 링크 내 파라미터 버전을 모두 인식해야 합니다.

같은 구독인데 클라이언트마다 노드 수가 다른 이유

노드 수가 다른 데에는 보통 네 가지 원인이 있습니다. 첫째, 클라이언트가 구독의 프로토콜이나 확장 필드를 지원하지 않아 해당 항목을 건너뛰는 경우입니다. 둘째, 구독 내용에 형식 오류가 있어 일부 링크를 해석하지 못하는 경우입니다. 셋째, 클라이언트에서 중복 제거, 필터, 키워드 제외가 설정된 경우입니다. 넷째, 구독 변환 서비스가 클라이언트 유형에 따라 다른 내용을 출력하는 경우입니다. 문제를 해결할 때는 총 개수만 비교하지 말고 먼저 프로토콜 유형별 분포를 비교하세요.

v2rayNG에서는 REALITY 노드가 보이는데 v2flyNG에서는 보이지 않는다면 먼저 코어 지원 범위를 확인하세요. 두 클라이언트 모두 같은 VMess 노드가 빠졌다면 구독 인코딩이나 링크 완전성 문제일 가능성이 큽니다. 데스크톱의 v2rayN에서 일부 노드만 가져와진다면 갱신 로그의 ‘건너뜀’, ‘알 수 없는 스킴’, ‘필드 해석 실패’ 같은 메시지를 확인하세요. 실제 설정은 노드 이름에 들어 있지 않으므로 이름을 직접 복사해 보충하지 마세요.

URI 인코딩으로 생기는 숨은 문제

비밀번호, 메모, 경로, 쿼리 파라미터에 특수 문자가 있으면 URI 규칙에 따라 인코딩해야 합니다. 구독 변환 과정에서 중복 인코딩이 발생하면 클라이언트에 퍼센트 인코딩 문자열이 불필요하게 늘어납니다. 반대로 전혀 인코딩하지 않으면 샵, 물음표, 슬래시 등이 링크 구조로 해석될 수 있습니다. Trojan과 SS의 비밀번호는 특히 주의해야 합니다. 가져온 뒤 비밀번호 길이가 눈에 띄게 달라졌다면 클라이언트에서 문자를 추측하지 말고 원본 구독을 확인하세요.

링크 끝의 샵 뒤 내용은 보통 노드 메모리로 사용되며 인증에는 관여하지 않습니다. 메모리가 깨져 보여도 일반적으로 연결 실패의 원인은 아니지만, 구독 인코딩 과정에 문제가 있을 수 있음을 알려 주는 신호입니다. 메모리와 핵심 파라미터가 함께 이상하다면 구독 내용을 다시 완전히 받아오세요. 링크를 복사할 때 자동 줄바꿈이나 문자 치환이 발생하는 편집기를 거치지 말고, 화면에 잘린 일부만 복사하지도 마세요.

구독 갱신 후 안전한 작업 순서

갱신 전에 이미 작동을 확인한 노드 하나를 보존하고 기존 설정을 바로 삭제하지 마세요. 갱신 후 노드 유형과 개수를 확인한 다음 새 노드 하나를 선택해 클라이언트 내장 테스트를 실행합니다. 테스트가 통과하면 시스템 프록시를 켜 실제 접속을 확인하고, 마지막으로 라우팅이나 TUN 설정을 갱신하세요. 이렇게 하면 구독 해석, 노드 연결, 시스템 트래픽 처리를 세 단계로 나눌 수 있습니다. 어느 단계에서 실패해도 이전의 정상 상태로 돌아갈 수 있습니다.

구독 갱신 후 기존 노드가 덮어써졌다면 클라이언트에 로컬 수정 보존, 메모리 기준 병합, 구독 그룹 분리 같은 옵션이 있는지 확인하세요. 구독 노드를 직접 수정하면 다음 갱신 때 덮어써지므로 장기적인 수정은 구독 원본에서 처리해야 합니다. 임시 테스트 노드는 독립 설정으로 복사하고 알아보기 쉬운 메모를 붙이는 것이 자동 갱신 항목과 혼동하지 않는 방법입니다.

클라이언트와 구독 유형을 맞춰 선택하세요

Windows, macOS, Linux 데스크톱에서는 구독을 한곳에서 관리하고 코어를 전환하며 로그를 확인하기 쉬운 v2rayN을 우선 선택하세요. Android 구독이 Xray 확장 기능 중심이라면 v2rayNG를, V2Fly 코어 호환성이 명확히 필요하다면 v2flyNG를 선택하세요. 설치 패키지는 클라이언트 받기 페이지에서 플랫폼과 아키텍처에 맞게 선택해야 하며, 공유 링크 이름만으로 설치 패키지 유형을 추측하지 마세요.

구독 링크는 설정 진입점이므로 공개 페이지나 스크린샷에 전체 내용을 그대로 노출하지 마세요. 문제를 해결할 때는 프로토콜 유형, 오류 메시지, 민감하지 않은 필드만 기록하고 인증 정보는 비공개로 유지해야 합니다. 다른 사람에게 문제를 설명할 때는 ‘프로토콜 + 전송 + 보안 계층 + 코어 + 오류 단계’ 형식으로 정리하면 대체로 원인을 좁히는 데 충분합니다.

08 / SCENARIO GUIDE

사용 상황에 맞춰 프로토콜·코어·클라이언트 선택

데스크톱 일상 사용: 유지 관리 변수를 우선 줄이세요

Windows, macOS, Linux 데스크톱 환경에서는 v2rayN을 우선 사용하세요. 첫 단계에서는 구독에 이미 있는 프로토콜을 기준으로 선택하고 서버가 제공한 노드 유형을 임의로 바꾸지 않습니다. 두 번째로 REALITY나 특정 Xray 확장 기능이 포함되어 있는지 확인하고, 포함되어 있다면 해당 Xray 코어 지원 경로를 사용합니다. 세 번째로 일반 시스템 프록시 모드에서 단일 노드 연결을 확인하세요. 시스템 프록시를 따르지 않는 앱을 사용하거나 전체 트래픽을 처리해야 할 때만 TUN 모드를 검토하면 됩니다.

프로토콜 측면에서 기존 VMess + TLS 설정이 안정적이라면 계속 사용해도 됩니다. 새 설정에 VLESS + REALITY가 명확히 제공된다면 모든 필드를 가져오고 코어를 확인하세요. 서버가 Trojan을 제공한다면 TLS와 SNI를 중점적으로 점검하고, SS를 사용한다면 암호화 방식이 일치하는지 확인하세요. 데스크톱은 보통 이들 프로토콜을 처리할 리소스가 충분하므로 선택의 초점은 작은 이론적 비용 차이가 아니라 호환성, 복구 능력, 유지 관리 비용에 맞춰야 합니다.

Android 장시간 백그라운드 사용: 먼저 재연결을 제어하세요

Android 구독에 VLESS + REALITY 같은 Xray 기능이 포함되어 있다면 v2rayNG를 우선 선택하세요. 설정이 V2Fly 코어를 중심으로 구성되어 있다면 v2flyNG를 선택합니다. 가져오기를 완료한 뒤 먼저 VpnService 연결 권한을 부여하고, 기기의 백그라운드 관리 방식에 맞춰 절전 예외 목록을 설정하세요. 화면을 끈 뒤 연결이 유지되는지 관찰하고, 로그에 연결 해제와 핸드셰이크 재시도가 반복되면 시스템 백그라운드 제한부터 해결하세요.

모바일에서 프로토콜을 선택할 때는 안정적인 연결과 대기 후 복구를 중시해야 합니다. SS는 설정이 간결하고 VLESS 자체는 가볍지만, 어떤 프로토콜이든 반복적으로 실패하고 재시도하면 배터리 소모가 늘어납니다. 테스트할 때는 같은 노드를 반나절 이상 고정해 대기, 네트워크 전환, 앱 깨우기 상황을 관찰하세요. 짧은 속도 측정 결과만 보지 마세요. 앱별 프록시를 사용하면 프록시가 필요 없는 앱의 연결 수를 줄여 불필요한 트래픽 처리도 낮출 수 있습니다.

여러 기기에서 구독 공유: 공통 지원 범위를 기준으로 선택하세요

같은 구독을 데스크톱과 Android에서 함께 사용한다면 모든 대상 클라이언트가 공통으로 지원하는 프로토콜 조합을 기준으로 삼아야 합니다. VMess, Trojan, SS, 일반 VLESS는 대체로 지원 클라이언트가 많지만 구체적인 전송 및 보안 필드까지 확인해야 합니다. 구독에 REALITY가 포함되어 있다면 지원 클라이언트에서는 해당 노드를 사용하고, 호환 범위가 더 넓은 백업 노드도 남겨 두세요. ‘이름을 통일한다’는 이유로 서로 다른 보안 조합을 억지로 같은 링크로 변환하지 마세요.

공유 구독에서 중요한 것은 필드의 일관성과 명확한 그룹 구성입니다. 프로토콜이나 코어 요구 사항에 따라 ‘VLESS-REALITY-Xray’ 또는 ‘VMess-TLS-공용’처럼 알아보기 쉬운 메모를 붙일 수 있지만, 메모는 식별용일 뿐 실제 파라미터를 대신하지 않습니다. 갱신할 때마다 두 종류의 기기에서 각각 노드 하나를 테스트해 변환 과정에서 쿼리 파라미터가 삭제되지 않았는지 확인하세요.

저사양·고동시성 환경: 전체 경로를 먼저 테스트하세요

리소스가 제한된 기기에서는 SS, VLESS처럼 처리가 직접적인 방식을 우선 비교할 수 있지만 서버 지원과 보안 계층이 완전하다는 전제에서 선택해야 합니다. 동시 연결이 많은 환경에서는 연결 재사용, 전송 방식, 코어 버퍼, 서버 제한도 함께 봐야 합니다. 프로토콜 캡슐화가 가벼워도 비용의 일부만 줄일 뿐이며, 회선 손실, 서버 부하, 잘못된 DNS 정책을 해결해 주지는 않습니다.

테스트할 때 CPU, 메모리, 연결 성공률, 지속 처리량을 기록하세요. 프로토콜 비용을 줄여 CPU는 개선되었지만 실패율이 높아졌다면 전체 결과는 오히려 나빠질 수 있습니다. 목표 부하에서 안정적으로 계속 작동하는 설정을 선택하고 언제든 되돌릴 수 있는 구성을 남겨 두세요. 전송, 코어, 보안 계층을 조정할 때는 한 번에 하나만 바꿔 결과의 원인을 분명히 하세요.

최종 확인 목록

선택을 마친 뒤 다음 여덟 가지를 순서대로 확인하세요. 프로토콜 이름이 서버와 일치하는지, 클라이언트 코어가 모든 필드를 지원하는지, 주소와 포트가 완전한지, 인증 정보에 공백이나 잘림이 없는지, 전송 방식과 경로가 일치하는지, TLS 또는 REALITY 파라미터가 완전한지, 클라이언트 단일 노드 테스트가 통과했는지, 시스템 프록시나 VpnService로 트래픽을 처리한 뒤 실제 접속이 정상인지 확인합니다. 하나라도 통과하지 못했다면 라우팅이나 TUN을 추가하지 말고 현재 단계에서 멈추세요.

연결에 성공한 뒤 연결 해제 후 재연결, 대기 후 복구, 네트워크 전환을 관찰하세요. 일정 시간 안정적으로 작동하면 프로토콜, 전송, 보안 계층, 코어, 클라이언트 이름을 포함한 현재 조합을 텍스트로 기록해 두세요. 나중에 문제가 생기면 이 기록을 기준으로 바뀐 필드만 비교하면 됩니다. 전체 구독을 다시 가져오는 것보다 원인을 찾기 쉽습니다.

한 페이지로 정리한 선택 결론

기존 설정이 성숙했고 여러 코어 간 호환성을 중시한다면 VMess를 우선 유지할 수 있습니다. Xray 생태계에서 완전한 VLESS + REALITY 파라미터를 제공하는 새 설정이라면 해당 조합을 지원하는 코어와 클라이언트를 사용하세요. 명확한 TLS 인증 모델을 원하고 인증서 설정이 완전하다면 Trojan을 선택할 수 있습니다. 설정을 단순하게 구성하고 서버가 SS를 명확히 제공하며 암호화 방식이 호환된다면 Shadowsocks를 사용할 수 있습니다. 모든 상황에 적용되는 프로토콜 순위는 없습니다.

데스크톱에서는 v2rayN을 우선 선택하고 Android에서는 코어 요구 사항에 따라 v2rayNG 또는 v2flyNG를 사용하세요. 선택을 마쳤다면 사용 가이드로 돌아가 구독 가져오기, 프록시 활성화, 연결 확인 순서대로 진행할 수 있습니다. 클라이언트가 시작 직후 종료되거나 포트가 사용 중이거나 인증서 핸드셰이크 오류가 계속된다면 문제 해결 및 TLS 인증서 오류 점검 목록을 확인하세요.