Clash 구독 링크 형식 정리: Base64·YAML 및 클라이언트별 구독 형식 변환 방법

구독 링크란 무엇인가: 주기적으로 가져오는 원격 목록

구독 링크는 일반적인 HTTPS 주소입니다. 클라이언트는 일정한 간격으로 이 주소에 GET 요청을 보내고, 서버는 텍스트를 반환하며 클라이언트는 이를 파싱해 로컬 노드 목록을 갱신합니다. RSS 리더가 피드를 가져오는 방식과 본질적으로 다르지 않습니다. 주소는 통로일 뿐이고, 실제로 사용 가능 여부를 결정하는 것은 반환되는 내용의 형식입니다.

먼저 확실히 알아둘 세 가지 기본 사실이 있습니다:

구독 링크는 프로토콜이 아닙니다. 트래픽 경로를 결정하지 않으며, 주기적으로 갱신되는 노드 목록을 받아오는 주소일 뿐입니다.
링크 속 토큰은 계정 자격 증명과 같습니다. 일반적인 구독 주소는 https://example.com/api/v1/client/subscribe?token=xxxxxxxx 형태이며, 이 문자열이 곧 신원 확인용 키입니다. 이 값이 유출되면 누구나 해당 요금제의 트래픽을 사용할 수 있으므로, 유출이 의심되면 가장 먼저 서비스 제공업체 관리자 페이지에서 구독 링크를 재발급해야 합니다.
같은 주소에서도 여러 형식이 반환될 수 있습니다. 서버는 요청 헤더의 User-Agent나 URL 파라미터로 클라이언트 종류를 판단해 Base64 목록 또는 Clash YAML을 각각 반환합니다. 하나의 링크로 여러 클라이언트를 지원하는 방식이 이렇게 구현됩니다.

Base64 구독: 줄 단위로 나열된 노드 공유 링크

Base64 구독은 V2Ray 생태계에서 만들어진 범용 교환 형식입니다. 서버는 하나의 긴 Base64 텍스트를 반환하며, 이를 디코딩하면 각 줄이 하나의 노드 공유 링크가 됩니다. 형태는 다음과 같습니다:

ss://[email protected]:8388#HK-01
vmess://eyJ2IjoiMiIsInBzIjoiSEstMDIifQ==
trojan://p%[email protected]:443?sni=cdn.example.com#HK-03

각 줄에는 연결에 필요한 전체 정보, 즉 프로토콜 접두사, 주소, 포트, 인증 정보, 전송 계층 및 TLS 파라미터, 그리고 # 뒤에 붙는 표시 이름이 모두 포함됩니다. 자주 쓰이는 접두사의 의미는 다음과 같습니다:

ss:// —— Shadowsocks, SIP002 규격을 따르며 @ 앞부분은 method:password를 Base64로 인코딩한 값입니다.
vmess:// —— VMess, 전체가 하나의 JSON 객체를 Base64로 인코딩한 값입니다.
vless:// —— VLESS, 파라미터는 query 문자열로 전달됩니다.
trojan:// —— Trojan, 비밀번호는 userinfo 부분에 들어갑니다.
hysteria2://(또는 hy2://), tuic:// —— QUIC 기반 프로토콜로, mihomo 등 신형 코어에서만 지원됩니다.

이 형식은 클라이언트 간 호환성이 높고 노드별로 독립적이어서 링크 하나만 따로 공유할 수 있다는 장점이 있습니다. 다만 정책 그룹이나 분기 규칙이 포함되지 않아, 가져온 뒤 규칙은 클라이언트가 자체적으로 채워야 합니다. 또 하나 흔한 실수는 ssr://(ShadowsocksR)가 Clash와 mihomo에서 지원되지 않는다는 점입니다. SSR 노드가 섞인 구독을 가져오면 해당 노드는 그대로 무시되므로, 노드 수가 맞지 않을 때 가장 먼저 확인해볼 부분입니다.

Clash YAML: 노드·정책 그룹·규칙이 하나로 결합된 형식

Clash 고유의 구독 형식은 완전한 YAML 설정 파일이며, 최소한 다음 세 가지 최상위 필드를 포함합니다:

mixed-port: 7890
allow-lan: false
mode: rule
proxies:
  - name: "HK-01"
    type: ss
    server: 203.0.113.10
    port: 8388
    cipher: aes-256-gcm
    password: "password"
proxy-groups:
  - name: "자동 선택"
    type: url-test
    proxies: ["HK-01"]
    url: http://www.gstatic.com/generate_204
    interval: 300
