Clash 구독 형식 가이드: base64·YAML·범용 형식 차이와 변환 방법

인코딩, 링크, 설정 파일부터 구분하기

“Clash 구독”은 하나의 형식만을 뜻하지 않습니다. 서버가 반환하는 내용은 전체 Clash YAML일 수도 있고, 여러 공유 링크를 줄바꿈으로 나열한 텍스트일 수도 있으며, 여기에 base64 인코딩이 한 겹 더 적용될 수도 있습니다. 모두 URL 하나로 가져올 수 있어 보이지만, 클라이언트가 응답을 받은 뒤 거치는 파싱 과정은 서로 다릅니다.

가장 혼동하기 쉬운 것은 base64입니다. base64는 바이트를 출력 가능한 문자로 바꾸는 인코딩 방식일 뿐, 노드 필드나 클라이언트의 프로토콜 지원 범위를 정의하지 않습니다. 여러 ss://·trojan://·vmess:// 링크를 한 줄씩 배치한 뒤 전체 텍스트를 base64로 인코딩하면 일반적으로 “base64 구독”이라고 부릅니다. 디코딩한 뒤 실제 의미를 갖는 것은 각 공유 링크입니다.

Clash YAML은 계층 구조를 가진 설정 파일입니다. 노드뿐 아니라 프록시 그룹, 라우팅 규칙, DNS, 수신 포트, 규칙 집합, TUN 매개변수까지 담을 수 있습니다. 범용 구독은 보통 노드 전달만 담당하고, 그룹 구성과 트래픽 분배는 클라이언트 템플릿이나 변환기가 보완합니다.

