Clash 구독 형식 비교: YAML 설정, Base64 노드 링크와 형식 변환

먼저 내용을 확인하세요: 구독 주소와 구독 형식은 다릅니다

Clash 구독을 가져오는 데 실패했다면 먼저 서버가 어떤 내용을 반환했는지 확인한 뒤 변환 여부를 결정하세요. https://로 시작하는 구독 주소는 데이터를 가져오는 경로일 뿐입니다. 실제 응답은 전체 YAML, 노드 목록을 Base64로 인코딩한 텍스트, 로그인 페이지 또는 오류 메시지일 수 있습니다. 파일 이름이 clash.yaml이라고 해서 유효한 설정인 것은 아니며, 클라이언트에 ‘구독’ 기능이 있다고 해서 모든 노드 형식을 지원하는 것도 아닙니다.

이 글은 주로 mihomo 커널을 사용하는 Clash 클라이언트를 대상으로 합니다. mihomo는 Clash Meta의 후속 프로젝트에서 사용하는 이름입니다. 기존 Clash 커널과 각 그래픽 클라이언트는 지원하는 프로토콜과 가져오기 경로가 서로 다를 수 있습니다. 클라이언트 이름만 보고 판단하지 말고 ‘커널에서 해당 노드를 사용할 수 있는지’와 ‘화면에서 공유 링크를 파싱할 수 있는지’를 각각 확인해야 합니다.

콘텐츠 유형	식별 단서	포함 정보	가져오기 방법
전체 Clash YAML	`proxies:`, `proxy-groups:`, `rules:` 등의 필드	노드, 프록시 그룹, 라우팅 규칙 및 실행 설정	설정 파일 또는 원격 설정으로 가져오기
노드 제공자 YAML	대개 최상위 항목에 `proxies:`만 있음	노드 목록. 보통 프록시 그룹과 규칙은 포함하지 않음	기본 설정에서 `proxy-providers`로 참조
Base64 범용 구독	인코딩된 텍스트 한 덩어리. 디코딩하면 여러 줄의 공유 링크가 나오는 경우가 많음	각 노드의 연결 매개변수	해당 형식을 지원하는 가져오기 도구나 변환기 사용
개별 공유 링크	`ss://`、`vmess://`、`trojan://`	노드 하나의 프로토콜 매개변수와 메모	노드 가져오기 화면에 붙여 넣거나 YAML 노드로 변환

Clash YAML: 노드와 라우팅 설정을 한 문서에 담습니다

YAML은 구조화된 텍스트 형식이지 노드 프로토콜이 아닙니다. proxies는 노드를 정의하고, proxy-groups는 노드를 프록시 그룹으로 묶으며, rules는 연결을 어떤 정책으로 보낼지 정합니다. 전체 설정에는 mixed-port, dns, tun도 지정할 수 있습니다. 노드 링크를 YAML로 변환할 때 이 설정은 변환 템플릿이나 로컬 설정에 추가해야 합니다.

전체 설정 구조 예시: Shadowsocks 노드 하나

아래는 전체 설정 구조를 보여 주는 예시이며, 그대로 인터넷에 연결할 수 있는 구독은 아닙니다. proxy.example.com은 문서용 예시 도메인이고 비밀번호도 샘플 값입니다. 실제로 사용하려면 서비스 제공업체가 안내한 주소, 포트, 암호화 방식, 비밀번호로 바꿔야 합니다. TUN은 활성화되어 있지 않으며 전용 DNS 설정도 없습니다.

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

proxies:
  - name: SS 예시
    type: ss
    server: proxy.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "password"
    udp: true

proxy-groups:
  - name: 수동 선택
    type: select
    proxies:
      - SS 예시
      - DIRECT

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,수동 선택

7890은 로컬 HTTP/SOCKS 혼합 프록시 포트이고 8388은 원격 노드 포트입니다. 서로 바꿔 쓸 수 없습니다.
노드 정의와 프록시 그룹 참조에 쓰는 SS 예시 이름은 공백까지 완전히 일치해야 합니다.
MATCH는 최종 기본 규칙이므로 구체적인 규칙 뒤에 배치해야 합니다. 여기서는 순서만 설명하며, 중국 본토와 해외를 나누는 전체 라우팅 설정은 아닙니다.
들여쓰기에는 탭 대신 공백을 사용하세요. 특수 문자가 YAML 문법으로 해석되지 않도록 비밀번호는 따옴표로 감싸는 편이 좋습니다.

노드 목록만 있다면 proxy-providers 사용을 고려하세요

