2026-09-09 선택 가이드 예상 읽기 시간 12분

Clash 구독 링크 형식 가이드: YAML·Base64·URI 노드 변환

Clash YAML 구독, Base64 인코딩 구독, 단일 URI 노드의 구조 차이를 설명하고 구독 변환 원리와 주요 옵션, 변환 후 확인 사항을 안내합니다.

구독 링크, 인코딩, 설정 형식의 차이

구독 링크는 콘텐츠를 가져오는 주소이고, YAML은 설정을 표현하는 데이터 형식, Base64는 인코딩 방식, URI 노드는 개별 프록시를 공유하는 형식입니다. 이 네 가지는 서로 다른 계층의 개념입니다. https://로 시작하는 구독 주소가 반환하는 내용은 완전한 YAML일 수도 있고, Base64로 인코딩된 여러 줄의 노드 링크일 수도 있습니다.

Clash에 가져올 수 있는지 판단할 때는 링크 끝에 .yaml이 붙었는지가 아니라 응답 본문의 구조를 클라이언트 코어가 파싱할 수 있는지가 중요합니다. 일부 서비스는 요청의 User-Agent에 따라 서로 다른 내용을 반환하므로 브라우저에서 확인한 결과와 클라이언트가 구독을 갱신할 때 받는 내용이 다를 수 있습니다.

콘텐츠 유형	주요 특징	포함 정보	사용 방법
전체 Clash YAML	`proxies:`、`proxy-groups:`、`rules:`	노드, 프록시 그룹, 규칙 및 기타 설정	일반적으로 설정으로 가져오기
노드 프로바이더 YAML	주로 `proxies:`를 포함	노드 목록	메인 설정의 `proxy-providers`에서 참조
Base64 구독	긴 인코딩 문자열이며 디코딩하면 여러 줄의 URI가 될 수 있음	대개 노드 매개변수	먼저 인코딩과 노드를 파싱한 뒤 원하는 형식으로 변환
단일 URI	`ss://`, `trojan://` 등	단일 프록시와 선택적 전송 매개변수	해당 프로토콜을 지원하는 가져오기 도구나 변환기 사용

Clash YAML: 전체 설정과 노드 목록

YAML은 키와 값, 들여쓰기로 구조를 표현합니다. 아래는 필드 관계를 설명하기 위한 최소 설정입니다. 로컬 혼합 프록시 포트는 7890, 프록시 서버 포트는 8388이며 서로 용도가 다릅니다. 예시 도메인과 비밀번호는 문법 설명용으로, 실제 접속 가능한 프록시 서비스가 아닙니다.

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

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

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

rules:
  - MATCH,출구 선택

세 가지 핵심 필드의 역할

proxies는 프로토콜, 서버, 포트, 인증 정보 등 연결 매개변수를 정의합니다.
proxy-groups는 노드 선택 방식을 정의합니다. 예시의 select를 사용하면 “예시 SS” 또는 DIRECT를 수동으로 선택할 수 있습니다.
rules는 연결을 어떤 정책에 전달할지 결정합니다. 여기서 MATCH,출구 선택은 마지막 기본 처리 규칙이며, 지역이나 도메인별로 세분화된 규칙이 아닙니다.

proxies만 포함된 YAML은 완전한 설정이 아닙니다. 노드 프로바이더용 데이터 파일로 사용할 수 있습니다. 클라이언트에서 직접 가져올 수 있더라도 완전한 트래픽 분기 정책까지 갖췄다는 뜻은 아닙니다. 자동 완성, 설정 병합, 덮어쓰기 기능은 클라이언트 동작이므로 각각 따로 확인해야 합니다.

YAML 파싱 오류가 나면 먼저 들여쓰기와 문자열을 확인하세요

들여쓰기에는 공백을 사용하고 탭은 섞지 마세요. 노드 이름에 콜론이나 샵 같은 기호가 있다면 특히 따옴표로 감싸는 것이 좋습니다. 비밀번호도 따옴표로 묶어야 일부 문자열이 숫자나 불리언 값으로 해석되는 일을 막을 수 있습니다. 수정한 뒤에는 구조가 올바른지와 코어가 지원하는지를 모두 확인하세요. YAML 파싱에 성공해도 현재 코어에서 모든 프록시 필드를 사용할 수 있는 것은 아닙니다.

Base64와 URI: 디코딩 후 프로토콜 판별

일반적인 Base64 구독은 여러 URI를 줄 단위로 이어 붙인 다음 전체를 인코딩합니다. 변환하려면 먼저 텍스트를 복원한 뒤 각 줄의 프로토콜을 판별해야 합니다. 디코딩 없이 일반 URI 목록을 그대로 반환하는 서비스도 있으므로 모든 구독을 무조건 한 번씩 디코딩해서는 안 됩니다.

