Clash 구독 형식 완전 정리: YAML 설정, Base64 링크, 형식 변환 방법

구독 형식이 왜 서로 다른가

Clash는 원래 한 가지 형식만 인식했습니다: 노드 정보(proxies), 정책 그룹(proxy-groups), 분기 규칙(rules)을 모두 담은 완전한 YAML 설정 파일입니다. 이 파일은 노드 목록이자 동작 설명서이며, 클라이언트가 다운로드하면 바로 로드해서 실행할 수 있습니다.

하지만 노드 제공자가 항상 완전한 규칙 세트를 관리하고 싶어하는 것은 아닙니다. 대부분의 구독 서비스 제공자는 노드 자체만 배포하고, 규칙 구성은 사용자나 클라이언트 자체 프리셋에 맡기는 쪽을 선호합니다. 여기서 더 가벼운 두 가지 형식이 파생됩니다: Base64로 인코딩된 노드 목록과 공유 링크 모음입니다. 세 형식은 각각 다른 상황에 맞춰져 있어 절대적으로 "더 나은" 것은 없지만, 혼용하면 필드 손실이나 클라이언트가 인식하지 못하는 문제가 쉽게 발생합니다.

완전한 YAML 설정: 필드 구조와 적용 상황

YAML 형식의 구독은 본질적으로 바로 실행 가능한 config.yaml입니다. mihomo(Clash Meta 커널)는 기존 필드를 바탕으로 새로운 문법을 많이 확장했지만, 최상위 구조는 대체로 일치합니다:

mixed-port: 7890
mode: rule
log-level: info
dns:
  enable: true
  nameserver:
    - 223.5.5.5
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,google.com,자동 선택
  - GEOIP,CN,DIRECT
  - MATCH,자동 선택

이 형식의 장점은 "즉시 사용 가능"이라는 점입니다: 규칙, 정책 그룹, DNS 정책이 모두 구독 제공자 쪽에서 관리되므로 사용자는 가져오기만 하면 추가 설정이 필요 없습니다. 단점도 분명합니다 - 클라이언트가 여러 구독을 합치거나 기존 규칙에 자체 분기를 추가하려면 처리가 좀 더 번거로워집니다. 단순한 이어붙이기가 아니라 필드 단위 병합이 필요하기 때문입니다.

또한 mihomo 커널에서 추가된 필드(예: smart 정책 그룹 타입, sniffer 도메인 스니핑 설정)는 오리지널 Clash 커널에서는 그냥 무시되거나 오류가 발생할 수 있으니, YAML 구독을 받기 전에 클라이언트가 어떤 커널을 쓰는지 먼저 확인하는 것이 좋습니다.

Base64 노드 목록과 공유 링크의 차이

구독 링크가 반환하는 내용이 읽을 수 있는 YAML이 아니라 규칙성이 없어 보이는 긴 문자열이라면, 대부분 Base64로 인코딩된 노드 목록입니다. 이런 구독은 한 줄이 한 노드에 대응하며, 형식은 보통 프로토콜://인코딩된 연결 파라미터이고, 흔히 쓰이는 프로토콜 접두사는 ss://, vmess://, trojan://, ssr:// 등이며 전체 구독은 이 줄들을 다시 한 번 통째로 Base64 인코딩합니다.

ss://[email protected]:443#hk-01
vmess://eyJ2IjoiMiIsInBzIjoic2ctMDIi...
trojan://[email protected]:443?sni=example.net#sg-02

이 형식은 "노드가 무엇인지"만 설명할 뿐, 분기 규칙이나 정책 그룹 정보를 포함하지 않습니다. 클라이언트의 구독 파서가 각 줄을 노드 객체로 복원하고, 클라이언트 로컬 또는 구독 변환 서비스가 제공하는 규칙 템플릿을 적용합니다. 장점은 범용성이 강해서 프록시 프로토콜을 지원하는 거의 모든 클라이언트(Clash에 한정되지 않음)에서 해석할 수 있다는 것입니다. 단점은 변환 도구 없이 이런 링크를 자동 변환을 지원하지 않는 Clash 클라이언트에 그냥 넣으면 대부분 아무것도 로드되지 않는다는 점입니다. Clash는 기본적으로 YAML만 인식하기 때문입니다.

이른바 "공유 링크 모음"은 사실 위의 Base64 노드 목록을 다르게 부르는 이름일 뿐이며, 프록시 서비스 제공자의 "구독 링크" 페이지에서 흔히 볼 수 있고 URL 단계에서는 순수 YAML 구독과 구분되지 않아 내용을 보고 판단해야 합니다.

