V2Ray 구독 형식 완벽 해설: base64, 네이티브 JSON, 공유 링크 변환 방법

이 글 한눈에 보기

구독 내용을 확인하거나 단일 노드를 옮기거나 가져오기 실패 원인을 찾는 사용자에게 적합합니다. 인코딩 컨테이너, 공유 링크, 코어 설정의 세 가지 계층을 구분하고 필드 매핑으로 안전하게 변환하는 방법을 익힐 수 있습니다.

먼저 인코딩, 노드, 실행 설정을 구분하기

“V2Ray 구독”은 엄밀하게 통일된 하나의 파일 형식이 아닙니다. 실제로는 여러 줄의 공유 링크를 반환하는 네트워크 주소를 뜻하기도 하고, 이미 디코딩된 노드 목록이나 V2Fly 또는 Xray 코어가 바로 읽을 수 있는 JSON 설정을 가리키기도 합니다. 세 형식 모두 서버 정보를 담지만 용도와 정보량은 서로 다릅니다.

base64는 인코딩 방식일 뿐 프로토콜이 아닙니다. 텍스트를 전송하기 편한 문자 집합으로 바꿀 뿐, 서버를 자동으로 검증하거나 전송 파라미터를 보완하거나 라우팅 규칙을 생성하지는 않습니다. 일반적인 구독 응답의 내부에는 줄바꿈으로 구분된 vmess://, vless:// 또는 trojan:// 링크가 들어 있고, 바깥쪽 전체가 한 번 더 base64로 인코딩됩니다.

공유 링크는 하나의 아웃바운드 노드를 설명합니다. 보통 서버 주소, 포트, 사용자 식별자, 전송 방식, TLS 파라미터, 별칭을 포함합니다. 반면 네이티브 JSON은 코어 실행을 위한 형식으로, 아웃바운드 외에도 인바운드 리스너, DNS, 로그, 라우팅 규칙, 정책 설정을 담을 수 있습니다. 따라서 JSON에서 공유 링크를 추출하면 대개 아웃바운드 하나만 보존되며, 반대로 변환해도 원래의 전체 규칙을 되살릴 수 없습니다.

base64 구독

권장

여러 노드를 한곳에서 배포하고 구독 주소를 기준으로 클라이언트가 정기적으로 업데이트할 때 적합합니다. 디코딩하면 보통 한 줄에 하나씩 공유 링크가 들어 있는 텍스트가 나옵니다.

적합한 용도: 일상적인 구독 업데이트, 다중 노드 그룹화

단일 공유 링크

노드 하나를 복사해 여러 기기에 가져오기 쉽고, 해당 노드의 아웃바운드 연결 파라미터에 집중할 수 있습니다.

적합한 용도: 단일 노드 이전, 파라미터 항목별 확인

네이티브 JSON

코어 설정 트리를 직접 표현하며 여러 인바운드·아웃바운드, DNS, 라우팅 규칙을 담을 수 있어 구조가 가장 완전합니다.

적합한 용도: 세밀한 라우팅, 코어 설정 수동 관리

결론: 바깥 계층부터 확인한 뒤 내부를 해석하기

긴 문자열을 봤다고 여러 번 연속으로 디코딩하지 마세요. 먼저 응답이 JSON인지, 평문 링크 목록인지, base64 텍스트인지 판단하고, 한 계층을 변환할 때마다 올바른 프로토콜 헤더가 나타나는지 확인해야 합니다.

base64 구독 안에는 무엇이 들어 있나

일반적인 구독 서비스는 평문을 반환합니다. 클라이언트는 응답을 받은 뒤 앞뒤 공백을 제거하고 한 번 base64 디코딩한 다음, \n 또는 \r\n으로 나눕니다. 빈 줄은 무시하고 각 비어 있지 않은 줄을 프로토콜 헤더에 따라 해당 파서로 넘깁니다. 디코딩 결과가 이미 왼쪽 중괄호로 시작한다면 JSON일 수 있으므로 링크 목록으로 계속 나눠서는 안 됩니다.

표준 base64는 대소문자, 숫자, 더하기 기호, 슬래시를 사용하며 끝에 등호 패딩이 붙을 수 있습니다. URL 안전 변형에서는 더하기 기호와 슬래시를 각각 하이픈과 밑줄로 바꿉니다. 일부 구독은 끝의 패딩을 생략하므로 파서는 길이에 맞춰 보완해야 하지만 중간 문자는 수정하면 안 됩니다. UTF-8 바이트 순서 표시, 응답 앞뒤의 안내 문구, HTML 오류 페이지도 디코딩 실패의 원인이 됩니다.

