Clash 구독 링크 가져오기 가이드:URL, 로컬 YAML, Base64 형식 차이

구독 주소, 설정 파일, 노드 목록부터 구분하기

구독을 받으면 먼저 제공업체에서 ‘Clash’ 또는 ‘Clash Meta / mihomo’ 전용 항목을 제공하는지 확인한 뒤 클라이언트의 설정 화면을 여세요. 브라우저 관리 페이지 주소, 개별 노드 링크, 구독 주소를 혼동하지 마세요. 모두 텍스트처럼 보여도 클라이언트에서 처리하는 방식은 서로 다릅니다.

URL은 콘텐츠를 가져오는 주소이고, YAML은 설정을 구성하는 형식이며, Base64는 텍스트 인코딩 방식입니다.서로 같은 종류의 선택지가 아닙니다. HTTPS 구독 주소 하나가 YAML을 반환할 수도 있고 Base64로 인코딩된 노드 목록을 반환할 수도 있습니다. 가져오기에 실패하면 링크가 https://로 시작하는지만 보지 말고 실제 응답 내용을 확인하세요.

URL로 가져오기: 원격 설정을 저장한 뒤 현재 설정으로 선택

올바른 클라이언트용 구독 주소 복사

1. 구독 제공업체의 관리 페이지에 로그인해 ‘구독’ 또는 ‘설정 내보내기’를 찾고 Clash나 mihomo에 맞는 형식을 선택하세요. 범용 구독만 제공된다면 먼저 클라이언트가 변환을 지원하는지 확인하세요.
2. 페이지의 복사 버튼으로 URL 전체를 복사하세요. 채팅 앱에서 복사할 때 마침표, 줄바꿈, 따옴표가 섞이지 않도록 주의하고, 특히 ? 뒤의 접근 매개변수를 빠뜨리지 마세요.
3. 클라이언트의 설정 목록을 열고 ‘새로 만들기’, ‘추가’ 또는 더하기 버튼을 선택한 뒤 원격 URL 유형으로 전환하세요. ‘일상용 구독’처럼 알아보기 쉬운 이름을 지정합니다.
4. 주소를 붙여 넣고 저장한 뒤 처음으로 가져오기가 완료될 때까지 기다리세요. 오류 상세 정보가 표시되면 상태 코드나 파싱 오류를 먼저 기록하고, 같은 주소를 연속해서 추가하지 마세요.
5. 설정 목록에서 방금 추가한 항목을 선택해 현재 설정으로 적용됐는지 확인하세요. 프록시 화면에서 정책 그룹이 표시되는지 확인한 뒤 사용할 노드를 선택합니다.

‘다운로드 완료’는 클라이언트가 설정을 가져왔다는 뜻일 뿐, 시스템 트래픽이 프록시를 통과한다는 뜻은 아닙니다. 가져온 뒤 실제 용도에 맞게 시스템 프록시를 켜거나 더 많은 앱의 트래픽을 처리해야 한다면 TUN을 설정하세요. 처음 확인할 때는 트래픽 처리 방식을 하나만 사용하고 연결이 정상인지 확인한 다음 기능을 추가해야 가져오기 문제와 라우팅 문제를 구분하기 쉽습니다.

업데이트 간격 설정과 두 가지 새로고침 방식 구분

클라이언트가 자동 업데이트를 지원한다면 우선 24시간마다 한 번 업데이트하도록 설정하세요. 화면에 따라 시간 또는 분 단위로 입력할 수 있으므로, 분 단위라면 1440분을 입력하면 됩니다. 이는 시작점으로 참고할 설정이며, 최종적으로는 제공업체의 요청 빈도 제한을 따르세요. 짧은 시간에 반복해서 새로고침하면 요청이 제한될 수 있습니다.

‘원격 설정 전체 업데이트’와 ‘설정에 포함된 proxy-providers 업데이트’도 구분해야 합니다. 전자는 클라이언트의 설정 관리 기능이 담당하고, 후자는 코어가 제공자의 interval 설정에 따라 노드를 가져옵니다. 제공자의 interval: 86400은 86400초를 뜻하며, 클라이언트가 하루마다 기본 설정 전체를 다시 다운로드하게 하지는 않습니다.

로컬 YAML 가져오기: 전체 설정 파일인지 먼저 확인

.yaml 또는 .yml 파일이 있다면 설정 화면에서 파일 가져오기를 선택하고 파일 선택기에서 해당 파일을 여세요. 가져오기 전에 일반 텍스트 편집기로 내용을 확인하세요. 시작 부분이 <!DOCTYPE html>, 로그인 페이지 또는 오류 메시지라면 설정 파일이 아니라 웹페이지가 저장된 것입니다. 확장자를 YAML로 바꿔도 파일 내용은 바뀌지 않습니다.

