V2Ray 프로토콜·코어 선택 가이드

연결 설정의 네 가지 계층

클라이언트, 코어, 원격 서버를 먼저 구분하세요

클라이언트에서 프로토콜을 선택하기 전에 세 가지 구성 요소부터 확인하세요. v2rayN, v2rayNG, v2flyNG는 설정을 저장하고 표시하며 연결을 시작하고 구독을 관리하는 그래픽 클라이언트입니다. 코어는 설정을 해석하고 연결을 수립하며 라우팅을 적용하고 데이터를 처리합니다. 원격 서버는 정해진 프로토콜에 따라 연결을 받습니다. 이 셋은 같은 소프트웨어 계층이 아닙니다. 인터페이스에서 항목을 저장할 수 있다는 것은 클라이언트가 입력값을 받아들였다는 뜻일 뿐, 코어가 모든 필드를 이해하거나 원격 서버가 같은 매개변수를 사용하는 것을 보장하지 않습니다. 데스크톱에서는 v2rayN 플랫폼 페이지에서 설치 파일을 선택하고, 안드로이드에서는 설정에 필요한 코어를 지원하는 클라이언트를 선택하세요.

연결 설정은 보통 서버 주소, 프록시 프로토콜, 전송 방식, 보안 계층의 네 가지 정보로 나눌 수 있습니다. 서버 주소는 어디에 연결할지, 프록시 프로토콜은 어떻게 인증하고 대상 주소를 표현할지, 전송 방식은 프로토콜 데이터를 어떻게 전달할지, 보안 계층은 연결에 기밀성과 신원 인증을 어떻게 제공할지 정합니다. 이 모든 정보를 통틀어 ‘프로토콜’이라고 부르면 문제 해결의 단계가 흐려집니다. 예를 들어 VLESS는 프록시 프로토콜, WebSocket은 전송 방식, TLS는 보안 계층이며 세 가지가 한 설정에 함께 들어갈 수 있습니다. 서로 배타적인 선택지가 아닙니다. 포트는 원격 서버가 연결을 받는 진입점일 뿐, 포트만으로 어떤 프로토콜을 쓰는지 알 수는 없습니다.

인터페이스의 각 항목은 서로 연관되어 있습니다

클라이언트의 ‘주소’는 보통 하위 계층 연결에 사용하고, ‘서버 이름’ 또는 SNI는 TLS 핸드셰이크에서 서버 이름을 전달하는 데 사용합니다. 두 값은 같을 수도, 서버 설정에 따라 다를 수도 있습니다. WebSocket의 Host와 경로는 별도의 애플리케이션 계층 매개변수입니다. 이름이 비슷하다는 이유로 SNI를 모든 항목에 복사해서는 안 됩니다. IP 주소로 직접 연결하더라도 인증서 검증에는 도메인 이름이 필요할 수 있습니다. 서비스 제공자가 안내한 항목별 역할을 그대로 유지하세요. 주소, Host, SNI를 서로 바꿔 쓸 수 있는 별칭으로 취급하거나 인증서 검증을 꺼서 설정 오류를 가리지 마세요.

라우팅 규칙은 원격 프로토콜을 바꾸지 않습니다

라우팅 설정은 요청이 코어에 들어온 뒤 어떤 아웃바운드로 처리할지 정합니다. 직접 연결, 프록시, 차단 중에서 선택할 수 있지만 VMess를 자동으로 VLESS로 바꾸거나 누락된 TLS 매개변수를 채우지는 않습니다. 안드로이드 VPN 모드와 데스크톱 시스템 프록시는 로컬 연결 방식의 차이입니다. VPN 모드는 시스템이 제공하는 가상 네트워크 인터페이스로 선택한 트래픽을 받습니다. 시스템 프록시는 해당 설정을 따르는 앱에 로컬 리스닝 포트를 이용하도록 알립니다. 클라이언트에는 실행 중으로 표시되는데 특정 프로그램만 프록시를 사용하지 않는다면 원격 프로토콜을 바꾸기 전에 연결 방식을 확인하세요. 관련 계층의 차이는 시스템 프록시와 라우팅 모드 안내에서도 확인할 수 있습니다.

공유 링크를 읽을 때도 같은 순서로 필드 목록을 만들어 보세요. 주소와 포트가 있는지, 인증 필드가 어떤 프로토콜에 속하는지, 전송 방식에 전용 경로가 있는지, 보안 계층을 사용하는지 확인한 뒤 라우팅과 DNS를 살펴봅니다. 이렇게 하면 클라이언트를 바꾸더라도 원격 연결에 필요한 조건과 로컬 사용 환경에 따른 설정을 구분할 수 있습니다. 링크 길이나 메모, 프로토콜 이름만으로 설정이 더 발전된 것인지 판단하지 마세요. 메모는 이름표일 뿐이며 실제 연결 동작은 코어가 최종적으로 받은 설정에 따라 결정됩니다.

VMess와 VLESS의 설계 차이

VMess는 인증과 데이터 보호를 프로토콜에 포함합니다

VMess는 Project V 생태계 초기에 만들어진 프록시 프로토콜로, 사용자 식별자와 요청 인증, 데이터 보호를 중심으로 설계되었습니다. 클라이언트에서 흔히 보는 UUID는 사용자를 식별하는 값이지 서버 도메인이나 구독 주소가 아닙니다. 설정의 암호화 또는 보안 옵션은 코어가 지원하는 방식과 일치해야 하며, 가져오기에 성공했다는 이유만으로 다른 값으로 임의 변경해서는 안 됩니다. VMess는 여러 전송 방식을 사용할 수 있고 TLS를 덧붙일 수도 있습니다. 프로토콜 자체의 암호화와 외부 TLS는 역할이 다르므로 어느 한 필드만 보고 연결 전체의 보안 상태를 판단할 수 없습니다.

