Clash 구독 형식 정리: Base64 노드 목록, YAML 설정, 공유 링크의 차이

구독 URL과 구독 데이터: 주소와 내용을 구분하세요

Clash 구독 URL은 보통 HTTPS 링크입니다. 이 링크는 설정을 가져오는 경로일 뿐, 응답 내용이 반드시 Clash 또는 mihomo 설정 형식에 맞는다는 뜻은 아닙니다. 같은 서비스에서도 일반 노드 구독, Clash 설정, 다른 클라이언트용 형식을 각각 제공할 수 있습니다. 요청 매개변수나 클라이언트의 User-Agent에 따라 응답이 달라지는 서비스도 있습니다.

형식을 확인할 때는 URL의 확장자가 아니라 클라이언트가 내려받은 응답 본문을 살펴보세요. .yaml 확장자가 없는 링크도 완전한 YAML을 반환할 수 있고, 반대로 해당 확장자가 있어도 로그인이 만료되면 HTML 페이지가 반환될 수 있습니다. HTTP 상태 코드 200은 서버가 응답했다는 뜻일 뿐, 설정이 유효하다는 보장은 아닙니다.

자주 쓰이는 세 가지 형식: 공유 링크, Base64 목록, YAML

공유 링크가 완전한 프록시 규칙을 뜻하지는 않습니다

공유 링크 하나로 노드 하나의 정보를 전달할 수는 있지만, 보통 ‘어떤 도메인은 직접 연결할지’ 또는 ‘최종 매칭을 어떤 전략 그룹이 담당할지’까지 지정하지는 않습니다. 예를 들어 TLS, SNI, WebSocket 경로는 노드 연결 매개변수이고, DOMAIN-SUFFIX, GEOIP, MATCH는 Clash 라우팅 설정에 속합니다. 서로 다른 계층의 정보이므로 노드 링크만으로 완전한 규칙을 만들어낼 수 없습니다.

프로토콜마다 링크를 인코딩하는 방식도 다릅니다. 일반적인 vmess:// 링크는 JSON을 인코딩하고, ss://는 과거부터 여러 표현 방식이 사용됐습니다. vless://는 쿼리 매개변수로 전송 설정을 전달하는 경우가 많습니다. 모든 링크를 같은 Base64 구조로 분해하면 필드를 놓치거나 잘못 해석하기 쉽습니다.

Base64는 인코딩이지 암호화가 아닙니다

‘Base64 구독’은 여러 줄의 노드 링크를 통째로 인코딩해 반환하는 형식인 경우가 많습니다. 디코딩은 텍스트를 복원할 뿐, 전략 그룹을 추가하거나 지원되지 않는 프로토콜을 지원되는 프로토콜로 바꾸지는 않습니다. URL 안전 문자를 사용하거나 끝의 패딩을 생략하는 경우도 있으므로, 문자열이 등호로 끝나는지만 보고 Base64인지 판단할 수는 없습니다.

노드 비밀번호와 구독 인증 정보가 인코딩된 내용에 그대로 들어 있을 수 있습니다. 원본 구독, 디코딩한 결과 또는 QR 코드 전체를 공개하면 동일한 접속 정보가 노출될 수 있습니다. 문제를 확인할 때는 로컬 텍스트 도구를 사용하고, 스크린샷을 공유하기 전에는 인증 정보를 가리세요.

mihomo에서 바로 불러올 수 있는 형식과 변환이 필요한 경우

mihomo는 Clash Meta의 후속 프로젝트명입니다. 설정 파일 가져오기에 가장 명확한 입력 형식은 mihomo 설정 구조에 맞는 YAML입니다. 완전한 설정에는 사용할 수 있는 아웃바운드와 매칭 로직이 필요합니다. 프록시 제공자 파일은 메인 설정의 proxy-providers에서 사용하는 파일이므로, YAML이라는 이유만으로 완전한 설정으로 간주해서는 안 됩니다.

