V2Ray 프로토콜 및 커널 선택 참고

클라이언트의 노드 하나는 보통 단일 프로토콜이 아니라 여러 계층의 매개변수가 조합된 형태입니다. 흔한 VLESS 노드를 예로 들면 하위 연결은 TCP를 사용하고, 외부 보안 기능은 TLS 또는 REALITY일 수 있으며, 데이터는 WebSocket, gRPC, HTTP Upgrade 또는 XHTTP를 통해 전달될 수 있습니다. 읽기 편하도록 노드 목록에는 지역, 프로토콜 약어와 회선 정보만 표시하고 전체 매개변수는 구독 내용에 넣는 경우가 많습니다. 따라서 노드를 비교할 때 VLESS와 VLESS + TCP + REALITY를 같은 수준의 항목으로 취급해서는 안 되며, 두 노드의 이름에 VMess가 적혀 있다고 연결 특성이 완전히 같다고 단정해서도 안 됩니다.

올바른 분해 순서는 먼저 클라이언트가 사용하는 커널을 확인한 뒤 애플리케이션 계층 프로토콜, 전송 방식, 보안 계층을 차례로 보고 마지막으로 주소, 포트, 사용자 식별자, 서비스 이름 등 연결 매개변수를 점검하는 것입니다. 커널은 클라이언트가 특정 기능을 인식할 수 있는지 결정하고, 프로토콜은 인증과 데이터 캡슐화 방식을 정하며, 전송 계층은 데이터 운반 방식을 결정합니다. 보안 계층은 암호화 핸드셰이크와 서버 식별 처리를 담당하고, 구체적인 매개변수는 해당 서비스에 연결할 수 있는지를 좌우합니다. 어느 한 계층이라도 맞지 않으면 시간 초과, 핸드셰이크 실패, 설정 시작 불가 또는 구독 가져오기 후 필드 유실로 나타날 수 있습니다.

다섯 가지 용어는 같은 계층에 속하지 않습니다

VMess, VLESS, Trojan, Shadowsocks는 보통 노드의 주요 프로토콜 유형으로 표시됩니다. REALITY는 Xray가 제공하는 전송 보안 기능에 더 가깝고, 실제 설정에서는 VLESS, TCP 및 flow 설정과 함께 조합되는 경우가 많습니다. REALITY를 VLESS와 같은 수준의 프로토콜로 단순히 이해하면 선택 과정에서 중요한 조건을 놓칠 수 있습니다. 예를 들어 클라이언트가 VLESS를 인식한다고 해서 현재 커널이 구독에 포함된 REALITY 매개변수까지 지원한다는 뜻은 아닙니다. 반대로 노드 이름에 REALITY가 보여도 기본 프로토콜, 전송 방식, 서버 이름 등의 필드를 계속 확인해야 합니다.

호환되지 않는 조합을 먼저 제외한 뒤 성능을 비교하세요

선택의 첫 번째 원칙은 사용 가능성입니다. 구독이 Xray 확장 기능에 명확히 의존하는데 클라이언트가 실제로 V2Fly 커널을 실행한다면 지연 시간과 처리량을 비교해도 의미가 없습니다. 먼저 커널이 설정을 완전히 읽을 수 있는지 확인한 뒤 실제 연결 테스트로 회선 품질을 판단하세요. 지연 시간은 로컬에서 서버까지 한 번 테스트하는 데 걸린 시간일 뿐 다운로드 속도와 같지 않습니다. 같은 프로토콜도 네트워크 경로, 서버 부하, 전송 조합에 따라 결과가 크게 달라질 수 있습니다. 프로토콜 이름은 기술적 특성을 판단하는 데 도움을 주지만 실제 회선 테스트를 대신할 수는 없습니다.

두 번째 원칙은 불필요한 계층을 줄이는 것입니다. 두 노드의 회선 품질이 비슷하다면 일반적으로 클라이언트가 기본 지원하고 매개변수가 적으며 별도 변환이 필요 없는 조합을 우선하세요. 전송 캡슐화 계층이 하나 늘어날 때마다 헤더, 상태 관리, 문제 해결 지점이 증가하지만 오버헤드가 크게 느껴지는지는 패킷 크기, 연결 수, 기기 성능에 따라 달라집니다. 계층 수가 적다고 반드시 더 빠른 것은 아니며, 설정 필드가 많다고 기능이 더 뛰어난 것도 아닙니다. 목표는 현재 커널, 기기, 서버 설정에 맞는 가장 짧은 경로를 찾는 것입니다.

세 번째 원칙은 되돌릴 수 있는 대안을 남겨 두는 것입니다. 구독에 VLESS, Trojan, VMess 또는 Shadowsocks 노드가 함께 있다면 현재 커널 능력에 가장 잘 맞는 유형을 먼저 선택하고, 비교용으로 구조가 단순한 노드도 남겨 두세요. 연결 문제가 발생했을 때 같은 지역, 같은 회선의 다른 프로토콜 노드로 교차 테스트하면 회선 문제, 프로토콜 매개변수 문제, 클라이언트 커널 문제를 구분할 수 있습니다. 가져오기, 업데이트, 노드 전환 방법을 다시 확인하려면 v2rayN 설정 튜토리얼로 돌아가고, 설치 패키지를 다시 선택하려면 다운로드 센터에서 운영체제별 항목을 선택하세요.

프로토콜의 차이는 우선 설계 목표에서 비롯됩니다. VMess는 Project V 초기에 형성된 핵심 프로토콜 중 하나로, 사용자 인증, 시간 검증, 데이터 암호화와 전송 연계를 하나의 구조에 통합했습니다. 생태계가 성숙했고 기존 구독에서 널리 사용되며 V2Fly와 Xray 모두 기본 지원이 비교적 충실하다는 점이 장점입니다. 반면 프로토콜 내부에서 담당하는 작업이 많으므로 설정할 때 사용자 식별자, 암호화 방식, 시간 정확성, 서버와 클라이언트 매개변수의 일치 여부를 확인해야 합니다. 이미 안정적으로 작동하는 VMess 노드는 새 프로토콜 이름이 등장했다는 이유만으로 즉시 바꿀 필요가 없습니다. 새 설정을 만들 때는 서버 기능과 클라이언트 커널을 함께 고려해 결정하세요.

VMess: 완성도 높은 구조와 기존 호환성

