V2Ray 프로토콜 및 코어
선택을 위한 기술 가이드

프로토콜 및 설정 계층: 노드 설정 읽기

연결을 네 가지 질문으로 나누기

클라이언트의 노드는 하나의 프로토콜 스위치가 아니라 여러 연결 매개변수의 조합입니다. 설정을 읽을 때는 네 가지를 확인하세요. 어느 서버에 연결하는지, 어떤 방식으로 인증하는지, 데이터를 어떤 전송 방식으로 보내는지, 연결 바깥에 어떤 보안 메커니즘을 적용하는지입니다. 서버 주소와 포트는 접속 지점을 지정하고, VMess, VLESS, Trojan 또는 Shadowsocks는 프록시 프로토콜을 정합니다. TCP나 WebSocket 등은 전송 수단을, TLS나 REALITY는 보안 계층을 다룹니다. 서로 연관은 있지만 같은 종류의 옵션처럼 서로 바꿔 쓸 수는 없습니다.

예를 들어 “VLESS + WebSocket + TLS” 설정이라면 사용자 식별자, WebSocket 경로, 요청 호스트와 TLS 서버 이름을 각각 확인해야 합니다. 경로가 맞아도 사용자 식별자가 틀리면 연결되지 않고, 서버 이름이 맞아도 원격 서버가 해당 포트를 수신 중이라는 뜻은 아닙니다. 클라이언트 화면에서 여러 필드를 한 창에 모아 보여 주면 프로토콜만 선택하면 설정이 끝난 것처럼 착각하기 쉽습니다. 노드 이름을 보고 추측하지 말고 서버에서 받은 전체 매개변수를 계층별로 대조하세요.

시스템 프록시와 TUN은 별도의 계층입니다

시스템 프록시는 앱의 요청을 로컬 프록시로 보낼지 결정하고, TUN은 가상 네트워크 인터페이스로 라우팅된 트래픽을 받습니다. 이 기능들은 트래픽이 클라이언트로 들어오는 방식을 바꿀 뿐, VMess를 VLESS로 바꾸거나 원격 인증 오류를 해결하지는 않습니다. 브라우저 하나만 연결되고 다른 프로그램은 연결되지 않는다면 먼저 해당 앱이 시스템 프록시를 따르는지 확인하세요. 모든 앱에서 실패한다면 로컬 진입점, 코어 아웃바운드, 원격 진입점 순으로 점검하세요.

도메인 이름이 어느 단계에서 조회되는지 구분하기

서버 주소가 도메인이라면 연결을 시작하기 전에 먼저 도메인 조회가 필요합니다. 반면 접속하려는 웹사이트의 도메인은 로컬 앱, 클라이언트 DNS 모듈 또는 원격 서버가 조회할 수 있습니다. 두 가지는 서로 다른 조회 경로입니다. 대상 도메인의 분기 규칙을 바꿔도 서버 도메인의 조회 결과까지 바뀌는 것은 아닙니다. “도메인 주소로는 실패하지만 IP 주소를 직접 입력하면 연결되는” 경우에는 진입점 도메인의 조회와 주소 체계를 확인하세요. 바로 프로토콜을 바꾸지는 마세요. IP 주소를 직접 입력하는 것은 원인을 좁히기 위한 방법일 뿐이며, 올바른 보안 계층 서버 이름은 그대로 유지해야 합니다.

클라이언트를 선택할 때도 같은 순서를 따르세요. 현재 서비스가 어떤 조합을 제공하는지 확인하고, 클라이언트 코어가 해당 조합을 구현하는지 확인한 뒤 TUN, 분기 규칙 또는 구독 관리가 필요한지 검토하세요. 데스크톱에서는 v2rayN 다운로드 페이지에서 플랫폼을 선택할 수 있습니다. 구독 링크만 있다면 먼저 가져온 다음 노드 세부 정보를 확인하세요. 보안 계층 이름을 무작정 바꾸면 기존 설정과 서버의 대응 관계가 깨지는 경우가 많습니다.

VMess와 VLESS: 인증 및 암호화 선택

VMess의 설계 배경과 호환 범위

VMess는 Project V 생태계의 프록시 프로토콜로, 사용자 인증과 데이터 보호 메커니즘을 포함해 비교적 완결된 프로토콜 처리 과정을 구성합니다. 기존 구독에서 여전히 흔히 사용되므로 이름이 오래됐다는 이유만으로 사용할 수 없다고 단정해서는 안 됩니다. 현재 클라이언트 코어와 서버 구현이 호환되는지, 설정이 완전한지, 실제 요구에 맞는지를 기준으로 판단하세요. 프로토콜 내부의 데이터 보호와 외부 TLS는 서로 다른 계층입니다. 둘을 함께 사용한다고 해서 같은 암호화 옵션을 중복 설정하는 것은 아닙니다.

