Clash 구독 링크 가져오기: 클라이언트별 설정 방법과 주요 구독 형식 안내

가져오기 전에 링크와 설정 형식 확인하기

Clash 클라이언트에서 ‘구독’은 일반적으로 HTTP 또는 HTTPS로 다운로드할 수 있는 원격 설정 주소를 의미합니다. 클라이언트가 해당 주소에 요청을 보내면 서버는 YAML 설정, 인코딩된 노드 목록 또는 특정 클라이언트용으로 변환된 결과를 반환합니다. 브라우저에서 링크가 열린다고 해서 그 내용이 반드시 Mihomo 코어에서 읽힌다는 뜻은 아닙니다. 반환 내용, 설정 필드, 클라이언트 지원 범위를 함께 확인해야 합니다.

구독 주소에는 사용자 식별자, 액세스 토큰 또는 단기간 유효한 인증 매개변수가 포함되는 경우가 많습니다. 복사할 때는 물음표 뒤의 매개변수를 포함한 전체 쿼리 문자열을 보존하고, 끝부분을 임의로 삭제하지 마세요. 이 주소는 설정에 접근하기 위한 인증 정보와 같으므로 스크린샷, 로그 또는 문의 내용에는 도메인만 남기고 경로와 매개변수는 가려야 합니다.

Clash 표준 YAML 설정

표준 설정은 Clash와 Mihomo 클라이언트에서 가장 직접적으로 사용할 수 있는 입력 형식입니다. 텍스트의 시작 부분에 특정 필드 순서가 요구되지는 않지만, 일반적으로 mixed-port, proxies, proxy-groups, rules, dns 등의 키를 확인할 수 있습니다. 최소 구조는 다음과 같은 형태입니다:

mixed-port: 7890
mode: rule
proxies:
  - name: example-node
    type: socks5
    server: 192.0.2.10
    port: 1080
proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - example-node
rules:
  - MATCH,PROXY

실제 구독에는 프로토콜 인증, TLS, UDP, 규칙 집합 및 DNS 설정이 함께 포함되는 경우가 많습니다. rule-providers, sniffer, tun과 일부 프로토콜 매개변수 같은 Mihomo 확장 필드는 해당 필드를 지원하는 코어에서 해석해야 합니다. 구버전 Clash 클라이언트는 확장 필드를 만나면 오류를 표시하거나, 인식할 수 없는 부분을 무시할 수 있습니다.

Base64 노드 구독

Base64 구독을 디코딩하면 일반적으로 줄마다 하나씩 공유 링크가 나열되며, 예를 들어 ss://, trojan://, vmess://, vless:// 등이 포함됩니다. 이 반환값은 완전한 Clash YAML이 아닙니다. 보통 정책 그룹, 규칙, DNS 및 TUN 매개변수가 없습니다. 일부 클라이언트는 노드 목록을 직접 해석해 기본 설정을 생성하지만, 다른 클라이언트는 YAML만 허용합니다. 이 경우 ‘설정 형식 오류’ 또는 ‘proxies 필드 누락’이 표시될 수 있습니다.

단일 공유 링크와 범용 구독

프로토콜 이름으로 시작하는 단일 URI는 하나의 노드만 설명합니다. 클라이언트의 ‘노드 가져오기’ 메뉴에는 적합하지만 ‘원격 설정 URL’ 입력란에는 사용할 수 없을 수 있습니다. 범용 구독은 요청 헤더를 기준으로 클라이언트를 식별해 서로 다른 형식을 반환하기도 합니다. 같은 주소가 브라우저에서는 Base64로 보이지만 클라이언트에서는 Clash YAML로 반환될 수 있으며, 이는 서버가 User-Agent에 맞춰 응답한 결과입니다.

데스크톱 클라이언트 가져오기

데스크톱 클라이언트마다 메뉴 이름은 조금씩 다르지만 기본 흐름은 같습니다. 원격 설정을 새로 만들고 URL을 입력한 뒤 설정을 다운로드하고 활성화한 다음 정책 그룹을 선택합니다. 아래 경로는 일반적인 버전의 화면을 기준으로 했습니다. 메뉴 배치가 달라졌다면 ‘구독’, ‘설정’ 또는 ‘Profiles’ 페이지에서 URL 가져오기 메뉴를 찾아보세요.

