프록시 프로토콜과코어 선택

설정 계층: 프로토콜만으로 연결이 완성되지는 않습니다

노드 설정을 네 가지 항목으로 나누기

클라이언트의 노드는 단순한 프로토콜 이름이 아니라 여러 연결 설정이 함께 작동하는 구성입니다. 첫째, 서버 주소와 포트는 트래픽을 보낼 위치를 정합니다. 둘째, 프록시 프로토콜과 인증 정보는 양쪽이 요청을 식별하는 방식을 정합니다. 셋째, 전송 방식은 프록시 데이터를 전달하는 방법을 정합니다. 넷째, 보안 계층은 연결을 암호화하고 상대를 확인하는 방법을 정합니다. 구독은 이 설정을 묶어 가져오므로 직접 입력할 필요를 줄여 주지만, 계층 간 의존 관계까지 없애지는 않습니다.

예를 들어 VLESS는 여러 전송 방식과 함께 사용할 수 있으며 TLS 또는 REALITY와 조합할 수도 있습니다. ‘VLESS’라는 이름만으로 어떤 보안 계층을 사용하는지 알 수 없고, ‘TCP’라고 해서 그 안의 프록시 프로토콜을 판단할 수도 없습니다. 클라이언트에 따라 전송 항목을 ‘전송 프로토콜’, ‘네트워크’, ‘전송 방식’ 등으로 표시하지만, 화면 이름이 달라도 상단의 프로토콜 유형과 혼동해서는 안 됩니다. 문제를 확인할 때는 원래 설정을 보존하고 계층별로 점검하는 편이 드롭다운을 무작정 바꾸는 것보다 원인을 찾기 쉽습니다.

화면 설정에서 실제 연결까지 추적하기

전송 방식마다 별도의 매개변수가 추가됩니다. WebSocket에는 경로와 Host가, gRPC에는 서비스 이름이 자주 사용됩니다. 이런 항목은 메모가 아니며 도메인 모양만 보고 값을 추측해서도 안 됩니다. 서버 주소는 기본 연결을 설정하는 데 쓰이고, Host는 상위 요청을 분기할 수 있으며, SNI는 TLS 핸드셰이크에서 서버 이름을 알리는 데 사용됩니다. 세 값이 같을 때도 있고 배포 방식에 따라 다를 때도 있습니다. 구독에 지정된 값은 빠짐없이 그대로 유지하고, 모두 서버 주소로 통일하는 대신 항목별로 확인하세요.

시스템 프록시와 라우팅 규칙은 별도의 계층입니다. 시스템 프록시는 시스템 설정을 따르는 앱의 요청을 클라이언트로 보낼지 결정하고, 라우팅 규칙은 클라이언트에 들어온 요청을 직접 연결할지 프록시로 보낼지 결정합니다. 노드 설정이 올바르더라도 모든 앱이 해당 노드를 사용하는 것은 아니며, 시스템 프록시가 켜져 있어도 라우팅 규칙이 요청을 현재 노드로 보내는 것은 아닙니다. 연결 문제는 먼저 요청이 클라이언트에 들어오는지 확인하고, 그다음 프로토콜 핸드셰이크가 성공하는지 살펴보세요. 앱의 접속 경로 문제를 프로토콜 비호환으로 오인하지 않는 것이 중요합니다.

설정을 잘못 바꾸지 않고 오류 읽기

로그의 ‘연결 거부’는 먼저 접속 주소와 서버의 수신 대기 상태를 확인해야 하는 경우가 많습니다. 이름 확인에 실패하면 DNS를, 인증서 오류가 나면 보안 계층을, 인증 실패가 나면 프로토콜 항목을 확인하세요. 오류와 원인이 항상 일대일로 대응하는 것은 아니지만, 첫 점검 방향을 정하는 데 도움이 됩니다. 마지막 재시도 안내 한 줄만 잘라내지 말고 같은 연결 시도 전후의 로그를 함께 보관하세요. 컴퓨터와 휴대전화의 결과도 따로 기록하는 것이 좋습니다. 기기마다 코어가 다르면 같은 이름의 노드도 실제 처리 경로가 다를 수 있습니다.

도움을 요청할 때는 클라이언트 이름, 코어 이름, 프로토콜 유형, 전송 방식, 보안 계층과 민감 정보를 가린 오류 내용을 제공할 수 있습니다. 사용자 식별자, 비밀번호, 전체 구독 주소, 공유 QR 코드는 공개하지 마세요. 노드 별칭은 자유롭게 붙일 수 있지만, 실제 설정을 증명하지는 않습니다. 편집 화면의 설정 항목과 코어가 구성을 받아들인 뒤의 실행 결과가 중요합니다. 다음 장에서도 같은 방식으로 계층을 나누어 프로토콜 자체를 먼저 살펴본 뒤 전송, 보안, 클라이언트 구현을 설명합니다.

VMess와 VLESS: 인증 및 암호화 방식 비교

VMess의 설계 배경과 기존 설정

VMess는 Project V 생태계 초기에 중요한 역할을 한 프록시 프로토콜로, 사용자 인증과 요청 정보 캡슐화, 데이터 보호를 자체 설계에 포함합니다. 클라이언트와 서버는 합의된 사용자 식별자로 연결을 확인하며, 여러 전송 방식과 조합할 수 있습니다. 오랫동안 사용되면서 설정 자료와 구독 예시가 많이 축적됐지만, 서로 다른 구현 시기의 내용이 섞여 있습니다. 오래된 가이드를 참고할 때 항목 이름이 같다는 이유만으로 인증 매개변수가 현재 클라이언트에서도 그대로 적용된다고 가정하지 마세요.

