Clash 구독 형식 완전정리: YAML·Base64·범용 포맷 상호 변환 가이드

구독 링크 안에는 무엇이 들어 있을까

구독 링크는 결국 클라이언트가 주기적으로 요청하는 HTTP(S) 주소일 뿐이고, 실제 데이터는 서버가 반환하는 응답 본문에 담겨 있습니다. 제조사나 패널마다 생성하는 구독 내용의 형식이 제각각인데, 대표적으로 세 가지가 있습니다. Clash 전용 YAML 구조, Base64로 인코딩한 범용 노드 목록, 그리고 일부 클라이언트가 자체 정의한 JSON이나 순수 텍스트 형식입니다. 클라이언트는 구독을 받아온 뒤 먼저 응답 내용의 유형을 판별하고, 그에 맞는 파싱 규칙에 따라 노드 정보와 분기 규칙을 로컬 설정에 반영합니다. 이 과정에서 실패하면 흔히 말하는 '구독은 불러왔는데 작동하지 않는' 문제가 발생합니다.

형식을 판별할 때는 링크 뒤의 확장자만 봐서는 안 됩니다. 많은 구독 주소가 .yaml 같은 표시를 붙이지 않기 때문에, 실제로 판단 근거가 되는 것은 응답 헤더의 Content-Type과 응답 본문의 실제 내용입니다. 클라이언트 파서는 보통 먼저 YAML로 해석을 시도하고, 실패하면 Base64 디코딩을 시도하며, 둘 다 맞지 않을 때에야 형식 오류를 보고합니다. 같은 구독이라도 클라이언트마다 다르게 동작하는 이유가 바로 여기에 있는데, 파서의 시도 순서와 지원 범위가 완전히 일치하지 않기 때문입니다.

YAML 형식: Clash 네이티브 설정 구조

Clash와 Clash Meta(mihomo 코어)가 기본적으로 인식하는 설정은 YAML 텍스트로, 최상위에 보통 proxies(노드 목록), proxy-groups(정책 그룹), rules(분기 규칙) 같은 필드가 포함됩니다. 이 형식의 장점은 정보가 완결적이고 가독성이 높다는 점입니다. 정책 그룹의 분류 논리와 규칙의 매칭 순서가 텍스트에 그대로 드러나므로, 숙련된 사용자는 설정 파일을 직접 열어 원하는 부분만 수정할 수 있습니다.

proxies:
  - name: "hk-01"
    type: ss
    server: example.com
    port: 443
    cipher: aes-256-gcm
    password: "your-password"

proxy-groups:
  - name: "자동 선택"
    type: url-test
    proxies: ["hk-01"]
    url: "http://www.gstatic.com/generate_204"
    interval: 300

rules:
  - DOMAIN-SUFFIX,github.com,자동 선택
  - MATCH,DIRECT

주의할 점은 YAML이 들여쓰기와 콜론 뒤 공백에 매우 민감하다는 것입니다. 수동으로 편집할 때 공백 하나만 더 들어가거나 콜론 하나만 빠져도 전체 설정 파싱이 실패할 수 있습니다. 구독 제공처가 YAML 직결 링크를 제공한다면 보통 사용자가 직접 손댈 필요는 없으며, 클라이언트가 전체를 받아와 로컬 설정에 덮어쓰거나 병합합니다. 문법을 신경 써야 하는 경우는 직접 노드를 구축하거나 규칙을 수동으로 작성할 때뿐입니다.

Base64와 범용 구독 형식의 호환 원리

Base64 형식은 초기 클라이언트와 온라인 공유 환경에 맞추기 위해 널리 퍼진 방식입니다. 서버는 각 노드 정보를 프로토콜://파라미터 형태의 링크(예: ss://, vmess://, trojan://로 시작하는 링크)로 만든 뒤, 모든 링크를 줄바꿈으로 이어 붙이고 전체를 Base64로 인코딩해 줄바꿈 없는 하나의 문자열로 출력합니다. 클라이언트는 구독을 받아온 뒤 먼저 Base64를 디코딩해 한 줄에 하나씩 노드가 나열된 텍스트로 복원하고, 줄마다 프로토콜 종류와 파라미터를 파싱해 내부적으로 사용할 노드 목록을 만듭니다.

