Clash·mihomo·클라이언트 관계 정리: 오픈소스 생태계 계보

먼저 구분할 네 가지: 코어, 클라이언트, 대시보드, 설정

다운로드 페이지에서 Clash는 프록시 코어를 뜻하기도 하고, GUI 앱이나 Clash YAML 호환 설정 형식을 가리키기도 합니다. 프로젝트 간 관계를 파악하려면 먼저 각 프로젝트가 담당하는 계층을 살펴보고, 실제로 불러오는 코어의 이름과 버전을 확인해야 합니다. 이름에 Clash가 들어가는지만으로는 지원 프로토콜, 규칙 문법, TUN 지원 여부를 판단할 수 없습니다.

예를 들어 GUI 클라이언트가 정상적으로 열렸다는 사실은 화면 프로세스가 실행됐다는 뜻일 뿐입니다. 코어의 설정 검증에 실패했다면 프록시는 시작되지 않았을 수 있습니다. 반대로 화면을 닫은 뒤에도 백그라운드 서비스가 실행 중이면 연결이 계속 프록시를 거칠 수 있습니다. 문제를 해결할 때는 화면, 코어 프로세스, 시스템 프록시 상태를 각각 확인하세요.

프로젝트 계보: Clash, Premium, Meta, mihomo

Clash 원본: 규칙 기반 프록시 코어의 출발점

Clash 원본은 보통 Dreamacro/clash 프로젝트를 가리키며, Go로 작성된 규칙 기반 프록시 코어입니다. 이 프로젝트는 proxies, proxy-groups, rules, dns 등을 포함한 생태계의 일반적인 설정 구조를 정립했습니다. 원본 프로젝트는 2023년에 공개 유지보수가 중단됐습니다. 기존 바이너리가 실행된다고 해서 프로토콜 지원이나 시스템 호환성 업데이트가 계속 제공되는 것은 아닙니다.

Clash Premium은 과거에 별도로 배포된 계열로, TUN, 규칙 프로바이더, 스크립트 등의 기능을 추가했습니다. 이러한 기능을 모든 버전의 Clash 오픈소스 코어가 기본으로 제공한다고 보면 안 됩니다. Premium의 추가 기능은 완전히 오픈소스로 공개되지 않았으므로, “Clash 생태계에 오픈소스 프로젝트가 있다”는 것과 “Clash를 표방하는 모든 배포판의 소스 코드가 공개돼 있다”는 것은 별개의 이야기입니다.

Clash.Meta: 프로토콜과 규칙 기능을 확장한 포크

Clash.Meta는 Clash에서 파생된 포크로, 프로토콜 지원, DNS, 스니핑, TUN 등의 기능을 확장했습니다. 예전 가이드에서 사용하는 Meta, Clash Meta, 파일명의 clash-meta는 대체로 이 포크를 가리킵니다. 원본 코어에서 켜는 옵션도 아니고, 외관만 바꾼 클라이언트도 아닙니다.

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

MetaCubeX가 관리하던 Clash.Meta는 이후 mihomo로 이름이 바뀌었습니다. 현재 프로젝트를 확인할 때는 MetaCubeX/mihomo 저장소, 릴리스 내역, 바이너리 버전을 살펴보세요. 이전 설정, 경로, 클라이언트 화면에는 여전히 Meta라는 표기가 남아 있을 수 있습니다. 이름이 모두 바뀌지 않았다고 해서 다른 코어를 사용한다는 뜻은 아닙니다.

Dreamacro/clash
├─ Clash 원본 오픈소스 코어
├─ Clash Premium(과거의 기능 확장 배포판)
└─ Clash.Meta(포크)
   └─ mihomo(Meta 프로젝트의 후속 이름)

GUI 클라이언트 → 코어 실행·설정·내장
컨트롤 패널   → 코어의 컨트롤 인터페이스에 연결

Verge Rev, ClashX, Nyanpasu는 각각 어떤 계층인가

이 이름들은 주로 GUI 클라이언트를 가리킵니다. 클라이언트는 시스템 트레이, 구독 관리, 권한 요청 등의 인터페이스를 담당하고, 프로토콜 및 규칙 처리는 주로 함께 제공되는 코어가 담당합니다. 앱 업데이트와 코어 업데이트는 별도의 버전 체계일 수 있으므로 문제를 제보할 때 두 버전을 모두 적어야 합니다.

이름이 같은 포크는 관리 주체와 릴리스 내역을 확인하세요