현재 VMess 설정에서는 AEAD 인증 방식을 확인해야 합니다. 구형 설정에 나오는 추가 식별 필드는 과거 호환성을 위한 항목이므로, 오래된 문서를 그대로 따라 하려고 임의의 0이 아닌 값을 넣지 마세요. 사용자 식별자는 서버와 일치해야 하며 시스템 시간도 정확해야 합니다. 인증에 실패하면 구독이 만료되지 않았는지, 식별자가 빠짐없이 입력됐는지 먼저 확인한 다음 시간 동기화와 클라이언트 호환성을 살펴보세요. 전송 방식을 바꾸는 것으로 인증 매개변수 불일치가 해결되는 경우는 드뭅니다.

VMess 자체의 데이터 암호화 옵션과 TLS는 같은 설정이 아닙니다. 전자는 프록시 프로토콜 내부에, 후자는 연결 바깥쪽의 보안 계층에 속합니다. 화면에 ‘자동’이 표시되면 보통 구현이 기기 기능에 맞는 처리 방식을 선택한다는 뜻이지, 서버가 어떤 조합이든 허용한다는 뜻은 아닙니다. 기존 구독이 정상 작동한다면 암호화 계층을 하나 줄이려고 현재 설정을 바로 끄지 마세요. 리소스 부담을 최적화하려면 먼저 서버가 지원하는 전체 설정을 확인한 뒤 같은 조건에서 비교해야 합니다.

VLESS에서 외부 보안 계층이 중요한 이유

VLESS는 간결한 인증과 요청 표현에 중점을 두며 VMess와 같은 내장 데이터 암호화 기능은 제공하지 않습니다. 따라서 VLESS의 보안을 설명할 때는 어떤 보안 계층과 조합했는지도 함께 확인해야 합니다. 인터넷에서 사용할 때는 일반적으로 서버가 명시적으로 지원하는 TLS 또는 REALITY 구성을 사용합니다. 프로토콜 이름이 간결하다는 이유만으로 본질적으로 더 안전하거나 빠르다고 단정하면 외부 보안 계층, 전송 방식, 서버 구현의 영향을 놓치게 됩니다.

VLESS 설정의 사용자 식별자, 암호화 항목, 흐름 제어 항목은 각각 역할이 다릅니다. 흔히 사용하는 암호화 값은 none이며, 이는 VLESS 프로토콜 내부의 암호화 선택을 나타낼 뿐 전체 연결에 TLS 보호가 없다는 뜻은 아닙니다. 흐름 제어는 특정 구현에 추가되는 기능입니다. 예를 들어 서버에서 Vision 흐름 제어를 요구하면 클라이언트와 코어 모두 이를 지원해야 합니다. 흐름 제어를 범용 속도 향상 버튼처럼 취급하지 말고, 모든 전송 방식에 같은 값을 일괄 적용해서도 안 됩니다.

두 방식 중 실제로 선택하는 방법

기존 VMess 설정이 안정적으로 작동하고 호환성이나 성능 문제가 없다면 그대로 사용하는 것이 합리적입니다. 새 설정에서 VLESS와 최신 보안 계층 조합을 명시적으로 제공한다면 현재 코어가 전체 구성을 지원하는지 먼저 확인한 뒤 도입을 검토하세요. 비교할 때는 서버, 전송 경로, 테스트 작업을 최대한 동일하게 맞춰야 합니다. 그렇지 않으면 차이가 프로토콜이 아닌 서로 다른 출구에서 비롯될 수 있습니다. 출처가 다른 두 노드를 비교해 특정 프로토콜이 항상 더 빠르다고 결론 내려서는 안 됩니다.

전환할 때는 구독과 기기 간 호환성도 고려해야 합니다. 컴퓨터에서 특정 VLESS 조합을 가져올 수 있다고 해서 휴대전화의 구형 파서가 모든 항목을 인식하는 것은 아닙니다. 먼저 한 기기에 기존 노드를 남겨 두고 새 설정을 추가한 뒤 인증, 도메인 접속, 필요한 앱이 모두 정상인지 확인하고 다른 기기로 확대하세요. 특정 클라이언트에서만 실패한다면 사용자 식별자를 다시 만들기보다 흐름 제어, 보안 계층, 지문 항목을 비교하세요. 결국 중요한 것은 양쪽이 전체 설정을 올바르게 처리할 수 있는지입니다.

Trojan과 SS: 서로 다른 보안 캡슐화 방식

Trojan이 TLS에 의존하는 방식

Trojan의 기본 방식은 TLS로 보호되는 연결 안에서 프록시 요청을 처리하고 비밀번호로 프록시 인증을 수행하는 것입니다. 암호화 기능을 프로토콜 내부에 두는 설계보다 성숙한 TLS 구현에 더 직접적으로 의존합니다. 따라서 Trojan 노드를 점검할 때 인증서 이름, 신뢰 체인, 시스템 시간은 부가적인 세부 사항이 아니라 연결 성립의 핵심 조건입니다. 비밀번호가 맞더라도 TLS 핸드셰이크가 성공했다는 뜻은 아닙니다.