Clash Verge Rev

클라이언트를 열고 ‘구독’ 페이지로 이동합니다.
전체 구독 주소를 상단 URL 입력란에 붙여 넣고 주소가 https:// 또는 http://로 시작하는지 확인합니다.
‘가져오기’를 선택합니다. 클라이언트가 원격 요청을 보내고, 다운로드에 성공한 설정을 구독 카드로 표시합니다.
새 설정 카드를 클릭해 현재 활성 설정으로 지정합니다.
‘프록시’ 페이지로 이동해 PROXY, 노드 선택 또는 비슷한 이름의 정책 그룹에서 노드를 선택합니다.
‘설정’ → ‘시스템 설정’으로 이동해 필요할 때 시스템 프록시를 켭니다. 더 많은 애플리케이션의 트래픽을 가로채야 할 때만 TUN 모드 활성화를 검토하세요.

가져온 뒤 카드가 표시되지만 프록시 페이지가 비어 있다면 시스템 프록시를 반복해서 켜지 마세요. 설정 세부 정보에서 다운로드 시간과 파일 크기를 확인한 다음 로그에서 YAML 해석 오류를 확인하세요. 일반적으로 사용하는 로컬 수신 포트는 혼합 포트 7890이지만 설정에서 이 값을 덮어쓸 수 있습니다. 브라우저에 프록시를 수동 설정할 때는 현재 실행 중인 설정에 표시된 포트를 사용해야 합니다.

Mihomo Party

‘구독’ 페이지로 이동해 ‘추가’를 선택합니다.
원격 구독 유형을 선택하고 이름과 구독 URL을 입력합니다.
저장한 뒤 한 번 업데이트를 실행하고 상태가 ‘다운로드 중’에서 ‘사용 가능’으로 바뀔 때까지 기다립니다.
방금 추가한 구독을 선택해 현재 설정으로 지정합니다.
‘프록시’ 페이지에서 정책 그룹과 노드를 선택한 다음 ‘설정’에서 시스템 프록시 또는 TUN을 켭니다.

Mihomo Party는 Mihomo 코어를 사용하므로 Mihomo 확장 필드가 포함된 설정을 읽는 데 적합합니다. 구독이 원격 규칙 집합을 참조한다면 최초 로드 시 rule-providers가 가리키는 파일도 계속 다운로드합니다. 주 설정은 정상적으로 다운로드됐지만 규칙 집합 다운로드에 실패한 경우 로그에는 두 요청이 별도로 기록됩니다. 문제를 확인할 때 구독 도메인과 규칙 집합 도메인을 구분하세요.

FlClash

‘설정’ 페이지를 열고 오른쪽 위의 추가 버튼을 선택합니다.
‘URL’을 선택하고 구독 링크를 붙여 넣은 뒤 알아보기 쉬운 이름을 입력합니다.
가져오기를 확인하고 설정 카드가 나타날 때까지 기다립니다.
설정을 선택한 뒤 ‘프록시’로 돌아가 정책 그룹을 펼치고 노드를 선택합니다.
‘도구’ 또는 ‘설정’ 영역에서 시스템 프록시를 활성화합니다. 데스크톱에서 모든 트래픽을 가로채야 할 때만 TUN을 켜세요.

FlClash는 여러 데스크톱 및 모바일 플랫폼을 지원하며 창 너비에 따라 화면 구성이 달라집니다. 좁은 창에서는 설정 메뉴가 하단 탐색 메뉴나 더보기 메뉴 안으로 들어갈 수 있지만, URL·파일·클립보드는 일반적으로 서로 다른 가져오기 방식으로 제공됩니다. 원격 구독은 URL을 선택하고, 로컬에 다운로드한 YAML은 파일을 선택하세요.

Android 및 iOS 클라이언트에서 가져오기

Clash Meta for Android

