V2Ray 프로토콜 가이드
프로토콜 종류와 코어 선택

01 · 프로토콜 계층과 VMess

노드 이름만으로 연결 설정을 알 수는 없습니다

클라이언트의 서버 항목에는 보통 서버 주소와 포트, 프록시 프로토콜, 전송 방식, 전송 보안, 인증 정보가 포함됩니다. 프로토콜은 대상 지정과 사용자 인증, 요청 구성을 담당하고, 전송 방식은 데이터가 어떤 경로로 전달되는지 정합니다. 보안 계층은 연결의 신원 확인과 전송 보호를 맡습니다. 구독 메모에는 프로토콜 이름만 적혀 있을 수 있지만 실제 연결에는 전체 설정이 필요합니다. 드롭다운에서 VMess를 VLESS로 바꾸는 것만으로 기존 서버가 다른 프로토콜로 바뀌지는 않습니다.

문제를 해결하기 전에 설정을 세 계층으로 나누어 기록하세요. 아웃바운드 프로토콜, 기반 전송 방식, 보안 설정을 각각 확인합니다. 예를 들어 VMess는 WebSocket 및 TLS와 조합할 수 있고, VLESS는 직접 전송 및 REALITY와 조합할 수 있습니다. 주소가 같아도 서로 다른 포트나 진입점에서 연결을 받을 수 있습니다. 페이지의 조합 예시는 구조를 설명하기 위한 것으로, 실제 사용 가능 여부는 서버 설정에 달려 있습니다. 클라이언트는 합의된 방식으로 연결을 시작할 뿐, 원격 서버에 없는 기능을 자동으로 추가할 수 없습니다.

VMess의 설계 배경과 인증 방식

VMess는 Project V가 초기 프록시 체계를 구축할 때 채택한 핵심 프로토콜 중 하나입니다. 프로토콜 계층에서 사용자 인증과 프록시 요청을 처리하며 여러 전송 방식과 조합할 수 있습니다. 단순한 소켓 전달 형식도, 특정 외부 암호화 연결을 뜻하는 것도 아닙니다. 따라서 이름이 같은 VMess 설정도 핸드셰이크 절차와 외부 보호, 연결 재사용, 네트워크 동작이 크게 다를 수 있습니다. 이름만으로 실제 성능을 판단해서는 안 됩니다.

최신 VMess 설정은 AEAD 인증을 지원하는 구현을 기준으로 해야 합니다. 과거 자료에 나오는 추가 ID 수나 이전 인증 방식은 새 설정에 그대로 적용하지 마세요. 클라이언트에 alterId 같은 이전 버전 필드가 표시된다면 구독 출처와 코어 설명을 확인하세요. 최신 설정에서는 보통 0을 사용합니다. 인증 방식과 페이로드 암호화 알고리즘은 서로 다른 개념입니다. 보안 드롭다운에 표시된 알고리즘을 인증 방식의 세대를 증명하는 정보로 볼 수 없습니다.

시스템 시간이 VMess 인증에 실제로 영향을 줍니다. 기기가 오랫동안 절전 상태였거나 시간을 수동으로 바꿨거나 시간 동기화에 실패하면 주소와 인증 정보가 올바른데도 연결이 거부될 수 있습니다. 시간대 표시와 실제 시각을 구분하세요. 화면에 표시되는 시간대가 다르다고 반드시 문제가 있는 것은 아니며, 실제 시계의 오차가 문제입니다. 먼저 시스템 자동 시간 설정을 복구한 뒤 다시 연결해 보세요. 시간 문제를 서버 장애나 프로토콜 비호환으로 오인하지 않도록 주의하세요.

필드 확인 순서와 적용 범위

가져온 뒤 주소와 포트, 사용자 ID를 먼저 확인하고 전송 유형을 살핀 다음 TLS, 서버 이름, 전송 경로를 점검하세요. 사용자 ID는 인증 정보이므로 온전히 보존해야 하지만 공개 화면에 노출해서는 안 됩니다. 전송 경로는 로컬 파일 경로가 아니며 WebSocket의 Host가 항상 서버 주소인 것도 아닙니다. 원격 진입점을 구분하는 데 쓰일 수 있으므로 중복처럼 보여도 삭제하지 마세요. 도메인 필드를 모두 DNS 조회 결과 주소로 바꾸는 것도 피해야 합니다.

VMess 페이로드 암호화 방식은 코어 구현과 프로세서 성능, 서버 설정에 따라 달라집니다. 하드웨어 가속이 가능한 프로세서에는 특정 알고리즘이 더 적합할 수 있고, 모바일 기기의 실제 성능은 시스템 스케줄링에도 영향을 받습니다. 자동 선택을 기본값으로 두는 것이 일반적입니다. 양쪽에서 명시적으로 지원되고 재현 가능한 테스트가 있을 때만 알고리즘을 직접 지정하세요. 페이로드 암호화 계층 하나를 끈다고 연결 전체가 다른 계층으로 보호되는 것은 아니므로 외부 보안 설정은 별도로 확인해야 합니다.

이미 안정적으로 작동하는 VMess 설정이라면 이름만 바꾸려고 이전할 필요는 없습니다. 새 기능이 필요하다면 현재 코어가 이를 지원하는지 먼저 확인한 뒤 설정 제공자에게 새 진입점 전체를 받으세요. 이전 전후 성능을 비교할 때는 기기와 네트워크, 대상, 테스트 시간을 최대한 동일하게 유지해야 합니다. 그렇지 않으면 원격 진입점 변경에 따른 차이를 프로토콜 자체의 차이로 오해해 재현하기 어려운 속도 결론을 내릴 수 있습니다.

02 · VLESS와 REALITY

경량 프로토콜이라고 전송 보호를 생략해도 되는 것은 아닙니다

VLESS는 V2Ray 생태계에서 인증과 요청 구성을 간결하게 하는 방향으로 설계됐습니다. VMess와 달리 기본 프로토콜 계층에서 같은 방식의 페이로드 암호화를 담당하지 않고, 함께 사용하는 전송 보안으로 연결을 보호합니다. 따라서 ‘프로토콜이 가볍다’는 말은 역할 분담을 설명할 뿐, 어떤 네트워크에서든 평문으로 사용해도 된다는 뜻이 아닙니다. 일반적인 VLESS 설정에서 encryption 값이 none인 것은 해당 필드의 프로토콜 설정을 의미하며 연결 전체에 보안 계층이 없다는 뜻은 아닙니다.