서버 주소와 인증서에 연결된 이름은 서로 다를 수 있습니다. 서버가 특정 SNI를 요구한다면 제공된 이름을 클라이언트에 입력해야 합니다. 신뢰할 수 있는 인증서를 사용하는 경우 시스템이 정상적인 인증서 신뢰 관계를 구성할 수 있어야 합니다. 인증서 오류가 났을 때 ‘인증서 검증 건너뛰기’를 켜면 오류 메시지가 달라질 수 있지만, 중요한 신원 확인도 함께 해제되므로 일반적인 해결책으로 사용해서는 안 됩니다. 먼저 이름, 시스템 시간, 인증서 체인, 구독이 올바른 서버를 가리키는지 확인하세요.

Trojan은 여러 전송 방식과 조합할 수 있으므로 ‘Trojan 노드’에 주소, 포트, 비밀번호만 있는 것은 아닙니다. 구독에 경로, Host, 서비스 이름이 포함되어 있다면 이 항목도 유지해야 합니다. 클라이언트에 프로토콜 이름은 표시되지만 추가 매개변수가 누락되면 가져오기는 성공하고 연결은 실패할 수 있습니다. 호환성을 확인할 때는 지원 목록에 Trojan이 있는지만 보지 말고 구체적인 조합을 확인하세요. 핸드셰이크 문제는 TLS 및 인증서 오류 문제 해결을 참고해 항목별로 점검할 수 있습니다.

SS의 암호화 방식이 호환 범위를 결정합니다

SS는 Shadowsocks를 흔히 줄여 부르는 이름으로, 비교적 간단한 암호화 프록시 전달을 지향합니다. 일반적으로 서버 주소, 포트, 비밀번호, 암호화 방식이 필요합니다. 암호화 방식은 프로토콜을 해석하는 데 필요한 값이지 임의로 바꿀 수 있는 로컬 설정이 아닙니다. 서버가 사용하는 방식에 맞는 구현을 클라이언트에서 선택해야 합니다. 비밀번호가 같더라도 방식이 다르면 통신할 수 없습니다. 구독에 표시된 방식 문자열은 하이픈과 숫자를 포함해 그대로 유지하고, 비슷해 보이는 이름을 기억에 의존해 고르지 마세요.

흔한 설정에는 AEAD 계열 방식이 있으며, 독립적인 키 및 세션 설계를 사용하는 최신 방식도 있습니다. 계열에 따라 비밀번호나 키 재료의 요구 사항이 다를 수 있으므로 한 방식의 일반 비밀번호를 다른 방식이 요구하는 인코딩된 키로 간주해서는 안 됩니다. 구형 방식은 현재 구현에서 제거되거나 제한되었을 수도 있습니다. 클라이언트에서 SS 편집 창을 열 수 있다는 사실은 일부 SS 설정을 지원한다는 뜻일 뿐, 과거의 모든 방식과 확장 기능을 지원한다는 뜻은 아닙니다.

전송 확장도 확인해야 합니다. 일부 SS 공유 링크에는 추가 확장 매개변수가 포함되지만, 이 사이트에서 소개하는 클라이언트와 선택한 코어가 해당 확장을 구현하지 않을 수 있습니다. 이런 경우 매개변수를 삭제하고 기능이 동일하다고 가정하지 말고, 설정 제공자에게 직접 호환되는 연결 구성을 요청하세요. 매개변수를 지우면 화면의 오류는 사라져도 연결에 필요한 캡슐화 방식이 달라질 수 있습니다. 가져온 설정을 원본과 항목별로 비교하고 특히 암호화 방식과 추가 전송 설명을 확인하세요.

설정이 간단하다고 부담이 자동으로 줄어드는 것은 아닙니다

설정 관점에서 기본 SS 구성은 항목이 적어 서버 방식이 명확하고 표준 프록시 전달만 필요한 경우에 적합합니다. Trojan은 TLS 설정이 정상이고 인증서를 올바르게 관리할 수 있는 서버에 적합합니다. 두 방식 모두 일상적인 웹 접속에 사용할 수 있지만 특정 앱에 적합한지는 UDP 지원, 클라이언트 연결 방식, 라우팅 설정에 따라 달라집니다. ‘설정 항목이 적다’고 해서 ‘휴대전화 배터리를 덜 쓴다’고 단정하지 마세요. 배터리 소모에는 연결 수와 백그라운드 동작이 더 크게 작용하는 경우가 많습니다.

선택하기 전에 실시간 통화, 게임 등 UDP에 의존하는 작업이 필요한지 확인하고, 클라이언트·코어·서버·전송 경로가 모두 해당 트래픽을 지원하는지 점검하세요. 웹페이지가 열린다는 것만으로 UDP가 통과했다고 볼 수 없습니다. 기존 SS 설정으로 필요한 작업을 할 수 있다면 다른 프로토콜 이름이 더 최신이라는 이유만으로 전환할 필요는 없습니다. 원하는 조합이 현재 코어에서 지원되지 않는 기능에 의존한다면 로컬 항목을 계속 수정하는 것보다 호환되는 설정을 받는 편이 효과적입니다.

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

TLS는 연결 상대를 검증합니다

