구독 형식 가이드: base64·기본 JSON·공유 링크 상호 변환 방법

세 형식은 각각 무엇인가

같은 노드 정보라도 어떤 그릇에 담느냐에 따라 모습이 완전히 달라집니다. base64 구독은 일괄 목록, 기본 JSON은 전체 설정, 공유 링크는 단일 레코드입니다.

세 형식의 정보량은 서로 같지 않습니다. 구독에 들어 있는 링크 한 줄은 보통 아웃바운드(outbound) 하나만 설명하지만, 기본 JSON은 인바운드, 라우팅, DNS, 로그 같은 클라이언트 측 설정까지 함께 담습니다. 이 차이를 헷갈리는 것이 이후 모든 변환 문제의 출발점입니다.

base64 구독의 인코딩 규칙

base64 구독은 인코딩이 한 겹 더 붙는 구조입니다. 서버가 여러 줄의 공유 링크를 하나의 일반 텍스트로 합친 뒤 전체를 한 번 base64로 인코딩해 HTTP 응답으로 돌려줍니다. 클라이언트는 받아온 뒤 먼저 디코딩해서 한 줄에 링크 하나씩 있는 목록을 얻습니다.

디코딩에 실패하면 클라이언트는 평문으로 간주해 처리하므로, 같은 파싱 로직으로 base64 구독과 평문 구독을 모두 소화할 수 있습니다. 직접 디코딩할 때는 아래 명령 하나만 기억하면 됩니다.

# 구독이 반환한 원문을 sub.txt로 저장한 뒤 전체를 한 번 디코딩
base64 -d sub.txt > nodes.txt    # GNU coreutils
base64 -D sub.txt > nodes.txt    # macOS / BSD

wc -l nodes.txt                  # 줄 수는 보통 노드 개수와 같음
head -n 2 nodes.txt

디코딩 결과에서 각 줄 맨 앞이 바로 프로토콜 접두사이며, 흔한 것은 vmess://와 vless://입니다. 한 구독 안에 여러 접두사가 섞여 있어도 정상이며, 클라이언트는 줄 단위로 하나씩 파싱합니다.

• URL-safe 변형: 일부 패널은 +, /를 -, _로 바꾸므로 디코딩 전에 되돌리거나, URL-safe를 지원하는 디코더를 바로 사용합니다.
• padding: 끝의 =는 자주 생략되므로 길이가 4의 배수가 아니면 직접 채운 뒤 디코딩합니다.
• 줄 단위와 전체 단위: 드물게 각 줄의 링크를 따로 인코딩한 구독도 있는데, 이때는 줄 단위로 디코딩해야 하며 전체를 한 번에 풀면 깨진 문자만 나옵니다.

풀어낸 첫 줄이 vmess://도 vless://도 아니라면 원문이 이미 평문 구독이라는 뜻이므로 더 디코딩할 필요가 없습니다.

공유 링크의 필드 구조

vmess와 vless의 차이는 인코딩 방식에 있습니다. vmess 링크는 'JSON을 base64로 한 겹 감싼' 형태이고, vless 링크는 'URI에 쿼리 파라미터를 붙인' 형태입니다. 앞쪽은 풀어낸 필드 이름이 전부 약어이고, 뒤쪽은 주소창에서 바로 읽을 수 있습니다.

vmess:// 뒤의 base64 전체를 한 번 디코딩하면 아래 객체가 나옵니다:

{
  "v": "2",              // 링크 형식 버전, 항상 2
  "ps": "홍콩-01",      // 비고, 가져오면 노드 이름이 됨
  "add": "example.com", // 서버 주소
  "port": "443",        // 포트, 여기서는 문자열
  "id": "b831381d-6324-4d53-ad4f-8cda48b30811",
  "aid": "0",           // alterId, VMess에만 있음
  "scy": "auto",        // 암호화 방식
  "net": "ws",          // 전송 계층
  "type": "none",       // 위장 유형
  "host": "example.com", // WS의 Host 헤더
  "path": "/ws",       // WS 경로
  "tls": "tls"          // TLS 사용 여부
}

vless 링크에는 내부 base64가 없고, 모든 파라미터가 ? 뒤의 쿼리 문자열에 들어가며 # 뒤는 비고입니다. 파라미터 이름이 vmess의 약어보다 직관적이지만 URI 규칙에 맞춰 URL 인코딩을 해야 합니다.

vless://[email protected]:443?encryption=none&security=reality&sni=www.example.com&fp=chrome&pbk=UuMBgl8KtNqHqY7p&sid=0123abcd&flow=xtls-rprx-vision&type=tcp#홍콩-01

두 링크는 같은 내용을 설명할 뿐 필드 이름과 배치만 다릅니다. 아래 네 개 카드에서 자주 쓰는 필드, 기본 JSON의 최상위 구조, 로컬 포트 관례를 한데 모아 대조합니다.

세 형식은 서로 어떻게 변환할까

변환 경로는 네 단계로 고정됩니다. 구독에서 링크 목록을 풀고, 링크를 필드로 되돌리고, 필드를 다시 기본 JSON으로 조립합니다. 반대 방향으로 가면 내보내기가 됩니다.

1. 구독 원문 꺼내기

   브라우저에서 구독 주소를 열고 응답 내용 전체를 sub.txt로 저장합니다. 응답은 base64 한 덩어리일 수도 있고 평문 링크 목록일 수도 있습니다.

2. 링크 목록 풀어내기

   base64 -d sub.txt > nodes.txt를 실행하면 한 줄에 링크 하나씩 있는 공유 링크 목록이 나옵니다. 프로토콜 접두사는 줄 맨 앞에, 비고는 줄 끝 # 뒤에 있습니다.