바깥쪽 구독 응답
        ↓ base64 한 번 디코딩
vmess://인코딩된 노드 설명
vless://사용자 식별자@edge.example:443?encryption=none&security=tls&type=ws#예시 노드
trojan://인증 정보@edge.example:443?security=tls&type=tcp#백업 노드
        ↓ 줄 단위로 프로토콜 식별
노드 1, 노드 2, 노드 3

내용이 실제 구독인지 판단할 때는 문자들이 base64 문자 집합에 맞는지만 봐서는 안 됩니다. 짧은 영문이나 숫자 문자열, 일반 텍스트도 우연히 규칙에 맞을 수 있습니다. 더 확실한 방법은 디코딩한 UTF-8 텍스트에 지원되는 프로토콜 헤더가 있거나 예상한 구조의 JSON이 나오는지 확인하는 것입니다. 서버 응답 상태도 점검해야 합니다. 예를 들어 HTTP 200일 때만 파싱을 진행하고, 301 또는 302는 클라이언트 정책에 따라 리디렉션을 처리하며, 401과 403은 대개 주소 인증 정보나 접근 조건이 바뀌었다는 뜻입니다.

일반적인 응답 특징

평문 목록: 첫 줄이 바로 vmess://, vless:// 또는 trojan://으로 시작하며 바깥 계층을 먼저 디코딩할 필요가 없습니다.
인코딩된 목록: 응답 본문이 연속된 문자열이며 한 번 디코딩하면 여러 줄의 프로토콜 링크가 나타납니다.
JSON 응답: 최상위 요소가 객체 또는 배열일 수 있으므로 제공 업체의 정의에 따라 읽어야 하며, 일반적인 줄바꿈 규칙을 적용하면 안 됩니다.
오류 페이지: <html 또는 읽을 수 있는 오류 설명으로 시작한다면 변환을 중단하고 구독 주소를 확인해야 합니다.

VMess와 VLESS 공유 링크의 필드 차이

vmess://는 노드 JSON 객체 전체를 인코딩한 뒤 프로토콜 헤더 다음에 넣는 방식이 일반적입니다. 디코딩한 객체에는 버전, 별칭, 서버 주소, 포트, 사용자 식별자, 전송 방식, 위장 유형, 경로, TLS, SNI 등의 필드가 자주 포함됩니다. 과거 구현에서는 필드명이 짧은 경우가 많으며, 예를 들어 add는 주소, port는 포트, id는 사용자 식별자를 뜻합니다.

vless://는 표준 URL에 더 가깝습니다. 사용자 식별자는 사용자 이름 위치에, 호스트와 포트는 authority 부분에, 전송 및 보안 파라미터는 쿼리 문자열에, 별칭은 해시 기호 뒤에 위치합니다. 파싱할 때는 먼저 URL 퍼센트 디코딩을 수행하고 쿼리 파라미터와 별칭을 구분해야 합니다. 443 포트는 TLS 연결에 자주 사용되고 80 포트는 TLS를 사용하지 않는 HTTP 또는 WebSocket 진입점에서 흔하지만, 포트 번호만으로 보안 계층의 활성화 여부를 판단할 수는 없습니다.

연결 정보	VMess 주요 필드	VLESS URL 위치	변환 시 주의점
서버 주소	`add`	호스트 부분	도메인과 IPv6 주소는 표기 방식이 다르며 IPv6에서는 대괄호 의미를 유지해야 합니다.
포트	`port`	호스트 뒤의 포트	1부터 65535까지의 정수로 변환해야 합니다.
사용자 식별자	`id`	사용자 이름 부분	기존 값을 그대로 복사해야 하며 별칭이나 서버 주소에서 추론할 수 없습니다.
전송 방식	`net`	`type` 파라미터	WebSocket, TCP, gRPC의 추가 필드는 서로 다릅니다.
경로 또는 서비스 이름	`path`	`path` 또는 `serviceName`	슬래시, 공백, 특수 문자는 올바르게 인코딩해야 합니다.
서버 이름	`sni`	`sni` 파라미터	연결 주소와 기본적으로 같다고 보면 안 됩니다.
별칭	`ps`	해시 기호 뒤의 fragment	표시 이름에만 영향을 주며 연결 수립에는 사용되지 않습니다.

