2026-08-21 선택 가이드 예상 읽기 시간 12분

Clash 원본·Meta·mihomo 커널 비교: 버전 계보와 호환성

Clash 원본 커널부터 Clash Meta, mihomo까지의 계보를 살펴보고 프로토콜 지원, 규칙 유형, 설정 필드 차이를 비교합니다. 클라이언트별 커널 세대도 확인할 수 있습니다.

커널, 클라이언트, 설정 파일부터 구분하기

커널은 프록시 연결, DNS 처리, 규칙 매칭을 실행하는 프로그램이고, 클라이언트는 이러한 기능을 관리하는 인터페이스입니다. 클라이언트는 업데이트 과정에서 커널을 바꾸기도 하고, 사용자가 직접 커널을 선택할 수 있게 하기도 합니다. 따라서 소프트웨어 이름에 Clash가 들어간다는 사실만으로 지원 프로토콜을 판단할 수는 없습니다.

설정 파일은 커널이 읽어들이는 입력값입니다. 확장자가 .yaml로 같다는 것은 YAML 문법을 사용한다는 뜻일 뿐, 노드 유형과 규칙 유형, 확장 필드까지 모든 커널이 인식한다는 의미는 아닙니다.

클라이언트 버전: 인터페이스, 시스템 프록시 설정, 구독 관리, 설치 문제를 파악할 때 확인합니다.
커널 이름과 버전: VLESS, Hysteria2, TUN, 특정 설정 필드의 사용 가능 여부를 판단할 때 확인합니다.
설정 생성 대상: 구독 변환기가 원본 Clash용 설정을 생성하는지, Meta/mihomo용 설정을 생성하는지 확인합니다.

계보 살펴보기: 원본, Premium, Meta, mihomo

Clash 원본과 Clash Premium은 지원 범위가 서로 다른 계열입니다

일반적으로 Clash 원본은 Dreamacro 프로젝트 계열의 Clash를 가리킵니다. 호환성을 따질 때는 오픈소스 커널과 Premium 커널도 구분해야 합니다. Premium은 TUN, 규칙 집합, 스크립트 등의 확장 기능을 제공했으며, 이를 원본 오픈소스 커널의 공통 기능으로 간주해서는 안 됩니다.

원 프로젝트 계열은 2023년 11월 공개 유지보수를 중단했습니다. 이미 설치한 구버전이 곧바로 작동을 멈추는 것은 아니지만, 새 프로토콜과 필드, 이후의 호환성 수정이 계속 제공되리라고 기대하기는 어렵습니다.

Clash Meta는 확장 포크이며, 이후 이름이 mihomo로 바뀌었습니다

Clash Meta는 Clash를 바탕으로 프로토콜, DNS, 라우팅, 연결 처리 기능을 확장했으며 이후 프로젝트 이름이 mihomo로 바뀌었습니다. 두 이름은 하나의 프로젝트가 발전해 온 과정이지, 함께 실행해야 하는 별개의 프로그램이 아닙니다. mihomo를 쓰기 전에 Meta를 먼저 설치할 필요도 없습니다.

오래된 튜토리얼의 ‘Meta 커널’, 설정 파일 주석의 Meta, 새 클라이언트에 표시되는 mihomo는 대개 같은 프로젝트 계열을 가리킵니다. 다만 같은 계열이라도 버전에 따라 기능은 다릅니다. 초기 Meta 빌드가 최신 mihomo 빌드와 동일한 것은 아닙니다.

커널 이름	특징	호환성 확인 사항
Clash 오픈소스 커널	원 프로젝트의 오픈소스 기본 구현	전통적인 노드 프로토콜과 기본 규칙 중심
Clash Premium	원 프로젝트의 확장 커널	TUN, 규칙 집합, 스크립트 등을 지원하며 오픈소스 버전과 혼동해서는 안 됨
Clash Meta	프로토콜과 라우팅 기능을 확장한 계열	많은 설정과 튜토리얼에서 여전히 Meta라는 이름을 사용
mihomo	Meta 프로젝트의 후속 이름	새 프로토콜과 확장 필드는 실제 빌드 버전을 기준으로 확인