클라이언트에서 VLESS를 선택한 뒤에는 원격 서버가 TLS, REALITY 또는 명시적으로 지원하는 다른 조합을 사용하는지 확인해야 합니다. 원격 핸드셰이크 진입점과 같은 방식을 사용해야 하므로 보안 드롭다운을 취향에 따라 바꿀 수 없습니다. 사용자 ID가 같아도 두 진입점을 서로 바꿔 쓸 수 있다는 뜻은 아닙니다. 가져오기 도구가 알 수 없는 보안 유형을 기본값으로 처리하면 서버 항목은 만들어져도 실제 핸드셰이크 설정이 달라질 수 있습니다. 즉시 설정 화면으로 돌아가 항목을 확인하세요.

REALITY는 보안 방식이지 독립된 프록시 프로토콜이 아닙니다

REALITY는 Xray 생태계의 전송 보안 방식으로, VLESS와 함께 사용하는 경우가 많습니다. 보안 핸드셰이크와 인증 방식은 바꾸지만 프록시 프로토콜의 대상 주소나 사용자 요청 의미를 대신하지는 않습니다. 구독에서 ‘REALITY 노드’라고 부르는 것은 보통 연결 설정 전체를 줄여 부르는 말입니다. 프로토콜 목록에서 VLESS를 대신할 REALITY 유형을 찾을 게 아니라 기반 프로토콜과 전송 방식, 흐름 제어 설정을 확인해야 합니다.

일반적인 인증서 배포 절차와 달리 REALITY는 자체 인증 매개변수와 핸드셰이크를 사용합니다. 클라이언트에는 보통 서버 이름과 공개 키 관련 인증 매개변수, 짧은 ID, 구현에서 요구하는 클라이언트 핑거프린트가 필요합니다. 공개 키는 클라이언트 사용자 ID가 아니며 짧은 ID도 임의의 메모가 아닙니다. 클라이언트와 코어에 따라 필드 이름이 바뀔 수 있으므로 가져온 설정과 현재 구현을 기준으로 확인하세요. 오래된 안내서의 필드 위치를 그대로 따라 해서는 안 됩니다.

서버 이름은 핸드셰이크 및 신원 확인 관련 절차에 사용되며 보통 서버에서 허용한 범위 안의 값이어야 합니다. 연결 주소와 텍스트가 완전히 같을 필요는 없지만 임의의 도메인으로 바꾸어도 되는 것은 아닙니다. 연결 주소는 클라이언트가 처음 접속할 대상을 정하고, 서버 이름은 보안 핸드셰이크의 구성과 검증에 영향을 줍니다. 둘을 하나의 ‘도메인’으로 이해하면 문제 해결 방향이 흐려집니다. 주소에 연결할 수 있지만 인증에 실패하는 경우는 계층별 확인이 필요한 대표적인 사례입니다.

Vision·핑거프린트·전송 방식의 조합 제약

XTLS Vision은 보통 flow 필드로 지정하며 대표 값은 xtls-rprx-vision입니다. 특정 연결 조합에서 데이터 흐름을 처리하는 방식이지, 값을 넣을수록 빨라지는 범용 가속 옵션이 아닙니다. 사용 여부는 서버와 코어, 전송 조합에 따라 달라집니다. 특히 직접 전송용 설정을 WebSocket 같은 전송 방식에 그대로 적용하지 마세요. 제공자가 흐름 제어 값을 지정하지 않았다면 다른 설정에 해당 값이 있다는 이유만으로 추가해서는 안 됩니다.

클라이언트 핑거프린트는 TLS 클라이언트 핸드셰이크의 일부 특징을 제어하지만 해당 브라우저를 설치했다는 뜻은 아니며 모든 앱 동작이 바뀌는 것도 아닙니다. 핑거프린트 옵션은 코어의 지원이 필요하며 이름이 같은 UI 항목도 구현에 따라 다르게 처리될 수 있습니다. 연결에 실패하면 먼저 구독에 원래 지정된 값으로 되돌리고 로그의 보안 계층 오류를 확인하세요. 그런 다음 핑거프린트 미지원, 인증 매개변수 오류, 서버 이름 불일치 여부를 판단해야 합니다.

REALITY 또는 Vision이 필요하다면 Android에서는 v2rayNG에 포함된 Xray의 지원 여부를, 데스크톱에서는 v2rayN에서 실제로 활성화된 코어를 먼저 확인하세요. VLESS 설정에 필수 인증 매개변수가 빠져 있다면 추측해서 채우지 말고 공유 설정 전체를 다시 받으세요. 구현 계열의 차이는 코어 계열에서 자세히 확인할 수 있습니다. 프로토콜 이름이 같다는 것은 호환성 확인의 출발점일 뿐입니다.

03 · Trojan과 Shadowsocks

Trojan: TLS 기반 인증과 프록시 요청

Trojan은 TLS 연결 안에서 프록시 인증과 요청을 처리하도록 설계됐으며, 일반적인 설정에서는 비밀번호를 사용자 인증 정보로 사용합니다. 프로토콜 계층과 외부 보안 계층의 경계가 비교적 명확합니다. 설정에 맞는 TLS 연결을 먼저 만든 다음 프록시 요청을 주고받습니다. Trojan을 선택해도 인증서 문제가 저절로 해결되지는 않습니다. 서버 이름과 인증서 신뢰 체인, 기기 시간이 올바른지 확인해야 합니다. 이 중 하나라도 문제가 있으면 프록시 인증이 시작되기 전에 연결이 종료될 수 있습니다.

