Clash 오픈소스 생태계: 클라이언트·코어·유지보수 브랜치 선택 가이드

Clash 다운로드를 검색하면 Clash, Clash Meta, mihomo, Clash Verge Rev, Clash Nyanpasu 같은 이름을 한꺼번에 접하게 됩니다. 이들은 하나의 프로그램을 여러 설치 패키지로 나눈 것이 아니며, 단순히 버전 번호의 높고 낮음으로 정렬할 수도 없습니다. 이 생태계를 이해하려면 먼저 네트워크 처리를 담당하는 코어, 사용자 인터페이스와 시스템 통합을 담당하는 GUI 클라이언트, 서비스 제공자가 생성하는 구독 설정을 구분해야 합니다.

이름이 비슷한 프로젝트는 대개 역사적 계승, 설정 호환성 또는 커뮤니티 포크 관계에서 비롯되지만, 이름만으로 기능이 완전히 같다고 판단할 수는 없습니다. 실제로 선택할 때는 어떤 코어를 사용하는지, 프로젝트가 계속 릴리스되는지, 대상 운영체제를 지원하는지, 기존 설정이 특정 확장 필드에 의존하는지를 확인해야 합니다. 이제 각 계층별 관계를 살펴보겠습니다.

코어·클라이언트·구독 설정부터 구분하기

Clash 생태계는 세 계층으로 이해할 수 있습니다. 가장 아래에는 코어가 있으며, 프록시 포트를 수신하고 아웃바운드 연결을 생성하며 규칙을 해석하고 정책 그룹을 선택하고 DNS를 처리합니다. TUN 모드를 활성화하면 더 많은 시스템 트래픽도 처리합니다. 코어는 보통 명령줄 프로그램이나 백그라운드 프로세스로 실행되며, 설정 파일의 어떤 필드를 지원할지 결정하는 핵심 요소입니다.

두 번째 계층은 사용자가 직접 조작하는 데스크톱 또는 모바일 앱인 클라이언트입니다. 클라이언트는 설정 가져오기, 구독 업데이트, 프록시 노드 선택, 시스템 프록시 전환, 로그 확인, 코어 시작·중지 같은 기능을 제공합니다. 일부 클라이언트는 서비스 설치, 네트워크 권한 요청, TUN 장치 생성, 시스템 시작 항목 설정도 담당합니다. GUI가 업데이트되더라도 내장 코어는 별도로 업데이트될 수 있으므로 ‘클라이언트 버전’과 ‘코어 버전’은 따로 확인해야 합니다.

세 번째 계층은 설정입니다. 구독 링크에서 반환된 내용은 대개 YAML 설정으로 변환되거나 저장되며, 프록시 노드·프록시 그룹·규칙·DNS·TUN 옵션을 포함합니다. 구독은 코어도 클라이언트도 아닙니다. 같은 구독이 여러 앱에서 작동하는지는 노드 프로토콜, 설정 필드, 규칙 문법을 해당 코어가 지원하는지에 따라 달라집니다.

계층	주요 역할	선택 시 확인할 항목
코어	연결, DNS, 규칙 매칭, 정책 그룹 및 TUN 트래픽 처리	코어 이름과 버전, 프로토콜 및 설정 필드 지원 여부
GUI 클라이언트	구독 관리, 시스템 통합, GUI 조작 및 코어 수명 주기 관리	운영체제 지원, 릴리스 상태, 코어 업데이트 방식
구독 및 설정	노드, 규칙, 정책 그룹 및 실행 매개변수 제공	형식, 필드 호환성, 업데이트 방식 및 오버라이드 규칙

원본 Clash, Clash Meta, mihomo의 관계

원본 Clash: 생태계의 기반과 설정 출발점

원본 Clash는 규칙 기반 프록시, 정책 그룹, YAML 설정이라는 핵심 사용 방식을 정립했습니다. 여러 튜토리얼에서 사용하는 proxies, proxy-groups, rules, DIRECT, MATCH 등의 개념도 이 기본 모델에서 비롯되었습니다. 원본 프로젝트는 이후 지속적인 유지보수가 중단되었으므로, 설정 체계와 과거 호환성을 이해하기 위한 참고 자료로는 적합하지만 새 환경에서 우선 선택할 코어로 보기는 어렵습니다.

유지보수 중단이 기존 설정의 즉각적인 무효화를 뜻하지는 않습니다. 많은 기본 노드, 도메인 규칙, 정책 그룹은 여전히 비슷한 의미를 유지하지만, 새로운 프로토콜 지원, DNS 동작 수정, 운영체제 대응, TUN 기능 개선은 대개 후속 유지보수 브랜치에 반영됩니다. 오래된 코어를 계속 사용할 때 가장 큰 제약은 GUI가 아니라 이러한 후속 기능과 수정 사항을 받을 수 없다는 점입니다.

