Clash 구독 형식 가이드: YAML 설정, Base64 링크, SIP008 변환 방법

구독 응답 형식부터 확인한 다음 변환 여부를 결정하세요

‘구독 링크’는 클라이언트가 특정 주소에서 콘텐츠를 가져온다는 뜻일 뿐, 그 내용이 반드시 Clash 설정이라는 의미는 아닙니다. 같은 HTTPS 주소에서도 완성된 YAML, Base64로 인코딩된 노드 목록, SIP008 JSON, 로그인 페이지 등이 반환될 수 있습니다. 가져오기에 실패하면 파일 확장자를 바꿔 보기보다 먼저 응답 본문을 확인하세요.

세 가지 층위를 구분해야 합니다. 구독 URL은 콘텐츠를 가져오는 주소이고, YAML·JSON·Base64는 콘텐츠의 구조나 인코딩 방식이며, Shadowsocks·Trojan·VLESS 등은 노드에서 사용하는 프록시 프로토콜입니다. Base64를 디코딩해도 Shadowsocks 노드가 다른 프로토콜로 바뀌거나 규칙 기반 라우팅이 자동으로 생성되지는 않습니다.

콘텐츠 유형	식별 방법	Clash 가져오기 처리
완성된 YAML	일반적으로 `proxies:`, `proxy-groups:`, `rules:`가 포함됩니다	대상 커널과의 호환성을 확인한 뒤 설정으로 가져옵니다
노드 목록 YAML	주로 `proxies:`만 포함하며, 정책 그룹과 규칙은 없습니다	노드 소스로 사용하거나 설정 구조를 보완합니다
Base64 노드 구독	인코딩된 텍스트입니다. 디코딩하면 여러 줄의 `ss://` 링크 등이 나오는 경우가 많습니다	노드를 파싱한 다음 YAML 설정을 생성합니다
SIP008 JSON	일반적으로 `version`과 `servers` 필드가 있습니다	Shadowsocks 서버 필드를 노드로 변환합니다
HTML 또는 오류 JSON	로그인 안내, 접근 거부, 사용량 한도 오류	먼저 구독 접근 문제를 해결해야 합니다. 변환으로 해결할 수 없습니다

Clash YAML: 노드, 정책 그룹, 규칙의 관계

Clash 계열 커널은 YAML로 실행 설정을 표현합니다. 노드는 원격 서버에 연결하고, 정책 그룹은 여러 노드를 수동 선택·자동 지연 시간 측정·장애 조치용으로 묶으며, 규칙은 연결 대상을 순서대로 확인해 트래픽을 지정된 정책으로 보냅니다. 리슨 포트, DNS, TUN은 로컬 네트워크 연결 설정에 해당합니다.

완성된 설정은 노드 목록과 다릅니다

proxies에 노드가 있어도 트래픽이 자동으로 해당 노드를 사용하지는 않습니다. 마지막 규칙이 여전히 MATCH,DIRECT라면 앞선 규칙에 일치하지 않은 연결은 직접 연결됩니다. 규칙이 존재하지 않는 정책 그룹을 참조하면 설정을 불러오지 못할 수 있습니다. 구독 변환 시 노드 이름과 정책 참조를 함께 처리해야 하며, 텍스트 몇 줄을 단순히 이어 붙이는 것으로는 충분하지 않습니다.

아래는 구조를 이해하기 위한 직접 연결 예시이며 원격 프록시 노드는 포함하지 않습니다. 리슨 포트는 7890으로 설정하고 로컬에서만 접속하도록 제한했습니다. 모든 트래픽은 ‘출구 선택’으로 보내지만 그룹에는 DIRECT만 있습니다. 원격 노드의 연결 가능 여부를 확인하는 용도로 사용할 수 없습니다.

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

proxies: []

proxy-groups:
  - name: "출구 선택"
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,출구 선택

YAML 문법과 커널 지원 여부를 각각 확인하세요

들여쓰기에는 탭 대신 공백을 사용하세요. 같은 계층에서는 들여쓰기 간격을 통일하고, 예시처럼 공백 두 칸을 사용하면 됩니다.
노드 이름, 비밀번호, 특수 문자가 포함된 문자열은 다른 자료형으로 해석되지 않도록 따옴표로 묶는 것이 좋습니다.
YAML 파싱에 성공했다는 것은 문법이 올바르다는 뜻일 뿐입니다. 프로토콜 유형, 전송 매개변수, 정책 그룹 옵션은 대상 커널에서도 지원해야 합니다.
기존 Clash와 Clash Meta(현재 이름: mihomo)는 지원 범위가 다릅니다. VLESS, Hysteria2 등의 노드가 포함되어 있다면 대상 커널의 문서를 확인하세요. 클라이언트 이름만으로 호환 여부를 판단할 수 없습니다.

