구독 형식 자세히 알아보기: base64, 네이티브 JSON, 공유 링크의 차이와 변환 방법

세 가지 형식은 해결하는 문제가 다릅니다

‘구독’은 흔히 넓은 의미로 쓰이지만, 실제로 받는 내용은 세 가지 수준으로 나뉩니다. base64 목록형 구독은 여러 공유 링크를 묶은 형식이고, VMess 또는 VLESS 공유 링크는 보통 하나의 아웃바운드 노드만 설명합니다. 네이티브 JSON은 인바운드, 아웃바운드, DNS, 로그, 라우팅 규칙을 포함한 전체 실행 설정일 수 있습니다. 먼저 수준을 판단한 뒤 가져오기 방식을 선택하는 편이 버튼을 바꿔가며 반복 시도하는 것보다 효율적입니다.

브라우저에서 구독 주소를 열었을 때 긴 영문자와 숫자, 일부 등호만 보인다고 해서 내용이 손상된 것은 아닙니다. 전체 텍스트가 base64로 인코딩된 결과일 수 있습니다. 디코딩한 각 줄이 vmess:// 또는 vless://로 시작한다면 일반적인 목록형 구독입니다. 여기서 인코딩은 텍스트를 포장하는 역할일 뿐 암호화가 아니며, 노드 매개변수 자체를 바꾸지도 않습니다.

base64 목록형 구독

권장

하나의 주소에서 여러 노드를 받을 수 있어 클라이언트 업데이트 시 서버 목록 전체를 교체할 수 있습니다. 지속적인 관리에 적합합니다.

적합한 용도: 일상적인 구독 업데이트, 여러 기기 간 노드 목록 동기화

VMess 또는 VLESS 공유 링크

하나의 링크가 하나의 노드를 설명하므로 임시 가져오기, 다른 기기로 복사, 매개변수 차이 확인에 편리합니다.

적합한 용도: 단일 노드 이전, 수동 테스트, 매개변수 대조

네이티브 JSON 설정

인바운드 리스너, 여러 아웃바운드, DNS와 라우팅을 함께 표현할 수 있어 가장 완전하지만 코어 필드의 호환성에 좌우됩니다.

적합한 용도: 세밀한 트래픽 분기, 서버 설정, 고급 문제 해결

형식	일반적인 시작 부분	포함 범위	일반적인 가져오기 결과
base64 목록형	고정된 프로토콜 헤더 없음	여러 공유 링크	서버 레코드 묶음 생성
VMess 공유 링크	`vmess://`	단일 VMess 노드	서버 레코드 하나 생성
VLESS 공유 링크	`vless://`	단일 VLESS 노드	서버 레코드 하나 생성
네이티브 JSON	`{`	전체 또는 일부 코어 설정	사용자 지정 설정으로 실행하거나 파싱

결론: 포함 수준을 먼저 식별한 뒤 변환 방식을 선택하세요

노드 묶음을 장기간 업데이트해야 한다면 구독 주소를 유지하세요. 하나의 노드만 이전할 때는 공유 링크를 사용하고, DNS·인바운드 포트·라우팅 규칙이 필요할 때는 네이티브 JSON을 보관하세요. 세 형식은 단순히 파일 확장자만 다른 것이 아닙니다.

base64 목록형 구독의 내부 구조

일반적인 목록형 구독의 원본 응답은 base64 텍스트입니다. 디코딩하면 보통 UTF-8 텍스트가 나오며, 각 줄에 공유 링크 하나가 들어 있고 줄바꿈은 LF 또는 CRLF일 수 있습니다. 클라이언트는 구독을 업데이트할 때 주소를 요청하고 텍스트를 디코딩한 다음 프로토콜 헤더에 따라 줄 단위로 파싱합니다. 인식하지 못한 줄은 대개 건너뛰므로 ‘업데이트는 성공했지만 노드 수가 0개’라면 디코딩 결과의 프로토콜을 현재 클라이언트가 지원하지 않거나 서버가 로그인 페이지·안내 페이지 같은 구독 이외의 내용을 반환했을 가능성이 큽니다.

dmxlc3M6Ly9mNDdhZDQ4YS1hZWMxLTQwZTQtYTgzOC0wNjE2N2VhZDc4OTVA
ZXhhbXBsZS5pbnZhbGlkOjQ0Mz9lbmNyeXB0aW9uPW5vbmUmc2VjdXJpdHk9
dGxzJnR5cGU9d3MmcGF0aD0lMkZhcGkjVExTLVdTLUV4YW1wbGU=

