Clash 구독 링크 가져오기: URL·Base64·YAML 형식 비교
플랫폼별 클라이언트에서 구독 링크를 가져오는 방법과 위치를 알아보고, 전체 YAML 설정·Base64 노드 목록·단일 노드 링크의 차이와 변환 방법을 비교합니다.
링크와 응답 내용부터 구분하기
Clash 구독을 가져오기 전에 두 가지를 확인하세요. 받은 것이 다운로드 주소인지 노드 자체인지, 그리고 주소에서 내려받는 내용이 전체 설정인지 노드 목록뿐인지 살펴봐야 합니다. “링크는 열리는데 클라이언트에서 가져오지 못하는” 문제는 대부분 여기서 비롯됩니다.
URL은 주소이고 YAML과 Base64는 콘텐츠 형식 또는 인코딩 방식입니다. 서로 다른 개념입니다.https://로 시작하는 구독 URL은 Clash YAML을 반환할 수도 있고, Base64로 인코딩된 노드 목록이나 계정 로그인 페이지를 반환할 수도 있습니다. 확장자나 링크 길이, 웹페이지 접속 여부만으로 호환성을 판단할 수는 없습니다.
| 받은 내용 | 확인할 단서 | 사용할 가져오기 방법 |
|---|---|---|
| 전체 YAML 설정 | 대개 proxies, proxy-groups, rules 등의 필드가 포함되며, provider를 통해 노드를 참조할 수도 있습니다. | 원격 설정 또는 로컬 설정 파일 가져오기 |
| Base64 노드 목록 | 디코딩하면 여러 줄의 ss://, vmess://, trojan:// 등의 링크가 나오는 경우가 많습니다. | 해당 형식을 지원하는 가져오기 도구 또는 신뢰할 수 있는 로컬 변환 절차 |
| 단일 노드 링크 | 특정 프로토콜 접두사로 시작하며, 보통 연결 하나의 정보를 담고 있습니다. | 해당 프로토콜을 지원하는 노드 가져오기 또는 노드 편집 메뉴 |
전체 YAML 설정과 노드 목록의 차이
전체 설정은 노드 모음만으로 구성되지 않습니다
바로 사용할 수 있는 Clash 설정에는 연결 정보뿐 아니라 트래픽을 커널로 보내는 방식, 규칙이 참조할 정책 그룹, 어떤 규칙에도 해당하지 않을 때 사용할 출구가 필요합니다. 흔히 쓰이는 필드는 mixed-port, mode, proxy-groups, rules, dns입니다. 커널마다 지원하는 필드가 다르므로, 특정 필드가 설정에 있다고 해서 모든 클라이언트가 이를 인식하는 것은 아닙니다.
아래 YAML은 필드 구조를 알아보기 위한 예시이며, 프록시 노드가 포함된 구독이 아닙니다. 7890은 리슨 포트 예시일 뿐, 로컬 클라이언트도 이 포트를 사용한다고 단정할 수 없습니다. MATCH,DIRECT는 이 규칙에 도달한 요청을 직접 연결합니다.
mixed-port: 7890
mode: rule
log-level: info
rules:
- MATCH,DIRECT가져올 때는 원본 파일의 계층 구조와 공백 들여쓰기를 유지하세요. 웹페이지에 표시된 서식 있는 텍스트를 설정으로 그대로 사용하면 안 됩니다. YAML 들여쓰기에는 Tab이 아닌 공백을 사용해야 합니다. 파서가 표시한 줄 번호부터 확인하되, 실제 오류는 바로 앞 줄에 있을 수도 있습니다. 따옴표를 빠뜨렸거나 콜론 뒤 구분이 잘못됐거나 목록 항목의 들여쓰기가 어긋났는지 살펴보세요.
YAML이어도 provider 파일일 수 있습니다
일부 주소는 최상위에 proxies:와 노드 목록만 포함된 내용을 반환합니다. 이런 파일은 보통 proxy-providers에서 사용하며, 정책 그룹과 라우팅 규칙까지 갖춘 전체 설정과는 다릅니다. 메인 설정에서 provider를 선언하고 정책 그룹의 use로 참조해야 합니다. 이를 전체 설정인 것처럼 가져오면 파싱은 되더라도 예상한 정책 그룹이나 라우팅 동작이 나타나지 않을 수 있습니다.
따라서 서비스 제공업체가 “Clash 설정”과 “노드 provider”를 따로 제공한다면 초보자는 먼저 전자를 선택하세요. 메인 설정을 직접 관리할 때만 후자를 연결하면 됩니다. 필드의 의미는 이 사이트의 설정 필드 문서에서 확인하세요. 파일 확장자만 보고 용도를 판단하지 마세요.
플랫폼별 구독 URL 가져오기
아래에서는 자주 사용하는 클라이언트의 화면을 기준으로 설명합니다. 메뉴 이름은 버전에 따라 달라질 수 있으므로, 표시되는 이름이 다르면 노드 검색창 대신 “구독”, “설정” 또는 Profiles 페이지를 찾아보세요. 처음 가져오기 전에 현재 작동하는 설정을 보관하고, 이전 설정을 삭제한 뒤 시도하지 마세요.
Windows·macOS: Clash Verge Rev 기준
- 서비스 제공업체의 구독 페이지에서 Clash 또는 mihomo 호환이라고 명시된 형식을 선택하고, 계정 관리 페이지 주소가 아닌 HTTPS 구독 주소 전체를 복사합니다.
- Clash Verge Rev에서 「구독」 페이지를 열고 구독 링크 입력란에 주소를 붙여 넣은 다음 「가져오기」를 클릭합니다. 화면에 「새로 만들기」 메뉴가 있다면 원격 유형을 선택하고 이름과 URL을 입력할 수도 있습니다.
- 원격 설정 다운로드가 끝날 때까지 기다린 다음 해당 설정을 선택합니다. 목록에 항목이 추가됐다고 해서 현재 사용 중인 설정으로 자동 전환되는 것은 아닙니다.
- 「프록시」 페이지를 열어 예상한 정책 그룹이 표시되는지 확인하고, 그룹에서 출구를 선택합니다. 규칙에 따라 트래픽을 분기하려면 실행 모드를 「규칙」으로 설정하세요.
- 필요에 따라 시스템 프록시 또는 TUN을 활성화하고 연결 기록을 확인합니다. 처음 확인할 때 DNS, 규칙, TUN 설정을 한꺼번에 바꾸면 어떤 변경이 적용됐는지 파악하기 어렵습니다.
Linux에서 같은 클라이언트를 사용할 때 구독 가져오기 절차는 동일합니다. 주된 차이는 시스템 프록시와 TUN의 권한, 서비스 설치 방식입니다. 구독 다운로드 성공 여부와 시스템 트래픽이 프록시를 통과하는지는 별개의 문제입니다.
Android: 설정 가져오기와 VPN 실행 구분하기
구형 Clash for Android에서는 보통 「설정」→「＋」→「URL에서 가져오기」를 선택한 뒤 이름과 URL을 입력하고 저장합니다. 설정 목록으로 돌아와 방금 가져온 설정을 선택하고 메인 화면에서 시작해야 합니다. 시스템에서 처음 VPN 권한을 요청하면 권한을 허용해야 해당 트래픽을 처리할 수 있습니다. 이 프로젝트는 유지 관리가 중단됐으므로 최신 프로토콜과 설정 필드의 호환성을 먼저 확인하세요.
FlClash처럼 계속 관리되는 클라이언트를 사용한다면 「설정」 페이지에서 추가 또는 URL 가져오기 메뉴를 찾으세요. 절차는 “주소 추가 → 다운로드 → 설정 선택 → 시작”으로 동일합니다. Android의 VPN 아이콘이 표시된다고 구독이 제대로 로드됐다는 뜻은 아닙니다. VPN 서비스가 실행 중이라는 사실만 보여 줍니다.
iOS: 클라이언트가 지원하는 형식부터 확인하기
iOS 클라이언트에는 공통된 Clash 가져오기 메뉴가 없습니다. 먼저 클라이언트 설명을 확인해 전체 Clash YAML, 노드 구독, 단일 노드 URI 중 어떤 형식을 지원하는지 알아본 다음 해당하는 「구독 추가」 또는 「설정 가져오기」 메뉴를 사용하세요. 두 앱이 같은 프록시 프로토콜을 지원한다고 해서 같은 설정 파일 형식까지 지원하는 것은 아닙니다.
구독 페이지에 「클라이언트에서 열기」 버튼이 있다면 앱이 실행된 뒤에도 가져오기 이름과 대상 주소를 확인하세요. 시스템 공유 메뉴에 앱이 표시되더라도 해당 앱이 현재 콘텐츠를 해석할 수 있다는 뜻은 아닙니다. 클라이언트를 바꿔야 한다면 클라이언트 다운로드 페이지에서 플랫폼과 커널 유형을 먼저 확인하세요.
Base64와 단일 노드 처리 방법
Base64 디코딩으로 라우팅 규칙이 생기지는 않습니다
Base64는 암호화가 아니라 인코딩입니다. 노드 목록을 인코딩하면 긴 문자열처럼 보이지만, 디코딩해도 보통 여러 줄의 노드 URI만 나옵니다. proxy-groups, rules, DNS 설정이 자동으로 추가되지는 않습니다. 목록에서 끝부분의 패딩 문자가 생략되거나 URL 안전 변형이 사용되기도 하므로, 간단한 온라인 디코더에서 오류가 날 수도 있습니다.
가장 간단한 방법은 서비스 제공업체 페이지로 돌아가 Clash 또는 mihomo용 구독 형식을 선택하는 것입니다. 해당 형식이 없을 때만 변환을 고려하세요. URL에 format=clash를 임의로 붙여 결과를 기대하지 마세요. 형식 매개변수는 서버에서 정하며 모든 구독 서비스에 통하는 공통 규칙은 없습니다.
단일 노드를 가져와도 자동 갱신되지는 않습니다
ss://, vmess://, trojan:// 등의 링크에는 보통 서버, 포트, 인증 정보와 전송 매개변수가 들어 있습니다. 가져오려면 클라이언트가 해당 프로토콜과 URI 매개변수 형식을 모두 지원해야 합니다. 일부 최신 프로토콜은 mihomo 등의 커널이 필요하며, 구형 Clash 커널은 프로토콜 이름만 바꾼다고 호환되지 않습니다.
수동으로 가져온 노드는 대개 일회성 스냅샷입니다. 서버에서 포트, 인증 정보 또는 전송 매개변수를 바꾸더라도 구독 페이지에서 가져왔다는 이유만으로 노드가 자동 갱신되지는 않습니다. 자동으로 관리하려면 원격 구독 항목을 저장하고 클라이언트의 업데이트 기능을 사용하세요.
변환 전후에 확인할 필드
- 프로토콜 및 인증: 노드 유형, 서버 포트, 비밀번호 또는 UUID가 빠지지 않았는지 확인하세요. 노드 이름이 같다는 이유만으로 변환이 성공했다고 판단하면 안 됩니다.
- TLS 매개변수: SNI, ALPN, 인증서 검증 설정을 확인하세요. 변환 결과가 “연결되도록” 인증서 검증을 바로 끄지 마세요.
- 전송 매개변수: WebSocket 경로와 요청 헤더, gRPC 서비스 이름은 핸드셰이크에 영향을 줄 수 있습니다. 하나라도 누락되면 연결에 실패할 수 있습니다.
- 설정 구조: 변환 도구가 생성한 정책 그룹과 규칙이 서로 올바르게 참조되는지 확인하세요. 규칙이 존재하지 않는 그룹 이름을 가리키면 노드가 유효해도 전체 설정을 불러오지 못할 수 있습니다.
응답 결과에 따라 가져오기 오류 해결하기
먼저 “요청이 실패한 경우”와 “요청은 성공했지만 내용이 잘못된 경우”를 구분하세요. 전자는 네트워크, 주소, 인증서를 확인하고 후자는 형식과 커널 호환성을 살펴봅니다. 다운로드에 실패했는데 YAML 들여쓰기를 계속 바꾸거나, 파싱에 실패했는데 노드만 바꾸지 마세요.
| 증상 | 흔한 원인 | 다음 단계 |
|---|---|---|
| HTTP 401 또는 403 | 토큰 만료, 권한 제한 또는 접속 차단 | 구독 주소를 다시 복사하고 계정 상태와 서비스 안내를 확인합니다. |
| HTTP 404 또는 410 | 주소 오류, 이전 API 제거 또는 리소스 만료 | 서비스 제공업체 계정 페이지에서 구독 링크를 다시 가져옵니다. |
| HTTP 429 | 짧은 시간 동안 업데이트를 너무 자주 시도함 | 연속 재시도를 멈추고 서버 안내에 따라 기다린 뒤 업데이트합니다. |
| 상태 코드는 200인데 파싱 오류가 표시됨 | HTML, JSON 오류 메시지 또는 호환되지 않는 노드 목록이 반환됨 | 응답의 첫 부분을 확인해 예상한 설정이 맞는지 살펴봅니다. |
| unknown proxy type 등의 유형 오류 | 현재 커널이 노드 프로토콜을 지원하지 않거나 변환 결과가 잘못됨 | 커널 유형과 노드 매개변수를 확인하세요. UI 프로그램만 업데이트해서는 해결되지 않을 수 있습니다. |
| 가져오기는 성공했지만 예상한 정책 그룹이 없음 | 설정이 활성화되지 않았거나 노드만 포함된 파일을 가져옴 | 현재 선택된 항목과 전체 설정 구조를 확인합니다. |
브라우저에서 열려도 클라이언트 다운로드까지 성공한 것은 아닙니다
브라우저에는 로그인 쿠키가 있지만 구독 다운로드 도구에는 없을 수 있습니다. 서버가 User-Agent에 따라 다른 내용을 반환하기도 합니다. 따라서 클라이언트가 실제로 받은 응답을 기준으로 판단하세요. 로그에 인증서 만료 또는 인증서 체인 오류가 표시되면 기기 시간, 시스템 인증서, 서버 인증서 상태부터 확인하세요. 인증서 검증을 건너뛰는 것은 일반적인 해결 방법이 아닙니다.
요청 시간이 초과되면 구독 도메인을 조회할 수 있는지, 클라이언트가 구독 업데이트에 직접 연결을 사용하는지 기존 프록시를 사용하는지 확인하세요. 프록시를 통해야만 다운로드할 수 있다면 작동 중인 이전 설정을 유지한 채 클라이언트의 프록시 다운로드 옵션을 사용하세요. 사용할 수 있는 설정이 없을 때 “새 구독을 다운로드해야 생기는” 출구를 선택하면 순환 의존성이 발생합니다.
가져온 뒤 네 가지 확인하기
- 현재 설정 확인.선택된 항목, 최근 업데이트 시각, 로드 로그를 확인해 “새 구독을 다운로드했지만 이전 설정이 계속 실행되는” 상황을 방지하세요. 업데이트에 오류가 나면 이전 사본을 보관하고 새 설정이 유효한지 확인한 뒤 교체합니다.
- 정책 그룹 참조 확인.「프록시」 페이지에서 그룹에 예상한 노드가 있는지 확인하세요. 규칙 모드에서는 연결에 적용된 규칙과 출구도 살펴봅니다. 글로벌 모드에서 연결에 성공했다고 해서 라우팅 규칙까지 올바르다는 뜻은 아닙니다.
- 트래픽 진입 경로 확인.시스템 프록시는 시스템 프록시 설정을 따르는 앱에 주로 적용되며, 다른 프로그램은 사용하지 않을 수도 있습니다. TUN이 처리하는 범위도 라우팅과 제외 항목에 따라 달라집니다. 구독만 가져온다고 모든 앱의 트래픽이 자동으로 프록시를 통과하지는 않습니다.
- 업데이트 설정 확인.전체 원격 설정의 갱신은 보통 클라이언트에서 관리합니다.
proxy-providers의interval은 초 단위이며, 예를 들어3600은 한 시간을 뜻합니다. 두 설정은 서로 다른 항목이므로 구체적인 갱신 간격은 서비스 제공업체의 안내를 따르세요.
마지막으로 순서를 기억하세요. 먼저 응답 형식을 확인하고, 설정을 가져와 활성화한 뒤 정책 그룹을 검증하고, 마지막으로 시스템 프록시나 TUN을 점검합니다. 각 단계를 나눠 확인하면 문제가 생겼을 때 주소, 설정, 트래픽 진입 경로 중 어디를 살펴봐야 할지 알 수 있습니다. 매번 클라이언트 재설치부터 시작할 필요가 없습니다.