3. 단일 노드 복원하기

   vmess는 vmess:// 뒤 내용을 base64로 한 번 더 풀어 JSON을 얻고, vless는 ? 뒤의 쿼리 파라미터를 그대로 읽으면 되므로 추가 디코딩이 필요 없습니다.

4. 기본 JSON으로 조립하기

   필드를 outbounds의 vnext와 streamSettings에 채워 넣습니다. port는 숫자로 바꾸고, tag는 직접 이름을 정하고, address에는 프로토콜 접두사를 붙이지 않습니다.

네 번째 단계에서 조립한 아웃바운드는 대략 이런 모습이며, 필드는 위의 vless 링크와 하나씩 대응합니다:

{
  "outbounds": [{
    "tag": "proxy",
    "protocol": "vless",
    "settings": {
      "vnext": [{
        "address": "example.com",
        "port": 443,
        "users": [{
          "id": "b831381d-6324-4d53-ad4f-8cda48b30811",
          "encryption": "none",
          "flow": "xtls-rprx-vision"
        }]
      }]
    },
    "streamSettings": {
      "network": "tcp",
      "security": "reality",
      "realitySettings": {
        "serverName": "www.example.com",
        "publicKey": "UuMBgl8KtNqHqY7p",
        "shortId": "0123abcd",
        "fingerprint": "chrome"
      }
    }
  }] // 아웃바운드 배열
}

역방향 변환도 같습니다. 기본 JSON의 settings.vnext[0]과 streamSettings는 링크 파라미터를 펼쳐 놓은 형태이므로, address, port, id를 꺼내 프로토콜 규칙에 맞춰 다시 URI로 인코딩하면 됩니다. VMess는 alterId를 aid로 되돌려 써야 합니다.

클라이언트에는 더 간편한 경로도 두 가지 있습니다. v2rayN은 '사용자 지정 설정' 유형의 서버를 지원하므로 완성된 JSON을 설정 상자에 붙여 넣으면 코어가 그대로 읽고, 클라이언트가 아웃바운드를 조립하지 않습니다. 반대로 구독 목록에서 단일 노드의 공유 링크를 복사해 다른 기기의 v2rayNG에 붙여 넣고 '⋮' → '클립보드에서 설정 가져오기'를 쓰면 됩니다.

변환할 때 가장 잘 빠지는 필드

필드가 빠지는 일은 거의 모두 수작업으로 옮기는 단계에서 생깁니다. 복사·붙여넣기 중 잘리거나, 문자열과 숫자를 혼용하거나, 약어에서 글자 하나를 놓치는 경우입니다. 아래 항목을 하나씩 대조하면 '가져오기는 됐는데 연결이 안 되는' 상황 대부분을 잡아낼 수 있습니다.

• flow=xtls-rprx-vision: Reality 노드에서는 필수입니다. 빠뜨리면 클라이언트가 일반 VLESS로 처리해 서버 측 핸드셰이크가 바로 실패합니다.
• pbk와 sid: Reality의 공개키와 short ID는 항상 짝으로 쓰이므로 하나만 옮기면 옮기지 않은 것과 같습니다.
• encryption=none: VLESS의 고정값이며, 빠뜨리면 일부 클라이언트가 이 링크의 가져오기를 거부합니다.
• aid: VMess의 alterId로, 링크에서는 문자열이고 기본 JSON에서는 숫자입니다. 오래된 서버는 2나 64를 쓰는 경우가 많아, 비워 두고 0으로 처리되면 핸드셰이크가 실패합니다.
• port의 타입: 링크 JSON에서는 "443"이지만 기본 JSON에서는 반드시 443이어야 하며, 따옴표가 붙으면 코어가 유효하지 않은 설정으로 판단합니다.
• serviceName: type=grpc일 때 path 대신 사용하며, 둘을 바꿔 넣으면 요청 경로가 맞지 않습니다.
• host와 sni: 앞은 WS의 Host 헤더, 뒤는 TLS SNI입니다. CDN 환경에서는 둘이 다른 게 정상이며, 바꿔 넣으면 403이 돌아옵니다.
• outboundTag: routing.rules 안의 값은 outbounds의 tag와 글자 하나까지 같아야 하며 대소문자를 구분합니다.

어떤 상황에 무엇을 쓸까

세 형식에 우열은 없고 역할만 다릅니다. 판단 기준은 두 가지뿐입니다. 노드 목록이 바뀌는지, 그리고 이 기기에 분할 라우팅 규칙이 필요한지.

공유 링크는 그 중간에 있습니다. 구독보다 임시 가져오기에 적합하고, 기본 JSON보다 클라이언트 간 복사에 적합합니다. 같은 링크를 v2rayN과 v2rayNG에 붙여 넣어도 나오는 아웃바운드 파라미터는 같고, 차이는 로컬 포트와 분할 라우팅 규칙을 각 클라이언트가 자기 설정에 둔다는 점뿐입니다.

실제로 더 흔한 조합은 서버에서 구독 주소 하나를 관리하고, 클라이언트에 로컬 라우팅 규칙을 한 벌 더 두는 방식입니다. 노드는 구독을 따라 갱신되고 분할 라우팅 로직은 로컬에 남아 서로 간섭하지 않습니다.

자주 묻는 질문

세 형식의 변환 관계는 복잡하지 않습니다. 구독을 한 겹 풀면 링크가 나오고, vmess 링크를 한 겹 더 풀면 필드가 나오며, 필드를 펼치면 기본 JSON이 됩니다. 시간이 오래 걸리는 쪽은 디코딩이 아니라 필드를 하나도 빠뜨리지 않고 제자리에 옮기는 일입니다.