VMess는 사용자 식별자로 인증하며 시간과 관련된 검증 로직을 포함합니다. 클라이언트 기기의 시스템 시간이 크게 어긋나면 연결에 실패할 수 있으므로 VMess 문제를 해결할 때 시간 동기화를 기본 점검 항목으로 삼아야 합니다. VMess는 여러 암호화 및 호환 설정 표현을 거쳐 왔고, 구독 파서는 일반적인 필드를 클라이언트 내부 형식으로 변환하는 경우가 많습니다. 기존 서버, 기존 구독 또는 여러 Project V 커널과의 호환이 필요한 환경에 적합합니다. 단점은 단순히 느리다는 것이 아니라 VLESS보다 프로토콜 내부 처리 과정이 더 완전해 이론적으로 계산과 캡슐화 작업을 더 부담한다는 점입니다. 실제 차이는 대부분의 최신 데스크톱 기기에서 회선 차이로 인한 영향보다 작은 경우가 많습니다.

VLESS: 암호화 책임을 보안 계층에 위임

VLESS는 더 가벼운 구조로 설계되어 기본 프로토콜은 주로 신원 확인과 데이터 전달을 담당하며 프로토콜 내부에 별도의 콘텐츠 암호화 체계를 중복으로 만들지 않습니다. 실제 배포에서는 TLS 또는 REALITY 같은 보안 기능과 함께 사용하는 경우가 많습니다. 이 방식은 역할이 명확하다는 장점이 있습니다. VLESS는 연결 신원을 관리하고 보안 계층은 핸드셰이크와 암호화를 처리하며 전송 계층은 데이터 운반 방식을 결정합니다. 그만큼 조합이 완전한지에 따라 설정 성공 여부가 달라집니다. 주소, 포트, 사용자 식별자만 입력해도 충분하지 않을 수 있으며 서버 이름, flow, 전송 유형, 경로, 공개 키 또는 짧은 ID가 빠지면 노드가 연결되지 않을 수 있습니다.

VLESS는 Xray 생태계의 중요한 프로토콜로 자주 인식되지만, 기본 VLESS 기능을 제공하는 클라이언트가 하나뿐인 것은 아닙니다. 실제로 확인해야 할 것은 확장 항목입니다. 노드에 REALITY, Vision flow 또는 최신 전송 필드가 포함되어 있다면 해당 기능을 명확히 지원하는 Xray 커널을 우선 사용하세요. 일반적인 VLESS와 TLS 조합이라면 호환 범위가 더 넓은 편입니다. 선택할 때 VLESS라는 네 글자만 보지 말고 노드 상세 정보를 열어 flow, security, network, serverName 값을 확인하세요.

Trojan: TLS 연결을 핵심 구조로 사용

Trojan은 TLS에 기반한 연결 구조를 사용하며 비밀번호로 인증합니다. 설정이 직관적이고 일반적인 필드는 서버 주소, 포트, 비밀번호, 서버 이름, 인증서 관련 옵션입니다. TLS가 조합에 필수이므로 서버 이름 오입력, 기기 시간 오류, 서버 인증서 설정 변경은 핸드셰이크에 직접 영향을 줍니다. 클라이언트에 ‘안전하지 않은 연결 허용’과 같은 옵션이 있어도 일반적인 해결책으로 사용해서는 안 됩니다. 먼저 서버 이름과 서버가 제공한 매개변수를 확인하고 인증 흐름을 서버 설정과 일치시키는 것이 올바른 방법입니다.

Trojan의 실행 비용은 복잡한 프로토콜 내부 암호화보다 표준 TLS 처리와 네트워크 경로에서 주로 발생합니다. 서버가 Trojan 방식으로 연결을 제공하고 구독 필드가 완전하며 클라이언트 커널 지원이 안정적인 환경에 적합합니다. VLESS + TLS와 비교하면 두 조합 모두 TLS를 사용할 수 있지만 인증 구조와 필드 의미가 다르므로 드롭다운에서 프로토콜 이름만 바꿔 서로 변환할 수 없습니다. 마이그레이션하려면 서버가 해당 진입점을 함께 제공해야 하며 클라이언트에도 전체 매개변수를 다시 가져와야 합니다.

Shadowsocks: 단순한 구조, 필수적인 암호화 방식 일치

Shadowsocks는 흔히 SS라고 줄여 부르며 간결한 암호화 프록시 구조를 중시합니다. 핵심 설정은 보통 서버, 포트, 비밀번호, 암호화 방식입니다. 필드가 가장 적어 보이지만 암호화 방식은 반드시 일치해야 하는 항목이므로 클라이언트와 서버의 값이 다르면 연결할 수 없습니다. 최신 구현에서는 지원하는 암호화 방식의 범위가 다를 수도 있습니다. 따라서 구형 클라이언트가 SS 링크를 인식한다고 해서 링크에 지정된 방식까지 실행할 수 있다는 뜻은 아닙니다. 가져오기는 성공했지만 시작되지 않는다면 커널 로그에 지원하지 않는 cipher 또는 method가 표시되는지 확인한 뒤 클라이언트 업데이트, 커널 전환, 다른 노드 선택을 결정하세요.

이 네 가지 프로토콜에는 환경과 무관한 고정 순위가 없습니다. 기존 VMess 서버가 안정적으로 작동한다면 호환성 자체가 가치입니다. 구독에 완전한 VLESS + REALITY 매개변수가 있고 클라이언트가 Xray를 사용한다면 해당 조합을 우선 테스트할 수 있습니다. Trojan은 서버가 그 구조에 맞춰 연결을 제공할 때 적합하고 Shadowsocks는 필드가 명확하며 구현 범위가 넓은 간결한 선택지입니다. 최종 기준은 서버가 무엇을 제공하는지, 현재 커널이 완전하게 구현할 수 있는지, 회선이 안정적인지, 기기가 연결 및 배터리 비용을 감당할 수 있는지입니다.

기본 프로토콜을 정한 다음 계층은 전송 및 보안 설정입니다. 많은 연결 문제는 프로토콜 자체보다 경로, 서비스 이름, 서버 이름, 지문 또는 flow 필드가 올바르게 가져와지지 않아 발생합니다. 클라이언트의 ‘전송 프로토콜’은 보통 TCP, WebSocket, gRPC, HTTP Upgrade, XHTTP 등의 전달 방식을 뜻하고, ‘전송 계층 보안’에는 TLS 또는 REALITY가 자주 사용됩니다. 두 그룹의 필드는 조합할 수 있지만 아무렇게나 함께 사용할 수 있는 것은 아니며 서버가 연 포트와 항목별로 일치해야 합니다.

TCP와 추가 전송 캡슐화