위 내용은 형식 예시일 뿐입니다. base64인지 확인하려면 먼저 문자가 주로 A-Z, a-z, 0-9, 더하기 기호, 슬래시, 등호 범위에 속하는지 살펴본 뒤 디코딩하세요. 문자 모양만으로는 유효성을 판단할 수 없습니다. 일반적인 무작위 텍스트도 같은 범위에 들어갈 수 있기 때문입니다. 디코딩 결과가 읽을 수 있는 텍스트인지, 각 줄에 지원되는 프로토콜 헤더가 있는지 확인하는 방법이 더 정확합니다.

1줄

보통 공유 링크 하나에 해당

UTF-8

디코딩 후 흔히 사용하는 텍스트 인코딩

10808

일반적인 로컬 SOCKS 리스너 포트 예시

2단계

목록 인코딩과 단일 노드 인코딩이 겹칠 수 있음

VMess 공유 링크 자체에도 base64 인코딩이 한 겹 포함되는 경우가 많으며, 내부에는 주소·포트·사용자 식별자·전송 방식·TLS 매개변수를 설명하는 JSON 객체가 들어갑니다. 따라서 VMess 목록형 구독은 단일 노드 JSON을 먼저 인코딩해 vmess:// 링크를 만든 다음 여러 링크를 이어 붙여 전체를 다시 인코딩할 수 있습니다. 문제를 확인할 때는 단계별로 처리해야 하며, 전체 구독을 단일 VMess 노드로 간주해 바로 디코딩해서는 안 됩니다.

VMess와 VLESS 공유 링크는 노드를 어떻게 표현할까요?

공유 링크의 목적은 클라이언트가 하나의 아웃바운드 노드를 재구성하도록 하는 것입니다. VMess는 보통 프로토콜 헤더 뒤에 base64로 인코딩한 JSON이 붙고, VLESS는 표준 URI에 더 가깝습니다. 사용자 식별자는 사용자 정보 부분에, 서버 주소와 포트는 호스트 부분에 있으며, 전송·보안·흐름 제어 매개변수는 쿼리 문자열에 들어갑니다. 해시 뒤의 텍스트는 노드 이름으로 사용됩니다. 두 링크 모두 민감한 연결 인증 정보를 포함할 수 있으므로 공개 웹페이지나 공개 로그에 붙여 넣지 마세요.

프로토콜 헤더를 읽고 VMess와 VLESS 중 어떤 파서를 사용할지 결정합니다.
서버 도메인, 포트, 사용자 식별자를 추출하고 포트가 1~65535 범위의 정수인지 확인합니다.
TCP, WebSocket, gRPC 같은 전송 유형을 읽고 유형에 따라 경로 또는 서비스 이름을 파싱합니다.
TLS, 서버 이름, 애플리케이션 계층 프로토콜 매개변수를 읽어 주소와 포트만 옮기는 일이 없도록 합니다.
노드 메모를 디코딩하고 퍼센트 인코딩을 처리한 뒤 서버 목록에 표시합니다.

VLESS URI 구조 예시

아래 예시는 해석할 수 없는 예약 도메인을 사용하며, 핵심은 필드의 위치입니다. security=tls는 전송 보안 설정, type=ws는 WebSocket, path는 요청 경로, sni는 TLS 핸드셰이크에 사용할 서버 이름을 뜻합니다. 매개변수 이름의 대소문자를 구분하는 경우에는 클라이언트 구현을 따라야 하며, 의미를 모르는 필드는 수동으로 수정하지 않는 편이 좋습니다.

vless://[email protected]:443?encryption=none&security=tls&sni=edge.example.invalid&type=ws&path=%2Fproxy#TLS-WS-Example

VMess와 VLESS는 프로토콜 이름만 바꾼다고 서로 변환되지 않습니다. 인증 모델과 매개변수 집합이 다르며, VLESS의 flow 같은 필드에는 VMess에 직접 대응하는 항목이 없습니다. 서버가 두 프로토콜의 인바운드 설정을 모두 제공할 때만 연결 가능한 공유 링크를 각각 만들 수 있습니다. URI만 고쳐 쓴다고 서버에 다른 프로토콜 지원이 추가되지는 않습니다.

네이티브 JSON과 클라이언트 구독의 관계

네이티브 JSON은 V2Ray 또는 Xray 코어를 대상으로 하며, 최상위에는 log, dns, inbounds, outbounds, routing 같은 필드가 자주 포함됩니다. 이 중 공유 링크로 매핑할 수 있는 것은 대부분 특정 outbounds 항목뿐입니다. JSON에 도메인·IP·포트·인바운드 태그별 라우팅 규칙까지 들어 있다면 단일 노드 링크로 내보낼 때 기존 동작을 유지할 수 없습니다.

권장 방식: 구독은 노드, 클라이언트는 로컬 정책 담당

데스크톱 v2rayN

구독 그룹으로 서버 목록 관리
필요에 따라 로컬 SOCKS 포트를 10808로 설정
라우팅 규칙은 별도로 저장하고 매칭 결과 테스트

