Clash 구독 형식 비교: YAML 설정, Base64 구독, URI 링크 변환 방법

먼저 내용을 확인한 뒤 가져오기 방식을 선택하세요

서비스 제공자가 명시한 Clash 또는 mihomo 구독 주소를 우선 사용하세요. 완전한 YAML 설정 파일을 받았다면 보통 클라이언트의 설정 목록에 바로 추가할 수 있습니다. Base64 텍스트나 프로토콜 URI 모음이라면 클라이언트가 해당 형식을 지원하는지 먼저 확인하세요. 파일 확장자만 바꾸지 말고, 구독 파일을 다운로드했다는 사실만으로 커널이 설정을 받아들였다고 판단하지 마세요.

먼저 혼동하기 쉬운 두 가지를 구분해야 합니다. 구독 주소는 콘텐츠를 가져오는 경로이고, 구독 형식은 주소에서 실제로 반환되는 데이터 구조입니다. 같은 HTTPS 주소라도 쿼리 매개변수나 요청 헤더에 따라 다른 콘텐츠를 반환할 수 있습니다. 주소가 .yaml로 끝나도 응답이 YAML이라는 보장은 없으며, 확장자가 없어도 완전한 설정 파일을 반환할 수 있습니다.

YAML 설정: 완전한 설정과 노드 목록 구분하기

최상위 필드부터 확인하세요. YAML은 데이터 표현 형식일 뿐 Clash 전용 형식이 아닙니다. YAML 파서가 읽을 수 있다고 해서 Clash 설정 구조에 맞는 것은 아닙니다. 특정 커널의 구조에 맞더라도 다른 커널이 모든 프로토콜과 옵션을 지원한다는 뜻은 아닙니다.

자주 볼 수 있는 YAML 콘텐츠 세 가지

• 완전한 설정: 일반적으로 proxies, proxy-groups, rules를 함께 구성하며, 수신 포트, DNS, TUN 등을 설정하기도 합니다.
• 노드 모음: proxies만 포함합니다. 호환되는 프록시 컬렉션 제공자에서 사용할 수 있지만, 이것만으로 프록시 그룹과 분류 규칙까지 설정됐다고 볼 수는 없습니다.
• 규칙 모음: 일반적인 최상위 필드는 payload입니다. rule-providers에서 참조하는 용도이며, 노드 구독이 아니므로 프록시 목록으로 가져올 수 없습니다.

아래는 구조를 설명하기 위한 설정 예시입니다. edge.example.com과 demo-password는 예시 값이며 실제 연결에 사용할 수 없습니다. 로컬 혼합 포트는 7890으로 설정하고 루프백 주소에서만 수신하며, 수동 선택 그룹 하나에 일치하는 모든 트래픽을 연결합니다.

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule

proxies:
  - name: DemoTLS
    type: trojan
    server: edge.example.com
    port: 443
    password: "demo-password"
    sni: edge.example.com
    udp: true

proxy-groups:
  - name: Manual
    type: select
    proxies:
      - DemoTLS
      - DIRECT

rules:
  - MATCH,Manual

여기서 443은 원격 프록시 서버 포트이고, 7890은 로컬 앱이 클라이언트에 연결하는 프록시 포트입니다. 두 포트는 서로 바꿔 쓸 수 없습니다. YAML을 노드 URI로 변환할 때는 원격 포트를 유지해야 합니다. 로컬 수신 포트, 프록시 그룹, 기본 규칙은 보통 노드 링크에 포함되지 않습니다.

실제 커널에 맞는 설정을 선택하세요

먼저 클라이언트의 ‘정보’ 또는 커널 정보 화면에서 커널 이름을 확인한 다음 해당 커널이 지원하는 프로토콜을 살펴보세요. 인터페이스에서 링크를 붙여 넣을 수 있다고 해서 실행 중인 커널이 링크의 프로토콜을 지원한다는 뜻은 아닙니다. Clash Meta에서 이어 발전한 mihomo와 이전 Clash 커널은 지원하는 프로토콜과 필드가 다르므로 파일 이름만 보고 변환 대상을 정해서는 안 됩니다.

Base64 구독: 디코딩은 변환이 아닙니다

