V2Ray 프로토콜 및 코어 가이드

연결 계층: 먼저 설정이 어느 계층에 속하는지 확인하세요

클라이언트, 코어, 서버는 서로 다른 구성 요소입니다

그래픽 클라이언트는 서버 정보를 저장하고 구독 그룹을 관리하며 설정 파일을 생성하고 로그를 표시합니다. 코어는 생성된 설정을 읽어 로컬 인바운드와 라우팅을 처리하고 원격 연결을 맺어 데이터를 전달합니다. 서버는 원격 연결을 받아 약속된 방식으로 인증합니다. 인터페이스에 프로토콜 이름이 표시된다는 것은 해당 설정 항목을 제공한다는 뜻일 뿐입니다. 실제 사용 가능 여부는 선택한 코어의 지원 여부와 서버에서 같은 조합을 활성화했는지에 달려 있습니다.

데스크톱에서는 애플리케이션의 요청이 먼저 시스템 프록시로 전달되고, 시스템 프록시는 클라이언트가 만든 로컬 수신 포트를 가리킵니다. 코어는 대상 주소를 확인한 뒤 직접 연결할지 원격 아웃바운드로 보낼지 결정하고, 그다음 원격 프로토콜 연결을 맺습니다. 안드로이드 VPN 모드에서는 시스템이 제공하는 가상 네트워크 인터페이스로 앱 트래픽을 받습니다. 진입 방식은 다르지만 이후의 프로토콜 인증 정보는 각각 일치해야 합니다. ‘시스템 프록시 사용’이 켜졌다고 해서 원격 연결까지 성공한 것은 아닙니다.

연결 설정은 네 가지 정보로 나눠 확인하세요

첫째는 서버 주소와 포트로, 어디에 연결할지 정합니다. 둘째는 프록시 프로토콜과 인증 정보입니다. 예를 들어 VMess의 사용자 ID나 Trojan의 비밀번호가 상대편의 요청 식별 방식을 결정합니다. 셋째는 프록시 데이터를 하위 연결에 실어 나르는 전송 설정입니다. 넷째는 TLS, 서버 이름, 인증서 검증 또는 REALITY 매개변수와 관련된 보안 설정입니다. 이 가운데 어느 하나라도 맞지 않으면 연결 시간 초과나 핸드셰이크 실패가 발생할 수 있습니다.

‘VLESS + TLS’는 계층을 조합한 구성입니다. VLESS는 프록시 요청 형식과 인증을 처리하고 TLS는 바깥쪽 전송을 보호합니다. WebSocket은 전송 방식이므로 사용자 인증을 대신하지 않습니다. REALITY는 보안 메커니즘이며, 서버 목록에 단독으로 입력할 수 있는 완전한 인증 정보 묶음도 아닙니다. 구독이나 가이드를 볼 때 용어가 어느 계층에 속하는지 먼저 파악하면 엉뚱한 화면에서 설정을 찾는 일을 줄일 수 있습니다.

연결 주소와 서버 이름은 서로 다를 수 있습니다

서버 주소는 실제 네트워크 연결에 사용되고, TLS 서버 이름은 협상과 신원 확인에 사용됩니다. 배포 방식에 따라 둘이 같을 수도, 다를 수도 있습니다. 주소를 IP로 바꿨다고 서버 이름까지 지워서는 안 됩니다. 반대로 서버 이름을 올바르게 입력해도 임의의 주소에 연결할 수 있는 것은 아닙니다. 리버스 프록시를 사용하는 경우에는 전송 경로와 호스트 필드, 서비스 이름도 해당 배포 환경의 진입 규칙에 맞아야 합니다.

포트 번호만 보고 용도를 판단해서도 안 됩니다. 같은 포트에서 여러 종류의 서비스를 제공할 수 있으며, 특정 포트 번호가 보인다고 TLS가 반드시 활성화되어 있는 것은 아닙니다. 클라이언트의 ‘안전하지 않은 연결 허용’은 대개 인증서 검증과 관련된 옵션이지, 호환성을 높이는 만능 설정이 아닙니다. 정상적인 구성에서는 신원 확인을 유지하세요. 인증서 오류가 나면 검증을 끄기보다 시스템 시간과 서버 이름, 신뢰 체인을 먼저 확인해야 합니다.

실제 점검에서는 클라이언트 이름, 코어 이름, 프로토콜, 전송 방식, 보안 유형을 먼저 기록한 뒤 서비스 제공자가 안내한 전체 설정과 대조하세요. 한 번에 한 항목만 바꾸고 저장 후 다시 연결해 같은 시점의 로그를 확인합니다. 원본 구독은 작동하지만 수동으로 만든 설정은 작동하지 않는다면 누락된 항목부터 비교하세요. 라우팅 규칙을 먼저 바꾸지는 마세요. 계층별로 기록해 두면 특정 버튼 위치를 외우는 것보다 오랫동안 참고하기 좋습니다.

VMess와 VLESS: 인증과 암호화의 차이

VMess는 프로토콜 내부에서 더 많은 역할을 처리합니다

VMess는 Project V 생태계에서 초기에 널리 사용된 프록시 프로토콜로, 설계 단계부터 사용자 인증과 데이터 보호를 프로토콜 자체에 포함했습니다. 사용자 ID는 보통 UUID 형태이며, 클라이언트에 암호화 방식 등의 항목이 표시되기도 합니다. 최신 설정은 서버가 지원하는 인증 방식에 맞춰야 합니다. 오래된 가이드를 보고 구식 매개변수를 그대로 입력하지 마세요. 특히 alterId가 이전 공유 자료에 남아 있더라도 0이 아닌 값을 새로 설정해야 한다는 뜻은 아닙니다.