안드로이드 v2rayNG 또는 v2flyNG

같은 구독 주소 가져오기
클라이언트가 지원하는 범위에 따라 노드 파싱
기기에서 라우팅과 DNS를 별도로 설정

노드 매개변수는 구독으로 동기화할 수 있지만 로컬 리스너, 애플리케이션 적용 범위, 라우팅 정책은 각 기기에서 따로 관리해야 합니다.

최소 설정이 곧 구독은 아닙니다

아래 JSON은 로컬 SOCKS 인바운드 하나와 VLESS 아웃바운드 하나를 함께 정의합니다. 아웃바운드 필드를 공유 링크로 변환하더라도 리스너 주소 127.0.0.1, 포트 10808, 라우팅 동작은 링크에 들어가지 않습니다. 대상 클라이언트는 자체 기본값이나 기존 설정으로 이 항목을 보완합니다.

{
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "example.invalid",
            "port": 443,
            "users": [
              {
                "id": "f47ad48a-aec1-40e4-a838-06167ead7895",
                "encryption": "none"
              }
            ]
          }
        ]
      }
    }
  ]
}

inbounds는 로컬 프로그램이 코어에 트래픽을 전달하는 방식을 결정합니다.
outbounds는 트래픽이 어떤 원격 프로토콜을 통해 또는 직접 연결로 나갈지 결정합니다.
routing은 도메인, IP, 포트, 태그를 기준으로 아웃바운드를 선택합니다.
dns는 이름을 해석하는 방식을 결정하지만 노드 공유 매개변수로 자동 변환되지는 않습니다.

클라이언트가 내보낸 JSON에는 프로그램이 생성한 태그, 통계 정책, 특정 코어 필드가 포함될 수도 있습니다. 다른 클라이언트로 가져오기 전에 대상 클라이언트가 사용하는 코어와 버전이 해당 필드를 인식하는지 확인해야 합니다. v2rayNG는 Xray 코어를, v2flyNG는 v2fly 코어를 사용합니다. 두 코어는 기본 VMess·VLESS와 일반적인 전송 방식에서 일부 호환되지만, 새로운 필드와 확장 기능까지 완전히 동일하다고 가정해서는 안 됩니다.

가져오기·변환·업데이트 실전

일상적으로는 수동으로 디코딩해 하나씩 가져오기보다 클라이언트가 구독 주소를 직접 읽도록 하는 편이 좋습니다. 직접 구독하면 업데이트 경로가 유지되어 서버에서 노드 이름·주소·포트를 변경해도 클라이언트가 목록을 다시 받을 수 있습니다. 수동 변환은 내용을 확인하거나 적은 수의 노드를 이전하고 특정 레코드의 파싱 실패 원인을 찾을 때 적합합니다.

목표 작업	권장 진입 경로	완료 후 확인 사항
v2rayN에 구독 추가	「구독 그룹」→「구독 그룹 설정」→「추가」	구독 업데이트 후 그룹 이름과 노드 수 확인
v2rayN에 단일 노드 가져오기	공유 링크를 복사한 뒤 「서버」→「클립보드에서 URL 일괄 가져오기」 사용	주소, 포트, 전송 방식, TLS 매개변수 대조
v2rayNG에 구독 추가	사이드 메뉴의 「구독 그룹 설정」을 열고 주소를 추가한 뒤 업데이트 실행	현재 그룹이 새 구독으로 전환되었는지 확인
v2rayNG에 단일 노드 가져오기	링크를 복사하고 오른쪽 위의 “+”를 누른 뒤 「클립보드에서 가져오기」 선택	노드 세부 정보에서 서버 이름과 전송 방식 확인
v2flyNG에 구독 가져오기	구독 그룹 설정으로 들어가 이름과 전체 주소를 입력한 뒤 업데이트	노드 프로토콜이 v2fly 코어의 지원 범위에 포함되는지 확인

메뉴 문구는 클라이언트 버전에 따라 달라질 수 있지만 순서는 대체로 같습니다. 먼저 구독 주소를 저장하고, 직접 업데이트한 다음, 노드를 선택해 연결을 시작하세요. 테스트할 때는 ‘실행 중’ 상태만 보지 말고 코어 로그, 실제 지연 시간, 대상 웹페이지 접속 결과도 확인해야 합니다. 지연 시간 테스트 실패가 반드시 노드를 사용할 수 없다는 뜻은 아니며, 테스트 주소에 접근할 수 없거나 DNS 해석에 문제가 있을 수도 있습니다.

구독 업데이트는 성공했는데 목록이 비어 있는 이유는 무엇인가요?

