Clash 구독 형식 정리: YAML 설정, Base64 링크, SIP008 차이와 변환

먼저 구분하기: 구독 URL, 콘텐츠 형식, 프록시 프로토콜

‘구독 가져오기 실패’가 반드시 URL 만료를 뜻하는 것은 아닙니다. 하나의 링크가 Clash YAML이나 Base64로 인코딩된 노드 목록을 반환할 수도 있고, 로그인 페이지를 반환할 수도 있습니다. 콘텐츠를 받은 클라이언트는 형식을 판별하고 노드를 파싱한 뒤, 코어에서 연결을 설정합니다. 어느 단계에서든 형식이 맞지 않으면 가져오기에 실패하거나 노드를 사용할 수 없게 됩니다.

문제를 해결할 때는 아래 세 가지를 나눠 살펴보는 편이 ‘구독 업데이트’를 반복해서 누르는 것보다 효과적입니다.

구독 URL: 설정 파일을 내려받는 HTTP 또는 HTTPS 주소입니다. 경로에 .yaml 확장자가 있다고 해서 응답 형식까지 알 수 있는 것은 아닙니다.
콘텐츠 형식: 노드와 설정을 어떤 구조로 저장하는지 말합니다. 예를 들면 YAML, Base64로 인코딩된 URI 목록, SIP008 JSON이 있습니다.
프록시 프로토콜: 실제 연결에 사용하는 Shadowsocks, VMess, Trojan 등의 프로토콜입니다. 형식을 변환해도 프록시 프로토콜이 다른 종류로 바뀌지는 않습니다.

YAML: 전체 설정과 노드 제공자 파일은 다릅니다

YAML은 설정을 작성하는 형식이지 프록시 프로토콜이 아닙니다. Clash 계열의 전체 설정에는 보통 proxies, proxy-groups, rules 등의 필드가 있으며, proxy-providers를 통해 외부 노드를 불러오기도 합니다. 서버 주소와 비밀번호뿐 아니라 프록시 그룹 선택, 규칙 순서, DNS, 수신 포트 등의 설정도 담을 수 있습니다.

전체 설정에는 트래픽 분기 규칙을 포함할 수 있습니다

아래는 구조를 확인하기 위한 예시입니다. 도메인과 비밀번호는 예시일 뿐 연결에 사용할 수 없습니다. mixed-port: 7890은 로컬 혼합 프록시 수신 포트이며 원격 서버의 포트가 아닙니다.

mixed-port: 7890
allow-lan: false
mode: rule
proxies:
  - name: "예시 SS 노드"
    type: ss
    server: node.example.com
    port: 443
    cipher: aes-128-gcm
    password: "demo-password"
proxy-groups:
  - name: "출구 선택"
    type: select
    proxies:
      - "예시 SS 노드"
      - DIRECT
rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - MATCH,출구 선택

여기서 443은 예시 원격 포트입니다. 규칙은 위에서 아래 순서로 적용됩니다. example.org와 하위 도메인으로 향하는 트래픽은 직접 연결하고, 나머지는 ‘출구 선택’ 그룹에서 결정합니다. 가져온 뒤 노드만 보이고 해당 프록시 그룹과 규칙이 없다면, 클라이언트가 원본을 전체 설정이 아닌 ‘노드 가져오기’로 처리했는지 확인하세요.

proxies만 있는 파일은 제공자 파일일 수 있습니다

노드 제공자 파일은 보통 최상위 proxies:에 노드 목록을 저장합니다. 주 설정에서 proxy-providers로 불러온 다음 프록시 그룹의 use로 참조합니다. 전체 트래픽 분기 정책은 없으므로 ‘YAML 파일’이라는 이유만으로 바로 전환해 쓸 수 있는 전체 설정이라고 판단하면 안 됩니다.

반대로 노드 목록만 받는 입력란에 전체 설정을 그대로 넣어서도 안 됩니다. 로컬 규칙은 유지하면서 서비스 제공자 노드만 업데이트하려면, 매번 업데이트 후 원격 설정 전체를 직접 수정하기보다 클라이언트가 지원하는 제공자 또는 오버라이드 방식을 사용하세요. 구체적인 설정은 프로토콜 가이드를 참고하세요.

