Clash 오픈소스 생태계 지도: 원본, Meta, mihomo와 각 클라이언트의 관계 총정리

먼저 코어, 클라이언트, 설정 파일을 구분하기

Clash 생태계에서 가장 흔한 오해는 Clash라는 이름이 붙은 모든 소프트웨어를 하나의 프로젝트로 보는 것입니다. 실제로는 네트워크 트래픽을 전달하는 코어, 그래픽 인터페이스를 제공하는 클라이언트, 구독 서비스나 사용자가 관리하는 YAML 설정의 세 계층으로 나뉩니다. 세 계층은 함께 사용할 수 있지만 유지관리 주체, 버전 번호, 호환 범위는 서로 다릅니다.

실제 트래픽 처리는 코어가 담당합니다

코어는 설정 파일을 읽고 로컬 프록시 포트를 수신하며 DNS, 규칙 매칭, 정책 그룹 선택, 아웃바운드 연결을 실행합니다. 클래식 설정에서 자주 사용하는 HTTP·SOCKS 혼합 포트는 7890이고, 외부 제어 인터페이스는 보통 127.0.0.1:9090으로 설정합니다. 시스템 프록시, TUN 가상 네트워크 인터페이스, 규칙 기반 분기는 최종적으로 코어에서 실행됩니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
secret: change-this-secret

클라이언트는 코어를 조작하는 인터페이스입니다

FlClash, Clash Verge Rev, ClashX 등의 이름은 대체로 그래픽 클라이언트를 가리킵니다. 클라이언트는 구독 가져오기, 코어 시작·중지, 시스템 프록시 변경, 연결 기록 표시를 담당하며 시스템 서비스와 TUN 권한을 관리하기도 합니다. 클라이언트가 실행된다고 해서 코어가 정상적으로 수신 중이라는 뜻은 아닙니다. 실행 상태를 확인할 때는 코어 로그, 포트 사용 현황, 제어 인터페이스를 함께 점검해야 합니다.

구독은 클라이언트 설치 파일이 아닙니다

구독 링크는 일반적으로 노드와 정책 설정을 반환합니다. 코어를 설치하거나 시스템 네트워크 권한을 자동으로 부여하지는 않습니다. 동일한 기본 구독을 여러 클라이언트에 가져올 수 있지만, 설정에 rule-providers, sniffer, Hysteria2, TUIC 또는 mihomo 전용 DNS 필드가 포함되어 있으면 클래식 Clash 코어가 이를 해석하지 못할 수 있습니다.

원본 Clash: 생태계의 설정과 API 기반

원본 Clash는 Dreamacro가 시작한 Go 기반 프로젝트입니다. 오늘날에도 많은 클라이언트가 이어받은 기본 모델을 정립했습니다. 프록시 노드는 proxies에, 정책 그룹은 proxy-groups에 넣고, 트래픽은 rules를 위에서부터 순서대로 매칭합니다. 또한 RESTful 외부 제어 인터페이스를 통해 그래픽 인터페이스에 상태, 연결 정보, 정책 전환 기능을 제공합니다.

mode: rule, mixed-port, dns.enable, external-controller 같은 클래식 필드는 지금도 생태계의 공통 언어입니다. 따라서 mihomo를 사용하더라도 설정 파일은 여전히 원본 Clash와 매우 비슷해 보입니다. 이는 호환성이 이어진다는 뜻이지, 두 코어가 동일한 유지보수 계열에 있다는 의미는 아닙니다.

원본 유지보수 중단이 실제로 미친 영향

원본 프로젝트는 2023년에 공개 유지보수가 중단되었으며, 흔히 알려진 아카이브 버전은 v1.18.0입니다. 유지보수 중단 이후에는 새로운 프로토콜, 규칙 기능, 운영체제 네트워크 스택 변화, 보안 수정이 원본에 지속적으로 반영되지 않습니다. 기존 기기에 고정된 클래식 설정은 계속 작동할 수 있지만, 새로 배포할 때 기본 선택으로 삼기에는 적합하지 않습니다.