VMess에서 자주 발생하는 문제는 사용자 식별자, 암호화 설정과 시스템 시간입니다. 인증 과정에는 시간 관련 검증이 포함되므로 기기 시간이 크게 어긋나면 핸드셰이크가 실패할 수 있습니다. 이때는 구독을 반복해서 새로고침하지 말고 시스템 자동 시간 설정을 켜세요. 이전 설정에는 추가 식별 매개변수가 남아 있을 수 있으며, 최신 구현에서는 보통 AEAD 인증을 사용합니다. 과거 필드가 있다면 서비스 제공자에게 적용 여부를 확인하세요. 오래된 화면을 보고 임의로 값을 입력하거나, 이전 매개변수와의 호환성이 모든 구형·신형 구현 간 호환을 뜻한다고 생각해서는 안 됩니다.

VLESS는 보안 책임을 조합에 맡깁니다

VLESS는 프로토콜 자체의 처리를 간소화하며, VMess와 같은 데이터 암호화 책임을 프로토콜 계층에서 맡지 않는 대신 보통 TLS 또는 REALITY와 함께 사용합니다. 간소화됐다고 자동으로 안전해지거나 모든 연결이 더 빨라지는 것은 아닙니다. 공용 네트워크에서 사용한다면 외부 보호를 어떻게 설정하는지 확인해야 합니다. 서버에 해당 진입점이 없는데 VMess 노드의 프로토콜 선택만 VLESS로 바꾸면 인증에 실패합니다. 프로토콜 변경은 양쪽에 설정해야 하며 클라이언트에서만 바꿔서는 안 됩니다.

VLESS 설정의 사용자 식별자는 여전히 인증 정보이며 TLS 서버 이름과 혼동해서는 안 됩니다. 흐름 제어 필드에도 구현상 제약이 있습니다. 서비스 제공자가 Vision 관련 설정을 안내했다면 전송 방식, 코어 지원 여부와 서버 요구 사항을 확인하세요. 모든 VLESS 노드에 같은 흐름 제어를 설정해야 하는 것은 아니며, REALITY가 보인다는 이유만으로 흐름 제어 값을 추가해서도 안 됩니다. 일반적인 설정을 무조건 적용하기보다 구독에 명시된 설정을 유지하는 편이 안전합니다.

둘 중 무엇을 선택할까

VMess 설정이 안정적으로 동작하고 대상 클라이언트에서 문제없이 가져올 수 있다면, “새 프로토콜이 더 빠르다”는 막연한 말만 믿고 바꿀 필요는 없습니다. 서버가 VLESS와 적절한 보안 계층을 명시적으로 제공하고 클라이언트 코어가 해당 조합을 지원한다면 원래 매개변수를 사용해 볼 수 있습니다. 비교할 때는 서버, 테스트 대상과 로컬 트래픽 처리 방식을 동일하게 유지하세요. 그렇지 않으면 진입점별 부하, 회선과 라우팅 정책이 프로토콜 차이를 가릴 수 있어 프로토콜이 아니라 두 노드 전체를 비교하게 됩니다.

전환하기 전에 기존 설정을 보관하고 새 설정은 별도 그룹에 가져오세요. 웹페이지 접속, 장시간 연결과 필요한 UDP 앱을 확인한 다음 기본 노드를 바꿀지 결정하세요. 정상 작동하는 항목을 덮어쓴 뒤 문제를 진단하지 마세요. 새 설정이 특정 코어에서만 실패한다면 전송 및 보안 계층의 지원 여부를 확인하고, 모든 코어에서 실패한다면 서버 매개변수와 네트워크 연결 상태를 점검하세요. 가져오기 방법은 v2rayN 구독 가져오기 튜토리얼을 참고하세요. 이 장에서는 필드 간 관계를 설명합니다.

Trojan과 Shadowsocks: 서로 다른 연결 방식

Trojan은 온전한 TLS 연결을 사용합니다

Trojan은 일반적으로 TLS 연결 안에서 프록시 요청을 전달하고 비밀번호로 인증합니다. 설정 화면이 간단해 보여도 주소와 비밀번호만 있으면 되는 것은 아닙니다. 서버 이름, 인증서 신뢰 여부와 전송 설정도 중요합니다. 연결할 IP 주소와 검증할 도메인은 다를 수 있습니다. IP 주소는 서버를 찾는 데 쓰이고, 도메인은 예상한 TLS 신원과 연결을 맺는 데 사용됩니다. 서버에서 별도의 이름 필드를 제공한다면 노드 주소를 모든 입력란에 그대로 복사하지 말고 해당 값을 유지하세요.