Shadowsocks 공유 링크 예시

아래는 흔히 쓰이는 SIP002 형식입니다. 인증 부분은 Base64로 인코딩되고 서버와 포트는 바깥쪽에 그대로 표시됩니다. 인증 부분 YWVzLTEyOC1nY206dGVzdA==를 디코딩하면 aes-128-gcm:test가 됩니다.

ss://[email protected]:8388#demo

ss://는 Shadowsocks 프로토콜을 지정합니다.
인증 부분은 암호화 방식 aes-128-gcm과 비밀번호 test에 해당합니다.
node.example.com:8388은 서버 주소와 서버 포트입니다.
#demo는 표시 이름입니다. 서버 비밀번호가 아니며 구독 서버에 HTTP 요청을 보낼 때 경로 일부로 전달되지도 않습니다.

구형 SS 공유 링크는 서버 주소까지 인코딩 부분에 포함할 수 있습니다. 플러그인을 사용하는 링크에는 plugin 매개변수가 들어갈 수도 있습니다. 모든 변형을 고정된 @ 위치만으로 나눌 수는 없습니다. Trojan, VMess, VLESS도 공유 형식이 서로 다릅니다. 예를 들어 일반적인 VMess 공유 링크의 인코딩된 본문은 SS 형식의 인증 문자열이 아니라 JSON입니다.

한글 이름과 인코딩 변형

노드 이름은 URI 조각의 %E9%A6%99%E6%B8%AF처럼 퍼센트 인코딩되어 있는 경우가 많으며, 이는 “홍콩”을 뜻합니다. 퍼센트 디코딩과 Base64 디코딩은 서로 다른 작업이므로 순서는 해당 프로토콜에 따라 결정해야 합니다. Base64에는 URL 안전 문자 -, _가 사용되거나 끝의 =가 생략될 수도 있습니다. 파서는 이런 변형도 인식해야 하며 등호가 없다는 이유만으로 링크가 손상됐다고 판단해서는 안 됩니다.

구독 변환: 파싱, 매핑, 생성 규칙

변환기는 보통 원본 구독을 가져온 뒤 노드를 내부 데이터 구조로 파싱하고, 마지막으로 원하는 형식으로 출력합니다. 완전한 Clash 설정을 생성할 때는 템플릿을 적용해 프록시 그룹, DNS, 규칙을 추가하기도 합니다. 따라서 “Base64를 YAML로 변환”하는 작업은 단순히 텍스트 포맷을 바꾸는 것이 아니라 필드를 매핑하고 설정을 생성하는 과정입니다.

원본 가져오기: HTTP 상태 코드와 응답 본문을 확인해 로그인 페이지, 만료 안내, 요청 제한 페이지, CAPTCHA 페이지가 아닌지 살펴봅니다.
입력 형식 판별: 전체 YAML, 프로바이더 YAML, 일반 URI 목록, 인코딩된 구독을 구분합니다.
노드 파싱: 프로토콜, 주소, 포트, 인증 정보와 TLS·전송 매개변수를 추출합니다.
대상 형식 선택: 실제 코어에서 지원하는 필드를 출력해야 합니다. 클라이언트 이름에 Clash가 들어 있는지만 보고 판단해서는 안 됩니다.
템플릿 적용: 프록시 그룹과 규칙을 생성하고 노드 이름과 그룹 이름의 참조 관계를 확인합니다.

자주 쓰는 변환 매개변수 이해하기

아래는 일반적인 subconverter 스타일 API를 예로 든 설명입니다. 매개변수는 업계 공통 표준이 아니며 구현과 버전에 따라 기본값이 다를 수 있습니다. 사용 전에 배포된 서비스의 문서를 확인하세요.

매개변수	예시 값	기능 및 주의 사항
`target`	`clash`	출력 형식을 선택합니다. mihomo의 모든 확장 필드까지 지원한다는 의미는 아닙니다.
`url`	URL 인코딩된 원본 주소	원본 주소의 물음표와 앰퍼샌드가 바깥쪽 매개변수와 분리되는 것을 방지합니다.
`list`	`false`	일반적인 구현에서는 목록 출력과 전체 설정 출력을 구분하는 데 사용합니다. 구체적인 출력 내용은 템플릿에도 영향을 받습니다.
`emoji`	`false`	이름에 들어간 국기 기호를 처리하며 서버 위치는 변경하지 않습니다.
`udp`	`true`	관련 UDP 필드에 영향을 주지만, 원래 UDP를 지원하지 않는 연결에 UDP 기능을 추가하지는 않습니다.
`config`	외부 설정 주소	지원되는 구현에서는 템플릿을 불러옵니다. 템플릿 출처, 트래픽 분기 규칙, 최종 출구를 확인해야 합니다.