최근 VMess 구성은 보통 AEAD 인증 방식을 사용합니다. 오래된 가이드에 나오는 추가 ID, 구형 인증 모드, 과거 호환 옵션을 현재 설정의 일반적인 권장값으로 여겨서는 안 됩니다. 기존 설정을 계속 쓸 수 있는지는 양쪽 구현이 같은 방식을 여전히 지원하는지에 달려 있습니다. 오래된 구독을 받았다면 서버에서 실제로 사용하는 인증 방식을 확인하고 최신 연결 매개변수를 받은 뒤 클라이언트와 코어의 지원 여부를 확인하세요. 추가 ID를 반복해서 바꾸거나 인터넷에서 찾은 고정값을 그대로 적용하면 설정 불일치만 늘어날 수 있습니다.

시스템 시간도 따로 확인하는 것이 좋습니다. 일부 프로토콜의 인증 절차는 시간 범위에 영향을 받기 때문에 기기 시간이 크게 어긋나면 하위 계층 TCP 연결은 성공해도 인증에 실패할 수 있습니다. 클라이언트를 반복해서 재설치하기보다 시스템의 날짜, 시간, 시간대를 자동으로 설정한 뒤 다시 연결해 보세요. 시간이 맞더라도 인증이 반드시 성공하는 것은 아니므로 UUID, 포트, 원격 설정도 각각 대조해야 합니다. 로그가 인증 단계에서 멈춘다면 요청이 다음 전달 단계에 도달하지 않았을 수 있으니 DNS나 라우팅 규칙을 먼저 바꾸기보다 이 조건부터 확인하세요.

VLESS는 데이터 보호를 외부 보안 계층에 맡깁니다

VLESS는 프로토콜 자체의 암호화 부담을 줄이고 데이터 보호를 TLS, REALITY 같은 외부 메커니즘에 맡기는 방향으로 설계되었습니다. 인증과 대상 주소 표현은 여전히 필요하며 프로토콜 오버헤드가 없다는 뜻은 아닙니다. 일반적인 VLESS 설정의 암호화 필드는 none입니다. 이는 해당 필드의 프로토콜상 의미일 뿐, 모든 데이터가 네트워크를 평문으로 통과한다는 뜻은 아닙니다. 연결 전체를 판단하려면 보안 계층도 함께 확인해야 합니다. 반대로 외부 보호가 없다면 VLESS라는 이름만으로 연결에 기밀성이 있다고 단정할 수도 없습니다.

VLESS 설정에는 xtls-rprx-vision 같은 flow 필드가 포함될 수 있습니다. 모든 연결에 그대로 붙여 넣어 속도를 높이는 옵션이 아니라, 특정 처리 방식과 전송 조합, 코어 기능에 따라 달라지는 매개변수입니다. 클라이언트와 서버가 모두 해당 조건을 충족해야 합니다. 지원하지 않는 전송 조합에 추가하면 설정이 거부되거나 핸드셰이크가 실패할 수 있습니다. 서비스 제공자가 flow를 안내하지 않았다면 이름만 보고 임의로 추가하지 마세요. flow를 안내받았더라도 다른 클라이언트에 입력란이 없다는 이유로 생략해도 된다고 판단해서는 안 됩니다.

기존 설정을 옮길 때는 매개변수를 빠짐없이 유지하세요

VMess와 VLESS는 드롭다운 메뉴만 바꿔 서로 전환할 수 있는 형식이 아닙니다. 서버 주소와 사용자 식별자가 같더라도 서버 측에서 해당 프로토콜을 받도록 설정되어 있어야 합니다. 이전할 때는 서버가 제공한 새 링크를 받아 보안 계층, 서버 이름, 전송 방식, 경로, flow를 각각 확인한 뒤 별도의 항목으로 추가해 테스트하세요. 기존에 작동하는 설정을 보존하면 새 설정이 실패했을 때 이전 매개변수 오류인지 로컬 네트워크 변화인지 빠르게 구분할 수 있습니다. 구독으로 관리되는 항목을 바로 덮어쓰지 마세요. 다음 업데이트에서 직접 수정한 값이 원래대로 돌아갈 수 있습니다.

기존 VMess 연결이 안정적으로 작동하고 서버에서 당장 이전할 계획이 없다면 프로토콜 이름만 바꾸려고 환경 전체를 교체할 필요는 없습니다. 새로 구성할 때 VLESS와 특정 보안 계층을 사용한다고 명시되어 있다면 해당 필드를 설정할 수 있는 클라이언트와 코어를 선택하세요. 어느 경우든 오버헤드 차이를 따지기 전에 종단 간 호환성을 우선해야 합니다. 서비스 제공자가 ‘VLESS 지원’만 안내하고 전송 방식과 보안 계층은 설명하지 않았다면 정보가 불완전한 것입니다. 매개변수를 먼저 확인한 뒤 가져와야 호환성 문제를 서버에 연결할 수 없는 문제로 오해하지 않습니다.

Trojan, Shadowsocks, REALITY

Trojan은 올바른 TLS 연결이 필요합니다

Trojan은 TLS를 기반으로 하며 보호된 연결 안에서 비밀번호 인증과 대상 요청을 처리하도록 설계되었습니다. 일반적인 설정에는 서버 주소, 포트, 비밀번호, 이름 검증에 필요한 매개변수가 포함됩니다. 이 비밀번호는 원격 연결 자격 증명이므로 공개 로그나 게시판에 올리지 마세요. TLS 핸드셰이크 성공과 프록시 인증 성공은 별개의 단계입니다. 인증서 이름이 일치하지 않으면 서버 이름과 인증서 설정을 확인하세요. 핸드셰이크가 완료된 뒤에도 거부된다면 비밀번호와 원격 서비스 설정을 확인해야 합니다. 두 단계를 모두 ‘연결 안 됨’으로 뭉뚱그리면 문제 범위가 불필요하게 커집니다.