TLS는 데이터를 바로 읽을 수 없게 만드는 데 그치지 않고 연결 상대의 신원을 인증합니다. 정상적인 검증에는 인증서 유효 기간, 인증서 이름 일치 여부, 발급 체인의 신뢰 여부 등이 포함됩니다. 시스템 시간이 맞지 않으면 정상 인증서가 아직 유효하지 않거나 만료된 것으로 보일 수 있고, 서버 이름을 잘못 입력하면 이름 불일치 오류가 발생합니다. 이런 문제를 해결할 때는 오류를 무시하는 옵션으로 모든 검사를 덮기보다 시간과 설정 출처부터 바로잡으세요.

SNI는 핸드셰이크 중 요청할 서버 이름을 전달하며, 인증서 검증에도 올바른 이름이 필요합니다. 그래픽 클라이언트에서는 ‘서버 이름’, ‘SNI’ 또는 관련 보안 설정으로 표시될 수 있습니다. 연결 주소가 도메인이나 IP라고 해서 SNI도 같은 값으로 바꿔야 하는 것은 아닙니다. 서버가 하나의 접속 지점으로 여러 서비스를 제공한다면 이름에 따라 요청이 분기될 수도 있습니다. 구독에 지정된 값을 사용하고 주소 입력란과 보안 계층의 이름 입력란을 기계적으로 같은 값으로 맞추지 마세요.

ALPN은 상위 프로토콜을 협상하고, 지문 설정은 클라이언트 핸드셰이크의 구체적인 동작에 영향을 줍니다. 어느 쪽도 범용 속도 향상 매개변수가 아닙니다. 서버가 특정 조합을 요구하면 동일하게 설정하고, 요구하지 않는다면 다른 노드의 값을 복사하지 않는 편이 좋습니다. 일부 클라이언트는 미리 정해진 이름으로 핸드셰이크 지문을 표시하며, 지원 범위는 구현에 따라 다릅니다. 이름을 저장할 수 있다고 해서 현재 코어가 실행할 수 있다는 뜻은 아닙니다. 시작에 실패하면 설정 로드 오류를, 핸드셰이크에 실패하면 서버와의 협상 관계를 확인하세요.

REALITY는 별도의 프록시 프로토콜이 아닙니다

REALITY는 보안 계층 방식이므로 VMess, VLESS, Trojan과 같은 프록시 프로토콜과 같은 계층에 놓고 서로 대체할 수 없습니다. 흔히 VLESS와 조합하지만, 어떤 조합을 지원하는지는 사용하는 코어의 구현에 따라 다릅니다. 노드를 선택할 때는 ‘프록시 프로토콜, 전송, 흐름 제어, 보안 계층’을 하나의 구성으로 읽어야 합니다. 노드 별칭에 REALITY라고 적혀 있다는 사실만으로 필요한 모든 항목을 알 수 없으며 다른 클라이언트와의 호환성을 판단할 수도 없습니다.

REALITY 클라이언트 매개변수에는 일반적으로 서버 이름, 서버가 제공한 공개 키 자료 또는 이에 대응하는 인증 항목, 짧은 ID, 핸드셰이크 지문이 포함됩니다. 클라이언트와 코어가 발전하면서 항목 이름이 달라질 수 있으므로 현재 설정 안내에 맞춰 대응시켜야 합니다. 짧은 ID는 노드 별칭이 아니며 공개 키 자료를 일반 비밀번호로 대신할 수도 없습니다. 값이 빠졌다면 설정 제공자에게 다시 요청하세요. 서버 개인 키가 일반 사용자용 클라이언트 구독에 포함되어서는 안 되며 문제 해결용 스크린샷으로 공개해서도 안 됩니다.

최소한의 변경으로 보안 계층 문제 해결

먼저 구독을 새로고침한 다음 실패한 노드의 편집 창에서 보안 계층 유형을 확인하세요. REALITY 설정이어야 하는데 일반 TLS로 가져왔다면 서버 이름을 수동으로 추가하고 끝내기보다 파서 호환성 문제를 먼저 의심해야 합니다. 이어서 지문, 인증 자료, 짧은 ID, 흐름 제어를 확인하세요. 명확한 근거가 있는 항목만 한 번에 하나씩 바꾸고 원래 설정도 보존하세요. 여러 매개변수를 동시에 바꾸면 연결에 성공하더라도 원인을 알기 어렵고 다른 기기에서 재현하기도 힘듭니다.

같은 구독이 컴퓨터에서는 작동하고 휴대전화에서는 작동하지 않는다면 코어 지원과 항목 보존 여부를 집중적으로 비교하세요. 모든 매개변수가 일치하고 구현 지원도 확인된 뒤에 네트워크 접속 환경 차이를 살펴보면 됩니다. REALITY는 모든 연결 오류를 해결하는 만능 설정이 아니며 TLS도 본질적으로 오래된 설정을 뜻하지 않습니다. 유지 관리와 검증이 가능하고 실제 배포 환경에 맞는 구성이 보안 계층 선택의 기준입니다.

성능과 배터리: 초기 응답, 전송량, 백그라운드 부담 구분하기

연결 속도는 하나의 지표가 아닙니다

사용자가 체감하는 ‘속도’에는 적어도 세 가지가 있습니다. 연결을 시작해 첫 정상 응답을 받을 때까지 걸리는 시간, 지속 전송 중 처리량, 장시간 사용 시 연결이 자주 끊기는지 여부입니다. 첫 번째는 DNS 조회, 네트워크 왕복 시간, 핸드셰이크의 영향을 받습니다. 두 번째는 회선 대역폭, 혼잡, 서버 부하, 로컬 처리 성능이 함께 좌우합니다. 간단한 테스트에서 결과가 좋은 노드가 대용량 파일도 더 빨리 전송하거나 실시간 통화 중 변동이 더 적다고 볼 수는 없습니다.