Clash Verge 원본과 Clash Verge Rev는 하나의 프로젝트가 계속 이어진 것이 아닙니다. Rev는 이후 별도로 유지관리되는 포크입니다. 원본 프로젝트의 업데이트 중단 여부로 Rev의 상태를 판단하거나 양쪽 버전을 하나의 업데이트 순서로 이어 붙여서는 안 됩니다. ClashX의 여러 포크도 각각 확인해야 하며, 특히 최소 OS 버전, 프로세서 아키텍처, 코어 출처를 살펴보세요.

macOS 설치 패키지를 확인할 때는 Apple Silicon용 arm64와 Intel용 x86_64를 구분하세요. 호환성 계층을 통해 앱이 실행되더라도 백그라운드 보조 프로그램의 아키텍처, 설치 경로, 권한을 별도로 확인해야 합니다. iOS는 시스템 네트워크 확장 기능의 제약을 받으므로 데스크톱에서 보조 서비스를 설치하는 절차를 iPhone에 그대로 적용할 수 없습니다.

“Clash 설정 호환”이 모든 필드의 실행을 보장하지는 않습니다

Clash YAML은 공유되는 설정 기반이지, 모든 코어 버전에서 동일한 기능을 보장한다는 뜻은 아닙니다. 구형 코어는 최신 프로토콜, 스니핑 옵션, DNS 필드를 지원하지 않을 수 있습니다. 일부 필드는 실행 실패를 일으키고, 다른 필드는 예상대로 동작하지 않을 수 있습니다. 클라이언트에서 구독을 가져올 수 있어도 모든 노드의 연결 테스트가 끝났다는 의미는 아닙니다.

마이그레이션 전에 세 가지 차이 확인

1. 노드 프로토콜: 각 노드의 type과 관련 매개변수를 확인하세요. Hysteria2, TUIC 같은 노드는 대상 mihomo 버전의 지원 범위를 확인해야 합니다. Clash 원본의 기능을 기준으로 지원 여부를 추측하지 마세요.
2. 규칙 및 리소스: rule-providers 형식, behavior, 업데이트 경로를 확인하세요. RULE-SET을 사용한다면 해당 리소스 이름이 실제로 존재하는지도 확인해야 합니다.
3. 시스템 트래픽 처리: tun, DNS 하이재킹, 라우팅, 권한 요구 사항을 확인하세요. 설정 문법을 받아들이는 것과 시스템 라우트를 정상적으로 설치하는 것은 별도의 검증 단계입니다.

같은 구독도 최종 실행 설정은 달라질 수 있습니다

클라이언트는 구독을 내려받은 뒤 규칙을 추가하거나 포트를 변경하고 DNS 설정을 병합할 수 있습니다. 따라서 설정 화면에 저장된 원본 YAML이 코어가 실제로 읽는 파일과 다를 수 있습니다. “같은 구독이 다른 클라이언트에서는 정상 작동한다면” 여러 번 다시 가져오기보다 실행 설정을 먼저 비교하세요.

# 7890은 이 예시의 설정값이며 모든 클라이언트에서 고정으로 사용하는 포트가 아닙니다
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

mixed-port: 7890은 하나의 포트에서 HTTP와 SOCKS 프록시 연결을 모두 받는다는 뜻입니다. 컨트롤 인터페이스 포트가 아니며 TUN을 자동으로 활성화하지도 않습니다. 클라이언트에서 포트 덮어쓰기를 사용한다면 시스템 프록시는 최종 적용된 포트를 가리켜야 합니다. 구독의 숫자만 바꿔서는 실행 결과가 달라지지 않을 수 있습니다. 위 내용은 필드 일부일 뿐, 노드나 전체 규칙 설정을 포함하지 않습니다.

앱 제목이 아니라 실행 중인 코어 확인하기

클라이언트 메뉴 이름은 버전에 따라 달라질 수 있습니다. 서로 대조할 수 있는 정보를 이용해 확인하세요. 화면에 표시된 코어 항목, 로그의 시작 기록, 실제 바이너리의 버전 출력이 이에 해당합니다. 클라이언트 정보 화면의 버전은 앱 외부 부분의 버전일 뿐, 코어 버전을 대신하지 않습니다.

1. 앱 버전 기록: 클라이언트의 “정보” 또는 버전 정보 화면에서 앱의 전체 이름, 버전, 운영체제 아키텍처를 기록하세요. “최신 버전”이라고만 적지 마세요.
2. 코어 정보 확인: 설정에서 “코어”, “Core” 또는 코어 관리 메뉴를 찾아 현재 선택된 이름과 업데이트 채널을 기록하세요. 다운로드 목록에 보이는 다른 코어를 실행 중인 코어로 착각하지 마세요.
3. 시작 로그 확인: 설정을 다시 불러온 뒤 로그에서 코어가 정상적으로 시작됐는지, 설정 경로가 올바른지 확인하고, 알 수 없는 프록시 유형, 리소스 로드 실패, 포트 사용 중 오류가 있는지 살펴보세요.
4. 실행 파일 확인: 추가 문제 해결이 필요하다면 클라이언트가 실제 사용하는 바이너리에 버전 확인 명령을 실행하세요. 별도로 내려받은 같은 이름의 파일은 그 파일의 버전만 알려줍니다.