Base64: 인코딩된 노드 링크 목록

흔히 ‘Base64 구독’이라고 부르는 형식은 여러 노드 URI를 줄마다 나열한 뒤 전체 문자열을 Base64로 인코딩한 것입니다. 디코딩하면 ss://, vmess://, trojan:// 등으로 시작하는 링크가 나올 수 있습니다. 일부 구독은 이런 링크를 평문으로 바로 반환하며 바깥쪽 인코딩이 없습니다.

Base64는 암호화가 아닙니다: 콘텐츠를 얻은 사람은 보통 서버 주소, 인증 정보, 노드 이름을 복원할 수 있습니다.
노드 내부에도 인코딩이 적용될 수 있습니다: 일부 URI의 인증 부분이나 페이로드도 Base64를 사용할 수 있습니다. 구독의 바깥쪽을 디코딩해도 모든 필드가 평문이 되는 것은 아닙니다.
확장 필드는 구현에 따라 다릅니다: 전송 계층, TLS, 플러그인 옵션, 새 프로토콜 필드를 온전히 유지하려면 가져오기 기능과 코어가 모두 지원해야 합니다.

Base64는 바깥쪽 포장에 불과하며, 일반적으로 Clash의 rules와 proxy-groups는 포함하지 않습니다. 이를 Clash 설정으로 변환했을 때 새로 생긴 ‘자동 선택’, ‘장애 조치’ 또는 분기 규칙은 대부분 변환 템플릿에서 만들어진 것이지 원래 노드 목록에서 복원된 것이 아닙니다.

SIP008: Shadowsocks용 구조화 서버 목록

SIP008은 Shadowsocks 생태계에서 온라인 설정을 전달하기 위한 규격으로, JSON으로 서버 목록을 표현합니다. 모든 프록시 프로토콜을 아우르는 범용 구독 표준이 아니며 Clash의 정책 그룹이나 도메인 규칙도 표현하지 않습니다. 일반적인 SIP008 v1 문서에는 version과 servers 필드가 있으며, 서버 항목에 주소, 포트, 암호화 방식, 비밀번호, 메모를 지정합니다.

{
  "version": 1,
  "servers": [
    {
      "id": "c71e2e80-925f-4cf6-a437-ef9b79e9cb17",
      "remarks": "예시 SS 노드",
      "server": "node.example.com",
      "server_port": 443,
      "method": "aes-128-gcm",
      "password": "demo-password"
    }
  ]
}

Clash 노드로 변환할 때는 보통 server_port를 port로, method를 cipher로, remarks를 name으로 매핑한 뒤 type: ss를 추가합니다. 이는 필드 매핑이지 프로토콜 변환이 아닙니다.

항목에 plugin과 plugin_opts가 있다면 대상 코어가 해당 플러그인과 매개변수 형식을 지원하는지도 확인해야 합니다. 변환기가 YAML을 출력한다고 해서 플러그인 핸드셰이크까지 호환되는 것은 아닙니다. 서버가 해당 연결 방식을 지원하고 클라이언트 설정도 올바라야 연결할 수 있습니다.

Clash 클라이언트에서 바로 가져올 수 있는 형식

‘코어가 설정을 읽는 것’과 ‘GUI 클라이언트가 형식을 변환해 주는 것’을 구분해야 합니다. Clash와 mihomo는 Clash 스타일 YAML 설정을 주요 입력 형식으로 사용합니다. 일부 GUI 클라이언트는 공유 링크 가져오기, 구독 형식 인식, 템플릿 조합 기능을 추가로 제공합니다. 특정 클라이언트가 Base64를 지원한다고 해서 모든 Clash 클라이언트가 지원하는 것은 아닙니다.