프로토콜 지원: 화면에서 가져올 수 있는지보다 노드를 파싱할 수 있는지가 중요합니다

노드 프로토콜은 설정의 type 필드로 지정합니다. 클라이언트에서 구독 파일을 저장하는 데 성공해도 커널을 시작할 때 지원되지 않는 프록시 유형이라는 오류가 나올 수 있습니다. 이 경우 프록시 모드를 바꾸거나 수신 포트를 수정해도 프로토콜 파싱 문제는 해결되지 않습니다.

프로토콜 또는 기능	Clash 원본 오픈소스	mihomo
HTTP、SOCKS5、Trojan、VMess	일반적으로 지원되는 범위	지원. 전송 방식과 TLS 매개변수는 각각 확인 필요
Shadowsocks	기존 구현에서 지원하는 암호화 방식 지원	지원. 암호화 방식은 구현과 버전에 따라 다름
VLESS 및 REALITY	해당 조합 미지원	해당 노드 설정 지원
Hysteria2	미지원	`type: hysteria2` 지원
TUIC	미지원	지원. 서버의 프로토콜 버전 및 매개변수와 일치해야 함

REALITY는 독립된 프록시 유형이 아닙니다

일반적인 mihomo 설정에서 REALITY는 VLESS 노드의 보안 핸드셰이크 관련 설정이지, type을 reality로 지정하는 방식이 아닙니다. type: vless, tls, servername, reality-opts 등의 필드가 서버 설정과 일치하는지 확인하세요. VLESS를 지원하더라도 모든 전송 조합과 새 매개변수를 지원하는 것은 아닙니다.

구독 변환으로 구형 커널에 새 프로토콜을 추가할 수는 없습니다

변환기는 YAML 순서를 바꾸거나 정책 그룹을 생성하고 URI 매개변수를 필드로 변환할 수 있지만, 원본 커널에 Hysteria2 기능을 추가하지는 못합니다. 변환 후 노드가 사라졌다면 구독이 무효라고 단정하기 전에 변환 대상에서 미지원 프로토콜을 제외했는지 확인하세요.

구독 주소에는 보통 액세스 토큰이 포함됩니다. 문제를 진단할 때는 민감한 정보를 가린 단일 노드 구조, 오류 메시지, 커널 버전만 공유하고 전체 구독 링크는 공개 게시판에 붙여 넣지 마세요.

규칙과 필드: 기본 문법은 비슷해도 확장 기능을 다른 커널에 그대로 적용할 수는 없습니다

mixed-port, mode, proxies, proxy-groups, rules는 일반적인 설정 항목입니다. DOMAIN, DOMAIN-SUFFIX, IP-CIDR, MATCH 같은 기본 규칙도 여러 계열에서 널리 이어져 사용됩니다. 그렇다고 설정 파일 전체를 커널 간에 자유롭게 복사할 수 있는 것은 아닙니다.

규칙 집합: rule-providers와 RULE-SET은 Premium과 mihomo에서 모두 사용되지만, 이를 근거로 원본 오픈소스 빌드도 지원한다고 볼 수는 없습니다.
확장 규칙: mihomo의 논리 조합, 프로세스 경로, 인바운드 관련 규칙 등의 기능은 구체적인 규칙 이름과 버전 요구 사항을 확인해야 합니다.
규칙 파일 형식: 텍스트, YAML, mihomo의 MRS 형식은 확장자만 바꿔 서로 변환할 수 있는 파일이 아닙니다.
스크립트: Premium의 script 설정은 mihomo에서 일반적으로 호환되는 인터페이스가 아닙니다. 마이그레이션할 때는 대개 규칙이나 다른 지원 메커니즘으로 다시 작성해야 합니다.
DNS 확장: fake-ip, DNS 정책, 스니핑은 서로 다른 설정 계층에 속합니다. 이전 예제의 필드 이름과 기본 동작을 새 버전의 기준으로 그대로 적용해서는 안 됩니다.