Base64 구독: 디코딩은 텍스트만 복원하며 규칙은 생성하지 않습니다

일반적인 Base64 구독은 여러 공유 링크를 줄마다 나열한 다음 전체 텍스트를 인코딩합니다. 디코딩하면 ss://, trojan://, vmess://, vless:// 등이 나올 수 있습니다. 각 링크의 필드 규칙이 다르므로 변환기는 링크를 하나씩 식별해야 합니다.

안팎으로 인코딩이 두 겹 적용된 경우도 있습니다. 바깥쪽은 구독 목록의 Base64이고, 안쪽은 개별 공유 링크에 들어 있는 인코딩 데이터입니다. 예를 들어 일부 Shadowsocks 링크는 인증 정보를 인코딩하고, 흔히 쓰이는 VMess 공유 링크는 JSON을 Base64로 담습니다. 바깥쪽만 디코딩해도 노드 정보를 전부 읽을 수 있는 것은 아닙니다.

로컬에서 구독 콘텐츠 확인하기

구독 응답을 subscription.txt로 저장한 뒤 로컬에서 디코딩할 수 있습니다. 아래 명령은 일반적인 표준 Base64 텍스트에 사용할 수 있습니다. 출력 파일에는 노드 인증 정보가 들어 있으므로 비공개 폴더에 보관하고 공개 저장소에 올리지 마세요.

# Linux：GNU coreutils
base64 --decode subscription.txt > nodes.txt

# macOS
base64 -D -i subscription.txt -o nodes.txt

도구에서 인코딩이 잘못되었다는 오류가 나오면 먼저 내려받은 콘텐츠가 HTML인지, URL 안전 문자나 패딩 누락 또는 추가 포장이 있는지 확인하세요. 모든 오류를 ‘구독이 잘못됨’으로 단정하지 마세요. 일부 변환기는 이런 변형을 처리할 수 있지만 지원 여부는 구현에 따라 다릅니다.

SIP008: Shadowsocks 서버용 JSON 구독

SIP008은 Shadowsocks 생태계의 구독 규약 중 하나이지, 범용 프록시 프로토콜이나 Clash 설정이 아닙니다. JSON의 서버 배열로 노드를 설명하며, 일반적으로 서버 주소·포트·암호화 방식·비밀번호 필드를 포함합니다. 표준 구조에는 여러 Shadowsocks 서버를 담을 수 있지만, 그렇다고 Clash 정책 그룹이나 라우팅 규칙까지 생기는 것은 아닙니다.

아래 예시는 예약된 예시 도메인으로 필드 간 관계를 보여줍니다. 비밀번호 역시 구조 설명용이며 실제로 연결할 수 있는 서비스에 해당하지 않습니다. 실제 변환 시에는 서비스 제공업체가 지정한 원본 인증 값을 유지하세요.

{
  "version": 1,
  "servers": [
    {
      "id": "80a3cf64-dcec-4ca9-bd7b-b69b9763ca15",
      "remarks": "SS 예시 노드",
      "server": "edge.example.com",
      "server_port": 443,
      "password": "demo-password-not-for-use",
      "method": "aes-128-gcm"
    }
  ]
}

SIP008에서 Clash로 필드 매핑하기

remarks는 일반적으로 Clash 노드의 name으로 사용합니다. 이름이 중복되면 고유하게 바꾸고 정책 그룹의 참조도 함께 수정해야 합니다.
server는 서버 주소로 유지하고, server_port는 port로 매핑합니다.
method는 cipher로 매핑하고, password는 인증 비밀번호로 유지한 뒤 type: ss를 설정합니다.
원본 데이터에 plugin과 plugin_opts가 있으면 대상 커널이 해당 플러그인과 매개변수 형식을 지원하는지 확인해야 합니다. Clash 필드로 그대로 복사할 수는 없습니다.

일부 서버는 사용자 정의 JSON이나 구형 배열 형식으로 응답해 위 구조와 완전히 일치하지 않습니다. 변환 도구에 ‘SIP008 지원’이라고 표시되어 있어도 모든 변형을 처리한다고 볼 수는 없습니다. ‘사용 가능한 노드 없음’이 표시되면 같은 가져오기 작업을 반복하기보다 응답의 최상위 구조와 필수 필드를 확인하세요.

구독 변환 단계: 원본 응답에서 완성된 YAML까지

먼저 원본 서버에서 제공하는 대상 형식을 사용하세요

구독 관리 페이지에서 Clash 또는 mihomo 전용 항목을 제공한다면 해당 항목을 먼저 사용하세요. 변환 단계를 줄이고 서비스 제공업체가 설정한 노드 매개변수를 유지하는 데 도움이 됩니다. 같은 구독 주소도 요청 매개변수나 User-Agent에 따라 다른 형식을 반환할 수 있으므로 브라우저에서 확인한 결과와 클라이언트가 가져오는 결과가 다를 수 있습니다.