먼저 로컬에서 디코딩한 뒤 결과를 확인하세요. Base64는 인코딩 방식이지 프록시 프로토콜이나 암호화 수단이 아닙니다. 흔히 여러 노드 URI를 줄마다 나열한 다음 전체 텍스트를 인코딩하지만, 서비스에 따라 다른 텍스트 구조를 인코딩하기도 합니다. 디코딩한 결과를 바로 Clash에 가져올 수 있다고 미리 단정하지 마세요.

인코딩이 두 겹일 수 있다는 점에 유의하세요. 구독의 바깥 부분이 Base64를 사용하고, 내부의 vmess:// 링크도 JSON을 Base64로 인코딩했을 수 있습니다. 일부 ss:// 링크도 인증 정보를 인코딩합니다. 구독의 바깥 부분을 먼저 복원한 다음, 해당 프로토콜을 이해하는 파서로 개별 링크를 처리하세요. 문자열을 여러 번 반복해서 디코딩하면 안 됩니다.

Python으로 로컬에서 인코딩된 콘텐츠 확인하기

받은 인코딩 본문을 subscription.txt로 저장하고 Python 3에서 다음 코드를 실행하세요. 이 스크립트는 일반적인 Base64 및 URL 안전 문자 집합을 지원하고 공백을 무시하며 끝부분의 패딩을 보충합니다. 결과는 decoded.txt에 저장하며 네트워크에 접속하지 않습니다. 입력이 실제로 YAML, 웹페이지 또는 일반 URI라면 해당 형식에 맞게 먼저 처리해야 합니다.

from pathlib import Path
import base64
import binascii

source = Path("subscription.txt").read_text(encoding="utf-8")
compact = "".join(source.split())
compact += "=" * (-len(compact) % 4)

try:
    raw = base64.b64decode(compact, altchars=b"-_", validate=True)
    text = raw.decode("utf-8")
except (ValueError, binascii.Error, UnicodeDecodeError) as exc:
    raise SystemExit("Base64 UTF-8 텍스트로 디코딩할 수 없습니다. 원본 콘텐츠를 확인하세요.") from exc

Path("decoded.txt").write_text(text, encoding="utf-8")
print("decoded.txt에 저장했습니다. 로컬에서 콘텐츠 형식을 확인하세요.")

• 줄마다 ss://, trojan:// 등이 보이면 URI를 설정 필드에 대응시키는 단계로 넘어가세요.
• proxies:가 보이면 이미 YAML인지 먼저 확인하세요. ‘노드 변환’을 다시 실행하지 마세요.
• HTML 로그인 페이지, 오류 메시지 또는 JSON 오류 객체가 보이면 먼저 구독 요청 문제를 해결하세요. 변환기로 존재하지 않는 노드 데이터를 만들어낼 수는 없습니다.

반대로 여러 줄의 URI를 Base64로 인코딩해도 같은 링크 모음을 다시 포장할 뿐입니다. rules나 proxy-groups가 자동으로 생성되지 않으며, 누락된 TLS, WebSocket, 인증 매개변수도 복구되지 않습니다.

URI를 YAML로 변환: 연결 매개변수를 하나씩 대응시키기

먼저 노드 하나로 필드를 확인한 다음 일괄 변환하세요. 아래 Trojan URI는 앞서 나온 YAML 노드에 해당합니다. 링크의 #DemoTLS는 표시 이름이며 인증 정보가 아닙니다. 쿼리 매개변수 sni는 TLS 서버 이름을 지정합니다.

trojan://[email protected]:443?sni=edge.example.com#DemoTLS

이 URI에는 앞선 예시의 udp: true가 명시되어 있지 않으므로 변환 후 원래 설정을 그대로 복원할 수 있다고 단정할 수 없습니다. 변환기가 자체 기본값을 적용할 수도 있습니다. 실제로 사용할 때는 서비스 지원 여부와 대상 커널의 요구 사항에 따라 UDP 설정을 명시적으로 확인하세요.

프로토콜과 전송 계층을 각각 처리하세요

