V2Ray 프로토콜 및 코어 기술 레퍼런스

v2rayNG나 v2rayN에서 노드를 열기 전에 세 계층을 먼저 구분해 두면 이후 선택이 훨씬 명확해집니다. 세 계층은 클라이언트, 코어, 프로토콜과 전송이며, 각 계층에서 바꿀 수 있는 것은 서로 다릅니다.

세 계층의 역할

클라이언트는 눈에 보이는 계층입니다. 데스크톱에서는 v2rayN, 안드로이드에서는 v2rayNG와 v2flyNG입니다. 클라이언트는 인터페이스, 구독 관리, 라우팅 스위치, 앱별 프록시 같은 조작을 담당하고 노드 정보를 코어가 읽을 수 있는 설정으로 변환합니다.

코어는 실제로 연결을 맺는 프로그램입니다. JSON 설정을 읽어 inbounds로 로컬 트래픽을 받고 outbounds로 트래픽을 내보내며, 그 사이에서 routing의 규칙에 따라 어느 아웃바운드로 보낼지 결정합니다. v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용하며 v2rayN 데스크톱 버전 역시 Xray 코어가 중심입니다. 코어는 어떤 프로토콜을 쓸 수 있는지 결정합니다. 예를 들어 REALITY는 Xray 쪽에만 존재하므로 REALITY 노드를 v2flyNG에 가져오면 파싱되지 않습니다.

프로토콜과 전송은 실제 성능을 좌우하는 계층입니다. 프로토콜은 VMess, VLESS, Trojan, Shadowsocks, REALITY 같은 인증과 캡슐화 방식이고, 전송은 TCP, WebSocket, gRPC 같은 운반 방식이며, 여기에 TLS 사용 여부가 더해집니다. 이 계층은 보통 구독과 함께 내려오기 때문에 일상적인 사용에서 직접 작성할 일은 거의 없습니다.

일상에서 바꿀 수 있는 항목은 몇 개뿐

클라이언트 설정 화면을 열면 일반 사용자가 실제로 건드리는 옵션은 몇 군데에 모여 있습니다. 어떤 노드를 쓸지, 라우팅 모드를 무엇으로 할지, 어떤 앱을 프록시로 보낼지, 부팅 시 자동 실행을 할지입니다. 프로토콜과 전송은 노드에 딸려 오는 것이지 현장에서 편집하는 것이 아닙니다. 그래서 "프로토콜을 잘 고르는 일"은 구독을 고르거나 자체 서버 설정을 정리하는 단계에서 일어나며, 연결할 때마다 일어나는 일이 아닙니다. 프로토콜 차이를 이해하는 가치는 두 가지입니다. 같은 구독에 여러 프로토콜 노드가 있을 때 어느 것을 먼저 시도할지 알 수 있고, 특정 노드가 연결되지 않을 때 문제가 프로토콜 파라미터에 있는지 링크 자체에 있는지 판단할 수 있습니다.

이 페이지와 빠른 시작 페이지의 역할 분담

빠른 시작은 한 번의 연결을 성공시키는 최단 경로를 담당합니다. 구독 가져오기, 모드 선택, 연결, 확인까지 각 단계에서 필요한 동작만 설명합니다. 이 페이지는 그 흐름을 반복하지 않고 각 단계 뒤에 있는 선택을 설명합니다. 프로토콜 간 차이, 두 코어의 선택 기준, 구독 필드 대응, 어떤 상황에 어떤 조합을 쓸지까지입니다. 지금 당장 연결만 되면 된다면 빠른 시작을 먼저 보세요. 구독을 고르거나 자체 설정을 정리하거나 문제를 해결하는 중이라면 이 페이지에 머무르세요.

목표별 섹션 찾기

• 다섯 가지 프로토콜의 설계 차이가 궁금하다 → 프로토콜 계열
• 핸드셰이크 오버헤드와 자원 사용량을 비교하고 싶다 → 속도와 오버헤드 비교
• v2rayNG와 v2flyNG의 코어 차이가 궁금하다 → 코어 계열
• 구독 가져오기가 실패하거나 필드가 맞지 않는다 → 구독 형식과 호환성
• 전송 방식과 라우팅 모드의 영향을 알고 싶다 → 전송과 라우팅
• 안드로이드 기기의 전력 소모가 신경 쓰인다 → 모바일 배터리 사용량
• 추천 조합을 바로 보고 싶다 → 상황별 선택
• 필드 빠른 조회나 문제 해결 목록이 필요하다 → 파라미터 빠른 조회와 문제 해결

