이 글은 v2rayN, v2rayNG, v2flyNG 사이에서 노드를 이전하거나 구독 형식 오류를 점검하려는 사용자를 위한 내용입니다. 세 형식의 실제 구조와 식별 방법, 클라이언트 가져오기 절차, 바로 변환할 수 있는 경우와 서버에서 별도 프로토콜 매개변수를 제공해야 하는 경우를 설명합니다.
세 형식은 같은 설정 계층에 있지 않습니다
‘구독’은 흔히 모든 설정 파일을 통칭하는 말로 쓰이지만, 엄밀히 말하면 구독은 여러 설정을 배포하는 방식이고 공유 링크는 단일 노드를 휴대하기 위한 표현이며 네이티브 JSON은 코어가 실행 시 읽는 전체 설정입니다. 일부 필드는 같을 수 있어도 파일 확장자만으로 서로 같은 형식이라고 판단할 수는 없습니다.
일반적인 base64 구독 응답은 여러 vmess, vless 공유 링크를 줄마다 나열한 뒤 전체 UTF-8 텍스트를 base64로 인코딩한 것입니다. 클라이언트는 구독을 업데이트할 때 응답을 다운로드하고 텍스트를 디코딩한 다음 각 줄의 노드를 파싱합니다. base64는 텍스트 표현 방식만 바꾸며 암호화하지 않고 프로토콜 필드도 자동으로 채우지 않습니다.
구독 주소
추천고정 주소에서 노드 목록을 계속 받아오므로 통합 관리, 일괄 업데이트, 여러 기기 동기화에 적합합니다.
적합한 경우: 일상적인 사용, 많은 노드, 정기적인 매개변수 변경
vmess/vless 공유 링크
링크 하나에 일반적으로 아웃바운드 노드 하나가 담깁니다. 복사하기는 편하지만 전체 DNS 및 라우팅 설정까지 포함하지는 않습니다.
적합한 경우: 단일 노드 이전, 임시 가져오기, 매개변수 항목별 확인
네이티브 JSON
인바운드, 아웃바운드, DNS, 라우팅, 로그, 정책을 설명할 수 있어 필드가 가장 풍부하지만 특정 코어의 문법에 의존합니다.
적합한 경우: 사용자 지정 설정, 복잡한 트래픽 분기, 코어 수준 배포
vmess 공유 링크 자체에도 base64가 포함되는 경우가 많습니다. 대표적인 형식은 vmess:// 뒤에 인코딩된 JSON 객체를 넣는 방식이며, 주소, 포트, 사용자 식별자, 전송 방식, TLS 설정, 별칭 등을 포함할 수 있습니다. 여기서 base64는 단일 노드 객체에만 적용되며, ‘전체 구독을 다시 인코딩한’ 외부 base64와는 다른 계층입니다.
vless 공유 링크는 일반적으로 URI 쿼리 매개변수로 서버 주소, 포트, 암호화 표시, 전송 유형, TLS 또는 REALITY 매개변수를 직접 표현합니다. 읽기 쉬운 키-값 구조에 가깝지만 경로, 호스트 이름, 별칭에 포함된 특수 문자는 URL 인코딩해야 합니다.
| 형식 | 일반적인 시작 부분 | 주요 내용 | 전체 라우팅 표현 가능 여부 |
|---|---|---|---|
| base64 구독 | 일반적으로 고정된 프로토콜 접두사가 없음 | 여러 공유 링크 또는 노드 기록 | 대개 불가능 |
| VMess 공유 링크 | vmess:// |
단일 VMess 아웃바운드 노드 | 불가능 |
| VLESS 공유 링크 | vless:// |
단일 VLESS 아웃바운드 노드 | 불가능 |
| 네이티브 JSON | { |
코어 전체 실행 설정 | 가능 |
base64, 공유 링크, JSON 식별 방법
형식을 판단할 때는 파일명만 보지 말고 디코딩 전후의 최상위 구조부터 확인해야 합니다. 구독 API가 .txt로 끝나더라도 base64를 반환할 수 있고, 확장자가 없는 주소가 줄바꿈된 공유 링크를 직접 반환할 수도 있습니다. 올바른 절차는 응답이 텍스트인지 확인한 뒤 프로토콜 접두사, JSON 구조, 줄바꿈 방식을 점검하는 것입니다.
- 먼저 평문 접두사를 확인합니다.
vmess://또는vless://로 시작한다면 보통 단일 노드 공유 링크로 처리할 수 있습니다. - 그다음 JSON 최상위 필드를 확인합니다.
inbounds,outbounds,routing,dns가 있다면 Xray 또는 V2Fly 코어의 네이티브 설정에 가깝습니다. - 디코딩 가능한 텍스트인지 확인합니다. 내용이 주로 영문자, 숫자, 더하기 기호, 슬래시, 끝부분의 등호로 구성되어 있다면 표준 base64 디코딩을 시도한 뒤 결과가 줄바꿈된 링크인지 확인할 수 있습니다.
- 응답이 웹 페이지로 감싸져 있지 않은지 확인합니다. 시작 부분이
<html, 오류 메시지, 로그인 페이지라면 가져올 수 있는 구독 데이터가 아닙니다.
다음은 디코딩 후 나타날 수 있는 줄 단위 구조입니다. 예시 도메인과 사용자 식별자는 필드 위치를 설명하기 위한 것이며 연결에는 사용할 수 없습니다.
vless://[email protected]:443?encryption=none&security=tls&type=ws&host=edge.example.com&path=%2Fws#Example-VLESS
vmess://eyJ2IjoiMiIsInBzIjoiRXhhbXBsZS1WTWVzcyIsImFkZCI6Im5vZGUuZXhhbXBsZS5jb20iLCJwb3J0IjoiNDQzIn0=첫 번째 줄은 바로 읽을 수 있는 VLESS URI입니다. 물음표 앞에는 사용자 식별자, 서버, 포트가 있고 물음표 뒤에는 전송 및 보안 매개변수가 있으며, 해시 기호 뒤에는 노드 별칭이 있습니다. 두 번째 줄의 VMess 데이터는 다시 한 번 디코딩해야 합니다. 이는 외부 구독 인코딩과 내부 노드 인코딩이 중첩될 수 있음을 보여주는 예입니다.
{
"log": {
"loglevel": "warning"
},
"inbounds": [
{
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks"
}
],
"outbounds": [
{
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "node.example.com",
"port": 443
}
]
}
}
]
}이 JSON에는 이미 로컬 인바운드와 원격 아웃바운드 계층이 포함되어 있으므로 일반 구독처럼 줄마다 파싱해서는 안 됩니다. 완전히 실행 가능한 설정이 되려면 유효한 사용자 매개변수와 일치하는 전송 설정도 필요합니다. 이 예시는 구조를 식별하는 방법만 보여줍니다.
v2rayN, v2rayNG, v2flyNG의 가져오기 차이
클라이언트가 특정 프로토콜을 지원하는지와 특정 텍스트 형식을 인식할 수 있는지는 별개의 문제입니다. 구독 디코딩에는 성공했더라도 현재 코어가 노드의 전송 방식이나 보안 기능을 지원하지 않아 연결하지 못할 수 있습니다. 문제를 확인할 때는 ‘파싱 성공’과 ‘코어 사용 가능 여부’를 따로 확인해야 합니다.
v2rayN 7.x 인터페이스를 예로 들면, 일괄 구독은 보통 「구독 그룹」→「구독 그룹 설정」에서 추가합니다. 주소를 저장한 뒤 메인 화면으로 돌아와 구독 업데이트를 실행합니다. 단일 공유 링크는 먼저 복사한 다음 클립보드에서 서버를 가져오는 기능을 사용할 수 있습니다. 가져온 후에는 노드 이름만 보지 말고 주소, 포트, 전송 유형, TLS, SNI, 경로를 확인해야 합니다.
권장 방식: 구독은 노드 관리, 클라이언트는 로컬 정책 관리
데스크톱 v2rayN
- 구독 그룹으로 노드 목록 관리
- 로컬 환경에 맞게 시스템 프록시와 라우팅 설정
- 로그에서 10808, 10809 등 로컬 포트 상태 확인
안드로이드 v2rayNG 또는 v2flyNG
- 호환되는 동일 구독 주소 가져오기
- 업데이트 후 사용 가능한 노드 다시 선택
- 클라이언트 코어 기능에 따라 프로토콜과 전송 방식 필터링
구독은 원격 노드 매개변수를 동기화하는 용도이며, 로컬 DNS, 앱별 규칙, 시스템 프록시 상태는 별도로 설정해야 합니다.
v2rayNG는 Xray 코어를 사용하므로 해당 코어가 지원하는 VMess, VLESS 및 관련 전송 설정을 가져오는 데 적합합니다. 일반적인 경로는 구독 그룹 설정을 열고 구독 주소를 추가한 뒤 업데이트를 실행하는 것입니다. 단일 링크는 오른쪽 상단의 추가 메뉴에서 클립보드로 가져올 수 있습니다. v2rayNG 1.9.x는 세부 버전에 따라 메뉴 문구가 조금 다를 수 있지만 구독 그룹과 클립보드 가져오기는 서로 독립된 진입점입니다.
v2flyNG는 V2Fly 코어를 사용하므로 서버에서 V2Fly 호환으로 명시한 설정을 우선 가져와야 합니다. 구독에 다른 코어에서만 구현된 필드가 섞여 있으면 링크를 읽는 데는 성공해도 연결 단계에서 지원되지 않는 전송 또는 보안 매개변수 오류가 발생할 수 있습니다. 노드 별칭을 바꾸거나 알 수 없는 필드를 삭제하는 것만으로 프로토콜 호환성을 판단할 수는 없습니다.
| 입력 내용 | v2rayN | v2rayNG | v2flyNG |
|---|---|---|---|
| base64 노드 구독 | 구독 그룹 업데이트로 사용 가능 | 구독 업데이트로 사용 가능 | 호환되는 노드 가져오기 가능 |
| 단일 VMess 링크 | 클립보드에서 가져오기 가능 | 클립보드에서 가져오기 가능 | 호환되는 링크 가져오기 가능 |
| 단일 VLESS 링크 | 선택한 코어와 매개변수에 따라 다름 | Xray 지원 여부에 따라 다름 | V2Fly 지원 여부에 따라 다름 |
| 코어 전체 JSON | 사용자 지정 설정으로 처리 | 일반 노드 구독과 동일하지 않음 | 일반 노드 구독과 동일하지 않음 |
형식 변환의 가능 경로와 정보 손실
형식 변환에서는 먼저 ‘인코딩 변환’과 ‘프로토콜 변환’을 구분해야 합니다. base64를 디코딩해 줄바꿈된 공유 링크로 되돌리는 것은 텍스트를 복원하는 작업일 뿐 노드 프로토콜을 바꾸지 않습니다. VLESS를 VMess로 다시 작성하려면 서버 인증과 프로토콜 구현이 필요하므로 링크 접두사만 바꿔서는 해결되지 않습니다.
base64 구독을 평문 링크 목록으로 변환하는 작업은 대체로 되돌릴 수 있습니다. UTF-8로 디코딩한 뒤 각 줄을 그대로 보존하고 원래 순서대로 다시 인코딩하면 됩니다. 다만 표준 base64와 URL 안전 변형은 문자를 처리하는 방식이 다르므로 끝의 패딩 문자를 잘못 삭제하면 디코딩에 실패할 수 있습니다.
- base64 구독을 공유 링크 목록으로 변환: 외부 텍스트를 디코딩하고 줄바꿈을 통일한 뒤 빈 줄을 제거하고 각 항목의 프로토콜 접두사를 식별합니다. 이 과정에서는 일반적으로 노드 필드가 손실되지 않습니다.
- 공유 링크를 클라이언트로 가져오기: 클라이언트가 단일 노드 매개변수를 파싱해 해당 아웃바운드 설정을 로컬에 생성합니다. 클라이언트의 DNS, 라우팅, 로그 설정은 공유 링크에 포함되지 않습니다.
- 공유 링크를 네이티브 JSON으로 변환: 아웃바운드 객체 하나는 만들 수 있지만, 완전한 실행 설정이 되려면 로컬 인바운드, DNS, 라우팅, 로그, 정책을 추가해야 합니다.
- 네이티브 JSON에서 공유 링크 추출: 구조가 명확한 단일 아웃바운드에만 적합합니다. 여러 아웃바운드, 부하 분산, 라우팅 규칙, DNS 서버, 정책 객체는 일반 링크 하나에 완전히 담을 수 없습니다.
- VMess와 VLESS 상호 변환: 서버에서 두 프로토콜의 리스너와 인증 매개변수를 모두 제공하는 경우에만 각각의 링크를 생성할 수 있습니다. 클라이언트에서 다른 프로토콜 설정을 임의로 추론할 수는 없습니다.
결론: 목표 계층을 먼저 정한 뒤 변환하세요
노드만 이전한다면 공유 링크를 유지하면 됩니다. 전체 DNS와 라우팅 동작을 복제해야 한다면 네이티브 JSON을 이전하거나 대상 클라이언트에서 로컬 정책을 다시 설정해야 합니다. 전체 JSON을 단일 링크로 축약하면 실행 로직 일부가 반드시 빠집니다.
VLESS URI를 변환할 때는 쿼리 매개변수의 대소문자와 값도 그대로 유지해야 합니다. 예를 들어 type=ws, security=tls, sni=edge.example.com, path=%2Fws는 각각 전송 방식, 보안 계층, 서버 이름, 경로를 나타냅니다. 핵심 필드 하나라도 빠지면 핸드셰이크 실패나 연결 후 트래픽 없음으로 이어질 수 있습니다.
VMess 링크의 JSON 필드는 역사적으로 여러 표현 방식이 있으며 포트가 문자열일 수도, 숫자로 파싱될 수도 있습니다. 처리할 때는 클라이언트가 허용하는 구조로 먼저 출력해야 하며 필드명만 보고 기계적으로 조합해서는 안 됩니다. 가져오기는 성공했지만 노드 매개변수가 비어 있다면 링크를 다시 디코딩하고 주소, 포트, 사용자 식별자, 전송 유형, TLS 필드를 항목별로 대조해야 합니다.
구독 변환이 실패할 때 자주 발생하는 문제
구독 업데이트 실패가 반드시 형식 문제를 뜻하지는 않습니다. 네트워크 시간 초과, 로그인 페이지를 반환하는 주소, 잘린 응답, 문자 인코딩 오류, 클라이언트 코어 비호환도 비슷한 메시지를 만들 수 있습니다. 가장 효과적인 점검 방법은 먼저 다운로드한 원본 내용을 확인한 뒤 노드 파싱과 연결 테스트로 넘어가는 것입니다.
구독 주소를 열었더니 긴 문자열만 보입니다. 정상인가요?
문자가 주로 영문자, 숫자, 더하기 기호, 슬래시, 끝의 등호로 구성되어 있다면 표준 base64일 수 있습니다. 디코딩 후에는 줄바꿈된 공유 링크가 나타나야 하며, 결과가 계속 깨진 문자열이라면 응답 인코딩과 내용이 완전한지 확인해야 합니다.
링크는 가져와지지만 업데이트 후 노드 수가 0개입니다. 어떻게 해야 하나요?
먼저 응답이 웹 오류 페이지가 아닌지 확인한 다음, 디코딩 결과에 클라이언트가 인식할 수 있는 프로토콜 접두사가 있는지 점검합니다. v2rayN 7.x에서는 로그를 열어 구독 파싱 메시지를 확인하고 구독 그룹에 잘못된 필터 조건이 설정되어 있지 않은지도 확인할 수 있습니다.
같은 구독인데 두 클라이언트에서 노드 수가 다른 이유는 무엇인가요?
클라이언트가 코어 기능에 따라 호환되지 않는 노드를 필터링하거나 서로 다른 별칭 중복 제거 규칙을 사용할 수 있습니다. 업데이트 전후의 노드 수를 각각 기록한 다음 제외된 링크의 프로토콜과 전송 매개변수를 비교해 보세요.
네이티브 JSON을 base64로 인코딩하면 구독으로 사용할 수 있나요?
그렇게 바로 동일시할 수는 없습니다. 일반적인 base64 구독을 디코딩하면 줄바꿈된 공유 링크가 나오지만, 전체 JSON은 단일 설정 객체입니다. 수신 측에서 해당 응답 구조를 명시적으로 지원하지 않는 한 파싱에 실패합니다.
구독 업데이트가 시간 초과되면 먼저 사용 가능한 것으로 확인된 노드에 연결한 뒤 업데이트 요청이 현재 프록시를 거칠 수 있는지 확인하세요. v2rayN에서는 로컬 리스닝 포트가 사용 중인지도 점검해야 합니다. 일반적인 설정은 SOCKS 포트에 10808, HTTP 포트에 10809를 사용하지만 실제 값은 「설정」→「매개변수 설정」의 현재 구성을 기준으로 해야 합니다.
- 응답이 HTML 태그로 시작함: 구독 주소가 로그인 또는 오류 페이지로 리디렉션되는지 확인하세요.
- base64 디코딩 실패: 복사 과정에서 끝부분 문자가 누락되지 않았는지, 응답이 중간에 잘리지 않았는지 확인하세요.
- 노드를 가져온 후 주소가 비어 있음: VMess 내부 JSON 필드가 완전한지 확인하세요.
- VLESS 가져오기 후 핸드셰이크 실패: 포트, SNI, 전송 유형, 경로, 보안 매개변수를 확인하세요.
- 업데이트 후 중복 노드가 나타남: 여러 구독 그룹이 같은 데이터 소스를 참조하는지 확인하고 별칭 중복 제거 설정을 점검하세요.
관리하기 쉬운 구독 및 설정 이전 절차 만들기
안정적인 이전 절차에서는 원본 구독 주소, 디코딩된 노드 목록, 클라이언트 로컬 설정 세 가지 정보를 보존해야 합니다. 구독 주소는 이후 업데이트를 담당하고, 노드 목록은 파싱 문제를 찾는 데 유용하며, 로컬 설정에는 공유 링크로 이전되지 않는 시스템 프록시, DNS, 라우팅, 포트 등이 포함됩니다.
클라이언트나 코어를 변경하기 전 현재 사용 가능한 노드의 프로토콜, 서버 포트, 전송 유형, 보안 매개변수를 기록한 다음 대상 클라이언트에서 같은 구독을 가져오세요. 업데이트가 끝났다고 바로 모든 노드를 일괄 수정하지 말고 VMess 또는 VLESS 노드 하나를 선택해 지연 시간과 실제 연결을 테스트하며 로그에 프로토콜 필드 오류가 없는지 확인해야 합니다.
- 구독 주소가 속한 그룹, 업데이트 방식, 마지막으로 성공한 업데이트 시간을 기록합니다.
- 정상 작동이 확인된 링크 하나를 추출해 프로토콜, 주소, 포트, 사용자 식별자, 전송 매개변수를 확인합니다.
- 대상 클라이언트에 새 구독을 추가하되 현재 사용 가능한 그룹을 덮어쓰지 않습니다.
- 수동 업데이트를 한 번 실행하고 업데이트 전후의 노드 수를 기록합니다.
- 노드 하나를 선택해 테스트하고 코어 로그, DNS 확인, 로컬 리스닝 포트를 점검합니다.
- 연결이 정상임을 확인한 후 라우팅 분기, 자동 업데이트, 시스템 프록시 설정을 복원합니다.
v2rayN과 v2rayNG 사이에서 노드만 동기화하면 되는 경우에는 구독 주소를 유지하는 것이 우선이며 전체 JSON을 반복해서 내보낼 필요가 없습니다. 복잡한 도메인 분기, 여러 아웃바운드, 사용자 지정 DNS에 의존하는 경우에는 노드 이전과 라우팅 이전을 두 단계로 나누어 공유 링크에 모든 동작이 포함되어 있다고 오해하지 않도록 해야 합니다.
최종 판단 기준은 파일을 ‘가져올’ 수 있는지가 아니라 필드가 완전히 파싱되는지, 현재 코어가 지원하는지, 연결 로그가 정상인지, 로컬 프록시와 라우팅이 예상대로 적용되는지입니다. 먼저 데이터 계층을 식별하고 그에 맞는 가져오기 메뉴를 선택하면 대부분의 구독 변환 문제를 줄일 수 있습니다.