표준 Trojan 연결에는 보통 VMess와 같은 사용자 ID가 필요하지 않습니다. 다른 프로토콜의 설정을 복사해 관련 없는 필드가 남으면 클라이언트가 이를 무시하거나 잘못된 설정을 만들 수 있습니다. 해당 프로토콜의 서버 항목을 새로 만들고 원본 공유 설정에 따라 비밀번호와 주소, 포트, 보안 매개변수를 입력하세요. 비밀번호에 특수 문자가 있으면 공유 링크를 직접 조합할 때 이스케이프 오류가 나기 쉽습니다. 클라이언트의 가져오기·내보내기 기능을 사용하는 편이 안전합니다.

인증서 검증에 실패했을 때 검증을 건너뛰는 설정을 상시 해결책으로 사용하지 마세요. 먼저 연결 주소와 서버 이름을 혼동하지 않았는지 확인한 뒤 시스템 시간과 인증서 유효 기간, 인증서 체인, 원격 서버의 TLS 제공 여부를 점검하세요. 안전하지 않은 연결을 허용하면 신원 확인 경계가 달라져 잘못된 대상도 연결을 받아들일 수 있습니다. 원인 파악을 위해 잠시 변경해야 한다면 내용을 기록하고 즉시 되돌리세요. 장기적으로는 검증 실패의 근본 원인을 해결해야 합니다.

Shadowsocks: 메서드와 키가 호환성을 결정합니다

Shadowsocks는 흔히 SS라고 부르며 비교적 간결한 암호화 프록시 형식을 사용합니다. VMess나 Trojan과 인증 및 데이터 구성 방식이 다르므로 비밀번호 필드가 비슷하다는 이유로 호환성을 판단할 수 없습니다. SS를 설정할 때는 최소한 서버 주소와 포트, 암호화 메서드, 비밀번호 또는 키를 확인해야 합니다. 메서드 이름은 프로토콜 규약의 일부이지 클라이언트에서 임의로 바꿀 수 있는 선택 사항이 아닙니다. 양쪽에서 알고리즘과 키 해석 방식을 일치시켜야 합니다.

초기 스트림 암호화 방식과 이후 AEAD 방식, Shadowsocks 2022 계열은 설계와 설정 요구 사항이 서로 다릅니다. 최신 배포에서는 현재 구현이 지원하는 AEAD 방식을 우선 고려하는 것이 일반적이지만, ‘SS 지원’이 모든 세대의 방식을 지원한다는 뜻은 아닙니다. 특히 최신 메서드에는 특정 형식과 길이의 키가 필요할 수 있습니다. 아무 짧은 비밀번호나 입력해도 코어가 호환되는 값으로 자동 변환해 줄 것이라고 기대하지 마세요. 정확한 형식은 원격 메서드 안내를 따라야 합니다.

SS 공유 링크에는 과거부터 여러 인코딩 방식이 사용됐습니다. 메서드와 비밀번호를 함께 인코딩하기도 하고 인증 부분을 별도로 인코딩하기도 하며, 뒤에 메모나 플러그인 매개변수가 붙을 수 있습니다. 가져오기에 실패하면 링크가 완전한지, 메신저가 내용을 잘라내지 않았는지 먼저 확인한 뒤 현재 클라이언트가 확장 형식을 지원하는지 살펴보세요. 인코딩된 내용을 여러 번 임의로 디코딩하고 다시 조합하면 특수 문자와 구분자가 손상되어 새로운 오류가 생기기 쉽습니다.

추가 래핑 기능을 프로토콜의 기본 기능으로 여기지 마세요

일부 SS 설정은 별도 플러그인이나 전용 외부 래핑에 의존합니다. 원본 프로토콜 지원과 플러그인 지원은 서로 다른 기능입니다. 그래픽 클라이언트에서 메서드 이름을 인식한다고 해당 플러그인을 실행할 환경까지 갖췄다는 뜻은 아닙니다. 이 가이드에서는 별도 클라이언트를 추천 목록에 포함하지 않습니다. 추가 구성 요소가 필요한 공유 설정이라면 v2rayN, v2rayNG 또는 v2flyNG의 현재 구현이 이를 완전히 처리할 수 있는지 먼저 확인한 뒤 설정을 유지할지 결정하세요.

UDP는 별도로 확인해야 하는 경로입니다. 프로토콜 규격에서 UDP 전달을 허용해도 구독 진입점과 원격 서비스, 클라이언트 모드, 로컬 앱에서 모두 활성화됐다는 뜻은 아닙니다. 웹페이지가 열린다고 일부 TCP 요청만 사용할 수 있음을 확인했을 뿐, 실시간 음성·영상이나 다른 데이터그램 기반 기능이 정상이라는 뜻은 아닙니다. 특정 앱에서 문제가 생기면 대체 경로로 전환됐는지, 대상 포트가 지원되는지, 라우팅 규칙이 두 종류의 트래픽을 서로 다른 아웃바운드로 보내는지 확인하세요.

전체 호환 설정이 이미 갖춰져 있다면 Trojan은 일반적인 TLS 운영 방식을 유지하고 싶은 진입점에 적합합니다. SS는 해당 방식으로 이미 배포되어 있고 메서드 요구 사항을 명확히 알고 있는 환경에 알맞습니다. 포장이 단순해 보인다는 이유만으로 어느 쪽이 더 빠르다고 판단할 수는 없습니다. 프로토콜을 바꿔야 한다면 원격 서버에서 새 프로토콜용으로 실제 제공하는 진입점을 받아야 합니다. 기존 포트를 그대로 둔 채 클라이언트 유형만 바꾸어서는 안 됩니다.

04 · 연결 속도와 리소스, 모바일 배터리

첫 요청과 지속 전송을 나누어 비교하세요

한 번 접속할 때 걸리는 시간에는 DNS 조회와 연결 설정, 보안 핸드셰이크, 프록시 인증, 대상 서버 응답이 모두 영향을 줍니다. 프로토콜은 이 중 일부에만 관여합니다. 짧은 연결이 많은 앱은 핸드셰이크 비용에 민감하고, 대용량 전송은 링크 대역폭과 혼잡 제어, 원격 출구의 제약을 더 많이 받습니다. 프로토콜을 비교하기 전에 페이지 열기와 첫 응답, 지속 전송량 중 무엇을 측정할지 정하세요. 이 지표를 하나의 속도 값으로 뭉뚱그리면 문제가 발생한 계층을 파악할 수 없습니다.