먼저 구독 그룹에서 현재 선택된 그룹을 확인한 뒤 업데이트 결과에 파싱된 레코드가 0개로 표시되는지 살펴보세요. 0개라면 응답 내용을 로컬 텍스트 도구에 복사해 확인합니다. base64를 디코딩한 뒤에는 줄마다 공유 링크가 나와야 하며 로그인 페이지, 오류 안내, HTML 소스가 나오면 안 됩니다.

VLESS 링크를 복사했더니 형식 오류가 표시됩니다. 어떻게 해야 하나요?

링크가 vless://로 시작하는지, 사용자 식별자·도메인·포트가 완전한지, 쿼리 매개변수의 &가 메신저에서 잘리지 않았는지 확인하세요. 원본 일반 텍스트를 다시 복사하고 퍼센트 인코딩을 수동으로 삭제하지 마세요.

base64 디코딩 후 글자가 깨집니다. 인코딩이 호환되지 않는 건가요?

먼저 입력 끝부분의 문자가 누락되지 않았는지 확인하고 표준 base64와 URL 안전 변형을 각각 시도하세요. 디코딩된 바이트는 보통 UTF-8로 읽습니다. 그래도 읽을 수 없다면 압축되었거나 다른 구독 프로토콜을 사용했거나, 목록형 텍스트가 아닌 응답일 수 있습니다.

전체 JSON을 구독 주소 입력란에 그대로 붙여 넣어도 되나요?

설정 본문을 URL로 사용할 수는 없습니다. 구독 주소 입력란에는 요청 가능한 URL이 필요합니다. 전체 JSON은 클라이언트의 사용자 지정 설정 가져오기 기능으로 처리하고, 인바운드 포트가 기존 프로그램과 충돌하지 않는지도 확인해야 합니다.

같은 구독인데 두 클라이언트에서 노드 수가 다른 이유는 무엇인가요?

각 클라이언트의 업데이트 후 전체 수를 기록하고, 건너뛴 노드의 프로토콜과 전송 매개변수를 확인하세요. v2rayNG와 v2flyNG는 서로 다른 코어를 사용하므로 한쪽만 지원하는 필드가 있으면 파싱이나 실행 결과가 달라질 수 있습니다. 이름만 바꿔 프로토콜을 강제로 변환하지 마세요.

변환 시 유지해야 할 필드와 보안 기준

신뢰할 수 있는 변환은 문자열을 찾아 바꾸는 대신 먼저 구조화된 객체로 파싱한 뒤 대상 형식에 맞게 다시 직렬화해야 합니다. 최소한 프로토콜, 서버 주소, 포트, 사용자 식별자, 전송 유형, TLS 상태, 서버 이름, 경로 또는 서비스 이름, 흐름 제어 매개변수, 노드 메모를 유지해야 합니다. 연결에 필요한 필드 하나라도 빠지면 ‘가져오기는 되지만 연결되지 않는’ 레코드가 생길 수 있습니다.

원본 내용을 로컬의 통제된 환경에 복사하고 구독 응답인지, 공유 링크인지, 전체 JSON인지 판단합니다.
디코딩하고 필드 객체로 파싱한 뒤 포트, 사용자 식별자, 필수 매개변수의 자료형을 검사합니다.
대상 클라이언트와 코어의 기능에 따라 표현 가능한 필드를 선별하고 매핑할 수 없는 항목을 기록합니다.
대상 형식을 생성한 뒤 다시 한 번 파싱하여 주소, 포트, 보안 계층, 전송 계층이 일치하는지 비교합니다.
클라이언트에 별도의 테스트 그룹을 만들고 현재 사용할 수 있는 원본 구독을 덮어쓰지 않습니다.
연결 후 코어 로그를 확인하고 DNS, TCP, 필요한 UDP 환경을 각각 검증합니다.

결론: 변환 전 원본 구독을 보존하고 변환 후 필드를 다시 확인하세요

가장 확실한 검수 방법은 ‘가져오기 성공’이라는 표시를 보는 데 그치지 않고 생성 결과를 다시 파싱해 항목별로 비교하는 것입니다. 주소, 포트, 사용자 식별자, TLS 서버 이름, 전송 경로가 모두 일치하는지 확인한 뒤 연결 테스트를 진행하세요.

구독 주소와 공유 링크에는 접근 인증 정보가 직접 포함될 수 있습니다. 스크린샷으로 문제를 공유할 때는 전체 구독 URL, 사용자 식별자, 인증 필드를 가리세요. 로그를 공유할 때는 오류 유형, 시간, 필요한 네트워크 상태만 남기세요. 구독 주소가 이미 공개 기록에 포함되었다면 서비스 제공자 관리 화면에서 구독 인증 정보를 변경한 뒤 클라이언트의 기존 주소를 삭제하고 전체 업데이트를 한 번 실행하세요.