프로토콜 설계는 인증, 캡슐화, 암호화에 드는 부담을 바꾸지만 전체 소요 시간에서 차지하는 비율은 일정하지 않습니다. 네트워크 왕복 시간이 길다면 로컬 암호화 한 번보다 연결 과정의 추가 왕복이 더 큰 영향을 줄 수 있습니다. 반대로 기기 처리 성능이 낮으면 대용량 전송에서 암호화와 메모리 복사가 병목이 될 수 있습니다. 따라서 모든 기기에 영구적으로 적용할 수 있는 프로토콜 속도 순위는 없습니다. 회선과 서버 차이를 먼저 배제한 뒤 실제 작업에 맞춰 전체 구성을 비교하는 것이 더 정확합니다.

전송 방식도 성능에 영향을 줍니다. WebSocket은 관련 캡슐화와 요청 처리가 추가되고, gRPC는 자체 전송과 협상 과정이 필요하며, 직접 TCP 조합은 대체로 구조가 간단합니다. 하지만 중간 접속 인프라가 특정 전송 방식만 지원한다면 추가 캡슐화는 배포 조건의 일부이지 임의로 없앨 낭비가 아닙니다. 최적화에 앞서 배포 제약을 확인하세요. 서버에서 경로와 상위 계층 전달을 요구하는데 클라이언트를 직접 TCP로 바꾸면 연결이 실패할 수 있습니다.

전체 작업 부하를 기준으로 리소스 사용량 확인하기

CPU 사용량은 암호화뿐 아니라 로그, 트래픽 통계, 규칙 매칭, 다수의 짧은 연결에서 발생할 수 있습니다. 하드웨어마다 암호화 알고리즘 지원이 달라 같은 알고리즘도 기기 두 대에서 비용이 같지 않을 수 있습니다. 메모리 사용량은 연결 버퍼, DNS 캐시, 규칙 데이터, 그래픽 인터페이스의 영향을 받습니다. 클라이언트를 비교할 때는 인터페이스 프로세스와 코어 프로세스를 구분하세요. 작업 관리자에서 한 번 확인한 전체 사용량을 프록시 프로토콜의 고정 부담으로 간주해서는 안 됩니다.

연결 재사용은 반복적인 연결 설정 비용을 줄일 수 있지만 여러 요청이 같은 연결을 공유하게 해 특정 패킷 손실 상황에서는 서로 영향을 줄 수도 있습니다. 일부 프로토콜이나 흐름 제어 조합은 재사용에 특별한 제약이 있으므로 ‘재사용 켜기’를 일괄적인 성능 개선 방법으로 권할 수 없습니다. 설정 제공자의 요구와 코어 지원을 먼저 확인한 뒤 여러 탭을 연 웹페이지, 지속 다운로드, 실제 앱으로 각각 검증하세요. 한 가지 테스트만 개선하고 일상적인 연결이 더 자주 멈춘다면 효과적인 최적화가 아닙니다.

모바일 배터리는 네트워크 동작과 밀접하게 관련됩니다

휴대전화 배터리 소모는 패킷마다 드는 암호화 비용만으로 결정되지 않습니다. 무선 네트워크 깨우기, 잦은 재연결, 과도한 연결 유지 신호, 지속적인 속도 테스트, 다수의 백그라운드 도메인 요청도 배터리 소모를 키울 수 있습니다. 신호가 약하면 네트워크 자체의 부담도 증가합니다. 배터리를 아끼려면 불필요한 자동 테스트와 재시도를 줄이고 구독 갱신 간격이 적절한지 확인한 뒤 프로토콜을 고려하세요. 연결을 항상 활성 상태로 유지하도록 설정해 과도한 연결 유지 신호를 보내지 마세요.

Android의 시스템 배터리 관리가 백그라운드에서 클라이언트를 제한하면 노드 연결이 끊긴 것처럼 보여도 실제로는 프로세스나 네트워크 활동이 일시 중지된 것일 수 있습니다. 기기의 배터리 설정에서 v2rayNG 또는 v2flyNG의 백그라운드 실행 권한을 확인한 뒤 중단이 계속되는지 살펴보세요. 반대로 모든 앱의 제한을 해제할 필요는 없습니다. 프록시 연결을 담당하는 클라이언트만 필요한 방식으로 실행되게 한 다음, 비슷한 사용량을 기준으로 하루 동안 배터리 변화를 비교하세요.

실제로 비교할 때는 비슷한 네트워크 환경에서 같은 작업을 선택하고 처음 열 때, 계속 사용할 때, 대기 후 다시 연결할 때의 결과를 각각 기록하세요. 한 번에 주요 변수 하나만 바꾸고 되돌릴 수 있도록 원래 설정을 보존합니다. 테스트 전에는 일괄 속도 측정을 끄고 다른 다운로드를 줄이며 라우팅이나 DNS를 함께 바꾸지 마세요. 두 구성의 서버가 다르다면 결과를 ‘현재 환경에서 이 두 설정을 사용했을 때의 차이’로 표현하고, 특정 프로토콜이 언제나 더 절전적이거나 안정적이라고 일반화하지 마세요.

