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

먼저 구독 주소와 설정 내용을 구분하세요

가져오기 전에 받은 항목이 무엇인지 확인하세요. URL은 리소스 주소이고, YAML은 설정 파일의 텍스트 형식이며, Base64는 인코딩 방식입니다. 세 가지는 서로 배타적인 구독 유형이 아닙니다. 같은 HTTPS 주소에서도 YAML이 반환될 수 있고, Base64로 인코딩된 노드 목록이나 로그인 페이지가 반환될 수도 있습니다.

Clash 클라이언트는 설정을 관리하고 인터페이스를 제공하며 프록시 코어를 실행합니다. mihomo는 Clash 설정 체계와 호환되면서 기능을 확장한 코어로, Clash Meta라고도 불립니다. 설정을 사용할 수 있는지는 반환된 내용뿐 아니라 현재 코어가 해당 프로토콜과 필드를 지원하는지에도 달려 있습니다.

URL 구독 가져오기: 주소 복사부터 설정 선택까지

1. Clash 또는 mihomo용 구독 주소 복사

구독 제공업체의 계정 페이지에 접속해 ‘Clash’, ‘Clash Meta’ 또는 ‘mihomo’로 표시된 내보내기 메뉴를 우선 선택하세요. 메뉴마다 반환하는 프로토콜과 설정 구조가 다를 수 있습니다. ‘범용 구독’이 완전한 Clash 설정으로 바로 사용할 수 있는 것은 아닙니다.

실제 구독 주소를 복사하세요. 계정 관리 페이지의 브라우저 주소나 버튼 옆 안내 문구를 복사하면 안 됩니다. 주소 앞에 공백이 없고 끝에 마침표가 붙지 않았는지 확인하세요. 주소의 &, =, 퍼센트 인코딩은 의미가 있을 수 있으므로 임의로 삭제하거나 수정하지 마세요.

2. 클라이언트 설정 페이지에서 가져오기

1. 클라이언트를 열고 ‘설정’ 또는 ‘Profiles’ 페이지로 이동하세요. Clash Verge Rev를 예로 들면 사이드바에서 ‘설정’을 누른 다음 해당 페이지의 구독 링크 입력란을 사용합니다.
2. 주소 전체를 붙여넣고 ‘가져오기’를 누르세요. 현재 버전에서 ‘새로 만들기’ 창을 사용하는 경우 원격 설정 유형을 선택한 뒤 URL을 입력합니다.
3. 설정 카드가 나타날 때까지 기다리세요. 업데이트 시간이나 오류 메시지를 확인하고 가져오기를 연속해서 누르지 마세요.
4. 방금 가져온 설정을 선택해 현재 설정으로 지정하세요. 목록에 표시되는 것만으로는 활성화된 상태가 아닙니다.
5. ‘프록시’ 페이지로 이동해 실제 사용할 프록시 그룹을 펼치고 노드가 표시되는지 확인한 다음 사용 가능한 노드를 선택하세요.

다른 클라이언트에서는 같은 기능이 메뉴 막대 아이콘의 ‘설정’ 메뉴에 있을 수 있습니다. 메뉴 이름은 달라도 원격 콘텐츠 가져오기, 설정 파싱, 설정 선택, 프록시 그룹 확인 순서는 같습니다.

3. 다운로드 성공과 설정 적용을 구분하세요

‘구독 업데이트 성공’은 보통 이번에 콘텐츠를 가져와 처리했다는 뜻입니다. 선택한 노드에 연결할 수 있다거나 브라우저 트래픽이 프록시를 통과한다는 뜻은 아닙니다. 먼저 현재 설정을 확인하고 프록시 모드를 살펴보세요. 일반적으로 ‘규칙’ 모드에서 시작하면 설정의 규칙에 따라 직접 연결 또는 프록시 연결이 결정됩니다.

로컬 YAML 가져오기: 구조와 출처를 확인하세요

YAML은 들여쓰기로 계층을 표현합니다. Clash 설정에는 노드용 proxies, 프록시 그룹용 proxy-groups, 분기 규칙용 rules가 자주 쓰이며, proxy-providers로 외부 노드를 불러오기도 합니다. proxies 항목이 없다고 해서 반드시 빈 설정인 것은 아닙니다.

1. 파일을 ‘다운로드’ 폴더처럼 찾기 쉬운 위치에 저장하세요. 웹페이지를 다른 이름으로 저장한 HTML 파일이 아닌지 확인합니다.
2. 클라이언트의 설정 페이지에서 ‘파일 가져오기’ 또는 로컬 설정 메뉴를 사용하세요. 일부 클라이언트는 파일을 끌어다 놓을 수도 있으니 화면 안내를 따르세요.
3. 설정을 선택한 뒤 파싱 오류가 있는지 확인하세요. 특정 줄 번호가 표시되면 해당 줄과 바로 앞 줄의 들여쓰기, 콜론, 따옴표를 먼저 살펴보세요.
4. 외부 노드 소스와 규칙 소스가 정상적으로 로드되는지 확인하세요. 로컬 파일도 네트워크 리소스에 의존할 수 있습니다.

