Clash 구독 링크 가져오는 방법: 전체 YAML, 노드 목록 및 공유 링크 차이

1. 입력 내용을 먼저 확인한 뒤 가져오기 방법 선택

“링크를 복사해 가져오기”는 클라이언트가 인식할 수 있는 입력에만 사용할 수 있습니다. 구독 URL은 콘텐츠를 가져오는 주소이고, YAML은 설정 텍스트 형식이며, 단일 노드 공유 링크는 특정 노드의 매개변수를 담는 방식입니다. 이 셋은 같은 계층에 있지 않습니다. 동일한 HTTPS 주소라도 전체 설정, 노드 목록 또는 로그인 페이지를 반환할 수 있습니다. 브라우저에서 주소가 열린다고 해서 Clash 설정으로 불러올 수 있다는 뜻은 아닙니다.

클라이언트는 화면, 구독 다운로드, 설정 관리를 담당하고, Clash 또는 Clash Meta(mihomo) 같은 코어는 유효한 설정을 해석하고 프록시 연결을 만들며 규칙 매칭과 DNS 처리를 담당합니다. 일부 클라이언트에는 형식 변환 기능이 있지만, 이를 근거로 모든 Clash 클라이언트가 임의의 공유 링크를 직접 가져올 수 있다고 판단해서는 안 됩니다. 시작하기 전에 “정보” 또는 코어 정보 화면에서 클라이언트 버전과 코어 버전을 기록하세요. 두 버전은 서로를 대신할 수 없습니다.

현재 가진 콘텐츠	일반적인 특징	찾아야 할 메뉴
원격 구독 URL	`https://`로 시작하며 인증 매개변수가 포함될 수 있음	원격 설정, URL 가져오기 또는 새 구독 만들기
로컬 YAML 파일	일반적으로 `.yaml` 또는 `.yml`이며 구조화된 텍스트로 구성됨	로컬 설정, 파일에서 가져오기
노드 프로바이더 콘텐츠	일반적으로 최상위에 `proxies:`가 있으며 프록시 그룹과 규칙은 없음	기본 설정의 `proxy-providers`에서 참조
단일 노드 공유 링크	`ss://`, `vmess://`, `trojan://` 등으로 시작	클라이언트가 명시적으로 제공하는 노드 가져오기 또는 변환 메뉴

2. 구독 URL 가져오기: 다운로드, 선택, 적용의 세 단계

먼저 현재 코어에 맞는 구독 주소 가져오기

구독 제공업체의 관리 페이지에서 클라이언트 코어와 호환되는 Clash 또는 mihomo 출력을 선택하세요. 계정 센터 페이지의 주소를 그대로 복사하거나 “원클릭 가져오기” 버튼의 클라이언트 호출 프로토콜을 HTTPS 구독 주소로 사용하지 마세요. 제공업체가 구형 Clash와 mihomo를 구분한다면 데스크톱 바로 가기 이름이 아니라 실제 실행 중인 코어를 기준으로 선택해야 합니다.

복사 결과 확인: 링크 앞뒤에 따옴표, 공백 또는 메신저가 덧붙인 문장 부호가 없어야 합니다. 기존 인증 매개변수는 유지하세요. 매개변수를 수정하면 서버가 접근을 거부할 수 있습니다.
원격 설정 만들기: 클라이언트의 “설정” 또는 “구독” 페이지에서 URL 입력란이나 원격 설정 생성 메뉴를 찾아 주소를 붙여 넣고 다운로드하세요. 클라이언트마다 버튼 이름과 배치는 다를 수 있습니다.
가져오기 결과 확인: 설정 목록에 새 항목이 추가되었는지 확인하고 업데이트 시간, 노드 수, 다운로드 오류를 점검하세요. 설정 이름만 표시된다고 해서 콘텐츠가 올바르게 해석되었다고 볼 수는 없습니다.
선택 후 적용: 새 항목을 현재 설정으로 지정하세요. 일부 클라이언트는 가져온 뒤에도 기존 설정을 사용하므로 설정 카드를 다시 클릭하거나 적용 작업을 수행해야 합니다.
실행 상태 확인: 코어가 실행 중인지, 프록시 그룹이 표시되는지, 알 수 없는 프로토콜이나 대상 없음 오류가 없는지 확인한 뒤 연결을 테스트하세요.