rules:
  - GEOIP,CN,DIRECT
  - MATCH,자동 선택

proxies: 노드 목록. 각 필드는 Base64 공유 링크와 대응되며, YAML 방식으로 작성된다는 점만 다릅니다.
proxy-groups: 정책 그룹. 대표적으로 수동 선택인 select, 자동 속도 측정인 url-test, 부하 분산인 load-balance, 장애 조치인 fallback이 있습니다.
rules: 분기 규칙. 도메인, IP 범위, GEOIP 등의 조건에 따라 트래픽을 직접 연결·프록시·차단으로 분배합니다.

YAML 구독을 받으면 노드, 그룹, 규칙이 모두 갖춰진 즉시 사용 가능한 완전한 설정을 얻게 됩니다. 다만 형식이 Clash 계열에 종속되어 다른 생태계의 클라이언트에서는 읽을 수 없다는 점이 단점입니다. 코어 간 차이도 주의해야 합니다. mihomo(Clash Meta)는 vless, hysteria2, tuic, wireguard 등의 노드 유형을 지원하지만, 개발이 중단된 예전 Clash 코어는 인식하지 못하는 유형을 만나면 파싱에 실패하거나 해당 노드를 그대로 건너뜁니다.

클라이언트별로 바로 가져올 수 있는 구독 형식 비교

아래 표는 본 사이트에서 소개하는 클라이언트가 코어별로 바로 가져올 수 있는 구독 형식을 정리한 것입니다:

클라이언트	코어	바로 가져올 수 있는 구독 형식
Clash Verge Rev	mihomo	Clash YAML, Base64 공유 링크
Clash Plus	mihomo	Clash YAML, Base64 공유 링크
FlClash	mihomo	Clash YAML, Base64 공유 링크
ClashX Meta	mihomo	Clash YAML, Base64 공유 링크
Clash for Android	Clash(개발 중단)	Clash YAML
Clash for Windows	Clash Premium(개발 중단)	Clash YAML
Surfboard	Surge 호환	Surge 형식 설정

규칙은 간단합니다. mihomo 코어 클라이언트는 두 형식을 모두 처리할 수 있습니다. Base64 구독을 가져올 때 클라이언트가 로컬에서 각 공유 링크를 proxies 항목으로 파싱한 뒤, 기본 정책 그룹과 규칙을 자동으로 덧씌워 줍니다. 반면 예전 Clash 코어는 YAML만 인식하며, Surfboard는 Surge 설정 체계를 사용하므로 Clash 구독은 먼저 변환을 거쳐야 합니다. 따라서 구독이 Base64 형식만 제공한다면, mihomo 코어 클라이언트를 선택하는 것이 변환 과정을 아예 건너뛸 수 있는 방법입니다.

형식을 서로 변환하는 세 가지 방법

방법 1: 구독 변환기(온라인 또는 직접 구축)

구독 변환기는 중간 서비스입니다. 원본 구독 주소를 변환기에 넘기면 변환기가 노드 목록을 가져와 지정한 형식으로 재구성한 뒤 돌려줍니다. 변환된 주소는 대체로 다음과 같은 형태입니다:

https://sub.example.com/sub?target=clash&url=원본구독주소의URL인코딩값&config=규칙템플릿

target 파라미터는 출력 형식(clash, surge, quanx 등)을 결정하고, config 파라미터는 추가로 적용할 규칙 템플릿을 지정합니다. 변환기는 형식 불일치 문제와 Base64 구독에 규칙이 없다는 문제를 동시에 해결해 줍니다.

공개 변환 서비스 사용 시 자격 증명 유출 위험

구독 주소를 제3자 변환기에 입력하는 것은 토큰을 그대로 상대 서버에 넘기는 것과 같으며, 상대방은 전체 노드 목록과 사용량을 확인할 수 있게 됩니다. 민감한 요금제라면 변환 백엔드를 직접 구축하거나(오픈소스 subconverter를 자체 배포 가능), 직접 가져오기를 지원하는 mihomo 클라이언트를 사용해 중간 단계를 건너뛰는 것을 권장합니다.

방법 2: 클라이언트 내장 파싱 기능 사용

Clash Verge Rev, Clash Plus, FlClash 등 mihomo 계열 클라이언트는 새 구독을 추가할 때 Base64 구독 주소를 그대로 붙여넣기만 하면, 코어가 콘텐츠 유형을 자동으로 판별해 변환까지 처리합니다. 별도 도구가 전혀 필요 없는 가장 간단한 방법이며, 초보 사용자에게 권장되는 방식입니다.

