구독 형식 정리: Clash YAML, Base64 노드 링크와 구독 변환의 차이

1. 응답 내용을 확인한 뒤 가져오기 방법 선택

Clash 클라이언트는 일반적으로 현재 코어와 호환되는 YAML 설정이 필요합니다. Base64로 인코딩된 노드 목록이나 단일 프로토콜 링크는 완전한 설정 파일이 아닙니다. 파일 이름에 ‘구독’이 들어가거나 확장자가 .yaml이라고 해서 가져오기가 보장되는 것은 아닙니다. 실제 형식은 서버가 반환하는 텍스트 구조와 클라이언트가 해당 형식을 파싱하거나 변환하는 기능을 제공하는지에 따라 결정됩니다.

구독 URL은 콘텐츠를 가져오는 경로일 뿐, 고정된 형식을 뜻하지 않습니다. 같은 URL도 요청 매개변수나 User-Agent에 따라 다른 내용을 반환할 수 있습니다. 브라우저에는 노드 링크가 표시되고 클라이언트에는 YAML이 전달될 수도 있으며, 그 반대도 가능합니다. 따라서 ‘브라우저에서 URL이 열린다’와 ‘Clash 클라이언트가 설정을 불러온다’는 별도로 확인해야 합니다.

콘텐츠 유형	일반적인 특징	권장 처리 방법
Clash YAML	`proxies:`, `proxy-groups:`, `rules:` 등의 필드가 보임	코어 호환성을 확인한 뒤 설정으로 가져오기
Base64 노드 목록	겉으로는 긴 인코딩 문자열이며, 디코딩하면 보통 여러 줄의 프로토콜 링크가 나옴	해당 입력 형식을 지원하는 도구로 대상 설정 형식으로 변환
단일 프로토콜 링크	`ss://`, `vmess://`, `trojan://` 등으로 시작	노드 가져오기 기능을 사용하거나 변환한 뒤 설정에 추가
웹페이지 또는 API 오류	`<!DOCTYPE html>`, 로그인 안내 또는 오류 JSON이 표시됨	구독 요청부터 바로잡고 변환은 진행하지 않기

2. Clash YAML: 노드, 정책 그룹, 규칙의 역할

YAML은 직렬화 형식이고, Clash 설정은 코어에서 정한 필드 모음입니다. YAML 문법에 맞는다고 해서 모두 올바른 Clash 설정인 것은 아닙니다. 예를 들어 message 필드 하나만 담긴 API 응답은 YAML로 파싱되더라도 사용할 수 있는 프록시 설정은 아닙니다.

proxies: 프로토콜 유형, 서버, 포트, 인증 정보 등을 포함하는 노드 정의입니다.
proxy-providers: 파일이나 원격 URL에서 노드 목록을 불러오는 노드 제공자입니다.
proxy-groups: 수동 선택, 지연 시간 테스트, 장애 조치 등의 선택 방식을 정의하는 정책 그룹입니다.
rules: 트래픽을 순서대로 매칭해 DIRECT, REJECT 또는 정의된 정책으로 전달합니다.
dns, tun: DNS 조회와 트래픽 가로채기 설정입니다. 모든 노드 구독에 포함되는 것은 아닙니다.

필드 구성을 확인하는 최소 예제

아래는 직결 규칙만 있는 설정입니다. mixed-port: 7890은 HTTP와 SOCKS가 같은 수신 포트를 사용한다는 뜻입니다. 원격 노드는 없으며 시스템 프록시나 TUN도 활성화하지 않습니다. 완전한 설정과 노드 목록의 차이를 보여 주기 위한 예제입니다. 클라이언트 UI 설정이 포트 등의 필드를 덮어쓸 수 있으므로 실제 값은 실행 중인 설정을 기준으로 확인하세요.

direct-demo.yaml · 직결 전용 예제

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: LOCAL
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,LOCAL