설정 계층: 기본 프록시, 정책 그룹, 도메인 규칙은 여전히 높은 마이그레이션 가치를 지닙니다.
코어 계층: 원본이 새로운 프로토콜 지원이나 TUN 개선을 제공할 것으로 기대해서는 안 됩니다.
클라이언트 계층: Clash라는 이름을 계속 사용하는 소프트웨어라도 이미 mihomo로 교체되었을 수 있고, 여전히 구형 코어를 포함할 수도 있습니다.
구독 계층: 서버가 설정을 생성할 때 mihomo 확장을 활성화했다면 클래식 코어로 가져오는 즉시 필드 오류가 발생할 수 있습니다.

Clash.Meta에서 mihomo로: 이름 변경과 지속적인 발전

Clash.Meta는 처음에 Clash 설정 체계와의 호환성을 목표로 한 확장 브랜치였습니다. 원본에서 자주 쓰던 설정 구조와 제어 인터페이스를 유지하면서 더 많은 프록시 프로토콜, 규칙 세트, DNS 동작, 트래픽 스니핑, TUN 기능을 추가했습니다. 원본 유지보수가 중단된 뒤 Clash.Meta는 많은 신규 클라이언트가 채택한 코어 계열이 되었습니다.

이후 Clash.Meta는 mihomo로 이름을 바꾸었고, MetaCubeX 커뮤니티가 프로젝트를 유지하고 있습니다. 변경의 주요 대상은 프로젝트명, 바이너리 파일명, 이미지 이름, 문서 진입점이며 설정 체계 전체를 처음부터 다시 만든 것은 아닙니다. 예전 자료의 “Meta 코어”와 최신 자료의 “mihomo 코어”는 대개 같은 발전 계열의 서로 다른 단계를 가리킵니다.

mihomo가 클래식 코어에 더한 기능

더 다양한 아웃바운드 프로토콜: 기존 Shadowsocks, VMess, Trojan 외에도 VLESS, TUIC, Hysteria2, WireGuard 등의 구현을 지속적으로 확장합니다.
규칙 세트 기능:rule-providers를 사용하면 로컬 파일이나 원격 주소에서 규칙 모음을 불러올 수 있어 대규모 도메인·IP 규칙을 나누어 업데이트하기 편리합니다.
TUN 개선: 가상 네트워크 인터페이스를 통해 시스템 프록시를 따르지 않는 프로그램의 트래픽을 처리하고, 플랫폼별로 적합한 네트워크 스택을 사용할 수 있습니다.
트래픽 스니핑: 조건이 충족되면 TLS SNI 또는 HTTP Host에서 대상 도메인을 복원해, 대상 IP만 확인되는 연결도 도메인 규칙과 매칭할 수 있습니다.
DNS 확장: fake-ip, redir-host, 도메인별 리졸버 선택, 규칙 연동, 더욱 세분화된 nameserver 정책을 제공합니다.

mihomo를 사용하는 클라이언트를 설치했다고 해서 이러한 기능이 자동으로 활성화되지는 않습니다. TUN에는 여전히 시스템 권한과 올바른 라우팅이 필요하고, 스니핑에는 sniffer.enable: true 설정이 필요합니다. 원격 규칙 세트에는 유효한 다운로드 주소와 업데이트 주기가 필요합니다. 코어는 기능을 제공하고, 설정이 활성화 여부를 결정합니다.

현재 mihomo가 실행 중인지 확인하는 방법

가장 직접적인 방법은 클라이언트의 “정보”, “코어” 또는 “버전” 페이지를 확인하는 것입니다. 해당 정보가 표시되지 않는다면 외부 제어 인터페이스가 활성화된 상태에서 /version을 요청할 수 있습니다. 다음 명령은 제어 포트 9090을 사용하며 앞에서 설정한 제어 키를 적용합니다:

curl -H "Authorization: Bearer change-this-secret" \
  http://127.0.0.1:9090/version