이 형식의 장점은 범용성이 뛰어나다는 점입니다. Clash 계열뿐 아니라 거의 모든 주요 클라이언트가 이 인코딩 규칙을 인식하므로, 같은 구독 하나를 여러 소프트웨어에 그대로 물려 쓸 수 있고, 패널이 여러 클라이언트를 동시에 지원해야 하는 상황에 적합합니다. 다만 한계도 명확합니다. Base64 범용 형식에는 정책 그룹이나 분기 규칙 같은 구조화된 정보가 포함되지 않으므로, 클라이언트는 노드 정보만 받아 자체 내장된 기본 그룹 논리로 처리할 수밖에 없고, 규칙의 세밀함은 YAML 네이티브 구독보다 태생적으로 떨어집니다. 일부 클라이언트는 범용 형식을 불러온 뒤 규칙 집합이 로컬에 미리 정해진 정적 템플릿이라, 구독을 갱신해도 노드만 바뀌고 분기 논리는 변하지 않습니다.

형식 변환이 필요한 경우

대부분의 경우 사용자가 직접 변환할 필요는 없습니다. 구독 링크를 클라이언트의 구독 관리 화면에 그대로 붙여넣으면 클라이언트가 자동으로 형식을 인식해 파싱을 완료합니다. 실제로 변환이 필요한 경우는 다음과 같은 상황에 집중됩니다.

• 패널이 범용 Base64 구독만 제공하지만 Clash에서 커스텀 분기 규칙과 다단계 정책 그룹을 쓰고 싶은 경우, 노드 정보를 YAML 구조로 변환하고 rules 필드를 별도로 채워야 합니다.
• 이미 흩어져 있는 프로토콜 링크(ss://, vmess:// 등)를 여러 개 갖고 있어, 클라이언트가 인식할 수 있는 구독 주소 하나로 합쳐 통합 관리와 자동 갱신을 편리하게 하고 싶은 경우.
• 다른 클라이언트에서 Clash 계열 클라이언트로 옮겨 왔는데 원본 구독이 전용 형식이라, 기존 그룹 구성 습관을 유지하려면 YAML로 변환해야 하는 경우.

변환의 기본 원리는 그리 복잡하지 않습니다. 먼저 원본 구독을 파싱해 구조화된 노드 파라미터(서버 주소, 포트, 암호화 방식, 비밀번호나 키 등)를 복원한 뒤, 목표 형식의 문법에 맞춰 다시 조립합니다. YAML을 목표로 할 경우 정책 그룹과 규칙도 추가로 생성해야 하는데, 이 부분은 보통 변환 스크립트가 미리 정해진 템플릿으로 채워 넣는 것이지 원본 구독에서 '추출'해 오는 게 아닙니다. 범용 형식 자체가 이런 정보를 담고 있지 않기 때문입니다.

자체 변환 서버 구축 시 주의점

능력과 필요가 있는 사용자는 오픈소스 구독 변환 서비스를 직접 배포해 Base64 범용 구독을 커스텀 규칙이 포함된 YAML 설정으로 바꾼 뒤, 새로운 구독 링크를 생성해 클라이언트가 받아가도록 할 수 있습니다. 자체 변환 서버를 구축할 때 눈여겨볼 점은 다음과 같습니다.

1. 규칙 템플릿은 주기적으로 관리해야 합니다. 변환 서비스가 생성하는 정책 그룹과 분기 규칙은 로컬 템플릿 파일에서 나오므로, 템플릿이 오래되면 새로 추가된 도메인 분류가 매칭되지 않을 수 있어 정기적으로 갱신해야 합니다.
2. 변환 과정의 접근 권한을 제한해야 합니다. 변환 서비스는 보통 원본 구독 내용을 그대로 다루므로, 외부에 공개된 주소로 배포한다면 접근 비밀번호를 걸거나 접근원을 제한해 구독 정보가 무관한 사람에게 노출되지 않도록 해야 합니다.
3. 출력 구독의 갱신 주기를 원본과 맞춰야 합니다. 변환 서비스는 보통 요청이 올 때마다, 또는 정해진 주기로 원본 구독을 다시 받아와 새 링크를 생성합니다. 정기 작업의 간격을 너무 길게 두면 클라이언트가 받는 노드 정보가 패널 쪽 실제 변경보다 늦어질 수 있습니다.
4. 프로토콜 필드 해석 범위를 폭넓게 커버해야 합니다. 프로토콜(Shadowsocks, VMess, Trojan, Hysteria 등)마다 파라미터 구조 차이가 커서, 변환 스크립트가 흔한 필드만 처리하면 플러그인 파라미터나 특수 전송 계층 설정이 포함된 노드에서 파싱 오류가 나기 쉽습니다.

일반 사용자라면 클라이언트가 이미 구독 형식을 정상적으로 인식하고 있는 상황에서 별도의 변환 단계를 굳이 넣을 필요는 없습니다. 변환은 패널 운영자나 특정 규칙이 필요한 숙련 사용자가 주로 활용하는 방법이며, 일상적으로는 클라이언트와 구독 형식이 애초에 호환되는지부터 확인한 뒤 변환이 정말 필요한지 판단하는 편이 좋습니다.