라우팅 규칙을 장기간 직접 관리하려면 기본 설정은 고정하고 노드 제공자만 갱신할 수 있습니다. 그러면 구독을 갱신할 때마다 로컬 규칙이 영향을 받는 일을 줄일 수 있습니다. 아래는 기존 기본 설정에 병합할 설정 조각입니다. 로컬 파일 ./providers/nodes.yaml에는 최상위 proxies: 항목과 노드 목록이 있어야 합니다.

proxy-providers:
  로컬 노드:
    type: file
    path: ./providers/nodes.yaml

proxy-groups:
  - name: 구독 선택
    type: select
    use:
      - 로컬 노드

파일 경로는 커널 실행 디렉터리와 클라이언트의 관리 방식에 따라 달라지며 다운로드 폴더가 아닐 수 있습니다. 기본 설정의 규칙이 구독 선택을 가리키도록 해야 합니다. 노드만 들어 있는 파일을 라우팅 규칙까지 설정된 전체 구성으로 취급하지 마세요.

Base64 구독: 인코딩일 뿐 암호화가 아닙니다

일반적인 범용 구독은 여러 줄의 공유 링크를 하나로 합친 뒤 전체 텍스트를 Base64로 인코딩합니다. 디코딩하면 노드 링크 목록이 나오며 Clash YAML이 자동으로 만들어지는 것은 아닙니다. 서비스에 따라 링크를 평문으로 반환하기도 하므로, 모든 구독을 무조건 디코딩하지 말고 먼저 내용을 확인하세요.

디코딩하면 무엇이 나오나요?

아래는 설명용 링크 두 줄입니다. 예시 도메인과 샘플 비밀번호를 사용하므로 연결에 쓸 수 없습니다. 첫 번째 링크의 사용자 정보는 디코딩하면 aes-128-gcm:password가 됩니다. 두 번째 링크의 sni는 TLS 연결에 사용할 서버 이름을 지정합니다.

ss://[email protected]:8388#SS-demo
trojan://[email protected]:443?sni=proxy.example.com#Trojan-demo

로컬에서 구독 텍스트를 확인할 때는 먼저 YAML인지 평문 공유 링크인지 살펴보세요.
Base64 형식임을 확인한 다음 디코딩하세요. URL-safe 문자 집합을 사용하거나 끝의 패딩 문자를 생략하는 변형도 있으므로 가져오기 도구가 이런 차이를 처리해야 합니다.
각 줄의 프로토콜을 확인하고 서버, 인증 정보, 전송 방식 등의 매개변수를 YAML 노드에 대응시키세요.
프록시 그룹과 규칙을 추가하고 대상 커널이 모든 필드를 지원하는지 확인한 뒤 클라이언트에 가져오세요.

디코딩에 실패한 원인은 HTML 페이지를 받았기 때문일 수도 있습니다. 요청이 로그인 페이지로 리디렉션되었거나 서버에서 요청 제한 안내를 반환했을 수 있습니다. 이때는 디코딩을 반복하지 말고 구독 만료 여부, 응답 상태, 반환된 내용을 확인하세요. 확장자를 바꾸거나 여러 번 인코딩해도 서버 측 인증 문제는 해결되지 않습니다.

ss·vmess·trojan: 변환 시 반드시 보존해야 할 필드

공유 링크의 형식은 하나로 통일되어 있지 않습니다. 같은 프로토콜도 링크 표기가 여러 가지일 수 있고, 변환기마다 지원하는 쿼리 매개변수가 다릅니다. 변환이 제대로 됐다는 것은 문법 오류가 없는 YAML이 만들어졌다는 뜻만이 아니라 연결 의미가 보존됐다는 뜻이어야 합니다.

프로토콜	주요 YAML 필드	빠뜨리기 쉬운 매개변수
Shadowsocks	`type: ss`、`server`、`port`、`cipher`、`password`	플러그인 유형과 `plugin-opts`, 새 암호화 방식의 커널 지원 여부
VMess	`type: vmess`、`uuid`、`alterId`、`cipher`	`network`, `tls`, `servername`, WebSocket 경로 및 Host
Trojan	`type: trojan`、`server`、`port`、`password`	`sni`, `alpn`, 전송 방식 및 인증서 검증 설정

Shadowsocks: 두 단계의 인코딩을 혼동하지 마세요

일반적인 SIP002 링크는 @ 앞의 사용자 정보를 인코딩하며, 구형 공유 링크는 더 긴 문자열을 인코딩할 수 있습니다. 범용 구독은 여기에 Base64 인코딩을 한 겹 더 적용하기도 합니다. ‘구독 전체의 인코딩’과 ‘개별 링크 내부의 인코딩’을 구분해야 합니다. 링크에 플러그인 매개변수가 있다면 주소와 비밀번호만 복사할 경우 연결에 필요한 전송 설정이 빠질 수 있습니다.

VMess: JSON 디코딩 후에도 필드 매핑이 필요합니다