반환 내용에는 보통 버전 문자열과 구현 식별자가 포함됩니다. 인터페이스 연결이 거부되면 먼저 코어가 실행 중인지 확인하고, external-controller가 로컬 주소에만 바인딩되어 있는지 점검하세요. 401 Unauthorized가 반환되면 제어 인터페이스에는 접근할 수 있지만 요청에 사용한 키가 일치하지 않는다는 뜻입니다.

FlClash, Verge, ClashX는 각각 어느 계층에 속할까

클라이언트의 가장 중요한 차이는 단순한 UI 스타일이 아니라 어떤 코어 유지보수 계열을 사용하는지, 시스템 프록시와 TUN을 어떻게 관리하는지, 설정을 그대로 이전할 수 있는지에 있습니다. 아래에서 프로젝트 계열별로 나누어 설명합니다.

FlClash: Flutter 클라이언트와 mihomo 코어

FlClash는 Flutter로 구축한 멀티플랫폼 그래픽 클라이언트이며 실행 코어로 mihomo를 사용합니다. 구독 관리, 정책 전환, 연결 확인, 로그 표시, 시스템 프록시 등의 작업은 FlClash가 담당하고, 프로토콜 해석과 규칙 실행은 mihomo가 처리합니다. 따라서 FlClash가 특정 프록시 프로토콜을 지원하는지 확인할 때는 FlClash에 통합된 코어 버전과 해당 프로토콜의 설정 필드를 함께 확인해야 합니다.

FlClash의 크로스 플랫폼 인터페이스는 일관된 조작 흐름을 유지하는 데 도움이 되지만 Windows, macOS, Linux, Android의 권한 모델은 서로 다릅니다. 예를 들어 데스크톱 시스템 프록시는 프록시 설정을 따르는 앱에 주로 영향을 주고, TUN 모드는 가상 네트워크 인터페이스를 생성해야 합니다. Android에서는 시스템 VPN 권한 승인 팝업을 통해 트래픽을 처리하므로 데스크톱 권한 절차를 모바일에 그대로 적용할 수 없습니다.

Clash Verge와 Clash Verge Rev: 이름은 비슷하지만 유지보수 계열은 다릅니다

기존 Clash Verge는 Windows, macOS, Linux에서 널리 사용되던 데스크톱 그래픽 클라이언트입니다. 원 프로젝트의 유지보수가 중단된 뒤 커뮤니티 후속 프로젝트인 Clash Verge Rev가 새로운 유지보수 브랜치가 되었습니다. “Verge 다운로드”를 검색하면 구버전, 복각 패키지, Rev 버전이 함께 노출되는 경우가 많으므로 전체 프로젝트명, 출시일, 코어 정보를 반드시 확인해야 합니다.

Clash Verge Rev는 mihomo 계열을 사용하며 데스크톱 트레이, 시스템 프록시, TUN, 구독 관리, 연결 확인이 필요한 사용자에게 적합합니다. 기존 Clash Verge의 설정 데이터는 마이그레이션 원본으로 활용할 수 있지만 데이터베이스, 서비스 설치 방식, 앱 설정이 완전히 호환된다고 가정해서는 안 됩니다. 이전할 때는 구독 주소와 직접 만든 YAML을 내보낸 뒤 새 클라이언트에서 다시 가져오는 방식이 더 안전합니다.

ClashX: 클래식 macOS 클라이언트 계열

ClashX는 macOS에서 초기에 인기를 얻은 메뉴 막대 클라이언트로, 과거 버전은 주로 클래식 Clash 코어를 기반으로 실행되었습니다. 원본 Clash의 설정 구조와 밀접하게 연결되어 있지만 주 유지보수 계열은 이미 정체된 상태입니다. 구형 ClashX에서는 기본 HTTP, SOCKS, 일반적인 정책 그룹이 계속 작동할 수 있지만 mihomo가 추가한 필드와 새 프로토콜은 기본적으로 호환된다고 볼 수 없습니다.

ClashX Pro, ClashX.Meta처럼 이름이 비슷한 프로젝트도 있었지만 하나의 저장소에서 이어진 연속 버전은 아닙니다. 특히 ClashX.Meta는 macOS 그래픽 인터페이스에 Meta 코어를 결합한 브랜치 방식의 사례입니다. “ClashX”라는 이름만 보이면 구체적인 브랜치, 마지막 출시일, CPU 아키텍처, 실제 코어를 추가로 확인해야 합니다.