인증서 오류가 발생하면 먼저 이름 일치 여부, 시스템 시간의 정확성, 인증서 체인의 완전성을 점검하세요. 인증서 검증을 끄면 보안 전제가 달라지므로 일반적인 해결책으로 사용해서는 안 됩니다. 서버에서 별도로 구성한 배포 방식이라면 어떤 전송 수단을 사용하는지도 확인해야 합니다. 확장 조합을 표현하는 방식은 코어나 클라이언트마다 다를 수 있습니다. 일반적인 Trojan 진입점이 동작한다고 해서 추가 전송 확장도 지원한다는 뜻은 아닙니다. 실제 구현과 매개변수를 확인하세요.

Shadowsocks에서는 방식 필드를 생략할 수 없습니다

Shadowsocks는 흔히 SS로 줄여 부르며, 공유 키를 사용합니다. 클라이언트에는 서버 주소, 포트, 비밀번호와 암호화 방식이 필요합니다. 주로 외부 TLS에 의존하는 설정 경로와는 다르므로 SS의 방식 이름을 VLESS 보안 계층 옵션에 입력할 수 없습니다. 이전 방식과 최신 AEAD 방식은 서로 다르며, 실제 선택은 서버가 지원하는 범위에 따라야 합니다. 클라이언트 목록에서 더 강해 보이는 방식으로 바꿔도 서버가 자동으로 업그레이드되지는 않습니다. 오히려 양쪽에서 데이터를 해석하지 못해 연결이 실패할 수 있습니다.

일부 최신 Shadowsocks 방식은 키의 인코딩과 길이를 엄격히 요구하므로 임의의 짧은 문구를 공통 비밀번호처럼 사용할 수 없습니다. 클라이언트에 방식 이름이 표시된다고 해서 현재 실행 중인 코어에서 구현된다는 보장도 없습니다. 가져온 뒤 방식이 사라지거나 비밀번호가 잘리거나 인증이 계속 실패한다면 같은 연결을 반복해서 시도하지 말고 원본 공유 형식과 대조하세요. 플러그인 매개변수도 확인해야 합니다. 기본 SS를 지원한다고 해서 특정 외부 플러그인이나 확장 전송까지 실행할 수 있는 것은 아닙니다.

UDP, 연결 재사용과 사용 범위

두 프로토콜 모두 “UDP 지원”이라는 문구만으로 대상 앱에서 사용할 수 있다고 판단해서는 안 됩니다. 원격 서버의 전달 허용 여부, 클라이언트의 관련 기능 활성화 여부, 로컬 앱 트래픽이 프록시에 들어가는지, 라우팅이 이를 허용하는지에 따라 결과가 달라집니다. TCP 연결만 확인하는 테스트로는 음성 통화, 게임 또는 다른 UDP 앱의 동작을 알 수 없습니다. 웹페이지는 열리지만 특정 앱이 실패한다면 비밀번호를 바로 바꾸지 말고 먼저 앱의 전송 방식과 트래픽 처리 경로를 확인한 다음 원격 지원 여부를 점검하세요.

설정을 관리할 때 Trojan은 주로 TLS 이름, 인증서와 비밀번호를, SS는 방식, 키와 선택적 확장 매개변수를 확인해야 합니다. 서버가 둘 중 하나만 제공한다면 해당 조합을 지원하는 클라이언트를 사용하면 됩니다. 이름을 통일하려고 다른 프로토콜로 변환할 필요는 없습니다. 데스크톱에서는 v2rayN에서 노드의 전체 매개변수를 확인하고, Android에서는 코어 요구 사항에 따라 v2rayNG 또는 v2flyNG를 선택할 수 있습니다. 두 기기에서 같은 서버 매개변수를 사용하면 클라이언트 차이와 서버 문제를 구분하기 쉽습니다.

TLS와 REALITY: 보안 계층 매개변수 확인

이름 검증과 네트워크 접속 지점을 구분하세요

TLS는 연결을 보호하며, 일반적인 사용에서는 상대방의 신원도 검증해야 합니다. 서버 이름은 연결하려는 대상의 신원을 나타내며 실제 연결 주소와 다를 수 있습니다. ALPN은 애플리케이션 계층 프로토콜을 협상하는 용도이지 임의로 설정하는 속도 향상 옵션이 아닙니다. 서버 설정에서 요구하는 값만 약속된 대로 설정하세요. 연결을 통과시키려고 이름이나 인증서 문제를 무시하면 기존 검증 조건을 잃게 됩니다. 먼저 설정 출처와 원격 서버 구성이 일치하는지 확인하세요.