TCP 직접 연결 구조는 이해하기 가장 쉽습니다. 기본 프로토콜 데이터가 TCP 연결 위에 바로 올라가고 추가 필드도 보통 적습니다. 필드가 적으면 문제 해결 경로가 짧지만 실제 성능은 네트워크 품질, 혼잡 제어, 서버 설정에 따라 달라집니다. WebSocket은 연결에 HTTP 업그레이드 과정을 추가하고 경로 같은 매개변수를 사용하므로 문자 하나만 달라도 실패할 수 있습니다. gRPC는 보통 서비스 이름이 필요하고 장시간 연결과 다중화 특성을 사용할 수 있으므로 클라이언트와 서버의 서비스 이름, 모드, TLS 설정이 일치해야 합니다. HTTP Upgrade도 업그레이드 요청 관련 매개변수에 의존합니다. XHTTP는 비교적 새로운 전송 기능이므로 사용 전에 현재 Xray 커널과 구독 파서가 해당 필드를 모두 인식하는지 확인하세요.

‘추가 캡슐화가 많다’는 이유만으로 특정 전송 방식이 반드시 느리다고 판단하지 마세요. 짧은 연결, 작은 패킷, 빈번한 요청에서는 핸드셰이크 횟수와 연결 재사용 방식의 차이가 커질 수 있습니다. 지속적인 대용량 전송에서는 회선 대역폭, 패킷 손실, 혼잡이 더 중요합니다. 클라이언트의 다중화도 높을수록 좋은 것은 아닙니다. 적은 수의 하위 연결에 여러 논리 연결을 담을 수 있지만 불안정한 네트워크에서 하위 연결 하나가 막히면 여러 요청이 동시에 영향을 받을 수 있습니다. 기본값으로 정상 작동한다면 먼저 그대로 두고 로그와 실제 애플리케이션 동작을 바탕으로 조정하세요.

TLS에 필요한 정보

TLS 조합에는 보통 최소한 서버 이름이 필요합니다. 연결 주소는 도메인일 수도 네트워크 주소일 수도 있지만 핸드셰이크에 사용하는 서버 이름은 서버가 제공한 값으로 입력해야 합니다. 클라이언트의 지문 옵션은 핸드셰이크 특성을 설명하므로 구독에 지정된 값이나 클라이언트의 호환 기본값을 따라야 하며, 서버 설정을 모르는 상태에서 임의로 바꾸지 마세요. ALPN과 allowInsecure 같은 옵션도 명확한 의미가 있습니다. ALPN은 애플리케이션 프로토콜 협상에 참여하고, 인증 검사를 건너뛰는 옵션은 신원 확인 과정을 변경하므로 일반적인 네트워크 장애의 장기 해결책으로 적합하지 않습니다.

REALITY는 보안 조합이지 단독 교체 항목이 아닙니다

REALITY는 보통 Xray 커널에서 구현되며 VLESS, TCP, Vision 등의 기능과 함께 사용됩니다. 일반적인 클라이언트 필드는 서버 이름, 공개 키, 짧은 ID, 지문, flow입니다. 공개 키는 서버 설정에서 오고 짧은 ID는 서버가 허용한 값으로 정해지며 서버 이름도 서버 설정을 충족해야 합니다. 어느 한 필드라도 비어 있거나 구독 변환 과정에서 잘리거나 복사 중 불필요한 문자가 섞이면 핸드셰이크가 실패할 수 있습니다. REALITY 노드가 연결되지 않으면 먼저 상세 정보를 열어 값을 대조하고 커널 로그를 확인해야 하며 TCP, WebSocket, TLS 사이를 무작정 바꿔서는 안 됩니다.

공유 링크에서 조합 필드 확인하기

일반적인 공유 링크는 URI 앞부분에 프로토콜을 넣고 호스트 부분에 기본 매개변수를, 쿼리 매개변수에 전송 및 보안 필드를 넣습니다. 구독 도구마다 필드 이름, 대소문자, 인코딩 처리 방식이 다를 수 있습니다. 가져온 뒤에는 노드가 목록에 표시되는지만 보지 말고 클라이언트의 노드 편집 화면에서 확인하세요. 아래 예시는 연결 가능한 정보 없이 구조만 보여 주며 필드 간 관계를 설명하기 위한 값입니다:

vless://[email protected]:443?type=tcp&security=reality&flow=xtls-rprx-vision&sni=example.invalid&fp=chrome&pbk=PUBLIC_KEY&sid=SHORT_ID#VLESS-REALITY

이 구조에서 vless는 기본 프로토콜, type=tcp는 전송 방식, security=reality는 보안 계층, flow는 flow입니다. sni, fp, pbk, sid는 각각 서버 이름, 지문, 공개 키, 짧은 ID를 뜻합니다. 주소, 포트, 사용자 식별자만 남기면 완전해 보이지만 실제로는 핸드셰이크를 완료할 수 없는 노드가 됩니다. 구독 변환 후 이 필드가 사라졌다면 원본 구독으로 돌아가 다시 가져오거나 해당 필드를 보존하는 형식을 사용하세요.

조합이 올바른지 세 단계로 확인할 수 있습니다. 첫째, 커널이 설정을 로드할 수 있는지 봅니다. 시작 단계에서 알 수 없는 필드 오류가 발생하면 대개 커널 또는 형식 호환성 문제입니다. 둘째, 네트워크 연결이 수립되는지 확인합니다. 즉시 시간 초과가 발생하면 주소, 포트, 로컬 네트워크를 점검하세요. 셋째, 핸드셰이크 단계의 로그를 확인합니다. 서버 이름, 공개 키, 인증, 서비스 이름 관련 오류가 보이면 보안 계층과 전송 필드를 하나씩 대조하세요. 계층별로 확인하면 노드 이름을 계속 바꾸는 것보다 빠르게 문제를 해결하고 클라이언트 업데이트, 커널 전환, 구독 재발급 중 다음 조치를 명확히 정할 수 있습니다.

프로토콜 성능은 연결 수립 시간, 지속 처리량, CPU 사용량, 메모리 사용량, 연결 안정성, 기기 깨우기 빈도로 나누어 봐야 합니다. 클라이언트에 표시되는 지연 시간은 보통 한 번의 테스트만 반영하므로 대용량 파일 다운로드 속도나 배터리 소모를 대표하지 않습니다. 같은 VLESS 노드도 데스크톱 유선 네트워크와 모바일 네트워크에서 결과가 완전히 다를 수 있습니다. 같은 프로토콜도 전송 방식, 회선, 서버 부하에 따라 프로토콜 자체의 차이보다 큰 변동을 보일 수 있습니다.