Clash for Windows: 흔했지만 유지보수가 중단된 데스크톱 클라이언트

Clash for Windows는 흔히 CFW로 줄여 부르며 Windows, macOS, Linux를 지원했습니다. 그래픽 클라이언트이지 원본 Clash 코어 프로젝트와 동일하지 않으며, 클라이언트 자체도 전체 Clash 오픈소스 생태계의 단일 상위 프로젝트가 아닙니다. CFW는 2023년에 유지보수가 중단되었으므로 기존 설치 파일의 인터페이스와 코어에는 정기 업데이트가 제공되지 않습니다.

CFW에서 마이그레이션할 때는 애플리케이션 폴더 전체가 아니라 구독 URL, 직접 만든 설정, 오버라이드 규칙, 정책 설정을 보존하는 것이 중요합니다. 기존 설정의 parsers, 스크립트 또는 클라이언트 전용 오버라이드 기능은 다른 클라이언트에서 바로 인식되지 않을 수 있으므로 대상 클라이언트가 지원하는 오버라이드 방식이나 표준 mihomo YAML로 다시 작성해야 합니다.

지금도 자주 사용되는 기타 mihomo 클라이언트

Clash Nyanpasu: 데스크톱 플랫폼용 그래픽 클라이언트로, mihomo 코어 계열을 사용하며 설정, 프록시, 연결 관리를 제공합니다.
Mihomo Party: mihomo를 핵심으로 사용하는 데스크톱 클라이언트로, 이름에서 코어와의 관계를 직접 드러냅니다.
OpenClash: OpenWrt용 관리·통합 솔루션으로, 라우터 측 서비스에서 Clash.Meta 또는 mihomo를 실행하고 방화벽 규칙과 연동해 LAN 트래픽을 처리합니다.
명령줄 mihomo: 그래픽 클라이언트 없이 YAML, 시스템 서비스, 외부 제어 패널을 조합해 서버나 게이트웨이로 구성할 수 있습니다.

“실행된다”는 사실만으로 유지보수 상태를 판단할 수 없습니다

클라이언트가 시작된다는 것은 현재 설치 파일과 운영체제가 당장은 함께 작동한다는 뜻일 뿐입니다. 유지보수 상태를 판단하려면 릴리스 버전, 커밋 활동, 코어 업데이트 속도, 시스템 대응 기록을 확인해야 합니다. 특히 운영체제 메이저 업데이트 후에는 TUN 드라이버, 네트워크 확장, 시스템 서비스 권한, 코드 서명이 달라질 수 있습니다.

프로젝트 이름보다 신뢰할 수 있는 네 가지 점검 항목

최근 릴리스 확인: 저장소의 최근 문서 수정일이 아니라 최신 안정 버전의 출시일을 확인합니다.
코어 버전 확인: 클라이언트가 업데이트되어도 mihomo가 함께 업데이트된다는 보장은 없습니다. 정보 페이지나 코어 로그에 표시된 실제 버전을 확인하세요.
시스템 호환성 확인: macOS의 Apple Silicon·Intel, Windows의 x64·arm64처럼 설치 파일이 현재 CPU 아키텍처를 지원하는지 확인합니다.
문제 대응 확인: 설치 실패, TUN 시작 불가, 구독 해석 오류 등의 문제가 여전히 유지관리자에 의해 처리되는지 살펴봅니다.

이 글의 기준일인 2026년 7월 28일 현재, 원본 Clash, 기존 Clash Verge, ClashX 메인 계열, Clash for Windows는 유지보수가 중단된 프로젝트로 보아야 합니다. mihomo는 여전히 활발히 개발되는 코어 계열이며, FlClash와 Clash Verge Rev는 mihomo를 기반으로 구축된 독립 클라이언트 프로젝트입니다. 클라이언트의 유지보수 상태는 시간이 지나며 바뀔 수 있으므로 설치 전 해당 프로젝트의 최신 공식 릴리스 기록을 확인해야 합니다.