VMess 연결 인증은 시간과 관련이 있으므로 기기의 시간이 크게 어긋나면 정보가 맞아 보여도 인증이 실패할 수 있습니다. 문제를 해결할 때는 먼저 운영체제에서 날짜와 시간, 시간대의 자동 설정을 켠 뒤 다시 연결하세요. 화면에 표시되는 시간대가 다르다고 해서 시계가 반드시 틀린 것은 아닙니다. 중요한 것은 시스템의 실제 시간이 정확한지입니다. 같은 설정이 다른 기기에서 작동한다면 사용자 ID를 계속 복사하기보다 기기 시간과 코어 지원 여부를 먼저 비교하세요.

VMess 자체에 데이터 보호 기능이 있다고 해서 바깥쪽 TLS가 항상 불필요한 것은 아닙니다. 외부 보안 계층과 전송 방식, 프록시 프로토콜은 각각 역할이 있으며 구체적인 조합은 서버 배포 설정에 따라 달라집니다. 완성된 구독을 제공받았다면 원래 조합을 유지하고 가져온 결과를 확인하는 것이 올바른 방법입니다. ‘암호화’라는 말을 보고 TLS 설정을 삭제하지 마세요. 계층을 임의로 줄여도 연결이 가벼워지는 대신 서버가 수신하지 않는 연결 방식이 될 수 있습니다.

VLESS는 프로토콜 자체를 간소화하지만 전체 연결 경로까지 단순해지는 것은 아닙니다

VLESS는 프로토콜 자체의 역할을 줄이는 설계로, 프로토콜 내부에서 VMess와 같은 데이터 암호화 계층을 제공하지 않습니다. 사용자 인증에는 여전히 올바른 ID가 필요하며, 연결 데이터의 보안은 보통 함께 사용하는 보안 메커니즘이 담당합니다. 인터페이스의 encryption 값이 none인 것은 해당 프로토콜 필드의 규칙을 나타내며, 외부 보안을 끄라는 뜻이 아닙니다. 네트워크를 통해 연결할 때는 서버가 명시적으로 지원하는 전체 보안 조합을 사용해야 합니다.

따라서 ‘VLESS는 VMess보다 계층이 하나 적으니 모든 상황에서 더 빠르다’는 말은 맞지 않습니다. 웹페이지를 여는 과정에는 DNS 조회와 연결 수립, 외부 보안 협상, 서버 처리, 대상 사이트의 응답이 모두 포함됩니다. 프로토콜 헤더의 차이는 그중 일부에 불과합니다. 짧은 연결은 핸드셰이크의 영향을 더 받을 수 있고, 장시간 전송은 회선 용량이나 기기의 암호화 처리 성능에 더 좌우될 수 있습니다. 같은 프로토콜도 회선이 달라지면 그 차이가 프로토콜 자체의 차이보다 훨씬 클 수 있습니다.

flow는 호환 조건이지 범용 속도 향상 버튼이 아닙니다

일부 VLESS 구성에는 특정 흐름 제어 방식과 함께 사용하는 flow 값이 포함됩니다. 이 항목은 클라이언트 코어와 서버 설정, 전송 방식, 보안 조합의 요구 사항을 모두 충족해야 합니다. 구독에 없는 값을 가이드 화면에 보인다는 이유만으로 추가하지 마세요. 구독에 포함된 값이 가져온 뒤 사라졌다면 공유 형식이나 파서가 해당 항목을 유지하는지 확인해야 합니다. 프로토콜 드롭다운만 바꿔서는 유효한 흐름 제어 조합이 자동으로 만들어지지 않습니다.

수동 점검은 ‘프로토콜 유형, 사용자 ID, 암호화 항목, 전송 방식, 보안 설정, 흐름 제어’ 순으로 진행하세요. 먼저 프로토콜 드롭다운을 확인하고 UUID 앞뒤에 불필요한 공백이 없는지 살펴본 다음 전송과 보안 설정을 확인합니다. 로그에 알 수 없는 항목이나 지원되지 않는 흐름 제어가 표시되면 클라이언트 인터페이스에 해당 옵션이 있는지만 보지 말고 실제 실행 중인 코어부터 확인하세요. 인터페이스에서 편집할 수 있는지와 실행 시 인식되는지는 별개의 조건입니다.

안정적으로 작동하는 VMess 설정이 있다면 프로토콜 이름만 바꾸기 위해 이전할 필요는 없습니다. 새 설정이 VLESS를 제공한다면 코어 지원 여부와 보안 조합을 확인한 뒤 실제 앱으로 테스트하세요. 자세한 비교는 VMess와 VLESS의 암호화 방식 및 호환성에서 확인할 수 있습니다. 목표는 항목이 빠짐없고 서버가 지원하며 관리하기 쉬운 설정을 마련하는 것이지, ‘간단하다’는 말만 믿고 다른 계층을 확인하지 않는 것이 아닙니다.

Trojan, SS와 REALITY: 프로토콜과 보안 메커니즘 구분하기

Trojan은 올바른 TLS 연결이 전제입니다

Trojan은 TLS로 보호되는 연결에서 프록시 인증을 수행합니다. 그래픽 설정에는 보통 주소와 포트, 비밀번호, 서버 이름이 포함됩니다. 바깥쪽 TLS가 중요한 기반이므로 비밀번호가 맞는 것만으로 연결이 보장되지는 않습니다. 서버 인증서 이름과 시스템 신뢰 설정, 실제 연결 엔드포인트가 모두 일치해야 합니다. 클라이언트가 먼저 인증서 오류를 보고한다면 프록시 비밀번호 인증에 도달하기 전의 문제이므로 비밀번호를 바꿔도 해결되지 않습니다.

