Clash 오픈 소스 생태계 프로젝트 관계도: 코어 브랜치, 데스크톱 클라이언트와 모바일 구현

Clash를 검색하면 Clash, Clash Meta, mihomo, Clash Verge Rev, Clash Nyanpasu, FlClash, OpenClash 같은 이름을 함께 접하게 됩니다. 이들은 하나의 프로그램을 여러 설치 패키지로 나눈 것이 아니며, 모두 같은 팀이 관리하는 것도 아닙니다. 일부는 프록시 코어를 제공하고, 일부는 그래픽 인터페이스만 담당하며, Android, 라우터 또는 특정 데스크톱 운영체제를 대상으로 하는 프로젝트도 있습니다.

이 프로젝트들을 이해할 때는 이름을 먼저 외우기보다 어느 계층에 속하는지 판단하는 것이 중요합니다. 연결을 처리하는 코어인지, 설정을 조작하는 클라이언트인지, 시스템 트래픽을 가로채는 플랫폼 구성 요소인지, 아니면 노드와 규칙을 배포하는 구독 서비스인지 구분해야 합니다. 계층을 나누어 보면 버전 선택, 설정 호환성 확인, 문제 원인 파악이 훨씬 쉬워집니다.

Clash 생태계를 네 가지 계층으로 나누어 보기

실제로 작동하는 Clash 환경은 대개 여러 구성 요소가 결합되어 만들어집니다. 이름에 Clash가 들어 있다고 해서 반드시 원본 Clash 코어를 포함하는 것은 아니며, 이름에 Clash가 없다고 해서 일반적인 Clash 설정을 읽지 못하는 것도 아닙니다. 프로젝트 간 관계는 단일 제품의 버전 계보라기보다 여러 부품을 조합하는 구조에 가깝습니다.

구독 및 로컬 설정
        ↓
그래픽 클라이언트 / Web 제어판
        ↓
Clash 계열 코어: Clash, Clash Meta, mihomo
        ↓
시스템 프록시 / TUN / 라우터 전달
        ↓
대상 네트워크

첫 번째 계층: 구독과 설정

구독 주소는 일반적으로 YAML 설정을 반환하며, 프록시 노드, 프록시 그룹, 분할 라우팅 규칙, DNS 설정, 규칙 세트 참조 등이 포함될 수 있습니다. 구독 서비스는 클라이언트도 코어도 아닙니다. 클라이언트는 설정을 주기적으로 내려받아 관리할 뿐이고, 설정을 실제로 해석하고 연결을 처리하는 것은 코어입니다. 구독 내용에 특정 브랜치 전용 필드가 포함되어 있다면 더 오래된 코어로 바꿀 때 파싱 오류가 발생할 수 있습니다.

두 번째 계층: 클라이언트와 제어판

데스크톱 클라이언트는 보통 구독 업데이트, 프록시 그룹 전환, 연결 확인, 로그 표시, 시스템 프록시 전환, TUN 관리 기능을 제공합니다. 클라이언트에 코어가 함께 패키징되어 있을 수도 있고, 코어 파일을 바꿔 사용할 수 있게 되어 있을 수도 있습니다. Web 제어판은 외부 제어 인터페이스를 통해 코어에 연결되어 상태를 표시하며, 데이터 전달을 직접 담당하지는 않습니다.

세 번째 계층: 프록시 코어

코어는 포트 수신, DNS 해석, 규칙 매칭, 프록시 그룹 선택, 프록시 연결 수립, 로그 출력을 담당합니다. 같은 그래픽 클라이언트라도 다른 코어로 교체하면 사용할 수 있는 필드와 동작 방식이 달라질 수 있습니다. 따라서 문제를 진단할 때는 클라이언트 버전과 코어 버전을 함께 기록해야 하며, 단순히 “Clash 최신 버전”이라고만 적어서는 안 됩니다.

네 번째 계층: 시스템 트래픽 가로채기

시스템 프록시는 운영체제의 프록시 설정을 따르는 앱에만 영향을 줍니다. TUN 모드는 가상 네트워크 인터페이스를 만들어 시스템 프록시를 사용하지 않는 프로그램까지 더 폭넓게 처리할 수 있습니다. 라우터 배포는 방화벽, 정책 라우팅, DNS 전달을 통해 로컬 네트워크의 기기를 관리합니다. 세 가지 진입 방식 모두 최종적으로 연결을 코어에 넘길 수 있지만, 필요한 권한과 DNS 경로, 문제 해결 방법은 서로 다릅니다.