일반적인 vmess:// 링크에는 Base64로 인코딩된 JSON이 들어 있습니다. 여기서 add는 보통 서버, id는 UUID, aid는 alterId, net은 전송 방식에 해당합니다. 최신 VMess AEAD 설정에는 보통 alterId: 0을 사용하지만, 과거 설정을 무조건 이 값으로 바꾸면 안 됩니다.

원본 노드가 WebSocket을 사용한다면 ws-opts.path와 ws-opts.headers.Host를 확인하세요. TLS 서버 이름과 WebSocket Host는 용도가 다릅니다. 값이 우연히 같다고 해서 하나로 합치면 안 됩니다. gRPC를 사용한다면 grpc-opts.grpc-service-name도 확인해야 합니다. 노드 이름보다 변환 도구가 이 값을 보존하는지가 더 중요합니다.

Trojan: URI 매개변수를 올바르게 디코딩해야 합니다

비밀번호나 메모에 특수 문자가 포함되면 공유 링크에서 퍼센트 인코딩을 사용할 수 있습니다. 가져오기 도구는 URI 규칙에 따라 먼저 파싱해야 하며, 모든 텍스트를 콜론이나 샵 기호로 단순히 나누면 안 됩니다. 변환 후에는 비밀번호, SNI, ALPN이 보존됐는지 확인하세요. 인증서 오류가 발생하면 시스템 시간과 서버 이름부터 확인하고, skip-cert-verify: true를 기본 해결책으로 사용하지 마세요.

형식 변환: 노드는 내보낼 수 있어도 규칙은 복원되지 않을 수 있습니다

‘Base64 구독을 Clash로 변환’하는 작업은 보통 노드를 추출한 다음 설정 템플릿을 적용합니다. ‘Clash를 범용 구독으로 변환’하면 대개 공유 링크로 표현할 수 있는 노드만 내보냅니다. 두 작업은 완전한 역변환이 아닙니다. 프록시 그룹, 규칙 순서, DNS, TUN 설정, 일부 커널 전용 매개변수는 일반 공유 링크에 대응하는 필드가 없는 경우가 많습니다.

변환 방식 선택 순서

전용 형식을 우선 사용: 서비스 제공업체의 구독 관리 페이지에서 대상 커널이 지원하는 Clash/mihomo 형식을 선택해 변환 단계를 줄이세요.
노드가 몇 개 안 되면 직접 입력: 프로토콜 필드를 하나씩 확인하며 입력하세요. 노드 한두 개를 다루거나 TLS 및 전송 매개변수를 꼼꼼히 검토할 때 적합합니다.
여러 노드는 로컬에서 변환: 도구가 원본 프로토콜과 대상 커널을 지원하는지 확인하세요. 변환 후에는 노드 수와 필드, 경고 메시지를 점검해야 합니다.
온라인 변환 시 인증 정보에 주의: 서비스 운영 주체와 데이터 처리 방식을 확인하세요. 토큰이 포함된 구독 주소를 공개 문서나 공개 설정 저장소에 넣지 마세요.

노드 12개를 입력했는데 결과가 9개뿐이라면 무시된 프로토콜, 중복 이름 처리, 필터 조건부터 확인하세요. 이전 설정을 바로 덮어쓰지 마세요.
모든 노드의 이름을 같게 바꾸면 프록시 그룹 참조가 꼬일 수 있습니다. 이름을 변경할 때는 그룹 내부의 참조도 함께 확인하세요.
원격 proxy-providers를 사용하는 설정은 내보내기 과정에서 제공자에 포함된 노드가 자동으로 펼쳐지지 않을 수 있습니다. 도구가 실제로 어떤 데이터를 읽었는지 확인하세요.
변환 템플릿을 바꾸면 규칙과 프록시 그룹도 달라질 수 있습니다. 비교하고 복원할 수 있도록 변환 전 설정을 로컬에 보관하세요.

‘직접 만든 규칙은 유지하고 서비스 제공업체의 노드만 갱신’하려면 매번 전체 설정을 변환하는 대신 노드 제공자나 클라이언트의 오버라이드 기능을 고려하세요. 클라이언트에서 원격 설정을 직접 수정할 때도 주의해야 합니다. 다음 구독 업데이트에서 수정 사항이 덮어써질 수 있습니다.

가져오기 및 문제 해결: 먼저 형식을 확인하고 연결을 점검하세요

Clash Verge Rev의 일반적인 화면을 예로 들면, 전체 원격 설정은 ‘구독’ → ‘새로 만들기’에서 구독 URL을 입력한 뒤 저장하고 업데이트하여 해당 설정을 선택합니다. 로컬 YAML은 같은 페이지의 파일 가져오기 기능으로 추가할 수 있습니다. 버튼 이름은 버전에 따라 다를 수 있으니 현재 화면을 기준으로 확인하세요. 다른 클라이언트에서는 해당 페이지를 ‘설정’ 또는 ‘Profiles’라고 부를 수 있습니다. 개별 노드 가져오기와 전체 설정 가져오기는 서로 다른 기능입니다.