Trojan 비밀번호는 온전한 문자열로 저장하고 복사할 때 앞뒤 공백과 줄바꿈, 링크에 인코딩된 문자를 확인하세요. 일부 공유 링크는 특수 문자를 퍼센트 인코딩하며, 클라이언트가 해당 형식에 맞춰 파싱해야 합니다. 직접 수정할 때 이미 디코딩된 비밀번호를 근거 없이 다시 이스케이프하지 마세요. 링크에서 필드 구분에 쓰이는 기호를 비밀번호의 일부로 취급해서도 안 됩니다. 먼저 원본 링크를 그대로 가져온 뒤 직접 입력한 결과와 비교하는 것이 좋습니다.

Shadowsocks는 암호화 방식과 비밀번호를 함께 확인해야 합니다

Shadowsocks는 보통 SS로 줄여 쓰며, 비교적 간단한 암호화 프록시 설계에서 출발했습니다. 설정에서는 서버 주소와 포트, 암호화 방식, 비밀번호를 확인해야 합니다. 암호화 방식은 사용자가 임의로 고르는 취향 설정이 아니라 양쪽이 함께 사용하는 통신 규약의 일부입니다. 비밀번호가 맞더라도 방식이 다르면 데이터를 제대로 복호화할 수 없습니다. 오래된 자료에 적힌 방식 이름만으로 현재 모든 코어가 지원한다고 판단하지 말고 실제 구현과 서버 설정을 확인하세요.

기존 AEAD 방식과 Shadowsocks 2022 계열은 키 요구 사항이 서로 다릅니다. 후자는 길이와 인코딩 규칙을 충족하는 키가 필요할 수 있으므로 일반 비밀번호를 입력해 자동으로 호환되리라 기대해서는 안 됩니다. 공유 형식에 확장 매개변수가 포함될 수도 있지만, 세 클라이언트가 이를 모두 인식하는 것은 아닙니다. 가져오기는 성공했는데 연결이 실패한다면 목록에 서버 이름이 표시되는지만 보지 말고 방식 이름과 키 형식, 코어 지원 여부를 확인하세요.

REALITY는 보안 계층의 메커니즘으로 이해해야 합니다

REALITY는 Xray 생태계의 보안 메커니즘이며 VMess, VLESS, Trojan, Shadowsocks와 같은 계층에서 비교할 수 없습니다. 흔히 볼 수 있는 구성은 VLESS와 REALITY의 조합입니다. VLESS가 프록시 프로토콜 부분을 담당하고 REALITY가 함께 사용하는 보안 핸드셰이크를 제공합니다. 여전히 유효한 주소와 포트, 사용자 인증 정보가 필요하며 서버가 제공하는 공개 키 자료와 서버 이름, 짧은 ID 등의 매개변수도 입력해야 합니다.

일반 TLS의 스위치 이름만 바꿔서는 REALITY로 전환할 수 없습니다. 서버가 REALITY를 명시적으로 지원해야 하고 클라이언트에서 사용하는 코어도 관련 매개변수를 인식해야 합니다. 인터페이스의 항목 이름은 구현에 따라 달라질 수 있으므로 공개 검증 자료와 사용자 인증 정보, 핸드셰이크 이름의 용도를 구분해 확인하세요. 개인 키는 서버의 민감 정보입니다. 클라이언트 구독에 포함되어서는 안 되며, 가져오기에 누락된 항목을 채운다며 요청해서도 안 됩니다.

이러한 방식을 비교할 때는 전체 조합을 적어야 합니다. ‘REALITY 사용’만으로는 사용자 인증 방식을 알 수 없고, ‘SS 사용’만으로는 암호화 방식을 알 수 없습니다. 클라이언트 목록에 표시되는 약칭은 빠르게 훑어보는 데는 편리하지만 문제 해결 기록으로는 부족합니다. 전체 조합을 적어 두면 의사소통이 명확해지고, 외부 핸드셰이크 실패를 프록시 프로토콜 자체의 문제로 잘못 돌리는 일도 막을 수 있습니다.

실제 선택은 현재 서버 설정을 기준으로 하세요. Trojan 진입점만 있다면 TLS와 비밀번호부터 확인하고, SS만 있다면 방식과 키를 확인합니다. VLESS와 REALITY 진입점이 있다면 Xray 지원 여부와 필수 항목이 모두 있는지 확인하세요. 프로토콜 정보가 부족하면 설정 제공자에게 보완을 요청하세요. 보안 옵션을 하나씩 바꿔 가며 맞혀 보는 것은 권장하지 않습니다. 추측으로 변수를 늘리면 처음부터 빠져 있던 항목을 찾기 더 어려워집니다.

성능과 배터리: 연결 전체의 비용 비교하기

연결 속도는 여러 단계로 나뉩니다

사용자가 체감하는 속도에는 연결 시작 시간, 첫 콘텐츠를 받기까지의 시간, 지속 전송 속도가 포함됩니다. 첫 단계는 DNS 조회와 왕복 경로, 핸드셰이크 횟수의 영향을 받습니다. 첫 콘텐츠는 원격 대상의 응답에도 좌우되며, 지속 전송은 회선 용량과 혼잡도, 기기의 처리 성능에 영향을 받습니다. 따라서 프로토콜을 비교하기 전에 어느 단계를 측정하는지 명확히 해야 합니다. 한 번의 지연 시간 측정으로 다운로드 성능 순위를 매기면 실제 사용과 반대되는 결론을 내릴 수 있습니다.