인증서 검증은 아무 때나 꺼도 되는 스위치가 아닙니다. 연결 대상 서비스의 신원을 확인하는 기능이므로 비활성화하면 일시적으로 연결되더라도 기존 보안 가정이 달라집니다. 기기 시간 오류, 불완전한 인증서 체인, 이름 불일치가 검증 실패의 원인일 수 있으니 각각 바로잡으세요. Trojan의 확장 기능은 구현에 따라 다릅니다. 한 클라이언트에서 기본 비밀번호 설정을 가져올 수 있다고 해서 다른 구현이 추가한 모든 옵션까지 이해하는 것은 아닙니다. 공유 링크에 추가 필드가 있다면 장식이라고 넘기지 말고 각각 확인하세요.

Shadowsocks는 암호화 방식과 키 형식을 함께 맞춰야 합니다

Shadowsocks는 클라이언트에서 Shadowsocks 또는 SS로 표시되는 경우가 많습니다. 사전 공유 비밀 값과 암호화 방식을 조합해 사용하며, 설정이 간단해 보여도 방식 이름은 연결 프로토콜의 일부입니다. 양쪽에서 같은 방식을 사용해야 하며 클라이언트에서 더 익숙해 보이는 항목으로 임의 변경해서는 안 됩니다. 기존 AEAD 방식과 Shadowsocks 2022 계열은 이름만 바꿔 서로 대체할 수 없습니다. 후자는 키 재료의 형식과 길이에 특정 조건이 있으므로 일반 비밀번호를 유효한 키로 사용할 수 없고, 클라이언트가 서버에 필요한 값으로 자동 변환해 줄 것이라고 기대해서도 안 됩니다.

Shadowsocks를 선택할 때는 구독에 플러그인 매개변수가 포함되어 있는지도 확인하세요. 기본 프로토콜 지원과 플러그인 지원은 별개의 기능입니다. 플러그인 구현이 없다면 주소, 포트, 방식, 비밀번호가 모두 맞아도 연결되지 않을 수 있습니다. 코어마다 지원하는 방식과 플러그인 범위가 다를 수 있으므로 현재 기기의 코어가 실제로 받아들이는 설정을 기준으로 판단하세요. UDP가 필요한 앱은 원격 서버에서 UDP 전달을 허용하는지, 클라이언트 연결 경로가 UDP를 지원하는지, 라우팅에서 차단하지 않았는지도 확인해야 합니다. 웹페이지가 열리는 것만으로 이 조건들이 충족됐다고 볼 수는 없습니다.

REALITY는 보안 메커니즘이지 독립된 프록시 프로토콜이 아닙니다

REALITY는 VLESS와 함께 사용되는 경우가 많아 공유 설정 이름이 ‘VLESS + REALITY’로 표시되기도 합니다. REALITY는 보안 계층의 역할을 맡으며 VLESS와 같은 수준의 별도 계정 유형이 아닙니다. 일반적인 클라이언트 필드는 서버 이름, 공개 키, short ID, fingerprint입니다. 공개 키는 서버의 키 설정과 대응하고, short ID는 서버에서 허용한 식별값과 일치해야 하며, fingerprint는 클라이언트 핸드셰이크 특성과 관련이 있습니다. 필드 형식과 필수 여부는 설정에 따라 다르므로 다른 연결에서 값을 임의로 가져오지 마세요. 공개 키를 UUID와 혼동해서도 안 됩니다.

REALITY 매개변수 조합은 서버에서 설계해 제공해야 합니다. 원격 주소에 접속할 수 있다고 해서 공개 키, short ID, 서버 이름 조합까지 올바른 것은 아닙니다. 연결에 실패하면 먼저 링크가 온전히 복사되었는지, 특히 특수 문자가 포함된 쿼리 매개변수가 빠지지 않았는지 확인하세요. 현재 클라이언트의 코어가 해당 필드를 인식하는지도 살펴봐야 합니다. 임의의 fingerprint나 short ID, 관련 없는 도메인을 먼저 시험하지 마세요. 인터페이스에서 필드가 비어 있더라도 가져오기 과정에서 값을 읽지 못한 것일 수 있습니다. 서버에서 필요하지 않다고 단정하지 말고 원본 공유 내용을 다시 확인하세요.

이 세 가지를 ‘구형에서 신형으로’ 이어지는 교체 목록처럼 볼 수는 없습니다. 기존 TLS 인프라, 현재 구독 형식, 서버 구현, 모바일 지원 여부가 최종 선택에 영향을 줍니다. 클라이언트만 사용하는 입장이라면 서비스 제공자가 안내한 매개변수 조합을 그대로 유지하고, 기기에서 모두 지원하는지 확인한 뒤 같은 네트워크와 같은 작업으로 비교하는 것이 가장 안전합니다. 보안 계층과 프록시 프로토콜 이름이 많다고 설정이 자동으로 더 나아지는 것은 아닙니다. 불필요한 중간 계층을 줄이면 이해와 관리가 쉬워집니다.

연결 속도, 처리량, 리소스 사용량

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