VMess 링크는 생성기마다 불리언 값을 문자열로 쓰거나 포트를 숫자 또는 문자열로 기록할 수 있습니다. 변환 도구는 먼저 타입을 정규화한 다음 대상 형식으로 출력해야 합니다. VLESS 링크는 중복 쿼리 파라미터, 파라미터 대소문자, 퍼센트 인코딩도 처리해야 합니다. 알 수 없는 파라미터는 조용히 버리기보다 확장 필드에 원본 그대로 보존하는 편이 좋습니다.

결론: 프로토콜 이름이 같아도 파라미터가 동일한 것은 아니다

변환할 때는 최소한 주소, 포트, 사용자 식별자, 전송 방식, 보안 계층, SNI, 경로의 일곱 항목을 확인해야 합니다. 앞의 세 항목만 복사하면 가져오기는 되지만 연결되지 않는 노드가 생기기 쉽습니다.

네이티브 JSON을 구독으로 바로 사용할 수 없는 이유

코어 JSON은 전체 실행 설정입니다. 일반적인 데스크톱 설정은 루프백 주소의 포트 10808을 로컬 인바운드로 지정한 뒤 하나 이상의 아웃바운드를 정의합니다. 라우팅은 도메인, IP 또는 인바운드 태그에 따라 아웃바운드를 선택하고, DNS 설정은 해석 방식을 결정합니다. 공유 링크에는 이러한 관계를 표현할 공간이 부족하므로 클라이언트는 보통 자체 기본 인바운드와 라우팅 템플릿을 사용합니다.

아래 구조는 필드 계층만 보여 주며 설명 문구는 그대로 연결할 수 있는 설정이 아닙니다. 동일한 아웃바운드 노드를 네이티브 JSON의 outbounds에 넣어야 하고, 로컬 프록시 포트는 inbounds에 위치한다는 점을 보여 줍니다. 둘을 혼동해서는 안 됩니다.

{
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks"
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "edge.example",
            "port": 443,
            "users": [
              {
                "id": "서비스 제공자가 할당한 사용자 식별자",
                "security": "auto"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "wsSettings": {
          "path": "/gateway"
        }
      }
    }
  ]
}

네이티브 JSON에서 VMess 공유 링크를 만들 때는 먼저 대상 아웃바운드를 선택하고, settings.vnext에서 서버와 사용자 정보를 읽은 다음 streamSettings를 전송 필드에 매핑해야 합니다. 하나의 아웃바운드에 여러 서버나 사용자가 포함되어 있다면 여러 링크로 확장해야 할 수 있습니다. 반대로 JSON을 생성할 때는 클라이언트가 로컬 인바운드, 로그, 라우팅 기본값도 보완해야 합니다.

변환 과정에서 보통 손실되는 내용

도메인, IP, 포트 또는 프로세스별로 설정한 라우팅 규칙과 우선순위입니다.
여러 아웃바운드 간 부하 분산 선택, 장애 조치, 태그 참조 관계입니다.
로컬 SOCKS, HTTP 또는 투명 프록시 인바운드의 리슨 주소와 포트입니다.
DNS 서버, 도메인 일치 규칙, 캐시 정책, 조회 경로입니다.
로그 수준, 통계 정책, 특정 코어 버전에서만 유효한 확장 항목입니다.

구독을 공유 링크로 변환하는 단계

안정적인 변환은 텍스트에 반복해서 디코딩을 시도하는 대신 계층적인 절차를 따라야 합니다. 먼저 원본 응답을 보존하고 콘텐츠 유형과 문자 인코딩을 기록한 뒤 바깥 계층을 판단합니다. 파싱이 끝나면 통합 노드 필드 모델을 만들고, 마지막으로 출력기별로 VMess·VLESS 링크 또는 코어 JSON을 생성합니다. 이렇게 하면 오류가 가져오기, 디코딩, 필드 파싱, 출력 중 어느 단계에서 발생했는지 쉽게 찾을 수 있습니다.

