구독 링크 형식 완벽 가이드: base64, 네이티브 JSON, 공유 링크의 차이와 변환

v2rayN, v2rayNG 또는 v2flyNG에 서버를 추가할 때 받는 내용은 https://로 시작하는 구독 주소일 수도 있고, 뚜렷한 구조가 보이지 않는 base64 문자열일 수도 있습니다. 또는 vmess://, vless://로 시작하는 단일 노드 공유 링크일 수도 있습니다. 모두 연결 정보를 담지만 업데이트 방식, 이식성, 가져오기 경로는 서로 다릅니다.

먼저 구독 주소, 인코딩된 본문, 공유 링크를 구분하세요

‘구독 링크’는 흔히 넓은 의미로 사용됩니다. 엄밀히 말하면 구독 주소는 반복 요청할 수 있는 네트워크 진입점이며, 클라이언트가 접속해야 노드 목록을 받습니다. base64는 서버가 노드 목록을 반환할 때 자주 사용하는 인코딩 방식이고, 공유 링크는 보통 하나의 노드만 설명합니다. 네이티브 JSON은 전체 설정 파일이나 구조화된 API 응답에 가깝고, 그 자체로 업데이트 가능한 구독을 의미하지는 않습니다.

가장 빠른 식별 방법은 시작 부분을 확인하는 것입니다. https://로 시작하고 경로가 긴 내용은 보통 원격 구독 주소입니다. 영문 대소문자, 숫자, 더하기, 슬래시 또는 밑줄이 이어지는 긴 문자열은 base64나 URL-safe base64일 수 있습니다. vmess://, vless://로 시작하면 프로토콜 공유 링크이고, 여는 중괄호로 시작하며 쌍을 이루는 필드명이 포함되어 있으면 대개 JSON입니다.

base64 구독 본문 복원 및 점검 방법

base64는 인코딩 방식이지 암호화 프로토콜이 아닙니다. 원본 바이트를 텍스트 전송에 적합한 문자로 바꾸므로, 읽기 어려운 긴 문자열이 보인다고 해서 내용이 보호 처리된 것은 아닙니다. 일반적인 V2Ray 구독은 여러 공유 링크를 줄바꿈으로 연결한 뒤 전체를 한 번에 base64로 인코딩합니다. 디코딩하면 대개 한 줄에 하나씩 vmess:// 또는 vless:// 주소가 나옵니다.

표준 base64에는 대소문자, 숫자, +, /, 끝에 붙는 패딩 문자 =가 자주 사용됩니다. URL-safe 변형에서는 +를 -로, /를 _로 바꾸며 끝의 패딩을 생략하기도 합니다. 클라이언트는 보통 두 변형을 모두 지원하지만, 직접 확인할 때는 문자와 패딩을 먼저 복원해야 합니다.

1. 현재 내용이 https://로 시작하는 원격 주소가 아니라 서버가 반환한 본문인지 확인합니다.
2. 복사 과정에서 들어간 공백과 앞뒤 줄바꿈은 제거하되, 본문 중간에 있을 수 있는 유효한 문자는 삭제하지 마세요.
3. URL-safe base64의 -와 _를 표준 문자로 되돌리고, 길이가 4의 배수가 되도록 패딩을 추가합니다.
4. 디코딩 후 각 줄에 명확한 프로토콜 접두사가 있는지, 노드 이름이 깨지지 않았는지, 포트가 1~65535 범위인지 확인합니다.
5. 디코딩 결과가 여전히 base64 문자열이라면 VMess 공유 링크 내부의 2차 인코딩인지 확인하세요. 무조건 반복해서 디코딩하면 안 됩니다.

아래 브라우저 콘솔 코드는 현재 기기의 텍스트만 처리합니다. 실행하면 입력창이 표시되고 디코딩 결과가 콘솔에 출력됩니다. 구독 본문에는 서버 주소, 사용자 식별자, 전송 매개변수가 포함되는 경우가 많으므로 실제 내용을 출처가 불분명한 온라인 변환 페이지에 제출하지 마세요.

const encoded = prompt("base64 구독 본문 붙여넣기").trim();
const normalized = encoded.replace(/-/g, "+").replace(/_/g, "/");
const padded = normalized.padEnd(
  Math.ceil(normalized.length / 4) * 4,
  "="
);
const bytes = Uint8Array.from(
  atob(padded),
  character => character.charCodeAt(0)
);
console.log(new TextDecoder().decode(bytes));

네이티브 JSON 설정의 핵심 필드