‘빠르다’는 느낌에는 적어도 세 가지가 있습니다. 클릭 후 첫 응답을 받기까지 걸리는 시간, 장시간 전송 시 유지되는 처리량, 동시 요청의 안정성입니다. 최초 응답은 로컬 DNS, 원격 주소 확인, 하위 계층 연결, 보안 핸드셰이크의 영향을 받습니다. 지속 처리량은 경로 대역폭, 패킷 손실, 혼잡 제어, 원격 서버 부하, 기기 처리 성능에 더 크게 좌우됩니다. 페이지를 처음 열 때 느린 설정도 대용량 파일 전송에서는 정상일 수 있습니다. 따라서 한 번의 페이지 로딩 결과와 다른 설정의 단일 속도 측정값을 비교하지 말고 먼저 비교할 지표를 정하세요.

프록시 프로토콜 자체의 처리 오버헤드는 전체 연결 경로의 일부일 뿐입니다. 암호화 알고리즘이 프로세서 명령어를 활용할 수 있는지, 외부 TLS가 추가되는지, 중간에 리버스 프록시를 거치는지에 따라 CPU 사용량과 연결 수립 비용이 달라집니다. 저전력 기기에서 체감되는 차이는 성능이 충분한 데스크톱에서는 작을 수 있습니다. 하드웨어 조건을 무시한 채 특정 프로토콜이 언제나 리소스를 가장 적게 쓴다고 단정하거나, 원격 서버 혼잡으로 처리량이 낮은 것을 로컬 암호화 알고리즘 탓으로 돌려서는 안 됩니다. 먼저 네트워크와 서버 부하를 확인한 뒤 프로토콜 오버헤드를 살펴보는 편이 좋습니다.

전송 캡슐화와 연결 재사용에는 각각 장단점이 있습니다

직접 TCP, WebSocket, gRPC의 차이는 주로 데이터 전달 방식, 중간 인프라와의 호환성, 연결 관리에 있습니다. WebSocket은 HTTP 업그레이드와 올바른 경로가 필요할 수 있고, gRPC는 보통 HTTP/2와 일치하는 서비스 이름에 의존합니다. 중계 설정도 이에 맞게 지원해야 합니다. 이런 방식은 배포에 유연성을 주지만 관리할 매개변수도 늘어납니다. 캡슐화 계층이 많을수록 성능이 좋아진다고 생각하지 말고 서버 측 요구가 분명할 때 선택하세요. 경로나 서비스 이름이 잘못되어도 하위 계층 포트에는 접속될 수 있지만 프록시 세션은 수립되지 않을 수 있습니다.

클라이언트의 ‘Mux 다중화 사용’은 여러 논리 요청이 더 적은 수의 하위 계층 연결을 공유하도록 합니다. 연결을 자주 수립하는 비용을 줄일 수 있지만, 여러 요청이 같은 연결의 혼잡이나 장애 영향을 함께 받을 수도 있습니다. 전송 자체의 다중화와 겹치면 이점이 더 커진다고 보장할 수 없으며 특정 프로토콜, flow, 코어 조합에는 명확한 제한이 있을 수 있습니다. 기본 설정을 유지하다가 서버 지원이 확인되고 실제로 짧은 연결이 많이 발생하는 경우에만 시험하세요. Mux를 버벅임을 해결하려면 무조건 켜야 하는 일반적인 옵션으로 생각해서는 안 됩니다.

한 번의 순위보다 재현 가능한 테스트를 하세요

먼저 일반 웹페이지로 최초 응답을 확인하고, 허용된 안정적인 리소스로 지속 전송을 살펴본 뒤 실제 작업에서 동시 요청과 장시간 연결을 테스트할 수 있습니다. 반복 측정에서는 최초 연결과 재사용 연결을 구분하세요. 캐시와 세션 복구가 결과를 바꿀 수 있습니다. 테스트 중에는 다른 대용량 작업을 멈추고 네트워크 전환이나 기기 절전이 있었는지 기록하세요. 가장 잘 나온 한 번의 결과만 남기거나 앱에 표시되는 연결 테스트 시간을 종단 간 다운로드 속도로 간주하지 마세요. 테스트 방식마다 측정하는 대상이 다를 수 있습니다.

CPU와 메모리 사용량도 상황에 맞게 살펴야 합니다. 규칙 데이터베이스, 연결 수, 로그 수준, DNS 캐시도 리소스 사용량을 늘릴 수 있으므로 전부 프로토콜 탓으로 돌려서는 안 됩니다. 클라이언트가 대기 중일 때는 정상인데 여러 페이지를 연 뒤 사용량이 늘어난다면 동시 연결과 규칙 처리를 먼저 확인하세요. 단일 장시간 전송만으로 기기가 눈에 띄게 뜨거워진다면 암호화와 캡슐화 조건을 비교하세요. 점검이 끝나면 불필요한 상세 로그를 끄고 원래 설정을 기록해 두어야 다음 변화의 원인을 기억에만 의존하지 않고 파악할 수 있습니다.

실시간 통신에서는 UDP 경로와 지터도 확인해야 합니다. 웹페이지가 정상적으로 열린다는 것은 일부 TCP 요청이 작동한다는 뜻일 뿐, 통화·게임·이름 확인에 필요한 UDP까지 원활하다는 보장은 없습니다. 작업이 간헐적으로 멈춘다면 프로토콜 이름만 바꾸지 말고 연결 방식, 서버 전달, 네트워크 패킷 손실을 확인하세요. 장기간 사용할 때는 한 번의 최대 처리량보다 실제 작업을 안정적으로 끝내는지가 더 중요합니다. 선택할 때 장애 복구 능력과 관리 편의성도 함께 고려하세요.

안드로이드 백그라운드 동작, 네트워크 전환, 배터리

배터리 소모는 전체 처리 경로에서 발생합니다