‘설정’으로 이동하고 오른쪽 위의 더하기 버튼을 누릅니다.
‘URL에서 가져오기’를 선택합니다.
설정 이름, 구독 URL 및 자동 업데이트 간격을 입력합니다.
저장한 뒤 다운로드가 완료될 때까지 기다리고, 해당 설정을 눌러 적용합니다.
메인 화면으로 돌아가 ‘시작’을 누른 다음 시스템에 표시되는 VPN 연결 권한을 확인합니다.
‘프록시’로 이동해 정책 그룹을 확인하고 연결할 수 없는 이전 노드가 선택되어 있지 않은지 확인합니다.

Android용 Clash Meta 클라이언트는 일반적으로 시스템 VPN 인터페이스를 통해 트래픽을 가로채므로 각 앱에 127.0.0.1:7890을 따로 입력할 필요가 없습니다. 처음 시작할 때 VPN 권한 대화상자가 나타나는 것은 정상적인 시스템 절차입니다. Android VPN 인터페이스는 동시에 하나의 앱만 사용할 수 있습니다. 다른 VPN, 필터 또는 프록시 도구가 실행 중이라면 먼저 중지한 뒤 현재 설정을 시작하세요.

자동 업데이트 간격은 너무 짧게 설정하지 않는 것이 좋습니다. 노드 정보가 자주 바뀌지 않는다면 먼저 1440분, 즉 하루 한 번으로 설정하세요. 규칙을 자주 조정하는 설정에는 360분을 사용할 수 있습니다. 15분으로 설정하면 중복 요청이 많아지고 구독 서비스의 요청 빈도 제한에 걸릴 수 있습니다.

FlClash 모바일 버전

Android의 FlClash 가져오기 절차는 데스크톱과 비슷합니다. ‘설정’ → ‘추가’ → ‘URL’로 이동해 링크를 붙여 넣고 다운로드한 뒤 활성화하세요. 서비스를 시작하기 전 시스템 VPN 권한에도 동의해야 합니다. 가져오기에 성공하면 홈 화면의 시작 상태만 확인하지 말고 프록시 그룹으로 이동해 노드를 확인하세요.

iOS에서의 호환 범위

iOS 클라이언트는 각 앱에서 설정 해석을 직접 구현합니다. Clash 규칙 구조를 지원하는 Stash 계열 클라이언트에서는 원격 설정 또는 설정 관리 페이지에서 URL 다운로드를 선택한 뒤 반환된 설정을 현재 설정으로 지정할 수 있습니다. 구체적인 메뉴는 클라이언트 버전에 따라 달라지므로 가져오기 전에 구독 제공자가 해당 클라이언트에서 지원하는 형식을 안내하는지 확인하세요.

일부 iOS 도구는 노드 구독과 단일 공유 링크만 주로 처리하며 Clash YAML의 정책 그룹, 스크립트, 규칙 집합 및 DNS 필드를 완전히 적용하지 않습니다. 같은 주소를 가져온 뒤 노드만 표시되고 원래 설정의 규칙 그룹이 보이지 않는다면 클라이언트가 형식을 변환한 경우가 많습니다. 원격 파일 자체에 규칙이 없다는 뜻은 아닙니다.

가져온 뒤 노드·정책 그룹·규칙이 로드됐는지 확인하기

‘가져오기 성공’은 클라이언트가 설정 기록을 저장했다는 뜻일 뿐입니다. 완전히 확인하려면 설정 내용, 코어 실행 상태, 정책 그룹 선택, 실제 연결의 네 가지 단계를 모두 점검해야 합니다. 다음 순서대로 확인하면 규칙 문제를 구독 다운로드 문제로 잘못 판단하는 일을 줄일 수 있습니다.

1단계: 설정 업데이트 시간과 콘텐츠 규모 확인

