Clash 구독 링크 가져오기: URL 가져오기 단계와 주요 구독 형식 차이
구독 링크 복사부터 클라이언트 적용까지 전체 가져오기 과정을 안내하고, Clash 기본 YAML·Base64 노드 목록·변환이 필요한 형식의 차이를 설명해 링크를 인식하지 못하는 원인을 파악할 수 있도록 합니다.
Clash에서 ‘구독 가져오기’는 웹 주소를 저장하는 것만을 뜻하지 않습니다. 클라이언트가 해당 URL에 접속해 원격 설정을 내려받고, 현재 코어에서 해석할 수 있는 형식인지 확인한 뒤 결과를 로컬 설정으로 저장합니다. 가져오기가 끝난 후에는 보통 해당 설정을 선택하고 프록시 노드를 지정한 다음 시스템 프록시 또는 TUN 모드를 켜야 트래픽이 실제로 Clash를 통과합니다.
가져오기 문제는 대부분 세 단계에서 발생합니다. 복사한 것이 구독 주소가 아니거나, 서버가 현재 클라이언트에서 지원하지 않는 형식으로 응답했거나, 설정 다운로드에는 성공했지만 현재 설정으로 지정되지 않은 경우입니다. 먼저 표준 URL 가져오기를 완료한 뒤 YAML, Base64 노드 목록, 단일 공유 링크를 차례로 구분해 보겠습니다.
가져오기 전에 구독 URL인지 먼저 확인하세요
원격 업데이트에 사용할 수 있는 구독 주소는 보통 https://로 시작하며, 복사한 결과가 한 줄짜리 전체 URL이어야 합니다. 예를 들면 다음과 같습니다.
https://sub.example.com/api/client/subscribe?token=abc123&target=clash웹 주소, 구매 페이지, 콘솔 로그인 주소와 구독 URL은 서로 다릅니다. 브라우저에서 열었을 때 계정 관리 화면, 요금제 정보 또는 로그인 양식이 보인다면 일반 웹페이지일 가능성이 큽니다. 올바른 메뉴는 보통 ‘Clash 구독’, ‘Clash Meta’, ‘구독 주소 복사’ 또는 ‘범용 구독’으로 표시됩니다. 서비스 제공업체가 여러 버튼을 제공한다면 Clash, Mihomo 또는 Clash Meta라고 명확히 표시된 형식을 우선 선택하세요.
복사한 뒤 다음 네 가지를 확인하세요
- 프로토콜이 완전한지: 주소에
https://또는http://가 포함되어야 하며, 도메인과 경로만 남아 있어서는 안 됩니다. - 불필요한 문자가 섞이지 않았는지: 링크 앞뒤에 ‘구독 주소:’, 따옴표, 공백 또는 줄바꿈이 없어야 합니다. 휴대전화에서 길게 눌러 복사할 때 설명 문장까지 함께 선택하기 쉽습니다.
- 쿼리 매개변수가 유지되었는지:
?뒤의 token, target 같은 매개변수가 인증 정보와 응답 형식을 결정할 수 있습니다. 임의로 잘라내면 401, 403 또는 형식 오류가 발생합니다. - 주소가 아직 유효한지: 구독을 초기화하거나 계정을 이전하거나 요금제를 변경하면 기존 URL이 즉시 만료될 수 있으므로 서비스 페이지에서 다시 복사해야 합니다.
공유 링크는 별도의 형식입니다. ss://, trojan://, vmess://, vless:// 또는 hysteria2://로 시작하는 문자열은 보통 하나의 노드만 설명하며, 정기적으로 업데이트되는 HTTP 구독 주소가 아닙니다. 일부 클라이언트는 단일 노드를 직접 가져올 수 있지만, ‘클립보드에서 가져오기’ 또는 ‘노드 추가’를 사용해야 하며 구독 URL 입력란에 넣어서는 안 됩니다.
Clash 구독 링크 표준 가져오기 단계
클라이언트마다 메뉴 이름은 조금씩 다르지만 처리 순서는 같습니다. 설정 관리 페이지를 열고 URL을 붙여 넣은 다음 설정을 다운로드하고 활성화한 뒤 노드와 트래픽 상태를 확인합니다. 다음 단계는 Mihomo 코어를 사용하는 일반적인 데스크톱 및 Android 클라이언트에 적용할 수 있습니다.
데스크톱: Clash Verge Rev 계열 클라이언트
- 클라이언트를 실행하고 왼쪽의 ‘구독’ 페이지로 이동합니다.
- 페이지 상단의 구독 주소 입력란에 전체 URL을 붙여 넣습니다.
- ‘가져오기’를 클릭하거나 Enter 키를 누르고 원격 설정 다운로드가 끝날 때까지 기다립니다. 네트워크가 정상이라면 보통 1~10초 안에 완료됩니다.
- 가져온 후 설정 카드에 노드 수, 업데이트 시간, 업데이트 버튼이 표시되는지 확인합니다.
- 설정 카드를 클릭해 현재 활성 구독으로 지정합니다. 일부 버전에서는 선택 상태 또는 ‘현재 설정’으로 표시됩니다.
- ‘프록시’ 페이지로 이동해 정책 그룹에서 지연 시간이 적절한 노드를 선택하거나 먼저 지연 시간 테스트를 실행합니다.
- ‘설정’ → ‘시스템 프록시’로 이동해 시스템 프록시를 켭니다. 시스템 프록시를 따르지 않는 프로그램까지 처리해야 할 때만 TUN 모드를 추가로 설정하세요.
Android: Clash Meta for Android 계열 클라이언트
- ‘설정’ 페이지로 이동해 오른쪽 위의 더하기 버튼을 누릅니다.
- ‘URL에서 가져오기’ 또는 ‘새 설정’ → ‘URL’을 선택합니다.
- 설정 이름을 입력합니다. 예를 들어 ‘일상 구독’이라고 지정한 뒤 URL 입력란에 전체 링크를 붙여 넣습니다.
- 자동 업데이트 간격은 우선
1440분, 즉 하루 한 번으로 설정할 수 있습니다. 서비스 제공업체에 별도 요구 사항이 있다면 안내에 맞게 조정하세요. - 저장하고 다운로드가 끝날 때까지 기다린 다음 설정 목록으로 돌아가 방금 만든 설정을 선택합니다.
- 홈으로 돌아가 서비스를 시작한 뒤 프록시 그룹에서 노드를 선택합니다. Android에서는 처음 실행할 때 VPN 연결 권한 창이 나타나며 시스템 확인이 필요합니다.
가져온 후 빠른 확인
가져오기가 끝난 뒤 다음 결과로 각 단계가 제대로 적용되었는지 확인할 수 있습니다.
- 설정 페이지에 구독 이름과 최근 업데이트 시간이 표시되고 파싱 오류가 더 이상 나타나지 않습니다.
- 프록시 페이지에서
PROXY,노드 선택,자동 선택같은 정책 그룹과 그룹 내부의 노드를 볼 수 있습니다. - 지연 시간 테스트에서 85ms, 210ms처럼 구체적인 값이 반환되며 계속 시간 초과로 표시되지 않습니다.
- 로그 페이지에 연결 기록이 나타나고 적용된 규칙, 대상 주소와 최종 정책이 표시됩니다.
- 업데이트 버튼으로 URL을 다시 붙여 넣지 않고도 설정을 다시 가져올 수 있습니다.
Clash 기본 YAML이란
Clash 기본 설정은 구조화된 YAML 파일입니다. 전체 설정에는 보통 수신 포트, 실행 모드, DNS, 노드, 정책 그룹과 규칙 등의 필드가 포함됩니다. Mihomo는 이 기본 구조를 이어받으면서 더 많은 프로토콜과 설정 기능을 추가했습니다. Clash에 맞는 원격 구독이 전체 YAML을 직접 반환한다면 클라이언트에서 대개 바로 파싱할 수 있습니다.
mixed-port: 7890
mode: rule
allow-lan: false
proxies:
- name: Example-Trojan
type: trojan
server: edge.example.com
port: 443
password: demo-password
sni: edge.example.com
proxy-groups:
- name: 노드 선택
type: select
proxies:
- Example-Trojan
- DIRECT
rules:
- GEOIP,CN,DIRECT
- MATCH,노드 선택이 예시는 전체 설정의 주요 구조를 갖춥니다. mixed-port: 7890은 HTTP와 SOCKS 요청이 로컬 혼합 포트를 함께 사용하게 하고, mode: rule은 규칙에 따라 트래픽을 분기한다는 뜻입니다. proxies에는 노드가 저장되고, proxy-groups는 사용자가 선택할 수 있는 정책을 구성하며, rules는 연결이 최종적으로 직접 연결될지 프록시를 통할지 결정합니다.
전체 설정과 프록시 컬렉션 YAML의 차이
확장자가 .yaml이라고 해서 모두 기본 설정으로 바로 사용할 수 있는 것은 아닙니다. 프록시 컬렉션 파일은 payload만 포함하는 경우가 있으며, 보통 기본 설정의 proxy-providers에서 참조합니다.
payload:
- name: Example-SS
type: ss
server: node.example.com
port: 8388
cipher: aes-128-gcm
password: demo-password이런 provider 파일을 일반 설정 가져오기 입력란에 직접 넣으면 클라이언트에서 proxies, proxy-groups 또는 rules가 없다고 표시할 수 있으며, 가져온 뒤 선택할 정책 그룹이 없을 수도 있습니다. provider 파일은 전체 기본 설정이 아니므로 proxy-providers, 정책 그룹과 규칙을 포함한 기본 YAML에서 불러와야 합니다.
| 콘텐츠 유형 | 일반적인 시작 부분 또는 필드 | Clash 설정으로 바로 사용 가능 여부 |
|---|---|---|
| 전체 Clash YAML | mixed-port、proxies、proxy-groups |
대체로 가능 |
| 프록시 컬렉션 YAML | payload: |
대체로 기본 설정에서 참조해야 함 |
| 규칙 컬렉션 YAML | payload: 뒤에 도메인 또는 규칙이 이어짐 |
기본 설정으로 단독 사용 불가 |
| 웹페이지 오류 콘텐츠 | <html>, 로그인 안내, 오류 페이지 |
불가 |
Base64 노드 목록을 인식하지 못할 수 있는 이유
범용 구독은 여러 노드 공유 링크를 줄바꿈으로 나열한 뒤 전체 텍스트를 Base64로 인코딩하는 경우가 많습니다. 디코딩한 내용은 다음과 비슷할 수 있습니다.
ss://[email protected]:8388#Example-SS
trojan://[email protected]:443?security=tls#Example-Trojan
vmess://encoded-json-data이 콘텐츠는 Clash YAML이므로 proxy-groups와 rules가 없습니다. 구독 변환을 지원하는 클라이언트는 가져오는 과정에서 노드 목록을 내부 설정으로 자동 변환할 수 있지만, Clash YAML만 지원하는 클라이언트는 YAML 파싱 실패나 설정 형식 오류를 표시하거나 가져온 뒤 정책 그룹이 없을 수 있습니다.
먼저 서비스 제공업체의 Clash 형식을 선택하세요
구독 페이지에 ‘범용 구독’, ‘Clash’, ‘Clash Meta’, ‘Surge’ 등의 옵션이 함께 있다면 Clash 또는 Clash Meta 링크를 우선 복사하세요. 구독 서버가 대상 형식을 직접 생성하므로 노드 프로토콜, 정책 그룹과 규칙이 현재 코어에 맞을 가능성도 높습니다.
범용 Base64 링크만 있다면 클라이언트가 해당 형식을 명시적으로 지원하는지 먼저 확인하세요. URL 확장자만 보고 판단해서는 안 됩니다. 많은 구독 주소에는 .yaml 확장자가 없고 쿼리 매개변수, 요청 헤더 또는 서버 설정으로 응답 형식이 결정됩니다. 브라우저에서 다운로드한 파일 이름이 subscribe여도 실제로는 유효한 YAML일 수 있습니다.
단일 노드 공유 링크는 Base64 구독과 다릅니다
vmess:// 뒤의 본문은 대개 자체적으로 Base64 인코딩된 데이터지만, 하나의 VMess 노드를 설명합니다. 반면 전체 Base64 구독은 인코딩 전에 여러 줄의 공유 링크를 포함합니다. 두 형식은 가져오기 메뉴가 다를 수 있습니다. 단일 링크라면 먼저 클라이언트의 ‘클립보드에서 가져오기’ 기능을 찾고, 장기간 자동 업데이트가 필요하다면 서비스 제공업체에 HTTPS 구독 URL을 요청하세요.
URL 가져오기 실패 시 오류 유형별 점검
‘가져오기 실패’라는 메시지가 같아도 네트워크 요청 실패와 형식 파싱 실패는 해결 방향이 완전히 다릅니다. 먼저 클라이언트에 표시된 상태 코드, 오류 문구와 발생 시간을 기록한 뒤 아래 표와 비교해 원인을 좁혀 보세요.
| 증상 또는 상태 | 일반적인 원인 | 우선 조치 |
|---|---|---|
| 시간 초과, 연결 실패 | 구독 도메인에 연결할 수 없음, DNS 이상, 현재 네트워크 제한 | 네트워크를 바꾸고 시스템 시간과 DNS를 확인한 뒤 다시 시도 |
| HTTP 401 또는 403 | 토큰 만료, 계정 상태 이상, 요청 제한 | 서비스 페이지에서 구독을 다시 복사하고 계정 상태 확인 |
| HTTP 404 | 경로 만료, 기존 구독 초기화 | URL을 직접 수정하지 말고 새 전체 주소 발급 |
| YAML 파싱 오류 | Base64, HTML 페이지 또는 손상된 YAML 들여쓰기가 반환됨 | Clash 형식을 선택했는지 확인하고 응답 콘텐츠 유형 확인 |
| 가져오기는 성공했지만 노드가 없음 | 규칙 집합, provider 파일 또는 빈 구독을 가져옴 | proxies와 정책 그룹이 있는지 확인 |
| 노드는 있지만 연결할 수 없음 | 노드 사용 불가, 시스템 시간 오차, 정책 미선택 | 시간을 맞추고 다른 노드를 테스트한 뒤 정책 그룹 확인 |
브라우저로 기본 상태 확인
구독 URL을 브라우저 주소창에 붙여 넣으면 링크에 아직 접속할 수 있는지 확인할 수 있습니다. 브라우저에서 텍스트 파일이 바로 다운로드된다면 서버가 최소한 응답하고 있다는 뜻입니다. 로그인 페이지, 요금제 페이지 또는 인증 페이지로 이동한다면 클라이언트가 설정이 아닌 HTML을 받았을 가능성이 있습니다. 브라우저에서 열린다고 해서 형식까지 올바른 것은 아닙니다. 서버가 클라이언트 요청 헤더에 따라 서로 다른 콘텐츠를 반환할 수 있기 때문입니다.
명령줄로 HTTP 상태 확인
터미널 사용에 익숙하다면 응답 헤더만 확인할 수 있습니다. 명령을 실행하기 전에 공유 화면, 터미널 기록 동기화 또는 공개 로그에 실제 토큰이 노출되지 않도록 주의하세요.
curl -I -L --max-time 15 "https://sub.example.com/api/client/subscribe?token=abc123&target=clash"-I는 응답 헤더만 요청하고, -L은 리디렉션을 따라가며, --max-time 15는 최대 대기 시간을 15초로 제한합니다. 결과의 200은 요청이 성공적으로 반환되었다는 뜻입니다. 301 또는 302 이후 최종적으로 로그인 페이지에 도달한다면 인증 또는 링크 문제일 가능성이 큽니다. 404는 경로가 존재하지 않는다는 뜻입니다. 일부 구독 서비스는 HEAD 요청에 응답하지 않으므로 명령은 실패할 수 있지만 클라이언트의 일반 GET 요청은 정상적으로 작동할 수 있습니다.
YAML 들여쓰기와 필드 확인
설정을 직접 저장하거나 편집할 때 YAML은 들여쓰기에 매우 민감합니다. 목록 항목 앞의 하이픈, 콜론 뒤의 공백, 같은 계층의 들여쓰기를 일관되게 유지해야 합니다. Tab 문자가 파서 오류를 일으킬 수도 있으므로 보통 공백 두 칸을 사용합니다. 원격 서버가 직접 생성한 구독이라면 노드 이름을 바꾸려고 다운로드 파일을 대규모로 수정하지 않는 것이 좋습니다. 다음 원격 업데이트에서 로컬 변경 사항이 덮어써지기 때문입니다.
자동 업데이트 간격과 로컬 설정 선택 방법
원격 구독은 노드 변경 사항을 동기화해야 하는 경우에 적합하고, 로컬 YAML은 규칙, DNS 또는 정책 그룹을 테스트할 때 유용합니다. 두 가지를 하나의 자동 업데이트 설정에 섞으면 업데이트 후 로컬 수정 사항이 사라질 수 있으므로 먼저 설정을 누가 관리할지 정해야 합니다.
업데이트 간격을 지나치게 짧게 설정하지 마세요
일반적인 자동 업데이트 간격은 1440분, 즉 24시간입니다. 노드 변경이 잦다면 360분 또는 720분으로 설정할 수 있습니다. 1~5분으로 설정하면 반복 요청이 대량으로 발생해 서버에서 접근 빈도를 제한할 수 있습니다. 일시적으로 최신 노드가 필요할 때는 ‘업데이트’를 한 번 직접 누르는 편이 적절합니다.
- 1440분: 일상적인 사용에 적합하며 업데이트 빈도가 안정적입니다.
- 720분: 하루 두 번 업데이트하며 노드 변경이 비교적 잦은 구독에 적합합니다.
- 360분: 6시간마다 업데이트하므로 서비스 제공업체가 해당 빈도를 허용하는지 확인해야 합니다.
- 수동 업데이트: 장기간 고정해 사용할 설정에 적합하며 필요할 때 새로고침합니다.
구독 업데이트 시 프록시를 거쳐야 할까요?
일부 클라이언트에는 ‘프록시를 통해 업데이트’ 또는 ‘시스템 프록시로 구독 업데이트’ 옵션이 있습니다. 구독 도메인에 현재 네트워크에서 직접 연결할 수 있다면 먼저 직접 연결로 업데이트해 경로를 단순하게 유지하세요. 직접 연결이 시간 초과되고 현재 프록시 노드를 사용할 수 있을 때만 프록시 업데이트를 시도하는 편이 좋습니다. 구독 업데이트가 현재 사용 중인 동일한 만료 설정에 의존하면 업데이트할 수 없는 순환이 생길 수 있으므로, 이때는 네트워크를 바꾸거나 먼저 다른 정상 설정을 활성화하세요.
복구 가능한 설정을 하나 보관하세요
DNS, TUN 또는 복잡한 규칙을 조정하기 전에 현재 정상적으로 작동하는 설정을 내보내거나 기본 로컬 설정을 하나 보관할 수 있습니다. 새 구독에서 필드 호환성 문제가 발생해도 먼저 네트워크를 복구한 뒤 계속 점검할 수 있습니다. 설정을 복구할 때는 기존 설정의 노드가 이미 만료되었을 수 있다는 점에 유의하세요. 백업의 핵심 가치는 포트, 규칙과 실행 매개변수를 보존하는 데 있습니다.
가져온 후 적용되지 않을 때 최종 점검 목록
구독에 ‘업데이트 성공’이 표시되는데도 웹페이지가 열리지 않는다면 다음 순서로 확인하세요. 한 번에 한 항목만 변경해야 문제가 설정, 노드 또는 시스템 연결 단계 중 어디에 있는지 쉽게 판단할 수 있습니다.
- 설정 목록에서 방금 가져온 구독이 선택되어 있는지 확인하세요. 기존 설정이나 비어 있는 로컬 설정이 선택되어 있으면 안 됩니다.
- 프록시 그룹으로 이동해 기본 정책을
DIRECT에서 지연 시간 테스트가 정상인 노드로 바꿉니다. - 실행 모드가 ‘규칙’ 또는 ‘전역’인지 확인하세요. 규칙 모드에서
DIRECT와 일치하는 웹사이트가 직접 연결되는 것은 정상입니다. - 데스크톱에서는 ‘설정’ → ‘시스템 프록시’를 열고, Android에서는 VPN 서비스가 실행 중인지 확인합니다.
- 로컬 포트 충돌 여부를 확인하세요. 일반적인 혼합 포트는
7890이지만 현재 설정의mixed-port값을 기준으로 판단해야 합니다. - 로그에 대상 연결이 나타나는지 확인하세요. 기록이 전혀 없다면 애플리케이션 트래픽이 Clash로 들어오지 않은 경우가 많습니다. 기록은 있지만 연결 시간 초과가 발생한다면 노드 또는 네트워크 문제에 가깝습니다.
- 시스템 프록시를 따르지 않는 프로그램에만 문제가 있다면 TUN 모드를 고려하세요. TUN을 구독 형식 오류의 해결책으로 사용해서는 안 됩니다.
구독 형식을 판단할 때 가장 유용한 단서는 파일명이 아니라 실제 응답 내용입니다. 전체 Clash YAML에는 노드, 정책 그룹과 규칙이 있어야 합니다. provider YAML은 기본 설정에서 참조하는 컬렉션만 포함합니다. Base64 범용 구독은 디코딩 후 대개 여러 공유 링크로 나타나며, HTML이라면 웹페이지나 오류 페이지를 받은 것입니다. ‘URL 확보 → 응답 다운로드 → 형식 식별 → 설정 활성화 → 트래픽 확인’ 순서로 점검하면 가져오기가 어느 단계에서 막혔는지 빠르게 찾을 수 있습니다.