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

자주 쓰이는 세 가지 구독 형식의 본질적 차이

구독 링크를 브라우저에 열어보면 반환되는 내용의 형태가 모두 같지는 않습니다. 대부분의 문제 해결은 반환된 게 정확히 어떤 형식인지 구분하지 않고 클라이언트가 "당연히 인식할 것"이라고 가정하는 데서 시작됩니다. 현재 유통되는 구독 내용은 크게 세 가지로 나뉘며, 처리 방식이 완전히 다릅니다.

• Clash YAML 설정: 응답 본문 자체가 완전한 YAML 문서로, proxies, proxy-groups, rules 등의 필드를 포함하며, Clash / Clash Meta / mihomo 코어가 별도의 변환 절차 없이 바로 해석해 적용할 수 있습니다.
• Base64 노드 목록: 응답 본문이 하나의 긴 Base64 문자열이며, 디코딩하면 vmess://, ss://, trojan:// 등 프로토콜 접두사로 시작하는 노드 링크가 줄 단위로 나열됩니다. 이 형식은 V2Ray/V2RayN 생태계에서 흔하며, Clash 코어는 이 응답을 직접 인식할 수 없어 먼저 디코딩한 뒤 한 줄씩 proxies 항목으로 변환해야 합니다.
• 프로토콜 전용 공유 링크의 평문 모음: Base64로 감싸지 않고 노드 링크를 줄 단위로 그대로 나열해 반환하는 방식으로, 개인이 구축한 소규모 패널에서 흔히 볼 수 있습니다. 처리 방식은 Base64 목록과 비슷하지만 디코딩 단계만 생략됩니다.

판단 방법은 간단합니다. 브라우저나 curl로 구독 링크를 열어 반환된 내용의 첫 줄을 확인하세요. port:, mixed-port:, proxies: 같은 YAML 키-값 형태라면 Clash 네이티브 설정입니다. 줄바꿈 없이 영숫자와 등호로 끝나는 긴 문자열이라면 Base64일 가능성이 높습니다. 매 줄이 프로토콜 이름과 ://로 시작한다면 평문 노드 목록입니다.

Clash YAML 설정의 핵심 필드

Clash 코어가 바로 사용할 수 있는 구독의 기본 골격은 대략 다음과 같습니다.

port: 7890
socks-port: 7891
mode: rule
log-level: info

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

proxy-groups:
  - name: "auto"
    type: url-test
    proxies:
      - hk-01
    url: "http://www.gstatic.com/generate_204"
    interval: 300

rules:
  - DOMAIN-SUFFIX,google.com,auto
  - GEOIP,CN,DIRECT
  - MATCH,auto

이 중 proxies는 노드 자체의 연결 파라미터를 기술하고, proxy-groups는 노드를 정책 그룹(자동 속도 테스트, 수동 선택, 로드 밸런싱 등)으로 묶으며, rules는 트래픽을 어떤 조건으로 어느 정책 그룹에 배분할지 결정합니다. 세 부분이 모두 필요하며, 구독으로 받은 YAML에 proxies만 있고 나머지 두 부분이 없다면 대부분의 클라이언트가 자동으로 기본 정책 그룹과 규칙을 추가하지만, 구체적인 동작은 클라이언트마다 다르므로 가져온 뒤 설정 뷰어를 열어 확인하는 것이 좋습니다.

Clash Meta(mihomo) 코어를 사용하는 경우 proxies 안에 tfo, smux, reality-opts 같은 확장 필드가 나타날 수 있습니다. 이는 원본 Clash가 인식하지 못하는 새로운 프로토콜 파라미터로, 원본 코어에 가져오면 바로 오류가 나거나 해당 노드를 건너뛰게 되며, 이는 "코어를 교체해야 하는지"를 판단하는 직접적인 신호이기도 합니다.

Base64 노드 목록의 디코딩과 변환 원리

Base64 형식 구독은 본질적으로 "여러 공유 링크를 하나의 텍스트로 묶은 것"으로, 클라이언트가 한 번에 갱신을 가져올 수 있게 하는 방식일 뿐 암호화가 아니라 단순 인코딩입니다. 디코딩하면 일반적인 노드 링크는 대략 다음과 같은 구조입니다.

ss://[email protected]:443#hk-01
vmess://eyJ2IjoiMiIsInBzIjoiaGstMDIiLCJhZGQiOiJleGFtcGxlLmNvbSIsInBvcnQiOiI0NDMi...}
trojan://[email protected]:443?sni=example.com#hk-03