Profiles 페이지와 URL 입력란이 있는 구형 Clash for Windows 화면을 예로 들면 경로는 일반적으로 Profiles → URL 입력란 → Download이며, 이후 해당 설정 카드를 선택해야 합니다. 이는 구형 화면의 메뉴 예시일 뿐 현재도 유지 관리된다는 뜻이 아니며 모든 클라이언트에 적용되지도 않습니다. 최신 클라이언트에서는 “원격 설정”이라는 기능의 의미에 맞는 메뉴를 찾으세요.

처음 가져올 때 TUN을 켜고 DNS를 변경하며 모든 규칙까지 한꺼번에 바꿀 필요는 없습니다. 먼저 설정이 로드되는지 확인한 다음 프록시 적용 방식을 점검해야 문제 범위를 한 단계로 좁힐 수 있습니다. 구독 다운로드 자체에 기존 프록시가 필요하다면 작동하는 기존 설정을 사용하거나 제공업체가 지원하는 네트워크 경로로 가져오세요. 새 설정은 아직 다운로드되지 않았으므로 자신의 다운로드 문제를 해결하는 데 사용할 수 없습니다.

3. 로컬 YAML: 콘텐츠 완전성과 참조 관계 확인

로컬 가져오기는 오프라인 설정, 백업 복원, 수동 편집에 적합합니다. 파일 확장자는 단서일 뿐입니다. 웹페이지 파일의 이름을 config.yaml로 바꾼다고 설정 파일이 되지는 않습니다. 일반 텍스트 편집기로 파일을 열어 <html>, 로그인 안내 또는 API 오류 메시지가 있는지 확인하세요. YAML 들여쓰기는 공백을 사용하며 Tab을 섞지 마세요. 편집기에서 실제 확장명을 표시하도록 설정해 config.yaml.txt로 저장되는 일을 방지하세요.

완전한 설정은 “proxies만 있으면 충분하다”는 뜻이 아닙니다

예상한 프록시 분산 처리를 수행할 수 있는 설정에는 일반적으로 노드 또는 노드 프로바이더, 프록시 그룹, 규칙, 적절한 리스닝 설정이 필요합니다. 필수 필드는 코어의 기본값과 클라이언트 생성 방식에 따라 달라질 수 있지만, 규칙 대상은 반드시 해석 가능해야 합니다. 규칙이 Proxy를 가리킨다면 같은 이름의 프록시 그룹이나 노드가 있어야 하며, 화면에 표시되는 이름만으로 존재 여부를 추정해서는 안 됩니다.

# 설정 예시: 구조만 확인하며 원격 프록시 노드는 포함하지 않음
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,Proxy

로컬 파일을 가져온 뒤 원래 구독의 자동 업데이트 관계가 유지된다고 가정해서는 안 됩니다. 클라이언트가 파일을 자체 설정 디렉터리에 복사할 수도 있고 원래 경로를 직접 참조할 수도 있습니다. 데스크톱에 있는 원본 파일을 편집해도 현재 실행 중인 복사본에는 반영되지 않을 수 있습니다. 현재 설정 항목의 편집 또는 보기 기능으로 실제 콘텐츠를 확인한 뒤 수정하고 다시 로드하세요. 작업 전에 config-backup-2026-06-16.yaml처럼 날짜가 포함된 백업을 저장하세요.

