Clash 구독 링크 형식 가이드: YAML 설정, Base64 노드 목록과 형식 변환

구독 응답 내용부터 확인하세요. 링크 확장자만 보면 안 됩니다

구독 링크는 클라이언트가 콘텐츠를 가져오는 주소일 뿐, 주소 자체가 설정 형식을 뜻하지는 않습니다. https://로 시작하는 같은 URL이라도 바로 불러올 수 있는 Clash YAML을 반환할 수도 있고, 긴 Base64 문자열을 반환할 수도 있습니다. 로그인 페이지나 오류 메시지가 표시되는 주소도 있습니다. 클라이언트에서 가져오기에 실패했다면 구독 이름을 계속 바꾸기보다 링크에 접속할 수 없는 문제인지, 응답 내용이 해당 가져오기 기능에서 지원하는 형식이 아닌지 먼저 구분하세요.

일반적으로 마주치는 콘텐츠는 크게 세 가지입니다. 전체 YAML 설정, 인코딩된 노드 목록, 그리고 ss:// 같은 단일 노드 공유 링크입니다. 각 형식에 담을 수 있는 정보의 범위가 다르므로 노드가 들어 있다는 이유만으로 같은 설정으로 취급하면 안 됩니다. 특히 프록시 그룹과 규칙이 중요합니다. 노드 목록은 연결할 수 있는 프록시를 설명하지만, 전체 설정은 트래픽이 어떤 프록시를 사용할지도 정합니다.

전체 YAML: 노드뿐 아니라 트래픽 경로 설정도 포함

Clash 설정 파일에는 일반적으로 .yaml 또는 .yml 확장자를 사용합니다. 파일에서 proxies는 노드를, proxy-groups는 수동 선택이나 자동 테스트 등의 정책 그룹을 정의하고, rules는 규칙 모드에서 트래픽에 적용할 조건을 정합니다. mixed-port 같은 필드는 로컬 수신 포트를 설정합니다. YAML은 들여쓰기로 계층 구조를 표현하므로 목록 항목 앞의 하이픈과 필드가 놓인 계층에 따라 파싱 결과가 달라집니다.

다음은 구조를 보여 주기 위한 최소 예시입니다. 127.0.0.1:1080은 로컬 컴퓨터에서 이미 실행 중인 SOCKS5 상위 서버를 뜻합니다. 해당 서비스가 없다면 이 예시는 외부 연결에 사용할 수 없습니다. 7890은 예시 설정의 로컬 혼합 포트이며, 모든 클라이언트가 이 포트를 사용하는 것은 아닙니다.

mixed-port: 7890
mode: rule

proxies:
  - name: 로컬 데모
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: 수동 선택
    type: select
    proxies:
      - 로컬 데모
      - DIRECT

rules:
  - MATCH,수동 선택

규칙 모드에서 예시의 MATCH는 다른 규칙에 매칭되지 않은 연결을 “수동 선택” 그룹으로 보냅니다. 그룹에서 DIRECT를 선택하면 해당 연결은 프록시를 거치지 않고 직접 연결됩니다. 실제 설정을 가져온 뒤에는 노드 목록에 항목이 표시되는지만 확인하지 말고, 클라이언트에 정책 그룹과 규칙이 제대로 나타나는지도 살펴보세요. 설정에 proxy-providers가 있다면 제공자 주소가 업데이트되는지, 현재 클라이언트와 그 코어가 설정에 사용된 필드를 지원하는지도 확인해야 합니다.

“YAML”은 파일 구문을 가리킬 뿐, 내용이 실행 가능한 전체 설정임을 보장하지는 않습니다. 예를 들어 proxies:만 있는 YAML 노드 목록은 프록시 제공자에서 참조하기에는 적합할 수 있지만, 단독 설정으로는 트래픽을 분산하지 못할 수 있습니다. 반대로 DNS, 규칙, 정책 그룹이 포함된 전체 설정은 파일명에 .yaml 확장자가 없어도 클라이언트가 YAML로 읽고 내용이 유효하다면 정상적으로 불러올 수 있습니다.

Base64 노드 목록: 먼저 디코딩한 뒤 프로토콜을 확인하세요

Base64는 텍스트 인코딩 방식이지 프록시 프로토콜이 아닙니다. 흔히 쓰이는 Base64 구독은 여러 공유 링크를 한 줄씩 나열한 다음 전체 텍스트를 하나의 문자열로 인코딩합니다. 디코딩한 뒤에는 각 줄의 프로토콜 접두사와 매개변수를 확인하세요. 인코딩된 긴 문자열을 config.yaml에 그대로 붙여 넣으면 안 됩니다. 인코딩 문자열을 proxies: 아래에 넣어도 YAML 노드 객체가 자동으로 생성되지는 않습니다.

