Clash 구독 링크 가져오기: URL·Base64·YAML 형식 식별 및 처리

먼저 구독 URL, 노드 목록, Clash YAML을 구분하세요

“구독 링크”는 고정된 파일 형식이 아니라 우선 URL입니다. 클라이언트가 URL에 접속한 뒤 서버가 실제 콘텐츠를 반환합니다. 반환 결과는 완전한 Clash YAML, 노드만 포함한 YAML, Base64로 인코딩된 범용 노드 목록일 수도 있고, 웹페이지·JSON 오류 메시지·만료 안내일 수도 있습니다. 바로 가져올 수 있는지는 클라이언트가 최종 반환 콘텐츠를 처리할 수 있는지에 따라 달라집니다.

Clash 및 Clash Meta(현재 일반적으로 mihomo라고 부름) 커널의 설정 입력 형식은 YAML을 기반으로 합니다. 완전한 설정에는 보통 포트, 실행 모드, 노드, 프록시 그룹, 규칙, DNS 등의 필드가 포함됩니다. 일부 그래픽 클라이언트는 가져오기 전에 범용 구독을 식별하고 내장 변환 기능을 호출합니다. 반면 커널이 설정 파일을 직접 읽는 경우에는 일반적으로 파싱 가능한 YAML을 입력해야 합니다.

자주 보이는 세 가지 결과의 핵심 차이

유형	시작 부분 또는 구조적 특징	일반적인 처리 방법
Clash YAML	`proxies:`、`proxy-groups:`、`rules:`	원격 설정으로 가져오거나 YAML 파일로 저장
Base64 노드 목록	연속된 영문자·숫자·`+`·`/`·`=`로 구성되며 본문에 줄바꿈이 거의 없음	먼저 디코딩해 프로토콜을 확인한 뒤 Clash YAML로 변환
범용 URI 목록	`ss://`、`vmess://`、`trojan://`、`hysteria2://`	해당 프로토콜을 지원하는 클라이언트로 가져오거나 원하는 형식으로 변환

Clash 클라이언트에서 구독 URL 가져오기

가져오기 전에 시스템 시간이 정확한지 확인하고 링크가 HTTPS로 정상 접속되는지 확인하세요. 시스템 시간이 몇 분만 달라도 TLS 인증서 검증이 실패할 수 있습니다. 링크를 복사할 때 공백·줄바꿈·한글 문장 부호가 섞여도 요청이 실패합니다. URL은 https://로 시작해야 하며 복사한 뒤 끝에 마침표를 붙이지 마세요.

Clash Verge Rev의 원격 설정 메뉴

Clash Verge Rev 2.3.1 화면을 기준으로 설명하면, 「구독」→「새로 만들기」로 이동한 뒤 유형을 「Remote」로 설정하고 URL 입력란에 주소를 붙여 넣어 확인합니다. 가져오기가 끝나면 설정 카드에서 활성화하세요. 버전에 따라 새로 만들기 메뉴가 더하기 버튼으로 표시될 수 있지만 원격 설정, URL, 업데이트 주기의 의미는 같습니다.

「구독」페이지를 열고 「새로 만들기」 또는 더하기 버튼을 선택합니다.
원격 설정 유형을 선택하고 전체 HTTPS 주소를 붙여 넣습니다.
이름에는 “일상 규칙 설정”처럼 용도를 입력하고 토큰을 이름으로 사용하지 마세요.
저장한 뒤 다운로드와 YAML 파싱이 끝날 때까지 기다린 다음 해당 설정을 현재 설정으로 지정합니다.
「프록시」페이지에서 프록시 그룹 정책을 선택한 뒤 「설정」→「시스템 설정」에서 시스템 프록시를 켭니다.

Clash for Windows의 기존 화면 경로

기존 환경을 계속 유지해야 한다면 Clash for Windows 0.20.39의 경로는 「Profiles」→ 상단 URL 입력란 →「Download」입니다. 다운로드가 완료되면 해당 설정 카드를 클릭해 현재 설정으로 지정해야 합니다. 이 클라이언트는 이미 업데이트가 중단되었으므로 이 경로는 기존 설치를 확인할 때만 참고하세요. 새로 구축할 때는 계속 유지 관리되고 mihomo 커널을 사용하는 클라이언트를 우선 선택하는 것이 좋습니다.

가져온 뒤 “다운로드 성공”만 확인하지 마세요