안드로이드 배터리 소모를 VMess, VLESS, Trojan만으로 구분할 수는 없습니다. 무선 네트워크 깨우기, 연결 유지, DNS 조회, 백그라운드 앱 요청, 암호화 처리, 상세 로그가 모두 배터리에 영향을 줄 수 있습니다. 지속적인 고속 전송은 무선 모듈과 프로세서의 작동 시간을 늘립니다. 작은 백그라운드 요청이 잦으면 전체 데이터 사용량이 많지 않아도 기기를 자주 깨워 배터리를 소모할 수 있습니다. 프로토콜을 비교할 때는 프록시 앱 적용 범위, 원격 서버, 네트워크 종류, 화면 상태를 동일하게 유지하세요. 그렇지 않으면 프로토콜 설계가 아니라 사용 방식의 차이를 측정하게 됩니다.

v2rayNG의 VPN 모드는 시스템 VPN 인터페이스로 트래픽을 받은 뒤 코어로 전달합니다. 앱별 프록시는 처리 경로에 들어가는 앱의 범위를 줄일 수 있지만, ‘앱 선택’이 선택한 앱만 프록시한다는 뜻인지 선택한 앱을 우회한다는 뜻인지는 현재 모드와 인터페이스 안내를 확인해야 합니다. 설정을 바꾼 뒤에는 연결을 다시 수립하고 대상 앱을 직접 열어 확인하세요. 시스템 프록시 모드는 앱이 로컬 프록시 진입점을 사용할 수 있어야 합니다. 모든 앱의 트래픽이 자동으로 전달되는 것은 아닙니다. 모드가 맞지 않으면 연결이 불안정한 것으로 오해하기 쉽습니다.

증상에 따라 백그라운드 제한을 조정하세요

앱을 백그라운드로 보내거나 화면을 끈 직후 연결이 끊긴다면 시스템이 클라이언트 서비스를 종료하는지, 백그라운드 실행을 허용하는지, 다른 VPN 앱이 현재 연결을 대체하는지 먼저 확인하세요. 안드로이드 기기마다 배터리 관리 메뉴의 위치와 이름이 다르므로 앱 정보의 배터리 및 백그라운드 권한부터 살펴보세요. 처음부터 모든 절전 설정을 끄지 말고 화면 꺼짐, 잠금 화면 정리, 특정 절전 모드 이후에 문제가 발생하는지 확인한 뒤 필요한 항목만 조정하세요. 네트워크 연결은 유지되는데 특정 앱에서 알림을 받지 못한다면 해당 앱의 백그라운드 제한도 확인해야 합니다.

클라이언트는 계속 실행 중인데 Wi-Fi에서 모바일 네트워크로 전환한 뒤에만 연결이 끊긴다면 기존 하위 계층 연결이 끊겼을 가능성이 큽니다. 프로토콜 이름이 같다고 해서 기존 연결이 다른 네트워크로 자동 이전되지는 않습니다. 코어와 앱이 세션을 다시 수립해야 합니다. 먼저 연결을 중지했다가 다시 시작해 복구되는지 확인하세요. 복구된다면 자동 재연결 동작, 시스템 네트워크 상태, 원격 서버의 연결 처리를 살펴보세요. 스트리밍이나 통화 앱은 기존 세션을 유지할 수도 있으므로 상태 표시줄 아이콘만 보지 말고 해당 앱 화면으로 돌아가야 합니다.

연결 재사용, 유지, DNS를 무작정 늘리지 마세요

연결 유지 기능은 끊어진 연결을 감지하거나 일부 네트워크 장비에서 세션을 유지하는 데 도움이 될 수 있지만, 탐지 간격이 짧아질수록 무선 네트워크를 더 자주 깨울 수도 있습니다. 유휴 상태에서 연결이 자주 끊기는 문제가 없다면 간격을 지나치게 줄일 필요는 없습니다. Mux도 프로토콜 조합에 맞춰 판단해야 합니다. 휴대전화의 전력 소모가 걱정된다고 공유 연결이 반드시 절전 효과를 내는 것은 아닙니다. 대용량 데이터를 계속 전송할 때 핸드셰이크를 조금 줄여도 주요 배터리 소모 원인은 달라지지 않을 수 있습니다. 연결 오류 후 반복 재시도는 오히려 부담을 키울 수 있습니다. 설정을 바꾼 뒤에는 스위치가 켜졌는지가 아니라 실제 사용 결과를 확인하세요.

DNS 설정 오류는 조회 반복, 시간 초과, 연결 재시도를 일으켜 클라이언트가 계속 작동하는 것처럼 보이지만 실제 요청은 처리되지 않을 수 있습니다. 이런 경우 주소 확인 실패와 보안 핸드셰이크 실패를 먼저 구분한 뒤 DNS 서버에 접속할 수 있는지, 라우팅이 순환하지 않는지, 도메인 정책이 추가 조회를 발생시키는지 확인하세요. 로컬 DNS를 사용한다고 해서 모든 앱이 자동으로 같은 조회 경로를 사용하는 것은 아닙니다. 앱 자체의 암호화 DNS도 결과에 영향을 줄 수 있습니다. 관련 문제는 FAQ 문제 해결 항목에서 계속 확인하고 DNS, 보안 계층, 라우팅을 한꺼번에 바꾸지 마세요.

배터리 비교는 같은 조건에서 두 가지 관찰 구간으로 나눌 수 있습니다. 먼저 화면이 꺼지고 실제 작업이 거의 없는 상태에서 백그라운드 안정성을 살펴본 뒤, 정해진 작업을 수행하면서 발열과 배터리 소모 추이를 확인하세요. 연결이 다시 수립되는지, 네트워크가 전환되는지, 앱이 계속 다운로드하는지 기록하면 됩니다. 기기 조건과 무관한 고정 배터리 소모율을 제시할 필요는 없습니다. 유휴 상태에서 문제가 발생하면 깨우기, 재시도, 로그를 중점적으로 확인하고, 부하가 높을 때만 문제가 생기면 처리량, 암호화, 기기 냉각을 살펴보세요. 그래야 실제 설정에 도움이 되는 결론을 얻을 수 있습니다.