용어 정리

이 페이지에서 노드는 서버 주소, 포트, 인증 필드, 전송 파라미터를 포함한 완전한 아웃바운드 설정을 뜻하고, 구독은 여러 노드 정보를 담은 링크나 파일을 뜻하며, 코어는 v2ray-core 계열의 처리 프로그램을 뜻합니다. 인바운드와 아웃바운드는 각각 로컬 트래픽의 입구와 출구에 해당합니다. 플로우 제어는 프로토콜 계층에서 데이터 전달 방식을 제어하는 파라미터입니다. REALITY는 이 페이지에서 프로토콜 계층 방안으로 다루며, 선택과 호환성 판단에 초점을 맞추고 서버 구축 세부 사항은 펼치지 않습니다.

프로토콜 간 차이는 대부분 "누가 더 빠른가"처럼 한마디로 답할 수 있는 문제가 아니라, 각 방안이 설계 당시 무엇을 우선 해결했고 무엇을 의도적으로 포기했는지의 문제입니다. 다섯 가지 프로토콜을 각자의 출발점에 놓고 보면 선택할 때의 의문이 훨씬 줄어듭니다.

VMess: 프로토콜 자체에 인증과 암호화 포함

VMess는 V2Ray 프로젝트 초기에 자체 개발한 프로토콜로, 품질이 불안정한 링크에서도 신원 확인과 데이터 캡슐화를 완료하는 것이 목표였습니다. UUID 신원 필드와 타임스탬프 검증을 갖추고 있으며, 초기에는 alterId 방식으로 여러 하위 신원을 생성했지만 이후 AEAD 인증 암호화로 바뀌면서 alterId를 0으로 두는 것이 주류가 되었습니다. 설계상 특징은 인증과 암호화가 모두 프로토콜 내부에서 이루어지므로 외부 TLS에 의존하지 않아도 동작한다는 점입니다. 대가는 모든 패킷에 캡슐화 계층이 하나 더 붙고, 핸드셰이크 때 클라이언트와 서버가 요청과 응답을 한 번 주고받아야 하므로 모바일 기기에서 프로세서 웨이크업이 몇 번 더 발생한다는 것입니다.

VLESS: 암호화는 외부에 맡김

VLESS는 VMess의 감량 버전으로 이해할 수 있습니다. 프로토콜 자체의 암호화 계층을 없애고 가벼운 신원 표시와 선택적 플로우 제어 파라미터만 남겼으며, 암호화는 전적으로 외부 채널, 보통 TLS에 맡깁니다. 선택은 분명합니다. "그냥 돌려도 암호화되는" 능력을 포기하고 더 짧은 핸드셰이크 경로와 더 적은 캡슐화 바이트를 얻습니다. 따라서 VLESS는 반드시 TLS나 그에 준하는 신뢰할 수 있는 암호화 채널과 함께 사용해야 하며, 단독으로 돌리면 기밀성이 제공되지 않습니다. Xray 코어에서는 VLESS에 flow 파라미터를 붙여 XTLS Vision 플로우 제어를 활성화하면 암복호화 계층을 한층 더 줄일 수 있습니다.

Trojan: 트래픽을 표준 HTTPS처럼 유지

Trojan은 새로운 트래픽 형태를 만들지 않고 프록시 트래픽을 평범한 HTTPS 접속처럼 보이게 합니다. 서버는 443 포트를 열고 실제 인증서를 보유하며, 비밀번호가 맞으면 트래픽을 전달하고 틀리면 요청을 실제 웹사이트로 되돌립니다. 외부에서 보면 평범한 웹 서버입니다. 대가는 도메인과 유효한 인증서가 반드시 필요하고 인증서나 포트 설정이 잘못되면 완전히 사용할 수 없다는 점입니다. 장점은 설정 개념이 적어 이해 부담이 낮고 트래픽 형태가 일반 HTTPS와 매우 비슷하다는 것입니다.