여기서 MATCH,LOCAL은 정의된 LOCAL 정책 그룹을 가리킵니다. 흔히 쓰이는 MATCH,PROXY도 설정에 PROXY라는 이름의 노드나 정책 그룹이 있어야 합니다. 자동으로 생성되는 기본 출구가 아닙니다. 규칙만 복사하고 정책 그룹을 빠뜨리면 참조 오류가 발생합니다.

완전한 설정과 provider 파일은 구분해서 사용하세요

노드 provider 파일은 보통 proxies:를 중심으로 노드 목록만 제공합니다. 규칙 provider 파일에는 보통 payload:가 사용됩니다. 이런 파일은 메인 설정에서 참조해야 하며, 정책 그룹과 라우팅 규칙까지 포함된 완전한 구독처럼 바로 사용할 수 없습니다. 특히 규칙 provider URL을 노드 구독 입력란에 넣지 마세요.

3. Base64와 프로토콜 링크: 디코딩은 변환이 아닙니다

Base64는 인코딩 방식이지 암호화나 프록시 프로토콜이 아닙니다. 기존 구독 형식에서는 여러 프로토콜 링크를 줄마다 배치한 뒤 텍스트 전체를 Base64로 인코딩하는 경우가 많습니다. 디코딩해도 노드 설명만 나오며 정책 그룹, DNS, 규칙이 자동으로 생기지는 않습니다.

일부 프로토콜 링크 내부에서도 Base64를 사용합니다. 예를 들어 흔히 쓰이는 VMess 공유 링크는 JSON 노드 매개변수를 인코딩해 vmess:// 뒤에 붙입니다. Shadowsocks 링크도 여러 인코딩 형식이 있습니다. ‘구독 전체의 인코딩 단계’와 ‘개별 프로토콜 링크의 인코딩 단계’를 혼동하지 마세요. 익숙한 텍스트가 나올 때까지 반복해서 디코딩해서도 안 됩니다.

바깥 형식 확인: 원문이 이미 ss:// 등의 링크로 한 줄씩 구성되어 있다면 전체를 Base64로 먼저 디코딩할 필요가 없습니다.
로컬에서 디코딩: 노드 목록이 인코딩된 것이 맞는지 확인한 뒤 신뢰할 수 있는 로컬 도구로 결과를 확인하세요. URL-safe 문자 사용 여부와 패딩 누락도 살펴보세요.
필드 확인: 프로토콜, 포트, 전송 방식, TLS 매개변수를 점검하세요. ‘노드 이름이 표시되는지’만 확인해서는 안 됩니다.
설정 생성: 파싱 가능한 노드를 대상 코어의 필드로 변환한 뒤 정책 그룹과 규칙을 추가합니다. 이 과정이 바로 구독 변환입니다.

4. 구독 변환: 대상 코어, 템플릿, 인증 정보 위험

변환 도구는 보통 원본 콘텐츠 다운로드, 노드 매개변수 파싱, 대상 형식으로 출력의 세 단계를 수행합니다. 규칙 템플릿을 적용하면 정책 그룹과 라우팅 규칙, 나아가 원격 규칙 세트 참조까지 추가할 수 있습니다. 따라서 같은 노드 목록을 변환해도 템플릿에 따라 최종 트래픽 경로가 완전히 달라질 수 있습니다.

서비스 제공자가 지원하는 형식을 우선 사용하세요

구독 관리 페이지에 ‘Clash’, ‘Clash Meta’, ‘mihomo’ 항목이 있다면 실제 코어에 맞는 옵션을 우선 선택하세요. Clash Meta는 현재 mihomo로 불립니다. 구형 Clash 코어와 mihomo는 지원하는 필드와 프로토콜 범위가 서로 다릅니다. 변환기에서 대상 이름을 과거 명칭으로 표시할 수도 있으므로 출력 필드와 대상 코어 문서를 최종 기준으로 삼으세요.