프로토콜 인증과 암호화, 캡슐화에는 실제로 리소스가 들지만 기기의 하드웨어 가속과 시스템 스케줄링, 구현 최적화에 따라 결과가 달라집니다. VMess, VLESS, Trojan, SS라는 이름만으로 CPU 사용량의 고정된 순서를 정할 수는 없습니다. VLESS 프로토콜 자체가 같은 방식의 암호화를 담당하지 않는다고 해서 TLS나 REALITY의 비용까지 사라지는 것은 아닙니다. 드롭다운의 이름만 비교하지 말고 같은 기기와 비슷한 회선에서 명확히 정한 보안 조합을 비교하세요.

전송 캡슐화와 연결 재사용에도 비용이 발생합니다

WebSocket과 같은 전송 방식은 서버 진입점에 맞추기 위해 추가 캡슐화를 사용할 수 있으며, 그로 인한 오버헤드의 영향은 작업마다 다릅니다. 다중화는 적은 수의 하위 연결로 여러 요청을 전달해 반복적인 연결 수립을 줄이려는 방식입니다. 반면 여러 요청이 하나의 연결에서 발생하는 패킷 손실이나 스케줄링의 영향을 함께 받을 수도 있습니다. 서버와 흐름 제어 방식에 맞춰 사용 여부를 결정하고, 이름에 ‘다중화’가 들어간 옵션을 전부 켜지는 마세요.

테스트할 때는 같은 대상 사이트를 선택하고 라우팅과 DNS 설정을 동일하게 유지한 채 첫 실행과 재방문, 지속적인 콘텐츠 읽기를 각각 관찰하세요. 한 번에 변수 하나만 바꾸고 연결이 새로 수립됐는지 기록합니다. 브라우저 및 대상 사이트 캐시와 기존 연결은 결과에 영향을 주므로 한 번 더 반복한다고 오차가 자동으로 사라지지는 않습니다. 설정별로 연결하는 서버가 다르면 결과는 주로 두 서비스 경로의 차이를 보여줄 뿐, 특정 프로토콜의 효율성을 따로 입증하지는 않습니다.

안드로이드 배터리 소모는 지속적인 작동 방식에 더 크게 좌우됩니다

안드로이드 VPN 모드는 시스템의 VpnService를 통해 앱 트래픽을 받습니다. 앱에서 네트워크 요청이 계속 발생하면 클라이언트가 깨어나 데이터를 처리할 수 있으며, 연결 재시도와 DNS 조회, 로그 기록도 동작량을 늘립니다. 데스크톱에서 특정 프로토콜의 점유율이 낮다고 해서 휴대전화 대기 상태에서도 배터리를 덜 쓴다고 단정할 수는 없습니다. 무선 네트워크 품질과 백그라운드 앱 수, 시스템 절전 정책이 모바일 환경의 차이에 큰 영향을 주는 경우가 많습니다.

배터리 소모를 점검하려면 먼저 평소 사용 습관을 유지한 채 클라이언트를 켠 경우와 끈 경우의 시스템 배터리 기록을 비교하세요. 그다음 VPN 모드와 앱별 프록시, 특정 앱으로 범위를 좁힙니다. 신호가 불안정하거나 네트워크가 자주 바뀌는 때, 백그라운드 전송이 지속될 때 소모가 집중되는지 살펴보세요. 로그에 연결 재시도가 반복되면 연결 실패 원인을 먼저 해결해야 합니다. 모든 시간 제한을 늘려도 실패한 연결이 더 오래 대기할 뿐 실제 작업량이 줄어들지는 않습니다.

문제 해결 목표에 맞는 로그 수준을 사용하세요. 일시적인 진단에는 상세 수준을 높일 수 있지만 문제를 확인한 뒤에는 일상 사용에 알맞은 수준으로 되돌려 불필요한 기록이 계속 쌓이지 않도록 하세요. 지연 시간 측정과 자동 테스트도 연결을 직접 시작하므로 상태를 확인한다며 너무 자주 실행해서는 안 됩니다. 클라이언트 목록과 구독 업데이트, 실제 앱 요청은 구분해서 살펴보세요. 백그라운드 활동이 모두 현재 브라우징 중인 앱에서 발생하는 것은 아닙니다.

특정 앱에서만 배터리가 많이 소모되거나 연결이 실패한다면 해당 앱이 UDP와 장시간 연결, 백그라운드 푸시를 사용하는지 확인한 뒤 프록시 적용 범위를 살펴보세요. 필요한 앱만 VPN 경로로 보내면 관련 없는 트래픽을 줄일 수 있지만, 앱별 설정의 의미를 정확히 알아야 합니다. 자세한 방법은 v2rayNG 권한, 절전 및 앱별 설정을 참고하세요. 속도 문제는 노드, 회선, 로컬 설정을 단계별로 점검하는 방법에 따라 확인하고, 원인을 찾는 대신 프로토콜부터 바꾸지는 마세요.

V2Fly와 Xray: 기능별로 호환성을 확인하세요

같은 생태계라고 해서 구현까지 완전히 같은 것은 아닙니다

Project V는 V2Ray 생태계를 이해하는 데 필요한 배경입니다. V2Fly는 관련 코어와 구성 요소의 개발을 이어 가고, Xray는 공통된 역사에서 출발해 자체 기능 방향으로 발전했습니다. 일부 프로토콜과 설정 구조, 용어가 비슷해 기초 설정도 닮아 보일 수 있습니다. 그러나 비슷하다고 모든 파일을 서로 바꿔 쓸 수 있는 것은 아닙니다. 보안 메커니즘과 흐름 제어, 전송 세부 사항, DNS 동작은 다를 수 있으므로 기능별로 확인해야 합니다.