Shadowsocks: 가벼운 대칭 암호화

Shadowsocks는 가벼운 대칭 암호화 노선을 따릅니다. 클라이언트와 서버가 비밀번호 하나를 공유하고 그 비밀번호에서 암호화 키를 유도하며, 별도의 신원 핸드셰이크 필드가 없습니다. 흔한 암호화 방식은 chacha20-ietf-poly1305, aes-256-gcm 같은 AEAD 알고리즘입니다. 캡슐화 오버헤드가 여러 방안 중 가장 작고 구현도 가장 단순해 연산 능력이 제한된 기기에서 여전히 자주 쓰입니다. 대가는 프로토콜 자체가 위장 계층을 제공하지 않아 트래픽 특징이 비교적 고정적이며, 외부 캡슐화나 플러그인으로 보완해야 한다는 점입니다.

REALITY: 실제 사이트의 핸드셰이크 절차를 빌려옴

REALITY는 Xray 쪽에서 제안한 방식으로, 인증서 유지 비용이라는 구체적인 문제를 겨냥합니다. 일반 TLS 방식은 도메인과 인증서를 직접 보유해야 하지만, REALITY는 핸드셰이크 단계에서 특정 실제 사이트의 인증서 체인을 빌립니다. 클라이언트는 대상 사이트의 공개 키를 미리 알고 있고 핸드셰이크에서 검증하는 대상도 그 사이트이며, 서버는 자체 인증서를 보유할 필요가 없습니다. 사용자 입장에서 REALITY 노드는 보통 몇 개 파라미터만 채우면 됩니다. 공개 키, shortId, 대상 도메인입니다. 현재는 주로 VLESS와 조합하고 XTLS Vision 플로우 제어와 함께 사용합니다.

다섯 가지 방안의 선택 비교

표에서 뚜렷한 진화 흐름을 읽을 수 있습니다. 초기 방안은 능력을 프로토콜 내부에 넣는 쪽이었고, 이후 방안은 능력을 외부에 맡기고 프로토콜 자체를 최대한 얇게 만드는 쪽입니다. 이 흐름은 새 프로토콜이 왜 TLS를 요구하는지도 설명해 줍니다. 보안 경계를 바깥으로 옮긴 것입니다.

"어떤 프로토콜이 빠른가"는 먼저 나눠서 봐야 합니다. 연결 시간은 세 부분으로 구성됩니다. 물리 링크 왕복, 핸드셰이크 왕복 횟수, 암복호화와 캡슐화 처리 시간입니다. 앞의 두 가지는 서버 위치와 링크 품질이 결정하며 프로토콜과 무관합니다. 프로토콜이 영향을 줄 수 있는 것은 세 번째와 핸드셰이크에 몇 번의 왕복이 필요한지뿐입니다. 그래서 같은 서버에서 프로토콜만 바꿔 속도를 재면 차이가 대개 매우 작고, 서버를 바꾸면 차이가 훨씬 클 수 있습니다.

핸드셰이크 경로: 몇 번 왕복하는가

VMess의 핸드셰이크는 요청과 응답의 2단계로, 클라이언트가 신원 정보를 보낸 뒤 서버의 확인을 기다립니다. VLESS는 가벼운 신원 표시 하나만 보내고 추가 확인 왕복을 기다리지 않습니다. Trojan은 표준 TLS 핸드셰이크를 거치고 비밀번호 검증은 핸드셰이크 이후 애플리케이션 계층 데이터에서 이루어집니다. Shadowsocks는 신원 왕복이 없고 공유 비밀번호에서 키를 바로 유도합니다. REALITY의 핸드셰이크 과정은 실제 사이트에 접속하는 것과 같고 클라이언트는 대상 사이트의 인증서 체인을 검증합니다. 왕복 횟수가 적을수록 지연이 큰 링크에서 첫 패킷 시간이 짧아집니다.

캡슐화 계층: 암복호화를 몇 번 하는가