V2Fly와 Xray: 코어 종류와 설정 호환 범위

클라이언트 인터페이스와 프록시 코어의 역할

Project V는 이런 도구 생태계를 이해하는 배경이며, V2Fly와 Xray는 관련 프록시 코어 프로젝트입니다. 코어는 설정을 해석하고 프록시 연결을 설정하며 라우팅을 실행하고 트래픽을 처리합니다. 그래픽 클라이언트는 구독을 관리하고 설정을 편집하며 코어를 실행하고 상태를 표시합니다. 둘은 같은 계층이 아닙니다. 인터페이스에 특정 프로토콜 이름이 표시되더라도 현재 실행 중인 코어가 관련 기능을 모두 갖췄거나 생성된 설정을 정상적으로 받아들였다는 뜻은 아닙니다.

v2rayN은 이 사이트에서 우선 추천하는 데스크톱 클라이언트로 Windows, macOS, Linux를 지원합니다. 사용할 코어는 실제 설치 패키지와 인터페이스에서 제공하는 기능을 기준으로 선택해야 합니다. Android에서는 v2rayNG가 주로 Xray 코어를 사용하며 v2flyNG는 V2Fly 코어를 사용하는 대안입니다. 세 클라이언트는 메뉴와 편집 가능한 항목이 서로 다르므로 컴퓨터 화면의 항목 위치를 휴대전화 조작 경로로 그대로 적용할 수 없습니다. 설치 파일은 4개 플랫폼용 클라이언트 설치 파일을 참고하세요.

공통된 배경이 설정의 완전한 호환성을 뜻하지는 않습니다

V2Fly와 Xray는 기술적 기반을 일부 공유하며 기본 설정에서도 인바운드, 아웃바운드, 라우팅, DNS처럼 비슷한 개념을 볼 수 있습니다. 하지만 프로젝트가 각자 발전하면서 프로토콜 확장, 전송 구현, 기본 매개변수, 항목의 의미가 달라질 수 있습니다. 특히 REALITY, 특정 VLESS 흐름 제어, 기타 확장을 사용할 때는 대상 코어가 명시적으로 지원하는지 확인하세요. 두 파일이 모두 JSON이라는 이유만으로 그대로 서로 바꿔 쓸 수 있다고 생각해서는 안 됩니다.

JSON 문법이 올바르다는 것은 괄호, 쉼표, 문자열이 형식에 맞는다는 뜻일 뿐입니다. 코어는 항목이 유효한지, 조합이 허용되는지, 필요한 구현이 있는지도 확인해야 합니다. 다음은 Xray 설정의 완전한 outbound 객체로, 프로토콜 계층의 위치를 설명하기 위한 예입니다. 이는 직접 연결 아웃바운드이지 프록시 노드나 단독 실행 가능한 전체 클라이언트 설정이 아닙니다. outbounds 배열에 넣더라도 나머지 설정을 함께 구성해야 합니다.

{
  "tag": "direct",
  "protocol": "freedom",
  "settings": {}
}

이 객체에서 protocol은 아웃바운드 동작을 설명하고 tag는 라우팅에서 참조하는 식별자입니다. 식별자만 바꿔서는 프로토콜이 바뀌지 않으며, 라우팅이 이전 식별자를 참조하면 설정이 작동하지 않을 수 있습니다. 마찬가지로 프록시 아웃바운드의 전송 및 보안 항목은 해당 코어의 구조를 따라야 합니다. 그래픽 클라이언트는 보통 이런 설정을 대신 생성하므로 일반 구독 사용자는 서로 다른 코어의 설정 조각을 섞어 복사하기보다 클라이언트에서 관리하는 것이 좋습니다.

코어를 바꾸기 전에 전환 범위를 정하세요

코어를 전환할 때는 먼저 구독 그룹과 사용자 설정을 백업한 다음, 작동 여부를 알고 있는 노드 하나로 제한해 시험하세요. 프로토콜, 보안 계층, 전송, 흐름 제어, DNS, 라우팅, UDP 요구 사항을 확인하고 대상 코어에서 모두 설정할 수 있는지 점검합니다. 전환이 끝난 뒤 기본 화면에 실행 중이라고 표시되는지만 보지 말고, 로그에서 미지원 항목, 규칙 로드 실패, 아웃바운드 초기화 오류가 있는지 확인하세요. 코어 프로세스가 실행 중이라고 모든 기능이 정상이라는 뜻은 아닙니다.

코어마다 DNS와 라우팅을 표현하는 방식에는 미묘한 차이가 있을 수 있습니다. 도메인 조회 정책, 규칙 순서, 데이터 파일 요구 사항이 서로 일대일로 대응하지 않을 수 있고, 클라이언트가 일부 설정을 변환하거나 프리셋을 다시 선택하도록 요구할 수도 있습니다. 전환 뒤에는 프록시를 사용해야 하는 대상과 직접 연결해야 하는 대상을 각각 확인한 다음 도메인 조회와 필요한 UDP 앱도 점검하세요. 웹페이지 하나를 열어 본 것만으로 전환이 완료됐다고 판단하면 분기 오류나 백그라운드 앱 문제를 놓칠 수 있습니다.