WebSocket이나 다른 중간 전송 수단을 사용하는 구성에서는 요청 호스트, TLS 서버 이름과 경로가 각기 다른 처리 단계에 영향을 줄 수 있습니다. 어떤 배포에서는 같은 도메인을 사용하지만 그렇지 않은 경우도 있습니다. 문제를 진단할 때는 필드 이름과 의미를 정리하세요. 화면에 입력란이 몇 개 없다는 이유로 모든 값을 하나로 통일해서는 안 됩니다. 브라우저에서 특정 도메인에 접속할 수 있다는 사실은 해당 브라우저 경로가 동작한다는 뜻일 뿐, 프록시 프로토콜 인증과 경로, 원격 전달까지 정상이라는 뜻은 아닙니다.

REALITY는 다섯 번째 아웃바운드 프로토콜이 아닙니다

REALITY는 Xray 생태계의 보안 계층 메커니즘으로, 흔히 VLESS와 조합해 사용합니다. 일반적인 TLS 인증서 구성과 설정 방식이 다르므로 보안 계층 이름만 REALITY로 바꾼다고 전환이 완료되는 것은 아닙니다. 클라이언트에는 보통 서버가 제공한 서버 이름, 인증용 공개 키 매개변수와 shortId가 필요하며, 경우에 따라 핑거프린트와 흐름 제어도 확인해야 합니다. 클라이언트에 따라 관련 필드를 “공개 키”로 표시하거나 코어 업데이트에 따라 이름이 달라질 수 있으므로 코어 문서와 구독 제공자의 필드 안내를 대조하세요.

공개 키는 서버가 보유한 개인 키에 대응하는 값이며 도메인으로 추측할 수 없습니다. shortId는 서버에서 허용한 값이어야 하며, 빈 값은 서버가 명시적으로 허용하는 경우에만 사용할 수 있습니다. 다른 노드의 값을 가져다 쓰지 마세요. 연결 주소는 배포된 진입점을 찾는 데 사용하고 서버 이름은 해당 배포의 요구 사항을 충족해야 합니다. 두 필드의 역할은 다릅니다. 구독을 업데이트한 뒤 값이 달라졌다면 기존 설정이 더 이상 유효하지 않을 수 있습니다. 주소와 포트만 바꾸지 말고 전체 매개변수를 다시 가져오세요.

핑거프린트와 흐름 제어는 성능 조절 버튼이 아닙니다

클라이언트 핑거프린트는 TLS 핸드셰이크 특성을 구현하는 방식과 관련이 있으며, 선택 가능한 값은 코어에 따라 다릅니다. 이름만 보고 호환 여부를 판단할 수 없습니다. 흐름 제어 역시 프로토콜 조합과 원격 서버 설정에 따라 제한됩니다. 가져온 뒤 알 수 없는 매개변수라는 안내가 표시되면 먼저 올바른 코어를 선택했는지, 현재 설정 형식이 해당 필드를 표현할 수 있는지, 변환 과정에서 정보가 사라졌는지 확인하세요. 화면마다 기본값이 다를 수 있으므로 문제를 진단할 때는 가져오기 전 공유 텍스트를 기억에 의존해 비교하지 말고 실제 저장된 설정을 확인해야 합니다.

안전한 확인 순서는 다음과 같습니다. 먼저 원격 서버가 일반 TLS를 사용하는지 REALITY를 사용하는지 확인한 다음 서버 이름을 대조하세요. REALITY라면 공개 키 매개변수와 shortId를 확인하고, 마지막으로 핑거프린트, 흐름 제어와 전송 방식을 점검하세요. 한 번에 관련 필드 한 묶음만 변경하고 원래 값을 보관하세요. 주소, 코어와 보안 계층을 동시에 바꾸면 원인을 찾기 어렵습니다. 핸드셰이크 오류는 문제 해결의 연결 점검 안내를 참고해 로그를 확인할 수 있지만, 인증 매개변수가 포함된 전체 설정을 공개적으로 붙여 넣어서는 안 됩니다.

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

최초 연결과 지속적인 전송을 나눠 살펴보세요