외부 전송 방식은 추가 요청이나 핸드셰이크를 발생시킬 수도 있고 연결 재사용으로 이후 비용을 줄일 수도 있습니다. TLS 활성화, WebSocket 사용, 다중 스트림을 지원하는 전송 방식이 일정한 속도 순서를 뜻하지는 않습니다. 네트워크 왕복 시간이 길면 추가 왕복의 영향이 커질 수 있고, 연결을 재사용하면 새 요청마다 전체 초기화 비용을 부담하지 않을 수 있습니다. 따라서 같은 설정이라도 첫 페이지 로드와 연속 새로고침의 체감은 서로 대체할 수 없습니다.

지속 전송 중 프로세서 부하는 알고리즘 구현과 하드웨어 가속, 버퍼 처리, 데이터 복사 등 여러 요인에 따라 달라집니다. 같은 프로토콜도 데스크톱 프로세서와 모바일 칩에서 병목이 다르게 나타날 수 있습니다. 프로세서가 실제로 계속 바쁘고 네트워크에 여유가 있을 때만 암호화나 래핑 비용을 따져 보세요. 모든 설정이 비슷한 지점에서 멈춘다면 프로토콜 이름을 계속 바꾸기보다 네트워크와 원격 리소스를 먼저 확인해야 합니다.

Mux는 만능 성능 옵션이 아닙니다

Mux는 여러 논리 연결을 더 적은 수의 전송 연결에 담습니다. 연결을 자주 만드는 비용을 낮출 수 있지만 여러 요청이 같은 링크의 지연 영향을 함께 받을 수도 있습니다. 효과는 프로토콜과 전송 방식, 코어 구현, 트래픽 유형에 따라 달라집니다. 일부 조합에는 이미 다중 스트림 기능이 있어 기존 Mux를 추가해도 이점이 없을 수 있고, 특정 흐름 제어 방식은 조합에 제약이 있습니다. 테스트할 때는 기존 설정을 기준으로 삼고 한 번에 재사용 설정 하나만 바꾸세요.

모바일 배터리 소모는 암호화 연산만으로 결정되지 않습니다. VPN 서비스의 상시 실행과 앱의 백그라운드 폴링, DNS 재시도, 네트워크 전환도 프로세서나 무선 모듈을 깨울 수 있습니다. 클라이언트 배터리 사용량이 증가했을 때 다른 앱도 네트워크를 많이 사용 중이라면 먼저 트래픽 발생 원인을 살펴보세요. 앱이 프록시를 통해 통신할 때 발생하는 네트워크 비용 일부가 VPN 서비스 사용량으로 집계될 수 있으므로 시스템 통계의 전체 소모량을 프로토콜 효율 문제로 단정하지 마세요.

백그라운드 제한과 연결 유지, 네트워크 전환

배터리 최적화 제한이 너무 강하면 백그라운드 서비스가 종료되어 연결이 끊긴 뒤 계속 재연결될 수 있습니다. 반대로 제한을 모두 해제하면 불필요한 백그라운드 실행이 길어질 수 있습니다. 먼저 서비스가 실제로 종료되는지 확인한 뒤 클라이언트에 필요한 백그라운드 권한만 조정하세요. 시스템 연결 유지와 Mux, DNS, 앱별 규칙을 한꺼번에 바꾸지 마세요. 여러 변수를 동시에 조정하면 배터리 사용량이 줄어도 업무량이 감소한 것인지 프로토콜 설정이 개선된 것인지 알기 어렵습니다.

Wi-Fi에서 모바일 네트워크로 전환하면 기존 연결을 다시 설정해야 하는 경우가 많고 DNS 캐시와 네트워크 인터페이스 상태도 바뀔 수 있습니다. 이때 잠시 실패한다고 인증 오류인 것은 아닙니다. 네트워크가 안정될 때까지 기다린 뒤 한 번 직접 다시 연결하고 로그가 DNS 조회와 연결, 핸드셰이크 중 어느 단계에서 발생하는지 기록하세요. 특정 네트워크에서만 실패한다면 주소 계열과 경로 MTU, 연결 가능성을 확인하세요. 링크 문제를 가리려고 인증 매개변수를 반복해서 바꾸지 마세요.

재현 가능한 비교를 하려면 기기와 앱, 대상, 네트워크 환경을 고정하고 초기 접속과 연속 요청, 유휴 상태의 백그라운드 동작을 각각 관찰해야 합니다. 매 회차 변수 하나만 바꾸고 연결이 안정될 때까지 기다리세요. 테스트 중에는 백그라운드 다운로드와 시스템 업데이트, 기타 부하가 큰 작업을 피하세요. 모든 사람에게 맞는 순위를 만들 필요는 없습니다. 현재 기기와 해당 업무에서 어떤 설정이 실패와 재연결, 지속적인 리소스 사용을 줄였는지 설명할 수 있는 결과가 중요합니다.

앱별 프록시를 사용하면 프록시가 필요 없는 앱의 트래픽을 VPN을 통해 보내지 않을 수 있지만 앱 간 전환과 로그인 구성 요소, 시스템 서비스 의존성을 고려해야 합니다. 주 앱만 프록시 대상으로 지정하고 인증 구성 요소를 제외하면 페이지는 열려도 로그인이 실패할 수 있습니다. 성능 최적화는 기능이 온전히 작동한다는 전제가 필요합니다. 먼저 필요한 기능이 제대로 동작하는지 확인한 뒤 불필요한 프록시 범위와 백그라운드 활동을 줄이는 편이 더 가벼워 보이는 프로토콜을 고르는 것보다 안정적인 결과를 얻기 쉽습니다.

05 · Project V, V2Fly와 Xray

클라이언트 UI와 코어는 서로 다른 계층입니다

