구독 URL, 노드 링크, 설정 파일
‘구독’이라고 해도 실제로 전달되는 내용은 제각각입니다. HTTPS 주소 하나일 수도 있고, ss://로 시작하는 노드 링크 몇 줄이나 proxies:가 포함된 YAML 파일일 수도 있습니다. Clash에 가져올 수 있는지는 링크 길이나 파일 확장자가 아니라 클라이언트가 받은 응답 내용과 현재 커널이 해당 필드를 해석할 수 있는지에 달려 있습니다.
구독 URL은 데이터를 가져오는 경로이고, 구독 형식은 그 경로에서 반환되는 데이터 구조이며, 프록시 프로토콜은 노드와 서버가 통신하는 방식입니다. 이 셋은 서로 바꿔 쓸 수 없습니다. 파일명을 nodes.txt에서 config.yaml로 바꿔도 형식은 달라지지 않습니다. 텍스트를 Base64로 인코딩해도 클라이언트가 새로운 프로토콜을 지원하게 되는 것은 아닙니다.
- 구독 URL: 보통 계정 토큰이 포함된 HTTPS URL로, 정기적으로 업데이트를 가져오는 데 사용됩니다. 반환되는 내용은 서버에서 결정합니다.
- 노드 공유 링크: 노드를 프로토콜별 URI로 표현합니다. 예를 들면
ss://,vmess://,trojan://이 있습니다. 프로토콜마다 필드를 인코딩하는 방식이 다릅니다. - 전체 설정: 노드뿐 아니라 프록시 그룹, 규칙, DNS, 리스닝 포트, 외부 리소스도 정의할 수 있습니다.
Base64 구독: 인코딩된 노드 링크 모음
일반적인 범용 구독은 여러 노드 공유 링크를 줄마다 나열한 뒤, 전체 텍스트를 Base64로 인코딩합니다. 디코딩하면 URI 목록이 나오며, Clash에서 바로 불러올 수 있는 전체 설정이 아닙니다. 인코딩하지 않은 링크 목록이나 JSON 등 다른 구조를 반환하는 서비스도 있으므로, 긴 영문·숫자 문자열처럼 보인다는 이유만으로 형식을 단정하지 마세요.
Base64는 암호화가 아닙니다
예를 들어 aGVsbG8=를 디코딩하면 hello가 됩니다. Base64는 바이트를 텍스트로 전송하기 쉬운 형태로 바꾸는 방식이며, 키가 필요하지 않습니다. 구독의 비밀번호, UUID, 서버 주소를 인코딩하더라도 내용을 입수한 사람은 다시 복원할 수 있습니다.
표준 Base64에는 보통 영문자와 숫자, +, /가 쓰이며 끝에 =가 붙을 수 있습니다. URL 안전 변형은 -와 _를 사용하고, 일부 구현에서는 패딩을 생략합니다. 디코딩에 실패해도 변형 방식이나 줄바꿈 처리 문제일 수 있으니 구독이 만료됐다고 바로 단정하지 마세요.
외부 인코딩을 풀어도 개별 링크는 따로 파싱해야 합니다
기존 vmess:// 공유 링크는 JSON을 Base64 페이로드에 담는 경우가 많습니다. ss://는 사용자 정보 인코딩과 플러그인 매개변수에 자체 규칙을 사용합니다. 구독 전체를 디코딩하는 단계와 개별 프로토콜 링크를 파싱하는 단계는 별개입니다. 같은 ‘디코딩’ 버튼을 반복해서 누르는 것으로 프로토콜 파서를 대신할 수 없습니다.
Clash YAML: 노드, 프록시 그룹, 규칙 구성
YAML은 데이터 표현 언어이지 Clash 전용 형식이 아닙니다. 현재 커널의 설정 구조를 따르는 YAML만 설정으로 사용할 수 있습니다. 문법은 맞더라도 일반 문서 내용이라면 Clash 설정으로 가져올 수 없습니다.
| 필드 | 주요 용도 | 주요 확인 사항 |
|---|---|---|
proxies | 개별 프록시 노드 정의 | 노드 유형과 전송 필드가 커널에서 지원되는지 |
proxy-groups | 수동 선택이나 자동 테스트 등의 프록시 그룹 구성 | 참조하는 노드와 프록시 그룹 이름이 실제로 존재하는지 |
rules | 연결에 사용할 프록시를 순서에 따라 결정 | 규칙 대상 이름과 마지막 기본 정책이 올바른지 |
proxy-providers | 외부 노드 리소스 선언 | 리소스 형식, 가져오기 URL, 업데이트 상태 |
dns | 커널의 도메인 이름 해석 방식 설정 | 업스트림 연결 가능 여부와 트래픽 가로채기 모드와의 호환성 |
구조를 이해하기 위한 설정 예시
아래 예시는 혼합 포트 7890을 사용하며, 직접 연결 정책만 포함합니다. 원격 프록시 노드가 없으므로 프록시 서비스 연결 여부를 확인하는 용도로 사용할 수 없습니다. 목록과 들여쓰기, 프록시 그룹 참조, 기본 규칙의 관계를 보여 주는 예시입니다. 7890은 이 예시에서 사용한 값일 뿐, 모든 클라이언트가 같은 포트를 사용하는 것은 아닙니다.
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxies: []
proxy-groups:
- name: "프록시 선택"
type: select
proxies:
- DIRECT
rules:
- MATCH,프록시 선택YAML 들여쓰기에는 공백을 사용해야 하며, 계층을 나타낼 때 Tab을 쓰면 안 됩니다. #이나 콜론 같은 특수 문자가 들어간 비밀번호는 따옴표로 감싸는 것이 좋습니다. 노드 이름도 일관되게 사용해야 합니다. 위 예시에서 규칙 대상을 존재하지 않는 ‘프록시 출구’로 바꾸면 들여쓰기가 모두 올바르더라도 설정 검증에 실패할 수 있습니다.
전체 설정과 노드 프로바이더 리소스도 구분해야 합니다. 일반적인 YAML 노드 리소스는 최상위에 proxies:만 있으며, proxy-providers에서 참조해 사용할 수 있습니다. 하지만 트래픽 분산 규칙까지 갖춘 전체 설정은 아닙니다. 클라이언트에 따라 프록시 그룹을 자동으로 보완하기도 하고 그렇지 않기도 하므로, 가져오기 결과가 항상 같다고 가정하면 안 됩니다.
형식 호환성과 커널 호환성은 별도로 확인해야 합니다
Clash 클라이언트는 인터페이스와 구독 관리, 시스템 연동을 담당하고, 커널은 연결과 파싱, 규칙 실행을 담당합니다. Clash Meta는 이후 mihomo라는 이름으로 개발이 이어졌지만, ‘Clash 설정 지원’이 모든 세대의 커널이 같은 필드를 지원한다는 뜻은 아닙니다.
예를 들어 VLESS, Hysteria2, TUIC 등의 노드가 포함된 설정은 사용하려는 커널과 해당 버전의 지원 범위를 확인해야 합니다. 노드를 YAML로 변환해도 구형 Clash 커널에 해당 프로토콜 구현이 추가되지는 않습니다. 프로토콜 이름이 지원되더라도 Reality, 전송 계층 또는 TLS 매개변수는 특정 버전에서만 지원될 수 있습니다.
- 먼저 입력 형식을 확인하세요: 가져오기 기능이 구독 URL, 전체 설정 파일, 개별 노드 공유 링크 중 무엇을 받는지 살펴보세요. ‘클립보드에서 가져오기’가 모든 URI를 지원하는 것도 아닙니다.
- 다음으로 커널 종류를 확인하세요: 앱 이름만 보지 말고, 클라이언트의 ‘정보’ 또는 커널 관리 화면에서 실제 실행 중인 커널을 확인하세요.
- 마지막으로 필드를 확인하세요: 설정 검증 오류 전문을 기록하고 노드 유형, 전송 매개변수, 리소스 참조 중 어디에서 문제가 발생했는지 확인하세요. 클라이언트를 반복해서 다시 설치할 필요는 없습니다.
Clash for Android의 일반적인 화면에서는 ‘프로필’ → ‘＋’ → ‘URL에서 가져오기’를 눌러 원격 설정을 추가합니다. 가져온 뒤에는 설정을 선택하고 서비스를 시작해야 합니다. 다른 클라이언트에서는 비슷한 기능이 ‘프로필’이나 ‘구독’ 화면에 있을 수 있고, 버튼 이름도 버전에 따라 다르므로 현재 화면을 기준으로 확인하세요. 노드 링크 하나만 있다면 ‘설정 URL’ 입력란에 붙여 넣는 것만으로 가져오기가 끝난다고 생각하지 마세요.
구독 변환: 노드를 파싱한 뒤 대상 형식으로 생성
구독 변환은 Base64 텍스트의 확장자만 바꾸는 작업이 아닙니다. 변환기는 보통 원본 데이터를 가져와 각 노드를 식별하고 파싱한 다음, 내부 표현을 만든 뒤 대상 형식에 맞춰 노드 필드를 생성합니다. 대상이 전체 Clash 설정이라면 규칙 템플릿을 적용하고, 프록시 그룹을 만들거나 DNS를 설정하고 자동 속도 측정 설정을 추가할 수도 있습니다.
변환할 수 있는 항목과 손실될 수 있는 항목
- 대체로 변환 가능한 항목: 대상 커널이 지원하는 경우 서버 주소, 포트, 비밀번호 또는 UUID와 명확히 대응되는 TLS·전송 매개변수
- 보존되지 않을 수 있는 항목: 대상 형식에서 지원하지 않는 플러그인 옵션, 프로토콜별 매개변수, 클라이언트 전용 확장, 출처가 불분명한 인증서 설정
- 다시 구성해야 하는 항목: 규칙, DNS, 중첩된 프록시 그룹, 테스트 정책. 노드 링크만으로는 보통 이런 설정을 복원할 정보가 충분하지 않습니다.
반대로 전체 YAML을 범용 노드 링크로 내보내면 노드 정보만 남는 경우가 많습니다. 기존 트래픽 분산 규칙과 DNS, 프록시 그룹 선택 로직은 각 URI에 자동으로 포함되지 않습니다. 따라서 ‘YAML → 링크 목록 → YAML’을 거쳐도 원래 설정이 복원된다고 보장할 수 없으며, 이런 왕복 변환을 백업 수단으로 사용해서는 안 됩니다.
온라인 변환 시 인증 정보 보호
구독 URL을 온라인 변환 서비스에 입력하면, 변환 서비스는 원본 구독에 접근해야 하므로 URL의 토큰과 반환되는 노드 인증 정보도 볼 수 있습니다. 브라우저와 변환 페이지 사이에 HTTPS를 사용하더라도 전송 구간만 보호할 뿐, 서버가 데이터를 읽는 것을 막지는 못합니다.
서비스 제공자가 Clash 또는 mihomo 전용 구독을 제공한다면 우선 해당 구독을 사용하세요. 변환이 꼭 필요하다면 작동 방식을 신뢰할 수 있는 도구를 고르고, 가능하면 로컬에서 처리하세요. 변환 결과를 공유하기 전에는 전체 URL도 확인해야 합니다. 원본 구독이 쿼리 매개변수에 포함될 수 있습니다. 실수로 공개했다면 서비스 제공자 페이지에서 구독 토큰을 재설정하고, 노드 인증 정보도 변경해야 하는지 확인하세요.
가져오기 실패: 응답부터 파싱, 연결 순으로 점검
‘구독 가져오기 성공’과 ‘노드 연결 성공’은 서로 다른 단계입니다. 문제를 확인할 때는 원본 설정을 보존하고 DNS, 규칙, 포트, TUN을 한꺼번에 바꾸지 마세요. 한 번에 한 요소만 변경해야 원인을 더 쉽게 찾을 수 있습니다.
| 증상 | 우선 확인할 항목 | 다음 조치 |
|---|---|---|
| 401 또는 403 응답 | 토큰, 권한, 요청 조건 | 서비스 제공자 페이지에서 구독 URL을 다시 복사하고 유효 기간과 클라이언트 요구 사항을 확인합니다 |
| 응답 첫 부분에 HTML 태그가 표시됨 | 로그인 페이지, 오류 페이지 또는 접근 확인 페이지인지 | 설정으로 저장하지 말고 관리 페이지가 아닌 구독 API를 사용했는지 확인합니다 |
| YAML 문법 오류 메시지 | 들여쓰기, 따옴표, 응답이 잘렸는지 | 오류가 표시된 줄 주변의 구조를 확인하고, Base64 텍스트가 반환된 것은 아닌지 살펴봅니다 |
| 알 수 없는 프록시 유형 오류 | 현재 커널의 프로토콜 지원 여부 | 커널 버전과 노드 매개변수를 확인하세요. 파일 확장자를 바꿔도 해결되지 않습니다 |
| 설정은 불러와지지만 노드 연결이 시간 초과됨 | 주소 해석, 서버 포트, 인증, TLS | 연결 로그를 확인한 뒤 구독 형식이 원인인지 판단합니다 |
HTTP 200은 요청에 응답이 왔다는 뜻일 뿐, 본문이 설정이라는 보장은 없습니다. Content-Type도 참고 정보로만 활용해야 합니다. 브라우저에서는 열리지만 클라이언트에서 가져오지 못한다면 리디렉션, 인증서 신뢰, 요청 헤더, 네트워크 경로 차이 등이 원인일 수 있습니다. 브라우저 세션 쿠키를 일반적인 해결책으로 사용하지 말고, 문제를 확인하려고 인증서 검증을 끄지도 마세요.
업데이트 후 작동하지 않는다면 수정 내용이 저장된 위치부터 확인하세요
원격 설정을 업데이트하면 보통 내용을 다시 다운로드합니다. 다운로드한 파일을 직접 수정하면 다음 업데이트 때 변경 내용이 덮어써질 수 있습니다. 개인 규칙을 추가하려는 경우 클라이언트에서 공식 지원하는 덮어쓰기, 병합 또는 확장 기능을 우선 사용하고 처리 순서도 확인하세요. 이런 기능은 클라이언트마다 달라 메뉴와 문법이 통일되어 있지 않습니다.
이름이 바뀌었거나 필터링된 노드를 프록시 그룹이 참조하는지, 외부 노드 리소스가 정상적으로 업데이트됐는지도 확인하세요. 원격 설정을 성공적으로 다운로드했더라도 설정에서 참조하는 모든 리소스까지 가져왔다는 뜻은 아닙니다.
구독을 가져오기 전에 확인할 사항
- Clash 또는 mihomo 전용 구독이 있는 경우: 우선 직접 가져오고 현재 커널과 호환되는지 확인해 변환 단계를 줄이세요.
- 범용 Base64 구독만 있는 경우: 클라이언트에 노드 파싱 또는 변환 기능이 내장되어 있는지 확인하세요. 없다면 적절한 변환 도구를 선택하세요.
- 공유 링크 하나만 있는 경우: 해당 프로토콜을 명시적으로 지원하는 노드 가져오기 기능을 찾으세요. 전체 설정이 필요하다면 프록시 그룹과 규칙도 추가해야 합니다.
- YAML 파일을 받은 경우: 먼저 전체 설정인지 노드 리소스인지 확인한 다음 문법, 참조 관계, 커널 지원 여부를 검증하세요.
- 사용 중인 설정을 교체할 경우: 현재 사용할 수 있는 버전을 보관하고 새 설정의 검증을 마친 뒤 전환하세요. 노드 수와 프록시 그룹, 규칙 동작도 확인해야 합니다.
형식 확인은 ‘데이터를 읽을 수 있는가’를, 커널 호환성은 ‘프로토콜을 실행할 수 있는가’를 판단합니다. 연결 로그를 보면 마지막으로 ‘서버에 접속할 수 있는가’를 확인할 수 있습니다. 이 세 단계를 나눠서 점검하면 구독 변환과 클라이언트 설정, 네트워크 문제를 오가며 불필요하게 시도하는 일을 줄일 수 있습니다. 처음 실행하는 방법은 사이트의 사용 가이드에서 확인하고, 프로토콜과 설정 필드는 프로토콜 참고 자료와 대조해 보세요.