REALITY와 특정 VLESS 흐름 제어 방식은 코어를 선택할 때 자주 기준이 되는 기능입니다. 구독에서 Xray의 관련 기능을 명시적으로 요구한다면 설정 모양이 비슷하다는 이유로 V2Fly로 바꿔도 자동으로 지원되지는 않습니다. 반대로 이러한 기능이 필요 없는 기본 연결이라고 해서 특정 계열의 코어를 반드시 써야 한다고 볼 수도 없습니다. 코어는 현재 프로토콜 조합과 관리 요구 사항에 맞춰 선택해야 하며, 계열 이름을 성능 등급으로 여겨서는 안 됩니다.

세 클라이언트가 연결 과정에서 담당하는 역할

v2rayN은 Windows와 macOS, Linux 환경을 지원하는 데스크톱 우선 선택지입니다. 그래픽 인터페이스를 통한 관리와 설정 생성을 담당하며, 실제 코어 기능은 사용 중인 배포 패키지와 실행 설정에 따라 확인해야 합니다. 인터페이스에서 매개변수를 선택할 수 있다고 해서 모든 코어가 이를 처리할 수 있는 것은 아닙니다. 문제 해결 시에는 클라이언트 이름만 보고 실행 환경을 추측하지 말고 실제 실행 기록을 확인해 예상한 코어가 구동되는지 살펴보세요.

안드로이드용 v2rayNG는 Xray 코어를 사용하는 앱이며, v2flyNG는 V2Fly 코어를 위한 대안입니다. 두 앱의 사용법이 비슷해도 프로토콜 기능의 차이를 간과해서는 안 됩니다. 가져온 설정에 한쪽에서만 구현된 보안 기능이나 흐름 제어 기능이 있다면 권한과 연결 설정을 조정하기 전에 기능에 맞는 앱부터 선택하세요. 자세한 비교는 V2Ray 클라이언트 세 가지 비교 및 선택 가이드를 참고하세요.

설정 이전 후에는 생성된 결과를 확인해야 합니다

이전할 때 가장 확실한 출발점은 예전 클라이언트의 화면을 보고 항목을 추측하는 것이 아니라 원본 구독이나 완전한 공유 정보입니다. 대상 클라이언트에 별도 그룹을 만든 뒤 가져와서 프로토콜과 주소, 인증, 전송, 보안, 흐름 제어를 확인하세요. 기존 설정을 바로 삭제하지 말고 단일 진입점의 연결부터 검증합니다. 원본 정보에 확장 매개변수가 빠져 있다면 대상 클라이언트가 해당 기능을 지원하더라도 누락된 정보를 복원할 수 없습니다.

네이티브 JSON을 이전할 때는 전체 설정인지 일부 아웃바운드인지 구분해야 합니다. 전체 설정은 로컬 수신과 라우팅 태그, DNS, 로그를 함께 지정할 수 있습니다. 새 코어가 어떤 항목을 받아들인다고 해서 전체 동작까지 그대로 유지된다는 뜻은 아닙니다. 특히 라우팅에서 참조하는 태그와 아웃바운드 태그가 일치하지 않으면 설정은 불러와져도 대상 트래픽이 예상한 경로로 전달되지 않을 수 있습니다. 먼저 최소한의 연결을 확인한 뒤 로컬 정책을 단계적으로 옮기세요.

클라이언트 업데이트와 코어 업데이트가 항상 같은 작업인 것은 아닙니다. 배포 방식에 따라 코어가 패키지에 포함되거나 클라이언트 기능으로 관리될 수 있습니다. 실제 설치 패키지와 인터페이스 안내를 확인하세요. 출처가 불분명한 코어 파일을 섞어 쓰는 것은 권장하지 않습니다. 업데이트 전에 설정을 내보내 보관하고, 업데이트 후 주요 연결과 라우팅 동작을 확인하세요. 문제가 생기면 변경된 범위를 기록해 파서와 설정 생성, 코어 실행 중 어디에서 달라졌는지 구분합니다.

오픈 소스라고 해서 모든 분기가 같은 라이선스와 배포 주기, 기능 목록을 사용하는 것은 아닙니다. 코드를 전달하거나 재배포할 때는 각 구성 요소에 적용되는 라이선스 조건을 따라야 합니다. 일상적인 선택에서 유용한 기록은 막연히 ‘V2Ray 설치’라고 적는 것이 아니라 ‘클라이언트, 실제 코어, 필요한 프로토콜 기능’을 남기는 것입니다. 이 기록은 나중에 문제를 설명할 때도 도움이 됩니다.

구독 형식: 가져오기에 성공해도 항목이 모두 보존된 것은 아닙니다

주소와 콘텐츠, 내부 설정은 서로 다릅니다

구독 주소는 콘텐츠를 가져오는 진입점일 뿐, 주소 끝부분이 응답 형식을 결정하지는 않습니다. 요청 결과로 공유 링크 목록이나 Base64 인코딩 목록, 네이티브 JSON, 오류 페이지가 반환될 수 있습니다. 클라이언트는 콘텐츠를 받은 뒤 형식을 판별하고 항목을 파싱해 자체 설정 모델로 변환해야 합니다. 브라우저에서 주소가 열린다는 것은 응답을 받았다는 뜻일 뿐, 현재 클라이언트가 서버 정보를 인식할 수 있다는 증거는 아닙니다.

Base64는 인코딩 방식이지 암호화 프로토콜이 아니며, 콘텐츠를 자동으로 안전하게 보호하지도 않습니다. 흔한 구독은 여러 공유 링크를 텍스트로 연결한 뒤 인코딩합니다. 디코딩한 다음에도 각 링크 형식에 맞춰 파싱해야 합니다. 반복 인코딩이나 줄바꿈 누락, 웹페이지 태그 혼입, 문자 인코딩 오류가 인식에 영향을 줄 수 있습니다. 비공개 구독을 온라인 디코딩 도구에 올리지 마세요. 구독 주소에는 접근 자격 정보가 포함될 수 있으므로 민감한 정보로 취급해야 합니다.

