Clash 구독 링크 가져오기 가이드: 세 가지 가져오기 방식과 주요 형식 안내

구독 링크는 원격 설정 파일을 가리키는 HTTP/HTTPS 주소로, 클라이언트가 주기적으로 이 주소에 요청을 보내면 서버는 YAML 또는 Base64로 인코딩된 노드와 규칙 모음을 반환합니다. 링크는 대개 프록시 서비스 제공업체의 사용자 센터에서 생성되며, 형식은 https://example.com/api/v1/sub?token=xxxx와 같이 쿼리 파라미터에 인증 토큰이 포함됩니다. 이 링크를 다른 사람에게 전달하는 것은 권장하지 않는데, 링크를 소유한다는 것은 곧 계정의 노드 사용 권한을 소유한다는 의미이기 때문입니다.

링크를 받은 뒤 브라우저에서 직접 열어볼 필요는 없습니다. 브라우저로 접속하면 대개 알 수 없는 문자열이 표시되거나 파일 다운로드가 시작되는데, 이는 응답 내용이 사람이 읽는 웹페이지가 아니라 클라이언트 프로그램이 해석하도록 만들어졌기 때문에 나타나는 정상적인 현상입니다. 올바른 사용 방법은 링크를 그대로 Clash 계열 클라이언트(Clash Verge, Clash for Windows 계열 포크, Clash Meta 코어 기반 프런트엔드 등)에 전달해, 요청·파싱·설정 작성까지의 전 과정을 클라이언트가 처리하도록 하는 것입니다.

URL 가져오기는 가장 널리 쓰이는 방식으로, 이후 업데이트 시 클라이언트가 자동으로 새로고침해 주기 때문에 파일을 직접 교체할 필요가 없다는 장점이 있습니다. 절차는 다음과 같습니다:

1. 클라이언트의 '구독' 또는 'Profiles' 관리 페이지를 엽니다.
2. '새로 만들기'나 '가져오기' 같은 버튼을 클릭하고 입력란에 구독 링크를 붙여넣습니다.
3. 선택적으로 구분하기 쉬운 이름을 입력합니다. 예를 들어 서비스 제공업체 이름과 요금제 종류를 조합한 형태가 좋습니다.
4. 확인을 누르면 클라이언트가 즉시 요청을 보내 원격 설정을 가져오고 로컬 캐시를 생성합니다.
5. 구독 목록에서 해당 항목을 선택하고 '활성화' 또는 '사용'을 클릭하면 규칙과 노드가 즉시 적용됩니다.

클립보드 가져오기는 브라우저 확장 프로그램, 채팅 앱, QR코드 스캔 결과 등에서 설정 텍스트나 링크를 복사했지만 클라이언트 창을 전환하기 번거로운 상황에 적합합니다. 대부분의 데스크톱 클라이언트는 구독 페이지에 '클립보드에서 가져오기' 버튼을 제공하며, 동작 방식은 다음과 같습니다:

1. 먼저 구독 링크 또는 완전한 YAML 설정 텍스트를 시스템 클립보드에 복사합니다.
2. 클라이언트로 돌아와 '클립보드에서 가져오기'를 클릭하면, 프로그램이 클립보드 내용이 링크인지 설정 본문인지 자동으로 판단합니다.
3. 링크로 인식되면 URL 가져오기와 동일하게 동작하며, 설정 본문으로 인식되면 곧바로 로컬 구독으로 저장되어 더 이상 원격 업데이트 기능을 갖지 않습니다.

모바일 클라이언트(안드로이드의 Clash Meta 계열 앱 등)도 동일한 기능을 제공하며, 다른 앱의 '공유' 기능으로 바로 넘어와 가져오기를 할 때 특히 유용해 직접 입력으로 인한 실수를 줄일 수 있습니다.

로컬 파일 가져오기는 오프라인 환경이거나 서비스 제공업체가 온라인 링크 대신 다운로드 파일만 제공하는 경우에 사용합니다. 일반적으로 .yaml, .yml 확장자를 사용하며, 예전 설정 중에는 .txt나 Base64 텍스트 형태로 배포되는 경우도 있습니다. 절차:

1. 설정 파일을 다운로드해 로컬 디스크에 저장하고 경로를 기억해 둡니다.
2. 클라이언트의 구독 페이지에서 '로컬 파일 가져오기' 또는 '설정 열기'를 선택합니다.
3. 시스템 파일 선택 창에서 해당 파일을 찾아 확인합니다.
4. 클라이언트가 파일 내용을 읽어 YAML 구조에 따라 노드, 프록시 그룹, 규칙 필드를 해석합니다.

URL 가져오기

일상적인 사용에 우선 추천, 자동 업데이트 지원, 구독 도메인에 접속할 수 있는 네트워크 환경이 필요

클립보드 가져오기

다른 앱과의 연계가 편리하며, 인식 결과는 클립보드 내용의 유형에 따라 달라짐

로컬 파일 가져오기

오프라인에서도 사용 가능, 업데이트 시 수동으로 다시 가져와야 하며 비상용 백업 설정에 적합

