mihomo·Clash Meta와 그래픽 클라이언트 관계 정리: 오픈소스 생태계 가이드

프록시 코어, 그래픽 프런트엔드, 모바일 앱을 기준으로 기존 코어와 Meta 계열, mihomo의 변천사와 주요 클라이언트의 기반 코어를 정리합니다.

먼저 세 계층으로 나눠 보세요: 프록시 코어, 관리 인터페이스, 시스템 연동

mihomo는 프록시 코어이며, Clash Meta는 이 프로젝트가 사용했던 이름입니다. Clash Verge Rev 같은 클라이언트는 코어와 그래픽 인터페이스, 시스템 연동 기능을 하나로 묶어 설치 가능한 제품으로 제공합니다.따라서 ‘Clash를 사용한다’는 말만으로는 실제로 어떤 코어가 실행 중인지, 어떤 프로토콜·설정 항목·시스템 기능을 지원하는지 알 수 없습니다.

문제를 해결할 때는 먼저 어느 계층에서 발생했는지 확인해야 합니다. 노드 프로토콜을 인식하지 못하면 코어의 기능과 설정 형식을 살펴보세요. 구독 버튼에서 오류가 나면 클라이언트의 다운로드나 파싱 단계에서 문제가 생겼을 수 있습니다. 브라우저에서는 접속되지만 다른 앱에서는 안 된다면 시스템 프록시, 가상 네트워크 인터페이스, 라우팅 설정도 확인해야 합니다.

계층주요 역할주요 점검 항목
프록시 코어설정 읽기, DNS 처리, 규칙 매칭, 프록시 연결 설정mihomo 버전, 실행 로그, 최종 YAML
그래픽 인터페이스구독 관리, 정책 그룹 선택, 연결 목록, 설정 편집클라이언트 버전, 구독 업데이트 기록, 오버라이드 설정
시스템 연동시스템 프록시 설정, 서비스 시작, TUN 인터페이스 생성권한, 서비스 상태, VPN 권한, 라우팅 테이블

이름의 변천: Clash, Clash.Meta, mihomo

기존 Clash: 설정 체계와 규칙 엔진의 출발점

기존 Clash는 이러한 도구에서 흔히 쓰이는 설정 구조를 정립했습니다. proxies로 프록시 노드를 정의하고, proxy-groups로 정책을 구성하며, rules로 연결 경로를 지정합니다. 이후 많은 클라이언트가 이 YAML 설정 방식을 이어받아, 인터페이스가 달라도 설정 일부를 공유하는 경우가 많습니다.

기존 오픈소스 코어와 과거의 Clash Premium도 구분해야 합니다. Premium은 일부 고급 기능을 제공하는 별도의 배포 계열이었으므로, 기능 목록을 기존 오픈소스 코어의 기능으로 그대로 간주해서는 안 됩니다. 원 프로젝트는 2023년 11월 공개 유지보수를 중단했습니다. 기존 소프트웨어가 계속 실행되더라도 이후 등장한 노드 프로토콜이나 새로운 설정 항목과의 호환성이 유지된다는 뜻은 아닙니다.

Clash.Meta: 호환성을 바탕으로 기능 확장

Clash.Meta는 Clash 생태계에서 발전한 포크로, 기존 설정과의 호환성을 유지하면서 프로토콜 지원, DNS, 라우팅 기능을 확장했습니다. 초기 문서나 구독 옵션, 클라이언트 메뉴에 나오는 ‘Meta 코어’는 대개 이 프로젝트 계열을 가리키며, 별도의 그래픽 클라이언트를 뜻하지 않습니다.

mihomo: Meta 프로젝트의 후속 이름

Clash.Meta는 이후 mihomo로 이름이 바뀌었으며, MetaCubeX 커뮤니티가 계속 개발하고 있습니다. 따라서 ‘Clash Meta와 mihomo 중 어느 쪽이 더 나은가’라는 질문은 대개 별개의 두 신생 프로젝트를 비교하는 것이 아니라 이전 이름과 현재 이름을 혼용한 것입니다. 파일명이나 호환 설정 항목, 로그에 Meta라는 문구가 남아 있어도 코어가 개명 이전 버전이라는 뜻은 아닙니다.

Clash 오리지널 오픈소스 코어
└─ Clash.Meta 포크
   └─ mihomo(후속 프로젝트 이름)