설정 카드에는 며칠 전의 캐시 시간이 아니라 방금 업데이트된 시간이 표시되어야 합니다.
원격 파일 크기가 0이어서는 안 됩니다. 수십 바이트에 불과하다면 오류 메시지나 로그인 페이지가 반환됐을 수 있습니다.
설정 세부 정보에서 노드 수를 확인할 수 있어야 합니다. 20개 노드가 예상되는데 1개만 표시된다면 단일 공유 링크를 잘못 가져온 것은 아닌지 확인하세요.
설정에 규칙이 선언되어 있다면 proxies뿐 아니라 rules 또는 원격 규칙 집합도 표시되어야 합니다.

2단계: 코어 실행 확인

설정을 전환한 뒤 실행 상태와 로그를 확인하세요. 정상이라면 설정 로드, 수신 포트 시작, 컨트롤 인터페이스 사용 가능 등의 기록이 표시됩니다. 로그가 해석 단계에서 멈췄다면 첫 번째 오류의 필드를 기준으로 확인하세요. 이후에 이어지는 다수의 오류는 앞선 들여쓰기, 필드 형식 또는 호환되지 않는 매개변수 때문에 발생하는 경우가 많습니다.

YAML은 공백으로 계층을 표현합니다. Tab, 콜론 누락, 잘못된 들여쓰기는 모두 해석 실패를 일으킬 수 있습니다. 예를 들어 rules는 목록이어야 하며, 전체 규칙을 줄바꿈하지 않은 하나의 문자열로 작성할 수 없습니다. 원격 구독을 서버에서 생성한다면 캐시 파일을 매번 직접 수정하기보다 제공자에게 원본 설정 수정을 요청하는 것이 좋습니다.

3단계: 정책 그룹 선택 확인

‘프록시’ 페이지로 이동해 정책 그룹을 단계별로 펼칩니다. 최종 출구 그룹이 DIRECT로 선택되어 있으면 클라이언트가 실행 중이어도 해당 그룹에 매칭되는 연결은 직접 연결됩니다. url-test 또는 fallback 자동 그룹을 선택했다면 최소 하나의 노드에서 지연 시간 테스트가 완료됐는지 확인하세요.

지연 시간 테스트에서 80ms가 표시된다는 것은 테스트 URL에 해당 노드로 접근할 수 있다는 뜻일 뿐, 모든 웹사이트에 연결할 수 있다는 의미는 아닙니다. 실제 요청을 한 번 더 보내고 연결 기록에서 도메인, 매칭된 규칙, 정책 그룹, 최종 노드를 확인하세요. 예를 들어 DOMAIN-SUFFIX가 매칭된 뒤 PROXY로 전달되고, 해당 그룹이 구체적인 노드를 선택하는 기록이 보여야 규칙 경로가 정상적으로 이어진 것입니다.

4단계: 프록시 모드 확인

모드	트래픽 동작	확인할 사항
규칙	rules를 위에서 아래로 매칭하고, 매칭된 정책을 사용합니다	연결 기록에서 규칙과 정책 그룹 확인
전역	모든 연결을 전역 정책 그룹으로 전달합니다	전역 그룹에서 사용 가능한 노드가 선택되어 있는지 확인
직접 연결	연결이 프록시 노드를 거치지 않습니다	기준선 테스트에 사용하며 노드 출구 확인에는 사용하지 않습니다

가져오기 결과를 확인할 때는 먼저 규칙 모드를 사용하는 것이 좋습니다. 구독이 원래 설계한 트래픽 분배 로직을 유지할 수 있기 때문입니다. 일시적으로 전역 모드로 전환하면 노드의 기본 연결성을 확인할 수 있지만 테스트가 끝나면 규칙 모드로 돌아가야 합니다. 모드 전환은 새 연결에만 영향을 줍니다. 이미 연결된 브라우저의 장시간 연결은 기존 경로를 계속 사용할 수 있으므로 해당 탭을 닫거나 앱을 다시 시작한 뒤 재테스트하세요.

구독 가져오기 실패 시 자주 표시되는 메시지와 해결 방법

HTTP 401, 403 또는 404