한 줄씩 변환하는 절차는 고정되어 있습니다.

1. 먼저 URL 파라미터로 프로토콜 종류(ss / vmess / trojan / hysteria2 등)를 구분합니다.
2. 사용자 정보 부분(보통 Base64로 인코딩되어 있으며, ss://의 사용자 정보 부분이 그 예)을 다시 디코딩해 암호화 방식과 비밀번호를 얻습니다.
3. 서버 주소, 포트, 전송 계층 파라미터(ws, grpc, TLS 관련 필드)를 Clash YAML의 proxies 항목에 대응하는 필드 이름으로 매핑합니다.
4. 노드 이름(# 뒤의 부분, 보통 URL 인코딩되어 있음)을 디코딩해 읽을 수 있는 이름으로 복원합니다.

단일 노드라면 수동으로 해도 문제없지만, 구독에는 보통 수십~수백 개의 노드가 들어 있어 하나씩 손으로 고치는 것은 현실적이지 않으며, 실제로는 거의 항상 구독 변환 서비스로 일괄 변환합니다. 다음 절에서 자세히 설명합니다.

구독 상호 변환의 두 가지 일반적인 방법

Base64/평문 구독을 Clash가 인식할 수 있는 YAML로 변환하는 방법은 크게 두 가지로 나뉘며, 각각 장단점이 있습니다.

방법 1: 클라이언트 내장 변환

일부 안드로이드 클라이언트는 "새 설정 만들기" 또는 "구독 가져오기" 단계에 형식 감지 로직을 내장하고 있습니다. 링크를 붙여넣으면 클라이언트가 먼저 Clash YAML로 해석을 시도하고, 실패하면 자동으로 Base64로 디코딩한 뒤 한 줄씩 변환해 로컬 설정을 생성합니다. 이 방법은 제3자 서비스에 의존하지 않고 데이터가 전 과정 로컬에서 처리되어 개인정보 측면에서 가장 안전한 방식이지만, 변환 능력이 클라이언트 자체의 프로토콜 필드 지원 정도에 좌우되어 비교적 새로운 전송 계층 파라미터(예: 일부 hysteria2 위장 파라미터)를 만나면 변환이 불완전하거나 해당 노드를 그냥 버릴 수 있습니다.

방법 2: 구독 변환 서비스 경유

다른 방식은 원본 구독 링크를 변환 서비스에 넘겨 서버 측에서 디코딩과 형식 재작성을 완료한 뒤, 생성된 Clash YAML 링크를 클라이언트에 구독시키는 것입니다. 이런 서비스는 보통 다음과 같은 커스텀 파라미터를 지원합니다.

• target: 대상 형식으로, clash 또는 clashr를 입력합니다.
• url: 원본 구독 주소로, 여러 구독을 |로 구분해 합쳐 처리할 수 있습니다.
• config: 원격 규칙 템플릿 주소로, 생성될 proxy-groups와 rules 구조를 결정하며, 입력하지 않으면 변환 서비스의 기본 템플릿을 사용합니다.
• emoji / udp / tfo: 불리언 파라미터로, 노드 이름 앞에 국기 이모지를 붙일지, UDP 포워딩과 TCP Fast Open 플래그를 강제로 켤지를 제어합니다.

이 방법의 장점은 변환 능력이 더 강력하고 템플릿을 재사용할 수 있어, 여러 구독 소스의 명명 규칙을 통일하거나 중복을 제거해야 하는 상황에 적합합니다. 대가는 원본 구독 링크(계정 신원 정보 포함)가 제3자 서버를 경유하게 되어 개인정보 노출 위험이 있다는 점입니다. 선택할 때는 해당 서비스가 로그 정책을 공개적으로 밝히고 있는지 확인해야 하며, 더 신중한 방법은 오픈소스 변환 서비스를 직접 구축해 중계 단계를 스스로 관리하는 것입니다.

변환 후 자주 발생하는 오류 상황과 점검 방법

구독 변환이 성공적으로 가져와졌다고 해서 노드가 반드시 정상적으로 연결된다는 뜻은 아닙니다. 실제 사용에서 다음 몇 가지 상황이 비교적 자주 나타납니다.

노드 수가 맞지 않음

변환 후 노드 수가 원본 구독보다 적다면, 보통 변환 서비스나 클라이언트가 특정 프로토콜 필드를 지원하지 않아 해당 노드 전체가 오류 없이 건너뛰어졌기 때문입니다. 확인 방법은 먼저 원본 Base64를 디코딩한 노드 총수를 보고, 생성된 YAML의 proxies 항목 수와 비교하는 것입니다. 실제로 줄었다면 빠진 노드의 프로토콜 종류가 비교적 드문 조합(예: 일부 실험적 전송 계층 조합)인지 확인하고, 변환 템플릿을 바꾸거나 해당 프로토콜을 지원하는 최신 코어 버전으로 업데이트하면 대부분 해결됩니다.

정책 그룹에 새 노드가 보이지 않음

원격 규칙 템플릿(config 파라미터로 지정한 템플릿)을 사용한 경우, 정책 그룹의 노드 필터 조건은 노드 이름의 키워드 매칭으로 고정되어 있습니다. 새 노드 이름이 템플릿의 키워드 규칙과 맞지 않으면(예: 템플릿이 "HK|SG|JP"로 시작하는 노드만 걸러내는 경우) 해당 정책 그룹에 자동으로 편입되지 않습니다. 이럴 때는 템플릿 안의 필터 정규식을 확인하거나, 차라리 원격 템플릿을 제거하고 변환 서비스가 기본으로 제공하는 "모든 노드를 하나의 자동 속도 테스트 그룹에 넣는" 정책을 사용하면 됩니다.

변환 후 TLS/SNI 파라미터 누락

일부 프로토콜(특히 Trojan과 VMess의 WebSocket+TLS 조합)은 SNI와 skip-cert-verify 필드에 비교적 민감합니다. 변환 서비스가 원본 링크의 sni나 allowInsecure 파라미터를 제대로 파싱하지 못하면 생성된 노드가 연결 타임아웃이나 핸드셰이크 실패를 겪게 됩니다. 이 경우 생성된 YAML을 수동으로 열어 원본 공유 링크의 파라미터와 대조하며 servername과 skip-cert-verify 필드를 보완하거나 수정하는 것이 좋습니다.

갱신 주기 설정 부적절로 인한 구독 만료

변환으로 생성된 구독 링크는 본질적으로 "실시간 프록시 요청"이어서, 클라이언트가 구독을 새로 고칠 때마다 변환 서비스가 원본 구독을 다시 가져와 다시 변환합니다. 원본 구독 자체에 갱신 빈도 제한(흔히 몇 시간에 한 번)이 걸려 있다면, 클라이언트가 너무 자주 새로 고치면 원본 패널이 비정상 요청으로 판단해 응답을 거부할 수 있고, 이는 변환 서비스가 빈 노드 목록을 반환하는 결과로 이어집니다. 클라이언트의 구독 갱신 간격은 6~12시간으로 설정하고, 수동으로 자주 새로고침 버튼을 누르지 않는 것이 좋습니다.

형식과 변환 방식을 고르는 실용적인 조언

• 서비스 제공자가 Clash 전용 구독 링크를 직접 제공한다면 이를 우선 사용하고, 모든 변환 단계를 건너뛰어 오류 가능성을 줄이세요.
• Base64/평문 구독밖에 없다면 먼저 클라이언트 내장 변환을 시도하고, 변환 실패나 노드 누락이 뚜렷할 때만 제3자 변환 서비스를 고려하세요.
• 제3자 변환 서비스를 사용할 때는 가능하면 오픈소스이며 직접 배포할 수 있는 프로젝트를 선택해, 원본 구독 인증 정보를 스스로 관리하는 서버에서 처리하세요.
• 변환이 끝나면 먼저 url-test 정책 그룹으로 전체 속도 테스트를 한 번 진행해 노드 수와 지연이 정상인지 확인한 뒤, 평소 사용하는 규칙 모드로 전환하세요.
• 규칙 템플릿과 노드 명명 규칙은 가능한 한 안정적으로 유지해, 서비스 제공자가 노드 이름 형식을 바꾸면서 정책 그룹 매칭이 깨지는 상황을 줄이세요.

구독 형식 변환은 사소한 형식 변환 문제처럼 보이지만, 그 뒤에는 노드 정보가 여러 당사자 사이를 오가는 경로가 얽혀 있습니다. 각 단계에서 데이터가 누구의 서버를 거쳤는지, 어떤 형태로 노출되는지 파악하는 일은 단순히 "링크가 작동한다"는 것보다 시간을 들여 확인할 가치가 있습니다.