설정의 세 가지 구성 요소 확인

• 노드 출처: proxies에 노드를 직접 정의하거나 proxy-providers로 노드 목록을 가져옵니다. 노드 제공자 파일에는 노드 목록만 들어 있는 경우가 많으므로 전체 기본 설정 파일과 같다고 볼 수 없습니다.
• 정책 선택: proxy-groups는 수동 선택, 자동 속도 테스트 등의 정책을 구성합니다. 규칙에서 참조하는 정책 이름은 설정에 실제로 있어야 합니다.
• 라우팅 규칙: rules가 연결 경로를 결정합니다. 규칙 모드는 위에서부터 차례로 적용되며 먼저 일치하는 규칙이 우선합니다. 존재하지 않는 그룹 이름을 가리키는 규칙이 있으면 설정을 불러오지 못할 수 있습니다.

아래는 구조를 이해하기 위한 최소 예시입니다. 원격 노드는 포함하지 않으며 모든 연결이 직접 연결되므로 원격 프록시의 작동 여부를 확인하는 데 사용할 수 없습니다. 7890은 예시용 혼합 포트이며 모든 클라이언트의 기본 포트가 아닙니다. 실제 사용 시에는 클라이언트에 표시된 수신 포트를 확인하세요.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: 수동 선택
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,수동 선택

YAML은 들여쓰기에 민감합니다. 공백을 사용하고 Tab은 사용하지 마세요. 같은 단계는 들여쓰기를 일관되게 유지하세요. 텍스트 편집기에서 모든 콜론을 일괄 변경하거나 문서 편집기가 일반 따옴표를 곡선 따옴표로 바꾸게 두지 마세요. 특수 문자가 포함된 이름이나 비밀번호는 YAML 문법에 맞게 따옴표로 묶어야 합니다.

원본 파일과 복구용 설정 보관

일부 클라이언트는 파일을 자체 설정 폴더에 복사하고, 다른 클라이언트는 외부 경로 참조를 지원합니다. 가져온 뒤 원본 파일을 수정해도 현재 설정에는 반영되지 않을 수 있으므로 다시 가져오거나 새로고침해야 합니다. 정상 작동하는 설정을 보관하고 DNS, 규칙 또는 노드를 수정하기 전에 사본을 만들어 두세요.

로컬 파일은 일반적으로 원격 구독처럼 설정 전체가 자동 업데이트되지 않습니다. 다만 파일에서 참조하는 원격 제공자는 인터넷을 통해 업데이트될 수 있습니다. 반대로 원격 구독을 다운로드해 얻은 파일을 직접 편집하면 다음 새로고침 때 변경 사항이 덮어써질 수 있습니다. 사용자 지정 규칙을 계속 유지하려면 클라이언트에서 지원하는 오버라이드, 병합 또는 패치 기능을 우선 사용하세요.

Base64 형식: 디코딩하면 노드가 나오지만 Clash 설정 파일은 아닙니다

일반적인 범용 구독은 여러 줄의 노드 링크를 Base64 텍스트 한 덩어리로 인코딩합니다. 디코딩하면 규칙과 정책 그룹이 포함된 YAML이 아니라 ss://, vmess:// 또는 trojan:// 링크 여러 개가 나올 수 있습니다. Base64는 인코딩 방식일 뿐이므로 원문을 가진 사람은 누구나 내용을 복원할 수 있습니다.

문자열 c3M6Ly8=을 예로 들면 디코딩 결과는 ss://뿐입니다. 인코딩 관계를 보여주는 예일 뿐 연결 가능한 노드는 아닙니다. 실제 구독에는 서버, 포트, 인증 매개변수가 포함되며, 일부 프로토콜 링크는 내부에서 다시 인코딩을 사용하므로 한 번 디코딩한다고 모든 프로토콜 파싱이 끝나는 것은 아닙니다.

순서에 따라 변환 방법 선택

1. 먼저 제공업체의 Clash 내보내기 옵션을 찾으세요. 대상 클라이언트 전용 출력을 사용하면 노드, 그룹, 규칙을 함께 가져올 수 있어 수작업으로 보완할 부분이 줄어듭니다.
2. 그다음 클라이언트의 가져오기 기능을 확인하세요. 범용 구독이나 노드 링크를 지원한다고 명시된 가져오기 기능만 Base64 내용을 바로 붙여 넣는 데 적합합니다. 클라이언트가 mihomo 코어를 사용한다는 이유만으로 그래픽 인터페이스가 모든 구독 형식을 지원한다고 가정하지 마세요.
3. 변환이 꼭 필요하다면 신뢰할 수 있는 환경에서 처리하세요. 로컬 도구나 제공업체가 지정한 서비스를 우선 사용하세요. 변환 후 노드 수, 프로토콜 필드, 정책 그룹 참조, 최종 규칙을 확인한 뒤 클라이언트에서 활성화하세요.