변환이 필요하다면 다음 다섯 단계를 따르세요

대상 커널을 확인합니다. 클라이언트의 정보 또는 커널 정보 화면에서 기존 Clash와 mihomo 중 무엇을 사용하는지 확인하세요. 화면 경로는 클라이언트마다 다르므로 실제 표시를 기준으로 판단하고, 클라이언트 외관의 이름을 커널 이름으로 간주하지 마세요.
원본 형식을 식별합니다. 응답의 시작 부분과 구조를 확인해 YAML, Base64, SIP008, 오류 페이지를 구분하세요. 원본 파일은 비교용으로 보관하고 현재 사용하는 설정을 바로 덮어쓰지 마세요.
변환을 실행할 위치를 선택합니다. 신뢰할 수 있는 로컬 도구나 직접 운영하는 서비스를 우선 사용하세요. 웹 양식이라고 해서 로컬에서 처리되는 것은 아닙니다. 양식이 구독 주소를 백엔드로 전송한다면 해당 백엔드가 구독 콘텐츠에 접근할 수 있습니다.
출력 템플릿을 선택합니다. 출력물이 완성된 설정인지, 노드만 포함된 provider 파일인지 확인하세요. 정책 그룹, 규칙, DNS 설정이 요구사항에 맞는지 점검하고 다른 커널용 템플릿을 무작정 적용하지 마세요.
저장하고 검증한 뒤 시험 실행합니다. 결과를 YAML 파일로 따로 저장하고 대상 커널로 테스트한 다음 클라이언트에 가져오세요. 기존 설정은 남겨 두고 연결과 업데이트가 정상임을 확인한 뒤 일상적인 설정으로 전환하세요.

변환기의 ‘Clash’와 ‘Clash Meta’ 대상 옵션은 서로 다른 직렬화 기능을 의미할 수 있습니다. 기존 형식을 선택하면 새 프로토콜이나 전송 매개변수가 누락될 수 있고, mihomo 형식을 선택해도 기존 커널이 새 필드를 이해하는 것은 아닙니다. 출력 형식은 실제로 실행 중인 커널에 맞춰야 합니다.

가져오기 전 확인: 필드 유지, 설정 테스트, 실제 연결

‘파일 생성 성공’이 ‘연결 성공’을 의미하지는 않습니다. 문법과 설정 참조를 먼저 확인하고, 다음으로 노드 핸드셰이크를 확인한 뒤, 마지막으로 규칙 일치와 대상 사이트 접속을 점검하세요. 이렇게 하면 파싱 오류, 인증 오류, 라우팅 오류를 구분할 수 있습니다.

대상 커널로 설정 테스트하기

mihomo 명령줄 프로그램이 설치되어 있다면 변환 결과를 설정 테스트할 수 있습니다. 명령의 converted.yaml은 로컬에 저장한 출력 파일 이름입니다. 현재 디렉터리에 파일이 없다면 실제 파일 경로를 지정하세요.

mihomo -t -f ./converted.yaml

설정 테스트 과정에서 외부 provider나 규칙 리소스를 읽어야 할 수 있으며, 실행 환경도 결과에 영향을 줍니다. 테스트 통과는 해당 검사에서 설정 로드를 막는 문제가 발견되지 않았다는 뜻일 뿐입니다. 서버 인증 성공이나 모든 사이트의 접속 가능성을 보장하지는 않습니다.

누락되기 쉬운 매개변수 확인하기

주소와 포트: server와 port가 모두 있는지 확인하세요. 포트가 443이라고 해서 TLS가 자동으로 활성화되는 것은 아닙니다.
인증 필드: 비밀번호, UUID, 암호화 방식 등 프로토콜에 필요한 정보를 확인하고 이스케이프와 URL 디코딩이 올바르게 되었는지 점검하세요.
TLS 및 전송: SNI, 인증서 검증, ALPN, WebSocket 경로, Host 등의 필드를 확인하세요. 매개변수 오류를 감추기 위해 인증서 검증을 끄지 마세요.
노드 참조: 정책 그룹이 참조하는 노드 이름이 실제로 존재해야 합니다. 노드 이름을 바꿨다면 참조도 함께 수정하세요.
로컬 리슨 설정: 예시의 7890은 로컬 프록시 포트이지 원격 서버 포트가 아닙니다. 이미 다른 프로세스가 사용 중이라면 클라이언트와 앱의 프록시 설정을 함께 변경해야 합니다.