• Shadowsocks: 암호화 방식, 비밀번호, 서버, 포트를 유지하세요. 플러그인이 있는 링크라면 플러그인 이름과 옵션도 확인해야 합니다. 호스트와 비밀번호만 저장하면 연결되지 않을 수 있습니다.
• VMess: 일반적인 공유 링크는 인코딩된 JSON을 포함하므로 UUID, 포트, 전송 유형, TLS 등의 필드를 파싱해야 합니다. 디코딩한 결과 전체를 YAML로 간주하면 안 됩니다.
• VLESS 및 기타 프로토콜: 대상 커널과 변환기가 모두 지원하는지 먼저 확인한 다음 flow, TLS, Reality 등 프로토콜 관련 매개변수를 점검하세요. 이름이 비슷한 필드로 기계적으로 바꿔서는 안 됩니다.
• WebSocket 또는 gRPC: 경로, Host 요청 헤더, 서비스 이름 등의 매개변수도 유지하세요. 프록시 프로토콜이 같아도 전송 설정이 다르면 연결되지 않을 수 있습니다.

문자열을 콜론으로 나누는 방식으로 범용 파서를 직접 만들지 마세요. IPv6 주소에는 콜론이 들어가고 비밀번호에는 이스케이프 문자가 포함될 수 있으며 노드 이름에 한글이 들어갈 수도 있습니다. URI 파싱 도구를 사용하고 각 프로토콜 규칙에 맞게 인코딩을 처리해, 반복 디코딩으로 비밀번호의 문자 그대로의 내용이 바뀌지 않도록 하세요.

YAML을 URI로 변환: 누락되는 정보를 확인하세요

URI는 개별 노드를 교환하는 수단으로만 사용하세요. 완전한 YAML은 더 많은 정보를 담고 있으며 노드 링크로 전체 실행 환경을 옮길 수는 없습니다. 클라이언트를 바꾸면서 트래픽 분류 로직도 유지하려면 URI를 내보냈다가 다시 가져오기보다 호환되는 전체 설정을 우선 이전하세요.

노드와 함께 완전히 옮길 수 없는 설정 네 가지

1. 프록시 그룹: select, url-test, fallback 그룹의 구성원, 테스트 주소, 전환 로직은 보통 노드 URI에 포함되지 않습니다.
2. 트래픽 분류 규칙: DOMAIN-SUFFIX, GEOIP, MATCH와 규칙 제공자 참조는 노드를 내보내도 자동으로 유지되지 않습니다.
3. 로컬 환경: 수신 포트, 시스템 프록시, TUN, DNS, 외부 제어 인터페이스 등의 설정은 새 설정이나 새 클라이언트에서 별도로 구성해야 합니다.
4. 확장 매개변수: 특수 전송, 인증서 처리, 멀티플렉싱, 커널 확장 필드는 URI 표현 방식이 통일되어 있지 않거나 일부 가져오기 도구에서만 인식될 수 있습니다.

양쪽에서 같은 프로토콜을 지원하더라도 공유 링크의 매개변수 이름은 구현에 따라 다를 수 있습니다. 변환한 뒤 서버, 포트, 인증 정보, TLS 이름, 전송 설정을 하나씩 비교하세요. 가져오기에 성공시키려고 인식되지 않는 매개변수를 삭제하지 말고, 인증서 검증 건너뛰기를 일반적인 해결책으로 사용하지 마세요.

직접 변환기 구축: 입력을 제한하고 출력 템플릿 고정하기

로컬에서 실행하거나 본인만 접근할 수 있는 환경에 배포하는 방식을 우선 고려하세요. 직접 변환기를 구축할 때는 YAML 생성뿐 아니라 원본 구독 인증 정보 보호, 원격 요청 범위 제한, 검토 가능한 변환 템플릿 고정도 중요합니다.