그래픽 클라이언트 및 모바일 클라이언트
└─ 각 코어 배포 계열을 통합하고 자체 인터페이스와 시스템 연동 기능 제공

이 도식은 코어 프로젝트의 변천과 클라이언트의 통합 관계만 나타냅니다. 이름에 Clash가 들어간 모든 소프트웨어가 같은 개발팀에서 나왔거나 동일한 오픈소스 라이선스를 사용한다는 뜻은 아닙니다. 프로젝트를 확인할 때는 저장소, 릴리스 안내, 라이선스 파일을 살펴보세요.

데스크톱 클라이언트: mihomo 기반과 과거 포크 구분하기

데스크톱 클라이언트는 보통 설정 관리와 코어 실행을 함께 담당합니다. 아래는 주요 프로젝트의 기술적 구분입니다. 실제 설치 파일에 포함된 코어 버전은 클라이언트 화면과 릴리스 안내에서 확인하세요.

클라이언트 또는 프로젝트코어 관계선택 시 유의 사항
Clash Verge Revmihomo를 코어로 사용하는 데스크톱 클라이언트Windows, macOS, Linux 지원. 기존 Clash Verge와 구분해야 합니다
Clash Nyanpasumihomo를 주 코어로 사용하는 데스크톱 클라이언트코어 배포 채널과 설치 파일은 각 릴리스 안내를 확인하세요
FlClashmihomo 기반 크로스플랫폼 클라이언트데스크톱과 Android는 시스템 연동 방식이 다릅니다
ClashX MetaMeta/mihomo 기술 계열의 macOS 클라이언트과거의 ClashX, ClashX Pro와 혼동하지 마세요
Clash for Windows과거 Clash 및 Clash Premium 코어를 사용원 프로젝트는 유지보수가 중단됐으므로 이름만 보고 mihomo의 최신 기능을 지원한다고 판단할 수 없습니다

Clash Verge Rev는 별도로 유지보수되는 후속 프로젝트이며, 기존 Clash Verge의 버전 번호만 바꾼 것이 아닙니다. 마이그레이션할 때는 기존 클라이언트의 시스템 연동이 그대로 이어질 것이라고 가정하지 말고, 서비스 설치 여부와 설정 폴더, 시작 프로그램을 다시 확인하세요.

이름이 비슷한 프로젝트도 주의해야 합니다. 이 사이트의 다운로드 목록에 있는 FlClashs는 위 표의 업스트림 FlClash와 이름이 비슷하다는 이유만으로 같은 배포 채널이라고 볼 수 없습니다. 파생 클라이언트를 사용할 때는 소스 코드 저장소, 통합된 코어, 설치 파일 출처를 각각 확인하세요. 다른 클라이언트도 같은 기준으로 살펴보면 됩니다.

모바일: Android VPN 서비스와 iOS 네트워크 확장

Android: Clash for Android와 Meta 포크는 별도로 확인

기존 Clash for Android는 유지보수가 중단됐습니다. 이름에 Meta가 들어간 Android 포크는 별도의 개발 계열이므로 기존 버전 기록만 보고 업데이트 상태를 판단할 수 없습니다. FlClash 같은 크로스플랫폼 클라이언트는 인터페이스 구현 방식은 다르지만 Android에서 mihomo를 통합해 사용할 수 있습니다.

Android 클라이언트는 보통 시스템 VpnService를 통해 기기의 트래픽을 연결합니다. 처음 활성화할 때 VPN 권한을 요청하는 것은 클라이언트가 로컬 가상 네트워크 인터페이스를 만들도록 허용하는 절차입니다. 시스템이 특정 원격 VPN 서비스에 자동으로 연결된다는 뜻은 아닙니다. 실제 연결 대상은 노드, 정책 그룹, 규칙에 따라 결정됩니다.

앱별 분할 라우팅, 백그라운드 실행, 로컬 네트워크 공유 지원 여부는 클라이언트 구현과 시스템 제약에 따라 달라집니다. 모바일에서 데스크톱과 같은 구독을 사용하더라도 앱 제외 목록, 배터리 최적화 설정, DNS 설정은 별도로 확인해야 합니다.

iOS: 인터페이스가 비슷해도 코어가 같다는 뜻은 아닙니다