연결 수립 시간은 어떤 단계로 구성되는가

새 연결 하나는 도메인 조회, TCP 연결, 보안 핸드셰이크, 프로토콜 인증, 상위 요청을 거칠 수 있습니다. TLS 또는 REALITY를 사용하면 해당 핸드셰이크 단계가 추가되지만 연결 재사용, 세션 복구, 안정적인 장기 연결로 반복 비용을 줄일 수 있습니다. WebSocket과 gRPC 같은 전송 방식에도 각자의 연결 수립 과정이 있습니다. 짧은 시간에 작은 요청을 많이 열면 연결 수립 비용이 더 크게 느껴지고, 지속 전송에서는 네트워크 경로, 혼잡, 패킷 손실 복구가 더 중요합니다. 따라서 테스트할 때는 최초 실행 속도, 반복 접속 속도, 지속 전송 성능을 구분해야 합니다.

VMess는 내부 처리가 비교적 완전하므로 이론상 가벼운 VLESS보다 계산 경로가 길 수 있습니다. VLESS는 보안 책임을 외부 계층에 맡겨 기본 프로토콜이 더 간결하고, Trojan의 주요 비용은 TLS와 데이터 전달에 집중됩니다. Shadowsocks의 비용은 선택한 암호화 방식과 구현에 따라 달라집니다. 이러한 차이는 저성능 기기, 많은 동시 연결, 작은 패킷이 집중되는 환경에서 더 잘 드러나지만 최신 데스크톱 CPU와 일반적인 웹 이용에서는 여전히 회선 품질이 주요 요인입니다. 한 번의 테스트에서 발생한 몇 ms 차이로 프로토콜의 영구적인 순위를 정하는 것은 신뢰하기 어렵습니다.

메모리와 CPU 사용량은 연결 모델에 따라 달라집니다

메모리 사용량은 프로토콜만으로 결정되지 않습니다. 클라이언트 GUI, 커널 프로세스, 규칙 집합, DNS 캐시, 라우팅 데이터, 연결 상태가 모두 메모리를 사용합니다. 데스크톱 클라이언트인 v2rayN은 보통 UI 프로세스와 커널 프로세스가 역할을 나누며, Android의 v2rayNG와 v2flyNG는 시스템 네트워크 서비스와 함께 작동합니다. TUN을 활성화하거나 큰 라우팅 데이터를 불러오거나 많은 연결을 동시에 유지하면 프로토콜을 바꾸는 것보다 사용량 변화가 클 수 있습니다. 문제를 확인할 때는 라우팅과 DNS 설정을 먼저 동일하게 유지한 뒤 같은 회선의 다른 프로토콜 노드와 비교하세요.

CPU 사용량은 암호화, 핸드셰이크, 데이터 복사, 압축, 로그 수준, 연결 수와 관련이 있습니다. 로그를 지나치게 상세하게 설정하면 지속적인 기록 자체가 리소스를 더 사용할 수 있습니다. 속도 측정 중 CPU 사용량이 잠시 상승하는 것은 정상입니다. 진짜로 확인할 부분은 유휴 상태에서도 높은 사용량이 지속되는지, 앱이 접근을 멈춘 뒤에도 연결이 자주 활동하는지, 커널 로그가 반복 재시도를 기록하는지입니다. 지속적인 재시도가 발생한다면 배터리와 CPU 소모는 프로토콜 효율 문제가 아니라 잘못된 설정이나 네트워크 연결 불가로 인한 연결 폭주일 가능성이 큽니다.

모바일 배터리는 깨우기와 재연결이 좌우합니다

모바일 배터리 성능을 ‘어떤 프로토콜이 더 절전적인가’로 단순화하면 안 됩니다. 실제 영향이 큰 요소는 네트워크 전환 빈도, 백그라운드 연결 유지, 연결 안정성, DNS 요청 수, TUN 적용 범위, 라우팅 규칙 복잡도, 실패 재시도입니다. 안정적인 장기 연결은 계속 시간 초과 후 재연결하는 상태보다 리소스를 적게 사용하는 경우가 많습니다. 무선 네트워크에서 모바일 네트워크로 전환하면 기존 연결을 다시 수립해야 할 수 있습니다. 노드 핸드셰이크가 실패해 빠르게 재시도되면 시스템이 계속 깨어 있어 배터리가 훨씬 빨리 줄어듭니다.

v2rayNG 또는 v2flyNG에서 배터리 소모를 줄이려면 안정적인 노드를 먼저 선택하고 불필요한 전체 트래픽 처리와 잦은 속도 측정을 줄이세요. 일부 앱만 연결을 사용한다면 클라이언트가 제공하는 앱별 설정이나 라우팅 기능으로 처리 범위를 줄일 수 있습니다. 모든 트래픽을 TUN으로 보내야 한다면 DNS와 라우팅을 확인해 순환 전달을 피하세요. 노드 수준에서는 최저 지연보다 핸드셰이크가 안정적이고 패킷 손실이 적은 조합을 우선하세요. 특별한 기능 요구가 없다면 이론적인 캡슐화 비용의 작은 차이보다 안정성이 중요합니다.

최종적으로는 세 단계로 판단할 수 있습니다. 먼저 지연 시간 테스트로 명백히 연결할 수 없는 노드를 제외하고, 실제 앱으로 최초 연결과 지속 전송을 확인한 다음, 유휴 상태의 재연결과 리소스 사용량을 관찰하세요. 데스크톱에서는 v2rayN 로그에서 연결 실패 빈도를 확인하고, 모바일에서는 네트워크 전환 후 복구되는지와 시간 초과가 계속 발생하는지를 중점적으로 보세요. 사이트의 노드 선택 글에서는 지연 시간, 배율, 지역, 프로토콜 네 가지 기준을 더 자세히 설명하므로 이 장과 함께 참고하면 좋습니다.

V2Fly와 Xray는 모두 Project V 관련 기술 생태계에서 출발했으며 여러 기본 프로토콜과 라우팅 개념을 처리할 수 있습니다. 그러나 이름만 바꿔 쓸 수 있는 동일한 프로그램은 아닙니다. 각자 기능, 설정 필드, 확장 기능을 유지·발전시키고 있습니다. VMess, 일반 VLESS, Trojan, Shadowsocks, 라우팅 규칙, DNS 같은 기본 기능은 설정 개념이 상당 부분 공통되지만 REALITY, Vision, 특정 전송 방식 또는 최신 확장 필드는 해당 커널의 실제 구현을 기준으로 판단해야 합니다.

공통 기반과 설정 유사성