공유 링크에는 통일된 필드 문법이 없습니다

일반적인 VMess 공유 링크에는 인코딩된 구조화 정보가 들어갑니다. VLESS와 Trojan 링크는 주소와 쿼리 매개변수를 조합하는 경우가 많고, SS에는 여러 공유 형식이 있습니다. 프로토콜 접두사가 비슷하다고 쿼리 매개변수를 서로 그대로 옮겨 쓸 수 있는 것은 아닙니다. 이름은 보통 메모일 뿐이므로 바꿔도 원격 기능은 달라지지 않습니다. 전송 경로와 서버 이름, 흐름 제어는 연결에 직접 영향을 줄 수 있으므로 변환 과정에서 함께 버려서는 안 됩니다.

파서는 확장 항목도 인식해야 합니다. 어떤 클라이언트는 프로토콜의 기본 정보는 보존하면서 알지 못하는 보안 매개변수를 무시할 수 있습니다. 그러면 서버가 목록에 보이는데도 연결은 실패할 수 있습니다. 가져온 뒤 서버 편집 화면을 열어 프로토콜과 전송 방식, 보안 유형, 주요 관련 항목을 확인하세요. 정보가 빠졌다면 같은 손실된 결과를 계속 변환하기보다 대상 클라이언트에 적합한 원본 형식을 찾는 것이 좋습니다.

네이티브 JSON이 항상 구독 그룹 진입점에 맞는 것은 아닙니다

네이티브 JSON은 전체 실행 설정일 수도 있고 일부 아웃바운드 정보만 담고 있을 수도 있습니다. 전체 설정에는 로컬 수신 포트와 DNS, 라우팅 규칙, 여러 아웃바운드가 포함될 수 있어 일반 서버 구독과 가져오기 방식이 다릅니다. 일부 클라이언트는 이를 사용자 지정 설정으로 관리하므로 일반 서버 목록에 여러 서버가 자동으로 나뉘어 들어가리라 기대해서는 안 됩니다. 가져오기 전에 해당 메뉴의 안내를 확인해 전체 설정을 개별 서버 정보로 잘못 처리하지 않도록 하세요.

전체 설정은 기존 로컬 동작을 덮어쓸 수도 있습니다. 일반 구독 목록은 보통 클라이언트가 수신과 라우팅을 일괄 생성하지만 사용자 지정 JSON은 해당 항목을 직접 지정할 수 있습니다. 가져온 뒤 시스템 프록시가 작동하지 않으면 실제 수신 포트가 시스템 설정과 일치하는지 확인하세요. 라우팅 태그를 추가로 사용한다면 참조 대상 아웃바운드가 있는지도 살펴봐야 합니다. JSON 문법이 올바르다는 이유만으로 현재 그래픽 클라이언트의 관리 방식에 적합하다고 판단하지 마세요.

v2rayN에서는 구독 그룹 관리에서 ‘구독 그룹 설정’으로 들어가 주소를 저장한 다음 해당 업데이트 작업을 실행할 수 있습니다. ‘현재 구독 업데이트(프록시 사용 안 함)’ 옵션은 구독 콘텐츠를 가져올 때 기존 프록시 경로를 거치지 않는다는 뜻이지, 반환되는 형식이 달라진다는 의미는 아닙니다. 연결은 정상인데 직접 업데이트만 실패한다면 클라이언트가 지원하는 업데이트 방식을 확인하세요. 사용할 수 있는 연결이 전혀 없다면 구독 주소에 직접 접속할 수 있는지 먼저 확인해야 합니다.

구독 업데이트 후 서버가 표시되지 않으면 요청이 성공했는지, 콘텐츠를 파싱할 수 있는지, 그룹 필터에 가려졌는지 순서대로 확인하세요. 로그인 페이지나 사용량 안내, 오류 문구가 반환된 것은 실제 형식 비호환과 다른 문제입니다. 업데이트 후 일부 항목만 실패한다면 모든 그룹을 삭제하기보다 해당 프로토콜 항목을 확인하세요. 다른 사람에게 문의할 때는 개인정보를 제거한 오류 유형과 프로토콜 조합만 공유하고 전체 구독 주소나 인증 정보를 공개하지 마세요.

형식 변환은 정보가 충분할 때만 의미를 보존할 수 있으며 서버 매개변수를 새로 만들어 낼 수는 없습니다. 전체 설정을 단순 링크로 내보내면 복잡한 라우팅과 DNS 정보가 대개 함께 전달되지 않습니다. 링크에서 JSON을 다시 만들 때도 원본에 없던 로컬 정책은 복원할 수 없습니다. 자세한 예시는 Base64, 네이티브 JSON, 공유 링크 간 변환의 한계를 참고하세요. 변환 후에도 주요 항목을 다시 확인하고 연결을 검증해야 합니다.

라우팅과 설정: 프로토콜이 작동한 뒤 트래픽을 분기하세요

로컬 진입점과 원격 아웃바운드를 먼저 구분하세요

로컬 SOCKS 또는 HTTP 수신은 앱 요청을 받는 데 사용하고, 원격 아웃바운드는 서버에 연결하는 데 사용합니다. 두 포트는 완전히 다를 수 있으므로 서버 포트를 앱의 로컬 프록시 설정에 입력해서는 안 됩니다. 인터페이스의 로컬 포트는 흔히 쓰이는 예시일 뿐 실제 값은 클라이언트가 현재 수신 중인 포트와 일치해야 합니다. 로컬 포트를 다른 프로그램이 사용 중이면 코어가 시작되지 않을 수 있습니다. 이 경우 원격 프로토콜 정보가 올바르더라도 사용할 수 없습니다.