• 서비스에서 Clash Meta 또는 mihomo 설정을 제공하는 경우: 우선 해당 형식을 사용하고, 클라이언트 코어가 구독에 포함된 프로토콜과 필드를 지원하는지 확인하세요.
• 서비스에서 Base64 또는 줄 단위 URI만 제공하는 경우: GUI 클라이언트가 해당 형식의 가져오기를 지원하는지 먼저 확인하세요. 지원하지 않는다면 신뢰할 수 있는 변환 도구로 필요한 형식을 출력하세요.
• 프록시 제공자를 사용하는 경우: 현재 mihomo 버전에서 지원하는 제공자 형식에 맞추세요. 다른 페이로드 형식의 지원 여부는 버전에 따라 다를 수 있으므로, 최상위 proxies를 사용하는 YAML로 노드 필드를 명확히 확인하는 편이 좋습니다.
• unsupported proxy type 오류가 발생하는 경우: 실제 실행 중인 코어와 노드 유형, 클라이언트 릴리스 정보를 확인하세요. 파일 변환에 성공해도 실행 중인 코어가 해당 프로토콜을 지원한다는 뜻은 아닙니다.

TUN을 형식 호환 스위치처럼 사용해서도 안 됩니다. TUN 모드는 가상 네트워크 인터페이스로 트래픽을 받아오며, 구독 파싱은 설정을 불러오는 단계에서 이루어집니다. YAML 파싱 오류, 미지원 노드 필드, 전략 그룹 참조 누락은 TUN을 켜도 해결되지 않습니다.

완전한 YAML 설정과 노드 제공자: 파일별 역할

아래는 구조를 이해하기 위한 mihomo 설정 예시입니다. 직접 연결만 사용하며 원격 프록시 노드나 계정 정보는 필요하지 않습니다. 7890은 이 예시에서 사용하는 혼합 프록시 포트입니다. 이 포트가 로컬에서 이미 사용 중이라면 비어 있는 포트로 바꾸고, 해당 포트를 사용하는 앱 설정도 함께 수정하세요.

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

proxies: []

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

rules:
  - MATCH,출구 선택

proxies에는 명시적으로 정의한 노드를 저장하고, proxy-groups에서는 선택할 출구를 구성하며, rules에서는 연결을 어느 출구로 보낼지 정합니다. 규칙의 출구 선택은 전략 그룹 이름과 일치해야 합니다. 노드 목록만 있고 필요한 전략 그룹과 라우팅 규칙이 없다면 완전한 설정과 동일하게 동작하지 않습니다.

제공자 파일은 메인 설정에서 참조합니다

노드를 업데이트하면서 자체 규칙을 유지하려면 노드 목록과 메인 설정을 분리할 수 있습니다. 아래 예시는 ./providers/nodes.yaml 경로의 로컬 파일 제공자를 사용합니다. 이 파일은 메인 설정의 나머지 부분과 함께 사용해야 하며, 완전한 설정으로 간주해 기존 파일을 통째로 덮어쓰면 안 됩니다.

proxy-providers:
  구독 노드:
    type: file
    path: ./providers/nodes.yaml

proxy-groups:
  - name: 노드 선택
    type: select
    use:
      - 구독 노드
    proxies:
      - DIRECT

rules:
  - MATCH,노드 선택

이 로컬 파일의 최상위 YAML에는 proxies 목록이 있어야 하며, 목록에는 현재 코어에서 지원하는 노드 정의를 입력합니다. 상대 경로는 코어의 작업 디렉터리를 기준으로 해석되므로 파일 관리자에서 보이는 설정 파일의 위치와 다를 수 있습니다. GUI 클라이언트는 별도의 데이터 디렉터리를 관리할 수도 있으니 실행 로그와 클라이언트 설정 디렉터리 경로를 확인하세요.

use는 제공자 이름을 참조하며 개별 노드 이름을 참조하지 않습니다. 노드 목록을 바꾸더라도 제공자 이름을 유지하면 메인 설정의 전략 그룹과 규칙을 노드 이름마다 수정할 필요가 없습니다. HTTP 제공자를 사용할 때는 원격 주소, 캐시 경로, 업데이트 간격도 설정하고 구독 형식이 해당 제공자 입력 방식에 맞는지 확인하세요.