두 커널 모두 인바운드, 아웃바운드, 라우팅, DNS를 중심으로 하는 설정 모델을 사용합니다. 인바운드는 로컬 앱이 트래픽을 커널에 전달하는 방식을, 아웃바운드는 커널이 대상 또는 원격 서비스에 연결하는 방식을 설명합니다. 라우팅 규칙은 트래픽을 어느 아웃바운드로 보낼지 정하고 DNS는 조회 정책을 담당합니다. 클라이언트는 보통 GUI의 노드와 설정을 바탕으로 전체 설정을 생성하므로 일반 사용자가 모든 내용을 직접 작성할 필요는 없습니다. 이러한 공통 개념을 이해하면 클라이언트나 커널을 바꿀 때 문제가 노드 프로토콜, 라우팅, DNS, GUI 설정 생성 중 어디에서 발생했는지 판단할 수 있습니다.

기본 필드 이름이 같다고 해서 모든 값을 그대로 복사할 수 있는 것은 아닙니다. 어떤 필드는 한 커널에서는 확장 기능이지만 다른 커널에서는 인식하지 못하거나 무시하거나 다른 구조로 처리할 수 있습니다. 대표적인 사례는 구독 노드에 Xray 고유 기능이 포함되어 있는데 변환 도구가 일반 V2Ray 필드만 출력하는 경우입니다. 노드는 가져와지지만 flow, REALITY 공개 키, 최신 전송 매개변수가 사라질 수 있습니다. 겉으로는 노드 이름과 주소가 남아 있어도 실제 핸드셰이크에 필요한 필드는 불완전한 상태입니다.

Xray의 기능 방향

Xray는 VLESS 확장, REALITY, Vision 및 여러 전송 기능을 중심으로 뚜렷한 기능 방향을 발전시켜 왔습니다. 구독에 이러한 키워드가 있다면 중간 변환을 줄일 수 있도록 Xray 커널을 우선 사용하세요. v2rayN과 v2rayNG는 이런 노드를 운용하는 데 자주 사용됩니다. v2rayN은 Windows, macOS, Linux 데스크톱 환경을 대상으로 하고 v2rayNG는 Android를 대상으로 합니다. 클라이언트 이름이 곧 커널 이름은 아니므로 실제 실행 중인 커널은 설정, 로그, 정보 화면에서 확인해야 합니다.

Xray를 사용한다고 해서 모든 노드를 VLESS로 바꿔야 하는 것은 아닙니다. Xray도 여러 프로토콜을 처리할 수 있으므로 호환과 비교를 위해 VMess, Trojan, Shadowsocks 노드를 유지하는 것은 합리적입니다. 커널 선택은 기능 집합을 고르는 일이고 프로토콜 선택은 구체적인 연결 진입점을 고르는 일입니다. 둘은 관련 있지만 동일하지 않습니다. 서버가 VMess만 제공한다면 클라이언트가 Xray를 실행하더라도 VMess 매개변수로 연결해야 하며 로컬에서 VLESS로 바꿀 수는 없습니다.

V2Fly의 기능 방향

V2Fly는 Project V의 개방형 설정 체계를 이어받아 VMess, VLESS 기본 기능, Trojan, Shadowsocks, 라우팅, DNS 등을 독립적으로 발전시키고 있습니다. v2flyNG는 Android에서 V2Fly 커널을 사용하는 대안 클라이언트이며, 구독이 주로 일반 프로토콜로 구성되고 V2Fly 구현을 명확히 사용하려는 경우에 적합합니다. 구독에 Xray 측에서만 구현된 매개변수가 명시적으로 포함되어 있다면 v2flyNG가 이를 완전하게 로드하지 못할 수 있습니다. 이때는 v2rayNG를 선택하거나 구독에서 서버가 제공하는 호환 노드를 사용하세요.

커널을 바꾸기 전에 저장할 항목

커널을 바꾸기 전에는 현재 클라이언트, 노드 이름, 기본 프로토콜, 전송 방식, 보안 유형, 라우팅 모드, DNS 설정을 기록하세요. 클라이언트가 설정 내보내기를 지원한다면 비교용 사본을 저장하고, 전환 직후 원본 구독을 덮어쓰지 마세요. 먼저 소수의 노드만 가져와 기본 연결을 확인한 다음 라우팅과 TUN 같은 고급 설정을 복원하세요. 이렇게 하면 커널 호환 문제와 고급 설정 문제를 분리할 수 있습니다. 전환 후 모든 노드가 시작되지 않으면 설정 로드 로그를 먼저 보고, REALITY 노드만 실패하면 확장 필드를 중점적으로 확인하며, 연결은 되지만 일부 도메인에 문제가 있으면 DNS와 라우팅을 점검하세요.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.invalid"],
        "outboundTag": "direct"
      }
    ]
  }
}

위 조각은 두 커널에서 모두 이해하기 쉬운 라우팅 구조를 보여 줍니다. 도메인이 지정된 규칙과 일치하면 direct라는 이름의 아웃바운드로 전달합니다. 이는 완전한 설정이 아니며 클라이언트가 인바운드, 원격 아웃바운드, DNS 등의 부분도 생성해야 합니다. 수동으로 편집할 때는 outboundTag가 실제 존재하는 아웃바운드 태그와 일치해야 합니다. GUI 클라이언트는 보통 이러한 연결을 자동으로 처리합니다. 프로토콜을 선택하고 구독을 가져오는 것뿐이라면 이 조각을 클라이언트에 직접 붙여 넣을 필요가 없습니다.

커널 업데이트의 주요 목적은 프로토콜 수정, 호환성, 실행 개선을 얻는 것입니다. ‘최신’이라고 해서 모든 기존 설정을 다시 만들어야 한다는 뜻은 아닙니다. 클라이언트를 업데이트한 뒤 기존 설정을 유지한 채 먼저 테스트하세요. 로그에서 기존 필드가 더 이상 적용되지 않거나 서버가 진입점을 변경했다고 명확히 표시할 때만 노드를 수정하면 됩니다. 설치 패키지와 클라이언트의 대응 관계는 다운로드 센터를 기준으로 하며, 페이지에서 네 플랫폼별 v2rayN, v2rayNG, v2flyNG 공식 진입점을 확인할 수 있습니다.