파일에서 proxy-providers 또는 rule-providers를 사용하는 경우 로컬 YAML은 진입점일 뿐이며, 시작할 때 외부 리소스를 다운로드해야 할 수 있습니다. 기본 파일을 복사한다고 모든 종속 항목까지 복사되는 것은 아닙니다. 프로바이더 경로, 원격 주소, 캐시를 사용할 수 있는지 확인하세요. 특히 다른 기기에서 설정을 옮길 때는 기존 기기의 절대 경로를 그대로 복사하지 마세요.

4. 노드 목록이나 공유 링크만 있을 때 처리 방법

노드 목록은 기본 설정에서 구성해야 합니다

최상위에 proxies:만 있는 YAML은 노드 프로바이더로 사용되는 경우가 많습니다. 사용 가능한 노드를 설명하지만 애플리케이션이 사용할 로컬 포트, 프록시 그룹, 분산 규칙까지 정의하지는 않을 수 있습니다. 이를 기본 설정으로 가져오면 어떤 클라이언트는 필요한 구조를 보완하지만, 어떤 클라이언트는 노드만 표시하거나 바로 오류를 냅니다. 특정 클라이언트의 자동 보완 동작을 일반적인 형식 규칙으로 간주해서는 안 됩니다.

프로바이더를 지원하는 코어에서는 일반적으로 기본 설정의 proxy-providers에 이름이 지정된 리소스를 정의하고, 프록시 그룹이 use로 이를 참조합니다. 프로바이더 이름은 일치해야 하며 원격 리소스도 코어가 지원하는 노드 형식이어야 합니다. 일반 구독 URL을 이 필드에 입력했다고 해서 코어가 임의의 Base64 노드 구독을 디코딩한다고 가정해서는 안 됩니다. 관련 필드는 설정 전체의 노드 설명에서 확인하세요.

공유 링크는 해석 기능과 프로토콜 지원을 함께 확인해야 합니다

단일 노드 URI: ss:// 등의 링크에는 하나의 노드 매개변수만 포함되며 전체 분산 규칙은 들어 있지 않습니다. 클라이언트가 해당 유형의 가져오기를 명시적으로 지원할 때만 바로 사용할 수 있습니다.
여러 줄 URI 또는 Base64 텍스트: 일반 노드 구독일 수 있지만 완전한 Clash YAML은 아닙니다. 제공업체가 호환 형식으로 출력하거나 신뢰할 수 있는 도구로 변환해야 합니다.
프로토콜 및 전송 매개변수: 변환 후에도 프로토콜, 포트, TLS, SNI, 전송 경로 등을 확인해야 합니다. 구형 Clash 코어는 mihomo와 같지 않으므로 두 코어가 동일한 프로토콜과 필드를 지원한다고 가정해서는 안 됩니다.

“알 수 없는 프로토콜”이 표시되면 먼저 현재 코어의 지원 범위를 확인하세요. 연결 핸드셰이크 오류가 발생하면 원본 매개변수와 대조합니다. 오류를 없애려고 인식할 수 없는 필드를 임의로 삭제하지 마세요. 해당 필드가 서버가 요구하는 전송 또는 인증 매개변수일 수 있습니다. 클라이언트를 변경해야 한다면 먼저 선택 가이드에서 플랫폼과 코어의 관계를 확인한 뒤 설정을 이전하세요.

5. 구독 업데이트 실패: 응답·해석·연결 단계별 문제 해결

“업데이트 실패”에는 최소 세 가지 문제가 포함됩니다. 요청이 콘텐츠를 받지 못한 경우, 받은 콘텐츠를 해석할 수 없는 경우, 해석은 성공했지만 노드에 연결할 수 없는 경우입니다. 노드 지연 테스트 실패가 곧 구독 업데이트 실패를 의미하지는 않습니다. 마찬가지로 HTTP 요청이 성공했다고 설정이 올바른 것도 아닙니다. 먼저 설정 업데이트 시간과 다운로드 로그를 확인하고, 다음으로 코어 오류를 확인한 뒤, 마지막으로 실제 연결을 테스트하세요.