URL로 가져온 구독은 클라이언트 안에서 대개 '업데이트 주기' 항목을 갖고 있으며 단위는 시간이고 기본값은 보통 24시간입니다. 주기를 너무 짧게 설정하면 구독 서버에 대한 요청 빈도가 높아지는데, 일부 서비스 제공업체는 잦은 요청에 속도 제한이나 차단 정책을 적용하므로 기본값을 유지하거나 최소 6시간 이상으로 설정하는 것이 좋습니다. 수정 방법은 대개 구독 항목의 '편집' 창에서 interval 또는 '자동 업데이트 주기' 입력란을 찾아 값을 입력하고 저장하면 되며, 클라이언트를 다시 시작할 필요는 없습니다.

다음 자동 주기를 기다리고 싶지 않다면, 거의 모든 클라이언트가 구독 항목 옆에 원형 화살표 모양의 '즉시 업데이트' 버튼을 제공합니다. 클릭하면 원격 요청을 다시 보내 노드 목록을 새로고침하며, 대개 몇 초 안에 완료됩니다. 업데이트가 실패하는 흔한 원인으로는 링크 만료, 구독 도메인에 접속할 수 없는 네트워크 상태, 또는 로컬 프록시 스위치 상태와 구독 도메인 정책 간의 충돌 등이 있으며, 이런 경우 먼저 시스템 프록시를 잠시 끄고 다시 업데이트를 시도해 볼 수 있습니다.

대부분의 구독 서버는 HTTP 응답 헤더에 Subscription-Userinfo라는 필드를 함께 보내며, 내용은 upload=xxx; download=xxx; total=xxx; expire=xxx 형태입니다. 클라이언트가 이 필드를 해석하면 별도 설정 없이도 구독 항목에 사용한 트래픽, 총 트래픽, 만료일이 바로 표시됩니다. 확인 위치는 대개 구독 목록에서 해당 항목의 오른쪽이나 세부 정보를 펼친 부분이며, 진행 바나 '사용량/전체 용량' 텍스트로 표시됩니다.

주의할 점은 이 데이터가 구독 서버가 이번 응답을 보낸 시점의 스냅샷이며, 실시간 값이 아니라는 것입니다. 다른 기기에서 방금 트래픽을 많이 소모했다면, 로컬에 표시되는 숫자는 다음 구독 업데이트가 되어야 반영됩니다. 특정 구독에서 트래픽 정보가 계속 표시되지 않는다면 대개 서비스 제공업체가 응답 헤더에 해당 필드를 반환하지 않는 경우이며, 이럴 때는 서비스 제공업체의 사용자 센터에서 실제 사용량을 확인해야 합니다. 클라이언트 화면만으로는 이 데이터를 만들어낼 수 없습니다.

• 남은 트래픽이 부족할 때는 미리 교체나 갱신을 계획해, 사용 중 노드가 갑자기 끊기는 상황을 피하는 것이 좋습니다.
• 만료일 필드와 트래픽 필드는 서로 독립적이어서, 트래픽이 충분하더라도 만료일이 지나면 구독은 그대로 만료됩니다.
• 로컬 파일로 가져온 설정은 HTTP 응답 헤더 전달 과정을 거치지 않기 때문에 일반적으로 이런 정보를 포함하지 않습니다.

Clash 계열 클라이언트가 지원하는 구독 콘텐츠 형식은 크게 두 가지입니다:

• 네이티브 YAML 형식: proxies, proxy-groups, rules 등의 필드로 구성되며, Clash Meta(mihomo 코어)는 이를 바탕으로 Hysteria2, TUIC, WireGuard 등 더 많은 프로토콜 필드와 규칙 유형을 확장했습니다. 오래된 버전의 코어가 확장 필드를 인식하지 못하면 건너뛰거나 오류를 내는데, 가져온 뒤 노드 수가 비정상적으로 적다면 대개 코어 버전이 오래된 탓입니다.
• Base64로 인코딩된 노드 목록: 초기 V2Ray/Shadowsocks 공유 링크 모음에서 자주 볼 수 있으며, 일부 클라이언트는 자동으로 인식해 Clash 규칙 세트로 변환하지만, 일부는 변환 서비스를 이용해 표준 YAML을 생성한 뒤 가져와야 합니다. 이런 링크를 그대로 Clash 구독으로 사용하면 해석에 실패할 수 있습니다.

proxies:
  - name: "예시 노드-HK-01"
    type: trojan
    server: example.node.tld
    port: 443
    password: "예시 비밀번호"
    sni: example.node.tld
    udp: true

위 예시는 가장 단순화한 Trojan 노드 필드 예시로, 실제 구독 파일에는 이런 항목이 여러 개 반복되며 proxy-groups로 노드를 분류하고 rules로 어떤 도메인이나 IP 대역이 어느 그룹을 거칠지 결정합니다. 가져오기 전에 이 필드들을 직접 수정할 필요는 없으며 클라이언트가 자동으로 해석하고, 직접 설정을 만들거나 이상 노드를 디버깅할 때만 하나씩 확인하면 됩니다.