캡슐화 계층 수는 프로세서 오버헤드를 결정합니다. VMess는 자체 암호화가 있어 바깥에 TLS를 한 겹 더 두르면 데이터를 두 번 암복호화해야 합니다. VLESS와 Trojan은 자체 암호화를 하지 않고 TLS 한 계층만 씁니다. REALITY는 XTLS Vision과 함께 쓸 때 프록시 데이터가 직통으로 흘러 중복 암복호화를 줄입니다. 데스크톱 프로세서에서는 이 계층 차이를 체감하기 어렵지만 저전력 안드로이드 기기에서는 배터리 소모와 발열로 나타납니다. 이 부분은 모바일 배터리 사용량 장에서 자세히 다룹니다.

세 가지 오버헤드 비교

차이가 체감되는 시점

세 가지 상황에서 프로토콜 차이가 뚜렷해집니다. 링크 자체의 지연이 클 때 핸드셰이크 왕복 횟수의 영향이 확대됩니다. 기기 연산 능력이 제한적일 때 암복호화 계층 수가 배터리 소모와 속도 저하로 바로 나타납니다. 동시 연결 수가 많을 때 연결마다의 오버헤드가 누적됩니다. 반대로 지연이 낮은 고정 회선과 중급 이상 기기에서는 VMess와 VLESS의 체감 차이가 안정적으로 재현되지 않을 만큼 작습니다.

의미 있는 자체 측정 방법

v2rayNG의 노드 목록에서는 메뉴로 지연 테스트를 실행할 수 있으며 흔히 TCP 테스트와 실제 연결 테스트 두 가지가 있습니다. TCP 테스트는 주소와 포트의 연결 가능 여부만 확인하므로 빠르지만 정보가 적습니다. 실제 연결 테스트는 프록시 연결을 실제로 맺기 때문에 결과가 실제 사용에 더 가깝습니다. 프로토콜을 비교할 때는 다음 순서로 진행하세요.

1. 서버 하나를 고정하고 같은 설정을 프로토콜만 바꿔 아웃바운드로 각각 작성합니다.
2. 실제 연결 테스트로 각각 세 번씩 측정하고 단일 수치가 아니라 변동 범위를 기록합니다.
3. 모든 테스트를 같은 시간대에 끝내 시간대를 넘나드는 비교를 피합니다.
4. 마지막으로 실제 접속 테스트를 한 번 더 해서 측정 결과와 체감이 일치하는지 확인합니다.

세 번의 결과가 서로 겹친다면 현재 링크에서 이 프로토콜들 사이에 구분 가능한 차이가 없다는 뜻이므로 선택 기준을 다른 요소로 옮겨야 합니다. 위장 필요 여부, 인증서 유지 비용, 기기 배터리 소모입니다. 같은 방식으로 노드를 선별하는 전체 절차는 첫 연결 점검에서 확인할 수 있습니다.

구독은 노드 정보가 서비스 제공자에서 클라이언트로 전달되는 주요 통로입니다. 형식을 이해하면 가져오기 실패 시 문제를 빠르게 찾을 수 있고 클라이언트 간에 설정을 옮길 때 필드가 빠지는 일도 피할 수 있습니다.

구독 링크와 공유 링크의 차이

공유 링크는 단일 노드를 설명하며 vless://, vmess:// 같은 형태이고 한 줄만 복사하면 노드 하나를 가져올 수 있습니다. 구독 링크는 노드 묶음을 설명하며 그 자체가 HTTP 또는 HTTPS 주소이고, 클라이언트가 접속하면 텍스트를 받아오는데 그 텍스트의 각 줄이 하나의 공유 링크입니다. 구독의 가치는 갱신에 있습니다. 노드가 추가되거나 삭제될 때 서비스 제공자가 한 곳만 수정하면 클라이언트가 다음 새로 고침에서 동기화되므로 일일이 다시 복사할 필요가 없습니다.

텍스트는 어떻게 인코딩되는가