방법 3: 수동 디코딩 및 편집

문제를 진단하거나 특정 노드만 필요할 때는 직접 처리할 수도 있습니다. Base64 구독 디코딩은 명령어 한 줄로 끝납니다:

curl -s "구독주소" | base64 -d

디코딩한 뒤 줄 단위로 노드 링크를 확인하며 프로토콜 접두사가 코어의 지원 목록에 있는지 점검하면 됩니다. YAML로 변환해야 한다면 앞서 설명한 proxies 필드 형식에 맞춰 항목을 하나씩 옮겨 적으면 되고, 노드 수가 적을 때는 오히려 변환기를 구축하는 것보다 수동 방식이 더 빠릅니다.

가져오기 실패 시 점검 순서

구독 가져오기에서 오류가 나거나 노드가 비어 있을 때는 아래 순서대로 확인하면 됩니다. 발생 빈도가 높은 순서입니다:

먼저 브라우저로 구독 주소를 직접 열어봅니다. 텍스트가 정상적으로 반환되면 링크는 유효합니다. 401/403이 뜨면 토큰이 만료된 것이고, 404가 뜨면 경로가 변경된 것이므로, 두 경우 모두 서비스 제공업체 관리자 페이지에서 다시 발급받아야 합니다.
반환된 내용의 형식을 확인합니다. 브라우저에서 공백 없이 이어진 긴 암호문처럼 보이면 Base64이고, proxies, rules 같은 필드가 보이면 YAML입니다. 형식이 클라이언트와 맞지 않으면 변환 과정이 필요합니다.
노드 프로토콜이 코어에서 지원되는지 확인합니다. ssr://가 포함된 구독은 Clash 계열에서 해당 노드가 제외되며, hysteria2나 tuic이 포함된 구독은 mihomo 코어에서만 인식됩니다.
로컬 네트워크 상태를 확인합니다. 구독 주소 자체가 접속이 차단되는 환경이라면 먼저 사용 가능한 프록시가 있어야 목록을 가져올 수 있습니다. 클라이언트의 '시스템 프록시로 구독 업데이트' 같은 옵션을 켜거나, 급한 경우 노드를 하나 수동으로 추가해 우회할 수 있습니다.
YAML 문법을 확인합니다. 직접 수정한 설정 파일에서는 들여쓰기 오류, 전각 콜론, 이스케이프하지 않은 특수문자가 흔히 발생하며, 클라이언트 로그에 보통 오류가 발생한 줄 번호가 표시됩니다.

구독 링크 보안과 일상적인 관리

구독 주소는 비밀번호와 동일하게 취급해야 합니다. 단체 채팅방에 공유하거나 캡처해서 유포하지 말고, 출처가 불분명한 온라인 변환 사이트에도 입력하지 마세요.
유출됐다면 즉시 재발급하세요. 서비스 제공업체 관리자 페이지에는 보통 '구독 링크 재발급' 버튼이 있으며, 재발급하면 기존 주소는 즉시 무효화되므로 각 클라이언트에 등록된 구독 주소도 함께 갱신해야 합니다.
갱신 간격은 지나치게 짧게 설정할 필요가 없습니다. 노드 목록이 자주 바뀌지 않으므로 클라이언트 기본값인 24시간이나 12시간이면 충분합니다. 너무 자주 요청하면 서버 부담만 늘어나고, 일부 서비스 제공업체는 요청 빈도를 제한하기도 합니다.
여러 클라이언트에서 같은 구독을 함께 쓸 때는 형식에 주의하세요. mihomo 클라이언트와 예전 코어 클라이언트를 함께 사용하는 경우, 서버가 Clash YAML을 출력할 수 있어야 한다는 전제가 필요합니다. 그렇지 않다면 예전 코어를 쓰는 기기는 별도의 변환 주소를 사용해야 합니다.

판단 흐름을 정리하면 다음과 같습니다. 구독 주소를 받으면 먼저 반환 형식을 확인하고, Base64라면 mihomo 클라이언트로 바로 가져오거나 변환기를 사용하며, Clash YAML이라면 모든 Clash 계열 클라이언트에서 바로 쓸 수 있고, Surge 계열 클라이언트라면 별도로 변환해야 합니다. 형식 문제가 해결되면 남은 것은 일반적인 분기 규칙과 정책 그룹 설정이며, 이 부분은 본 사이트의 설정 가이드를 참고해 하나씩 진행하면 됩니다.