설정 카드에 업데이트 시간이 표시되는지 확인하세요. 기록 목록에만 나타나는 것은 충분하지 않습니다.
「프록시」페이지에 “노드 선택”, “자동 선택”, “장애 조치”와 같은 예상 프록시 그룹이 표시되는지 확인하세요.
현재 모드를 확인하세요. 규칙 설정은 일반적으로 Global 모드가 아니라 Rule 모드를 사용해야 합니다.
로컬 수신 포트를 확인하세요. 흔히 혼합 포트로 7890을 사용하지만 실제 값은 설정의 mixed-port를 기준으로 해야 합니다.
시스템 프록시를 켠 뒤 시스템 HTTP 및 HTTPS 프록시가 127.0.0.1과 클라이언트의 실제 포트를 가리키는지 확인하세요.

반환 내용으로 구독 형식 확인하기

브라우저에서 구독 URL을 직접 열면 파일이 다운로드될 수도 있고 긴 문자열이 표시될 수도 있습니다. 가장 신뢰할 수 있는 판단 기준은 파일 확장자가 아니라 HTTP 상태, 응답 헤더, 응답 본문입니다. 서버가 .txt 경로를 사용해도 표준 YAML을 반환할 수 있으며, 반대로 config.yaml이라는 주소가 로그인 페이지를 반환할 수도 있습니다.

curl로 상태와 응답 헤더 확인하기

curl -L --compressed -D headers.txt \
  -o subscription.txt \
  "https://sub.example.net/profile?token=demo-token"

-L은 301, 302, 307, 308 리디렉션을 따르고, --compressed는 curl이 지원하는 gzip 및 Brotli 등의 압축 응답을 해제하도록 합니다. -D는 응답 헤더를 별도 파일에 저장합니다. 최종 상태가 200인지 확인한 뒤 Content-Type을 살펴보세요. YAML 응답은 text/yaml, application/yaml, 일반적인 text/plain을 사용할 수 있으므로 MIME 유형은 보조 판단 기준으로만 사용해야 합니다.

완전한 Clash YAML의 구조

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

proxies:
  - name: Example-Trojan
    type: trojan
    server: edge.example.net
    port: 443
    password: sample-credential
    sni: edge.example.net

proxy-groups:
  - name: 노드 선택
    type: select
    proxies:
      - Example-Trojan
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,노드 선택
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택

들여쓰기와 필드가 올바르다면 이러한 내용은 UTF-8로 인코딩된 config.yaml로 저장할 수 있습니다. YAML은 공백으로 계층을 표현하므로 Tab을 들여쓰기로 사용하면 안 됩니다. 이름에 콜론, 샵 또는 앞뒤 공백이 포함되면 따옴표로 감싸는 것이 좋습니다. 설정이 파싱된다고 해서 노드 매개변수가 반드시 유효한 것은 아닙니다. 프로토콜 유형, 포트, TLS, SNI, 인증 정보가 서버 설정과 일치해야 합니다.

노드만 포함한 provider YAML

또 다른 흔한 반환 형식은 최상위에 proxies:만 있고 rules:와 proxy-groups:는 없는 경우입니다. 이는 보통 프록시 제공자 파일이며, 완전한 설정의 proxy-providers에서 참조하기에 적합합니다. 반드시 단독으로 주 설정을 시작할 수 있는 형식은 아닙니다.

proxy-providers:
  remote-nodes:
    type: http
    url: "https://sub.example.net/provider.yaml?token=demo-token"
    path: ./providers/remote-nodes.yaml
    interval: 21600
    health-check:
      enable: true
      interval: 600
      url: https://www.gstatic.com/generate_204

proxy-groups:
  - name: 자동 선택
    type: url-test
    use:
      - remote-nodes
    url: https://www.gstatic.com/generate_204
    interval: 300

여기서 interval: 21600은 21600초, 즉 6시간마다 provider를 업데이트한다는 뜻입니다. 상태 확인은 600초마다 실행되고 프록시 그룹의 속도 측정 주기는 300초입니다. 세 주기는 서로 독립적이므로 속도 측정이 성공했다고 구독까지 업데이트된 것으로 보면 안 됩니다.

Base64 및 범용 노드 구독 처리 방법

Base64는 인코딩 방식이지 프록시 프로토콜이 아닙니다. 여러 줄의 URI를 전송하기 편한 하나의 텍스트로 합칠 때 자주 사용됩니다. 일반적으로 본문은 대소문자, 숫자, 더하기 기호, 슬래시, 끝부분의 등호로 구성되며 URL-safe Base64에서는 하이픈과 밑줄이 사용될 수도 있습니다. 문자 모양만으로 형식을 완전히 판단할 수 없으므로 디코딩한 뒤 내용을 확인해야 합니다.

오프라인에서 디코딩하고 URI 식별하기