이런 목록에는 보통 서버, 포트, 인증 매개변수와 노드 이름이 포함되지만, Clash의 proxy-groups, rules 또는 로컬 mixed-port 설정은 제공하지 않습니다. 클라이언트에 별도의 “노드 구독” 기능이 있다면 목록을 노드로 파싱해 기존 설정에 추가할 수 있습니다. “설정 가져오기” 기능만 있다면 사용할 수 있는 Clash 설정을 받거나, 로컬에서 변환한 뒤 정책 그룹과 규칙을 보완해야 합니다. 기능 이름은 사용 중인 클라이언트의 실제 화면을 기준으로 확인하세요.

• proxies:로 시작하는 경우: YAML 형식으로 들여쓰기, 필드, 대상 코어와의 호환성을 먼저 확인하세요.
• 전체가 인코딩된 문자열인 경우: 먼저 실제 Base64 텍스트인지 확인한 다음 디코딩된 내용을 줄별로 살펴보세요. URL의 파일명만 보고 판단하지 마세요.
• 디코딩 결과에 ss:// 등의 링크가 여러 줄로 나타나는 경우: 노드 목록이지, 완성된 트래픽 분산 설정이 아닙니다.
• HTML 페이지나 로그인 안내가 반환되는 경우: 먼저 구독 접근 권한, 로그인 상태 또는 만료된 URL 문제를 해결하세요. 파일 확장자를 바꿔도 반환 내용은 달라지지 않습니다.

헷갈리기 쉬운 경우가 하나 더 있습니다. 단일 공유 링크에도 일부 매개변수가 인코딩되어 있을 수 있지만, 여전히 노드 하나만 설명합니다. Base64 문자가 보인다고 해서 “Base64 구독”이라고 단정하면 안 됩니다. 먼저 가장 바깥 형식을 확인하세요. 인코딩된 여러 줄 목록인지, 프로토콜 접두사가 붙은 공유 링크 한 개인지 살펴보면 됩니다.

단일 노드 링크: 연결 정보를 공유할 수 있지만 전체 구독을 대신하지는 않습니다

ss://, vmess://, trojan:// 등의 접두사는 서로 다른 프로토콜의 공유 링크를 나타냅니다. 링크 하나는 보통 노드 하나에 해당합니다. 클라이언트가 클립보드에서 링크를 인식해 가져오더라도, 해당 노드를 어떤 정책 그룹에 넣을지, 어떤 도메인을 직접 연결할지, DNS를 어떻게 설정할지까지 이 링크 하나로 알 수는 없습니다. 노드를 수동으로 추가한 뒤에는 현재 설정의 정책 그룹에서 해당 노드를 참조하는지도 확인해야 합니다.

프로토콜 접두사로 유형을 짐작할 수는 있지만 호환성까지 보장되지는 않습니다. 원본 Clash와 Clash Meta(mihomo)는 지원하는 프로토콜과 설정 필드의 범위가 다릅니다. 예를 들어 vless:// 링크를 발견해도 원본 Clash에서 바로 사용할 수 있다고 가정하면 안 됩니다. mihomo를 사용하더라도 실제 코어 버전, 프로토콜 매개변수, 클라이언트의 가져오기 기능을 확인해야 합니다. 클라이언트가 공유 링크를 인식하지 못하는 문제와 코어가 변환된 노드 필드를 지원하지 않는 문제는 서로 다른 단계입니다. 문제를 진단할 때 오류를 각각 기록하세요.

형식 변환: 필드를 보존하고 트래픽 경로 설정을 보완하세요

변환은 .txt를 .yaml로 바꾸는 것만으로 끝나지 않습니다. 노드 목록을 Clash 설정으로 변환하려면 각 링크를 해당하는 proxies 객체로 바꿔야 합니다. 이후 정책 그룹 이름, 노드 소속, rules 처리 방식도 정해야 합니다. 전체 YAML에서 노드 목록을 내보내는 것은 반대로 정보를 줄이는 작업입니다. 프록시 그룹, 규칙, DNS 설정, 로컬 포트는 보통 단일 노드 링크에 함께 저장되지 않습니다.

변환 전에 네 가지 정보 확인

1. 프로토콜 필드: 서버, 포트, 인증 방식은 물론 프로토콜에 필요한 전송 및 TLS 매개변수도 확인하세요. 필드 하나만 빠져도 “노드는 표시되지만 연결은 실패하는” 상황이 생길 수 있습니다.
2. 노드 이름: 변환 후 이름이 중복되지 않는지 확인하세요. 정책 그룹이 이름으로 노드를 참조하는 경우, 이름이 겹치거나 바뀌면 기존 선택이 의도한 노드를 가리키지 않을 수 있습니다.
3. 그룹과 규칙: 변환 결과에 proxy-groups와 rules가 실제로 포함되어 있는지 확인하세요. proxies만 생성됐다면 전체 설정이 아니라 노드 목록으로 봐야 합니다.
4. 대상 코어: 실행할 Clash 또는 mihomo에 맞는 출력 형식을 선택하세요. 변환 도구가 필드를 생성하더라도 현재 코어가 해당 필드를 파싱하거나 사용할 수 있다는 뜻은 아닙니다.