원본 Clash, Clash Meta와 mihomo의 브랜치 관계

원본 Clash는 초기 생태계의 핵심 기반이었습니다. YAML 설정, 규칙 매칭, 프록시 그룹, 외부 제어 인터페이스 같은 일반적인 구조를 정립했으며, 많은 데스크톱 클라이언트, 라우터 플러그인, 구독 템플릿이 이러한 인터페이스를 중심으로 만들어졌습니다. 원본 저장소가 지속적인 유지보수를 중단한 뒤에도 생태계 전체가 멈춘 것은 아니며, 현재 유지되는 브랜치와 호환 구현으로 이어졌습니다.

Clash Meta는 처음에 원본 Clash의 브랜치로 발전하면서 프록시 프로토콜, 규칙 기능, DNS 동작, TUN 지원, 설정 필드를 확장했습니다. 이후 프로젝트 명칭은 점차 mihomo로 바뀌었습니다. 현재 “Meta 코어”와 “mihomo 코어”라는 표현은 대개 같은 발전 계보의 서로 다른 시기를 가리키며, 동시에 설치해야 하는 별개의 코어를 뜻하지는 않습니다.

이름	프로젝트 위치	현재의 이해 방식	설정 시 주의점
Clash	초기 핵심 코어	많은 설정 형식과 인터페이스의 출처	후속 브랜치에서 추가된 일부 필드를 인식하지 못함
Clash Meta	확장 코어 브랜치	mihomo 발전 과정에서 사용된 이전 명칭	오래된 문서, 이전 디렉터리 이름, 클라이언트 인터페이스에서 자주 보임
mihomo	현재도 유지보수되는 코어 프로젝트	최신 Clash 계열 클라이언트에서 널리 사용하는 코어	해당 버전의 문서로 필드를 확인해야 함

mihomo는 일반적인 Clash 설정과 높은 호환성을 유지하지만, 모든 필드를 조건 없이 양방향으로 옮길 수 있다는 뜻은 아닙니다. 규칙 세트 제공자, 특정 DNS 옵션, 새로운 프로토콜 매개변수, 트래픽 스니핑 또는 확장 규칙 유형을 사용할 때는 대상 코어의 최신 문서를 기준으로 확인해야 합니다. mihomo 설정을 구버전 원본 코어에 그대로 전달하면 알 수 없는 필드, 프록시 그룹 참조 실패 또는 규칙 제공자 로드 실패가 발생하는 경우가 가장 많습니다.

데스크톱 클라이언트는 외피일 뿐, 코어 이름과 같은 뜻이 아닙니다

Windows, macOS, Linux 사용자는 보통 그래픽 클라이언트부터 접하게 됩니다. 클라이언트는 설정 파일, 코어 프로세스, 시스템 프록시, 트레이 메뉴를 하나의 인터페이스로 묶지만, 코어와는 여전히 서로 다른 계층입니다. 클라이언트 업데이트는 인터페이스와 플랫폼 통합만 바꿀 수 있고, 코어 업데이트는 프로토콜, DNS 또는 규칙 동작을 변경할 수 있습니다. 릴리스 노트에 앱 버전과 코어 버전이 따로 표시된다면 이러한 계층 분리를 보여주는 것입니다.

Clash Verge Rev

Clash Verge Rev는 Windows, macOS, Linux에서 주로 사용되는 크로스플랫폼 데스크톱 클라이언트입니다. mihomo를 기반으로 구독 관리, 프록시 전환, 시스템 프록시, TUN, 연결 기록, 로그 인터페이스를 제공합니다. 이름의 Rev는 커뮤니티에서 이어진 프로젝트임을 뜻하며, 이름이 비슷하지만 유지보수 상태가 다른 과거 프로젝트와 혼동해서는 안 됩니다.

이러한 클라이언트는 여러 설정을 시각적으로 관리하려는 데스크톱 환경에 적합합니다. 설치할 때는 운영체제뿐 아니라 프로세서 아키텍처도 확인해야 합니다. 예를 들어 Windows의 x64와 ARM64, macOS의 Intel과 Apple Silicon을 구분해야 합니다. 아키텍처가 맞지 않는 것은 설치 패키지 선택 문제이며, 구독 유효성과는 관련이 없습니다.

Clash Nyanpasu

Clash Nyanpasu 역시 데스크톱 그래픽 계층에 속하며 설정 관리, 코어 제어, 시스템 통합 기능을 제공합니다. Clash Verge Rev와 유사한 구독 내용을 사용할 수 있지만, 인터페이스 구현, 설정 저장 방식, 업그레이드 절차, 플랫폼별 세부 동작은 다릅니다. 두 프로젝트는 대개 대체 관계이므로 기능을 “완성”하기 위해 동시에 실행할 필요는 없습니다.