응답 확인
요청이 HTTP 200을 반환했는지, 로그인 페이지나 오류 페이지가 아닌지 확인합니다. 응답에 줄바꿈, JSON 시작 문자 또는 식별 가능한 프로토콜 헤더가 포함되어 있는지도 기록합니다.
바깥 계층 해제
내용이 인코딩된 구독의 특징에 부합할 때만 base64 디코딩을 한 번 수행합니다. 표준 문자표와 URL 안전 문자표를 모두 지원하고 결과는 UTF-8로 읽습니다.
노드 분리
CRLF 또는 LF로 줄을 나누고 빈 줄을 제거합니다. 각 줄은 vmess://, vless:// 또는 trojan://에 따라 해당 파서로 전달합니다.
필드 정규화
포트를 정수로 변환하고 전송 방식 이름을 통일합니다. 주소, 사용자 식별자, TLS, SNI, 경로, 별칭을 각각 저장하며 알 수 없는 필드는 별도로 보존합니다.
가져오기 및 검증
v2rayN에서 「설정」→「파라미터 설정」→「Core 유형」을 열어 선택한 코어가 대상 프로토콜을 지원하는지 확인한 다음 새 그룹으로 가져오고 코어 로그를 확인합니다.

검증은 “가져오기 성공”만으로 끝나지 않습니다. 가져오기 성공은 클라이언트가 문법을 받아들였다는 뜻일 뿐입니다. 노드 상세 정보의 서버, 포트, 전송 파라미터를 확인하고 실행 후 로그에서 DNS 실패, TLS 이름 불일치, 잘못된 경로, 포트 점유 여부를 살펴보세요. 로컬 포트로 10808을 사용한다면 다른 프로세스가 같은 리슨 포트를 점유하고 있지 않은지도 확인해야 합니다.

자동화에 적합한 점검 항목

구독 응답 크기가 적절한지 확인하고 빈 응답이면 즉시 파싱을 중단합니다.
디코딩 결과가 유효한 UTF-8인지, 비정상 바이트가 잘못된 문자 집합에서 비롯된 것인지 확인합니다.
각 노드의 포트가 1부터 65535 사이인지 확인합니다.
TLS가 활성화된 경우 SNI 또는 해당 서버 이름이 보존되어 있는지 확인합니다.
WebSocket 경로가 슬래시로 시작하는지, 쿼리 파라미터가 중복 인코딩되지 않았는지 확인합니다.
노드 별칭이 URL 디코딩되었는지 확인하고, 별칭이 연결 필드를 덮어쓰지 않도록 합니다.

v2rayN, v2rayNG, v2flyNG에서 가져오기

v2rayN은 데스크톱 환경에서 구독 그룹을 관리하는 데 적합합니다. 구독 주소를 추가한 뒤 업데이트하면 클라이언트가 노드 목록을 가져와 파싱합니다. 단일 공유 링크만 있다면 클립보드에서 가져오기 기능을 사용할 수 있습니다. 버전에 따라 메뉴 문구는 조금 다를 수 있지만, 구독 그룹을 만든 뒤 해당 그룹을 업데이트하고 노드를 선택해 시스템 프록시를 활성화하는 순서는 같습니다.

v2rayNG는 Xray 코어를 사용하고 v2flyNG는 V2Fly 코어를 사용합니다. 두 클라이언트 모두 일반적인 VMess 구독과 공유 링크를 처리할 수 있지만, 특정 프로토콜 확장의 지원 여부는 코어에 따라 달라집니다. 링크는 파싱되지만 실행할 때 알 수 없는 전송 방식이나 보안 유형이 표시된다면 base64 내용을 계속 수정하기보다 링크에 필요한 코어 기능을 확인해야 합니다.

구독 주소를 붙여 넣었는데 노드가 없나요?

먼저 브라우저가 아닌 클라이언트 로그에서 HTTP 상태를 확인합니다. 200이 반환되었다면 디코딩 결과에 프로토콜 헤더가 줄마다 들어 있는지 확인하고, JSON 객체가 반환되었다면 해당 가져오기 방식을 사용해야 합니다.

왜 한 번 디코딩해도 깨진 문자가 나오나요?

텍스트가 URL 안전 base64를 사용하는지 확인하고 끝의 등호 패딩을 보완하세요. 그래도 실패하면 응답에 안내 문구, UTF-8 바이트 순서 표시, HTML 오류 내용이 섞였는지 살펴봅니다.

노드는 성공적으로 가져왔는데 연결되지 않나요?

포트, 전송 방식, TLS, SNI, 경로를 항목별로 확인한 뒤 코어 로그를 살펴보세요. WebSocket 경로에서 슬래시 하나가 빠지거나 SNI가 누락되어도 핸드셰이크가 몇 초 안에 실패할 수 있습니다.

구독을 업데이트하면 수동 별칭이 덮어써지나요?