구독은 여러 노드의 매개변수를 클라이언트에 전달하는 역할을 합니다. 여러 공유 링크를 포함할 수도 있고 구조화된 설정이나 서버가 생성한 전용 형식을 사용할 수도 있습니다. 클라이언트가 구독을 가져오면 먼저 텍스트를 다운로드하고 각 기록을 파싱한 뒤 내부 노드 모델로 변환합니다. 호환성 문제는 어느 단계에서든 발생할 수 있습니다. 주소에 접근할 수 없거나 텍스트 인코딩이 잘못되거나 공유 링크 필드가 누락되거나 파서가 새 매개변수를 인식하지 못하거나 클라이언트 내부 모델에 해당 필드가 없을 수 있습니다. 따라서 ‘구독 업데이트 성공’은 요청 과정이 완료되었다는 뜻일 뿐 모든 노드가 완전하게 파싱되었다는 의미는 아닙니다.

공유 링크는 단일 노드 전달에 적합합니다

VMess, VLESS, Trojan, Shadowsocks에는 모두 널리 쓰이는 공유 링크 형식이 있습니다. 링크는 보통 기본 인증 정보, 서버, 포트, 전송, 보안 매개변수를 한 줄의 텍스트로 인코딩합니다. 복사와 가져오기가 편리하지만 프로토콜 확장에 따라 필드 이름이 늘어나고 파서마다 새 필드 지원 속도가 다를 수 있다는 단점이 있습니다. 특히 VLESS + REALITY 조합에서는 공개 키, 짧은 ID, 지문, 서버 이름, flow를 모두 보존해야 합니다. 구독 변환 서비스가 초기 VLESS 필드만 인식한다면 가져온 결과는 보안 매개변수가 없는 일반 노드로 변질될 수 있습니다.

VMess 공유 내용은 인코딩된 JSON 형식을 자주 사용하며 주소, 포트, 사용자 식별자, 네트워크 유형, 호스트, 경로, TLS 등의 정보를 포함할 수 있습니다. 생성기마다 필드 약어와 기본값 처리 방식이 완전히 같지는 않습니다. Trojan과 Shadowsocks 링크 구조는 비교적 단순하지만 비밀번호, 암호화 방식, 서버 이름 등은 여전히 올바르게 인코딩해야 합니다. 링크에 특수 문자가 있으면 URI 인코딩이 필요합니다. 수동으로 복사할 때 끝부분의 쿼리 매개변수를 빠뜨리거나 줄바꿈을 필드에 포함하면 파싱 오류가 발생할 수 있습니다.

전체 설정과 클라이언트 구독은 용도가 다릅니다

전체 커널 설정에는 보통 인바운드, 아웃바운드, 라우팅, DNS, 로그 등 전역 내용이 포함되어 커널을 직접 실행하는 데 적합합니다. 클라이언트 구독은 주로 원격 노드를 설명하고, 클라이언트는 로컬 시스템 프록시, TUN, 포트, 라우팅 설정을 결합해 최종 설정을 생성합니다. 전체 설정을 일반 노드 구독처럼 가져오면 클라이언트가 전역 규칙을 모두 보존하지 않을 수 있습니다. 반대로 노드 공유 링크만으로는 로컬 인바운드와 라우팅이 부족합니다. 확장자보다 파일의 용도를 확인하는 것이 중요합니다.

v2rayN의 구독 그룹은 여러 원격 노드를 관리하는 데 적합하며, 가져온 후 노드 편집 화면에서 프로토콜, 전송, 보안 필드를 확인할 수 있습니다. v2rayNG와 v2flyNG도 구독을 가져올 수 있지만 사용하는 커널 방향은 서로 다릅니다. 동일한 일반 VMess 또는 Shadowsocks 노드는 대체로 쉽게 옮길 수 있지만 Xray 확장이 포함된 VLESS 노드는 v2rayNG에서 우선 검증해야 합니다. 모든 클라이언트에서 가져올 수 있게 만들겠다는 이유로 핵심 필드를 삭제하지 마세요. 호환 범위가 넓어져도 노드가 올바른 설정을 잃으면 의미가 없습니다.

구독 변환으로 무엇이 바뀔 수 있을까

구독 변환은 이름 통일, 노드 필터링, 다른 클라이언트 형식 출력에 자주 사용됩니다. 변환 과정에서 노드 이름을 다시 쓰거나 알 수 없는 쿼리 매개변수를 삭제하거나 전송 이름을 매핑하거나 기본 지문을 설정하거나 빈 값을 생략할 수 있습니다. 일반 프로토콜에서는 영향이 없을 수 있지만 확장 필드에 의존하는 조합에서는 알 수 없는 필드를 삭제하는 순간 연결 의미가 달라집니다. 변환 결과를 사용할 때는 노드 하나를 추출해 원본 매개변수와 비교하고 protocol, network, security, flow, serverName, publicKey, shortId, path, serviceName을 중점적으로 확인하세요.

구독 업데이트의 안전한 순서

업데이트 전에 현재 사용할 수 있는 노드와 라우팅 모드를 기록하세요. 구독을 업데이트한 뒤에는 새로 추가되거나 삭제된 노드와 프로토콜 변화를 먼저 확인하고 수동 설정을 즉시 일괄 덮어쓰지 마세요. 구조가 명확한 노드 하나를 선택해 커널 시작을 테스트하고 실제 연결을 확인한 다음 자동 선택, 부하 분산 정책, TUN을 복원하세요. 새 구독으로 모든 노드가 작동하지 않으면 이전 그룹과 비교할 수 있습니다. 문제가 구독 다운로드 단계에 집중되면 주소를 확인하고, 노드 파싱 단계에 집중되면 형식을 확인하며, 핸드셰이크 단계에 집중되면 프로토콜 매개변수를 확인하세요.

구독 주소는 설정 자격 증명에 해당하므로 관리되는 기기와 신뢰할 수 있는 클라이언트에서만 사용하세요. 공개 페이지나 스크린샷에 붙여 넣지 마세요. 기기를 옮겨야 한다면 새 클라이언트에서 원본 구독을 다시 추가한 뒤 그룹과 라우팅을 확인하고 여러 번 복사된 단일 노드 텍스트에 의존하지 않는 것이 좋습니다. 파싱 오류가 발생하면 V2Ray 실행 로그 해석을 참고해 rejected, timeout, DNS, 필드 오류로 장애 단계를 구분하세요.

프로토콜 선택은 결국 클라이언트 화면에서 이루어집니다. 이 사이트에서는 세 클라이언트만 다룹니다. 데스크톱에서는 v2rayN을 우선 사용하고 Android에서는 v2rayNG를 우선 사용하며 V2Fly 커널이 필요하면 v2flyNG를 선택하세요. 세 클라이언트 모두 GUI로 노드를 관리하지만 필드 배열과 표시 옵션은 다릅니다. 구독을 가져온 뒤 현재 커널이 노드를 로드할 수 있는지 먼저 확인하고 수동 편집 여부를 결정하세요. 수동 수정은 알고 있는 필드를 바로잡는 데 적합하며 서버가 제공하지 않은 정보를 추측해 채우는 용도가 아닙니다.