Clash Meta: 확장 기능을 위한 커뮤니티 브랜치

Clash Meta는 원본 설정 모델을 바탕으로 프로토콜 지원, 규칙 기능, DNS 옵션, TUN 관련 기능을 확장했습니다. Clash 사용자에게 익숙한 설정 구조를 상당 부분 유지하면서 Meta 계열에서만 존재하거나 더 완전하게 동작하는 필드도 추가했습니다. 구독 서비스가 설정을 ‘Meta’용으로 표시한다면, 해당 확장 기능에 의존할 수 있으므로 오래된 원본 코어에서 실행된다고 가정해서는 안 됩니다.

mihomo: Meta 이후 사용되는 현재 프로젝트명

mihomo는 Clash Meta 이후 사용된 프로젝트명으로, Meta와 전혀 무관한 네 번째 설정 체계라기보다 같은 유지보수 흐름의 연장선으로 이해할 수 있습니다. 일부 클라이언트 GUI, 구독 변환기, 이전 문서에는 여전히 ‘Clash Meta’가 표시되고 다른 곳에는 ‘mihomo’가 표시됩니다. 판단할 때는 GUI의 한 라벨만 보지 말고 코어 저장소, 실행 파일 정보, 실제 버전을 함께 확인해야 합니다.

새 환경에서 mihomo 계열을 선택하면 계속 발전하는 코어 기능을 이용하면서 Clash 스타일의 규칙과 정책 그룹도 유지할 수 있습니다. 다만 mihomo 확장 설정을 오래된 코어로 되돌릴 때는 호환되지 않을 수 있습니다. 반대로 구조가 표준적인 기본 Clash 설정은 대체로 mihomo로 옮기기 쉽지만, DNS·스크립트·규칙 제공자·프록시 프로토콜 필드는 반드시 확인해야 합니다.

주요 GUI 클라이언트와 코어는 같은 프로젝트가 아닙니다

GUI 클라이언트는 보통 별도 팀이 유지보수하며, 코어에 데스크톱 트레이, 구독 목록, 시스템 프록시, TUN 전환, 설정 오버라이드, 로그 패널을 추가합니다. 하나의 클라이언트가 버전에 따라 코어를 교체할 수도 있고, 사용자가 코어 채널을 선택하도록 허용할 수도 있습니다. 따라서 클라이언트를 비교할 때는 GUI 화면만 비교하지 말고 핵심 구성 요소를 어떻게 관리하는지도 확인해야 합니다.

Clash Verge Rev: 데스크톱 시스템 통합 중심의 클라이언트

Clash Verge Rev는 널리 사용되는 데스크톱 GUI 클라이언트로, Windows·macOS·Linux에서 구독 관리, 시스템 프록시, 서비스 모드, TUN 조작에 초점을 둡니다. 초기 동명 프로젝트와 계승 관계가 있지만, 현재 유지보수 저장소와 릴리스 기록을 기준으로 확인해야 합니다. mihomo 코어를 사용하고 트레이 전환과 GUI 기반 규칙 확인이 필요한 데스크톱 사용자라면, 이런 클라이언트가 명령줄 코어를 직접 실행하는 것보다 일상 관리에 편리한 경우가 많습니다.

Clash Nyanpasu: 독립 GUI와 멀티플랫폼 관리

Clash Nyanpasu 역시 커뮤니티에서 유지보수하는 GUI 프런트엔드로, 설정 관리·구독 업데이트·코어 실행 제어 기능을 제공합니다. mihomo와의 관계는 ‘클라이언트가 코어를 관리한다’는 것이지, mihomo의 다른 이름이라는 뜻이 아닙니다. 현재 기기에 적합한지는 해당 시점의 지원 플랫폼, 설치 방식, 알려진 문제, 코어 버전을 기준으로 판단해야 합니다.

모바일 클라이언트: 이름보다 권한 모델이 중요합니다

Android 같은 모바일 플랫폼의 Clash 스타일 클라이언트는 보통 시스템 VPN 인터페이스를 통해 트래픽을 처리하고 앱 내부에서 호환 코어를 실행합니다. 선택할 때는 시스템 버전, 백그라운드 실행 제한, VPN 권한, 앱별 분기, 코어 업데이트 상태를 확인해야 합니다. 데스크톱의 ‘시스템 프록시’ 개념을 모바일에 그대로 적용할 수는 없습니다. 모바일 앱은 VPN 서비스로 트래픽을 전달하는 경우가 많아, 시스템에 의해 백그라운드 앱이 종료되면 연결도 끊길 수 있습니다.