“어떤 프로토콜이 빠른가”를 논하기 전에 무엇을 측정할지 정해야 합니다. 페이지를 처음 열 때는 도메인 조회, 서버 연결, 프로토콜 인증과 TLS 핸드셰이크가 영향을 줍니다. 지속적인 다운로드에서는 회선 용량, 혼잡, 원격 서버 부하와 기기의 처리 성능이 더 중요합니다. 어떤 조합이 처리 단계를 하나 줄인다고 해서 모든 네트워크에서 페이지 로딩 시간이 눈에 띄게 줄어드는 것은 아닙니다. 테스트 대상이나 서버 진입점이 다르면 최종 차이를 모두 프로토콜 탓으로 돌릴 수 없습니다. 이를 근거로 고정된 속도 순위를 매기는 것도 적절하지 않습니다.

핸드셰이크는 왕복 지연 시간의 영향을 크게 받고, 대용량 전송은 안정적인 처리량에 더 민감합니다. 적절한 상황에서 연결 재사용은 반복적인 연결 수립을 줄일 수 있지만 연결 간 경쟁이나 장애의 영향 범위를 바꿀 수도 있습니다. 클라이언트에 재사용 옵션이 있다고 해서 모든 노드에서 켜야 하는 것은 아닙니다. 일부 조합에는 재사용이나 흐름 제어에 관한 제약이 있으므로 서버 권장 사항을 우선 따르세요. 효과를 확인하려면 나머지 설정을 그대로 유지하고 짧은 요청, 장시간 연결, 동시 접속을 각각 관찰하세요.

CPU와 메모리 오버헤드는 전체 처리 과정에서 발생합니다

VMess 프로토콜 처리, SS 암호화 방식, TLS 핸드셰이크, 데이터 복사와 전송 캡슐화 모두 오버헤드를 발생시킵니다. 최신 프로세서의 하드웨어 가속 기능에 따라 상대적인 비용도 달라집니다. VLESS는 프로토콜 계층의 처리를 줄이지만 외부 보안 메커니즘에는 여전히 연산 자원이 필요합니다. TUN, DNS 모듈과 규칙 비교에도 자원이 사용되므로 클라이언트 전체 사용량을 특정 프로토콜의 사용량으로 간주해서는 안 됩니다. 데스크톱에서 모드를 바꾼 뒤 메모리 사용량이 달라졌다면 추가 코어 기능이나 규칙 집합이 함께 활성화됐는지 먼저 확인하세요.

모바일에서는 화면 깨우기와 재연결을 중점적으로 확인하세요

Android 기기의 배터리는 암호화 연산뿐 아니라 무선 연결 유지, 백그라운드 하트비트, DNS 요청과 실패 후 반복되는 재연결에도 소모됩니다. 신호가 약하거나 네트워크를 자주 전환하면 같은 프로토콜도 다르게 동작할 수 있습니다. 클라이언트를 켠 뒤 대기 중 배터리 소모가 크게 늘었다면 계속 실패하는 로그가 있는지, 특정 앱이 자주 네트워크에 접속하는지, 구독 업데이트나 연결 확인 작업이 너무 잦은지 확인하세요. 재연결이 계속 반복되는 상황에서 프로토콜만 바꿔서는 근본 원인을 해결하기 어렵습니다.

배터리 사용량을 비교할 때는 신호 상태를 비슷하게 유지하고 같은 앱과 사용 방식을 적용하세요. 화면을 켜 둔 테스트와 백그라운드 대기 테스트도 구분해야 합니다. 짧은 시간 동안 배터리 비율이 조금 달라졌다는 것만으로 프로토콜의 우열을 판단할 수는 없습니다. 데스크톱도 유휴 상태와 사용 중 상태를 모두 확인하고, 한쪽에서만 다른 다운로드 작업을 실행한 채 비교하지 마세요. 브라우저가 아닌 프로그램의 트래픽 처리에 관심이 있다면 v2rayN TUN 모드의 작동 원리와 설정을 살펴보세요. 먼저 트래픽이 들어오는 경로를 해결한 뒤 추가 오버헤드를 평가해야 합니다.

V2Fly, Xray와 세 클라이언트의 역할

코어 계열과 그래픽 인터페이스는 서로 다른 계층입니다

Project V는 이 생태계를 이해하는 출발점입니다. V2Fly는 V2Ray 관련 프로젝트의 개발을 이어가고 있으며, Xray는 V2Ray와 공통된 역사를 바탕으로 별도로 발전하고 있습니다. 두 프로젝트는 프로토콜, 전송 방식과 설정 구조에서 공통 기반을 공유하지만 각각 기능도 발전시켜 왔습니다. 오픈 소스라는 것은 각 프로젝트의 라이선스에 따라 코드를 확인하고 사용할 수 있다는 뜻이지, 서로 다른 프로젝트가 언제나 완전히 같은 설정 의미를 공유한다는 뜻은 아닙니다. 특정 기능은 이름만 보지 말고 실제 실행 중인 코어의 구현을 기준으로 확인하세요.