Project V는 V2Ray 생태계를 이해하는 배경입니다. V2Fly는 V2Ray의 커뮤니티 개발을 이어가고, Xray는 관련 코드 체계에서 분리되어 자체 기능 방향으로 발전했습니다. 역사와 설정 개념 일부를 공유하지만 같은 프로그램의 다른 이름으로 볼 수는 없습니다. 프로토콜 이름과 JSON 필드, 디렉터리 구조가 비슷하다는 것은 공통 기반이 있음을 나타낼 뿐, 새 기능이 두 구현에 동시에 들어가거나 같은 설정이 항상 똑같이 동작한다는 뜻은 아닙니다.

그래픽 클라이언트는 구독 관리와 설정 편집, 라우팅 선택, 시작 제어를 맡고 코어는 실제 연결과 트래픽 전달을 담당합니다. UI에 선택지가 있어도 실제 실행은 선택한 코어의 지원 범위에 따릅니다. 입력란에 값을 넣을 수 있다고 코어가 이를 받아들인다는 뜻은 아닙니다. 설정을 저장할 수 있어도 해당 값이 최종 실행 파일에 전달된다는 보장도 없습니다. 문제를 해결할 때는 창 제목만 보지 말고 클라이언트와 코어 계열, 실제 적용된 설정을 모두 확인해야 합니다.

세 클라이언트의 선택 범위

데스크톱에서는 Windows와 macOS, Linux 설치 경로를 제공하는 v2rayN을 우선 추천합니다. 구독과 라우팅, 데스크톱 프록시를 통합 관리하는 데 적합하지만 운영체제에 따라 UI 세부 사항과 시스템 통합 방식은 다를 수 있습니다. 프로토콜 기능과 관련된 문제는 현재 활성화된 코어와 실제 포함된 구성 요소를 확인하세요. 다른 기기의 v2rayN에서 특정 조합이 작동한다고 현재 설치에도 같은 기능이 있다고 단정할 수 없습니다.

Android용 v2rayNG는 Xray 코어를 사용하며 해당 프로토콜 조합이 필요한 설정에 적합합니다. v2flyNG는 V2Fly 코어를 사용하므로 해당 구현이 필요한 경우 대안으로 쓸 수 있습니다. 이름이 비슷하다는 이유로 자유롭게 바꿔 쓰기보다 기존 설정에 필요한 기능을 기준으로 선택하세요. 구독에서 REALITY나 Vision을 명시했다면 Xray 경로를 우선 확인하세요. V2Fly 설정을 유지 중이라면 V2Fly의 현재 필드와 동작 기준으로 살펴봐야 합니다.

두 코어 계열 모두 널리 쓰이는 프로토콜과 전송 방식을 지원하지만 지원 범위와 세부 의미는 구현에 따라 발전합니다. REALITY와 Vision은 Xray 지원 여부를 확인할 때 중요한 항목이며, 해당 필드가 있는 아웃바운드를 V2Fly에 그대로 전달해서는 안 됩니다. 반대로 V2Fly 전용 전송 방식이나 설정 구조도 Xray에서 호환된다고 가정하지 마세요. 코어를 바꿀 때는 항목별로 확인해야 합니다. 파일 전체를 덮어쓴 뒤 실행 여부만 보는 것은 적절한 검증이 아닙니다.

설정을 이전할 때 구조와 의미를 함께 확인하세요

코어 설정에는 보통 인바운드와 아웃바운드, 라우팅, DNS, 로그 등이 포함됩니다. 아웃바운드만 복사하면 해당 아웃바운드 태그를 참조하는 라우팅이나 DNS 정책이 빠질 수 있습니다. 전체 설정을 복사하면 현재 기기에 없는 수신 주소와 포트, 파일 경로가 따라올 수 있습니다. 사용할 수 있는 백업을 먼저 보관한 뒤 모듈별로 옮기세요. 필드 검증에 통과해도 대상 트래픽이 의도한 아웃바운드로 전달되는지, DNS 조회가 기존 정책을 따르는지 확인해야 합니다.

로그에 표시되는 알 수 없는 필드와 인식할 수 없는 보안 유형, 미지원 흐름 제어는 호환성 문제를 찾는 단서입니다. 오류를 없애려고 해당 필드를 삭제해서는 안 됩니다. 중요한 필드를 지우면 프로그램은 시작되더라도 연결에 필요한 의미가 사라질 수 있습니다. 먼저 해당 필드를 어느 구현이 제공하는지 확인한 다음 호환되는 코어를 쓰거나 현재 코어에 맞는 설정을 다시 받아야 합니다. 무작정 필드를 삭제하는 것보다 두 방법이 문제를 설명하고 관리하기 쉽습니다.

클라이언트 업데이트와 코어 업데이트도 구분해야 합니다. UI 업데이트는 가져오기 파싱 문제를 해결할 수 있고 코어 업데이트는 프로토콜 지원을 바꿀 수 있습니다. 두 업데이트가 해결하는 문제는 서로 다릅니다. 업데이트 전에 구독과 로컬 규칙을 보관하고, 업데이트 후에는 알려진 설정 하나를 테스트한 다음 복잡한 라우팅을 복원하세요. 문제가 다시 생기면 단순히 ‘업데이트 후 작동하지 않음’이라고 기록하지 말고 발생 단계와 필드를 적으세요. 코어 계열에 관한 자세한 설명은 Xray와 V2Fly의 차이 및 설정 호환성을 참고하세요.

06 · 전송 설정과 라우팅, DNS

경로와 Host, 서버 이름은 각각 역할이 다릅니다

전송 방식은 프록시 데이터가 어떤 형식으로 전달되는지 정합니다. TCP 직접 연결은 구조가 비교적 단순하고 WebSocket은 HTTP 업그레이드 절차를 거칩니다. gRPC 등은 각자의 요청 및 다중 스트림 의미를 가집니다. 이런 방식은 클라이언트가 임의로 선택하는 장식 옵션이 아니라 원격 진입점의 일부입니다. 서버가 특정 전송만 받는다면 로컬에서 다른 방식으로 바꿀 경우 인증 전에 실패하는 것이 일반적입니다. 성능을 비교하기 전에 비교 대상 조합이 실제로 존재하는지 확인해야 합니다.