V2Fly, Xray와 클라이언트 호환성의 범위

공통된 뿌리가 있다고 기능까지 같은 것은 아닙니다

Project V는 이 생태계를 이해하는 출발점입니다. V2Fly와 Xray는 관련 코어 계열에서 각기 다른 방향으로 발전해 왔습니다. 인바운드, 아웃바운드, 라우팅, DNS 설정 방식처럼 일부 개념과 역사적 기반을 공유하지만 프로토콜 기능, 전송 구현, 설정 필드는 독립적으로 발전합니다. 둘 다 ‘V2Ray 생태계’에 속한다는 이유만으로 완전히 호환된다고 판단해서는 안 됩니다. 한 코어에서 유효한 필드가 다른 코어에는 없거나 이름이 다르거나 제약 조건이 다를 수 있습니다. 설정 전체를 그대로 복사하기보다 항목별로 확인하세요.

v2rayNG는 주로 Xray 코어를 연결 기능의 기반으로 사용하고, v2flyNG는 V2Fly 코어 계열을 지원합니다. v2rayN은 데스크톱 그래픽 관리와 관련 코어의 실행 설정을 제공합니다. 인터페이스 기능과 실제로 선택한 코어를 함께 확인해야 합니다. 클라이언트에 가져오기 메뉴가 있더라도 현재 실행 중인 코어가 가져온 내용을 처리할 수 있다는 뜻은 아닙니다. 자세한 생태계 관계는 Project V, V2Fly, Xray 계열 안내를 참고하세요. 클라이언트 이름만 보고 지원 프로토콜 목록을 짐작하지 마세요.

프로토콜, 설정, 인터페이스는 서로 다른 호환성입니다

프로토콜 호환성은 양쪽에서 같은 프로토콜로 데이터를 주고받을 수 있는지, 설정 호환성은 코어가 설정 구조와 필드를 이해하는지, 인터페이스 호환성은 클라이언트에서 해당 필드를 입력하고 저장해 전달할 수 있는지를 뜻합니다. 셋 중 하나라도 충족되지 않으면 작동하지 않을 수 있습니다. 예를 들어 코어가 특정 기능을 지원해도 그래픽 가져오기 도구가 새 매개변수를 보존하지 못하면 최종 설정은 불완전합니다. 반대로 인터페이스가 원본 문자열을 보존하더라도 코어가 이를 인식하지 못하면 기능을 사용할 수 없습니다. 문제 해결 시 실제로 어느 단계에서 실패했는지 확인하세요.

REALITY와 흔히 사용하는 VLESS Vision 조합은 Xray 기능과 필드가 빠짐없이 갖춰졌는지 특히 확인해야 합니다. 다른 코어에 이름과 의미가 같고 그대로 대체할 수 있는 구현이 있다고 가정해서는 안 됩니다. V2Fly 계열의 프로토콜과 전송 기능도 실제 구현을 기준으로 확인해야 하며, 어느 계열을 다른 계열의 모든 기능을 포함하는 집합으로 설명해서는 안 됩니다. 코어 선택은 어느 쪽이 더 앞선지 가리는 문제가 아닙니다. 현재 서버가 요구하는 조합을 정확히 실행할 수 있는지, 클라이언트에서 해당 설정을 관리할 수 있는지가 기준입니다.

짧은 설정도 실행 환경을 확인해야 합니다

아래는 Xray 스타일의 라우팅 규칙 예시입니다. 규칙의 역할을 설명하기 위한 것으로, 단독으로 실행할 수 있는 완전한 설정은 아닙니다. 사용하려면 해당 규칙을 완전한 설정에 합치고 direct 및 block 태그가 붙은 아웃바운드와 필요한 규칙 리소스가 구성되어 있는지 확인해야 합니다. 첫 번째 규칙은 지정된 광고 도메인 목록을 차단하고, 다음 두 규칙은 각각 사설 주소와 지정된 도메인 목록을 직접 연결 아웃바운드로 보냅니다. 규칙은 순서대로 적용되며 먼저 일치한 규칙을 뒤의 규칙이 덮어쓰지 않습니다. 따라서 순서를 바꾸면 결과도 달라질 수 있습니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

IPIfNonMatch는 도메인 규칙이 일치하지 않을 때 라우팅 단계에서 도메인을 확인해 IP 조건을 추가로 검사할 수 있다는 뜻입니다. ‘모든 도메인을 먼저 IP 기준으로 분기한다’는 의미는 아닙니다. 규칙 리소스가 없거나 아웃바운드 태그가 잘못되었거나 DNS에 접근할 수 없으면 설정이 예상대로 작동하지 않을 수 있습니다. 설정 호환성은 필드 이름뿐 아니라 리소스, 태그, 도메인 확인 경로 같은 실행 환경에도 달려 있습니다. 일반적으로는 클라이언트에서 제공하는 라우팅 인터페이스로 규칙을 관리하고, 생성되는 구조를 명확히 이해하는 경우에만 사용자 지정 설정을 사용하세요.

구독, 공유 링크, 가져오기 호환성

구독 주소와 연결 자격 증명은 서로 다릅니다