그래픽 클라이언트는 구독 관리, 노드 편집, 코어 실행과 시스템 프록시 설정 등을 담당하고 코어는 연결 처리, 프로토콜 구현과 규칙 실행을 맡습니다. v2rayN은 Windows, macOS와 Linux를 지원하는 데스크톱 우선 클라이언트입니다. 같은 클라이언트라도 화면 구성이나 패키징 방식이 다를 수 있으며, 이를 서로 다른 프록시 프로토콜로 오해해서는 안 됩니다. 설치 파일을 선택할 때는 먼저 플랫폼과 프로세서 아키텍처를 확인하고, 그다음 실제로 실행되는 코어와 코어에 전달되는 설정을 확인하세요.

Android에서는 필요한 코어에 맞춰 선택하세요

v2rayNG는 Android용 클라이언트로 Xray 코어를 사용하며, v2flyNG는 V2Fly 코어를 사용하는 대안입니다. 가져오기 과정이 비슷해 보여도 두 클라이언트의 코어 기능까지 같은 것은 아닙니다. REALITY 등 Xray 관련 기능이 필요하다면 현재 조합을 v2rayNG가 지원하는지 먼저 확인하세요. v2flyNG가 같은 설정을 그대로 지원한다고 가정해서는 안 됩니다. 기존 설정이 V2Fly용이라면 이름이 비슷하다는 이유만으로 결정하지 말고 실제 전송 및 프로토콜 지원 여부를 기준으로 v2flyNG를 검토하세요.

v2rayN에서 코어를 선택할 수 있다면 노드와 라우팅 설정을 실제로 어느 코어가 처리하는지 확인하세요. 화면에서 필드를 저장할 수 있다는 것은 편집기가 텍스트를 받아들였다는 뜻일 뿐, 백그라운드 코어가 해당 기능을 구현했다는 뜻은 아닙니다. 시작에 실패하면 먼저 코어 오류를 확인하고, 연결에 실패하면 핸드셰이크와 라우팅 오류를 확인하세요. 로그에 알 수 없는 필드나 미지원 전송 유형이 표시된다면 시스템 프록시를 반복해서 켜고 끄지 말고 코어 호환성을 확인해야 합니다. 두 오류는 서로 다른 처리 단계에서 발생합니다.

필드별로 설정 호환성을 확인하세요

두 코어가 모두 JSON을 사용한다고 해서 전체 설정 파일을 서로 그대로 바꿔 쓸 수 있는 것은 아닙니다. 같은 프로토콜 이름을 쓰더라도 확장 매개변수, 기본값, 전송 구현이나 DNS 동작이 다를 수 있습니다. 설정을 이전할 때는 먼저 작동에 필요한 최소한의 아웃바운드를 옮긴 다음 라우팅, DNS와 다른 기능을 하나씩 추가하세요. 복잡한 설정 전체를 한 번에 복사하면 지원되지 않는 필드와 설정 간 의존성까지 함께 옮겨져 노드 문제처럼 보이는 설정 로드 오류가 발생할 수 있습니다.

클라이언트를 업그레이드할 때도 인터페이스와 코어의 변화를 구분해야 합니다. 인터페이스에 새 옵션이 추가됐다고 기존 설정을 모두 변경해야 하는 것은 아닙니다. 코어를 업데이트한 뒤에는 이전 필드에 안내가 표시되거나 호환성이 달라질 수 있습니다. 복구할 수 있는 설정을 저장하고 현재 코어 이름을 기록한 뒤 노드 하나부터 검증하면 이전 비용을 줄일 수 있습니다. 설치와 실행 환경 문제는 v2rayN 첫 설치 및 초기 설정을 참고하세요. 클라이언트와 아키텍처별 다운로드는 다운로드 센터에서 확인할 수 있으므로 별도의 코어 다운로드 페이지를 찾을 필요는 없습니다.

구독 형식 호환성: 가져온 뒤 확인할 사항

구독 주소, 공유 링크와 코어 설정

구독 주소는 보통 노드 정보를 반환하는 네트워크 리소스를 가리킵니다. 단일 노드 공유 링크에는 하나의 연결 설정이 인코딩되어 있고, 코어 설정 파일에는 로컬 인바운드, DNS와 라우팅도 포함될 수 있습니다. 세 가지는 용도가 다르므로 텍스트가 길어 보인다는 이유만으로 같은 방식으로 가져와서는 안 됩니다. 일부 클라이언트는 여러 형식을 자동으로 인식하지만 지원 범위에는 한계가 있습니다. 먼저 구독 주소인지 단일 노드 내용인지 확인한 다음 해당 가져오기 메뉴를 선택하면 웹 주소나 전체 설정 파일을 노드 링크로 잘못 가져오는 일을 피할 수 있습니다.