정기적으로 업데이트해야 한다면 한 번 변환한 파일과 구독에 따라 업데이트되는 설정을 구분하세요. 특정 시점의 구독 내용을 로컬 YAML에 복사하면 당시의 노드 상태만 저장됩니다. 이후 원본 제공자가 노드나 인증 정보를 변경해도 로컬 파일은 자동으로 갱신되지 않습니다. 클라이언트의 URL 설정 업데이트 기능을 사용한다면 업데이트 후에도 필요한 그룹과 규칙이 유지되는지 확인하세요. 프록시 제공자를 사용한다면 제공자 업데이트 결과와 이를 참조하는 정책 그룹도 살펴보세요.

변환 결과는 세 단계로 확인할 수 있습니다. 먼저 클라이언트가 YAML을 불러올 수 있는지 확인하고, 다음으로 정책 그룹에 예상한 노드가 표시되는지 살펴본 뒤, 마지막으로 규칙 모드에서 실제 연결을 테스트해 경로를 확인하세요. 설정을 불러왔다는 것은 현재 클라이언트가 형식을 파싱했다는 뜻일 뿐, 노드 매개변수와 상위 서비스, 규칙 적용 결과까지 모두 정상이라는 의미는 아닙니다. 테스트 전 선택된 그룹 구성원을 기록하고, 테스트 후 연결 로그와 비교하면 DIRECT를 잘못 선택한 일을 구독 오류로 오해하는 상황을 피할 수 있습니다.

가져오기에 실패하면 콘텐츠, 파싱, 연결 순서로 확인하세요

1단계: 콘텐츠를 가져왔는지 확인

클라이언트의 “설정” 페이지에서 URL로 가져올 때는 주소가 완전한지, 계정에 아직 접근 권한이 있는지, 업데이트 중 네트워크 오류가 발생했는지 먼저 확인하세요. 브라우저에서 페이지가 열린다고 해서 클라이언트 요청에도 같은 설정 내용이 반환되는 것은 아닙니다. 로그인 페이지, 리디렉션된 안내 페이지, 만료 안내는 YAML이 아닙니다. 문제를 진단할 때는 응답의 첫 부분을 확인하고, 스크린샷에 구독 URL의 토큰이 노출되지 않도록 주의하세요.

2단계: 예상한 형식으로 파싱되는지 확인

YAML 오류가 표시되면 들여쓰기에 탭이 섞였는지, 콜론 뒤에 공백이 있는지, 목록 항목이 올바른 계층에 있는지 확인하세요. 가져온 뒤 노드만 보이고 규칙과 정책 그룹이 없다면 원본이 애초에 노드 목록이었는지 살펴보세요. 지원하지 않는 프로토콜이나 필드라는 오류가 표시되면 클라이언트 버전과 코어 이름을 기록하고 구독의 대상 형식과 비교하세요. 코어 호환성 문제를 해결하려고 파일 이름을 반복해서 바꾸지 마세요.

3단계: 노드와 트래픽 경로가 작동하는지 확인

노드가 보이면 먼저 현재 정책 그룹에 포함되어 있는지 확인한 다음, 규칙 모드에서 실제로 어떤 규칙이 적용되는지 살펴보세요. 시스템 프록시는 일반적으로 시스템 프록시 설정을 사용하는 앱의 트래픽을 처리합니다. 다른 트래픽까지 처리해야 하는 경우 일부 클라이언트에서 TUN 모드를 제공합니다. 하지만 TUN 권한, DNS, 라우팅 설정은 별도로 구성해야 하며 구독 형식 변환으로 자동 보완되지 않습니다. 노드는 연결되는데 앱 트래픽이 예상한 정책 그룹을 거치지 않는다면 클라이언트 모드, 시스템 프록시 또는 TUN 상태, 실제로 적용된 규칙을 각각 확인하세요.

형식을 선택하는 원칙은 간단합니다. 트래픽 분산 설정까지 바로 불러오려면 현재 코어에 맞는 전체 YAML을 우선 사용하세요. 기존 설정에 노드 여러 개만 추가하려면 클라이언트가 지원하는 노드 목록 또는 프록시 제공자 기능을 사용하세요. 연결 정보 하나만 공유하려면 해당 프로토콜의 단일 노드 링크를 사용하면 됩니다. 콘텐츠 유형을 먼저 확인하고, 그에 맞는 가져오기 기능을 선택한 뒤 그룹, 규칙, 연결 결과를 점검하면 형식 문제와 네트워크 문제를 구분하기 쉽습니다.