V2Ray 또는 Xray 커널이 사용하는 네이티브 JSON은 서버 주소만 담는 형식이 아니라 설정 트리입니다. 실행 가능한 설정에는 보통 로컬 인바운드 inbounds와 원격 아웃바운드 outbounds가 최소한 필요하며, 필요에 따라 routing, dns, log와 정책 필드가 추가됩니다. 구독 서비스가 반환하는 사용자 정의 JSON 노드 배열은 전혀 다른 필드명을 사용할 수 있으므로 클라이언트의 명시적인 지원이 필요합니다. JSON이라는 이유만으로 커널 설정으로 바로 가져올 수는 없습니다.

아래는 필드 계층을 이해하기 위한 VLESS 및 WebSocket 예시입니다. 예시 도메인은 문서용이며, outbounds의 프로토콜 매개변수와 streamSettings의 전송 매개변수가 어떻게 나뉘는지 확인하는 데 초점을 둡니다.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "edge.example.net",
            "port": 443,
            "users": [
              {
                "id": "d342d11e-d424-4583-b36e-524ab1f0afa4",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "wsSettings": {
          "path": "/gateway"
        },
        "tlsSettings": {
          "serverName": "edge.example.net"
        }
      }
    }
  ]
}

• address에는 호스트명만 입력하고, WebSocket 경로는 wsSettings.path에 별도로 입력합니다.
• VLESS 사용자 항목의 encryption은 보통 none으로 설정하며, 전송 계층의 TLS 활성화 여부는 streamSettings.security가 결정합니다.
• 로컬 SOCKS 인바운드는 127.0.0.1에서 수신 대기하므로 로컬 기기의 연결만 허용합니다. LAN 공유가 필요하다면 수신 주소와 접근 제어를 별도로 검토해야 합니다.
• 전체 설정에는 직접 연결, 차단 등 여러 아웃바운드가 포함될 수 있으며, tag와 라우팅 규칙으로 서로 연결합니다.

VMess와 VLESS 공유 링크의 내부 차이

VMess 공유 링크는 보통 vmess:// 뒤에 base64 내용이 이어지는 형태입니다. 디코딩하면 주소, 포트, 사용자 식별자, 전송 유형, TLS 상태, WebSocket 경로, 노드 메모 등이 포함된 JSON 객체가 나옵니다. 이 JSON은 단일 노드 공유용 구조이며 커널이 바로 실행하는 전체 설정과는 다릅니다. 일반적으로 로컬 인바운드, DNS, 라우팅 등이 빠져 있기 때문입니다.

VLESS 공유 링크는 표준 URI에 더 가깝습니다. 사용자 식별자는 @ 앞에, 서버와 포트는 그 뒤에 오며, 전송 방식, 보안 계층, 서버 이름, 경로 등의 매개변수는 쿼리 문자열에 넣습니다. 노드 이름은 # 뒤에 표시합니다. 단순화한 구조는 다음과 같이 쓸 수 있습니다.

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

d342d11e-d424-4583-b36e-524ab1f0afa4

사용자 식별자이며, 가져올 때 문자와 하이픈을 모두 그대로 유지해야 합니다.

edge.example.net:443

서버 주소와 포트이며, 포트 앞에는 반각 콜론을 사용합니다.

security=tls

전송 보안 계층 매개변수이며, 프로토콜 필드 자체가 바뀐다는 뜻은 아닙니다.

type=ws

WebSocket 전송을 사용하며 서버 측 설정과 일치해야 합니다.

path=%2Fgateway

URL 인코딩된 경로이며, 디코딩하면 /gateway가 됩니다.

#Example-WS

클라이언트에 표시되는 이름이며 서버 인증에는 사용되지 않습니다.

세 형식을 매개변수 손실 없이 변환하는 방법

가장 흔한 변환은 ‘구독 본문을 공유 링크 목록으로 바꾸는 것’입니다. 원격 응답이 base64라면 먼저 UTF-8로 디코딩한 다음 줄바꿈으로 나눕니다. 각 줄은 대개 바로 가져올 수 있는 공유 링크입니다. 반대로 변환할 때는 여러 공유 링크를 줄바꿈으로 연결한 뒤 전체를 base64로 인코딩합니다. 이 과정은 포장 방식만 바꿀 뿐 정적 텍스트에 원격 업데이트 기능을 추가하지는 않습니다.

‘공유 링크를 네이티브 JSON으로 변환’하려면 필드 매핑이 필요합니다. VLESS를 예로 들면 URI의 사용자 식별자는 settings.vnext[].users[].id로, 호스트와 포트는 address와 port로 들어갑니다. 쿼리 매개변수의 type은 streamSettings.network에 대응하고, security는 전송 보안 계층에 대응하며, sni와 경로는 각각의 전송 설정에 입력합니다. 실행 가능한 설정을 만들려면 로컬 인바운드와 필요한 아웃바운드도 추가해야 합니다.

