Clash 구독 형식 완전 정리: YAML, Base64, 구독 변환 제대로 쓰는 법
Clash YAML, 범용 Base64, 각 클라이언트 전용 형식의 차이를 분석하고, 구독 변환 서비스의 동작 원리와 흔한 변환 실패 원인, 서로 다른 코어 클라이언트 간 동일한 구독을 옮기는 방법을 설명합니다.
READ →오픈소스 프로젝트 · 5개 플랫폼 클라이언트가 코어 업데이트를 지속적으로 반영
Clash 전체 플랫폼 클라이언트 다운로드 및 설정 매뉴얼입니다. 구독 링크 등록부터 규칙 분류, TUN 가상 네트워크 카드까지 모든 단계를 실제로 따라 할 수 있게 정리했습니다: 어디를 클릭하고, 무엇이 보이고, 다음엔 뭘 해야 하는지. 문제 해결 글과 용어집도 함께 제공해 오류 메시지를 항목별로 대조해 처리할 수 있습니다.
Clash는 단일 소프트웨어가 아니라 같은 코어를 공유하는 클라이언트 모음입니다. 플랫폼마다 활발히 유지보수되는 GUI 클라이언트가 따로 있으며, 다운로드 페이지에서 플랫폼별로 선택 가능한 옵션, 시스템 요구 사항, 설치 방법을 정리했습니다. 아래 링크로 각 플랫폼 항목에 바로 이동할 수 있습니다.
규칙은 Clash의 핵심 동작 방식입니다. 모든 연결은 도메인, IP 소속 국가, 프로세스명을 기준으로 하나씩 매칭되며, 일치하면 해당 출구로 전달되고 일치하지 않으면 MATCH 기본 규칙으로 처리됩니다. 자주 쓰는 유형으로는 DOMAIN-SUFFIX(도메인 접미사), DOMAIN-KEYWORD(도메인 키워드), GEOIP(IP 지리 데이터베이스), IP-CIDR(대역)이 있습니다. 규칙은 위에서 아래로 순서대로 매칭되며 먼저 일치한 항목이 우선 적용되므로 순서 자체가 우선순위입니다. 매번 프록시를 켜고 끄는 수동 방식과 달리 규칙 분류는 한 번 설정하면 계속 유지됩니다: 한국 국내 사이트는 직접 연결, 목표 사이트는 프록시 경유, 광고 도메인은 즉시 차단하는 식으로 세 가지 흐름이 서로 간섭하지 않습니다. 대부분의 구독에는 이미 검증된 규칙 세트가 포함돼 있어 처음부터 직접 작성할 필요는 없습니다.
규칙 매칭 이후의 처리 방식은 출구가 결정하며 기본값은 세 가지입니다: DIRECT는 로컬 네트워크로 직접 연결, PROXY는 프록시 노드를 거쳐 전달, REJECT는 연결을 즉시 차단합니다. PROXY는 대개 단일 노드가 아니라 정책 그룹으로 구성됩니다. 수동 선택 그룹(select)은 사용자가 노드를 직접 지정하고, 자동 속도 측정 그룹(url-test)은 주기적으로 지연 시간을 측정해 가장 빠른 노드를 선택하며, 장애 조치 그룹(fallback)은 우선 노드가 실패하면 자동으로 대체 노드로 전환합니다. 정책 그룹은 중첩도 가능해서 '지역별 그룹 안에 자동 속도 측정 그룹'처럼 구성할 수 있습니다. 출구 정책을 이해하면 노드 전환이 더 이상 막연한 작업이 아니라, 클라이언트 화면에서 클릭하는 항목 하나하나가 설정 파일 속 명확한 그룹과 노드에 대응된다는 사실을 알게 됩니다.
구독은 서비스 제공자가 관리하는 노드와 규칙 목록을 가리키는 HTTP 링크입니다. 클라이언트의 설정/구독 화면에 링크를 붙여넣으면 클라이언트가 이를 다운로드해 완전한 설정으로 해석하고, 이후 지정한 주기에 따라 자동으로 갱신되므로 노드가 바뀌어도 파일을 직접 수정할 필요가 없습니다. 형식은 크게 두 가지입니다: Clash YAML 네이티브 형식은 그대로 등록 가능하고, 범용 Base64 형식은 구독 변환 서비스를 거쳐 YAML로 바꾼 뒤 사용해야 합니다. 등록에 실패하면 다음 세 가지를 먼저 확인하세요: 링크가 잘리지 않고 완전한지, 반환된 내용이 웹페이지가 아니라 YAML인지, 클라이언트 코어 버전이 설정에 사용된 프로토콜을 지원하는지. 본 사이트의 가이드 문서에는 등록 과정을 화면 단위로 상세히 설명하고 있습니다.
시스템 프록시는 프록시 설정을 따르는 애플리케이션에만 적용되며, 명령줄 도구, 게임 클라이언트, 일부 데스크톱 소프트웨어는 이를 우회해 직접 통신할 수 있습니다. TUN 모드는 시스템에 가상 네트워크 카드를 생성해 모든 네트워크 트래픽을 네트워크 계층에서 가로챈 뒤 Clash 코어가 규칙에 따라 처리하도록 하므로, 애플리케이션이 프록시 설정을 따르는지 여부와 무관하게 동작합니다. 사용 전제 조건은 다음과 같습니다: Windows는 관리자 권한으로 서비스 구성요소를 설치해야 하고, macOS는 시스템 확장 프로그램 권한을 승인해야 하며, Linux는 해당 권한이 필요합니다. 활성화 후에는 fake-ip 방식의 DNS 모드를 함께 사용하는 것이 좋습니다. DNS 해석이 규칙 매칭보다 먼저 이루어지면서 분류가 부정확해지는 것을 막을 수 있습니다. 일상적인 웹서핑에는 시스템 프록시로 충분하며, 전체 트래픽을 제어해야 할 때만 TUN을 켜는 것을 권장합니다.
도메인 해석은 규칙 매칭보다 먼저 발생하므로, DNS 설정이 잘못되면 두 가지 대표적인 문제가 생깁니다: 해석 결과가 오염돼 직접 연결 트래픽이 잘못된 IP를 받아 웹페이지가 열리지 않거나, 해석 경로 자체가 잘못돼 GEOIP 규칙이 프록시 트래픽을 직접 연결로 오판하는 경우입니다. Clash 코어는 내장 DNS 서비스를 제공하며 fake-ip와 redir-host 두 가지 모드를 지원합니다: fake-ip는 예약된 대역의 가상 주소를 반환하고 실제 연결이 성립되는 시점에 코어가 진짜 해석 경로를 결정하는 방식으로, TUN과 함께 쓸 때 가장 안정적입니다. redir-host는 전통적인 해석 방식에 더 가까워 IP에 민감한 일부 앱과 호환성이 좋습니다. 대부분의 구독에는 이미 사용 가능한 DNS 설정이 포함돼 있으니, '연결은 됐지만 웹페이지가 안 열림' 증상이 나타나면 이 부분을 먼저 확인하세요.
Clash는 원래 Go 언어로 작성된 오픈소스 규칙 기반 프록시 코어로, 'YAML 설정 하나로 모든 동작을 정의한다'는 설계로 기술 커뮤니티에서 널리 채택됐습니다. 원본 저장소가 보관 처리(archive)된 이후, 커뮤니티 포크인 Clash.Meta가 개발을 이어가며 Mihomo로 이름을 바꿔 현재의 사실상 표준 코어로 자리잡았습니다. 프로토콜 지원 범위가 넓고 규칙 유형이 다양하며 TUN 구현도 더 완성도가 높아, 주요 GUI 클라이언트들은 모두 이 코어로 전환했습니다.
GUI 클라이언트와 코어는 서로 다른 두 계층입니다. 코어는 프로토콜 핸드셰이크, 규칙 매칭, 트래픽 전달을 담당하고, 클라이언트는 구독 관리, 화면 상호작용, 시스템 통합을 담당합니다. Clash Plus, Clash Verge Rev, FlClash 등의 클라이언트는 각각 독립적으로 개발·유지되지만 동일한 YAML 설정 형식을 읽습니다. 즉 구독과 규칙을 다른 클라이언트로 그대로 옮길 수 있어, 클라이언트를 바꿔도 설정을 처음부터 다시 배울 필요가 없습니다.
코어와 각 클라이언트의 코드는 모두 공개 저장소에 올라와 있어 커밋 기록, 이슈 논의, 버전 릴리스를 누구나 확인할 수 있습니다. 버전 업데이트는 각 프로젝트 커뮤니티가 주도합니다: 코어는 프로토콜과 규칙 구현을 개선하고, 클라이언트는 코어 버전에 맞춰 화면을 갱신합니다. 본 사이트의 다운로드 페이지에 있는 버전 정보와 설치 파일은 각 프로젝트의 공식 배포 채널과 동일하며, 별도로 수정해 배포하지 않습니다.
설정 형식이 순수 텍스트인 YAML이라는 점은 실질적인 장점을 만듭니다: 어떤 설정 문제든 '파일의 어느 줄에 무엇이 적혀 있는지'로 명확히 환원할 수 있어 백업하고, 비교하고, 글에서 한 줄씩 짚어가며 설명할 수 있습니다. 본 사이트의 가이드와 문제 해결 글은 모두 이 형식을 기준으로 작성되었으므로, 자신의 설정 파일을 놓고 그대로 따라 하면 됩니다.
git clone https://github.com/MetaCubeX/mihomo.git
코어 소스 코드 저장소입니다. 일반 사용자는 직접 빌드할 필요 없이 다운로드 페이지에서 GUI 클라이언트를 받으면 됩니다.
Clash YAML, 범용 Base64, 각 클라이언트 전용 형식의 차이를 분석하고, 구독 변환 서비스의 동작 원리와 흔한 변환 실패 원인, 서로 다른 코어 클라이언트 간 동일한 구독을 옮기는 방법을 설명합니다.
READ →느린 속도 문제를 노드, 회선, 로컬 설정 세 단계로 나눠 진단하는 방법입니다. 먼저 지연 시간 테스트와 노드 전환으로 문제를 분리하고, 프로토콜과 포트 선택을 점검한 뒤, 마지막으로 시스템 프록시와 DNS, 분류 규칙이 직접 연결 트래픽을 느리게 만들고 있는지 확인합니다.
READ →실행 시 bind: address already in use 오류가 뜰 때의 전체 대처 과정입니다. netstat과 lsof로 7890 포트를 점유한 프로세스를 찾아, 종료할지 포트를 바꿀지 판단하고, 포트를 바꾼 뒤 시스템 프록시 설정도 함께 맞추는 절차를 안내합니다.
READ →