1. 구현 선택: 변환기가 원본 프로토콜, 대상 커널, 필요한 확장 필드를 명시적으로 지원하는지 확인하세요. 배포 버전과 템플릿 수정 내역을 기록하고, 업데이트 전에 정상 작동하는 출력물을 보관하세요.
2. 수신 범위 제한: 로컬 서비스는 127.0.0.1에서만 수신하도록 설정할 수 있습니다. 예를 들어 로컬 포트 25500을 사용하더라도 해당 포트를 인터넷에 직접 공개하지 마세요. 실제 포트는 선택한 구현의 설정을 따릅니다.
3. 템플릿 고정: 템플릿의 프록시 그룹, 규칙, 원격 리소스 주소를 검토하세요. 변환 시 노드만 바꾸고, 출처가 불분명한 템플릿이 DNS, 제어 인터페이스, 트래픽 출구까지 변경하지 못하도록 하세요.
4. 원격 URL 처리: 원본 구독과 원격 템플릿에 허용 목록을 적용하고 리디렉션, 응답 크기, 요청 시간 제한을 설정하세요. 서비스가 내부 네트워크나 클라우드 인스턴스 메타데이터 주소에 접근하는 데 악용되지 않도록 해야 합니다.
5. 로그 관리: 전체 쿼리 문자열, 인증 헤더, 구독 본문을 기록하지 마세요. 로그를 공유해야 한다면 토큰을 먼저 가리고, 생성된 파일과 캐시를 정기적으로 삭제하세요.

URL 매개변수로 원본 구독 주소를 전달할 때는 원본 주소 전체를 올바르게 한 번 퍼센트 인코딩해야 합니다. 원본 주소에 ?token=과 &type=이 들어 있는데 인코딩하지 않고 다른 URL에 넣으면 매개변수가 바깥쪽 요청에서 잘릴 수 있습니다. 변환기 설명서에서 지원하는 로컬 파일이나 요청 본문 입력 방식을 우선 사용해 브라우저 방문 기록과 액세스 로그에 인증 정보가 남을 가능성을 줄이세요.

정적 변환과 지속 구독도 구분해야 합니다. 파일을 한 번 다운로드해 생성하면 그 시점의 스냅샷만 얻게 됩니다. 자동 업데이트를 하려면 안정적인 업데이트 경로를 유지하거나 설정에서 커널이 지원하는 프록시 컬렉션 기능을 사용해야 합니다. 원격 업데이트가 로컬 수정을 덮어쓰는지는 클라이언트의 병합 및 덮어쓰기 방식에 따라 다르므로 ‘자동 업데이트 사용’ 스위치만 확인해서는 안 됩니다.

변환 후 검증: 구조, 연결, 트래픽 분류를 단계별로 확인

설정을 먼저 검사한 다음 현재 실행 설정을 전환하세요. 비교할 수 있도록 기존에 정상 작동하던 구독을 보관해 두세요. mihomo를 사용한다면 생성된 파일을 대상으로 설정 테스트를 실행할 수 있습니다. 아래 명령의 파일 이름은 로컬에 저장한 출력 파일입니다.

mihomo -t -f ./converted.yaml

테스트를 통과했다는 것은 해당 커널의 검사를 통과했다는 뜻이지 원격 노드가 작동한다는 뜻은 아닙니다. 원격 리소스를 참조하는 설정은 로컬 파일, 네트워크 접근, 실행 디렉터리의 영향을 받을 수 있으므로 테스트 환경을 실제 운영 환경과 최대한 동일하게 맞추세요.

최소한의 검증 수행하기

• 변환 전후의 노드 수와 이름을 확인해 필터링, 이름 변경, 파싱 실패가 있었는지 살펴보세요.
• 사용 가능한 것으로 확인된 노드 하나만 선택해 TLS와 전송 매개변수가 모두 있는지 확인한 다음 전체 목록으로 확대하세요.
• 예시의 혼합 포트 7890을 사용한다면 실제로 수신 중인지 먼저 확인한 뒤 앱을 해당 포트에 연결하세요.
• 일반 웹페이지 접속, DNS 해석, UDP가 필요한 앱을 각각 확인하세요. 웹페이지 한 번 접속에 성공했다고 모든 사용 사례가 검증된 것은 아닙니다.

마지막으로 변환 기록을 남기세요. 원본 형식, 대상 커널, 변환기와 템플릿 버전, 직접 추가한 필드를 기록해 두면 나중에 구독 업데이트가 실패했을 때 원본 데이터, 파싱 과정, 로컬 실행 설정 중 어디에서 문제가 생겼는지 파악할 수 있습니다. 온라인 변환 사이트를 번갈아 시도할 필요도 없습니다.