구독이 반환하는 내용에는 두 가지 흔한 형태가 있습니다. 평문 여러 줄 공유 링크와, 전체 텍스트를 한 번 Base64로 인코딩한 단일 문자열입니다. 클라이언트는 가져올 때 먼저 평문으로 파싱을 시도하고 실패하면 Base64로 디코딩한 뒤 다시 파싱합니다. 그래서 구독 내용을 직접 확인할 때 줄바꿈 없는 긴 문자열이 보이면 먼저 Base64 디코딩을 한 뒤 읽으세요. 디코딩된 각 줄은 프로토콜 이름으로 시작해야 합니다.

네 가지 공유 링크의 필드 형태

보시다시피 VMess와 Shadowsocks는 필드를 Base64 구간에 묶어 넣고 VLESS와 Trojan은 필드를 URL 쿼리 파라미터에 펼쳐 놓습니다. REALITY 노드는 보통 vless:// 형태로 나타나며 공개 키와 shortId 두 파라미터를 추가로 가지는데, 둘 중 하나라도 없으면 핸드셰이크를 완료할 수 없습니다.

가져오기 실패의 흔한 원인

• Base64 구간이 복사 과정에서 잘려 끝부분 몇 글자가 빠지면 디코딩 결과가 불완전해집니다.
• 공유 링크의 서버 주소가 도메인인데 현재 환경에서 도메인 조회가 되지 않으면 가져오기는 성공하지만 연결이 실패합니다.
• REALITY 노드의 공개 키나 shortId가 빠지면 가져온 뒤 노드는 존재하지만 핸드셰이크를 완료할 수 없습니다.
• 구독의 노드가 현재 클라이언트 코어에서 지원하지 않는 기능을 사용하면 가져올 때 건너뜁니다.
• 구독 주소에 추가 요청 헤더나 인증 파라미터가 필요하면 브라우저에서는 열리지만 클라이언트에서는 가져오기에 실패합니다.

가져온 뒤 클라이언트 내부는 어떻게 되는가

가져오기가 끝나면 노드는 코어가 읽을 수 있는 JSON으로 변환됩니다. 아래는 VLESS 아웃바운드의 최소 골격이며 필드 이름은 실제 설정과 같고 주소와 신원은 대체했습니다.

{
  "outbounds": [
    {
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "node.example.com",
            "port": 443,
            "users": [
              {
                "id": "00000000-0000-0000-0000-000000000000",
                "flow": "xtls-rprx-vision"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "serverName": "www.example.com",
          "publicKey": "example-public-key",
          "shortId": "0123456789abcdef"
        }
      }
    }
  ]
}

이 골격과 대조하면 가져오기 과정을 이해할 수 있습니다. 공유 링크의 각 쿼리 파라미터는 결국 settings나 streamSettings의 특정 키에 들어갑니다. 필드가 맞지 않을 때 문제는 대개 클라이언트가 아니라 링크 자체에 있습니다.

여러 클라이언트를 함께 쓸 때의 동기화

같은 구독을 v2rayN과 v2rayNG에서 가져오면 노드 목록이 이론적으로 같아야 합니다. 데스크톱에는 있는데 안드로이드에 없다면 먼저 그 노드의 프로토콜과 전송을 확인하세요. REALITY와 flow가 붙은 VLESS 노드는 기본 프로토콜만 지원하는 코어에서 건너뜁니다. 구독을 갱신할 때 클라이언트는 보통 구독 그룹 단위로 전체를 교체하므로 로컬에서 개별 노드의 이름을 바꾸거나 순서를 조정한 내용은 유지되지 않을 수 있습니다. 중요한 노드는 핵심 필드를 따로 기록해 두는 것이 좋습니다. 여러 기기 사이에서 설정을 옮기는 몇 가지 방법은 여러 기기에서 V2Ray 설정 동기화를 참고하세요.

같은 프로토콜 파라미터라도 전송 방식을 바꾸면 성능이 완전히 달라질 수 있습니다. 전송은 데이터가 어떻게 운반되는지를, 라우팅은 어떤 트래픽이 프록시로 들어가는지를 결정하며 둘은 함께 연결 성공률과 사용 경험에 영향을 줍니다.

흔한 전송 방식