가져오기 과정을 확인하기 위한 최소 설정

아래는 로컬 설정 파일로 저장해 사용할 수 있는 YAML 예시입니다. 로컬 포트 7890에서 요청을 수신해 직접 연결로 보냅니다. 프록시 노드는 포함하지 않으므로 파일 형식과 설정 로드 과정만 확인할 수 있으며 프록시 경로 테스트에는 사용할 수 없습니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

mixed-port는 HTTP와 SOCKS 프록시 요청을 모두 받는 혼합 포트입니다. 여기서 7890은 예시일 뿐 모든 클라이언트에서 고정으로 사용하는 값이 아닙니다. 화면의 포트 설정이나 설정 덮어쓰기로 포트가 바뀌었다면 실제 수신 포트를 기준으로 하세요.

YAML을 수정할 때는 공백으로 들여쓰고 탭 문자를 섞지 마세요. 노드 비밀번호, URL, 이름에 특수 문자가 있으면 YAML 문법에 맞게 따옴표로 묶으세요. 원격 설정을 직접 수정하면 다음 업데이트 때 덮어써질 수 있습니다. 지속적으로 수정해야 한다면 클라이언트의 덮어쓰기 또는 병합 기능을 우선 사용하세요.

Base64 식별: 디코딩한 뒤에도 내용을 확인하세요

Base64는 암호화가 아닙니다. 흔히 쓰이는 인코딩 문자열에는 영문자와 숫자, 더하기 기호, 슬래시가 포함되고 끝에 등호가 붙을 수 있습니다. URL 안전 변형은 하이픈과 밑줄을 쓰기도 합니다. 하지만 긴 문자열처럼 보인다는 것만으로 유효한 구독이라고 단정할 수는 없습니다.

디코딩 결과로 흔히 나오는 세 가지 유형

• 여러 줄의 노드 URI: 예를 들어 ss:// 또는 vmess:// 링크가 여러 개 나옵니다. 노드 목록일 뿐, 프록시 그룹과 분기 규칙을 포함한 완전한 설정은 아닙니다.
• YAML 텍스트: 설정 구조와 코어 호환성을 계속 확인하세요. 디코딩에 성공했다고 해서 바로 사용할 수 있는 것은 아닙니다.
• 오류 메시지 또는 다른 텍스트: 제공업체 페이지로 돌아가 구독 권한과 링크 유형, 유효 기간을 확인하세요.

오프라인으로 확인해야 한다면 Mac의 ‘터미널’에서 아래 명령을 실행할 수 있습니다. 먼저 확인할 인코딩 문자열을 클립보드에 복사한 다음 실행하세요. 이 명령은 로컬에서만 디코딩하며 결과는 터미널에 표시됩니다.

pbpaste | /usr/bin/base64 -D

이 명령은 macOS에 기본 포함된 도구의 인수 형식을 사용합니다. 디코딩 오류가 발생하면 텍스트가 잘렸거나 다른 문자가 섞였거나 다른 인코딩 변형을 사용했을 수 있습니다. 계정이 만료됐다고 바로 단정하지 마세요. 디코딩 결과에 비밀번호가 포함될 수 있으므로 화면을 녹화하거나 그대로 공유하지 말고, 확인이 끝나면 클립보드를 비우세요.

결과가 노드 목록인데 클라이언트의 원격 설정 메뉴가 완전한 YAML만 받는다면 제공업체 페이지로 돌아가 Clash 전용 구독을 선택하세요. 클라이언트가 범용 노드 구독을 명확히 지원하거나 신뢰할 수 있는 로컬 변환 절차를 설정한 경우에만 해당 메뉴를 사용하세요. 한 번 가져오려고 인증 정보가 포함된 구독을 출처가 불분명한 온라인 변환 서비스에 넘기지 마세요.

첫 연결 확인: 설정, 노드, 트래픽을 차례로 점검

먼저 설정과 프록시 그룹 확인

현재 설정에 선택 표시가 있는지, 프록시 페이지의 노드 이름이 이번에 가져온 내용과 일치하는지 확인하세요. 프록시 그룹은 사용할 연결 경로를 선택하기 위한 설정 모음입니다. 규칙에서 참조하는 그룹이 없으면 파일을 다운로드할 수 있어도 제대로 로드되거나 트래픽을 라우팅하지 못할 수 있습니다.

그다음 노드 연결 확인

프록시 페이지에서 지연 시간을 한 번 테스트하세요. 테스트 결과는 클라이언트가 테스트 주소에 연결해 확인한 값으로, 다운로드 속도와 같지 않으며 모든 웹사이트에 접속할 수 있다는 보장도 아닙니다. 시간 초과가 발생하면 다른 노드로 다시 테스트하고 로그에서 연결 또는 인증 오류를 확인하세요. 빨간 숫자 하나만 보고 클라이언트를 재설치하지 마세요.

마지막으로 앱 트래픽이 프록시를 통과하는지 확인