변환기는 인코딩된 텍스트의 확장자만 바꾸는 도구가 아닙니다. 노드 프로토콜을 분석하고 Clash / mihomo의 필드에 맞춰 노드를 구성한 다음 기본 설정에 필요한 정책과 규칙을 추가해야 합니다. 대상 코어가 지원하지 않는 프로토콜이나 매개변수는 변환만으로 지원할 수 없습니다. 클라이언트의 ‘정보’ 화면에서 실제 코어와 버전을 확인하고 해당 코어가 지원하는 설정 문법과 대조하세요.

가져오기 실패: 네트워크, 응답 내용, 설정 문법 순서로 확인

먼저 클라이언트 로그나 가져오기 오류 상세 정보를 확인한 뒤 다음 단계를 결정하세요. 네트워크 요청 실패, 잘못된 응답 내용, 설정 문법 오류는 서로 다른 문제이므로 해결 방법도 다릅니다. 브라우저에서 관리 페이지가 열린다고 클라이언트가 구독을 가져올 수 있는 것은 아닙니다. 관리 페이지는 로그인 쿠키가 필요할 수 있지만 구독 API는 별도의 접근 자격 증명을 사용해야 합니다.

‘프록시를 통해 업데이트’는 사용할 수 있는 프록시가 있지만 구독 서버에 직접 연결할 수 없는 경우에 적합합니다. 사용 가능한 설정이 하나도 없는 상태에서 이 옵션을 켜면 의존 관계가 생길 수 있습니다. 노드를 얻으려면 먼저 업데이트해야 하지만, 업데이트하려면 노드가 필요한 상황입니다. 이때는 제공업체가 안내한 접속 가능한 주소를 사용하거나 신뢰할 수 있는 네트워크에서 설정을 가져와 로컬로 가져오세요.

가져온 뒤 확인: 설정, 노드, 트래픽 경로를 각각 점검

1. 설정이 활성화됐는지 확인하세요.현재 설정 이름, 최근 업데이트 시간, 로드 로그를 확인하세요. 설정 목록에 항목이 표시되는 것만으로 코어가 해당 설정을 사용 중이라고 볼 수는 없습니다.
2. 정책이 선택됐는지 확인하세요.프록시 화면에서 실제 규칙이 가리키는 정책 그룹을 열고 노드를 선택하세요. 지연 시간 테스트에 성공했다는 것은 특정 테스트 요청이 성공했다는 뜻일 뿐, 모든 웹사이트에 접속할 수 있다는 뜻은 아닙니다.
3. 트래픽 진입점을 확인하세요.시스템 프록시를 사용할 때는 클라이언트 수신 포트와 시스템 설정이 일치하는지 확인하세요. 예를 들어 클라이언트에 혼합 포트가 7890으로 표시된다면 앱은 해당하는 127.0.0.1:7890에 연결해야 합니다. 다른 기기의 포트를 그대로 사용하지 마세요.
4. 규칙이 적용됐는지 확인하세요.대상 웹페이지를 연 뒤 연결 기록에서 도메인, 일치한 규칙, 정책 그룹, 실제 출구를 확인하세요. 기록에 요청이 전혀 없다면 구독을 계속 바꾸기보다 먼저 앱이 프록시 진입점을 사용하는지 확인하세요.

TUN으로 처리해야 하는 앱이라면 클라이언트 안내에 따라 권한을 부여하고 라우팅 및 DNS를 설정하세요. TUN은 트래픽을 처리하는 방식이지 구독 형식 변환기가 아닙니다. DNS 하이재킹도 Base64 노드 목록을 완전한 설정 파일로 바꾸지 않습니다. 설정 가져오기, 코어 로드, 트래픽 처리의 세 단계를 나눠 확인해야 문제 지점을 정확히 찾을 수 있습니다.

평소 관리할 때는 복구할 수 있는 설정을 보관하고 업데이트 주기를 기록하며 구독이 변경된 뒤 정책 그룹 이름을 확인하세요. 제공업체가 그룹 이름을 바꾸면 사용자 지정 규칙이나 오버라이드가 이전 이름을 계속 참조할 수 있습니다. 참조 관계를 먼저 확인한 뒤 규칙을 조정하면 ‘구독 업데이트는 성공했지만 설정 로드는 실패하는’ 문제를 반복해서 점검하지 않아도 됩니다.