구독을 변환할 때는 프로토콜 매개변수와 전략 그룹을 확인하세요

변환 도구는 보통 노드 데이터를 파싱한 뒤 결과를 대상 설정에 반영합니다. 두 번째 단계에서 도구가 미리 설정한 DNS, 규칙, 전략 그룹, 포트가 추가될 수 있습니다. 따라서 노드 수가 같다는 사실만으로 변환이 올바르다고 볼 수는 없습니다. 생성된 설정이 실제로 어떻게 동작하는지도 확인해야 합니다.

1. 출력 형식을 확인하세요. 완전한 설정과 노드 제공자 출력을 구분해야 합니다. proxy-providers로 불러올 예정이라면 제공자에 맞는 출력을 선택하세요. 완전한 메인 설정을 노드 파일로 사용하면 안 됩니다.
2. 주요 연결 매개변수를 확인하세요. 서버 주소, 포트, 인증 정보, TLS 설정, SNI, 전송 방식, WebSocket 경로와 Host를 하나씩 점검하세요. REALITY 노드는 해당 공개 키와 short-id 등의 매개변수도 유지해야 합니다.
3. 이름 참조를 확인하세요. 규칙 대상, 전략 그룹 구성원, 제공자 이름이 서로 일치해야 합니다. 노드 이름을 바꿨다면 해당 노드를 고정 목록으로 참조하는 전략 그룹도 수정하세요. 전략 그룹 이름을 바꾸면 규칙 대상도 함께 바꿔야 합니다.
4. 필터링 결과를 확인하세요. 정규식 필터는 노드 이름이 바뀌면 모든 노드를 제외할 수 있습니다. 먼저 제공자에 실제로 몇 개의 노드가 들어 있는지 확인한 다음, 전략 그룹이 예상한 구성원을 선택하는지 살펴보세요.
5. 전역 설정을 확인하세요. 변환 템플릿이 dns, tun, allow-lan 또는 컨트롤 인터페이스를 변경했는지 살펴보세요. proxies 항목만 확인해서는 안 됩니다.

자체 변환 서비스의 접근 범위 관리

원본 구독 URL을 변환 서비스에 전달하면 해당 서비스가 구독 내용을 읽을 수 있습니다. 직접 운영하는 경우 접근 가능한 출처를 제한하고 인증을 설정하며, 전체 요청 URL이 공개 액세스 로그에 남지 않게 하세요. 임의의 사용자가 가져올 URL을 제출할 수 있는 서비스라면 루프백 주소, 사설 네트워크 주소, 클라우드 환경 메타데이터 주소도 제한해야 합니다. 변환 인터페이스가 내부 네트워크에 접근하는 통로로 악용될 수 있습니다.

중첩된 구독 URL은 URL 인코딩도 고려해야 합니다. 원본 주소에 &, ? 또는 퍼센트 기호가 포함된 상태로 변환 인터페이스의 쿼리 문자열에 붙이면 하나의 구독 URL이 여러 매개변수로 분리될 수 있습니다. 도구가 제공하는 입력 양식이나 올바른 URL 생성 방식을 사용하고, 문자 몇 개를 수동으로 바꾸는 방식으로 전체 링크를 처리하지 마세요.

가져오기 실패 해결: 응답 본문부터 설정 검증까지

1단계: 웹페이지가 반환된 것은 아닌지 확인

클라이언트의 구독 업데이트 로그를 확인하세요. 로그인 페이지, CAPTCHA 페이지, 접근 거부 메시지 또는 HTML 태그가 보인다면 먼저 구독 인증과 서비스 응답 문제를 해결해야 합니다. 401 또는 403은 보통 인증 정보나 접근 제한을 확인해야 합니다. 429가 발생하면 서비스 안내에 따라 요청 빈도를 낮추고 업데이트 버튼을 연속으로 누르지 마세요.