가져온 뒤 노드를 하나 직접 선택하고 연결 로그에서 대상, 일치한 규칙, 출구 정책을 확인하세요. 로그에 DIRECT가 표시되면 먼저 규칙이 트래픽을 프록시 그룹으로 보내는지 확인합니다. 노드가 선택되었는데도 핸드셰이크에 실패한다면 프로토콜 매개변수와 서버 연결 상태를 점검하세요.

지속적인 업데이트: 완성된 설정과 proxy-providers를 별도로 관리하기

한 번 변환해 로컬 YAML로 저장하면 보통 그 시점의 스냅샷만 얻습니다. 서비스 제공업체가 노드를 추가하거나 비밀번호를 바꾸거나 회선을 삭제해도 로컬 파일은 자동으로 동기화되지 않습니다. 유효한 원격 업데이트 경로가 설정되어 있어야 클라이언트나 커널이 새 콘텐츠를 가져올 수 있습니다.

일반적인 방법은 두 가지입니다. 클라이언트가 원격 완성 설정을 주기적으로 업데이트하도록 하거나, 기본 설정에는 정책 그룹과 규칙을 유지하고 proxy-providers로 노드를 업데이트하는 방법입니다. 후자는 로컬 라우팅 설정을 고정하고 싶은 사용자에게 적합하지만, provider와 정책 그룹의 use 참조, 업데이트 주기를 올바르게 설정해야 합니다.

임의의 구독 주소를 provider로 바로 사용하지 마세요

일반 YAML 노드 provider는 대개 proxies: 구조로 노드 정보를 반환해야 합니다. 완성된 설정, Base64 목록, SIP008 JSON은 서로 구분 없이 바꿔 쓸 수 없습니다. mihomo의 provider 지원 범위는 커널 구현에 따라 다르므로 다른 형식을 사용하기 전에 문서와 테스트 결과를 확인하세요.

예를 들어 업데이트 간격을 3600초로 설정하면 한 시간 주기로 업데이트를 시도한다는 뜻이지 매번 요청이 성공한다는 뜻은 아닙니다. 주소가 만료되거나 네트워크에 연결할 수 없거나 변환 서비스에 문제가 생기면 업데이트 로그와 로컬 캐시를 확인해야 합니다. 타이머가 활성화되어 있다는 이유만으로 노드가 최신 상태라고 판단하지 마세요.

자주 묻는 질문: 가져오기 오류, 누락된 노드, 인증 정보 보호

YAML 파싱 오류가 표시되면 어디부터 확인해야 하나요?

먼저 파일의 시작 부분이 HTML, JSON 오류 응답, 미디코딩 텍스트인지 확인한 다음 오류 줄 번호를 기준으로 들여쓰기, 따옴표, 콜론을 점검하세요. HTTP 요청이 200으로 성공해도 로그인 페이지가 반환될 수 있습니다. 상태 코드만으로 설정을 받았다고 판단할 수는 없습니다.

변환 후 노드 수가 줄어드는 것은 정상적인 필터링인가요?

그렇게 단정할 수 없습니다. 먼저 지역이나 이름 필터 조건을 확인하고, 다음으로 대상 형식이 모든 프로토콜을 지원하는지, 마지막으로 중복 이름 제거, 플러그인 매개변수, 파싱 실패 로그를 확인하세요. 노드 감소는 의도적인 필터링일 수도 있고 변환 기능의 한계일 수도 있으므로 원본 데이터와 비교해야 합니다.

노드 링크 하나만으로 구독을 만들 수 있나요?

단일 공유 링크는 보통 노드 하나만 설명하며 원격 업데이트 기능은 포함하지 않습니다. 일부 클라이언트에서는 단일 노드를 추가할 수 있지만 완성된 설정을 가져오는 것과는 다릅니다. 규칙 기반 라우팅을 사용하려면 해당 노드를 정책 그룹과 규칙에 연결해야 합니다.

구독 주소를 이미 제삼자에게 보냈다면 어떻게 해야 하나요?

서비스 제공업체의 관리 페이지에서 기존 구독 토큰을 재설정하거나 폐기하고, 클라이언트에 저장된 주소를 업데이트한 뒤 공개된 기록에서 민감한 정보를 삭제하세요. 로컬 변환 파일만 삭제해도 이미 노출된 접근 권한은 취소되지 않습니다. 노드 비밀번호도 변경해야 하는지는 서비스 제공업체의 인증 방식에 따라 판단하세요.

실제 작업은 네 가지로 정리할 수 있습니다. 입력 형식을 확인하고, 커널에 맞는 출력 형식을 선택하고, 최종 적용 설정을 테스트하고, 구독 인증 정보를 보호하세요. 이 네 가지를 먼저 점검한 뒤 규칙 템플릿과 업데이트 방식을 조정하면 문제를 더 정확히 진단할 수 있습니다.