로컬에 변환 서비스가 설치되어 127.0.0.1:25500에서 수신 중이라고 가정하고, 매개변수의 중첩 인코딩 구조를 살펴보겠습니다. 이 주소는 API 설명용일 뿐 클라이언트를 설치하면 변환 서비스가 자동으로 제공된다는 뜻은 아닙니다.

http://127.0.0.1:25500/sub?target=clash&url=https%3A%2F%2Fsubscription.example.com%2Ffeed%3Ftoken%3Ddemo&list=false&emoji=false&udp=true

내부 주소는 원래 https://subscription.example.com/feed?token=demo입니다. 원본 주소에 &type=all이 있다면 앰퍼샌드도 %26으로 인코딩해야 합니다. 그렇지 않으면 변환 서비스가 이를 자체 매개변수로 처리합니다. 바깥쪽 주소 전체를 다시 인코딩한 뒤 구독 주소로 사용하지 마세요.

변환의 한계: 노드는 내보내도 트래픽 분기 설정은 유지되지 않을 수 있습니다

URI에는 보통 단일 노드가 담기지만 전체 YAML에는 규칙, 프록시 그룹, DNS, TUN, 노드 프로바이더 정의가 포함될 수 있습니다. 전체 YAML을 URI 목록으로 내보내면 이런 전역 설정은 대부분 표현할 수 없습니다. 이후 URI를 다시 YAML로 변환해도 원래 설정이 완전히 복원되는 것이 아니라 새 템플릿으로 만든 설정이 생성됩니다.

새 프로토콜은 코어와 변환기가 모두 지원해야 합니다

Clash 원본 버전, Clash Meta, mihomo는 지원하는 프로토콜과 필드 범위가 서로 다릅니다. 예를 들어 Hysteria2 노드가 원본에 있어도 구형 코어용 변환 대상에서는 유지되지 않을 수 있습니다. 변환기가 입력 프로토콜을 인식하고, 출력기가 해당 필드를 표현할 수 있으며, 실행 중인 코어가 그 필드를 불러와 사용할 수 있어야 합니다.

TLS 매개변수: SNI, 인증서 검증 설정, ALPN을 확인하세요. 가져오기에 성공시키려고 인증서 검증을 임의로 끄면 안 됩니다.
전송 매개변수: WebSocket 경로와 요청 헤더를 유지해야 합니다. 경로를 누락하면 노드는 정상적으로 표시되지만 핸드셰이크가 실패할 수 있습니다.
확장 기능: 멀티플렉싱, 지문, Reality 등의 설정을 하나씩 확인하세요. 이름이 같은 필드라도 모든 코어에서 의미가 같다고 가정해서는 안 됩니다.
이름 참조: 이름을 바꾼 뒤에는 프록시 그룹에서 참조하는 이름도 함께 변경해야 합니다. 노드 이름이 중복되면 검증에 실패하거나 선택 결과가 예상과 달라질 수 있습니다.

원본 서비스가 현재 mihomo 코어와 호환되는 YAML을 제공한다면 해당 형식을 우선 사용하세요. 입력 형식이 호환되지 않거나 템플릿을 통합 관리해야 하거나 여러 출처를 병합해야 하는 경우에만 변환 단계를 추가하면 필드 손실 가능성을 줄일 수 있습니다.

변환 후 확인: 가져오기 성공에서 실제 연결까지

가져오기에 성공했다는 것은 특정 단계의 파싱을 통과했다는 뜻일 뿐입니다. 원본 설정을 보관하고 변환 결과를 새 파일로 저장한 다음 아래 순서대로 검증하세요. 한 번에 교체해 복구할 수 있는 설정까지 잃지 않도록 주의해야 합니다.