2단계: 구조와 문자 확인

YAML은 공백으로 들여쓰며 Tab은 사용하면 안 됩니다. 목록 항목 앞의 하이픈, 필드 뒤의 영문 콜론, 올바른 들여쓰기 단계가 모두 중요합니다. 노드 이름에 콜론이나 샵 기호가 들어 있다면 따옴표로 감싸 구조나 주석으로 잘못 해석되지 않게 하세요. 오류가 난 줄을 단순히 삭제해 설정을 고치려 해서는 안 됩니다. 뒤에 있는 규칙이 삭제한 항목을 계속 참조할 수 있습니다.

3단계: 실제 사용 중인 코어로 검증

mihomo를 독립 실행하는 경우 설정 검사 옵션으로 파일을 확인할 수 있습니다. 아래 명령은 현재 디렉터리에 config.yaml이라는 설정 파일이 있고 mihomo가 명령 검색 경로에 등록되어 있다고 가정합니다.

mihomo -t -f ./config.yaml

검사로 설정 파싱 오류와 일부 참조 문제를 찾을 수 있지만, 원격 노드가 작동한다는 뜻은 아닙니다. 검사를 통과한 뒤에도 클라이언트에서 선택한 전략을 확인하고 연결 로그를 살펴본 다음 실제 요청을 테스트하세요. GUI 클라이언트가 설정을 덮어쓸 수 있으므로 구독을 다운로드하기 전의 템플릿이 아니라 최종 적용된 설정을 점검해야 합니다.

업데이트 후 규칙이 사라지는 문제: 노드 업데이트와 로컬 설정 분리

완전한 구독 설정은 업데이트할 때 새로 생성되는 경우가 많습니다. 다운로드한 파일에서 rules를 직접 수정하면 다음 업데이트 때 원격 내용으로 덮어써질 수 있습니다. 수정 사항을 계속 유지하려면 클라이언트의 덮어쓰기 또는 병합 기능을 우선 사용하세요. 또는 자체 메인 설정을 관리하고 원격 구독은 노드 제공에만 사용하면 됩니다.

• 가져온 뒤 바로 사용하려는 경우: 서비스에서 명시적으로 제공하는 mihomo 또는 Clash Meta 완전 설정을 선택하고, 전략 그룹과 규칙이 원하는 방식인지 확인하세요.
• 로컬 라우팅 규칙을 유지해야 하는 경우: 자체 규칙과 전략 그룹은 보존하고 제공자로 노드를 업데이트하거나, 클라이언트가 지원하는 지속형 덮어쓰기 기능을 사용하세요.
• DNS 또는 TUN을 수정해야 하는 경우: 최종 적용된 설정에서 해당 필드를 확인하고, 클라이언트가 별도로 설정을 관리하는지 살펴보세요. 서로 덮어쓰는 설정을 두 군데에서 관리하지 않도록 주의해야 합니다.
• 클라이언트를 옮길 예정인 경우: 구독 주소와 로컬 덮어쓰기 설정을 함께 백업하세요. 구독 URL만 복사하면 로컬 규칙, UI에서 선택한 노드, 시스템 프록시 설정은 보통 이전되지 않습니다.

문제 해결 순서는 응답 형식 확인, 가져오기 방식 확인, 코어 지원 여부 확인, 참조 관계 점검, 연결 테스트로 정해 두면 편리합니다. 형식은 데이터를 표현하고, 전략 그룹과 규칙은 트래픽을 분기하며, 시스템 프록시와 TUN은 트래픽을 코어로 전달합니다. 각 계층을 나눠 살펴야 구독을 변환할지, 설정을 조정할지, 네트워크 연결을 점검할지 판단할 수 있습니다.

설정 필드를 더 알아보려면 고급 설정을 확인하세요. 노드, 전략 그룹, 규칙의 차이가 헷갈린다면 먼저 용어 설명을 살펴보세요. 원본 구독 링크는 접근이 제한된 곳에 보관하고, 진단 자료에는 문제 해결에 필요한 필드만 포함하세요.