기존 구독에서는 Base64로 인코딩된 여러 줄의 공유 내용이 흔히 사용되며, 다른 구조화 형식도 있습니다. Base64는 인코딩일 뿐 기밀성을 제공하지 않습니다. 디코딩할 수 있다고 해서 각 줄에 유효한 노드가 들어 있다는 뜻도 아닙니다. VMess 공유 내용은 인코딩된 JSON에 필드를 담는 경우가 많고, VLESS와 Trojan은 쿼리 매개변수가 포함된 URI를 자주 사용합니다. SS에는 여러 인코딩 표현이 있습니다. 형식마다 새 필드를 표현하는 능력이 다르므로 구독을 변환할 때는 특히 보안 계층, 흐름 제어와 확장 전송 매개변수가 유지되는지 확인하세요.

인코딩이 올바르더라도 설정 의미가 사라질 수 있습니다

비밀번호, 경로와 쿼리 매개변수에 특수 문자가 포함된 경우 해당 형식의 인코딩 규칙을 따라야 합니다. 예를 들어 URL의 구분 문자를 일반 문자처럼 임의로 사용해서는 안 되며, 메신저에서 줄바꿈되거나 복사 과정에서 잘려도 링크가 손상될 수 있습니다. 문제를 확인할 때는 먼저 원본에서 다시 복사하세요. 직접 디코딩하고 수정한 뒤 다시 인코딩하면 오히려 오류가 추가될 수 있습니다. 구독 응답이 로그인 페이지나 오류 메시지라면 네트워크 요청이 성공했더라도 유효한 노드가 만들어지지 않습니다.

아래는 로컬 SOCKS 인바운드의 최소 예시입니다. 코어 설정과 노드 공유 링크의 구조가 서로 다르다는 점을 보여 주기 위한 것으로, 완전한 클라이언트 설정이 아니며 구독 가져오기에 사용할 수 없습니다. 해당 코어의 전체 설정 구조 안에 넣고 아웃바운드를 설정해야 합니다. 예시는 루프백 주소에만 바인딩해 로컬 프록시 진입점이 다른 기기에 노출되지 않도록 했습니다. 그래픽 클라이언트를 사용하는 경우 일반적으로 인터페이스에서 로컬 포트를 변경하면 클라이언트가 설정을 생성합니다. 생성된 파일을 직접 동시에 수정하지 마세요.

{
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ]
}

구독 변환으로 코어 기능이 추가되지는 않습니다

구독 변환은 기존 정보를 다른 형식으로 표현하는 기능이지, 지원하지 않는 기능을 클라이언트에 새로 구현하는 기능이 아닙니다. 대상 형식이 REALITY에 필요한 매개변수를 담지 못하면 노드 목록은 정상적으로 표시되어도 핸드셰이크가 실패할 수 있습니다. 원본 설정과 대조해 프로토콜, 보안 계층, 서버 이름, 공개 키 매개변수와 shortId가 유지됐는지 확인하세요. 원본에 필드가 없다면 변환 서비스도 올바른 값을 추측할 수 없으므로 설정 제공자에게 완전한 정보를 요청해야 합니다.

구독 주소에는 계정 설정에 접근할 수 있는 식별 정보가 포함될 수 있으므로 민감한 정보로 취급하세요. 주소를 타사 변환 서비스에 제출하면 해당 서비스가 구독 내용에 접근할 수 있습니다. 화면을 공유할 때도 링크, QR 코드와 인증 필드를 가리세요. 업데이트에 실패하면 먼저 유효 기간과 응답 내용을 확인한 뒤 직접 연결로 실패했는지 프록시를 통해 업데이트하다 실패했는지 구분하세요. 점검 순서는 구독 파싱 실패 자가 점검에서, 변환 범위는 구독 변환 자주 묻는 질문에서 확인할 수 있습니다.

사용 환경에 맞게 선택하고 연결을 검증하세요

사용 가능한 구독이 있다면 호환성부터 확인하세요