받은 콘텐츠	적합한 가져오기 방식	확인할 사항
Clash 전체 YAML 설정	설정 파일 또는 원격 설정 가져오기	코어가 프로토콜과 설정 필드를 지원하는지
YAML 노드 제공자	주 설정의 proxy-providers	프록시 그룹에서 use로 제공자를 참조하는지
Base64 또는 평문 URI 목록	클라이언트가 명시적으로 지원하는 노드 가져오기 또는 신뢰할 수 있는 변환 절차	프록시 그룹, 규칙, DNS를 추가해야 하는지
SIP008 JSON	SIP008을 명시적으로 지원하는 가져오기 또는 변환 메뉴	SS 암호화 방식과 플러그인 매개변수가 호환되는지

클라이언트마다 메뉴 이름은 다릅니다. 작업할 때는 ‘설정 파일 가져오기’, ‘원격 설정 추가’, ‘노드 가져오기’의 용도를 구분하세요. 노드 공유 링크를 HTTPS 구독 URL만 받는 입력란에 붙여 넣으면 안 됩니다. 처음 설치한다면 빠른 시작 가이드에 따라 설정을 먼저 가져온 다음 형식 호환 문제를 확인하세요.

구독을 변환하면 무엇이 사라질까: 노드 외 정보가 가장 쉽게 손실됩니다

‘변환 성공’은 대상 파일이 만들어졌다는 뜻일 뿐 원본 설정이 완전히 복사됐다는 뜻은 아닙니다. 먼저 원본 형식에 대상 정보가 담겨 있었는지 확인하고, 변환기가 해당 정보를 실제로 유지했는지도 살펴보세요.

전체 YAML을 노드 링크로 변환할 때

규칙과 순서: DOMAIN-SUFFIX, IP-CIDR, MATCH 등의 규칙은 일반적으로 개별 노드 URI에 포함되지 않습니다.
프록시 그룹 관계: select, url-test, fallback의 계층 구조와 테스트 주소, 간격 등의 설정은 보통 유지할 수 없습니다.
로컬 실행 설정: DNS, TUN, 수신 주소, 혼합 포트, 컨트롤 인터페이스 등은 노드 공유 정보에 포함되지 않습니다.
외부 참조: 규칙 세트와 노드 제공자, 업데이트 정책은 내보낼 때 제외되거나 당시 펼쳐진 노드 목록만 스냅샷으로 남을 수 있습니다.

노드 목록을 전체 YAML 설정으로 변환할 때

변환기는 노드를 어떤 그룹에 넣을지, 어떤 도메인을 직접 연결할지, 기본 트래픽을 어디로 보낼지 추가로 결정해야 합니다. 템플릿에 따라 결과도 달라집니다. 같은 노드 목록으로 생성한 두 설정에서 같은 웹사이트의 연결 경로가 달라진다면, 대개 노드가 아니라 규칙이 달라졌기 때문입니다.

노드 이름도 확인해야 합니다. 이름 변경, 중복 제거, 지역별 그룹화로 기존 규칙 참조가 깨질 수 있고, URI 인코딩된 이름은 변환 과정에서 올바르게 디코딩해야 합니다. 가져오기 오류에 ‘프록시가 없습니다’라고 표시되면 proxy-groups와 rules에서 참조하는 이름부터 대조하고, 모든 규칙을 성급하게 삭제하지 마세요.

변환으로 서버에 없는 기능을 만들어낼 수는 없습니다

Shadowsocks 항목을 Trojan이나 다른 프로토콜 필드로 바꿔 써도 원래 서버가 해당 프로토콜을 지원하게 되는 것은 아닙니다. 마찬가지로 원본에 TLS 서버 이름, 전송 경로, 필수 인증 정보가 빠져 있다면 변환기가 이를 알아서 추론할 수 없습니다. 설정 파일을 저장할 수 있게 될 때까지 매개변수를 임의로 추가하기보다 올바른 형식의 구독을 다시 받으세요.

재사용 가능한 구독 확인 및 변환 절차