클라이언트에서 ‘시스템 프록시’를 켠 뒤 브라우저로 확인할 웹사이트를 여세요. 시스템 프록시는 macOS가 앱에 제공하는 프록시 설정이며, 이를 따르는 앱만 해당 설정을 사용합니다. 터미널 명령이나 일부 앱은 자동으로 적용되지 않을 수 있으므로 프록시 포트를 명시해 테스트할 수 있습니다.

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

실행하기 전에 명령의 포트를 클라이언트에서 실제 사용하는 HTTP 또는 혼합 포트로 바꾸세요. 127.0.0.1은 현재 사용 중인 Mac을 가리킵니다. 연결 대기 시간은 최대 10초, 전체 요청 시간은 최대 20초입니다. HTTP 응답을 받았다는 것은 요청 경로에서 응답을 받았다는 뜻입니다. 원격 노드를 통과했는지는 ‘연결’ 페이지나 로그의 규칙 적용 및 출구 정보를 함께 확인해야 합니다.

TUN은 가상 네트워크 인터페이스를 통해 트래픽을 처리하는 방식으로, 일반적으로 시스템 프록시보다 더 많은 트래픽을 다룹니다. 구독을 처음 가져올 때 TUN을 바로 켤 필요는 없습니다. 먼저 설정과 일반 프록시 요청이 정상 작동하는지 확인한 다음 앱 요구에 맞춰 트래픽 처리 방식을 조정하면 문제 해결 시 변수를 줄일 수 있습니다.

구독 업데이트 주기 설정: 수동 업데이트 성공 후 자동화

먼저 설정 카드의 작업 메뉴에서 ‘업데이트’를 한 번 실행하세요. 업데이트 시간이 바뀌고 설정이 계속 로드되는지 확인한 다음, 해당 설정의 편집 또는 설정 메뉴를 열어 자동 업데이트와 업데이트 주기 항목을 찾으세요. 클라이언트에 따라 단위가 분, 시간, 초로 다를 수 있으므로 값을 입력하기 전에 단위를 확인해야 합니다.

• 일반적인 개인 사용: 24시간마다 한 번, 즉 1440분 또는 86400초로 시작할 수 있습니다. 이는 권장 시작값일 뿐 프로토콜에서 정한 값은 아닙니다.
• 노드 변경이 잦은 경우: 제공업체 안내에 따라 6시간 또는 12시간마다 업데이트하세요. 주기를 몇 초 단위로 지나치게 짧게 설정하지 마세요.
• 노드 또는 요금제를 임시로 변경한 경우: 제공업체에서 변경을 마친 뒤 수동으로 한 번 업데이트하고, 프록시 그룹에 새 노드가 나타나는지 확인하세요.
• Mac을 자주 덮어 두는 경우: 잠자기 중에는 클라이언트 작업이 예정된 시간에 실행되지 않는 경우가 많습니다. 깨어난 뒤 실제 업데이트 시간을 확인하고 필요하면 수동으로 업데이트하세요.

구독 설정 업데이트, 노드 소스 업데이트, 규칙 소스 업데이트, 지연 시간 테스트는 각각 다른 작업입니다. YAML의 provider에 지정된 interval은 초 단위인 경우가 많지만, 클라이언트 설정 카드의 업데이트 주기와는 별개입니다. 구독 새로고침 빈도를 높이려고 interval이 포함된 모든 필드를 임의로 수정하지 마세요.

현재 설정을 업데이트할 때 기존 프록시 연결이 필요하다면 업데이트 전에 사용 가능한 노드를 하나 남겨 두세요. 업데이트에 실패했을 때 클라이언트가 기존 설정을 유지하는지 확인해, 유일하게 작동하는 설정을 삭제한 뒤 새 주소에 접속할 수 없다는 사실을 알게 되는 일을 막으세요.

가져오기 및 업데이트 실패: 오류 유형별 해결

다운로드는 완료됐지만 노드가 없음

규칙만 포함된 파일을 잘못 사용했거나 다른 설정에서 참조해야 하는 노드 소스 파일을 가져오지 않았는지 확인하세요. 전체 설정, 노드 provider 파일, 규칙 provider 파일은 용도가 다릅니다. 확장자가 모두 YAML이라고 서로 바꿔 사용할 수 있는 것은 아닙니다.

브라우저에서는 주소가 열리지만 클라이언트 업데이트는 실패함

브라우저는 로그인 쿠키를 보내지만 클라이언트는 보통 브라우저 로그인 상태를 이어받지 않습니다. 서버가 요청 헤더에 따라 다른 형식으로 응답할 수도 있습니다. 계정 페이지에서 구독 전용 주소를 다시 받고 클라이언트 로그에서 실제 오류를 확인하세요. 오류를 피하려고 인증서 검증을 끄지 마세요.

주소가 공개된 적이 있다면

제공업체 관리 페이지에서 구독 토큰을 재설정한 다음 모든 기기의 주소를 업데이트하고 기존 주소가 더는 유효하지 않은지 확인하세요. 채팅 캡처를 삭제하거나 로컬 설정을 지우는 것만으로 이미 유출된 접근 정보를 무효화할 수는 없습니다.