전송을 고르는 실용적 기준은 TCP를 쓸 수 있으면 TCP를 쓰고, 전면 서비스나 특정 포트와 맞물려야 할 때 WebSocket과 gRPC를 고려하는 것입니다. WebSocket은 설정 항목이 가장 많은데 경로와 Host 헤더를 잘못 쓰는 것이 가장 흔한 연결 실패 원인 중 하나입니다. gRPC는 링크 품질이 흔들릴 때 다중화 덕분에 유리하지만 설정에 서비스 이름 파라미터가 하나 더 있어 잘못 채우면 역시 연결되지 않습니다.

선택에서 TLS와 SNI의 위치

TLS는 트래픽 암호화 여부를, SNI는 핸드셰이크 때 상대에게 어느 도메인에 접속하는지 알리는 역할을 합니다. VLESS와 Trojan에서 TLS는 선택 사항이 아니라 전제 조건이고 VMess에서는 추가할 수 있는 한 계층입니다. REALITY는 SNI를 실제 사이트로 향하게 하고 핸드셰이크에서 그 사이트의 인증서 체인을 검증하므로 설정의 serverName이 대상 사이트와 일치해야 하며 잘못 쓰면 핸드셰이크가 실패합니다. 전송을 고를 때는 먼저 구독에 포함된 SNI 필드를 확인하고 추가 설정이 필요한지 판단하세요.

라우팅 모드 세 가지

v2rayNG와 v2rayN의 라우팅 모드는 보통 세 가지를 제공합니다.

• 프록시만: 내장 규칙에 따라 분기해 매칭된 트래픽은 프록시로, 나머지는 직접 연결합니다. 일상에서 가장 많이 씁니다.
• LAN 우회: 사설망 주소는 직접 연결하고 나머지 트래픽은 프록시로 보냅니다. 공유기 관리 페이지나 NAS 같은 로컬 기기에 접속해야 하는 상황에 적합합니다.
• 전역: 모든 트래픽이 프록시로 들어갑니다. 문제를 진단할 때 자주 쓰지만 일상에서 쓰면 불필요한 트래픽 소모가 늘어납니다.

세 가지 모드는 코어 설정의 routing 구간에 있는 서로 다른 규칙 집합에 대응합니다. 모드를 바꿔도 노드 자체는 변하지 않고 어떤 트래픽이 아웃바운드로 나가는지만 달라집니다.

앱별 프록시와 부팅 시 자동 실행

안드로이드의 앱별 프록시는 앱 패키지 이름을 기준으로 프록시 사용 여부를 정하므로 일부 앱만 프록시로 보내는 방식에 적합합니다. 켜면 앱을 하나씩 선택해야 하고 선택하지 않은 앱은 직접 연결로 처리됩니다. 데스크톱에는 이 설정이 없고 대신 프로세스나 주소 대역 기준 규칙을 씁니다. 부팅 시 자동 실행은 항상 켜 두는 기기에 적합하지만 모바일 기기에서 켜면 백그라운드 연결을 계속 점유하므로 사용 빈도에 따라 결정하세요.

domainStrategy와 DNS의 관계

라우팅 규칙의 domainStrategy는 도메인이 언제 IP로 해석되는지를 결정합니다. 흔한 값은 세 가지입니다.

이 항목은 DNS 설정과 맞물려 있습니다. DNS 조회가 프록시를 거치지 않으면 해석 결과로 실제 출구가 드러날 수 있습니다. 관련 현상과 점검 방법은 V2Ray DNS 유출 검사와 차단 설정 글에 정리되어 있습니다. 모든 트래픽을 가상 네트워크 인터페이스로 넘겨야 할 때의 방법은 TUN 모드 원리와 활성화를 참고하세요.

앞선 장들의 결론을 하나의 판단 순서로 모으면 이렇습니다. 먼저 코어 지원을 확인하고 다음으로 링크와 유지보수 비용을 보고 마지막으로 기기 유형에 따라 미세 조정합니다. 아래는 흔한 상황별 권장 조합입니다.

세 단계 판단 순서