iOS 클라이언트는 보통 Network Extension 같은 시스템 기능으로 네트워크 트래픽을 처리하며, 확장 실행 환경의 제약을 받습니다. 특정 Clash 구독을 가져올 수 있다는 것은 해당 형식을 지원하거나 변환할 수 있다는 뜻일 뿐, 같은 버전의 mihomo를 완전히 실행한다는 증거는 아닙니다.

iOS 앱을 선택할 때는 공개 문서에서 코어 출처, 지원 프로토콜, 설정 항목을 명확히 안내하는지 확인하세요. 특히 스크립트, 규칙 세트, DNS, TUN 관련 옵션은 데스크톱 안내서의 메뉴 경로를 그대로 따라 해서는 안 됩니다.

설정 호환성의 한계: 구독, 규칙, 인터페이스 오버라이드

구독 주소가 최종 실행 설정은 아닙니다

구독 응답은 완전한 YAML일 수도 있고 노드 목록만 포함할 수도 있으며, 클라이언트에서 변환해야 하는 다른 형식일 수도 있습니다. 완전한 설정에는 대개 proxies, proxy-groups, rules가 포함됩니다. 노드형 provider는 보통 노드만 제공하고, 정책 그룹과 규칙은 기본 설정에서 정의합니다.

그래픽 클라이언트는 로컬 오버라이드, 스크립트 처리, 인터페이스 설정을 구독 내용에 병합할 수도 있습니다. 따라서 ‘같은 구독인데 두 클라이언트의 결과가 다르다’는 문제를 해결할 때는 구독 원문만 비교하지 말고 코어에 전달되는 최종 설정을 비교해야 합니다. 마이그레이션할 때 기본 구독부터 가져온 뒤 오버라이드를 하나씩 복원하면 차이를 찾기 쉽습니다.

규칙 문법이 비슷해도 정책 이름을 확인하세요

아래는 규칙 순서를 설명하는 예시이며, 그대로 실행할 수 있는 완전한 설정이 아닙니다. 정책 그룹에 PROXY라는 이름이 이미 있어야 합니다. 여기서 PROXY는 직접 정의해야 하는 사용자 지정 이름이며, 기본 제공되는 범용 출구가 아닙니다.

rules:
  - DOMAIN-SUFFIX,example.org,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

규칙은 위에서부터 순서대로 매칭되며, 마지막의 MATCH는 앞선 규칙에 걸리지 않은 연결을 처리합니다. 마이그레이션 후 정책 그룹 이름을 ‘노드 선택’으로 바꿨는데 규칙에서 여전히 PROXY를 참조하면 설정 검증에 실패할 수 있습니다. 마찬가지로 RULE-SET에서 참조하는 규칙 세트 이름은 rule-providers에 정의되어 있어야 합니다.

TUN과 Fake-IP는 서로 다른 기능입니다

TUN은 트래픽을 코어로 전달하는 방식이고, Fake-IP는 도메인 정보를 복원할 수 있도록 가상 주소를 매핑하는 DNS 처리 모드입니다. 두 기능을 함께 사용하는 경우가 많지만 하나의 설정으로 취급해서는 안 됩니다. TUN을 켜도 잘못된 정책 그룹이 자동으로 수정되지 않으며, 모든 DNS 요청이 예상대로 코어에 전달된다고 보장하지도 않습니다.

설정의 tun, dns, 프로토콜별 항목과 규칙 세트 형식에는 버전 요구 사항이 있을 수 있습니다. 새 코어에서 인식하는 항목을 구형 Clash나 Premium은 지원하지 않을 수 있습니다. 알 수 없는 항목이나 지원되지 않는 프록시 유형이 나타나면 오류 항목을 지워 마이그레이션이 된 것처럼 처리하지 말고, 먼저 필요한 버전을 확인하세요.

현재 코어 확인하기: 버전, 프로세스, 로컬 제어 인터페이스