노드 수 확인: 예를 들어 원본 구독에 노드가 12개인데 출력 결과에 8개만 남았다면 곧바로 사용하지 말고 필터 조건, 프로토콜 지원 여부, 파싱 로그를 확인하세요.
주요 필드 확인: 노드를 하나 이상 골라 서버, 포트, 프로토콜, 인증 정보, TLS 매개변수를 비교하세요. 이름만 같은 것은 아닌지 확인해야 합니다.
코어 설정 확인: mihomo 명령줄 프로그램을 설치했다면 아래 테스트 명령을 실행할 수 있습니다. 실행 파일 이름과 경로는 로컬 설치 환경에 맞춰 확인하세요.
프록시 그룹 확인: 그룹에 대상 노드가 있는지, 마지막 규칙이 실제로 존재하는 정책을 참조하는지 확인하세요. 템플릿이 실수로 DIRECT로 바꾼 것은 아닌지도 살펴봅니다.
실제 연결 확인: 먼저 노드를 테스트한 다음 연결 목록에서 대상 도메인, 적용된 규칙, 최종 연결 경로를 확인하세요. 한 번의 지연 시간 테스트만으로 모든 웹사이트와 UDP 앱의 작동을 보장할 수는 없습니다.

mihomo -t -f converted.yaml

이 명령은 설정을 테스트할 뿐 원격 서버에 반드시 연결할 수 있다는 것을 보장하지 않습니다. 설정에서 외부 프로바이더나 규칙 리소스를 참조하면 테스트 중 해당 리소스를 불러올 수도 있습니다. 오류에 지원하지 않는 필드가 표시되면 먼저 코어의 지원 여부를 확인하세요. 알 수 없는 프록시 이름이 표시되면 프록시 그룹과 규칙의 참조를 점검하세요. YAML 파싱 오류라면 들여쓰기, 따옴표, 목록 구조부터 확인합니다.

“가져오기는 되지만 연결되지 않을 때” 점검 순서

모든 노드가 동시에 실패함: 네트워크와 구독 만료 여부를 먼저 확인하고, 변환 결과 전체에 잘못된 템플릿이 적용되지 않았는지도 살펴보세요.
특정 프로토콜만 실패함: 해당 프로토콜의 코어 지원 여부, 전송 매개변수, 변환기 버전을 먼저 확인하세요.
노드 테스트는 성공하지만 웹페이지가 열리지 않음: 규칙 적용 여부, DNS 해석, 프로그램이 프록시 경로를 이용하는지 확인하세요.
브라우저는 되지만 게임은 실패함: UDP, 앱의 프록시 방식, TUN 처리 여부를 추가로 점검하세요. 구독 인코딩만 수정해서 해결할 수는 없습니다.

구독 개인정보, 갱신 주소, 자주 묻는 질문

한 번 변환하면 노드가 자동으로 갱신되나요?

로컬 YAML 파일을 가져오면 보통 가져온 시점의 스냅샷만 적용되며 원본 구독에서 새 노드를 자동으로 가져오지 않습니다. 변환된 원격 주소를 가져온 경우에는 클라이언트가 갱신할 때 그 주소를 다시 요청합니다. 원본 구독을 실시간으로 가져오는지는 변환 서비스의 캐시 정책에 따라 달라집니다. 원본 주소, 대상 형식, 템플릿 설정을 기록해 두면 나중에 원본 콘텐츠가 갱신되지 않은 것인지 변환 캐시가 아직 갱신되지 않은 것인지 구분하기 쉽습니다.

브라우저에서 열었더니 왜 알아볼 수 없는 긴 문자열이 나오나요?

본문 대부분이 문자와 숫자, 일부 인코딩 기호로 이루어져 있다면 Base64일 수 있습니다. 로컬에서 디코딩해 내용을 확인하세요. 본문이 HTML 태그로 시작하거나 로그인, 사용량 한도, 접근 제한 안내가 보인다면 유효한 노드 설정이 아닙니다. 오류 페이지를 다시 변환하지 말고 “HTTP 200”만으로 구독이 유효하다고 판단하지도 마세요.

문제 해결을 위해 구독 주소를 다른 사람에게 보내도 되나요?

전체 주소를 그대로 보내지 않는 것이 좋습니다. 인증 정보는 제거하고 프로토콜 이름, 오류 문구, 설정 일부만 공유하세요. 토큰이 이미 공개됐다면 서버에서 구독 주소를 재설정해야 합니다. 로컬 기록만 삭제해도 기존 토큰은 무효화되지 않습니다. 주소를 바꾼 뒤에는 클라이언트와 변환 서비스에 저장된 원본 주소도 업데이트하세요.

실제 선택은 세 단계로 정리할 수 있습니다. 먼저 응답 본문을 판별하고, 다음으로 대상 코어를 확인한 뒤, 마지막으로 변환된 필드와 연결 결과를 점검합니다. 인코딩은 텍스트 표현을, 변환은 형식 간 매핑을, 규칙 템플릿은 트래픽의 경로를 결정합니다. 이 세 가지를 구분하면 문제를 더 명확하게 진단할 수 있습니다.