구독 링크는 보통 여러 설정을 가져오는 주소이고, 개별 공유 링크는 하나의 연결 정보를 나타냅니다. 단일 공유 링크를 구독 주소 입력란에 넣거나 구독 주소를 연결 항목으로 가져오면 가져오기에 실패하거나 사용할 수 있는 항목이 없을 수 있습니다. 구독에는 접근 토큰이 포함될 수 있으며, 토큰 권한이 설정 전체에 적용될 수도 있으므로 민감 정보로 다루세요. 문제를 확인할 때 원본 구독 주소를 공개하지 마세요. 로그나 스크린샷에서도 인증 쿼리 매개변수, 계정 식별자, 원격 비밀번호를 가려야 설정 전체의 접근 권한이 노출되지 않습니다.

Base64는 인코딩 방식이지 암호화 프로토콜이 아니며 구독 내용을 보호하지도 않습니다. 일반적인 구독은 여러 공유 링크를 텍스트로 묶어 인코딩합니다. 클라이언트는 먼저 텍스트를 디코딩한 뒤 링크를 하나씩 해석해야 합니다. 일부 API는 디코딩된 링크 목록이나 구조화된 설정을 바로 반환하기도 합니다. 서버가 웹페이지, 로그인 안내, 오류 메시지를 반환하면 클라이언트가 이를 유효한 구독으로 인식하지 못할 수 있습니다. 업데이트에 실패하면 단순히 Base64 인코딩 문제라고 생각하지 말고 요청 실패와 응답 형식 비호환을 먼저 구분하세요.

같은 프로토콜도 공유 링크 형식은 다를 수 있습니다

VMess 공유 내용은 인코딩된 구조화 데이터인 경우가 많습니다. VLESS와 Trojan은 쿼리 매개변수가 포함된 URI를 흔히 사용하고, Shadowsocks 링크는 사용자 정보 인코딩 형식이 다를 수 있습니다. 이런 형식은 클라이언트 간 공유를 위한 규약이며 코어 설정 형식과 완전히 같지는 않습니다. 하위 프로토콜을 지원하더라도 인코딩 방식, 매개변수 이름, 확장 필드 차이로 인해 가져오기 도구가 내용을 빠짐없이 인식하지 못할 수 있습니다. 링크 접두사를 알아보는지만 확인하지 말고 가져온 뒤 전송 방식, 보안 계층, 인증 필드가 올바른 위치에 들어갔는지 확인하세요.

링크의 경로, 메모, 쿼리 값은 퍼센트 인코딩되어 있을 수 있습니다. 직접 복사하는 과정에서 줄바꿈, 공백, 메신저의 자동 잘림, 중복 디코딩이 원본 값을 바꿀 수 있습니다. 특히 경로에 물음표, 샵 기호, 앰퍼샌드가 들어 있으면 URI 구조에 의미가 있으므로 모두 일반 텍스트처럼 붙여 넣어서는 안 됩니다. 먼저 클라이언트의 클립보드 가져오기나 스캔 기능을 사용하고 텍스트 편집기에서 여러 번 변환하지 마세요. 가져온 뒤에는 메모가 같은지만 보지 말고 각 필드의 의미를 대조해야 합니다.

구독 그룹 메뉴에서 업데이트한 뒤 결과를 확인하세요

v2rayNG에서는 보통 ‘구독 그룹 설정’에서 그룹 메모와 구독 주소를 추가하고 저장한 뒤 구독을 업데이트합니다. v2rayN에서는 구독 그룹 관련 메뉴에서 주소와 업데이트를 관리합니다. 메뉴 이름은 클라이언트 인터페이스에 따라 달라질 수 있지만 ‘구독 주소 저장’과 ‘구독 내용 가져오기’는 별개의 작업입니다. 저장에 성공했다고 원격 내용까지 다운로드된 것은 아닙니다. 자세한 사용법은 구독 메뉴와 Base64 형식 안내를 참고하고, 처음 설정한다면 입문 가이드에 따라 주요 단계를 진행하세요.

업데이트가 끝나면 먼저 항목이 속한 그룹, 프로토콜 종류, 주요 보안 매개변수를 확인한 뒤 연결을 시도하세요. 업데이트 전에는 작동했는데 이후 실패한다면 클라이언트를 바로 초기화하지 말고 서버에서 인증, 전송 방식, 보안 계층을 변경했는지 비교하세요. 그룹을 업데이트하면 관리 대상 항목이 교체될 수 있으며 구독 항목을 직접 수정한 내용도 다음 업데이트에서 덮어써질 수 있습니다. 매개변수를 임시로 확인해야 한다면 용도를 명확히 표시한 별도의 테스트 항목을 만드세요. 테스트가 끝나면 구독 원본을 수정해 서로 충돌하는 설정 두 개를 장기간 관리하지 않도록 하세요.

형식 변환 도구는 이해할 수 있는 내용만 변환합니다. 원본 구독에 플러그인, flow, REALITY 매개변수, 특수 전송 필드가 들어 있어도 대상 형식에 표현 방법이 없다면 변환 결과를 가져오더라도 중요한 기능이 빠질 수 있습니다. 변환 단계를 추가하면 민감한 설정이 다른 처리 주체에 노출될 가능성도 커집니다. 서버에서 제공하는 기본 호환 형식을 우선 사용하세요. 변환이 꼭 필요하다면 변환 전후 필드를 하나씩 대조하고, ‘변환 성공’을 종단 간 호환성의 증거로 여기지 마세요. 구독은 설정을 배포할 뿐 서버와 코어 간의 기능 차이를 해결하지 않습니다.

사용 환경에 맞춰 선택하고 실패 단계를 확인하세요

필수 조건을 먼저 정한 뒤 사용 경험을 비교하세요