# macOS / Linux: 현재 디렉터리에 mihomo와 config.yaml이 있어야 합니다
./mihomo -v
./mihomo -t -f ./config.yaml

# Windows PowerShell: 현재 디렉터리에 mihomo.exe와 config.yaml이 있어야 합니다
.\mihomo.exe -v
.\mihomo.exe -t -f .\config.yaml

-v는 버전을 확인하고, -t는 설정을 테스트하며, -f는 설정 파일을 지정합니다. 문법 테스트를 통과했다는 것은 해당 버전의 검사를 통과했다는 뜻일 뿐, 원격 노드에 연결할 수 있거나 TUN 권한이 승인됐다는 의미는 아닙니다. 설정에서 로컬 규칙, 인증서, 프로바이더 파일을 참조한다면 경로와 실행 디렉터리가 실제 환경과 일치하는지도 확인하세요.

작업에 맞는 클라이언트 선택: 설정을 검증한 뒤 시스템 트래픽 처리 확인

최신 프로토콜이나 mihomo 전용 필드가 필요한 경우

mihomo를 사용한다고 명시된 클라이언트를 선택한 다음 코어 버전과 필드 지원 여부를 확인하세요. 클라이언트에 노드 이름이 표시된다는 이유만으로 프로토콜 호환이 확인된 것은 아닙니다. 최소한 설정 테스트 통과, 대상 정책 그룹 선택, 실제 연결 한 번 수립, 연결 화면에서 적용된 규칙과 아웃바운드 이름 확인까지 진행하세요.

시스템 프록시 설정을 따르지 않는 앱에 TUN을 적용하려는 경우

클라이언트가 해당 플랫폼용 서비스나 보조 프로그램을 제공하는지, 시스템에서 필요한 권한을 승인했는지 확인하세요. 시스템 프록시는 프록시 설정을 따르는 앱에 주로 영향을 줍니다. TUN은 가상 네트워크 인터페이스와 라우팅으로 트래픽을 처리하며, 적용 범위는 라우트, 제외 항목, 플랫폼 제한에 따라 달라집니다. TUN을 사용한다고 모든 트래픽이 강제로 프록시로 전달되는 것은 아닙니다. 최종 아웃바운드는 여전히 규칙, 정책 그룹, 직접 연결 설정의 영향을 받습니다.

구형 클라이언트에서 유지관리 중인 프로젝트로 이전

1. 구독 출처, 직접 작성한 규칙, DNS 설정, 정책 그룹 선택을 백업하세요. 화면을 캡처하는 것만으로는 충분하지 않습니다.
2. 새 클라이언트에 먼저 설정 하나를 가져와 테스트를 통과하는지 확인한 뒤, 덮어쓰기 설정을 하나씩 복구하세요.
3. 기존 클라이언트의 시스템 프록시와 TUN을 끄고, 기존 백그라운드 서비스가 더 이상 트래픽을 처리하지 않는지 확인한 다음 새 클라이언트를 켜세요.
4. 프록시 포트를 확인하고 도메인 조회, 규칙 매칭, 대상 웹사이트 연결을 각각 테스트하세요. 문제가 생기면 이 세 단계별로 기록하세요.
5. 검증을 마친 뒤 기존 서비스와 시작 프로그램 항목을 정리하세요. 두 프로그램이 같은 포트를 동시에 사용하지 않도록 주의해야 합니다.

클라이언트를 선택할 때 가장 유용한 기록은 “앱 이름과 버전, 코어 이름과 버전, 실행 설정 출처, 시스템 트래픽 처리 방식”입니다. 앱 외관에 따라 조작 경로가 달라지고, 코어에 따라 프로토콜과 규칙 기능이 달라지며, 운영체제 권한에 따라 트래픽 처리가 가능한지가 달라집니다. 이 세 가지를 따로 확인해야 클라이언트 교체, 코어 업데이트, 설정 수정 중 무엇으로 문제를 해결할지 판단할 수 있습니다.

플랫폼 지원을 비교하려면 클라이언트 비교를 확인하세요. 정책 그룹, 규칙, DNS의 차이를 알아보려면 용어 빠른 확인을 참고하세요. 설치 후에는 현재 클라이언트에 실제로 제공되는 설정을 기준으로 확인하고, 다른 포크의 메뉴 화면을 혼용하지 마세요.