아래는 일부러 기본 필드만 남긴 테스트 설정입니다. 로컬 7890 포트에서 수신하고 규칙 모드를 사용하며, 마지막에는 트래픽을 DIRECT로 보냅니다. 커널이 설정을 불러오고 로컬 프록시 연결을 받을 수 있는지 확인하기 위한 예시이며, 원격 프록시 노드는 포함하지 않습니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: 프록시 선택
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,프록시 선택
  - MATCH,DIRECT

기본 설정이 정상적으로 시작되면 노드, DNS, 규칙 집합, TUN을 차례로 추가하세요. 확장 설정 수백 줄을 한꺼번에 가져오면 필드, 파일 경로, 외부 리소스에서 오류가 동시에 발생해 원인을 찾기 어려워집니다.

TUN과 DNS: 커널 지원은 사용을 위한 조건 중 하나일 뿐입니다

TUN은 가상 네트워크 인터페이스로 라우팅된 트래픽을 받아 시스템 프록시 설정을 따르지 않는 프로그램에도 적합합니다. TUN은 네 번째 프록시 모드가 아닙니다. TUN을 켜도 이후 처리 방식은 rule, global, direct에 따라 결정됩니다.

이 부분에서 Clash 원본 오픈소스와 Premium은 차이가 뚜렷합니다. mihomo도 TUN을 지원하지만 운영체제 권한, 라우팅 설정, 클라이언트 통합이 함께 필요합니다. 데스크톱에서는 관리자 권한이나 서비스 모드가 필요할 수 있고, Android 클라이언트는 일반적으로 시스템 VPN 권한을 이용합니다.

mihomo TUN 설정 예시

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

이 내용은 설정 일부이며 모든 플랫폼에서 단독으로 사용할 수 있는 설정은 아닙니다. 1053은 예시에서 커널 DNS가 수신하는 포트이고, any:53은 일반 DNS 트래픽을 가로챌 대상입니다. 두 포트를 같게 설정할 필요는 없습니다. 예시의 업스트림 DNS에 현재 네트워크에서 연결할 수 없다면 사용 가능한 리졸버로 바꾸세요.

stack: mixed는 mihomo에서 선택할 수 있는 네트워크 스택 설정 중 하나이며, 모든 구형 커널에 그대로 복사해서는 안 됩니다.
auto-route는 관련 라우팅을 자동으로 설정합니다. 다른 VPN, 라우터 정책, 방화벽 제한까지 반드시 우회할 수 있다는 뜻은 아닙니다.
auto-detect-interface는 아웃바운드 인터페이스를 자동으로 감지합니다. 여러 네트워크 어댑터를 사용하는 환경에서는 실제 아웃바운드 선택을 확인해야 합니다.
앱이 직접 보내는 HTTPS DNS 요청은 any:53에 가로채이지 않을 수 있습니다. 앱의 보안 DNS 설정과 연결 기록도 확인하세요.

TUN을 켠 뒤 인터넷이 완전히 끊기면 우선 TUN을 끄고 로컬 7890 포트만 사용할 때 정상적으로 접속되는지 확인하세요. 기본 프록시는 되지만 TUN만 작동하지 않을 때 권한, 라우팅, DNS를 살펴보면 됩니다. 바로 구독을 바꿀 필요는 없습니다.

클라이언트별 커널과 버전 확인

클라이언트 이름은 참고만 하고, 실제 설치된 패키지에서 실행 중인 커널을 기준으로 판단해야 합니다. 일부 클라이언트는 커널 전환, 테스트 채널, 사용자 지정 바이너리 경로를 제공합니다. 앱 버전과 커널 버전이 같은 속도로 올라간다고 볼 수도 없습니다.

클라이언트 또는 계열	일반적인 커널 구성	중점 확인 사항
Clash for Windows 구버전	공식 구버전은 대체로 Premium 커널을 사용	인터페이스가 비슷하다는 이유만으로 mihomo 설정을 사용하지 마세요
Clash for Android 구버전	빌드 계열이 여러 가지	전체 버전, 빌드 출처, 커널 로그를 기록하세요
Clash Verge Rev	mihomo 사용	현재 선택된 커널과 버전 확인
FlClash	mihomo 기반	앱 버전과 커널 버전을 구분하세요
이름에 Clash가 포함된 기타 클라이언트	이름만으로는 판단할 수 없음	정보 화면, 시작 로그 또는 커널 파일 확인

