Clash 커널 버전 선택 가이드: 원본·Premium·Meta에서 mihomo까지
각 커널 계열의 탄생 배경과 현재 유지 관리 현황을 살펴보고, 클라이언트별 내장 커널을 확인해 플랫폼과 용도에 맞는 선택을 돕습니다.
클라이언트, 커널, 구독 설정을 구분하기
Clash를 고를 때 가장 헷갈리기 쉬운 부분은 화면에 표시되는 클라이언트 버전과 실제 연결을 처리하는 커널 버전입니다. 클라이언트는 구독 관리, 트레이 메뉴, 시스템 프록시 전환, 설정 편집을 담당하고, 커널은 YAML을 읽어 DNS를 해석하고 규칙을 적용해 프록시 연결을 설정합니다. 두 구성 요소는 따로 업데이트될 수 있으며, 이름도 서로 다를 수 있습니다.
구독은 설정을 가져오는 경로입니다. 노드만 제공할 수도 있고, 정책 그룹, 규칙, DNS, TUN 설정을 함께 포함할 수도 있습니다. 같은 구독이라도 클라이언트에 따라 다르게 작동하는 이유는 커널 기능 차이일 수도 있고, 가져온 뒤 클라이언트가 설정을 덮어썼기 때문일 수도 있습니다. 파일 확장자가 .yaml이라는 사실만으로 어떤 계열과 호환되는지 판단할 수는 없습니다.
- 클라이언트 버전: 인터페이스 기능, 운영체제 호환성, 릴리스 노트를 확인할 때 참고합니다.
- 커널 버전: 프로토콜, 설정 필드, TUN 구현, 규칙 기능을 확인할 때 참고합니다.
- 설정 형식: 구독에서 실제 사용하는 기능을 결정합니다. “Clash 구독”이라는 표현만으로 호환성을 판단할 수는 없습니다.
발전 과정: 네 가지 버전이 차례로 업그레이드된 것은 아닙니다
원본 Clash: 오픈 소스 규칙 기반 프록시 커널
일반적으로 원본 Clash라고 하면 Dreamacro/Clash 프로젝트의 오픈 소스 커널을 가리킵니다. 이 커널은 많은 사용자에게 익숙한 proxies, proxy-groups, rules 등의 설정 구조를 정립했습니다. 규칙을 순서대로 검사해 일치하는 항목이 있으면 해당 아웃바운드를 선택하는 방식은 이후 분기에도 이어졌습니다.
2023년 11월 무렵 프로젝트에 변화가 생긴 뒤 원본은 기존 공식 채널에서 더 이상 지속적으로 유지 관리되지 않고 있습니다. 현재 볼 수 있는 원본 설치 파일, 미러 저장소, 제3자 재컴파일 버전을 원 개발자가 배포를 재개한 것으로 간주해서는 안 됩니다. 구형 설정을 이해하는 데는 여전히 유용하지만, 최신 프로토콜 지원을 평가할 때 기본 기준으로 삼기는 어렵습니다.
Clash Premium: 과거의 비공개 강화 커널
Premium은 원 프로젝트가 제공했던 비공개 강화 버전으로, 특정 그래픽 클라이언트의 유료 회원 등급이 아닙니다. 원본에 TUN, 규칙 제공자, 스크립트 등의 강화 기능을 추가했습니다. 여기서 “Premium”은 커널 계열을 뜻하며 구독 서비스의 유료 여부와는 관련이 없습니다.
Premium 역시 기존 채널을 통한 업데이트가 중단됐습니다. 구형 가이드에 나오는 script나 Premium 전용 옵션을 mihomo에서도 그대로 쓸 수 있다고 보면 안 됩니다. 마이그레이션할 때는 실행 파일 이름만 바꾸지 말고, 대상 커널의 문서를 확인해 항목별로 바꿔야 합니다.
Clash Meta: 원본에서 갈라져 나온 커뮤니티 계열
Clash Meta는 원본을 바탕으로 발전한 커뮤니티 분기로, 원본과 Premium이 존재하던 초기부터 병행해 개발됐습니다. 원본의 유지 관리가 중단된 뒤에야 등장한 것은 아닙니다. 프로토콜과 설정 기능을 확장하며 독자적인 유지 관리 경로를 갖추게 됐습니다. 구형 클라이언트의 “Meta 커널” 옵션이나 구형 구독의 Meta 형식은 보통 이 계열을 가리킵니다.
mihomo: Meta 계열의 후속 프로젝트 이름
Clash Meta는 이후 mihomo로 이름을 바꿨으며, 프로젝트의 유지 관리 채널은 보통 MetaCubeX/mihomo로 표시됩니다. 원본 Clash의 공식 후속작도, Premium을 잇는 차세대 비공개 버전도 아닙니다. 이를 알아야 “Meta 설정을 mihomo에서 쓸 수 있는가?”를 올바르게 판단할 수 있습니다. 기본 구조는 대체로 이어서 사용할 수 있지만, 개별 필드의 지원 여부는 실행 중인 버전에 따라 다릅니다.
이름이 바뀌었다고 구형 바이너리에 새 기능이 자동으로 추가되는 것은 아닙니다. 일부 클라이언트 메뉴에는 여전히 “Meta”라고 표시되지만 실제로는 mihomo를 포함하고 있을 수 있습니다. 반대로 오래된 설치 파일에는 초기 Meta 빌드가 들어 있을 수도 있습니다. 실제 실행 로그나 커널 버전 출력으로 확인하세요.
기능 비교: 설정 요구 사항별 확인
| 확인 항목 | 원본 Clash | Premium | Meta / mihomo |
|---|---|---|---|
| 유지 관리 경로 | 과거 오픈 소스 프로젝트, 기존 채널의 업데이트 중단 | 과거 비공개 강화 버전, 기존 채널의 업데이트 중단 | 커뮤니티 유지 관리 계열, 현재 프로젝트 이름은 mihomo |
| 기본 규칙 기반 분기 | 도메인, IP, 정책 그룹 등의 기본 구조 지원 | 기본 구조를 유지하면서 강화 기능 제공 | 일반적인 구조를 유지하고 규칙 및 아웃바운드 기능 확장 |
| TUN 트래픽 처리 | 원본 오픈 소스 커널에 기본 포함되지 않음 | 과거 버전에서 제공했으며 설정은 구형 구현에 제약됨 | TUN 지원. 구체적인 설정 필드와 플랫폼 지원 여부는 버전별로 확인 필요 |
| 최신 노드 프로토콜 | 이후 추가된 프로토콜을 지원하지 않음 | 구형 빌드에서 이후 추가된 프로토콜을 지원한다고 기대할 수 없음 | 더 폭넓은 프로토콜 지원. 예: VLESS, Hysteria2, TUIC. 실제 지원은 버전에 따라 다름 |
| 스크립트 호환성 | Premium 스크립트 설정을 그대로 사용할 수 없음 | 과거 전용 스크립트 기능 제공 | 기존 Premium 스크립트 설정을 그대로 실행한다고 가정할 수 없음 |
프로토콜 지원은 이름만 비교해서 판단할 수 없습니다. 예를 들어 노드에 type: hysteria2가 지정돼 있으면 구형 커널은 로드 단계에서 “지원하지 않는 프록시 유형” 오류를 낼 수 있습니다. 프로토콜을 인식하더라도 인증 매개변수, 전송 옵션, TLS 설정이 서버와 맞지 않을 수 있습니다. 먼저 설정을 불러올 수 있는지 확인한 다음 연결 단계의 문제를 살펴보세요.
TUN을 켠다고 모든 트래픽이 프록시로 전송되는 것도 아닙니다. TUN은 트래픽이 커널로 들어오는 방식을 바꾸며, 커널에 들어온 뒤에는 규칙에 따라 DIRECT, 프록시 정책 또는 차단으로 처리될 수 있습니다. 시스템 프록시와 TUN은 트래픽을 가져오는 서로 다른 방식이지, “일반 속도”와 “가속 속도”를 선택하는 옵션이 아닙니다.
클라이언트별로 주로 사용하는 커널
아래 표는 흔히 볼 수 있는 조합을 식별하기 위한 참고 자료이며, 설치 파일의 릴리스 노트를 대신하지 않습니다. 같은 이름의 클라이언트도 버전에 따라 커널이 바뀌었을 수 있고, 배포 주체가 패키징 방식을 변경했을 수도 있습니다.
| 클라이언트 또는 사용 방식 | 일반적인 커널 구성 | 확인 방법 |
|---|---|---|
| Clash for Windows（CFW） | 과거 릴리스는 주로 Premium을 사용했으며, 클라이언트 유지 관리가 중단됨 | 해당 설치 파일의 커널 정보를 확인하고 CFW 창의 버전을 커널 버전으로 착각하지 마세요 |
| ClashX / ClashX Pro | 과거에는 원본과 Premium 계열이 각각 널리 사용됨 | 구체적인 배포 프로젝트, 빌드 날짜, 커널 정보를 확인하세요 |
| Clash Verge Rev | mihomo 계열 사용 | 커널 버전과 테스트 빌드 사용 여부를 확인하세요 |
| Clash Meta for Android | Meta / mihomo 계열 사용 | 앱에 표시된 커널 정보와 해당 릴리스 노트를 확인하세요 |
| Linux 서비스 또는 라우터 플러그인 | 실제로 실행되는 바이너리에 따라 다르며, 커널을 바꿀 수 있는 경우도 있음 | 서비스 시작 명령에 지정된 실행 파일 경로를 확인하세요 |
Windows, macOS, Linux
데스크톱에 새로 설치한다면 mihomo 사용을 명시하고 운영체제 아키텍처에 맞는 설치 파일을 제공하는 클라이언트를 우선 선택하세요. macOS에서는 Apple Silicon과 Intel을 구분하고, Linux에서는 x86_64, ARM64 등의 아키텍처를 확인해야 합니다. 아키텍처가 맞지 않으면 프로그램이 시작되지 않을 수 있으며, 이는 구독 설정과는 별개의 문제입니다.
Android 및 iOS
Android에서는 VPN 권한을 허용해야 앱이 기기 트래픽을 가져올 수 있지만, VPN 권한이 있다고 해서 커널이 구독의 모든 설정 필드를 지원하는 것은 아닙니다. iOS에서는 데스크톱 Clash처럼 이름이 같은 커널을 교체하는 방식으로 접근하지 마세요. 네트워크 도구마다 설정 형식과 구현이 다르므로, 노드 프로토콜을 지원한다는 이유만으로 YAML 전체가 호환된다고 판단하지 말고 해당 구독 형식의 가져오기를 지원하는지 확인해야 합니다.
실제 커널 확인하기: 버전 확인 후 설정 테스트
1단계: 실행 중인 파일 찾기
먼저 클라이언트의 커널 정보와 시작 로그를 확인하세요. 명령줄로 배포했다면 서비스가 실제로 호출하는 파일에 버전 명령을 실행하세요. 다운로드 폴더의 새 파일은 테스트하면서 백그라운드 서비스는 이전 경로의 파일을 계속 실행하는 일이 없도록 주의해야 합니다.
# Linux / macOS: 커널 파일이 있는 디렉터리에서 실행
./mihomo -v
# Windows PowerShell: 커널 파일이 있는 디렉터리에서 실행
.\mihomo.exe -v출력에서 커널 이름, 버전 번호, 빌드 정보, 파일 경로를 기록해 두세요. 문제를 보고할 때는 “최신 버전으로 업데이트했다”는 설명보다 이런 정보가 훨씬 유용합니다. 클라이언트와 커널은 서로 다른 버전 체계를 사용하므로 두 버전 번호의 크기를 직접 비교해 어느 쪽이 최신인지 판단할 수 없습니다.
2단계: 대상 커널로 YAML 확인
# Linux / macOS
./mihomo -t -f ./config.yaml
# Windows PowerShell
.\mihomo.exe -t -f .\config.yaml-t는 설정 테스트에, -f는 설정 파일 지정에 사용합니다. 규칙 파일이나 기타 리소스를 상대 경로로 참조한다면 작업 디렉터리도 확인하세요. 서비스 배포에서는 -d로 설정 디렉터리를 지정할 수 있습니다. 테스트를 통과했다는 것은 관련 로드 검사를 통과했다는 뜻일 뿐, 모든 원격 노드와 규칙 다운로드 주소, DNS 업스트림에 연결할 수 있다는 뜻은 아닙니다.
3단계: 최소 설정으로 주변 요소의 영향 배제
아래 예시는 설정 구조와 로컬 리스너만 확인하기 위한 직접 연결 구성입니다. 로컬에서 혼합 프록시 포트 7890를 열며, 원격 노드와 TUN 설정은 포함하지 않습니다. 클라이언트가 이미 해당 포트를 사용 중이면 기존 인스턴스를 먼저 중지하거나 테스트 파일에서 사용 가능한 포트로 바꾸세요.
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxies: []
proxy-groups:
- name: 수동 선택
type: select
proxies:
- DIRECT
rules:
- MATCH,수동 선택이 설정은 시작되는데 전체 구독은 시작되지 않는다면, 구독 필드, 외부 리소스, 정책 그룹 참조, 클라이언트 덮어쓰기를 중점적으로 확인하세요. 처음부터 DNS를 변경하고 TUN을 켜고 모든 규칙을 교체하지 마세요. 설정을 한 번에 한 종류씩 바꿔야 로그를 비교할 수 있습니다.
Premium 또는 구형 Meta에서 mihomo로 마이그레이션
- 기존 환경 보관: 원본 구독, 로컬 설정, 덮어쓰기 내용, 커널 버전을 백업하세요. 백업에는 노드 비밀번호와 구독 토큰이 포함될 수 있으므로 그대로 공개 업로드하지 마세요.
- 노드 유형 확인: 각
type과 매개변수를 확인하세요. 구독 서비스에서 mihomo 형식이라고 명시한 구성을 우선 사용하고, 구형 “Clash 형식”만 제공된다면 먼저 설정 테스트를 진행하세요. - 규칙과 스크립트 확인: 기본 규칙은 대체로 쉽게 옮길 수 있습니다. Premium 스크립트 로직은 별도로 검토해야 하며 mihomo에서도 동일하게 작동한다고 가정해서는 안 됩니다.
- 일반 프록시부터 확인: 우선 TUN을 켜지 말고 로컬 포트 리스닝, 정책 그룹 선택, 주요 웹사이트 접속이 정상인지 확인한 뒤 DNS와 가상 네트워크 어댑터의 트래픽 처리를 점검하세요.
- 덮어쓰기 설정은 하나씩 복원: 규칙 제공자, DNS, 사용자 지정 라우팅, TUN을 차례대로 복원하고, 각 변경 후 다시 테스트해 시작 로그를 확인하세요.
일반 프록시는 작동하지만 TUN을 켠 뒤 실패한다면 관리자 권한, 라우팅, DNS 처리, 다른 VPN과의 충돌을 추가로 확인하세요. 이를 곧바로 “mihomo와 구독의 비호환성”으로 단정해서는 안 됩니다. 시작 단계에서 알 수 없는 필드나 프로토콜, 누락된 정책 그룹 오류가 발생했다면 먼저 설정을 수정해야 합니다. 시스템 프록시 스위치를 바꿔도 설정 로드 오류는 해결되지 않습니다.
선택 체크리스트: 필요한 기능에 맞춰 고르기
- 새로 설치하거나 최신 프로토콜이 필요한 경우: mihomo를 명확히 통합하고 꾸준히 릴리스되는 클라이언트를 우선 선택한 뒤, 해당 프로토콜에 필요한 최소 커널 버전을 확인하세요.
- TUN이 필요한 경우: 다운로드 페이지에 “TUN”이라고 적혀 있는지만 보지 말고 클라이언트의 권한 처리, 운영체제 지원, 커널 설정을 함께 확인하세요.
- 과거 설정을 재현해야 하는 경우: 해당 구형 커널과 설정 사본을 보관하고, 과거 동작을 현재의 표준으로 간주하지 마세요.
- 기기 성능이 제한적인 경우: 실제 규칙 규모, DNS 캐시, 연결 수를 살펴보세요. 커널 계열 이름만으로 메모리 사용량을 추측해서는 안 됩니다.
- 유지 관리 부담을 줄이고 싶은 경우: 릴리스 노트가 명확하고 커널 버전을 표시하며 백업과 롤백이 쉬운 클라이언트를 선택하세요. 매번 테스트 빌드를 따라갈 필요는 없습니다.
선택은 다음 순서로 진행하세요. 먼저 운영체제와 아키텍처를 확인하고, 다음으로 클라이언트에 포함된 커널을 확인한 뒤, 구독 형식을 검증하고 마지막에 TUN 등의 추가 기능을 켭니다. 클라이언트를 비교하려면 선택 가이드를, DNS 및 가상 네트워크 어댑터 설정은 DNS 설정과 TUN 설정을 참고하세요. 인터페이스 버전, 커널 버전, 설정 출처를 따로 기록해 두면 이후 업그레이드와 문제 해결이 쉬워집니다.