구체적인 신호	우선 확인할 항목	다음 조치
HTTP 401 또는 403	토큰 만료, 계정 권한, 접근 제한	구독 주소를 다시 발급받고 계정 상태를 확인하세요. 403은 접근 보호 기능 때문에 발생할 수도 있습니다.
HTTP 404	주소 경로 변경, 불완전한 복사	제공업체가 현재 생성한 주소와 대조하고 경로를 임의로 추측하지 마세요.
HTTP 429	너무 잦은 새로고침	연속 재시도를 중지하고 응답 안내나 제공업체 정책에 따라 기다리세요.
HTTP 200이지만 해석 오류 발생	웹페이지, 오류 JSON 또는 호환되지 않는 노드 형식이 반환됨	로컬에서 응답의 시작 부분과 오류 줄을 확인하고 호환 형식을 점검하세요.
DNS 실패 또는 연결 시간 초과	구독 도메인 해석과 다운로드에 사용되는 경로	로컬 네트워크, 기존 프록시, 구독 업데이트의 프록시 설정을 확인하세요.
TLS 인증서 오류	시스템 시간, 인증서 체인, 인증 포털 또는 네트워크 차단	시간을 보정하고 네트워크 상태를 확인하세요. 인증서 검증을 끄는 방법을 일반적인 해결책으로 사용하지 마세요.

브라우저에서는 다운로드되지만 클라이언트에서 실패한다면 리디렉션, 로그인 Cookie, 요청 헤더, 제공업체의 클라이언트 식별 정책도 확인해야 합니다. 브라우저는 로그인 상태 덕분에 파일을 받을 수 있지만 클라이언트는 로그인 페이지를 받을 수 있습니다. 반대로 서버가 User-Agent에 따라 다른 콘텐츠를 반환할 수도 있습니다. 해결 방법은 대상 클라이언트용 구독 메뉴를 확보하는 것이며, 브라우저 로그인 세션을 관련 없는 소프트웨어에 복사하는 것이 아닙니다.

yaml: line 12와 같은 메시지가 표시되면 12번째 줄과 그 바로 앞 줄의 들여쓰기, 따옴표, 콜론을 확인하세요. 오류 줄은 파서가 이상을 발견한 위치일 뿐 최초로 잘못 작성된 위치가 아닐 수 있습니다. 원격 콘텐츠 자체에 문제가 있다면 제공업체에 문의하거나 지원되는 출력 형식으로 전환하는 것이 우선입니다. 로컬에서 임시로 수정해도 다음 업데이트에서 원래 오류 콘텐츠를 다시 가져올 수 있습니다.

6. 업데이트로 로컬 변경 사항이 덮어써질 때: 구독과 덮어쓰기 분리

원격 구독은 일반적으로 다시 다운로드할 수 있는 원본 파일입니다. 그 안에 규칙을 추가하거나 포트를 수정하거나 프록시 그룹 이름을 바꾸면 다음 업데이트에서 덮어써질 수 있습니다. 이는 콘텐츠 업데이트 방식에 따른 결과이지 반드시 저장 실패를 뜻하지는 않습니다. 클라이언트의 실행 설정은 “구독 콘텐츠 + 전역 설정 + 덮어쓰기”를 병합해 생성될 수도 있으므로, 어느 한 계층을 편집한 뒤 최종 적용값을 확인해야 합니다.

구독 원본 보존: 원격 설정 항목에는 원격 주소와 자동 업데이트를 유지하고, 복구하기 어려운 수동 버전으로 유일한 복사본을 바꾸지 마세요.
변경 사항 별도 저장: 클라이언트가 덮어쓰기, 병합 또는 스크립트 기능을 제공한다면 이를 사용해 사용자 지정 규칙과 설정을 저장하세요. 구체적인 적용 순서는 해당 클라이언트의 구현을 따릅니다.
배열 동작 확인: rules와 proxy-groups는 교체되거나 앞에 삽입되거나 뒤에 추가될 수 있으므로 모든 병합 방식이 같다고 가정해서는 안 됩니다.
규칙 순서 재확인: 규칙은 일반적으로 순서대로 매칭됩니다. 사용자 지정 규칙을 MATCH 뒤에 두면 적용되지 않는 경우가 많습니다. 규칙이 참조하는 프록시 그룹도 업데이트 후 계속 존재해야 합니다.
수동 업데이트 한 번 실행: 업데이트 전후의 유효한 설정을 비교해 구독 새로고침이 성공했는지, 사용자 지정 설정이 유지되는지 확인한 뒤 정기 업데이트를 켜세요.