클라이언트 이전: 변환 방법과 도구 선택

클라이언트나 기기를 바꿀 때 가장 흔한 요구는 Base64 노드 목록을 완전히 사용 가능한 YAML 설정으로 변환하거나, 반대로 YAML 안의 노드 정보를 추출해서 다른 소프트웨어에 쓰는 것입니다. 흔한 방법은 세 가지입니다:

1. 클라이언트 내장 변환: 대부분의 Clash 클라이언트(mihomo 커널을 지원하는 버전 포함)는 구독을 추가할 때 Base64 노드 목록을 자동으로 인식해서 내부적으로 YAML 구조로 변환하고 기본 규칙 템플릿을 적용합니다. 사용자가 직접 처리할 필요가 없어 가장 편한 방법입니다.
2. 구독 변환 서비스: 원본 구독 링크와 규칙 템플릿을 변환 서비스에 함께 제출하면 서버 쪽에서 노드를 가져와 규칙을 적용하고 완전한 YAML을 조립한 뒤 새 구독 주소를 돌려줍니다. 이 방법은 정책 그룹을 커스터마이즈하거나 여러 구독 소스를 합치고 싶은 상황에 적합합니다.
3. 로컬 스크립트 변환: 노드 수가 적고 규칙을 완전히 직접 관리하고 싶은 사용자는 Base64 내용을 직접 디코딩해서 복원한 노드 파라미터를 YAML의 proxies 필드에 하나씩 채우고 규칙과 정책 그룹도 직접 작성할 수 있습니다. 가장 번거롭지만 어떤 서드파티 서비스에도 의존하지 않습니다.

어떤 방식을 선택할지는 주로 구독 소스가 안정적인지, 규칙을 자주 조정해야 하는지에 달려 있습니다. 일시적으로 클라이언트를 바꿔 테스트하는 것뿐이라면 클라이언트 자체의 자동 인식 기능을 우선 사용하고, 여러 클라이언트에서 공통으로 쓸 구독을 장기적으로 관리할 계획이라면 구독 변환 서비스가 더 편합니다.

변환 시 흔한 필드 손실과 방지 방법

형식 변환에서 가장 문제가 생기기 쉬운 부분은 노드 자체가 연결이 안 되는 것이 아니라, "별로 중요하지 않아 보이는" 필드가 변환 도구에 의해 조용히 버려지는 경우입니다. 다음 필드들은 특히 변환 과정에서 사라지기 쉽습니다:

• TLS 관련 파라미터: 예를 들어 skip-cert-verify, sni, alpn 같은 필드는 일부 간소화된 변환 도구가 기본적으로 해석하지 않아, 원래 정상이던 노드가 변환 후 핸드셰이크에 실패하게 됩니다.
• 전송 계층 확장: VMess/Trojan 노드에 자주 따라붙는 ws-opts, grpc-opts 등의 전송 설정은 변환 도구가 가장 기본적인 프로토콜 템플릿으로만 해석할 경우 이 부분이 통째로 무시됩니다.
• 정책 그룹 참조 관계: 원본 구독의 규칙이 특정 커스텀 정책 그룹 이름을 참조하고 있는데 변환 후 노드 이름이나 그룹 이름이 바뀌면 규칙이 해당 그룹을 찾지 못해 전부 기본 정책으로 떨어지게 됩니다.
• DNS 및 TUN 관련 설정: 순수 노드 목록 자체에는 이런 필드가 없어서, 변환 서비스가 보완할 때 자체 기본 템플릿을 사용하게 되고 사용자가 원래 쓰던 DNS 정책과 다를 수 있으므로 변환 후 직접 확인이 필요합니다.

또한 구독 변환 서비스마다 프로토콜 지원 정도가 다르며, 특히 비교적 새로운 프로토콜이나 난독화 파라미터는 변환 후 생성된 YAML 파일을 열어서 노드 개수가 맞는지만 볼 게 아니라 몇 개 노드를 골라 필드가 완전한지 직접 확인해보는 것을 추천합니다.

세 가지 형식 비교 정리

전체적으로 보면, 구독 내용이 어떤 형식에 속하는지 파악한 뒤 그에 맞는 가져오기 또는 변환 방식을 선택하면 "구독을 가져왔는데 노드가 없다"거나 "규칙이 적용되지 않는다" 같은 문제 대부분을 미리 피할 수 있습니다. 형식 변환은 신비한 게 아니라, 핵심은 필드가 온전히 보존되었는지 확인하는 것입니다.