ClashX 계열 명칭

macOS 생태계에는 오랫동안 ClashX, ClashX Pro, ClashX Meta처럼 비슷한 이름의 프로젝트가 존재했습니다. 유지보수 주체, 코어 조합, 라이선스 방식이 완전히 같지는 않습니다. 이름을 확인한 뒤에는 저장소 출처, 마지막 릴리스 버전, 코어 유형, 지원하는 macOS 아키텍처를 추가로 살펴봐야 합니다. 이름에 “X”나 “Meta”가 들어간다는 사실만으로 현재 시스템에 적합한지 판단할 수는 없습니다.

데스크톱 클라이언트 간에 이전할 때는 앱 데이터 디렉터리 전체를 그대로 복사하지 않는 것이 좋습니다. 디렉터리에는 YAML 외에도 데이터베이스, 창 상태, 서비스 권한 정보, 시스템 프록시 백업, 이전 코어 파일이 들어 있을 수 있습니다. 더 안정적인 방법은 구독 주소와 확인된 로컬 덮어쓰기 규칙을 보존한 뒤 새 클라이언트에서 다시 가져오고, TUN, DNS, 시작 시 자동 실행 설정을 항목별로 복원하는 것입니다.

모바일, 라우터, Web 제어판의 구현 차이

모바일 프로젝트는 코어를 포장하는 것뿐 아니라 운영체제가 제공하는 VPN 인터페이스와 백그라운드 실행 제한도 준수해야 합니다. Android 클라이언트는 일반적으로 로컬 VPN 서비스를 통해 앱 트래픽을 코어로 전달하므로 상태 표시줄에 VPN 연결이 표시됩니다. 여기서 VPN은 시스템 트래픽의 진입점일 뿐이며, 구독 노드가 반드시 전통적인 VPN 프로토콜을 사용한다는 의미는 아닙니다.

Android 클라이언트

Clash Meta for Android는 한때 널리 사용된 Meta 계열 Android 구현이었으며, 오래된 튜토리얼에도 인터페이스 화면이 자주 등장합니다. 계속 사용할지는 프로젝트 유지보수 상태와 코어 업데이트 시점을 확인해 판단해야 합니다. FlClash 같은 크로스플랫폼 프로젝트도 Android에서 실행할 수 있으며 최신 Clash 계열 코어로 설정을 처리합니다. 앱마다 데이터 디렉터리와 로컬 백업 형식은 대개 호환되지 않지만, 표준 구독 주소는 다시 가져올 수 있습니다.

Android에서 브라우저만 사용할 수 있고 일부 앱이 연결되지 않는다면 앱별 라우팅, 우회 목록, VPN 권한, 배터리 절전 제한, IPv6 경로를 확인해야 합니다. 모든 도메인에서 실패한다면 먼저 DNS 로그와 설정 파싱 결과를 확인하세요. 모바일 문제는 노드를 계속 바꾸는 것만으로 해결하려 해서는 안 됩니다. 시스템 제한과 코어 설정은 서로 다른 계층의 문제이기 때문입니다.

iOS 및 iPadOS

iOS는 Network Extension 같은 시스템 메커니즘을 통해 네트워크 트래픽을 가로채야 하며, 앱 배포와 백그라운드 리소스도 플랫폼 규칙의 제약을 받습니다. 시장에는 일부 Clash 형식 설정이나 구독을 읽을 수 있는 네트워크 도구가 있지만, 이름과 코어, 설정 호환 범위는 각각 다릅니다. 프록시 그룹을 지원한다는 이유만으로 원본 Clash 프로젝트에 속한다고 판단해서는 안 됩니다.

가져오기 전에 앱이 지원하는 것이 완전한 Clash YAML인지, 구독 변환 후의 노드 목록인지, 아니면 자체 설정 형식인지 확인해야 합니다. 구독에 mihomo 전용 규칙과 DNS 필드가 포함되어 있다면 모바일 앱이 해당 내용을 무시하거나 변환하거나 거부할 수 있습니다. 이 경우 같은 데스크톱 설정을 반복해서 가져오기보다 대상 앱에 맞는 형식으로 준비해야 합니다.

OpenClash와 라우터 배포