1. 코어 보기: 노드에 REALITY나 flow 파라미터가 있는지 확인합니다. 있으면 Xray 코어 클라이언트를 쓰고 없으면 두 코어 모두 커버할 수 있습니다.
2. 링크와 유지보수 비용 보기: 도메인과 인증서를 관리할 의향이 있는지 봅니다. 관리할 의향이 있으면 Trojan과 VLESS+TLS 모두 성숙한 선택이고 없다면 VLESS+REALITY로 인증서 단계를 생략할 수 있습니다.
3. 기기 보기: 저전력 기기는 캡슐화 계층이 적은 방식을 우선하고 데스크톱은 편의성 기준으로 고르면 됩니다.

상황별 비교

권장하지 않는 조합 몇 가지

• VLESS를 TLS 없이 그대로 사용: 프로토콜 자체가 기밀성을 제공하지 않아 데이터가 링크에서 암호화되지 않습니다.
• V2Fly 코어에서 REALITY 노드 사용: 코어가 이 방식을 지원하지 않아 설정이 적용되지 않습니다.
• Shadowsocks를 모든 상황의 유일한 방안으로 사용: 프로토콜 계층 위장이 없고 설정 항목이 적어 경로를 직접 지정해야 하는 링크에서는 대안이 없습니다.
• 모바일 기기에서 전역 모드를 장기간 켜 두기: 모든 트래픽이 프록시로 들어가 연결 수와 웨이크업 횟수가 모두 늘어납니다.

실행 가능한 적용 절차

1. 클라이언트에서 구독을 가져오고 노드 수가 예상과 일치하는지 확인합니다.
2. 프로토콜별로 묶고 캡슐화 계층이 적은 노드를 우선 테스트합니다.
3. 실제 연결 테스트로 연결되지 않는 노드를 걸러냅니다. 절차는 첫 연결 점검을 참고하세요.
4. 두세 개 노드를 상용으로 정하고 나머지는 예비로 남겨 둡니다.
5. 기기 유형에 맞춰 라우팅 모드와 앱별 프록시를 조정합니다.

프로토콜 간 횡적 비교는 VMess, VLESS, Trojan, SS 비교도 참고하세요. 그 글은 핸드셰이크 오버헤드, 지연, 상황별 선택 세 각도에서 다루며 이 페이지의 비교표와 서로 보완합니다. 클라이언트 선택과 시스템 요구 사항은 다운로드 센터에, 세 클라이언트의 차이는 선택 가이드에 모여 있습니다.

이 장은 앞 내용을 색인 형태로 마무리합니다. 자주 쓰는 필드의 의미, 대표적인 현상에 대응하는 점검 항목, 그리고 사이트 내 관련 페이지 입구입니다.

자주 쓰는 필드 빠른 조회

현상과 점검 항목

관련 페이지

• 빠른 시작: 구독 가져오기, 모드 선택, 연결, 확인까지의 전체 흐름.
• 다운로드 센터: 세 클라이언트의 플랫폼별 입구와 시스템 요구 사항.
• 선택 가이드: v2rayN, v2rayNG, v2flyNG 세 클라이언트의 횡적 비교.
• 자주 묻는 질문: 기초 개념, 설치와 설정, 사용 팁, 문제 해결로 분류해 정리.
• 첫 연결 점검: 노드 선별, 실제 연결 속도 측정, 프록시 적용 확인.
• DNS 유출 검사: 현상, 검사 입구, 설정 항목.
• 여러 기기 설정 동기화: 세 가지 이전 방식의 장단점.
• 네 가지 프로토콜 비교: 핸드셰이크 오버헤드, 지연, 상황별 선택.
• TUN 모드: 원리와 활성화 순서.

마지막 설명

이 페이지의 결론은 모두 프로토콜과 코어의 공개된 설계를 바탕으로 하며 구체적인 서버 배포 파라미터는 다루지 않습니다. 프로토콜 선택에 유일한 정답은 없습니다. 같은 구독도 링크에 따라 성능이 다를 수 있고 같은 서버도 기기에 따라 전력 소모가 다릅니다. 이 페이지를 판단 근거로 삼고 실제 테스트를 최종 결론으로 삼아야 두 가지를 결합해 자신에게 맞는 조합을 고를 수 있습니다. 이 페이지에서 다루지 않은 문제가 있다면 자주 묻는 질문에서 분류별로 찾아보거나 빠른 시작으로 돌아가 전체 흐름을 다시 따라가 보세요.