1. 먼저 원본 내용을 백업하고, 원격 주소·응답 본문·단일 노드 링크를 구분합니다.
2. 보존해야 할 필드를 나열합니다: 프로토콜, 서버, 포트, 사용자 식별자, 전송 방식, 보안 계층, 서버 이름, 경로, 메모.
3. 디코딩이나 구조 변환이 끝나면 필드를 하나씩 비교하세요. 노드 이름이 표시되는지만 확인해서는 안 됩니다.
4. 먼저 노드 하나를 가져와 로그와 연결을 테스트한 뒤 나머지 노드를 일괄 처리합니다.
5. 클라이언트의 구독 기록에 원본 https:// 주소가 그대로 저장되어 있는지 확인하고 수동 업데이트를 한 번 실행합니다.

v2rayN, v2rayNG, v2flyNG에 올바르게 가져오기

v2rayN 7.x의 구독 메뉴는 보통 「구독 그룹」→「구독 그룹 설정」에 있습니다. 그룹을 추가할 때 원격 주소를 입력하고 저장한 뒤 「구독 그룹」→「모든 구독 업데이트」로 노드를 가져옵니다. 단일 노드 공유 링크는 먼저 클립보드에 복사한 다음 서버 가져오기 관련 메뉴를 사용하면 됩니다. 세부 버전에 따라 메뉴 문구가 조금 다를 수 있지만 ‘구독 그룹’과 ‘서버 가져오기’는 서로 독립된 경로입니다.

연결 후에도 시스템 앱에 트래픽이 없으면 「설정」→「매개변수 설정」에서 로컬 포트를 확인합니다. 일반적인 설정은 SOCKS 포트 10808과 HTTP 포트 10809를 사용하지만 실제 값은 현재 설정 화면을 기준으로 해야 합니다. 다른 프로그램이 포트를 사용 중이면 커널 로그에 수신 대기 실패가 표시되는 경우가 많습니다. 이때 비어 있는 포트로 바꾸고 브라우저 또는 시스템 프록시 설정도 함께 수정합니다.

• v2rayN: 데스크톱 구독 그룹, 대량 노드 관리, 사용자 지정 라우팅에 적합합니다. 가져온 후 먼저 구독을 업데이트하고 활성 서버를 선택한 다음 시스템 프록시 모드를 설정하세요.
• v2rayNG: Android에서 Xray 커널을 사용하며 VMess, VLESS 공유 링크와 원격 구독을 가져오기에 적합합니다. 업데이트 후 현재 선택한 노드가 여전히 존재하는지 확인하세요.
• v2flyNG: Android에서 v2fly 커널을 사용하며 VMess 등 호환 설정 중심의 환경에 적합합니다. 확장 매개변수를 만났다면 먼저 커널이 해당 필드를 인식하는지 확인하세요.

구독 관리 및 문제 해결 순서

형식 문제와 네트워크 문제는 쉽게 뒤섞입니다. 구독 요청 시간 초과는 ‘내용 가져오기’ 단계에서 발생하고, base64 문자 이상이나 JSON 필드 오류는 ‘내용 파싱’ 단계에서 발생하며, 노드 연결 시간 초과는 ‘설정 사용’ 단계에서 발생합니다. 단계별로 로그를 확인하면 네트워크에 접속할 수 없을 때 형식만 반복해서 수정하는 일을 피할 수 있고, 매개변수 오류가 있을 때 로컬 프록시 포트를 무작정 바꾸는 일도 줄일 수 있습니다.

원격 구독 주소, 최근 성공한 업데이트 시간, 클라이언트 버전을 기록해 두는 것이 좋습니다. 노드에 문제가 생기면 먼저 수동 업데이트를 하고, 확실히 사용할 수 있는 노드 하나를 테스트한 뒤 커널 로그를 확인하세요. v2rayN에서는 구독 그룹 상태와 로그 패널을 함께 확인할 수 있으며, Android에서는 업데이트 후 현재 설정이 바뀌거나 삭제되지 않았는지 살펴봐야 합니다.

1. 가져오기 단계: 구독 도메인, HTTPS 연결, 응답 상태를 확인하고 클라이언트가 실제로 본문을 받았는지 확인합니다.
2. 파싱 단계: 본문이 base64인지 JSON인지 공유 링크 목록인지 판단하고 줄바꿈, 패딩, 문자 인코딩을 확인합니다.
3. 가져오기 적용 단계: 클라이언트에 노드가 추가되었는지, 노드 수와 그룹 이름이 예상과 일치하는지 확인합니다.
4. 연결 단계: 주소, 포트, 사용자 식별자, 전송 방식, 보안 계층, 서버 이름, 경로를 확인합니다.
5. 프록시 단계: 활성 서버, 시스템 프록시 모드, 10808·10809 등의 로컬 포트가 정상적으로 수신 대기 중인지 확인합니다.
6. 라우팅 단계: 연결은 정상인데 특정 도메인에서만 이상이 발생할 때 routing.rules의 순서와 아웃바운드 태그를 확인합니다.