OpenClash는 OpenWrt 환경을 위한 관리 및 통합 프로젝트입니다. 코어 다운로드와 실행, 실행 설정 생성, 방화벽 연동, DNS 전달 처리, 관리 페이지 제공을 담당합니다. 실제 트래픽은 선택한 코어가 처리합니다. OpenClash, mihomo, OpenWrt는 각각 관리 플러그인, 프록시 코어, 라우터 운영체제에 해당하며 서로를 대체할 수 없습니다.

라우터 배포는 데스크톱 클라이언트보다 로컬 네트워크 전달, 정책 라우팅, 투명 프록시, DNS 하이재킹 같은 단계가 더 많습니다. 클라이언트에서 노드가 정상으로 표시되어도 라우터 경로가 올바르다는 뜻은 아닙니다. 로컬 네트워크 기기에 연결할 수 없거나, 중국 본토 도메인 해석이 비정상이거나, 일부 기기가 계속 재연결을 반복한다면 코어 로그, DNS 업스트림, IPv4 및 IPv6 규칙, 방화벽 체인, 보조 라우터 게이트웨이 설정을 순서대로 확인해야 합니다.

Web 제어판

Yacd, MetaCubeXD 같은 Web 패널은 제어 인터페이스를 통해 프록시 그룹, 연결, 로그를 읽습니다. 이들은 조작 인터페이스이지 프록시 코어가 아닙니다. 브라우저 페이지를 닫아도 일반적으로 프록시 서비스가 중지되지는 않으며, 반대로 패널이 열려 있다고 해서 코어가 트래픽을 올바르게 처리하고 있다는 뜻도 아닙니다. 패널 연결에 실패하면 노드 프로토콜을 수정하기보다 제어 주소, 리스닝 범위, 인증 키, 방화벽을 확인해야 합니다.

같은 구독이 프로젝트마다 다르게 작동하는 이유

구독을 가져올 수 있다는 것은 클라이언트가 내용을 받아왔다는 뜻일 뿐입니다. 실제로 작동하려면 설정 파싱, 리소스 다운로드, DNS 초기화, 리스닝 포트 생성, 시스템 트래픽 가로채기 과정을 거쳐야 합니다. 프로젝트마다 이 단계의 기본값이 다르므로 같은 구독도 두 기기에서 서로 다른 결과가 나올 수 있습니다.

코어 버전이 다름: 최신 규칙 유형, 프로토콜 매개변수 또는 DNS 필드를 오래된 코어가 인식하지 못할 수 있습니다.
클라이언트 덮어쓰기가 다름: 클라이언트가 포트, 제어 인터페이스, TUN, DNS 또는 설정 디렉터리를 자동으로 변경할 수 있습니다.
규칙 리소스가 다름: 원격 규칙 세트를 내려받지 못하면 정책에 핵심 매칭 항목이 빠질 수 있으며, 로그에는 보통 provider 오류가 나타납니다.
시스템 진입 방식이 다름: 데스크톱은 시스템 프록시, 모바일은 로컬 VPN, 라우터는 투명 프록시를 사용하므로 트래픽 처리 범위가 자연스럽게 달라집니다.
DNS 경로가 다름: 시스템 DNS, 코어 DNS, 브라우저 보안 DNS, 라우터 전달이 동시에 존재할 수 있어 최종 질의가 같은 리졸버로 들어간다고 보장할 수 없습니다.
정책 선택이 동기화되지 않음: 설정의 프록시 그룹 기본 항목이 이전 기기에 저장된 선택과 다를 수 있으므로 가져온 뒤 현재 정책을 다시 확인해야 합니다.

문제를 확인할 때는 최소 경로부터 시작할 수 있습니다. 설정이 파싱되는지 확인하고, 연결이 검증된 노드 하나를 선택한 다음, 추가 덮어쓰기는 잠시 끄고 필요한 DNS와 규칙만 남긴 뒤 코어의 리스닝 포트를 테스트합니다. 코어에 직접 연결하는 테스트가 통과한 후 시스템 프록시나 TUN을 켜면 설정 계층, 코어 계층, 시스템 트래픽 가로채기 계층 중 어디에서 문제가 발생했는지 구분할 수 있습니다.

확인 순서:
1. 구독이 YAML을 정상적으로 반환하는가
2. 코어가 설정 파싱을 완료했는가
3. 프록시와 규칙 리소스가 로드되었는가
4. 로컬 리스닝 포트가 생성되었는가
5. 시스템 프록시 또는 TUN이 트래픽을 가로채는가
6. DNS 질의가 예상한 경로로 들어가는가
7. 규칙이 예상한 프록시 그룹에 매칭되는가