형식	일반적인 시작 부분 또는 구조	표현할 수 있는 내용	주요 용도
Clash YAML	proxies:、proxy-groups:	노드, 프록시 그룹, 규칙, DNS, TUN 등	Clash 또는 mihomo 설정으로 직접 사용
평문 공유 링크	ss://、trojan://	단일 노드의 연결 매개변수	클라이언트 간 노드 복사
base64 구독	연속된 문자, 숫자 및 인코딩 기호	대개 인코딩된 여러 공유 링크	구독 주소 하나로 노드 묶음 배포
제공업체 전용 JSON	{ 또는 클라이언트 정의 필드	서버와 대상 애플리케이션에 따라 다름	특정 클라이언트 또는 API 연동

Clash YAML은 왜 단순한 노드 목록이 아닐까

직접 실행할 수 있는 Clash YAML은 보통 최소한 proxies·proxy-groups·rules 세 부분으로 구성됩니다. 첫 번째는 노드 매개변수를 저장하고, 두 번째는 수동 선택·자동 속도 측정·장애 조치 등의 전략을 정의하며, 마지막은 연결을 어느 프록시 그룹으로 보낼지 결정합니다.

mixed-port: 7890
allow-lan: false
mode: rule

proxies:
  - name: HK-Trojan-01
    type: trojan
    server: edge.example.net
    port: 443
    password: example-password
    sni: cdn.example.net

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - HK-Trojan-01
      - DIRECT

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

이 설정은 혼합 프록시 포트를 7890으로 지정하고 PROXY라는 수동 선택 그룹을 만듭니다. 실제 구독에는 rule-providers·proxy-providers·dns·sniffer·tun 및 영속 캐시 설정이 추가될 수 있습니다. 이러한 항목은 단일 공유 링크로 표현할 수 있는 범위를 넘어섭니다.

전체 설정과 프록시 제공자는 서로 다르다

mihomo 설정은 proxy-providers를 통해 원격 노드 묶음을 참조할 수 있습니다. 주 설정에는 DNS·규칙·프록시 그룹을 남기고, 원격 주소에서는 노드만 갱신하는 방식입니다. 이렇게 하면 “로컬 트래픽 분기 로직”과 “원격 노드 출처”를 분리해 관리할 수 있습니다.

proxy-providers:
  airport-a:
    type: http
    url: https://sub.example.net/token
    path: ./providers/airport-a.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

이때 원격 콘텐츠는 보통 provider YAML이며, 최상위에 proxies:만 있을 수도 있습니다. 즉, 커널을 독립적으로 실행할 수 있는 전체 설정이 아닙니다. provider 파일을 전체 Profile만 허용하는 클라이언트에 직접 가져오면 포트·프록시 그룹·규칙이 없어 설정 검증에 실패하는 경우가 많습니다.

YAML은 들여쓰기와 데이터 형식에 민감하다

• 들여쓰기에는 공백을 사용하고 Tab 문자를 섞지 마세요.
• 포트 443은 보통 숫자로 작성하고, 비밀번호·이름·서버 주소는 대개 문자열로 작성합니다.
• 이름에 콜론·해시 기호가 포함되거나 앞뒤에 공백이 있으면 따옴표로 감싸는 것이 좋습니다.
• true와 문자열 "true"는 의미가 다르므로 임의로 바꿔 쓸 수 없습니다.
• 같은 이름의 노드가 프록시 그룹에 들어가면 혼동이 생길 수 있으므로 변환 전에 이름을 중복 제거해야 합니다.

base64 구독과 범용 공유 링크 구성 방식

범용 구독의 원본은 보통 한 줄에 하나의 URI를 배치합니다. 각 프로토콜은 URI 안에 서버·포트·인증 정보·확장 매개변수를 표현하는 방식을 자체적으로 정합니다. 예를 들어 Shadowsocks는 ss://, Trojan은 trojan://, VMess는 흔히 vmess://, VLESS는 vless://를 사용합니다. mihomo는 더 많은 프로토콜을 지원하지만, 구버전 Clash 커널과 각 그래픽 클라이언트의 지원 범위는 서로 다릅니다.

ss://[email protected]:8388#SS-01
trojan://[email protected]:443?sni=cdn.example.net#Trojan-01
vless://[email protected]:443?type=ws&security=tls&host=cdn.example.net#VLESS-01

링크 끝의 프래그먼트는 보통 노드 이름으로 사용되고, 쿼리 매개변수에는 TLS·SNI·WebSocket 경로·Host·전송 방식·지문 설정 등이 저장될 수 있습니다. 구현마다 매개변수 이름과 기본값 처리 방식이 다릅니다. 한 클라이언트가 URI 접두사를 인식한다고 해서 모든 확장 필드를 완전히 해석한다는 뜻은 아닙니다.

base64 디코딩 후에도 두 번째 인코딩 계층이 있을 수 있다

전체 구독을 디코딩한 뒤에도 VMess 링크 내부에 base64로 인코딩된 JSON이 들어 있을 수 있으며, Shadowsocks 사용자 정보도 여러 URI 표현 방식을 사용합니다. 문제를 확인할 때는 계층별로 처리해야 합니다. 먼저 구독 본문을 디코딩하고, 다음으로 줄마다 프로토콜을 식별한 뒤, 해당 프로토콜 파서에 넘기세요. 전체 내용을 무작정 반복 디코딩하면 원본 링크가 손상될 수 있습니다.

1. 구독 응답을 가져오고 원본 텍스트 사본을 보관하세요.
2. 본문 시작 부분에 이미 proxies:·프로토콜 URI·JSON 구조가 나타나는지 확인하세요.
3. 내용이 실제로 base64 문자 특성에 부합할 때만 디코딩을 시도하세요.
4. 디코딩한 뒤 줄바꿈으로 나누고 빈 줄을 제거한 다음 각 줄의 프로토콜을 식별하세요.
5. 노드 수·이름·포트·TLS 매개변수가 온전히 유지되었는지 확인하세요.

클라이언트 호환성은 커널과 가져오기 경로에 달려 있다

같은 구독이 두 클라이언트에서 다르게 동작한다고 해서 보통 구독 주소가 만료된 것은 아닙니다. 커널의 프로토콜 지원, 클라이언트의 사전 처리 로직, 가져오기 경로가 서로 다르기 때문입니다. Clash for Windows 0.20.39는 유지보수가 중단되었으며 Profiles 페이지는 주로 Clash 설정을 대상으로 합니다. mihomo 기반 클라이언트는 더 다양한 프로토콜 필드를 해석하는 경우가 많지만, 그래픽 인터페이스에서 원본 범용 구독을 허용하는지는 각 클라이언트의 구독 모듈에 달려 있습니다.

전체 YAML 가져오기 경로

Clash for Windows 0.20.39를 예로 들면 일반적인 경로는 「Profiles」→ 상단에 구독 URL 입력 →「Download」입니다. 가져온 뒤에는 먼저 설정 카드가 나타나는지 확인하고, 「Proxies」로 이동해 프록시 그룹과 노드를 확인하세요. 노드만 보이고 예상한 규칙이 없다면 서버가 원본 전체 YAML이 아니라 클라이언트 템플릿으로 처리된 노드 묶음을 반환했을 수 있습니다.

mihomo 커널을 사용하는 2.x 그래픽 클라이언트에서는 보통 「구독」→「새로 만들기」→「URL」 순서로 가져옵니다. 메뉴 이름은 클라이언트마다 다르지만 확인 방법은 같습니다. 업데이트 로그에 HTTP 200이 반환되는지, 설정 검증을 통과하는지, 프록시 그룹 수가 예상과 일치하는지, 커널이 정상적으로 다시 로드되는지 확인하세요.

포트 번호는 구독 노드 자체에 포함되지 않는다

7890·7891·9090은 Clash 설정에서 자주 보이지만 역할은 서로 다릅니다. 7890은 HTTP와 SOCKS 혼합 수신 포트로 자주 사용되고, 7891은 일부 구형 설정에서 SOCKS용으로 사용되며, 9090은 외부 제어 인터페이스에 주로 사용됩니다. 범용 공유 링크는 원격 프록시 노드를 설명할 뿐, 로컬 클라이언트의 수신 포트를 정하지 않습니다.

따라서 범용 구독을 YAML로 변환할 때 변환기는 mixed-port·프록시 그룹·규칙을 추가로 주입하는 경우가 많습니다. 노드가 완전히 같더라도 템플릿이 다르면 두 변환 결과의 트래픽 분기 방식이 달라질 수 있습니다.

형식 변환에서 실제로 처리되는 작업

“구독 변환”은 보통 입력 식별, 노드 파싱, 필드 매핑, 출력 템플릿 적용의 네 단계로 이루어집니다. 입력은 전체 YAML·provider YAML·base64 링크 묶음·평문 URI일 수 있고, 출력은 Clash YAML·mihomo YAML 또는 다른 클라이언트가 읽을 수 있는 구독 텍스트일 수 있습니다.

범용 구독을 Clash YAML로 변환

가장 흔한 변환 경로입니다. 변환기는 각 공유 링크를 파싱해 proxies 항목으로 만들고, 템플릿에 따라 프록시 그룹과 규칙을 생성합니다. 최소한 다음 필드는 확인해야 합니다.

• 프로토콜 유형, 서버 주소, 포트 및 인증 정보
• TLS가 활성화되었는지, SNI 또는 servername이 유지되었는지
• WebSocket·gRPC 등의 전송 방식과 경로 매개변수
• UDP 활성화 여부, 인증서 검증 생략 설정 및 클라이언트 지문 매개변수
• 노드 이름 인코딩이 정상인지, 이름이 중복될 때 접미사가 자동으로 붙는지
• 생성 대상이 구형 Clash 문법인지 mihomo 확장 문법인지

Clash YAML을 범용 구독으로 변환

역변환에서는 설정 계층 정보가 반드시 손실됩니다. 공유 링크에는 노드 연결 매개변수를 담을 수 있지만 proxy-groups·rules·rule-providers·DNS·TUN·스니핑·수신 포트는 담을 수 없습니다. 다른 클라이언트에 다시 가져온 뒤 노드 수가 같다고 해서 두 설정이 동등하다고 판단할 수는 없습니다.

전체 YAML을 provider YAML로 변환

이 단계에서는 보통 proxies만 추출해 proxy-providers에서 참조할 파일을 만듭니다. 원래 설정의 트래픽 분기 규칙과 프록시 그룹은 주 설정에 자동으로 들어가지 않습니다. 주 설정에서 use:를 통해 provider를 지정된 프록시 그룹에 넣어야 하며, 그렇지 않으면 노드를 다운로드했어도 화면에서 선택 항목이 보이지 않을 수 있습니다.

proxy-groups:
  - name: AUTO
    type: url-test
    use:
      - airport-a
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

필드 누락이 자주 발생하는 여섯 가지 지점

1. 프로토콜 확장 필드에 대응하는 대상 필드가 없는 경우

원본 형식에는 클라이언트 지문·Reality 공개 키·짧은 ID·ECH·혼잡 제어·특정 전송 매개변수가 포함될 수 있지만, 대상 형식에는 동등한 필드가 없을 수 있습니다. 변환기가 이를 무시하거나 대상 클라이언트가 인식하지 못하는 확장 키로 기록할 수도 있습니다. 대개 즉시 오류가 발생하지 않고 노드는 표시되지만 연결이 시간 초과됩니다.

2. 규칙과 프록시 그룹이 템플릿으로 덮어써지는 경우

전체 YAML을 변환할 때 도구가 먼저 노드를 추출한 다음 템플릿을 적용하면 기존의 DIRECT·REJECT·장애 조치 그룹과 규칙 순서가 바뀔 수 있습니다. Clash 규칙은 위에서 아래로 매칭되므로 순서 자체가 결과를 바꿉니다. 예를 들어 특정 도메인 프록시 규칙보다 GEOIP,CN,DIRECT를 앞에 두면 대상 연결이 먼저 직접 연결될 수 있습니다.

3. 노드 이름이 필터링에 사용되는 경우

많은 템플릿은 정규식으로 이름을 검색해 “홍콩”·“일본”·“저배율” 같은 프록시 그룹을 만듭니다. 변환 후 이름의 국기 이모지·공백·지역 약칭이 달라지면 필터 결과가 노드 30개에서 0개로 줄어들 수 있습니다. 마이그레이션 전후에는 전체 구독 수뿐 아니라 각 프록시 그룹의 실제 구성원도 비교해야 합니다.

4. 불리언 값과 기본값이 달라지는 경우

원본 링크에 특정 매개변수가 없으면 두 클라이언트가 서로 다른 기본값을 사용할 수 있습니다. UDP·TLS 검증·SNI 추론·전송 Host는 기본 동작에 좌우될 수 있습니다. 변환기가 값을 명시적으로 기록하면 오히려 원래 클라이언트와 연결 동작이 달라질 수 있습니다.

5. DNS와 TUN은 기존 설정에 그대로 남는 경우

노드 마이그레이션이 완료되었다고 해서 시스템 프록시 경로까지 옮겨진 것은 아닙니다. Fake-IP 주소 풀·DNS 업스트림·도메인 스니핑·라우팅 제외 항목·TUN 자동 라우팅은 모두 로컬 설정입니다. 범용 구독에는 이러한 필드가 포함되지 않습니다. 클라이언트를 바꾼 뒤에는 「설정」→「시스템 프록시」, 「설정」→「TUN 모드」 및 DNS 설정을 다시 확인하고, 이전 클라이언트의 상태를 그대로 믿지 마세요.

6. 구독 업데이트 방식이 다른 경우

전체 YAML은 고정 노드를 직접 포함할 수 있지만 provider에는 별도의 interval과 캐시 경로가 있습니다. 그래픽 클라이언트가 자체 업데이트 시간을 관리할 수도 있습니다. 예시의 interval: 3600은 3600초마다 한 번 요청한다는 뜻이고, 상태 확인의 interval: 600은 600초마다 한 번 테스트한다는 뜻이므로 서로 다른 작업입니다.

검증 가능한 마이그레이션 절차

형식 변환은 “한 번에 가져온 뒤 바로 트래픽을 전부 넘기는” 방식보다 기존 설정을 보존하고 단계별로 대조하는 것이 안전합니다. 다음 절차는 범용 구독을 mihomo YAML로 옮길 때뿐 아니라 두 Clash 그래픽 클라이언트 사이에서 설정을 이전할 때도 적용할 수 있습니다.

1. 기준 상태를 기록합니다. 기존 클라이언트의 전체 노드 수, 자주 사용하는 프록시 그룹, 시스템 프록시 포트, DNS 모드, TUN 상태를 적어 둡니다.
2. 입력을 판별합니다. 반환된 콘텐츠가 전체 YAML인지, provider YAML인지, 평문 URI인지, base64 텍스트인지 확인합니다.
3. 대상을 선택합니다. 대상 커널이 구형 Clash인지 mihomo인지 명확히 정해 대상 커널이 지원하지 않는 필드 생성을 피합니다.
4. 먼저 노드만 변환합니다. 서버·포트·프로토콜·TLS·SNI·전송 계층·이름을 대조하고, 규칙을 바로 덮어쓰지는 않습니다.
5. 그다음 템플릿을 적용합니다. 프록시 그룹·규칙·DNS·수신 포트를 추가하고 참조 이름이 일치하는지 확인합니다.
6. 설정을 검증합니다. 클라이언트를 다시 로드하기 전에 파싱 오류를 확인하고 YAML 들여쓰기·중복 키·존재하지 않는 프록시 그룹을 중점적으로 살핍니다.
7. 소규모 트래픽으로 검증합니다. 먼저 TUN을 끄고 시스템 프록시만 활성화합니다. 브라우저 경로를 확인한 다음 DNS와 TUN을 테스트합니다.
8. 실제 동작을 비교합니다. 직접 연결 도메인·프록시 도메인·차단 도메인·UDP 환경을 각각 테스트해 규칙 매칭이 예상대로인지 확인합니다.

변환 후 노드는 정상적으로 표시되지만 모두 시간 초과된다면 노드 하나를 추출해 원본 링크와 대조하고 포트·SNI·TLS·전송 경로를 확인하세요. 일부 웹사이트만 문제가 생기면 규칙 순서와 DNS를 우선 살펴보세요. 시스템 애플리케이션이 프록시를 사용하지 않는다면 구독 형식을 계속 수정하기보다 시스템 프록시 또는 TUN을 확인해야 합니다.

사용 목적에 따라 형식을 바로 선택하기

• 트래픽 분기를 그대로 재현해야 한다면: 대상 커널과 호환되는 전체 YAML을 우선 사용하고 규칙·프록시 그룹·DNS를 유지합니다.
• 클라이언트 간 노드만 옮기려면: 범용 공유 링크 또는 base64 구독을 사용하고, 정책 구성은 대상 클라이언트에 맡깁니다.
• 로컬 규칙을 장기간 관리하려면: 주 설정은 고정하고 노드는 proxy-providers를 통해 원격으로 업데이트합니다.
• mihomo 확장 프로토콜과 호환해야 한다면: 변환 대상을 mihomo로 명확히 선택하고 구형 Clash 필드 집합으로 되돌아가지 않도록 합니다.
• 출처 형식이 확실하지 않다면: 먼저 응답 본문을 확인한 뒤 디코딩 또는 변환 여부를 결정하고 여러 변환기를 연속으로 적용하지 마세요.

결국 base64는 텍스트 전송을 위한 것이고, 공유 링크는 단일 노드를 설명하며, Clash YAML은 전체 프록시 동작을 관리합니다. 변환으로 필드를 옮길 수는 있지만 대상 형식이 표현할 수 없는 정보까지 되살릴 수는 없습니다. 마이그레이션 전에 이 세 계층을 구분하면 노드는 “가져오기에 성공했지만 사용할 수 없는” 상태가 되고, 규칙이 사라지거나 DNS 동작이 갑자기 바뀌는 문제를 크게 줄일 수 있습니다.

클라이언트 설치 및 구독 확인

사용 중인 플랫폼을 먼저 선택한 다음 안내에 따라 구독을 가져오고, 프록시 그룹·시스템 프록시·DNS를 확인하세요.

다운로드 페이지로 설치 가이드 보기