이름에 Clash가 들어간 오래된 클라이언트는 최근 릴리스 날짜와 저장소 상태를 특히 확인해야 합니다. 이름의 인지도는 유지보수 상태를 대신할 수 없습니다. 클라이언트가 여전히 실행되더라도 오래된 코어 버전에 고정되어 새 구독의 프로토콜 필드를 인식하지 못하거나, 최신 운영체제에서 필요한 대응이 빠져 있을 수 있습니다.

사용 시나리오에 맞는 유지보수 브랜치와 클라이언트 선택

데스크톱 일상 사용: 지속적으로 유지보수되는 mihomo GUI를 우선 선택

Windows·macOS·Linux 사용자가 주로 구독 가져오기, 정책 그룹 전환, 시스템 프록시 활성화, 가끔 TUN 사용을 원한다면, mihomo 코어를 채택하고 꾸준히 릴리스되는 GUI 클라이언트를 우선 검토하는 것이 좋습니다. Clash 설정 사용 습관을 유지하면서 GUI로 코어와 시스템 권한을 관리할 수 있기 때문입니다. 선택 전에는 Windows의 x64 또는 ARM64, macOS의 Apple Silicon 또는 Intel처럼 운영체제 아키텍처도 확인해야 합니다.

서버 및 게이트웨이: 코어를 직접 관리하는 편이 제어하기 쉽습니다

Linux 서버, 투명 게이트웨이 또는 컨테이너 환경에서는 GUI가 필수 조건이 아닙니다. mihomo 코어를 직접 실행하고 명확한 설정 경로, 로그 출력, 서비스 관리 방식을 구성하면 업그레이드 일정을 더 쉽게 통제할 수 있습니다. 이런 환경에서는 수신 주소, 방화벽, 라우팅 포워딩, DNS 포트 충돌, 프로세스 권한도 직접 처리해야 하므로 데스크톱 클라이언트의 원클릭 TUN 설정을 그대로 적용할 수 없습니다.

기존 설정이 안정적으로 작동한다면: 먼저 검증한 후 이전하기

현재 설정이 오랫동안 안정적으로 작동한다면 프로젝트 이름이 바뀌었다는 이유만으로 모든 규칙을 즉시 다시 작성할 필요는 없습니다. 설정을 복사한 뒤 새 클라이언트나 코어에서 병행 검증하고, 시작 로그·DNS 해석·정책 그룹 선택·규칙 매칭 결과를 확인하는 편이 안전합니다. 핵심 서비스 연결이 정상임을 확인한 뒤 기존 환경을 교체하세요.

구독에 새 프로토콜이나 Meta 필드가 포함된 경우: mihomo 호환성을 기준으로 선택

구독 설명에서 Clash Meta 또는 mihomo를 명시적으로 요구하거나, 오래된 코어가 인식하지 못하는 확장 항목이 설정에 포함되어 있다면 해당 코어를 선택해야 합니다. 알 수 없는 필드를 억지로 삭제하면 노드 매개변수, DNS 분기, 규칙 동작이 바뀔 수 있습니다. 구독 제공자에게 대상 클라이언트가 지원하는 형식으로 출력해 달라고 요청하고, 클라이언트 코어를 프로젝트가 권장하는 버전 범위로 유지하는 편이 적절합니다.

요구 사항	권장 방향	주요 확인 항목
데스크톱 구독 및 규칙 분기	지속적으로 유지보수되는 mihomo GUI 클라이언트	시스템 버전, 아키텍처, TUN 서비스 설치
서버 또는 게이트웨이 배포	mihomo 코어 및 시스템 서비스	권한, 라우팅, DNS, 방화벽 및 로그
기존 설정의 안정적인 이전	설정을 복사한 후 병행 테스트	필드 경고, 규칙 매칭, DNS 결과
Meta 전용 구독	mihomo 코어와의 호환성 확인	프로토콜, 확장 필드, 구독 변환 형식

기존 프로젝트에서 mihomo 클라이언트로 이전할 때의 점검 절차