로그 수준은 먼저 info로 설정해 설정 로드, DNS, 규칙 세트, 연결 오류를 확인하세요. 특정 요청을 추적해야 할 때만 일시적으로 로그 상세도를 높여야 하며, 반복 기록이 핵심 오류를 가리지 않도록 주의해야 합니다. 규칙, DNS, TUN을 조정할 때는 한 번에 변수 하나만 변경하고 복원 가능한 원래 설정을 보관하세요.

유지보수 상태, 플랫폼, 설정 요구에 맞춰 프로젝트 선택하기

Clash 계열 프로젝트를 선택할 때는 먼저 유지보수 상태를 확인하고, 다음으로 플랫폼과 아키텍처를 확인한 뒤, 필요한 기능이 해당 코어에서 제공되는지 확인해야 합니다. 프로젝트 이름이 비슷하거나 검색 결과 상위에 노출되거나 오래된 튜토리얼이 많다는 사실만으로는 이러한 확인을 대신할 수 없습니다.

사용 환경	필요한 프로젝트 계층	중점 확인 사항
Windows, macOS, Linux 데스크톱	데스크톱 클라이언트와 mihomo 코어	운영체제 버전, 프로세서 아키텍처, TUN 권한
Android 스마트폰 또는 태블릿	모바일 클라이언트와 로컬 VPN 연동	유지보수 상태, 백그라운드 제한, 앱별 라우팅
iPhone 또는 iPad	플랫폼 메커니즘에 맞는 네트워크 도구	설정 형식, 배포 방식, 필드 호환성
OpenWrt 라우터	OpenClash, 코어와 방화벽 통합	기기 아키텍처, 저장 공간, DNS 및 IPv6
그래픽 인터페이스가 없는 Linux 서버	mihomo 명령줄과 서비스 관리	설정 경로, 실행 사용자, 포트와 로그

목표가 데스크톱 브라우저와 일반 앱의 프록시 사용이라면 유지보수가 활발한 데스크톱 클라이언트가 대체로 가장 간단합니다. 게임, 명령줄 프로그램 또는 시스템 프록시를 따르지 않는 소프트웨어까지 처리해야 한다면 TUN을 검토하세요. 로컬 네트워크 전체에 동일한 분할 라우팅을 적용하려면 라우터 방식을 고려하되, 방화벽과 DNS 문제를 직접 진단할 수 있는 여유를 확보해야 합니다. 서버 환경에는 보통 데스크톱 외피가 필요하지 않으므로 mihomo를 직접 실행하고 systemd로 관리하는 편이 명확합니다.

설정 이전은 특정 클라이언트의 내부 데이터베이스가 아니라 표준 YAML, 구독 주소, 직접 관리하는 규칙을 중심으로 진행해야 합니다. 코어 전용 필드는 별도로 기록해 다음 프로젝트가 실제로 지원하는지 확인하세요. 오래된 튜토리얼을 참고할 때는 먼저 튜토리얼에 나온 프로젝트 이름, 게시 시점, 코어 단계부터 확인한 뒤 현재도 적용할 수 있는 절차를 골라야 합니다.

관계도에서 프로젝트 위치를 최종적으로 판단하는 방법

새 프로젝트 이름을 발견했을 때는 네 가지 질문으로 위치를 파악할 수 있습니다. 프록시 코어를 포함하는가, 포함된 코어가 원본 Clash인지 이전 명칭인 Meta인지 mihomo인지, 시스템 프록시·TUN·로컬 VPN·라우터 방화벽 중 어떤 방식으로 트래픽을 가로채는지, 설정이 표준 Clash YAML인지 확장 필드인지 독립 형식인지 확인하세요. 네 가지 답이 명확해지면 생태계에서의 프로젝트 위치도 거의 확정됩니다.

Clash 생태계의 발전은 여러 독립 프로젝트의 협력에 달려 있습니다. mihomo는 최신 코어 기능을 담당하고, 데스크톱 및 모바일 클라이언트는 플랫폼 상호작용을 담당하며, OpenClash는 라우터 통합을 담당합니다. Web 패널은 원격 제어를, 구독 및 규칙 프로젝트는 설정 데이터를 담당합니다. 서로 조합할 수 있지만 릴리스 주기, 유지보수 팀, 호환 범위는 각각 독립적입니다. 선택할 때는 계층별로 확인하고, 문제를 해결할 때는 데이터 경로를 단계별로 점검하는 편이 모든 프로그램을 “Clash 클라이언트”라고 부르는 것보다 정확합니다.