이미 서버 설정이 있다면 선택 범위는 우선 서버가 정합니다. VMess를 받았다면 해당 인증과 전송 조합을 지원하는 클라이언트를 사용하고, VLESS와 REALITY를 받았다면 Xray 기능과 필수 필드를 먼저 확인하세요. 서버에서 완전한 설정을 여러 종류 제공할 때만 같은 조건에서 비교할 수 있습니다. 데스크톱에서는 v2rayN을 우선 사용하고 운영체제와 프로세서 아키텍처에 맞는 설치 파일을 선택하세요. 안드로이드에서는 보통 v2rayNG부터 확인하고 V2Fly 계열 설정이 필요하다면 v2flyNG 지원 여부를 살펴보세요. 파일 정보는 다운로드 페이지에서 확인할 수 있으며, 이 페이지는 설치 파일 선택을 대신하지 않습니다.

일반 웹과 사무 작업에서는 첫 응답, 인증서 검증, 장시간 안정성이 중요합니다. 이론적인 오버헤드를 줄이겠다며 복잡한 캡슐화를 추가할 필요는 보통 없습니다. 개발 도구와 터미널은 앱이 시스템 프록시를 따르는지, 프록시 환경 변수를 별도로 설정해야 하는지 먼저 확인하세요. 브라우저는 되는데 터미널만 실패한다면 원격 프로토콜이 터미널에 맞지 않는 게 아니라 로컬 연결 방식이 다를 가능성이 큽니다. 브라우저와 터미널을 따로 점검하는 안내를 참고해 원인을 확인하고 이미 작동하는 원격 설정의 인증과 보안 매개변수를 반복해서 바꾸지 마세요.

실시간 통신, 인터랙티브 서비스, UDP가 필요한 앱을 사용할 때는 UDP 지원을 필수 조건으로 고려해야 합니다. 먼저 클라이언트 연결 방식, 코어, 원격 전달, 라우팅 순으로 확인한 뒤 실제 작업을 테스트하세요. 모바일 네트워크가 자주 바뀌는 환경에서는 순간적인 최대 처리량보다 재연결, 백그라운드 유지, 세션 복구가 중요합니다. 장시간 전송에서는 지속 속도, 프로세서 부하, 안정성을 살펴볼 수 있지만 원격 서버 위치와 테스트 리소스는 동일하게 유지해야 네트워크와 프로토콜 차이를 구분할 수 있습니다.

단계별로 문제 범위를 좁히세요

첫 번째 단계는 설정을 불러올 수 있는지 확인하는 것입니다. 로그에 알 수 없는 필드, 잘못된 방식, 누락된 매개변수가 표시되면 라우팅을 조정하기 전에 클라이언트 가져오기와 코어 호환성을 점검하세요. 두 번째 단계에서는 원격 주소를 확인하고 하위 계층 연결을 수립할 수 있는지 봅니다. 주소 확인 실패는 DNS를, 연결 시간 초과는 주소·포트·네트워크 경로·원격 서버 리스닝 상태를 중점적으로 확인하세요. 포트에 접속할 수 있어도 하위 계층 진입점에서 응답이 있다는 뜻일 뿐, 프록시 인증 성공을 의미하지는 않습니다. 현재 단계의 문제 하나씩 해결하면 서로 관계없는 변경 사항이 원인을 가리는 일을 줄일 수 있습니다.

세 번째 단계는 보안 핸드셰이크와 인증을 확인하는 것입니다. 인증서 오류가 있으면 시간, 서버 이름, 인증서 체인을 확인하세요. REALITY 관련 오류라면 공개 키, short ID, fingerprint, 이름 매개변수를 살펴보고, 인증이 거부되면 UUID, 비밀번호, 프로토콜 전용 필드를 대조하세요. 네 번째 단계에서는 요청이 올바른 아웃바운드로 전달되는지 확인합니다. 핸드셰이크는 완료됐는데 대상에 접속할 수 없다면 라우팅 규칙, DNS 결과, 아웃바운드 태그, 대상 서비스 상태를 살펴보세요. 특정 앱에서만 실패한다면 전체 연결이 끊어진 것으로 분류하기 전에 시스템 프록시, 앱별 프록시, 앱 자체 프록시 설정을 다시 확인하세요.

테스트 결과를 유지 관리 기록으로 남기세요

후보 설정마다 용도, 필수 필드, 클라이언트와 코어, 테스트 네트워크, 관찰 결과를 기록할 수 있습니다. 공개해도 되는 계정 정보가 아닌 비밀 값은 기록하지 마세요. 용도는 웹, 개발 도구, 실시간 통신처럼 구체적으로 적고, 결과는 첫 응답 지연, 백그라운드 연결 끊김, UDP만 실패 등으로 구분하세요. ‘특정 프로토콜이 안 좋다’는 기록보다 유용하며 기기를 바꾼 뒤에도 올바른 설정을 다시 구성할 수 있습니다. 클라이언트나 구독을 업데이트한 뒤에는 기준 작업을 먼저 재시험하고 변화가 있을 때 단계별로 비교하세요. 원인을 찾는 대신 전체 초기화로 해결하려 하지 마세요.

최종 선택은 세 가지 조건을 모두 충족해야 합니다. 서버 설정을 빠짐없이 지원하고, 보안 검증이 올바르게 유지되며, 실제 작업이 대상 기기에서 안정적으로 실행되어야 합니다. 이 조건을 갖춘 뒤 리소스 사용량, 관리 난이도, 네트워크 전환 시 동작을 비교해 선택하세요. 프로토콜 이름만으로 이런 조건을 검증할 수는 없으며 모든 기기와 작업에 통하는 만능 선택지도 없습니다. 흔한 증상에 대한 간단한 답은 FAQ에서 확인할 수 있습니다. 가져오기와 연결, 검증 절차를 다시 진행하려면 입문 가이드로 돌아가 순서대로 따라 하세요.