macOS 또는 Linux에서는 먼저 응답 파일을 복사한 다음 아래 명령을 실행할 수 있습니다. GNU coreutils에서는 보통 base64 -d를 사용하고, macOS 기본 도구에서는 -D도 지원합니다. 현재 플랫폼의 옵션이 다르면 먼저 base64 --help를 실행해 확인하세요.

base64 -d subscription.txt > decoded.txt
head -n 8 decoded.txt

디코딩 결과는 보통 한 줄에 하나씩 노드 URI가 표시되며, 예를 들어 ss://, trojan://, vmess:// 등이 있습니다. VMess URI의 본문에는 Base64로 인코딩된 JSON이 다시 포함될 수도 있습니다. 파일 전체를 반복해서 디코딩하지 말고, 첫 번째 결과에 이미 읽을 수 있는 프로토콜 접두사가 나타났는지 먼저 확인하세요.

Base64 구독을 항상 Clash 커널에 직접 넘길 수 없는 이유

Clash 설정 로더가 읽는 것은 YAML 구조이고, 범용 Base64 목록은 여러 노드 URI에 불과합니다. 그래픽 클라이언트가 “범용 구독 가져오기” 또는 내장 변환 기능을 제공하면 URI를 proxies 항목으로 자동 변환할 수 있습니다. 반면 mihomo 바이너리를 직접 실행하고 -f로 설정을 지정할 때는 먼저 Clash 또는 mihomo 형식의 YAML을 준비해야 합니다.

서비스 제공자가 “Clash”, “Mihomo”, “Clash Meta” 형식을 모두 제공한다면 해당하는 메뉴를 우선 선택하세요.
변환이 필요하면 서비스 제공자의 형식 변환 기능이나 로컬 변환 도구를 우선 사용하세요.
변환 대상은 커널의 지원 범위에 맞춰야 합니다. VLESS, Reality, Hysteria 2 등의 필드가 포함되어 있다면 mihomo 호환 형식을 선택하세요.
변환 후 노드 수, 프록시 그룹, 규칙, DNS를 확인하세요. 파일이 생성되었는지만 확인해서는 안 됩니다.

업데이트 주기, 캐시, 구독 만료 처리

구독을 매분 새로 고칠 필요는 없습니다. 원격 설정에는 보통 완전한 규칙과 노드 목록이 포함되므로 잦은 요청은 서버 부담을 늘리고 속도 제한을 유발할 수 있습니다. 일반적인 사용에서는 6~24시간마다 한 번 업데이트하도록 설정하세요. 노드 변경이 잦다면 1시간으로 줄일 수 있지만 자동 업데이트 주기를 수십 초로 설정하는 것은 권장하지 않습니다.

자주 쓰는 주기 환산

업데이트 주기	초	적용 환경
1시간마다	`3600`	노드 변경이 잦은 임시 설정
6시간마다	`21600`	일반 원격 provider
12시간마다	`43200`	규칙과 노드 변경이 적은 설정
24시간마다	`86400`	안정적인 완전 설정 구독

수동 업데이트 후에도 이전 노드가 표시됨

목록의 다른 동명 설정이 아니라 현재 활성화된 설정을 업데이트했는지 확인하세요.
클라이언트 로그에서 요청 시간, HTTP 상태, 파싱 오류를 확인하세요.
구독 URL에 대한 브라우저 캐시의 영향을 배제하려면 curl에서 Cache-Control: no-cache 요청 헤더를 추가해 비교하세요.
서버가 CDN을 통해 이전 콘텐츠를 캐시하고 있는지 확인하세요. 응답 헤더의 Age를 보조 지표로 사용할 수 있습니다.
proxy-providers를 사용한다면 주 설정 업데이트 시간만 보지 말고 provider 파일의 업데이트 시간도 확인하세요.
업데이트가 완료되면 프록시 그룹을 다시 선택하세요. 삭제된 노드가 이전 세션에서 잠시 사용 중일 수 있습니다.

HTTP 상태별 점검 방향

401 또는 403: 토큰이 유효하지 않거나 권한이 부족하며, 출처 제한 또는 필수 요청 헤더 문제일 수 있습니다.
404: 경로가 변경되었거나 주소를 복사하는 과정에서 일부 매개변수가 누락되었습니다.
429: 요청이 너무 잦습니다. 업데이트 주기를 늘리고 제한이 해제될 때까지 기다리세요.
500, 502, 503: 서버 또는 upstream에 일시적인 문제가 있습니다. 기존 설정을 유지한 채 잠시 후 다시 시도하세요.
200이지만 파싱에 실패함: 응답이 로그인 페이지, 오류 JSON, Base64 텍스트 또는 호환되지 않는 YAML일 수 있습니다.