대부분의 클라이언트는 구독 응답에 따라 해당 그룹을 다시 구성하므로 수동으로 수정한 이름이 바뀔 수 있습니다. 장기간 보존할 노드는 별도 그룹에 복사하고 원래 구독 소속을 기록해 두세요.

네이티브 JSON을 구독 입력란에 바로 가져올 수 있나요?

보통은 불가능합니다. 구독 입력란은 네트워크 주소나 노드 목록을 기대하므로 코어 JSON은 클라이언트가 제공하는 사용자 지정 설정 메뉴로 가져와야 하며, 인바운드 포트·라우팅·DNS 설정도 별도로 확인해야 합니다.

v2rayN에서 코어 선택을 확인하려면 「설정」→「파라미터 설정」→「Core 유형」으로 이동해 현재 설정을 확인할 수 있습니다. 구독 업데이트 후 목록이 바뀌지 않는다면 먼저 올바른 그룹을 업데이트했는지 확인한 다음 로그의 타임스탬프를 살펴보세요. 모바일에서 가져오기 전에는 클립보드 내용이 완전한지 확인해야 합니다. 긴 링크가 메신저에서 잘리면 끝의 별칭은 남아 있어도 중간 쿼리 파라미터가 사라질 수 있습니다.

가져온 뒤 확인할 네 가지 항목

필드 확인: 노드 상세 정보의 서버, 포트, 전송 방식이 원본 내용과 일치합니다.
코어 확인: 선택한 코어가 링크에 선언된 프로토콜과 전송 확장을 지원합니다.
로그 확인: 실행 후 포트 점유, DNS 해석, TLS 핸드셰이크 오류가 발생하지 않습니다.
그룹 확인: 수동 노드와 구독 노드를 분리해 저장하여 다음 업데이트에서 보존해야 할 설정이 덮어써지지 않도록 합니다.

변환의 한계와 유지 관리 권장사항

구독 변환의 목표는 겉보기만 비슷한 링크를 만드는 것이 아니라 연결 파라미터를 일치시키는 것입니다. 도구가 인식하지 못하는 필드는 원본 데이터를 보존하고 명확히 알리는 편이 삭제한 뒤 계속 출력하는 것보다 안전합니다. 특히 전송 계층 확장과 보안 파라미터는 누락되어도 문법상 올바른 링크가 생성될 수 있지만 연결 결과는 달라집니다.

구독 주소는 보통 업데이트 진입점 역할을 합니다. 한 번 가져온 노드를 정적 공유 링크로 내보내면 이후 서버, 포트, 사용자 정보가 변경되어도 자동으로 반영되지 않습니다. 장기간 사용할 때는 원래 구독 그룹을 보존하고, 정적 링크는 임시 이전이나 파라미터 분석용으로 활용하는 편이 좋습니다.

네이티브 JSON은 검증된 라우팅 및 인바운드 설정을 보존하는 데 적합합니다. 수정하기 전에 현재 로컬 리슨 포트, 시스템 프록시 상태, 코어 유형, 설정 파일 출처를 기록하세요. 문제가 발생하면 먼저 이러한 기본 항목을 복원한 뒤 노드 필드를 확인하면 시스템 프록시 문제를 구독 형식 문제로 잘못 판단하는 일을 줄일 수 있습니다.

목표	권장 입력	권장 출력	반드시 확인할 항목
여러 노드 정기 업데이트	구독 주소	클라이언트 구독 그룹	업데이트 상태, 그룹 소속, 프로토콜 지원 여부
노드 하나 이전	단일 공유 링크	새 노드	TLS, SNI, 경로, 별칭
세밀한 라우팅 관리	네이티브 JSON	독립 코어 설정	인바운드 포트, DNS, 라우팅 태그
구독 내용 분석	원본 응답	디코딩한 읽기 전용 사본	한 계층만 디코딩하고 연결 정보를 공개하지 않기

가장 안전한 작업 방식은 자료를 세 가지로 나누어 보관하는 것입니다. 수정하지 않은 구독 응답, 정규화한 노드 필드, 최종 가져오기 파일을 각각 보존하면 연결 이상이 어느 변환 단계에서 발생했는지 추적할 수 있습니다. 일반 사용자는 클라이언트가 구독을 직접 관리하도록 하는 것이 우선이며, 이전·디버깅·사용자 지정 라우팅 구성 때만 인코딩과 JSON 매핑을 수동으로 처리하면 됩니다.