가져온 후 네 단계로 확인하세요

설정이 활성화됐는지 확인: 구독 또는 설정 페이지에서 현재 선택된 항목을 확인하세요. 다운로드에 성공했더라도 커널이 설정을 불러왔다는 뜻은 아닙니다.
파싱 결과 확인: ‘프록시’ 페이지에서 프록시 그룹과 노드 수를 확인하고 사용할 노드를 선택하세요. 그룹이 비어 있다면 노드 참조나 제공자 로딩에 문제가 있을 수 있습니다.
로컬 프록시 포트 확인: 설정에서 실제 혼합 포트를 확인하세요. 이 글의 예시는 127.0.0.1:7890이지만 클라이언트에 따라 다른 포트를 사용할 수 있으므로 그대로 덮어쓰지 마세요.
로그 확인: 먼저 YAML 파싱 오류, 존재하지 않는 프록시 이름, 제공자 읽기 오류를 해결한 다음 인증 실패, TLS 오류, 연결 시간 초과를 점검하세요.

증상	먼저 확인할 항목	해결 방법
YAML 파싱 오류가 표시됨	다운로드한 내용이 HTML인지, 들여쓰기에 탭이 섞였는지	올바른 형식을 다시 가져오고 오류가 발생한 줄 번호를 기준으로 구조 수정
존재하지 않는 프록시라고 표시됨	프록시 그룹이나 규칙에서 참조하는 이름	노드, 프록시 그룹, 제공자 이름을 하나씩 대조
가져오기는 됐지만 모든 노드 연결에 실패함	비밀번호, UUID, TLS 서버 이름 및 전송 매개변수	원본 링크와 항목별로 비교하고 라우팅 규칙은 먼저 변경하지 않기
구독을 업데이트한 뒤 사용자 지정 규칙이 사라짐	원격 설정 내용을 직접 수정했는지	클라이언트 오버라이드 기능을 사용하거나 로컬 기본 설정에서 규칙 관리
변환기에서 일부 노드를 건너뜀	원본 프로토콜 지원 여부, 출력 로그 및 필터 조건	해당 프로토콜을 지원하는 변환 방식으로 바꾸거나 직접 입력

자주 묻는 질문: 확장자 변경, QR 코드, 구독 업데이트

Base64 텍스트의 확장자를 .yaml로 바꾸면 바로 가져올 수 있나요?

파일 이름만 바꿔서는 변환되지 않습니다. 먼저 디코딩해 노드를 파싱한 다음 대상 커널에 맞는 YAML을 생성해야 합니다. 클라이언트에 범용 구독 파서가 내장되어 있다면 해당 기능으로 처리할 수 있지만, 공유 링크를 YAML 파서가 기본적으로 받아들이는 것은 아닙니다.

QR 코드와 공유 링크는 어떤 관계인가요?

QR 코드에는 보통 공유 링크가 텍스트로 저장되며 구독 URL이 들어 있을 수도 있습니다. 스캔한 뒤 개별 노드 링크인지 원격 구독 주소인지 확인하고 알맞은 가져오기 경로를 선택하세요. QR 코드 이미지에도 비밀번호나 토큰이 노출될 수 있으므로 공개하기 전에 텍스트 인증 정보와 마찬가지로 주의해서 처리해야 합니다.

로컬 파일로 변환한 뒤에도 노드가 자동으로 업데이트되나요?

한 번 생성한 로컬 YAML은 원본 구독이 바뀌어도 자동으로 이를 감지하지 못합니다. 다시 변환해 가져오거나, 주기적으로 가져올 수 있는 원격 설정이나 HTTP 노드 제공자를 사용해야 합니다. 자동 업데이트가 계속 작동하는지는 클라이언트에 저장된 업데이트 주소와 실행 방식에 달려 있습니다. 파일에 ‘구독’이라는 단어가 있는지는 관계없습니다.

최종 저장 형식은 어떻게 선택하나요?

노드, 프록시 그룹, 라우팅 규칙을 함께 사용하려면 전체 Clash/mihomo YAML을 저장하세요. 규칙을 장기간 직접 관리하려면 기본 설정을 저장하고 노드 제공자를 별도로 관리하세요. 호환되는 클라이언트 사이에서 노드만 옮길 때는 공유 링크나 범용 구독을 사용하면 됩니다. 어떤 정보가 필요한지에 따라 선택해야 하며, 인코딩이 복잡해 보이는지를 기준으로 삼을 필요는 없습니다.