WebSocket 경로는 요청 라우팅에 사용되고 Host는 리버스 프록시의 가상 호스트 선택에 영향을 줄 수 있으며, TLS 서버 이름은 보안 핸드셰이크에 쓰입니다. 세 값은 같을 수도, 배포 방식에 따라 다를 수도 있습니다. 경로의 대소문자와 앞쪽 슬래시, 특수 문자는 그대로 보존해야 합니다. 리버스 프록시가 요청을 올바른 백엔드로 전달하지 않으면 인증서 핸드셰이크에 성공하더라도 일반 웹페이지나 오류 응답을 받을 수 있습니다. 이를 프록시 프로토콜이 정상이라는 근거로 삼아서는 안 됩니다.

gRPC에서 흔히 사용하는 서비스 이름도 원격 설정과 일치해야 하며 클라이언트에서 보기 편하게 붙이는 메모가 아닙니다. ALPN은 보안 연결에서 애플리케이션 프로토콜을 협상하는 데 사용됩니다. 후보를 잘못 제한하면 필요한 전송을 설정하지 못할 수 있습니다. 배포 안내에서 명시적으로 요구하지 않는 한 다른 노드의 ALPN 목록을 그대로 가져오지 마세요. 주소 연결과 보안 핸드셰이크, 전송 프로토콜, 프록시 인증 순서로 점검해 먼저 실패한 계층을 찾은 뒤 해당 필드를 조정하세요.

라우팅 순서에 따라 프로토콜의 적용 범위가 달라집니다

프록시 아웃바운드 하나를 선택했다고 모든 트래픽이 이를 사용하는 것은 아닙니다. 시스템 프록시와 VPN 가로채기, 앱 자체 프록시, 코어 라우팅이 트래픽 경로를 함께 결정합니다. 시스템 프록시는 관련 설정을 따르는 앱에만 적용됩니다. VPN 또는 가상 네트워크 인터페이스 모드는 더 넓은 범위의 트래픽을 처리하지만 제외 설정과 권한의 영향을 받습니다. 특정 앱만 계속 다르게 동작한다면 먼저 요청이 클라이언트에 도달하는지 확인하세요. 진입점 문제를 해결하기 전에 아웃바운드 프로토콜부터 살펴보느라 시간을 낭비하지 마세요.

라우팅 규칙은 대개 순서대로 적용됩니다. 범위가 넓은 규칙을 앞에 두면 뒤의 세부 규칙이 적용되지 않을 수 있으며 기본 아웃바운드는 일치하지 않은 트래픽을 처리합니다. 아래는 규칙 일부일 뿐 독립 실행 가능한 전체 설정이 아닙니다. 기존 direct 및 block 아웃바운드와 해당 규칙 리소스가 필요합니다. 합칠 때 태그가 실제로 존재하는지 확인하세요. JSON 문법이 유효하다는 이유만으로 파일 전체를 바꾸어도 된다고 판단해서는 안 됩니다.

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

DNS와 아웃바운드는 함께 검증해야 합니다

DNS 설정은 리졸버 주소 하나를 입력하는 것으로 끝나지 않습니다. 누가 조회 요청을 보내는지, 어느 아웃바운드를 통해 전송하는지, 응답 주소가 이후 라우팅에 어떻게 쓰이는지 확인해야 합니다. 앱이 자체 암호화 DNS를 사용하거나 시스템에 별도의 조회 경로가 남아 있을 수 있습니다. 따라서 코어의 DNS 설정이 반드시 해당 요청을 처리하는 것은 아닙니다. 클라이언트에 원격 DNS를 지정한 뒤에도 실제 요청 경로를 확인해야 합니다. 설정 페이지의 문구만 보고 DNS 조회가 프록시를 따른다고 판단할 수 없습니다.

원격 DNS에는 시작 단계의 의존성 문제가 생길 수도 있습니다. 프록시 서버가 도메인 주소를 사용하고 그 도메인을 조회하는 DNS 서버가 아직 연결되지 않은 프록시를 통해서만 접근 가능하다면 순환 의존성이 발생합니다. 서버 도메인을 조회할 수 있는 명확한 경로를 지정하고, 이 시작 경로가 모든 업무 도메인 조회까지 처리하지 않도록 주의하세요. 서버 주소 조회와 대상 사이트 조회를 구분하면 캐시를 지운 뒤에야 일부 설정의 문제가 드러나는 이유를 파악하는 데 도움이 됩니다.

FakeDNS는 합성 주소를 사용해 도메인과의 연결 정보를 유지합니다. 특정 트래픽 가로채기 및 라우팅 조합에 적합하지만 켜기만 하면 DNS 유출이 막히는 기능은 아닙니다. 합성 주소는 이를 인식할 수 있는 처리 경로로 돌아가야 합니다. 관련 없는 앱이나 아웃바운드가 이를 실제 주소로 취급하면 연결에 실패합니다. 캐시와 주소 계열, 규칙도 함께 맞춰야 합니다. 구체적인 확인 방법은 DNS 요청 경로 점검과 설정 방법을 참고하고 변경 전에 기존 설정을 저장하세요.

전송과 DNS 설정을 바꾼 뒤에는 도메인 접속과 조회가 필요한 프록시 진입점, 업무에 필요한 데이터그램 연결을 각각 확인하세요. 웹페이지 하나만 테스트하면 캐시가 DNS 문제를 가릴 수 있고 연결 재사용이 핸드셰이크 문제를 숨길 수 있습니다. 새 연결을 한 번 이상 생성하고 로그에서 일치한 아웃바운드 태그도 확인해야 합니다. 그래야 프로토콜 미지원과 라우팅 규칙 미일치, DNS 경로 오류라는 흔한 원인을 구분할 수 있습니다.

07 · 구독 형식과 클라이언트 간 호환성

구독은 배포 형식이지 통신 프로토콜이 아닙니다

구독 링크는 서버 설정 묶음을 가져오는 데 사용되며 클라이언트는 이를 실제 실행 설정으로 변환합니다. 구독 자체가 데이터 전송 방식을 정의하는 것은 아니며 구독의 모든 항목이 현재 코어에 적합하다는 뜻도 아닙니다. 업데이트에 성공했다는 것은 콘텐츠를 가져와 파싱하는 과정의 일부가 완료됐다는 의미일 뿐입니다. 이후에는 항목 수 외에도 프로토콜 유형과 보안 매개변수 보존 여부, 현재 코어의 필드 해석 가능 여부를 확인해야 합니다.