이미 유효한 구독을 갖고 있다면 구독의 매개변수를 온전히 표현할 수 있는 클라이언트를 사용하는 것이 가장 실용적입니다. 데스크톱에서는 v2rayN을 우선 선택하고 시스템과 프로세서에 맞는 설치 파일을 고르세요. Android에서는 필요한 코어에 따라 v2rayNG를 선택하고, V2Fly용 기존 설정이라면 v2flyNG를 검토할 수 있습니다. 프로토콜 우선순위를 먼저 정한 뒤 모든 노드를 앞에 있는 이름으로 억지로 바꾸지 마세요. 사용할 수 있는 조합은 서버가 이미 정해 놓았습니다. 클라이언트의 역할은 설정을 정확히 재현하는 것이지 새로운 조합을 만들어 내는 것이 아닙니다.

처음 연결을 확인할 때는 가장 단순한 경로를 유지하세요. 구독을 가져오고, 매개변수가 완전한 노드 하나를 선택한 뒤 시스템 프록시를 지원하는 앱으로 접속을 확인합니다. 기본 연결이 확인된 다음 분기 규칙, TUN이나 다른 기능을 추가하세요. 모든 설정을 동시에 켜면 실패 원인이 프로토콜, DNS, 규칙 또는 권한 중 무엇인지 판단하기 어렵습니다. 빠른 작업 순서는 구독 가져오기 안내에서, Android의 자세한 과정은 v2rayNG 구독 가져오기에서 확인하세요.

모바일 환경과 복잡한 앱은 따로 점검하세요

모바일 기기는 네트워크를 자주 전환하므로 한 번의 연결 테스트보다 재연결, 백그라운드 실행과 시스템 배터리 관리에 주목해야 합니다. 절전 모드 이후 연결이 끊긴다면 시스템이 클라이언트를 제한하는지, 네트워크 전환 뒤 연결이 다시 수립되는지, 진입점 도메인을 다시 조회할 수 있는지 확인하세요. 배터리를 아껴야 하는 환경에서는 특정 프로토콜 이름을 고집하기보다 불필요한 연결 확인과 실패 후 재시도를 줄이는 편이 효과적입니다. 구독 업데이트 간격은 적절하게 설정하고 v2rayNG 구독 업데이트 안내를 참고하세요.

데스크톱에서 시스템 프록시를 따르지 않는 프로그램이 있다면 그때 TUN을 고려하고 시스템 권한, DNS와 라우팅 루프도 함께 확인하세요. 가상 네트워크 인터페이스를 켰다고 해서 모든 트래픽을 원격 서버로 보내야 하는 것은 아니며 로컬 네트워크 접근을 무시해도 되는 것도 아닙니다. 원격 업무, 로컬 네트워크 기기와 로컬 서비스에는 직접 연결 경로가 필요할 수 있습니다. 라우터나 보조 라우터 배포는 별도의 실행 환경이므로 프로세서 아키텍처와 설정 유지 관리까지 고려해야 합니다. 자세한 내용은 라우터에서 Xray를 실행하는 배포 개요를 참고하세요.

계층별로 확인해 문제 범위를 좁히세요

연결 검증은 네 단계로 나눌 수 있습니다. 첫째, 클라이언트 코어가 정상적으로 시작되고 로컬 진입점에 포트 충돌이 없는지 확인합니다. 둘째, 서버 도메인이 조회되고 진입점에 연결할 수 있는지 확인합니다. 셋째, 프로토콜 인증과 보안 계층 핸드셰이크를 점검합니다. 넷째, 대상 앱의 DNS, 라우팅과 전송 요구 사항을 확인합니다. 각 단계에서 관찰 가능한 정보를 기준으로 판단하세요. 포트에 연결할 수 있어도 인증이 성공한 것은 아니며, 인증에 성공해도 대상 웹사이트에 접속할 수 있다는 뜻은 아닙니다. 브라우저가 동작해도 다른 앱의 트래픽이 프록시로 들어온다고 볼 수 없습니다.

구성을 비교할 때는 클라이언트, 코어, 프로토콜 조합과 트래픽 처리 방식을 기록하고 한 번에 변수 하나만 바꾸세요. 특정 노드에서만 문제가 생기면 서버 매개변수와 원격 상태를 확인하고, 특정 앱에서만 발생하면 프록시 지원 여부와 라우팅을 확인하세요. 네트워크를 바꾼 뒤에만 문제가 나타난다면 도메인 조회, 재연결과 네트워크 제한을 점검하세요. 최종 선택은 매개변수를 관리하기 쉽고, 필요한 앱이 안정적으로 작동하며, 기기 부담이 감당 가능한지를 기준으로 하세요. 배포 환경을 무시한 채 프로토콜에 일률적인 순위를 매길 수는 없습니다. 낯선 설정을 반복 적용하기보다 복구할 수 있는 설정을 보관하는 편이 실용적입니다.