명령줄에 접근할 수 있다면 바이너리에서 직접 확인

# Linux 또는 macOS: 실제 커널이 있는 디렉터리에서 실행
./mihomo -v
./mihomo -t -f ./config.yaml

# Windows PowerShell: 실제 커널이 있는 디렉터리에서 실행
.\mihomo.exe -v
.\mihomo.exe -t -f .\config.yaml

-v는 버전 정보를 출력하고 -t는 설정을 테스트합니다. 클라이언트가 파일 이름을 바꿀 수 있으므로 실제 파일 이름을 사용하세요. 상대 경로를 사용하는 규칙 집합이나 인증서를 테스트할 때는 작업 디렉터리도 클라이언트 실행 환경과 일치시켜야 합니다. 필요하면 -d로 설정 디렉터리를 지정하세요.

테스트 통과는 이번 검사에서 로드를 막는 문제를 발견하지 못했다는 뜻일 뿐, 원격 노드에 연결할 수 있다거나 TLS 매개변수가 올바르다는 의미는 아닙니다. 명령줄을 사용할 수 없다면 클라이언트의 ‘정보’ 또는 ‘커널’ 화면이나 시작 로그에서 커널 이름과 버전을 찾으세요. 메뉴 위치는 클라이언트마다 다릅니다.

마이그레이션 확인 순서: 로드, 연결, 규칙 순으로 점검

현재 상태를 저장합니다. 설정, 구독 출처, 정책 그룹 선택, DNS 및 TUN 설정을 백업하고 되돌릴 수 있는 클라이언트 환경을 남겨 두세요.
올바른 구독 대상을 선택합니다. VLESS, REALITY, Hysteria2 등의 노드가 있다면 서비스 제공자가 Meta/mihomo용이라고 명시한 설정을 우선 사용하세요. ‘Clash’라는 표기만 확인해서는 안 됩니다.
최종 설정을 테스트합니다. 클라이언트가 구독과 파일, 인터페이스 설정을 병합하거나 덮어쓸 수 있습니다. 다운로드한 원본 YAML만 보지 말고 실제로 커널에 전달되는 설정을 확인하세요.
기본 연결을 확인합니다. 우선 TUN을 끄고 지정한 로컬 포트로 테스트하세요. 시스템 프록시, 앱 프록시, 커널 수신 포트가 서로 일치해야 합니다.
규칙 매칭을 확인합니다. 연결 기록에서 도메인, 매칭된 규칙, 아웃바운드 정책을 확인하세요. 정책 그룹을 잘못 선택한 문제를 커널 비호환으로 오인하지 않도록 합니다.
확장 기능을 하나씩 복구합니다. DNS 정책, 규칙 집합, 스니핑, TUN을 차례대로 켜고 항목을 추가할 때마다 같은 접속 테스트를 반복하세요.

예를 들어 로컬 혼합 포트가 7890이라면 아래 명령으로 HTTP 프록시를 명시해 시스템 프록시 설정에 영향을 받지 않고 테스트할 수 있습니다. 시스템에 curl이 설치되어 있어야 합니다.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com

예시에서는 연결 시간 제한을 10초로 설정합니다. 이는 대기 시간만 제한하며 실제 지연 시간을 나타내지는 않습니다. HTTP 응답을 받으면 요청이 로컬 프록시를 거쳤다는 뜻입니다. 원격 노드를 통과했는지는 커널 연결 기록에서 확인하세요. 앞서 소개한 기본 설정을 사용했다면 요청은 마지막에 DIRECT로 전달됩니다.

설치 전에는 클라이언트 선택 가이드를 확인하고, 필드를 점검할 때는 설정 참고 문서를 살펴보세요. 호환성은 항상 ‘실제 커널 → 설정 필드 → 실행 결과’ 순서로 판단해야 합니다. 클라이언트 이름부터 보고 결론을 내려서는 안 됩니다.