변환으로 구형 코어에 프로토콜 지원을 추가할 수는 없습니다. 원본 노드가 대상 코어에서 지원하지 않는 프로토콜이나 전송 매개변수를 사용하면 도구가 오류를 내거나 노드를 건너뛰고 필드를 버릴 수 있습니다. 출력 파일의 확장자를 .yaml로 바꿔도 호환성 문제는 해결되지 않습니다.

공개 변환 서비스에서 확인할 수 있는 정보

경로, 쿼리 매개변수, 접근 토큰이 포함된 원본 구독 URL
가져온 서버 주소, 포트, 비밀번호, UUID 등 노드 인증 정보
구독에 포함된 요금제 정보와 변환 요청 관련 접근 기록

HTTPS는 전송 중인 데이터를 보호하지만 변환 서비스 자체가 입력 내용을 읽는 것까지 막지는 못합니다. 변환이 필요하다면 신뢰할 수 있는 로컬 도구나 자체 호스팅 서비스를 우선 사용하세요. 웹페이지를 로컬에 저장했다고 변환까지 로컬에서 이뤄지는 것은 아닙니다. 원격 백엔드로 요청을 보내는지 확인해야 합니다.

변환 후 반드시 확인할 항목

원본과 비교해 노드 수, 프로토콜 유형, TLS의 servername, WebSocket의 ws-opts, gRPC의 grpc-opts, 인증 정보가 유지됐는지 확인하세요. 연결 오류를 없애려고 skip-cert-verify를 일괄 활성화하지 마세요. 템플릿이 낯선 rule-providers, DNS 업스트림 또는 외부 제어 설정을 추가했는지도 살펴보세요. 변환이 성공했다는 것은 결과물이 생성됐다는 뜻일 뿐, 설정이 예상대로라는 의미는 아닙니다.

5. Clash 클라이언트에서 가져오기 및 확인

‘원격 설정 가져오기’와 ‘단일 노드 추가’를 구분하세요. 대부분의 Clash GUI 클라이언트는 설정 단위로 관리하며, 임의의 프로토콜 링크를 바로 받아들이는 것은 보장하지 않습니다. 아래에서는 Clash Verge Rev의 ‘구독’ 페이지를 예로 듭니다. 다른 제품은 메뉴가 ‘설정’으로 표시될 수 있고 버튼 이름도 버전에 따라 달라집니다.

현재 설정 백업: 기존 구독 URL, 로컬 오버라이드, 사용 중인 정책 그룹 선택을 저장하세요. 새 설정을 테스트할 때 기존 설정을 유지하면 필요할 때 되돌릴 수 있습니다.
원격 설정 추가: ‘구독’으로 이동해 서비스 제공자가 안내한 Clash 또는 mihomo 구독 URL을 URL 입력란에 넣고 ‘가져오기’를 실행한 다음 새 설정을 선택하세요.
로컬 파일 가져오기: YAML 파일이 있다면 클라이언트의 로컬 설정 가져오기 메뉴를 사용하세요. 디스크 경로를 원격 URL 입력란에 붙여넣지 마세요.
파싱 결과 확인: ‘프록시’로 이동해 정책 그룹과 노드가 표시되는지 확인하세요. 로그를 살펴 설정 로드 실패, provider 다운로드 실패, 노드 연결 실패를 구분하세요.
트래픽 확인: 실제 수신 포트를 확인한 뒤 시스템 프록시를 활성화하고 브라우저 접속을 테스트하세요. 실행 포트가 7890이라면 앱의 연결 주소는 구독 서버 주소가 아니라 로컬 주소 127.0.0.1:7890이어야 합니다.

시스템 프록시와 TUN은 트래픽이 코어로 들어가는 방식을 정할 뿐, Base64 노드 목록을 YAML로 변환하지 않습니다. 가져오기에 실패했다고 TUN을 반복해서 전환하면 점검할 변수만 늘어납니다. 먼저 설정이 정상적으로 로드되도록 한 다음 트래픽 처리 범위, DNS, 라우팅 문제를 살펴보세요.