기능 하나만 필요하다는 이유로 여러 코어를 자주 오가지는 마세요. 주요 사용 환경을 정하고 필요한 범위를 완전히 지원하는 안정적인 설정을 선택한 뒤 되돌릴 수 있는 구성을 보관하세요. 노드가 Xray의 특정 확장 기능에 의존한다면 해당 기능을 명시적으로 지원하는 클라이언트 경로를 우선 사용하세요. 기존 V2Fly 설정이 장기간 요구 사항을 충족한다면 계속 사용해도 됩니다. 코어 선택의 기준은 기능과 설정의 일치 여부이지 프로젝트 이름이 더 최신처럼 들리는지가 아닙니다.

구독 형식: 가져오기에 성공해도 항목이 온전한 것은 아닙니다

구독 주소, 공유 링크, 설정 파일 구분하기

구독 주소는 설정 묶음을 가져오는 경로이고, 공유 링크는 보통 단일 노드를 설명합니다. 설정 파일에는 노드 외에 인바운드, 라우팅, DNS 설정이 포함될 수도 있습니다. 세 가지 모두 설정 정보를 옮기는 데 사용할 수 있지만 같은 데이터는 아닙니다. 구독 주소를 단일 노드 링크처럼 가져오거나 전체 설정 파일을 공유 링크 입력란에 붙여 넣으면 결과가 비어 있거나 파싱 오류가 발생할 수 있습니다. 먼저 자료의 종류를 확인한 뒤 클라이언트에서 해당하는 가져오기 메뉴를 선택하세요.

흔한 공유 링크는 vmess://, vless://, trojan://, ss:// 등의 접두사로 시작합니다. 접두사는 파서가 사용할 규칙 종류를 알려 주지만 모든 확장 매개변수가 표준화되어 있다는 뜻은 아닙니다. VMess 링크에는 인코딩된 구조화 데이터가 자주 사용되고, VLESS와 Trojan은 쿼리 매개변수로 전송 및 보안 설정을 나타내는 경우가 많습니다. SS에도 여러 인코딩 방식이 있습니다. 한 도구가 링크를 인식한다고 해서 모든 클라이언트가 똑같이 파싱하는 것은 아닙니다.

구독 서비스는 인코딩된 여러 링크를 반환할 수도 있고 특정 클라이언트 전용 형식을 반환할 수도 있습니다. 브라우저에서 긴 문자열이 보인다는 이유만으로 현재 클라이언트에 맞는 내용이라고 판단할 수 없습니다. 로그인 페이지, 오류 안내, 만료 메시지가 반환되더라도 다운로드 자체는 성공한 것으로 표시될 수 있습니다. 클라이언트가 파싱한 항목과 로그를 기준으로 확인하세요. 갱신 뒤 노드가 보이지 않더라도 기존 그룹을 먼저 보존하고 모든 이전 설정을 바로 삭제하지 마세요. 사용할 수 있는 되돌리기 경로가 사라질 수 있습니다.

가져온 뒤 특히 확인할 항목

기본 주소, 포트, 사용자 식별자는 눈에 잘 띄지만 흐름 제어, 지문, 보안 계층 이름, WebSocket 경로, Host, gRPC 서비스 이름, REALITY 인증 매개변수는 놓치기 쉽습니다. 특히 새 형식을 구형 파서로 가져오면 파서가 전체 링크를 거부하는 대신 알 수 없는 항목을 무시할 수 있습니다. 이 경우 기본 화면에서 노드를 볼 수 있고 편집 창도 열리지만 실제 연결에 필요한 정보는 이미 빠져 있을 수 있습니다.

구독을 갱신하면 일반적으로 원본 내용을 다시 가져옵니다. 구독 관리 아래의 노드를 직접 편집하면 다음 갱신 때 변경 사항이 덮어써질 수 있습니다. 동작은 클라이언트마다 다르므로 수동 수정 한 번으로 영구적으로 해결됐다고 생각해서는 안 됩니다. 매개변수를 비교하려면 클라이언트에서 허용하는 경우 별도의 테스트 노드로 복사하고 알아보기 쉽게 이름을 붙이세요. 구독 원본에 문제가 있다면 원본을 수정하거나 호환되는 경로를 사용해야 합니다. 갱신할 때마다 같은 항목을 다시 보완하지 마세요.

갱신 경로와 여러 기기 간 동기화

구독 갱신에 프록시를 사용할지는 현재 연결 조건에 따라 결정해야 합니다. v2rayN에는 ‘모든 구독 업데이트(프록시 사용 안 함)’와 같은 메뉴가 표시될 수 있습니다. 기존 프록시를 사용할 수 없는데 갱신도 그 프록시에 의존하면 연결이 반복해서 실패할 수 있습니다. 반대로 환경에 따라 직접 갱신이 실패할 수 있으므로 클라이언트가 제공하는 갱신 경로를 비교하세요. 갱신 방식을 바꿀 때마다 구체적인 오류를 확인해 연결, 인증, 파싱 실패를 구분하고 업데이트 버튼만 반복해서 누르지 마세요.

여러 기기에서 같은 구독을 사용해도 모든 로컬 설정이 공유되는 것은 아닙니다. 구독은 보통 노드 목록을 제공하며 시스템 프록시, 앱 연결, 라우팅, DNS는 각 기기에서 따로 설정해야 합니다. 컴퓨터의 사용자 지정 규칙은 휴대전화에서 같은 주소를 가져온다고 자동으로 나타나지 않습니다. QR 코드 내보내기에 단일 노드만 포함될 수도 있습니다. 자세한 이전 방법은 컴퓨터와 휴대전화 간 구독 동기화 방법을 참고하세요. 갱신 오류가 계속되면 구독 업데이트 실패 자가 점검 목록을 확인할 수 있습니다.