아래는 필드 간 관계를 설명하기 위한 실제 인바운드 설정 일부이며, 이것만으로 서버에 연결할 수 있는 완전한 설정은 아닙니다. 로컬 루프백 주소에서만 수신하므로 앱은 같은 기기의 해당 포트로 연결해야 합니다. 앱 설정 문제를 해결하려고 수신 주소를 모든 네트워크 인터페이스로 함부로 바꾸지 마세요. 다른 기기에서 로컬 프록시에 접근할 수 있는 범위가 달라집니다. 원격 프로토콜과 인증 정보는 완전한 아웃바운드 설정으로 별도 제공되어야 합니다.

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    },
    {
      "tag": "local-http",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

domainStrategy는 라우팅 규칙 매칭 시 도메인을 해석하는 방식을 제어합니다

라우팅의 domainStrategy는 규칙을 비교하는 과정에서 대상 도메인을 어떻게 처리할지 결정합니다. AsIs는 원래 대상 형식을 우선 유지하며 IP 규칙에 맞추려고 도메인을 주소로 바꾸지 않습니다. IPIfNonMatch는 도메인 규칙이 일치하지 않을 때 주소 해석을 시도한 뒤 IP 관련 규칙을 계속 확인합니다. IPOnDemand는 IP 정보가 필요한 규칙을 비교할 때 주소 해석을 수행합니다. 이 세 값은 규칙 매칭 과정에 영향을 주며 요청이 반드시 프록시를 거칠지 직접 연결될지를 정하는 것은 아닙니다.

이 값들을 아웃바운드나 다른 모듈의 이름이 비슷한 정책과 혼동해서도 안 됩니다. 선택하기 전에 해당 항목이 어느 설정 객체에 있는지 확인하고 의미를 읽어 보세요. 앱이 처음부터 IP 주소만 전달했다면 라우팅에서 바로 사용할 수 있는 도메인 정보가 없을 수 있습니다. 스니핑으로 연결 내용에서 도메인 단서를 얻을 때도 있지만 모든 프로토콜과 트래픽에서 작동하는 것은 아니며 앱이 원래 사용한 전체 도메인 정보를 복원한다고 보장할 수 없습니다.

DNS와 규칙 순서, 대상 형식이 함께 결과를 좌우합니다

일반적인 라우팅은 규칙을 순서대로 검사합니다. 조건이 너무 넓은 규칙이 앞에 있으면 뒤에 있는 세부 규칙이 적용되지 않을 수 있습니다. 도메인 규칙과 IP 규칙도 현재 확인 가능한 대상 형식에 따라 달라집니다. ‘규칙을 설정했는데 적용되지 않는다’면 먼저 요청이 도메인으로 표시되는지 IP로 표시되는지 확인하세요. 그다음 어느 규칙이 먼저 일치하는지, 대상 아웃바운드 태그가 올바른지 점검합니다. 처음부터 모든 규칙의 범위를 넓히지는 마세요.

코어 DNS와 운영체제 DNS의 적용 범위도 다를 수 있습니다. 앱이 직접 주소를 해석하거나 코어가 라우팅 판단을 위해 다시 해석할 수 있고, 원격 서버가 최종 대상을 해석할 수도 있습니다. DNS 주소 하나를 바꿨다고 모든 요청이 같은 경로로 처리되는 것은 아닙니다. 도메인 접속은 되는데 IP 규칙이 예상대로 작동하지 않는다면 주소 해석이 발생한 위치와 반환된 주소 계열, 캐시를 확인한 뒤 domainStrategy 변경 여부를 결정하세요.

안드로이드 앱별 프록시 설정은 어떤 앱을 VPN 경로에 포함하거나 우회할지 정하고, 코어 라우팅은 들어온 트래픽을 어디로 보낼지 결정합니다. 우회 모드를 켜면 앱 목록의 의미가 ‘포함’에서 ‘제외’로 바뀔 수 있으므로 화면 안내를 확인하세요. 변경한 범위를 시스템에 적용하려면 클라이언트 안내에 따라 VPN을 다시 연결해야 할 수 있습니다. 테스트할 때는 앱 목록과 DNS, 도메인 규칙을 동시에 바꾸지 말고 앱과 대상 하나를 정하세요.

순서대로 확인하세요. 로컬 수신이 시작됐는지, 앱 요청이 실제로 들어오는지, 프로토콜 연결이 작동하는지 확인한 뒤 마지막으로 라우팅을 추가합니다. 문제가 생기면 검증된 단순 설정으로 잠시 돌아간 다음 규칙을 하나씩 복구하세요. 라우팅과 DNS, 프록시 모드에서 자주 발생하는 문제는 자주 묻는 질문에서 확인할 수 있습니다. 이렇게 하면 ‘진입점 연결 실패’, ‘원격 연결 실패’, ‘라우팅 규칙 불일치’를 별개의 문제로 나눠 볼 수 있어 프로토콜 항목을 무작정 바꿀 필요가 없습니다.

사용 환경과 문제 해결: 선택 기준을 점검 순서로 구체화하세요

데스크톱은 클라이언트부터 정한 뒤 프로토콜 조합을 확인하세요

데스크톱에서는 우선 v2rayN을 사용하고 다운로드 페이지에서 운영체제와 기기 아키텍처에 맞는 설치 파일을 선택하세요. 설치 패키지의 인터페이스 유형과 원격 프로토콜은 별개의 선택입니다. Windows 데스크톱 버전과 클래식 WPF 버전은 인터페이스와 배포 방식의 차이일 뿐, 서로 다른 프로토콜 진입점을 구매하거나 만들어야 한다는 뜻은 아닙니다. 구독이 있다면 먼저 가져와 연결 하나를 검증한 뒤 인터페이스 사용 방식과 로컬 그룹을 조정하세요.

Xray 기능이 필요한 설정을 안드로이드에서 사용한다면 v2rayNG를 선택하세요. 기존 정보가 V2Fly용이고 필요한 기능도 맞는다면 v2flyNG를 고려할 수 있습니다. 두 앱이 같은 접두사를 인식한다고 해서 관련 보안 매개변수를 무시해서는 안 됩니다. 장시간 백그라운드에서 사용하려면 VPN 권한과 절전 정책, 앱별 적용 범위도 확인해야 합니다. 시스템이 권한을 회수해 연결이 끊겼다면 UUID를 바꾸거나 암호화 방식을 변경해 해결하려 해서는 안 됩니다.

기존 설정이 선택 가능한 범위를 결정합니다

사용 가능한 서버 정보가 하나뿐이라면 일반적인 순위에 따라 다른 프로토콜을 고르기보다 해당 설정을 올바르게 구성하는 데 집중하세요. 서버에서 여러 진입점을 제공한다면 클라이언트 지원 여부와 정보의 완전성, 실제 앱 사용 결과, 유지 관리 비용을 비교하면 됩니다. 기기를 자주 바꾸는 사용자는 프로토콜 오버헤드의 작은 차이보다 형식이 범용적인지, 주요 항목을 빠짐없이 가져올 수 있는지가 더 중요할 수 있습니다. 특정 Xray 기능이 필요하다면 코어 지원 여부는 반드시 확인해야 합니다.

LAN 관리와 웹 브라우징, 지속적인 데이터 전송은 연결에 서로 다른 조건을 요구합니다. 웹 사용은 짧은 요청이 여러 번 발생하는 경우가 많고, 실시간 앱은 연결 안정성과 UDP 경로를 더 중요하게 여깁니다. 장시간 전송은 회선이 지속적으로 제공할 수 있는 용량에 더 크게 좌우됩니다. 프로토콜 이름만으로 실제 사용 환경의 검증을 대신할 수는 없습니다. 같은 네트워크 조건에서 실제 작업을 수행한 뒤 연결이 끊겼을 때와 네트워크가 바뀐 뒤 복구되는지도 확인하세요. 목록에 표시되는 한 번의 테스트 결과보다 실제 요구에 가까운 평가 방법입니다.

추측으로 설정을 바꾸지 말고 실패 단계에 따라 원인을 찾으세요

첫째, 코어가 시작되는지 확인합니다. 설정 파싱 실패나 알 수 없는 항목, 포트 사용 중이라는 메시지가 나오면 로컬 문제부터 해결하세요. 둘째, 서버 주소와 포트에 연결할 수 있는지 확인합니다. 연결 시간 초과는 주소와 라우팅, 원격 수신 상태와 관련될 수 있으며 이것만으로 비밀번호 오류라고 단정할 수 없습니다. 셋째, 보안 핸드셰이크를 점검합니다. 시스템 시간과 서버 이름, 인증서, REALITY 매개변수를 확인하세요. 마지막으로 프록시 인증과 대상 트래픽 전달을 살펴봅니다.

로그에 연결이 수립됐다고 나오는데 앱에서 데이터를 받지 못한다면 요청이 실제로 클라이언트에 들어오는지 확인한 뒤 DNS와 라우팅 대상, 원격 접속 가능 여부를 점검하세요. 특정 사이트만 실패하고 다른 사이트는 정상이라면 대상 도메인과 앱 동작을 중심으로 범위를 좁히는 편이 좋습니다. 바로 클라이언트를 다시 설치하지 마세요. UDP 관련 서비스만 비정상이라면 로컬 진입점과 프로토콜 지원, 서버의 전달 기능을 확인해야 합니다. TCP 연결이 한 번 성공했다고 모든 기능이 정상이라고 판단해서는 안 됩니다.

도움이 필요하면 실패한 작업과 같은 시점의 로그 일부를 보관하고 클라이언트와 실제 코어, 프로토콜, 전송 방식, 보안 메커니즘, 실패 단계를 기록하세요. 구독 자격 정보와 비밀번호, 사용자 ID 등 개인 계정을 식별할 수 있는 정보를 삭제하고, 스크린샷에 숨겨진 영역이나 전체 주소 표시줄이 나오지 않았는지도 확인해야 합니다. ‘연결이 안 됩니다’라고만 하면 처음부터 다시 점검해야 하지만 ‘보안 핸드셰이크 실패’라고 구체적으로 설명하면 관련 없는 설정을 상당수 제외할 수 있습니다.

최종 선택은 세 가지 질문으로 정리할 수 있습니다. 서버에서 제공하는 전체 조합은 무엇인지, 현재 코어가 이를 그대로 지원하는지, 대상 기기에서 실제 앱이 안정적으로 작동하는지 확인하세요. 세 가지 답이 분명해진 뒤 라우팅과 백그라운드 동작을 조정하면 됩니다. 첫 연결은 빠른 시작 가이드의 순서를 따르고, 반복되는 증상은 자주 묻는 질문에서 확인하세요. 설계 차이를 이해하려면 이 가이드의 해당 장으로 돌아오면 됩니다. 사용법과 원리, 문제 해결을 나눠 살펴보면 설정을 더 쉽게 관리할 수 있습니다.