일반적인 구독 콘텐츠에는 줄마다 공유 링크가 나열된 형식과 인코딩된 링크 모음, 특정 구현용 전체 설정이 있습니다. 확장자나 URL 모양만으로 실제 형식을 판단할 수 없으며 클라이언트는 응답 내용을 기준으로 인식해야 합니다. 응답이 웹페이지와 로그인 안내, 오류 문구라면 여러 번 복사해도 구독 데이터가 되지 않습니다. 문제를 해결할 때는 먼저 출처에 인증이 필요한지, 응답이 약속된 형식인지 확인한 뒤 파싱 호환성을 살펴보세요. 클라이언트 재설치를 먼저 해서는 안 됩니다.

접두사를 인식해도 설정의 의미가 모두 보존되는 것은 아닙니다

VMess 공유 데이터에는 구조화된 필드가 들어가는 경우가 많고 VLESS와 Trojan 공유 링크는 주소와 쿼리 매개변수로 보안 및 전송 설정을 설명합니다. SS는 과거부터 서로 다른 인코딩 방식이 사용됐습니다. 클라이언트마다 별칭과 선택 매개변수, 확장 필드의 지원 범위가 다를 수 있습니다. 가져오기 도구가 알 수 없는 매개변수를 무시해도 완성된 것처럼 보이는 항목을 만들 수 있습니다. 따라서 클라이언트 간 이전 후에는 이름과 주소만 보지 말고 편집 화면에서 각 항목을 대조해야 합니다.

서버 이름과 흐름 제어, 핑거프린트, 짧은 ID, 전송 경로, 서비스 이름이 특히 누락되기 쉽습니다. 일부 매개변수는 특정 보안 또는 전송 유형에서만 표시되므로 유형을 잘못 인식하면 후속 필드가 숨겨지거나 지워질 수 있습니다. 원본 공유 설정에 필드가 있는데 UI에 해당 항목이 없다면 먼저 클라이언트와 코어의 지원 여부를 확인하세요. 알 수 없는 매개변수를 메모에 넣거나 모양이 비슷한 다른 입력란으로 대체하지 마세요.

구독은 보통 연결 진입점을 설명할 뿐 전체 라우팅과 DNS, 시스템 프록시, 앱별 규칙까지 포함하지는 않습니다. 두 기기에 같은 구독을 가져와도 로컬 정책이 동기화되지 않아 접속 동작이 다를 수 있습니다. 특히 데스크톱에서 Android로 옮길 때는 이 두 부분을 구분하세요. 먼저 서버 설정을 옮긴 다음 라우팅과 VPN 설정을 따로 확인해야 합니다. 이전 절차는 여러 기기에서 구독·공유 코드·백업 설정을 옮기는 방법을 참고하세요.

업데이트와 그룹, 로컬 수정의 범위

자동 업데이트는 일반적으로 구독 소스에서 해당 그룹의 항목을 다시 생성합니다. 로컬에서 직접 바꾼 내용은 다음 업데이트 때 사라질 수 있으며 실제 동작은 클라이언트에 따라 다릅니다. 실험 설정을 계속 유지하려면 명확한 수동 그룹에 복사하고 구독의 원본 항목과 어떤 관계인지 기록하세요. 출처가 불분명한 수정 설정을 같은 그룹에 섞어 두고 메모만으로 업데이트 적용 여부를 추측해서는 안 됩니다. 업데이트 전후에는 정렬 순서뿐 아니라 중요한 보안 매개변수도 확인하세요.

구독 필터와 메모용 정규식은 항목이 목록에 표시되는 방식에만 영향을 주며 프로토콜 사용 가능 여부를 자동으로 검사하지 않습니다. 필터 조건이 지나치게 엄격하면 정상적인 진입점이 제외될 수 있으며 이름이 비슷해도 설정까지 같다는 보장은 없습니다. ‘업데이트 후 서버가 보이지 않음’ 문제라면 필터를 끄고 그룹을 확인한 다음 구독에서 실제로 항목이 삭제됐는지 판단하세요. 표시 문제를 코어 오류로 오해하지 않도록 구독 그룹과 서버 필터 안내를 참고하세요.

QR 코드는 텍스트를 담는 또 다른 방식일 뿐 프로토콜 지원을 늘려 주지 않습니다. QR 스캔 실패는 이미지 인식 문제일 수 있고 스캔에 성공한 뒤 가져오기가 실패하면 텍스트 형식 문제일 수 있으므로 따로 살펴봐야 합니다. 기기에서 인식 결과의 프로토콜 접두사와 구조를 먼저 확인하고 인증 정보가 포함된 내용을 알 수 없는 변환 서비스에 올리지 마세요. 긴 공유 문자열을 메신저로 전달할 때 줄바꿈과 문장부호 변경, 끝부분 잘림에도 주의해야 합니다.

신뢰할 수 있는 이전 기록에는 서버 목록 화면뿐 아니라 출처 유형과 클라이언트, 코어 계열, 주요 설정 조합이 포함돼야 합니다. 이전한 뒤에는 구조가 단순하고 출처가 분명한 설정 하나를 먼저 검증한 다음 일괄 가져오기를 진행하세요. 검증이 끝나면 필터와 자동 업데이트, 복잡한 규칙을 복원할 수 있습니다. 실패하면 가져오기와 파싱, 설정 생성, 실행, 핸드셰이크의 다섯 단계를 따라 원인을 찾으세요. 모든 설정을 반복해서 바꾸면 최초 오류의 단서를 잃기 쉽습니다.

08 · 사용 환경에 맞는 설정 선택

제약 조건부터 정리한 뒤 프로토콜을 비교하세요

선택의 첫 기준은 속도 순위가 아니라 현재 원격 서버에서 어떤 진입점을 제공하는지입니다. 다음으로 기기 운영체제와 클라이언트, 코어 계열, 필요한 서비스, 유지 관리 방식을 확인하세요. 서버가 완전한 설정 하나만 제공한다면 다른 프로토콜을 요청하기 전에 우선 해당 설정을 올바르게 작동시켜야 합니다. 클라이언트는 원격 기능을 새로 만들어낼 수 없습니다. 로컬에서 프로토콜 유형만 바꾸면 대개 이를 받아 줄 서버가 없는 설정이 만들어집니다.