사용 환경별 선택: 요구 사항에 맞는 설정으로 범위 좁히기

일상적인 데스크톱 및 모바일 사용

데스크톱에서 처음 사용하는 경우 v2rayN을 우선 선택하고 운영체제와 프로세서 아키텍처에 맞는 설치 파일을 고르세요. 프로토콜은 이름부터 고른 뒤 설정을 찾는 대신 서버가 실제로 제공하는 전체 조합을 확인하고, 현재 코어에서 지원하지 않는 선택지를 제외한 다음 안정성을 비교해야 합니다. 웹, 문서, 일반 앱을 주로 사용한다면 프로토콜 변경에 따른 이론적인 차이보다 안정적인 도메인 조회, 올바른 라우팅, 확실한 연결 복구가 더 중요할 때가 많습니다.

Android에서는 v2rayNG를 우선 사용하고 V2Fly 설정과의 호환이 필요할 때 v2flyNG를 검토하세요. 휴대전화에서는 백그라운드 실행, 배터리 관리, 네트워크 전환 후 연결 복구를 먼저 확인한 다음 지속 전송을 시험해야 합니다. Wi-Fi와 모바일 네트워크를 오간 뒤 문제가 생기면 비밀번호나 사용자 식별자를 바로 바꾸지 말고 클라이언트가 연결을 다시 설정하는지 확인하세요. 연결 복구는 실행 동작의 문제이며 인증 자료는 보통 접속 네트워크를 바꾼다고 달라지지 않습니다.

이름 순서가 아니라 실제 작업에 맞춰 선택하기

기존 VMess 또는 SS 설정으로 필요한 작업을 할 수 있다면 클라이언트 호환성을 유지하며 계속 사용하는 것이 비용이 적게 듭니다. VLESS, REALITY, 특정 흐름 제어를 사용하려면 서버가 해당 매개변수를 제공해야 하며 대상 코어가 이를 지원하는지도 확인해야 합니다. Trojan은 TLS 이름과 인증서 조건을 주의 깊게 살펴야 합니다. 모든 사용자에게 맞는 프로토콜 순위는 없습니다. 같은 프로토콜도 전송 방식, 보안 계층, 서버 조합에 따라 실제 사용 경험이 크게 달라질 수 있습니다.

UDP에 의존하는 작업은 특히 주의해야 합니다. 프로토콜 계층에서 UDP를 처리할 수 있다고 해도 클라이언트 접속 지점, 서버 전달, 대상 네트워크가 모두 지원된다는 뜻은 아닙니다. 시스템 프록시를 켜도 모든 앱 트래픽이 클라이언트로 들어오는 것은 아닙니다. 일부 앱은 자체 프록시 설정이나 별도의 연결 방식을 사용합니다. 먼저 입문 가이드의 접속 및 연결 확인 절차에 따라 트래픽이 들어오는 경로를 확인한 뒤 대상 앱에서 실제로 시험하세요. 브라우저가 열리는 것으로 업무 앱까지 검증됐다고 판단하지 마세요.

선택부터 되돌리기까지의 전체 절차

첫째, 플랫폼, 앱 유형, UDP 필요 여부, 백그라운드 상시 실행 필요 여부 등 필수 요구 사항을 정리합니다. 둘째, 원본 설정의 프로토콜, 전송, 보안 계층, 추가 매개변수를 기록하고 클라이언트와 코어가 모두 지원하는지 확인합니다. 셋째, 테스트 설정을 가져와 시작 로그를 확인한 뒤 도메인 접속, 규칙 분기, 실제 작업을 각각 검증합니다. 넷째, 간단한 속도 측정 한 번에 의존하지 말고 비슷한 네트워크 조건에서 연결 복구 능력과 리소스 사용량을 살펴봅니다.

실패가 발생하면 ‘요청이 클라이언트에 들어오는가, 주소에 연결할 수 있는가, 보안 계층 핸드셰이크가 성공하는가, 프록시 인증이 완료되는가, 라우팅과 DNS가 올바른가’ 순서로 범위를 좁히세요. 각 단계에서는 근거가 있는 항목 하나만 바꾸고 변경 전후의 증상을 기록합니다. 도메인 요청에 문제가 있으면 DNS 검사 및 분기 설정을 참고하세요. 기본 개념이 헷갈린다면 구독·노드·코어 초보자 질문 10가지를 읽어 보세요. 무작위로 매개변수를 조합하는 방식으로 문제 해결을 끝내지 마세요.

실제 사용에 적용하기 전에 기존 구독 그룹이나 별도 설정을 보존하고 새 구성이 주요 앱을 지원하는지 확인한 뒤 중복 항목을 정리하세요. 클라이언트를 업데이트한 뒤에도 간단한 재검사를 진행해 사용자 지정 라우팅, DNS, 코어 선택이 예상대로 유지되는지 확인해야 합니다. 새 설정이 테스트 하나만 개선하고 백그라운드 중단이나 호환성 부담을 늘린다면 기존 설정으로 되돌리는 것도 충분히 합리적입니다. 관리하기 쉬운 설정은 각 핵심 항목의 출처를 설명할 수 있고 다른 기기에서도 같은 방식으로 다시 구성할 수 있어야 합니다.