v2rayN: 데스크톱의 기본 진입점

v2rayN은 Windows, macOS, Linux를 지원하며 여러 구독, 데스크톱 시스템 프록시, TUN, 라우팅, 여러 커널을 관리하는 데 적합합니다. 노드 목록에서 편집을 선택하면 보통 주소, 포트, 사용자 식별자 또는 비밀번호, 전송 프로토콜, 전송 계층 보안, 서버 이름 등의 필드를 볼 수 있습니다. VLESS 노드가 REALITY를 사용한다면 flow, 공개 키, 짧은 ID, 지문도 확인해야 합니다. UI 버전에 따라 필드 그룹이 다를 수 있지만 위치가 바뀌어도 필드의 의미는 달라지지 않습니다.

데스크톱에서 v2rayN을 우선 사용하는 이유는 노드 관리, 커널 실행, 시스템 프록시 진입점을 한 화면에 모으고 이 사이트에서 다루는 여러 프로토콜을 처리할 수 있기 때문입니다. 노드를 선택한 뒤 먼저 실제 연결을 테스트하고 시스템 프록시나 TUN을 활성화하세요. 노드 테스트가 실패했을 때 시스템 프록시 모드를 계속 바꾸지 마세요. 시스템 프록시는 앱 트래픽이 클라이언트로 들어오는 방식을 결정할 뿐 원격 노드의 핸드셰이크 매개변수를 고칠 수 없습니다. 로그에 설정 로드 실패가 표시되면 프로토콜과 커널을 먼저 확인하고, 연결이 수립된 뒤에도 앱이 접근하지 못한다면 시스템 프록시, 라우팅, DNS를 확인하세요.

v2rayNG: Android에서 Xray를 선택할 때

v2rayNG는 Xray 프로토콜 확장이 필요한 Android 설정에 적합합니다. 구독을 가져온 뒤 노드 상세 화면에서 프로토콜, 전송, TLS 또는 REALITY 관련 필드를 확인하세요. 연결을 시작하면 클라이언트가 시스템 네트워크 인터페이스를 통해 해당 트래픽을 처리합니다. 일부 앱만 연결을 사용해야 한다면 앱별 설정으로 범위를 제어하고, 전체 트래픽을 처리한다면 DNS, 라우팅, 배터리 사용량을 점검하세요. REALITY와 Vision 조합은 구독 필드가 완전하다는 전제에서 v2rayNG로 우선 테스트하는 것이 좋습니다.

모바일 네트워크에서는 주소 변경과 연결 전환이 자주 발생하므로 무선 네트워크에서 정상인 노드가 전환 후 잠시 끊겼다고 해서 반드시 프로토콜 비호환인 것은 아닙니다. 먼저 연결을 중지했다가 다시 시작하고 로그에서 세션이 재수립되는지 확인하세요. 시간 초과가 계속되면 같은 구독의 안정적인 다른 노드로 바꾸세요. 속도 측정을 백그라운드 상주 작업으로 자주 실행하지 마세요. 측정은 능동적으로 연결을 만들고 리소스를 소모합니다. 평소 안정적인 노드 하나와 다른 프로토콜의 예비 노드 하나를 남겨 두면 장애 범위를 빠르게 판단할 수 있습니다.

v2flyNG: V2Fly 커널 대안

v2flyNG의 사용 방식은 일반적인 Android GUI 클라이언트와 비슷하지만 V2Fly 커널을 사용합니다. 구독이 주로 VMess, 일반 VLESS, Trojan, Shadowsocks로 구성되어 있다면 V2Fly 구현에서의 동작을 확인하는 데 사용할 수 있습니다. 노드에 REALITY, Vision 또는 다른 Xray 확장이 포함되어 있으면 가져오기는 성공해도 실행 단계에서 실패할 수 있습니다. 이는 기능 범위의 한계이므로 필드를 삭제해 억지로 실행해서는 안 됩니다. 이때는 v2rayNG로 전환하거나 구독에서 제공하는 일반 프로토콜 노드를 선택하세요.

UI 필드 읽는 법

주소와 포트는 연결 대상을 결정합니다. 사용자 식별자는 VMess 또는 VLESS 인증에 사용되고 비밀번호는 Trojan과 Shadowsocks에서 흔합니다. 암호화 방식은 주로 Shadowsocks에 사용됩니다. 전송 유형은 TCP, WebSocket, gRPC 등의 전달 방식을 결정하고 Host, path, serviceName은 해당 전송 매개변수입니다. security는 TLS 또는 REALITY를 가리키며 serverName은 보안 핸드셰이크에 사용되고 flow는 특정 VLESS 조합에서 자주 사용됩니다. 클라이언트마다 번역이 다를 때는 화면 위치보다 필드의 역할을 기준으로 대응하세요.

노드를 수정할 때는 한 번에 하나의 필드만 바꾸고 변경 전에 노드를 복사해 백업하세요. 주소, 전송, 보안 계층을 동시에 수정하면 테스트 실패 후 원인을 알 수 없습니다. 구독 노드는 보통 서버가 관리하므로 수동 변경 사항이 다음 업데이트에서 덮어써질 수 있습니다. 오래 유지해야 하는 로컬 변경은 노드를 복사해 별도 노드로 만들고 이름에 표시하세요. 원본 구독 노드는 그대로 두어 서버 측 변경 사항과 비교할 수 있게 하세요.

클라이언트를 선택한 뒤 튜토리얼의 기본 단계에 따라 구독을 가져오고 노드를 선택해 연결을 시작한 다음 확인하세요. 운영체제와 CPU에 맞는 설치 패키지를 확인하려면 V2Ray 클라이언트 다운로드 페이지로 이동하세요. 다운로드 페이지 하단의 다운로드 자주 묻는 질문에서는 설치 패키지 선택, 시스템 요구 사항, 업그레이드 방법을 정리합니다. 이 페이지에서는 프로토콜과 커널 판단을 계속 다룹니다.