계속 유지해야 하는 규칙은 클라이언트가 지원하는 오버라이드 기능에 넣으세요. 원격 구독을 다운로드한 뒤 파일을 직접 편집하면 다음 업데이트 때 서비스 제공자의 원본으로 복원될 수 있습니다. 목록 병합 오버라이드를 사용하는 경우에는 클라이언트가 규칙을 추가, 앞에 삽입, 교체 중 어떤 방식으로 처리하는지 확인하세요. 최종 MATCH 규칙보다 사용자 지정 규칙이 뒤로 밀리지 않도록 해야 합니다.

6. 가져오기 실패: 오류가 발생한 단계별 점검

증상 또는 로그 내용	우선 확인할 항목	다음 단계
`401 Unauthorized` / `403 Forbidden`	토큰 만료 여부, 서비스 제공자 제한, URL 전체 복사 여부	구독 URL을 다시 발급받으세요. 변환으로 접근 제한을 우회하려고 하지 마세요.
`yaml: unmarshal errors`	응답이 YAML인지, 필드 유형이 올바른지	실제 응답을 로컬에서 확인하고 오류가 난 줄 주변의 구조를 살펴보세요.
`proxy not found`	규칙이나 정책 그룹이 참조하는 이름이 실제로 있는지	이름과 대소문자, 변환 후 이름이 바뀌었는지 하나씩 대조하세요.
원본 구독보다 노드 수가 적음	변환기가 미지원 프로토콜을 건너뛰었거나 노드를 필터링했는지	변환 로그와 필터 조건, 대상 코어의 지원 범위를 확인하세요.
설정은 로드됐지만 연결 시간이 초과됨	노드 연결 가능 여부, 인증, DNS, TLS, 전송 매개변수	연결 로그를 확인하세요. 형식 변환부터 다시 하지 마세요.

YAML 들여쓰기와 필드 유형

YAML 들여쓰기는 공백으로 하고 Tab은 사용하지 마세요. 목록 항목에는 -가 필요하고, 매핑에는 일반적으로 콜론 뒤에 공백을 둡니다. 비밀번호나 이름에 콜론, 샵 등의 문자가 포함되면 YAML 규칙에 맞게 따옴표로 감싸야 합니다. 인증 값은 문자열로 지정하는 것이 좋습니다. 순수 숫자나 특수한 텍스트가 다른 유형으로 파싱되는 일을 방지할 수 있습니다.

브라우저에서는 다운로드되지만 클라이언트에서 업데이트되지 않음

리디렉션, 인증서, 요청 헤더 차이, 구독 업데이트에 직결과 프록시 중 어떤 경로를 사용하는지 확인하세요. 프록시를 통해서만 구독에 접근할 수 있는데 현재 설정에 사용할 수 있는 노드가 없다면, 아직 마련되지 않은 연결에 업데이트가 의존하는 상황이 생길 수 있습니다. 먼저 서비스 제공자가 제공한 로컬 YAML로 초기 가져오기를 마친 뒤 원격 업데이트 경로를 점검하세요.

새 프로토콜을 가져온 뒤 미지원 오류가 표시됨

클라이언트의 ‘정보’ 페이지에서 클라이언트 버전과 코어 버전을 확인하세요. 두 버전 번호는 서로 다릅니다. 정확한 프로토콜 이름, 코어 버전, 오류 메시지를 기록한 뒤 호환성을 확인하세요. 설치 파일 이름에 Clash가 들어간다고 모든 필드가 호환되는 것은 아닙니다. 구형 Clash 설정, mihomo 확장 필드, 클라이언트 자체 오버라이드 스크립트는 각각 따로 판단해야 합니다.

확인 순서는 응답 내용 확인 → 형식 식별 → 대상 코어 확인 → 설정 가져오기 → 연결 확인입니다. 호환되는 YAML을 받았다면 추가 변환은 필요하지 않습니다. 변환해야 한다면 손실된 필드를 비교하고 찾을 수 있도록 원본 내용과 변환 설정을 보관하세요.