데스크톱에서는 v2rayN을 사용해 원본 구독을 가져오고 설정은 기본값을 유지하는 것부터 시작할 수 있습니다. REALITY나 Vision이 필요하다면 해당 조합을 지원하는 Xray 경로를 선택했는지 확인하세요. 기존 VMess와 Trojan, SS 설정이 안정적으로 작동한다면 이름을 통일하려고 이전할 필요 없이 구체적인 필드와 코어 지원만 확인하면 됩니다. 설치 파일과 시스템 아키텍처 선택은 다운로드 페이지에서 확인하세요. 이 페이지에서는 설치 후 설정이 호환되는지 판단하는 방법을 다룹니다.

Android와 배터리 사용에 민감한 환경

Android에서 Xray 기능이 필요하다면 v2rayNG를 먼저 확인하세요. V2Fly 설정을 유지한다면 v2flyNG를 선택하고 해당 구현에 맞춰 매개변수를 확인할 수 있습니다. 첫 테스트에서는 Mux와 앱별 규칙을 원인을 파악하기 쉬운 상태로 유지한 뒤 조금씩 조정하세요. 백그라운드 연결이 끊기면 시스템이 VPN 서비스를 종료하는지 먼저 확인해야 합니다. 연결은 안정적인데 배터리 소모가 늘었다면 앱 요청과 네트워크 재설정 횟수를 살펴보세요. 시스템 스케줄링 문제를 프로토콜 헤더 비용으로 오해하지 마세요.

배터리에 민감한 기기에서는 필드를 최소화하는 데 집중하기보다 불필요한 지속 네트워크 활동을 줄여야 합니다. 안정적으로 연결되고 재연결이 적으며 필요한 업무를 지원하는 조합을 선택한 뒤 실제 앱 사용 범위에 맞춰 앱별 프록시를 설정하세요. 실시간 음성·영상이나 데이터그램이 필요한 경우 UDP 경로를 따로 확인해야 합니다. 웹페이지 접속만 필요하다면 일반적인 웹 요청으로 기준을 잡을 수 있지만 이 결과를 모든 앱이 사용 가능하다는 뜻으로 확대해서는 안 됩니다.

기존 안정 설정과 새 배포 설정은 판단 기준이 다릅니다

이미 안정적으로 작동하는 설정이라면 유지 관리 비용도 결정에 포함해야 합니다. 프로토콜을 바꾸면 원격 진입점과 보안 매개변수, 구독 생성, 모든 기기의 호환성까지 조정해야 할 수 있지만 프로토콜 자체에서 얻는 이점은 없을 수도 있습니다. 현재 코어에 필요한 기능이 없거나 핸드셰이크 비용이 실제 병목이거나 기존 방식의 유지 관리가 어려워지는 등 명확한 이유가 있을 때 이전 목표가 생깁니다. 막연히 ‘최신으로 바꾸기’가 아니라 테스트로 확인할 수 있는 목표를 정해야 합니다.

새로 배포할 때는 양쪽에서 명시적으로 지원하고 문서가 충분하며 점검하기 쉬운 조합을 우선하세요. 일반적인 TLS 운영 방식을 원한다면 Trojan이나 이에 맞는 VLESS 조합을 검토할 수 있습니다. SS 기반 환경이 있다면 최신 메서드와 키 형식, 데이터그램 지원을 확인하세요. VMess를 사용할 때는 최신 인증 방식과 시간 동기화를 확인해야 합니다. REALITY를 선택한다면 클라이언트에 해당 이름이 표시되는지만 볼 것이 아니라 Xray 지원 여부와 인증 매개변수 관리 방식도 함께 살펴야 합니다.

오류 발생 단계에 따라 선택 범위를 좁히세요

가져오기 단계에서 실패하면 공유 형식과 클라이언트 파싱을 먼저 살펴보세요. 코어가 시작되지 않으면 필드 구조와 기능 지원을 확인해야 합니다. 주소에 연결할 수 없다면 DNS 조회와 포트, 네트워크 경로를 점검하세요. 보안 핸드셰이크가 실패하면 서버 이름과 인증서 또는 REALITY 매개변수를 확인합니다. 핸드셰이크에 성공했지만 앱이 작동하지 않으면 프록시 인증과 라우팅, 트래픽 가로채기 범위를 살펴보세요. 각 단계마다 확인할 증거가 다릅니다. 모두 ‘프로토콜 문제’로 묶어 설정 전체를 바꾸지 마세요.

정상 작동이 확인된 설정 하나를 보존해 두면 큰 도움이 됩니다. 이를 기준으로 문제 원인이 기기 전체인지 현재 네트워크인지 특정 진입점인지 판단할 수 있습니다. 비교할 때 네트워크와 코어, 프로토콜을 동시에 바꾸지 마세요. 원래 환경에서 다시 테스트한 다음 하나씩 변경해야 합니다. 로그를 공유할 때 인증 정보는 숨기되 오류 발생 순서와 유형은 남겨 두세요. 단계별로 기준 설정을 다시 만들려면 사용 가이드를 참고하고 구체적인 문제는 FAQ에서 유형별로 찾아보세요.

모든 환경에 적용되는 단 하나의 프로토콜 선택법은 없습니다. 관리하기 좋은 설정은 각 핵심 필드의 출처를 설명할 수 있고 트래픽이 어떤 방식으로 코어에 들어오는지 알며 DNS 조회 실패와 핸드셰이크 실패를 구분하고 업데이트 뒤 기본 테스트를 재현할 수 있는 설정입니다. 프로토콜과 보안 계층, 전송 방식, 로컬 정책을 각각 관리하되 전체 연결은 함께 검증하세요. 그래야 기기를 옮기거나 코어를 바꿔도 한 번 우연히 성공한 연결에 기대지 않고 안정적인 동작을 유지할 수 있습니다.