원본을 보관하세요: 구독 주소의 형식 안내와 확인 시점을 기록하고 현재 정상 작동하는 설정을 백업하세요. 유일한 기존 설정 파일을 덮어쓰며 테스트하지 마세요.
응답 내용을 확인하세요: 다운로드가 성공했는지 확인합니다. <!DOCTYPE html>이나 로그인 양식으로 시작하는 응답은 웹페이지이지 사용할 수 있는 프록시 설정이 아닙니다. HTTP 200 응답이라고 해서 이 가능성을 배제할 수는 없습니다.
파일명이 아니라 구조를 확인하세요: 최상위에 proxies: 등의 필드가 있으면 YAML일 가능성이 높습니다. version과 servers가 포함된 JSON은 SIP008일 수 있습니다. 인코딩된 긴 문자열은 로컬에서 디코딩한 뒤 구조를 확인해야 합니다.
원래 형식을 우선 사용하세요: 서비스 제공자가 해당 코어용 Clash 또는 mihomo 형식을 제공한다면 그 형식을 다시 받는 것이 좋습니다. 적합한 주소가 없을 때만 신뢰할 수 있는 로컬 도구나 직접 운영하는 변환 도구를 고려하세요.
업데이트 경로를 유지하세요: YAML을 한 번 내보내면 스냅샷이 만들어질 뿐 원본 주소의 변경 사항이 자동으로 반영되지 않습니다. 원격 변환 주소를 사용하면 변환 서비스가 계속 작동해야 하고 원본 구독 정보가 서비스에 노출될 수도 있습니다.
가져온 뒤 항목별로 확인하세요: 원본과 대상의 노드 수, 프로토콜 종류, 프록시 그룹, 최종 기본 규칙을 비교한 다음 직접 연결되어야 하는 대상 하나와 프록시를 거쳐야 하는 대상 하나를 테스트하세요.

예를 들어 원본 목록에 항목이 12개 있는데 변환 결과가 9개뿐이라면, 나머지 3개가 프로토콜 미지원, 필드 누락, 중복 제거, 이름 충돌로 제외됐는지 확인하세요. 이 숫자는 검증 방법을 보여 주기 위한 예시일 뿐, 변환 과정에서 정상적으로 허용되는 손실량이 아닙니다. 이유를 모른 채 노드가 줄어드는 상황을 당연하게 받아들이지 마세요.

가져오기 실패와 업데이트 오류: 오류가 발생한 단계별로 확인하세요

YAML 구문 오류가 발생할 때

먼저 오류가 난 줄 주변의 들여쓰기, 콜론, 따옴표를 확인하세요. YAML 들여쓰기는 공백을 사용하며 Tab으로 대체할 수 없습니다. 예시에서 비밀번호를 따옴표로 감싼 것은 특수 문자가 구조 기호로 해석되는 일을 막기 위해서입니다. 응답이 실제로 JSON이나 HTML이라면 YAML 들여쓰기를 고쳐도 해결되지 않으므로 구독 주소를 다시 확인하세요.

설정을 가져왔지만 노드가 없거나 연결할 수 없을 때

파일에 제공자 내용만 들어 있는지, 주 설정에서 해당 제공자를 참조하는지 먼저 확인하세요. 노드는 있지만 연결되지 않는다면 코어 로그에서 ‘지원하지 않는 프록시 유형’, ‘알 수 없는 암호화 방식’, 플러그인 매개변수 오류를 확인하세요. 형식이 올바른 것과 연결이 되는 것은 별개이며, 연결 여부는 서버 상태, 네트워크 경로, 계정 유효성에도 달려 있습니다.

수정한 규칙이 한 번 업데이트한 뒤 원래대로 돌아올 때

원격 설정을 업데이트하면 다운로드한 내용으로 기존 설정이 교체되는 경우가 많습니다. 원격 파일을 직접 편집하면 다음 업데이트 때 변경 사항이 덮어써질 수 있습니다. 계속 유지해야 하는 규칙은 클라이언트가 지원하는 오버라이드, 병합 기능 또는 별도 주 설정에 넣고 최종 적용 순서를 확인하세요. 규칙은 위에서 아래로 매칭되므로 사용자 규칙을 MATCH 뒤에 추가하면 대개 원하는 결과를 얻을 수 없습니다.