설정 마이그레이션: 기본 필드 호환성이 완전한 범용성을 뜻하지는 않습니다

클래식 Clash 클라이언트에서 mihomo 클라이언트로 옮길 때는 기본 노드, 정책 그룹, 규칙 문법이 이어지므로 대체로 수월합니다. 반대 방향의 마이그레이션은 더 자주 실패합니다. 클래식 코어가 mihomo에 후속 추가된 프로토콜과 필드를 인식하지 못하기 때문입니다. 이전 전에는 “표준 기본 설정”, “코어 확장 설정”, “클라이언트 전용 설정”을 먼저 구분해야 합니다.

대체로 그대로 이전할 수 있는 항목

구독 URL과 로컬 YAML 파일
일반적인 proxies, proxy-groups, rules
DOMAIN, DOMAIN-SUFFIX, IP-CIDR, GEOIP, MATCH 등의 기본 규칙
자주 사용하는 포트, LAN 접근 허용 스위치, 기본 DNS 주소

다시 확인해야 하는 항목

클라이언트 전용 오버라이드, 스크립트, 설정 병합, 구독 전처리 기능
TUN 네트워크 스택, 자동 라우팅, 엄격한 라우팅, 인터페이스 이름
GeoData 모드, 규칙 세트 형식, 원격 리소스 업데이트 주소
fake-ip 필터 목록, DNS 분기, 시스템 hosts 동작
VLESS, Reality, TUIC, Hysteria2 등의 확장 프로토콜 필드

마이그레이션을 마친 뒤에는 먼저 mode: rule을 유지한 상태에서 구독 업데이트, 노드 연결, DNS 해석, 규칙 매칭, 시스템 프록시를 순서대로 확인하세요. 마지막에 TUN을 활성화하면 한 번에 바뀌는 변수를 줄일 수 있습니다. 로그에 field not found, unsupported proxy type, YAML 해석 오류가 나타나면 클라이언트를 반복해서 재설치하기보다 먼저 필드 호환성을 확인해야 합니다.

선택 결론: 먼저 유지보수 계열을 고르고 인터페이스를 선택하세요

새로 설치할 때는 활발한 mihomo 코어를 사용하고 지속적으로 릴리스하며 현재 운영체제를 명확히 지원하는 클라이언트를 우선 선택하세요. Windows, macOS, Linux, Android에서 비슷한 조작 흐름을 원한다면 FlClash를 고려할 수 있습니다. 데스크톱 트레이와 시스템 서비스 관리를 선호한다면 FlClash, Clash Verge Rev, Clash Nyanpasu, Mihomo Party를 비교해 보세요. OpenWrt 라우터에서 LAN 트래픽을 중앙 관리하려면 OpenClash와 명령줄 mihomo를 검토해야 합니다.

구형 클라이언트가 여전히 실행되더라도 먼저 구독 주소를 기록하고 직접 만든 규칙을 내보내며 현재 포트를 확인해야 합니다. 흔히 사용하는 7890, 7891, 9090 포트를 기존 프로세스가 점유하면 새 클라이언트의 코어가 시작되지 않을 수 있습니다. 마이그레이션 중에는 시스템 프록시나 TUN을 한 번에 하나의 클라이언트만 관리하도록 해야 프록시 루프와 기본 라우팅 충돌을 줄일 수 있습니다.

전체 생태계는 다음과 같은 명확한 관계로 정리할 수 있습니다. 원본 Clash가 설정과 제어 인터페이스의 기반을 만들었고, Clash.Meta가 호환성을 유지하면서 기능을 확장했습니다. 이후 Clash.Meta는 mihomo로 이름을 바꾸고 계속 유지보수되고 있습니다. FlClash와 Clash Verge Rev는 mihomo를 호출하는 그래픽 클라이언트이며, ClashX, 기존 Clash Verge, CFW는 서로 다른 역사적 단계의 클라이언트 프로젝트입니다. 이 계층을 이해하면 이름이 비슷하다는 이유로 선택을 망설일 필요가 없습니다.