Clash 구독 형식 완벽 가이드: 구성 유형 식별, 호환성 차이와 변환 원칙
Clash, Mihomo 및 범용 노드 구독의 구조적 차이를 확인하고 변환 전에 점검해야 할 필드와 규칙을 알아봅니다.
구독, 설정, 인코딩은 서로 다른 계층입니다
Clash 구독 문제를 점검할 때 첫 단계는 변환 도구를 찾는 것이 아니라 링크, 응답 내용, 클라이언트 설정의 관계를 구분하는 것입니다. 구독 링크는 데이터를 가져오는 진입점일 뿐입니다. 클라이언트가 이 주소로 요청하면 서버는 완전한 YAML 설정, 노드만 포함된 YAML, 한 줄에 하나씩 나열된 공유 링크 또는 Base64로 인코딩된 텍스트를 반환할 수 있습니다. 링크 끝에 파일 확장자가 있는지만으로는 응답 유형을 정확히 판단하기 어렵습니다.
완전한 Clash 설정은 실행 가능한 트래픽 처리 경로를 정의합니다. 노드 외에도 수신 포트, 프록시 그룹, 규칙, 규칙 제공기, DNS, TUN, 스니핑, 설정 제공기 등이 포함될 수 있습니다. 노드 구독은 ‘사용 가능한 프록시 진입점’을 제공할 뿐, 도메인이 어떤 정책 그룹으로 이동할지 독립적으로 결정하지 못하며 로컬 DNS나 네트워크 가로채기 설정을 대신할 수도 없습니다.
일반적인 콘텐츠는 다음 네 가지 유형으로 나눌 수 있습니다.
- 완전한 설정: 일반적으로
proxies,proxy-groups,rules를 확인할 수 있습니다. 가져온 뒤 규칙 모드의 기본 실행 체인을 바로 구성할 수 있습니다. - 노드 제공기 설정: 주로
proxies배열로 구성되며, 주 설정의proxy-providers에서 참조됩니다. 완전한 설정으로 단독 실행되지 않을 수 있습니다. - 범용 공유 링크 목록: 각 줄에
ss://,trojan://,vmess://같은 프로토콜 링크가 하나씩 들어갑니다. 직접 가져올 수 있는지는 클라이언트의 구독 파싱 기능에 달려 있습니다. - 인코딩된 텍스트: Base64는 텍스트 전송 방식일 뿐입니다. 디코딩한 뒤에도 링크 목록인지, YAML인지, JSON인지, 아니면 서버가 반환한 오류 페이지인지 다시 확인해야 합니다.
응답 내용으로 설정 유형 확인하기
형식을 판단할 때는 웹페이지의 설명이 아니라 구독 요청이 실제로 반환한 본문을 확인해야 합니다. 브라우저 개발자 도구, 클라이언트 업데이트 로그 또는 응답 헤더와 본문을 표시하는 명령줄 도구를 사용할 수 있습니다. 구독에 인증이 필요하다면 전체 주소를 공개 로그, 스크린샷 또는 온라인 분석 페이지에 붙여 넣지 마세요. 쿼리 매개변수에 장기간 유효한 접근 자격 증명이 포함될 수 있습니다.
반환된 내용이 설정인지 웹페이지인지 먼저 확인하세요
구독 주소가 만료되었거나 인증이 만료되었거나 요청 빈도가 제한되면 서버가 HTML 로그인 페이지, 오류 페이지 또는 인증 페이지를 반환할 수 있습니다. 본문 시작 부분에 <!doctype html> 또는 <html>이 나타난다면 YAML로 계속 파싱해서는 안 됩니다. HTTP 상태가 성공이라고 해서 본문이 유효한 설정이라는 뜻도 아닙니다. 일부 서비스는 일반 웹페이지에 오류 설명을 표시합니다.
YAML 최상위 필드 확인하기
구조가 비교적 완전한 Clash 설정은 다음과 같은 뼈대를 가질 수 있습니다. 실제 필드는 커널과 용도에 따라 달라지지만, 프록시 그룹의 참조와 규칙 대상은 서로 연결되어야 합니다.
mixed-port: 7890
mode: rule
log-level: info
proxies:
- name: Tokyo-01
type: trojan
server: edge.example.invalid
port: 443
password: example-password
sni: edge.example.invalid
proxy-groups:
- name: PROXY
type: select
proxies:
- Tokyo-01
- DIRECT
rules:
- DOMAIN-SUFFIX,example.org,PROXY
- MATCH,DIRECTproxies에서 노드를 정의하고, proxy-groups에서 노드나 다른 정책 그룹을 선택 가능한 정책으로 구성합니다. rules의 마지막 부분은 정책 그룹, 노드 이름 또는 내장 동작을 참조합니다. 규칙이 PROXY를 가리킨다면 설정에 같은 이름의 정책 그룹이나 사용 가능한 대상이 있어야 합니다. 이름의 대소문자와 공백은 구분되므로 변환 과정에서 임의로 이름을 바꾸면 참조가 끊어질 수 있습니다.
링크 목록과 인코딩된 콘텐츠 확인하기
디코딩한 여러 줄의 텍스트에 프로토콜 접두사가 다수 나타난다면 일반적으로 노드 링크 구독입니다. 링크에는 서버, 포트, 인증 정보와 일부 전송 매개변수가 들어 있지만 완전한 규칙 체계는 보통 포함되지 않습니다. 일부 링크는 조각 식별자에 표시 이름을 저장합니다. 파서마다 퍼센트 인코딩이나 문자 집합을 처리하는 방식이 다르면 가져온 뒤 노드 이름이 깨지거나 중복될 수 있습니다.
텍스트가 무작위 문자열처럼 보인다는 이유만으로 Base64라고 단정할 수는 없습니다. 먼저 압축 데이터, JSON, HTML, 서버 안내문인지 확인한 뒤 문자 집합에 맞는 방식으로 디코딩하세요. 디코딩이 끝난 뒤에도 형식 식별을 다시 수행해야 하며, 디코딩에 성공했다고 설정을 사용할 수 있는 것은 아닙니다.
| 관찰된 특징 | 가능한 유형 | 다음 단계 |
|---|---|---|
| proxies, proxy-groups, rules가 모두 존재함 | 완전한 Clash 또는 Mihomo YAML | 커널 필드 호환성과 참조 관계 확인 |
| proxies 배열만 존재함 | 노드 제공기 콘텐츠 | 주 설정에서 provider로 참조하거나 정책과 규칙을 보완 |
| 각 줄이 프로토콜 링크로 시작함 | 범용 노드 구독 | 해당 프로토콜을 지원하는 파서로 노드 항목 생성 |
| 본문이 HTML 태그로 시작함 | 로그인 페이지 또는 오류 페이지 | 주소, 인증, 상태 코드 및 리디렉션 확인 |
| 디코딩 후에야 YAML 또는 링크가 나타남 | 인코딩으로 포장된 구독 | 디코딩된 실제 콘텐츠를 기준으로 계속 판단 |
Clash, Clash Meta, Mihomo의 호환성 경계
‘Clash 형식’은 영원히 고정된 단일 버전이 아닙니다. 초기 Clash 커널은 널리 사용되는 YAML 구조를 마련했고, Clash Meta는 이를 기반으로 프로토콜, 규칙, DNS, TUN 및 라우팅 기능을 확장했습니다. 이후 프로젝트 명칭은 Mihomo로 이어졌습니다. 현재 많은 클라이언트가 Mihomo를 커널로 사용하지만, 인터페이스나 구독 제공업체는 여전히 Clash라는 일반적인 명칭을 사용합니다.
일반적으로 새 커널은 기존 필드를 더 많이 읽을 수 있지만, 그렇다고 모든 Mihomo 설정을 구형 커널에서 사용할 수 있는 것은 아닙니다. 구형 커널이 인식하지 못하는 프록시 유형, 전송 매개변수, 규칙 문법 또는 DNS 옵션이 하나라도 포함되면 시작 시 필드 오류가 발생하거나 일부 설정이 무시될 수 있습니다. 변환 대상은 클라이언트 이름이 아니라 실제 실행 중인 커널을 기준으로 정해야 합니다.
프록시 프로토콜 및 전송 매개변수
노드 사용 가능 여부는 커널이 해당 프로토콜과 매개변수 조합을 구현했는지에 따라 결정됩니다. 두 구독에 같은 이름의 프로토콜이 들어 있어도 TLS 지문, Reality, HTTP/2, gRPC, QUIC 또는 기타 확장 매개변수의 필드 이름과 지원 범위는 다를 수 있습니다. 변환기가 특정 필드를 인식하지 못하면 ‘자동 호환’되는 것이 아니라 해당 필드가 삭제되거나 연결할 수 없는 노드로 바뀌는 경우가 많습니다.
규칙 제공기의 동작 유형
rule-providers에는 원격 파일 주소뿐 아니라 behavior, 형식, 업데이트 주기, 저장 경로도 포함됩니다. 일반적인 동작 유형은 domain, ipcidr, classical입니다. 도메인 집합을 IP 대역 집합으로 직접 사용할 수는 없으며, 클래식 규칙 집합은 유형 접두사가 붙은 규칙 항목을 담을 수 있습니다. 주 규칙의 RULE-SET 참조는 제공기 이름과 일치해야 합니다.
DNS와 TUN은 로컬 실행 환경에 속합니다
DNS와 TUN 설정은 운영체제, 권한, 네트워크 인터페이스, 클라이언트 구현과 밀접하게 연관됩니다. 노드 구독의 서버 정보는 여러 기기에서 옮겨 쓸 수 있지만, TUN 인터페이스 이름, 라우팅 제외 항목, DNS 수신 주소 또는 시스템 프록시 설정 전체를 복사하면 원본 기기의 전제 조건이 대상 기기로 그대로 منتقل될 수 있습니다. 데스크톱에서 사용할 수 있는 설정이 서버에 적합하다는 보장은 없으며, Android 클라이언트는 인터페이스에서 VPN 권한을 관리하면서 일부 데스크톱 필드를 무시할 수도 있습니다.
구독 변환 전에 확인할 여섯 가지
변환의 목표는 모든 내용을 ‘가져올 수 있는’ 파일 하나로 압축하는 것이 아니라, 원본 데이터를 대상 커널이 이해할 수 있는 구조로 매핑하는 것입니다. 변환을 시작하기 전에 최소한 다음 여섯 가지를 확인하세요.
- 대상 커널을 확인합니다. 클라이언트가 Mihomo를 사용하는지, 기존 Clash 호환 커널을 사용하는지, 자체 파싱 계층을 가진 모바일 클라이언트인지 기록하세요. 같은 구독도 클라이언트에 따라 가져오기 결과가 달라질 수 있습니다.
- 원본 범위를 확인합니다. 원본이 완전한 설정인지, 노드 모음인지, 단일 공유 링크인지 판단하세요. 노드 모음은 변환 후에도 주 설정에서 정책 그룹, 규칙, DNS를 제공해야 하는 경우가 많습니다.
- 프로토콜과 핵심 필드를 정리합니다. 각 노드 유형의 인증, TLS, SNI, 전송 방식, UDP 지원 여부와 확장 매개변수를 확인하세요. 변환 후에는 노드 수만 비교하지 말고 여러 항목을 표본으로 대조해야 합니다.
- 이름 참조를 확인합니다. 프록시 그룹은 노드와 다른 프록시 그룹을 참조할 수 있고, 규칙은 정책 대상을 참조합니다. 이름 변경, 중복 제거 또는 문자 정규화가 발생하면 모든 참조도 함께 업데이트해야 합니다.
- 규칙의 의미를 확인합니다. Clash는 설정 순서대로 위에서 아래로 규칙을 검사하고 일치하면 중단하므로 규칙 순서가 결과에 영향을 줍니다. 변환 중 규칙을 다시 정렬하면 트래픽 경로가 달라질 수 있습니다.
- 원격 설정과 로컬 설정을 나눕니다. 노드와 원격 규칙은 일정에 따라 업데이트할 수 있지만, 포트, 제어 인터페이스, DNS, TUN, LAN 수신, 인증은 일반적으로 로컬 템플릿에서 관리하는 편이 적합합니다.
노드 수가 같은데도 변환에 실패하는 이유
노드 수가 같다는 것은 파서가 같은 수의 항목을 만들었다는 뜻일 뿐, 각 항목의 매개변수가 완전하다는 의미는 아닙니다. 변환기가 서버와 포트는 유지하면서 SNI, 전송 경로 또는 프로토콜 확장을 누락할 수 있고, 같은 이름의 노드에 자동으로 접미사를 붙여 기존 정책 그룹이 이전 이름을 계속 참조하게 만들 수도 있습니다. 검증할 때는 서로 다른 프로토콜의 노드를 골라 각각 확인하고 연결 로그에서 핸드셰이크 단계의 오류를 살펴보세요.
규칙을 단순히 텍스트로 이어 붙이면 안 되는 이유
두 규칙 목록을 그대로 이어 붙이면 순서 충돌이 발생할 수 있습니다. 예를 들어 앞부분의 광범위한 도메인 규칙이 먼저 일치해 뒤의 정밀한 규칙이 작동하지 않을 수 있습니다. IP 규칙은 DNS 조회를 유발할 수도 있으며, 구체적인 동작은 규칙 유형과 매개변수에 따라 달라집니다. 병합할 때는 먼저 우선순위를 정하세요. 로컬 예외 규칙은 일반적으로 더 구체적인 위치에 두고, 광범위한 규칙과 최종 폴백 규칙은 뒤에 배치하며, 전체 설정에는 명확하고 제어 가능한 최종 경로만 남겨야 합니다.
온라인 변환 서비스와 자격 증명의 경계
구독 주소에는 일반적으로 노드 설정을 읽을 수 있는 권한이 있습니다. 전체 주소를 제3자 변환 서비스에 제출하면 해당 서비스에 구독 응답에 접근할 권한을 주는 것과 같습니다. 더 안전한 방법은 신뢰할 수 있는 환경에서 로컬 변환 절차를 사용하거나 구독 제공업체가 명시한 대상 형식을 이용하는 것입니다. 중간 서비스를 반드시 거쳐야 한다면 요청 방식, 로그 정책, 캐시 동작을 확인하고 처리 후에는 제공업체가 지원하는 방식으로 접근 자격 증명을 갱신하세요.
검증 가능하고 되돌릴 수 있는 변환 절차 만들기
안정적인 변환 과정에서는 원격 노드, 로컬 주 설정, 생성 결과를 별도로 저장해야 합니다. 이렇게 하면 구독이 업데이트될 때 데이터 소스만 교체되고, 이미 검증한 DNS, TUN, 규칙 구조는 덮어쓰이지 않습니다.
1단계: 원본 스냅샷 고정
원본 응답을 한 번 저장하고 가져온 시간, 응답 유형, 사용한 대상 커널을 기록하세요. 스냅샷은 점검 중 구독 원본이 변경되어 발생하는 혼란을 배제하는 데 사용됩니다. 저장할 때는 파일 접근 권한을 제한해야 합니다. 노드 인증 정보가 포함될 수 있기 때문입니다.
2단계: 수정하지 않고 파싱
먼저 파서가 구조화된 결과를 출력하도록 하여 인식된 프로토콜, 노드 이름, 필드를 확인하세요. 이 단계에서는 규칙을 추가하거나 일괄 이름 변경을 하지 않습니다. 특정 노드 유형을 인식하지 못한다면 후속 템플릿에서 오류를 숨기지 말고 원본과 대상의 프로토콜 호환성 문제부터 해결해야 합니다.
3단계: 로컬 주 설정에 매핑
노드를 proxy-providers 또는 명시적인 proxies 데이터로 주 설정에 연결한 다음, 로컬 주 설정에서 정책 그룹을 정의합니다. 제공기를 사용할 때는 정책 그룹이 use로 노드 모음을 참조하도록 구성할 수 있어 구독이 바뀔 때마다 그룹 내 목록을 수동으로 수정하는 작업을 줄일 수 있습니다.
proxy-providers:
remote-set:
type: http
url: https://config.example.invalid/profile.yaml
interval: 21600
path: ./providers/remote-set.yaml
health-check:
enable: true
interval: 600
url: https://www.gstatic.com/generate_204
proxy-groups:
- name: PROXY
type: select
use:
- remote-set
proxies:
- DIRECT이 예시는 구조적 관계를 설명하기 위한 것입니다. 실제 사용 시 제공기가 반환하는 콘텐츠는 대상 커널의 요구 사항을 충족해야 하며, 상태 확인 주소, 업데이트 주기, 저장 경로도 네트워크 환경에 맞게 조정해야 합니다. 구독 원본이 제공기 형식이 아닌 완전한 설정만 반환한다면 주소를 proxy-providers에 넣는 것만으로 커널이 노드를 자동 추출할 것이라고 기대할 수 없습니다.
4단계: 세 계층으로 검증
- 문법 계층: YAML 들여쓰기, 목록 계층, 따옴표, 필드 유형이 올바른지 확인하세요. 콜론, 해시 기호 또는 특수 문자가 포함된 이름은 따옴표로 감싸는 것이 좋습니다.
- 참조 계층: 프록시 그룹이 참조하는 노드나 제공기가 존재하는지, 규칙 대상이 존재하는지, 규칙 집합 이름이 제공기와 일치하는지 확인하세요.
- 실행 계층: 시작 후 설정 로드, 제공기 업데이트, DNS 조회, 노드 핸드셰이크, 규칙 매칭 로그를 확인하고 직접 연결과 프록시 트래픽을 각각 테스트하세요.
5단계: DNS와 TUN을 단계별로 활성화
먼저 일반적인 시스템 프록시 또는 명확한 프록시 포트에서 노드와 규칙을 검증하고, 그다음 복잡한 DNS 설정을 활성화한 뒤 필요할 때 TUN을 테스트하세요. 노드 형식, DNS, TUN을 한 번에 변경하면 연결 실패의 원인을 찾기 어렵습니다. 매번 변수 한 그룹만 추가하고 이전에 시작할 수 있었던 설정을 보존하세요.
가져오기 실패와 노드 누락 점검 순서
구독 업데이트에서 파싱 오류가 표시될 때
먼저 오류가 다운로드 단계에서 발생했는지 YAML 파싱 단계에서 발생했는지 확인하세요. 다운로드 단계에서는 상태 코드, 리디렉션, 인증, 응답 본문을 중점적으로 확인하고, 파싱 단계에서는 해당 줄 주변의 들여쓰기, 콜론, 목록 기호, 문자 인코딩을 확인합니다. YAML은 공백으로 계층을 표현하므로 탭이나 어긋난 들여쓰기만으로도 파일 전체를 불러오지 못할 수 있습니다.
가져온 뒤 노드가 보이지 않을 때
응답이 실제로 노드 모음인지 확인하세요. 파일에 proxy-providers 정의만 있다면 이는 노드를 계속 가져오는 방법을 설명할 뿐, 현재 파일 안에 proxies가 이미 존재한다는 뜻은 아닙니다. 파일에 규칙 집합만 있다면 원래 노드가 생성되지 않습니다. 또한 클라이언트에서 완전한 설정 가져오기와 별도 노드 구독 기능이 서로 다른 진입점으로 분리되어 있는지도 확인해야 합니다.
노드는 있지만 정책 그룹이 비어 있을 때
정적 정책 그룹의 proxies 목록에는 노드 이름을 입력해야 하며, 제공기 기반 정책 그룹은 use로 해당 제공기를 참조해야 합니다. 변환기가 노드 이름을 바꾸고 그룹 내부 참조를 업데이트하지 않으면 클라이언트가 대상을 찾을 수 없다고 보고할 수 있습니다. 정규식 필터형 정책 그룹은 필터 표현식도 확인해야 합니다. 필터가 너무 엄격하면 모든 노드가 제외될 수 있습니다.
설정은 시작되지만 모든 연결이 실패할 때
먼저 복잡한 규칙을 우회하고 노드 하나를 직접 선택해 연결을 테스트하세요. 시스템 시간, 서버 도메인 확인, 포트 연결 가능 여부, TLS 서버 이름, 전송 매개변수를 확인합니다. 특정 프로토콜만 실패한다면 변환 전후의 프로토콜 확장 필드를 중점적으로 대조하세요. 모든 노드가 동시에 실패한다면 구독 만료, 네트워크 출구, DNS, 시스템 프록시 인계 상태를 먼저 확인해야 합니다.
규칙 모드에서 트래픽 경로가 예상과 다를 때
규칙 로그를 활성화하고 실제로 일치한 규칙을 확인하세요. 규칙 파일에 ‘있어야 하는’ 항목만 보고 결과를 추측해서는 안 됩니다. 더 앞에 있는 규칙이 이미 일치했을 수 있기 때문입니다. 규칙 집합 업데이트 성공 여부, 규칙 동작 유형, 정책 대상이 예상 그룹을 가리키는지 확인하고 최종 폴백 규칙이 너무 앞에 배치되지 않았는지도 확인하세요.
같은 구독인데 기기마다 결과가 다를 때
클라이언트 버전, 커널 이름, 커널 버전, 구독 가져오기 경로를 비교하세요. 일부 클라이언트는 가져오기 전에 자체 변환을 수행하고, 다른 클라이언트는 YAML을 그대로 커널에 전달합니다. 모바일 기기에서는 백그라운드 업데이트, VPN 인계, 로컬 파일 접근이 제한될 수도 있습니다. 구독 주소만 비교하지 말고 양쪽에서 실제 적용된 설정을 내보내거나 시작 로그를 확인해야 합니다.
Base64 구독을 그대로 Clash 설정으로 사용할 수 있나요?
인코딩 방식만으로는 판단할 수 없습니다. Base64를 디코딩하면 한 줄에 하나씩 된 노드 링크일 수도 있고 YAML이나 다른 텍스트일 수도 있습니다. 클라이언트는 디코딩된 콘텐츠 형식과 그 안에서 사용하는 프로토콜을 모두 지원해야 합니다.
Mihomo 설정을 구형 Clash 커널에 바로 가져올 수 있나요?
기본 필드는 호환될 수 있지만 Mihomo가 확장한 프로토콜, 규칙, DNS, TUN 필드를 구형 커널이 인식하지 못할 수 있습니다. 구형 커널의 지원 범위에 맞게 필드를 삭제하거나 매핑한 뒤 규칙과 연결을 다시 검증해야 합니다.
구독을 변환한 뒤 기존 규칙을 유지해야 하나요?
변환 목적에 따라 다릅니다. 노드 데이터만 필요하다면 로컬 주 설정에서 규칙을 통합 관리할 수 있습니다. 완전한 설정을 이전한다면 규칙 순서, 규칙 집합, 정책 대상 사이의 관계를 유지해야 하며 규칙 텍스트만 복사해서는 안 됩니다.
구독을 업데이트하면 수동 수정 사항이 덮어써지는 이유는 무엇인가요?
다운로드한 구독 파일을 직접 편집하면 다음 업데이트 때 원격 콘텐츠로 다시 작성되는 경우가 많습니다. 기기별 설정은 별도의 주 설정에 두고 원격 노드를 제공기로 참조하거나, 클라이언트가 지원하는 오버라이드 기능을 사용하세요.
형식 식별 최종 체크리스트
구독 변환이 끝나면 다음 순서로 확인할 수 있습니다. 응답이 웹 오류 페이지가 아닌지 확인하고, 실제 콘텐츠 유형을 식별하며, 대상 커널을 확인하고, 프로토콜 필드를 표본 점검한 뒤 노드와 정책 그룹의 참조를 검증합니다. 이어서 규칙 순서를 확인하고 DNS와 TUN을 각각 테스트하세요. 문제가 발생하면 이상이 처음 나타난 계층으로 돌아가고 변환 도구를 계속 바꾸지는 마세요.
대부분의 장기 사용 환경에서 가장 안정적인 구조는 모든 옵션을 원격 구독에 넣는 것이 아니라, 자주 업데이트되는 노드 데이터와 기기별 로컬 설정을 분리하는 방식입니다. 이렇게 하면 구독 변경을 계속 반영하면서도 이미 검증한 규칙 체인, 포트, DNS, 네트워크 인계 방식을 유지할 수 있습니다.