401과 403은 일반적으로 인증 매개변수 누락, 토큰 만료, 접근 출처 제한 또는 구독 비활성화를 의미합니다. 404는 주소 경로가 존재하지 않는다는 뜻이며, 서버가 유효하지 않은 토큰을 숨기기 위해 이 상태 코드를 사용할 수도 있습니다. 구독 관리 페이지에서 전체 주소를 다시 복사하고, 브라우저 주소창의 관리 페이지 URL만 복사하지 마세요. 링크에 & 매개변수가 있다면 메신저나 메모 앱이 뒷부분을 잘라내지 않았는지도 확인하세요.

요청 시간 초과 또는 연결 거부

구독 업데이트가 프록시 시작 전에 실행되면 클라이언트는 보통 로컬 네트워크를 통해 구독 도메인에 직접 연결합니다. 프록시가 이미 실행 중인 경우 일부 클라이언트는 업데이트 요청을 현재 프록시를 통해 보낼 수 있습니다. 구독 도메인에 프록시를 통해서만 접근할 수 있다면 ‘설정을 다운로드하지 못해 프록시를 시작할 수 없고, 프록시가 시작되지 않아 설정을 다운로드할 수 없는’ 순환이 생길 수 있습니다. 먼저 연결 가능한 네트워크에서 최초 가져오기를 완료하거나, 클라이언트가 지원한다면 구독 업데이트 요청 경로를 조정하세요.

로컬 HTTP 프록시의 일반적인 주소는 127.0.0.1:7890이고 SOCKS 포트는 보통 127.0.0.1:7891이지만 이는 어디까지나 자주 쓰이는 기본값입니다. 포트를 다른 프로그램이 사용 중이면 코어가 시작되지 않을 수 있으며 로그에 bind 또는 address already in use가 표시됩니다. 이때 현재 설정의 mixed-port, port, socks-port를 확인해 중복 수신을 피하세요.

YAML 해석 오류 메시지가 표시될 때

먼저 설정 세부 정보에서 반환된 내용이 HTML이 아닌지 확인하세요. 파일 시작 부분에 <!doctype html>, 로그인 안내 또는 오류 페이지가 보인다면 클라이언트가 YAML이 아닌 내용을 받은 것입니다. 실제로 YAML이라면 로그에 표시된 줄 번호와 필드명을 기록하고 들여쓰기, 불리언 값의 형식, 목록 구조, 해당 프로토콜 필드를 코어가 지원하는지 중점적으로 확인하세요.

노드는 있지만 규칙과 정책 그룹이 사라진 경우

Base64 노드 구독을 가져왔거나 클라이언트가 범용 구독을 기본 설정으로 변환했을 때 흔히 발생합니다. 노드 목록에는 연결 매개변수만 있고 완전한 트래픽 분배 설계는 포함되지 않습니다. 규칙 기반 분배가 필요하다면 Clash 또는 Mihomo YAML 구독을 받아야 합니다. 또는 클라이언트의 로컬 오버라이드 기능으로 정책 그룹, DNS 및 규칙을 보완할 수 있습니다. 오버라이드하기 전에 원본 설정을 저장해 구독 업데이트 후 필드가 중복되는 일을 방지하세요.

업데이트 후 설정이 바뀌지 않는 경우

먼저 클라이언트에 표시된 업데이트 시간을 확인한 뒤 수동 업데이트를 한 번 실행하세요. 업데이트 시간은 바뀌었지만 노드가 그대로라면 서버 콘텐츠가 실제로 갱신되지 않았을 수 있습니다. 업데이트 시간도 그대로라면 요청이 캐시에 걸렸는지, 자동 업데이트가 활성화되어 있는지, 클라이언트가 같은 이름의 다른 설정 카드를 사용하고 있지 않은지 확인하세요. 설정을 삭제하면 로컬 선택 상태도 함께 지워지므로 일반적으로 첫 단계로 권장하지 않습니다.

자동 업데이트·오버라이드·TUN 설정 순서

구독 가져오기가 안정된 뒤 자동 업데이트와 로컬 오버라이드를 조정하세요. 권장 순서는 원격 YAML이 독립적으로 로드되는지 먼저 확인하고, 360~1440분의 업데이트 간격을 설정한 다음, 소량의 오버라이드를 추가하고, 마지막으로 시스템 프록시 또는 TUN을 테스트하는 것입니다. 여러 계층을 한 번에 변경하면 실패 지점을 찾기 어려워집니다.