기존 설정과 오버라이드 내용을 백업합니다.
기본 YAML 파일뿐 아니라 클라이언트의 구독 주소, 전역 확장 스크립트, 로컬 규칙, 정책 그룹 선택, DNS 오버라이드도 저장해야 합니다. 일부 클라이언트는 이러한 내용을 여러 디렉터리에 나누어 보관하므로 구독 파일만 복사하면 전체 동작을 복원하지 못할 수 있습니다.
새 클라이언트가 실제로 사용하는 코어를 확인합니다.
정보 페이지·코어 설정·시작 로그에서 이름과 버전을 확인하세요. 설치 패키지 이름만 보고 코어를 추정하지 말고, GUI 클라이언트 버전 번호를 mihomo 버전으로 착각해서도 안 됩니다.
먼저 기본 설정을 가져온 후 문법을 점검합니다.
YAML은 들여쓰기에 민감하며 목록 계층과 콜론 뒤의 공백도 파싱 결과에 영향을 줍니다. 시작에 실패하면 시스템 프록시를 계속 전환하거나 재설치를 반복하지 말고 로그에서 첫 번째 설정 오류를 찾아야 합니다.
프록시 모드와 TUN 모드를 각각 검증합니다.
먼저 시스템 프록시를 사용해 브라우저처럼 프록시 설정을 따르는 프로그램을 확인한 다음 필요할 때 TUN을 활성화하세요. TUN은 가상 네트워크 장치, 라우팅, DNS 가로채기를 포함하므로 일반 시스템 프록시보다 문제 범위가 넓습니다. 두 모드를 동시에 변경하면 원인 파악이 더 어려워집니다.
규칙과 정책 그룹의 실제 매칭 결과를 확인합니다.
자주 사용하는 도메인이 예상한 정책 그룹으로 들어가는지, 로컬 네트워크 주소가 올바르게 연결되는지, 최종 규칙이 매칭되지 않은 트래픽을 처리하는지 확인하세요. 자동 정책 그룹은 테스트 주소, 검사 간격, 노드 가용성도 확인해야 하며, 전환 동작을 코어 오류로 오해하지 않도록 주의해야 합니다.
검증을 마친 후 기존 클라이언트를 제거합니다.
두 클라이언트를 동시에 실행하면 포트 점유, 시스템 프록시 덮어쓰기, VPN 충돌, 라우팅 중복 수정이 발생할 수 있습니다. 이전을 테스트할 때는 한 번에 하나의 프로그램만 트래픽을 가로채도록 하고, 기존 환경을 복구하는 방법도 기록해 두세요.

Clash 프로젝트를 계속 사용해도 될지 판단하는 방법

오픈소스 프로젝트의 유지보수 상태는 저장소에 계속 접속할 수 있는지만으로 판단할 수 없습니다. 릴리스 기록, 커밋 활동, 이슈 처리, 문서 업데이트를 함께 확인하는 편이 더 신뢰할 수 있습니다. 성숙한 프로젝트가 매일 코드를 커밋할 필요는 없지만, 최신 시스템 호환성·핵심 결함·의존성 업데이트에는 대체로 명확하게 대응합니다.

최근 정식 릴리스를 확인하세요: 설치 패키지가 소스 코드 태그와 일치하는지 확인하고, 릴리스 노트에서 코어·시스템 권한·마이그레이션 관련 내용을 읽습니다.
코어 업데이트 방식을 확인하세요: 코어가 클라이언트 릴리스에 포함되는지, 클라이언트가 온라인으로 업데이트하는지, 수동으로 교체해야 하는지 알아보세요. 자동 업데이트 GUI가 코어까지 함께 업데이트한다는 보장은 없습니다.
지원 플랫폼의 범위를 확인하세요: Windows·macOS·Linux·Android라는 이름만 보지 말고 현재 운영체제 버전과 CPU 아키텍처를 확인합니다.
이슈 추적 영역을 확인하세요: 시작 실패, TUN, DNS, 절전 모드 복귀, 시스템 업그레이드 후 호환성 문제와 함께 유지보수 담당자가 실행 가능한 해결책을 제시하는지 중점적으로 살펴봅니다.
설정 문서의 출처를 확인하세요: 클라이언트 설정, mihomo 필드, 구독 서비스 규칙은 서로 다른 계층이므로 문서가 실제 구성 요소와 일치해야 합니다.
배포 경로를 확인하세요: 프로젝트가 명확히 안내한 릴리스 채널에서 설치 파일을 받아 동명으로 재패키징된 버전과 원본 프로젝트를 혼동하지 않도록 합니다.

최종 선택은 다음과 같이 정리할 수 있습니다. 신규 사용자는 지속적으로 유지보수되고 mihomo를 내장하거나 지원하는 GUI 클라이언트를 우선 선택합니다. 기존 사용자는 현재 코어와 설정 의존성을 먼저 확인한 뒤 이전 여부를 결정합니다. 서버 사용자는 mihomo 코어를 중심으로 감사 가능한 서비스·로그·업그레이드 절차를 구축합니다. 이렇게 하면 ‘프로젝트 이름이 너무 많다’는 문제를 코어 기능, 클라이언트 통합, 설정 호환성이라는 세 가지 검증 가능한 기준으로 바꿀 수 있습니다.