7. 가져온 뒤 최소 검증 목록

가져오기 성공 여부는 설정, 코어, 실제 요청의 세 계층을 확인해야 판단할 수 있습니다. 먼저 “모든 노드를 한 번씩 테스트하기”로 기본 점검을 대신하지 마세요. 지연 측정 대상에 연결할 수 없어도 브라우저는 해당 노드를 통해 다른 사이트에 접속할 수 있고, 반대로 측정은 성공했지만 애플리케이션이 프록시를 사용하지 않을 수도 있습니다.

설정 계층: 새 설정이 현재 선택되어 있고 업데이트 시간이 이번 작업과 일치하며 대상 프록시 그룹이 존재하고, 그룹 안에서 DIRECT가 아닌 예상 노드가 선택되어 있는지 확인하세요.
코어 계층: 해석 실패, 포트 사용 중, 알 수 없는 프로토콜 오류가 없는지 확인하세요. 실제 리스닝 포트를 확인하고 튜토리얼의 7890을 그대로 따라 하지 마세요.
적용 계층: 데스크톱 시스템 프록시는 시스템 프록시 설정을 따르는 애플리케이션에 주로 영향을 줍니다. TUN은 가상 네트워크 카드, 라우팅, 권한과 관련되며 모바일에서는 일반적으로 VPN 권한이 필요합니다. 어느 쪽도 잘못된 구독 형식을 수정해 주지는 않습니다.
요청 계층: 정상 작동이 확인된 웹사이트에 접속하고 연결 또는 로그 페이지에서 코어에 요청이 들어갔는지, 어떤 규칙이 매칭되었는지, 최종적으로 어떤 프록시 정책을 사용했는지 확인하세요.

명시적 프록시 요청으로 시스템 프록시 문제 분리

데스크톱 기기에 curl이 설치되어 있고 코어가 실제로 로컬 7890 포트에서 HTTP 또는 혼합 프록시를 제공한다면 아래 진단 명령을 실행할 수 있습니다. Windows에서는 curl.exe를 사용하면 일부 PowerShell 환경에서 같은 이름의 별칭으로 인해 발생하는 매개변수 차이를 피할 수 있습니다.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

여기서 10초는 연결 시간 초과의 상한이고 20초는 전체 요청 시간의 상한이며 실제 측정 지연 시간이 아닙니다. HTTP 응답을 받았다는 것은 이번 명시적 프록시 요청의 응답 과정이 완료되었다는 뜻이지만, 원격 노드를 사용했다는 의미는 아닙니다. 규칙이 여전히 직접 연결을 선택할 수 있기 때문입니다. 127.0.0.1:7890에 연결할 수 없다는 메시지가 표시되면 먼저 리스닝 포트와 코어 실행 상태를 확인하세요. 명시적 요청은 성공하지만 일반 브라우저가 실패한다면 브라우저 프록시 설정이나 다른 프록시 적용 방식과의 충돌을 확인하세요.

마지막으로 개인정보를 제거한 오류 정보, 클라이언트 및 코어 버전, 입력 유형, 재현 절차를 저장하세요. 계속 조정하기 전에 빠른 시작의 연결 확인을 참고해 매번 하나의 변수만 변경하세요. 이렇게 하면 문제가 구독 가져오기, 설정 해석, 프록시 경로 중 어디에서 발생했는지 명확히 파악할 수 있으며, 반복적인 가져오기와 재설치로 단서를 잃지 않을 수 있습니다.