앞에서 계층별로 나누어 확인했다면 선택 과정은 고정된 흐름으로 정리할 수 있습니다. 기기와 클라이언트를 확인하고 커널을 확인한 뒤 구독이 실제로 제공하는 프로토콜 조합을 살펴보세요. 필드가 불완전하거나 커널이 지원하지 않는 노드를 제외하고 남은 노드의 안정성을 테스트합니다. 프로토콜은 최신일수록 좋은 것도, 필드가 적을수록 좋은 것도 아닙니다. 가장 적합한 노드는 서버가 제공하고, 클라이언트가 완전하게 파싱하며, 커널이 실행하고, 현재 회선이 안정적이며, 기기 리소스가 감당할 수 있어야 합니다.

데스크톱 일상 사용

Windows, macOS, Linux 데스크톱에서는 먼저 v2rayN을 사용하세요. 구독에 완전한 VLESS + REALITY 필드가 있다면 Xray 커널에서 우선 테스트하고, 기존 VMess, Trojan, Shadowsocks 노드가 장기간 안정적이라면 계속 유지해도 됩니다. 데스크톱은 보통 CPU와 메모리가 더 충분하므로 프로토콜 간 작은 계산 차이를 첫 번째 기준으로 삼을 필요가 없습니다. 연결 안정성, 회선 품질, 앱 호환성, 라우팅 요구 사항을 우선 확인하세요. 모든 트래픽을 TUN으로 처리할 때는 권한, DNS, 라우팅을 추가로 점검하고 TUN 문제를 원격 프로토콜 탓으로 돌리지 마세요.

Android 일상 사용

Android에서 구독에 REALITY, Vision 또는 다른 Xray 확장이 포함되어 있다면 v2rayNG를 선택하세요. 구독이 일반 VMess, Trojan, Shadowsocks 또는 일반 VLESS 중심이고 V2Fly 커널을 사용하려면 v2flyNG를 선택할 수 있습니다. 모바일에서는 연결 안정성과 재연결 동작을 우선 고려하세요. 지연 시간이 가장 짧아도 자주 끊기는 노드는 지연 시간이 조금 높지만 안정적인 노드보다 실제 배터리 사용량과 체감 품질이 나쁠 수 있습니다. 네트워크 전환 후 빠르게 교차 테스트할 수 있도록 다른 프로토콜의 노드 두 개를 남겨 두세요.

기존 설정을 새 클라이언트로 옮기기

마이그레이션할 때는 노드를 하나씩 옮겨 적기보다 원본 구독을 다시 가져오는 것이 좋습니다. 가져온 뒤 노드 수, 프로토콜, 전송, 보안 필드를 확인하고 일반 노드 하나와 확장 기능이 포함된 노드 하나를 테스트하세요. 원격 연결이 정상임을 확인한 다음 라우팅, DNS, 시스템 프록시, TUN 설정을 옮기세요. 기존 클라이언트가 V2Fly이고 새 클라이언트가 Xray라면 일반 프로토콜은 대체로 쉽게 이동할 수 있지만 기본 필드는 확인해야 합니다. 반대 방향이라면 REALITY, Vision, 최신 전송 기능을 먼저 제외하고 확인하세요.

프로토콜 마이그레이션을 클라이언트에서 유형을 바꾸는 일로 이해해서는 안 됩니다. VMess 드롭다운을 VLESS로 바꿔도 서버에 해당 진입점이 생기지 않으며 TLS를 REALITY로 바꿔도 공개 키와 짧은 ID 같은 서버 매개변수가 만들어지지 않습니다. 실제 프로토콜 마이그레이션에는 서버가 새 노드를 제공하거나 구독을 업데이트하는 과정이 필요합니다. 클라이언트의 역할은 매개변수를 완전하게 받고 적절한 커널을 선택한 뒤 연결을 검증하는 것입니다.

로그에 따라 문제 해결 경로 선택

설정을 시작할 수 없다면 먼저 필드 구조, 커널 지원, 로컬 포트를 의심하세요. 연결이 즉시 실패하면 주소, 포트, 인증 값, 보안 필드를 확인하고, 오랫동안 시간 초과가 발생하면 네트워크 접근성, 서버 상태, 회선을 점검하세요. 특정 도메인만 이상하면 DNS와 라우팅을 확인하고, 브라우저는 정상인데 다른 앱이 작동하지 않으면 시스템 프록시 적용 범위나 TUN을 확인하세요. 모바일에서 네트워크 전환 후 문제가 생기면 먼저 연결을 다시 만든 뒤 실패가 계속되는지 관찰하세요.

5분 선택 체크리스트

1. 클라이언트 결정: 데스크톱은 v2rayN, Android는 Xray 또는 V2Fly 필요에 따라 v2rayNG나 v2flyNG를 선택합니다.
2. 노드 상세 정보 열기: 기본 프로토콜, 전송 방식, 보안 계층, 핵심 확장 필드를 기록합니다.
3. 기능 충돌 제외: REALITY, Vision 또는 최신 전송 필드는 이를 명확히 지원하는 Xray 커널에 우선 맡깁니다.
4. 실제 연결 테스트: 먼저 설정 로드 여부를 확인하고 핸드셰이크를 점검한 뒤 실제 앱과 지속 전송을 테스트합니다.
5. 기기 비용 관찰: 모바일에서는 재연결, 배터리, 네트워크 전환을 보고 데스크톱에서는 라우팅, DNS, TUN을 확인합니다.
6. 대체 노드 보존: 매개변수가 명확하고 프로토콜이 다르며 연결을 검증한 노드를 최소 하나 남겨 둡니다.

더 깊이 알아보려면 지연 시간과 지역을 기준으로 한 노드 선택은 노드 선택 방법에서, 라우팅 문법은 domain, ip, geosite 규칙 설명에서 확인하세요. 실행 실패는 로그 오류 대조로 원인을 찾을 수 있습니다. 이 개념을 처음 접한다면 먼저 V2Ray 초보자 질문 10가지를 읽은 뒤 이 페이지의 해당 장으로 돌아오세요.

프로토콜 선택에서 모든 고급 설정을 한 번에 완료할 필요는 없습니다. 먼저 구독의 원본 매개변수로 안정적인 연결을 만든 다음 시스템 프록시, 라우팅, DNS, TUN을 단계적으로 추가하세요. 항목을 하나 추가할 때마다 검증하고 문제가 생기면 가장 최근 변경 사항부터 되돌리세요. 이렇게 하면 원격 프로토콜, 클라이언트 커널, 로컬 네트워크 설정을 분리해 처리할 수 있어 여러 변수가 겹치는 것을 막을 수 있습니다. 설치 패키지를 다시 받아야 한다면 다운로드 센터로 이동하고, 가져오기부터 검증까지 처음부터 다시 진행하려면 설정 튜토리얼로 돌아가세요.