YAML 파싱 실패 및 가져온 뒤 인터넷에 연결되지 않음

구독 가져오기 오류는 “다운로드 단계”, “파싱 단계”, “실행 단계”로 나누어 처리해야 합니다. 다운로드 단계에서는 HTTP와 TLS를 확인하고, 파싱 단계에서는 YAML 행 번호와 필드 유형을 확인하며, 실행 단계에서는 노드 핸드셰이크, DNS, 라우팅 규칙, 시스템 프록시를 점검합니다. 세 가지 문제를 섞으면 실제 원인을 찾지 못한 채 구독 주소만 반복해서 바꾸게 됩니다.

자주 발생하는 YAML 오류

들여쓰기 오류: 목록 항목 앞의 공백 계층이 일치하지 않거나 Tab이 섞여 있습니다.
중복 키: 같은 계층에 rules: 또는 dns:가 두 번 나타납니다. 뒤의 항목이 앞의 항목을 덮어쓰거나 엄격한 파싱 오류를 일으킬 수 있습니다.
인용하지 않은 콜론: 노드 이름에 “지역:회선”처럼 콜론이 포함될 때 따옴표를 사용하지 않으면 키-값 구조로 인식될 수 있습니다.
필드 유형 오류: port는 숫자여야 하지만 변환할 수 없는 텍스트로 작성되었습니다. 불리언 값은 true 또는 false를 사용해야 합니다.
커널 비호환: 설정에 mihomo 확장 필드가 포함되어 있지만 클라이언트가 여전히 오래된 Clash 커널을 사용하고 있습니다.

가져오기는 정상인데 브라우저에서 웹페이지가 열리지 않음

현재 프록시 그룹에서 사용 가능한 노드를 선택했는지 확인하세요. 빈 그룹이나 만료된 노드가 선택된 상태가 아니어야 합니다.
시스템 프록시의 수신 주소와 포트가 일치하는지 확인하세요. 설정이 mixed-port: 7890이라면 시스템 프록시는 일반적으로 127.0.0.1:7890을 가리킵니다.
Rule 모드에서 요청이 어떤 규칙과 일치했는지 확인하세요. 마지막의 MATCH 정책은 앞선 규칙과 일치하지 않은 트래픽에 영향을 줍니다.
DNS 설정을 확인하세요. fake-ip를 활성화했다면 해당 애플리케이션의 트래픽이 실제로 커널을 통과하는지 확인해 이름 해석 경로와 연결 경로가 분리되지 않도록 해야 합니다.
시스템 프록시를 따르지 않는 애플리케이션을 가로채야 할 때만 TUN을 켜세요. 켠 뒤 인터넷이 완전히 끊기면 TUN 스택, 라우팅 설치 권한, DNS 하이재킹 설정을 확인해야 합니다.

안정적인 구독 가져오기 설정 절차

처음 설정할 때는 서버가 직접 제공하는 Clash 또는 mihomo YAML을 우선 선택하세요. 가져온 뒤 최근에 정상 작동한 로컬 설정을 하나 보관하면 원격 업데이트에 실패했을 때 빠르게 되돌릴 수 있습니다. 클라이언트가 설정 병합을 지원한다면 개인 규칙, DNS, 스크립트를 로컬 오버라이드 계층에 두어 구독 업데이트 때마다 수동 변경 사항이 덮어써지지 않게 하세요.

구독 URL은 클라이언트 설정에만 사용하고 공개 동기화 저장소에는 넣지 마세요.
완전한 설정과 provider 파일을 분리해 관리하고 각각의 업데이트 주기를 명확히 지정하세요.
노드 이름은 고유하게 유지해 이름은 같지만 매개변수가 다른 노드가 프록시 그룹에서 선택되지 않도록 하세요.
규칙을 수정한 뒤 설정을 다시 불러오고 연결 로그에서 적용된 정책을 확인하세요.
커널 버전을 변경한 뒤 먼저 설정 문법을 검증하고 시스템 프록시 또는 TUN을 켜세요.

구독 형식을 판단하는 핵심은 링크가 어떻게 보이는지가 아니라 최종적으로 무엇을 반환하는지입니다. YAML은 바로 설정 과정에 사용할 수 있고, Base64는 먼저 디코딩해 식별해야 하며, 범용 URI 목록은 호환 클라이언트 또는 신뢰할 수 있는 변환 절차를 통해 대상 YAML로 만들어야 합니다. 다운로드, 파싱, 활성화, 트래픽 가로채기의 네 단계로 점검하면 대부분의 가져오기 문제를 정확히 찾아낼 수 있습니다.