가장 신뢰할 수 있는 기록은 ‘클라이언트 이름과 버전 + 실제 실행 중인 코어 버전 + 최종 설정’입니다. 클라이언트 버전에 따라 메뉴 위치가 달라질 수 있으므로 ‘정보’, 코어 관리 화면, 시작 로그에서 전체 버전 문자열을 찾아보세요. 문제를 문의할 때는 ‘최신 버전’이라고만 적지 말고 원래 문자열을 남기세요.

  1. 실행 로그 확인: 연결을 종료한 뒤 코어를 다시 시작하고, 시작 로그에서 코어 이름과 설정 로드 결과를 확인합니다.
  2. 실제 바이너리 확인: 출처를 확인한 mihomo 파일에서 mihomo -v를 실행하세요. mihomo -t -f config.yaml로 지정한 설정을 검사할 수 있습니다. 명령줄에서 검사하는 파일은 클라이언트가 실제로 실행하는 코어와 일치해야 합니다.
  3. 제어 인터페이스 확인: 로컬 REST API를 활성화했다면 /version을 조회할 수 있습니다. 제어 포트와 프록시 포트는 용도가 다릅니다.

아래는 구체적인 예시 설정입니다. 혼합 프록시 포트는 7890, 제어 인터페이스는 127.0.0.1:9090입니다. 모든 클라이언트에 공통으로 적용되는 기본값은 아니므로 실제 실행 설정을 확인하세요.

mixed-port: 7890
external-controller: 127.0.0.1:9090
secret: "local-demo-token-change-before-use"

아래 명령으로 로컬 인터페이스를 조회할 수 있습니다. 예시 토큰은 먼저 직접 설정한 값으로 바꾸세요. 실제 토큰을 공개 문의에 붙여 넣지 마세요.

curl --header "Authorization: Bearer local-demo-token-change-before-use" \
  http://127.0.0.1:9090/version

Windows PowerShell에서는 curl.exe를 사용해 명령을 한 줄로 입력할 수 있습니다. 연결이 거부되면 포트가 잘못됐거나 인터페이스가 수신 대기 중이 아닐 수 있습니다. 401 응답이 오면 인증 토큰을 확인하세요. 버전 정보를 확인하려고 제어 인터페이스가 모든 네트워크 어댑터에서 수신하도록 설정하지 마세요. 제어 인터페이스는 설정과 연결을 관리할 수 있으므로 접근 범위를 제한해야 합니다.

클라이언트 선택 및 마이그레이션 체크리스트: 기능을 확인한 뒤 연결 방식을 조정하세요

클라이언트는 다음 순서로 선택하면 됩니다. 인터페이스 취향과 실제 실행 기능을 구분할 수 있고, 설정을 한꺼번에 너무 많이 바꿔 원인을 추적하기 어려워지는 상황도 피할 수 있습니다.

  1. 플랫폼과 아키텍처 확인: Windows, macOS, Linux, Android, iOS는 권한 체계가 서로 다릅니다. Apple Silicon과 Intel용 설치 파일도 크기만 보고 선택해서는 안 됩니다.
  2. 필요한 코어 기능 확인: 구독에 포함된 프로토콜 유형, provider 형식, DNS 항목이 대상 코어 버전에서 지원되는지 확인합니다.
  3. 설정 출처 백업: 구독 주소, 로컬 규칙, 오버라이드, 스크립트를 각각 저장하세요. 인증 정보가 포함된 설정을 공개된 곳에 업로드하지 마세요.
  4. 트래픽을 제어하는 클라이언트는 하나만 실행: 마이그레이션할 때는 포트 충돌과 라우팅 경합을 피하기 위해 기존 클라이언트의 시스템 프록시 또는 VPN/TUN을 먼저 끄세요.
  5. 기본 연결부터 테스트: 구독을 가져오고 정책 그룹을 선택한 다음 브라우저에서 요청을 보내세요. 연결 목록에서 적용된 규칙과 실제 출구를 확인합니다.
  6. 마지막으로 고급 기능 복원: TUN, DNS 오버라이드, 앱별 분할 라우팅, 시작 시 자동 실행을 하나씩 활성화하고 변경할 때마다 로그를 확인합니다.

정리하면 Clash는 이 설정 생태계의 중요한 출발점이고, Clash.Meta와 mihomo는 같은 프로젝트 계열에서 사용된 과거 이름과 후속 이름입니다. 그래픽 클라이언트는 코어를 각 운영체제와 연동합니다. 이 세 계층을 이해하면 문제 해결에 코어 업데이트, 설정 수정, 클라이언트 시스템 권한 조정 중 무엇이 필요한지 정확히 판단할 수 있습니다.

설정을 더 확인하려면 사용 설명서를 참고하세요. 정책 그룹, Fake-IP, TUN이 익숙하지 않다면 먼저 용어 안내를 읽어 보세요.

Clash 다운로드