자동 업데이트 간격

노드 변경이 적은 경우: 1440분, 하루 한 번 확인합니다.
규칙 또는 노드를 자주 조정하는 경우: 360분, 6시간마다 확인합니다.
설정 수정이 완료되기를 잠시 기다리는 경우: 수동 업데이트를 사용하고 5분 또는 10분 간격으로 반복 요청하지 마세요.

클라이언트 절전, 시스템의 백그라운드 활동 제한 또는 모바일 절전 정책으로 업데이트가 지연될 수 있습니다. 따라서 자동 업데이트 간격은 예정된 주기일 뿐 정확히 해당 시각에 실행된다는 보장은 없습니다. 새 콘텐츠를 즉시 받아야 한다면 설정 페이지에서 수동 업데이트를 실행하고 업데이트 시간이 실제로 변경됐는지 확인하세요.

로컬 오버라이드의 적용 범위

오버라이드는 수신 포트 변경, 로컬 네트워크 직접 연결 규칙 추가, DNS 서버 조정, TUN 매개변수 보완 등 기기별 차이를 반영하는 데 적합합니다. 오버라이드 파일에 많은 노드를 복사해 넣지는 마세요. 구독이 업데이트된 뒤 오래된 항목이 남기 쉽습니다. 규칙 순서도 중요합니다. Clash는 위에서 아래로 매칭하므로 새로 추가한 로컬 네트워크 규칙을 MATCH 뒤에 배치하면 실행되지 않습니다.

TUN 모드는 구독 해석 여부를 결정하지 않습니다

TUN은 운영체제 트래픽을 가로채고, 구독 가져오기는 설정을 받아 해석하는 역할을 합니다. 두 단계는 서로 다릅니다. YAML 해석에 실패했을 때 TUN을 켜도 설정이 복구되지는 않습니다. 노드와 규칙이 정상적으로 로드됐지만 일부 앱이 시스템 프록시를 따르지 않을 때 TUN을 트래픽 가로채기 방식으로 테스트해야 합니다. 활성화한 뒤 연결을 새로 만들고 연결 목록에 대상 앱의 요청이 나타나는지 확인하세요.

반복 실행 가능한 구독 가져오기 체크리스트

Clash 또는 Mihomo 구독 URL을 복사했는지 확인하고, 관리 웹페이지나 QR 코드 주소는 사용하지 않습니다.
URL의 전체 경로, 쿼리 매개변수 및 프로토콜 접두사를 그대로 유지합니다.
클라이언트의 ‘구독’ 또는 ‘설정’ 페이지에서 URL 가져오기를 선택하고 로컬 파일을 잘못 선택하지 않습니다.
다운로드 후 업데이트 시간, 노드 수, 정책 그룹 및 규칙이 예상과 일치하는지 확인합니다.
새 설정을 활성화하고 코어가 시작되며 로컬 수신 포트에 충돌이 없는지 확인합니다.
프록시 그룹에서 노드를 선택한 다음 시스템 프록시 또는 모바일 VPN 서비스를 켭니다.
규칙 모드로 새 연결을 만들고 연결 기록에서 규칙, 정책 그룹 및 최종 노드를 확인합니다.
안정적으로 실행된 뒤 자동 업데이트, 오버라이드 및 TUN을 설정하고 여러 변수를 동시에 변경하지 않습니다.

구독 가져오기의 핵심은 ‘추가’를 한 번 클릭하는 데 있지 않습니다. 원격 콘텐츠가 클라이언트가 지원하는 설정인지 확인하고 다운로드, 해석, 활성화, 트래픽 매칭으로 이어지는 전체 경로를 검증해야 합니다. 문제가 발생하면 HTTP 요청, 반환 형식, 코어 해석, 정책 선택, 시스템 가로채기 순서로 확인하면 대개 문제를 하나의 단계로 좁힐 수 있습니다.