Clash 커널 버전 비교: 오리지널 Premium, Clash Meta, mihomo의 차이

먼저 이름부터 정리하기: 세 가지 버전이 나란히 개발된 것은 아닙니다

Clash 클라이언트는 보통 그래픽 인터페이스, 커널, 설정 파일로 구성됩니다. 그래픽 인터페이스는 구독 가져오기, 노드 전환, 로그 표시를 담당하고, 커널은 프록시 연결 수립, 규칙 해석, DNS 정책 실행, 트래픽 가로채기를 처리합니다. 클라이언트 이름이 같아도 사용하는 커널은 다를 수 있습니다. 기능 범위를 판단할 때는 앱 이름만 보지 말고 커널 이름과 버전을 먼저 확인해야 합니다.

오리지널 Clash는 Dreamacro가 공개한 오픈 소스 코어로, HTTP·SOCKS·혼합 프록시 포트·프록시 그룹·기본 규칙 매칭 등을 제공합니다. Clash Premium은 원작자가 이를 바탕으로 배포한 강화 빌드로, TUN·규칙 집합·스크립트·보다 완전한 트래픽 가로채기 기능을 추가했습니다. 2023년 원 프로젝트 저장소의 유지보수가 중단된 뒤로는 오리지널과 Premium 모두 지속 업데이트를 위한 기준으로 사용하기 어렵습니다.

Clash Meta는 커뮤니티가 Clash에서 포크한 확장 커널입니다. Clash 설정 구조를 이어받으면서 프로토콜·규칙·DNS·TUN·프록시 그룹 기능을 확장했습니다. 이후 프로젝트의 공식 명칭이 mihomo로 변경되었으므로 Clash Meta와 mihomo는 완전히 별개의 새 커널이라기보다 이전 이름과 현재 이름의 관계에 가깝습니다. 구형 클라이언트 화면에는 여전히 Meta로 표시될 수 있지만, 최신 버전·문서·프로세스 이름에서는 mihomo를 더 많이 사용합니다.

이름과 유지보수 관계

이름	분류	현재 선택 시 의미
오리지널 Clash	초기 오픈 소스 기반 커널	기존 설정을 읽고 기본 문법을 이해하는 데 적합하지만, 새로 구축할 때는 권장하지 않음
Clash Premium	원작자가 배포한 강화 빌드	구형 데스크톱 클라이언트에서 흔히 사용되며 기존 설정 호환성이 핵심
Clash Meta	커뮤니티 확장 브랜치의 이전 명칭	대부분의 기능이 mihomo로 이어짐
mihomo	Clash Meta가 이름을 바꾼 뒤 계속 유지보수되는 프로젝트	새 프로토콜·확장 규칙·완전한 TUN 기능이 필요한 기기에 적합

프로토콜 지원 차이: 먼저 구독 노드의 전송 방식을 확인하세요

커널이 구독을 읽을 수 있다고 해서 구독에 포함된 모든 노드에 연결할 수 있는 것은 아닙니다. 구독 변환 결과는 보통 proxies 배열이며, 각 노드에는 type·서버 주소·포트·인증 필드가 포함됩니다. 지원되지 않는 유형을 만나면 커널이 로드 단계에서 바로 오류를 내거나 해당 노드를 건너뛸 수 있습니다. 그 결과 구독 업데이트는 완료됐지만 노드 수가 줄어든 것처럼 보일 수 있습니다.

오리지널과 Premium의 기본 지원 범위

오리지널 Clash는 당시 널리 쓰이던 Shadowsocks·VMess·Trojan·Snell·SOCKS5·HTTP 등을 주로 지원했습니다. Premium의 핵심 강점은 모든 최신 프록시 프로토콜을 지원하는 데 있다기보다 TUN·규칙 집합·실행 기능 강화에 있습니다. 새 필드가 포함된 구독을 구형 Premium 클라이언트에 넣으면 unsupported proxy type 또는 필드 해석 오류가 발생할 수 있습니다.

mihomo의 확장 지원 범위

mihomo는 일반적인 Clash 노드 구조와의 호환성을 유지하면서 VLESS·Reality·Hysteria 2·TUIC·WireGuard·ShadowTLS 등의 유형과 전송 조합을 계속 추가해 왔습니다. 구체적인 필드는 커널 버전에 따라 달라집니다. 예를 들어 VLESS Reality에는 보통 servername·reality-opts·공개 키·짧은 식별자가 필요하고, Hysteria 2에는 서버 포트·인증 정보·TLS 서버 이름이 필요한 경우가 많습니다. 구형 커널이 해당 필드를 인식하지 못한다면 노드 이름만 바꿔서는 해결되지 않습니다.

구독이 Shadowsocks·VMess·Trojan 위주라면 세 커널의 기본 연결 능력은 상당 부분 겹칩니다.
구독에 VLESS Reality·Hysteria 2·TUIC이 포함되어 있다면 클라이언트에 mihomo가 내장되어 있는지 바로 확인해야 합니다.
WireGuard 노드를 사용할 때는 ‘프록시 노드 유형’과 시스템에서 별도로 실행되는 WireGuard 앱을 구분해야 합니다. 설정 진입점이 서로 다릅니다.
노드 지원 여부는 클라이언트의 래핑 방식에도 영향을 받습니다. 커널이 기능을 지원하더라도 그래픽 인터페이스에 필드 편집 메뉴가 없다면 YAML 설정을 직접 사용해야 합니다.

규칙 기능 차이: 기본 문법은 호환되지만 확장 필드는 상호 호환되지 않습니다

세 커널 모두 Clash의 위에서 아래로 규칙을 평가하고, 처음 일치한 규칙에서 중단하는 모델을 따릅니다. 일반적으로 사용하는 DOMAIN·DOMAIN-SUFFIX·DOMAIN-KEYWORD·IP-CIDR·GEOIP와 마지막 기본 규칙은 호환성이 높습니다. 실제 차이는 규칙 집합, 프로세스 매칭, 인바운드 조건, 지리 데이터 로딩 방식에서 나타납니다.

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - DOMAIN-KEYWORD,video,Media
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Final

이 설정은 일반적인 원칙을 보여 줍니다. IP 해석이 필요한 규칙보다 도메인 규칙을 앞에 배치하고, 로컬 네트워크 주소는 직접 연결합니다. no-resolve는 IP-CIDR 규칙이 DNS 조회를 능동적으로 시작하지 않도록 하며, 마지막에는 MATCH로 일치하지 않은 연결을 처리합니다. 일부 구형 설정은 FINAL을 사용하므로, 마이그레이션할 때는 대상 커널 문서에서 지원하는 문법으로 통일해야 합니다.

RULE-SET과 규칙 제공자

Premium은 규칙 집합 기능으로 지나치게 긴 규칙 목록을 관리하는 문제를 해결했습니다. Meta와 mihomo에서는 rule-providers가 더욱 널리 사용되며, 로컬 파일이나 원격 주소에서 domain·ipcidr·classical 등의 동작 유형을 불러올 수 있습니다. 설정할 때는 규칙 파일 내용뿐 아니라 behavior와 콘텐츠 형식이 일치하는지도 확인해야 합니다. 도메인 목록을 ipcidr로 선언해도 커널이 자동으로 추측해 수정하지는 않습니다.

rule-providers:
  private-domain:
    type: file
    behavior: domain
    path: ./rules/private-domain.yaml

rules:
  - RULE-SET,private-domain,DIRECT
  - MATCH,Final

원격 규칙 제공자에는 url·interval·캐시 경로가 포함될 수도 있습니다. 업데이트 간격은 보통 초 단위이며, 예를 들어 86400은 24시간을 뜻합니다. 규칙 파일은 자주 업데이트할수록 좋은 것이 아닙니다. 공개 지리 목록은 하루 한 번 내려받아도 대체로 충분하며, 지나치게 잦은 업데이트는 시작 시간과 네트워크 요청 부담만 늘립니다.

프로세스 및 인바운드 매칭

mihomo는 PROCESS-NAME·PROCESS-PATH·NETWORK·IN-PORT·SRC-IP-CIDR와 논리 조합 규칙 등 더 다양한 조건을 지원합니다. 프로세스 매칭은 운영체제 권한과 구현 방식에 따라 달라지며 Android·Windows·macOS에서 사용할 수 있는 범위가 완전히 같지 않습니다. 모바일 운영체제의 제한이 큰 경우에는 도메인 및 IP 규칙을 사용하는 편이 일반적으로 더 안정적입니다.

GEOSITE와 GEOIP: 이름은 비슷하지만 매칭 대상은 다릅니다

GEOIP는 대상 IP가 속한 지역을 기준으로 매칭합니다. 연결 대상이 도메인만 포함하는 경우에는 지역을 판단하기 위해 커널이 먼저 IP를 조회해야 할 수 있습니다. 반면 GEOSITE는 검색 서비스·스트리밍 서비스·특정 지역 도메인 모음처럼 미리 정리된 도메인 분류 데이터를 기준으로 매칭합니다. 실시간으로 웹사이트 소유 지역을 조회하거나 웹페이지 내용을 분석하는 기능은 아닙니다.

오리지널 Clash는 비교적 이른 시기부터 GEOIP 같은 기본 지리 매칭을 지원했습니다. Premium과 이후 분기 프로젝트는 사용할 수 있는 데이터와 규칙 형식을 확장했습니다. mihomo는 GeoIP·GeoSite 및 여러 형식의 데이터 파일과 함께 사용할 수 있지만, 파일 형식·다운로드 경로·설정 항목은 반드시 해당 버전에 맞아야 합니다. 규칙 행만 있고 데이터 파일이 없으면 시작 로그에 리소스 읽기 실패가 표시되는 경우가 많습니다.

rules:
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Final

위 예시는 먼저 도메인 분류로 광고 목록을 처리하고, 중국 본토에서 자주 사용하는 도메인은 직접 연결한 뒤, GEOIP로 이미 IP가 확인된 연결을 보완합니다. 순서를 임의로 바꾸면 안 됩니다. 넓은 범위의 GEOSITE,cn,DIRECT를 프록시가 필요한 특정 도메인 규칙보다 앞에 두면 해당 구체적인 규칙은 영원히 매칭되지 않을 수 있습니다.

지리 데이터 점검 시 자주 확인할 항목

클라이언트의 ‘설정’ → ‘커널’ 또는 ‘정보’에서 실제로 실행 중인 것이 Premium·Meta·mihomo 중 무엇인지 확인합니다.
설정 디렉터리를 열어 GeoIP와 GeoSite 데이터 파일이 존재하는지 확인하고 수정 시간이 적절한지도 살펴봅니다.
‘설정’ → ‘로그’에서 geo·rule·provider를 검색해 파일이 로드되었는지 확인합니다.
대상 도메인을 더 구체적인 DOMAIN 또는 DOMAIN-SUFFIX 규칙에 넣어 테스트하고, 지리 분류 자체의 오차를 배제합니다.
클라이언트가 커널을 업데이트한 뒤 지리 데이터도 함께 업데이트했는지 확인합니다. 두 항목은 서로 다른 메뉴에서 관리되는 경우가 많습니다.

TUN 모드 차이: 가로채기 범위는 커널·권한·시스템 라우팅에 따라 달라집니다

시스템 프록시는 HTTP 또는 SOCKS 프록시 설정을 따르는 앱에만 영향을 줍니다. 게임·명령줄 프로그램·일부 스토어 앱·자체 네트워크 스택을 사용하는 소프트웨어는 시스템 프록시를 우회할 수 있습니다. TUN 모드는 가상 네트워크 인터페이스를 통해 더 많은 TCP 및 UDP 트래픽을 가로채므로, 데스크톱과 모바일 기기에서 통합적인 규칙 분기에 자주 사용됩니다.

오리지널 기본 코어는 주로 프록시 포트를 중심으로 동작합니다. Premium은 TUN을 중요한 강화 기능으로 추가했습니다. mihomo는 TUN 설정을 이어받아 확장했으며, 대표적인 필드로 enable·stack·auto-route·auto-detect-interface·strict-route·dns-hijack가 있습니다. 지원 값은 버전에 따라 달라질 수 있으므로 구형 설정을 옮길 때는 현재 커널이 출력하는 오류를 기준으로 판단해야 합니다.

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

auto-route는 필요한 라우팅을 자동으로 추가하고, auto-detect-interface는 현재 출구 네트워크 인터페이스를 식별하려고 시도합니다. strict-route는 트래픽 우회를 줄이며, dns-hijack는 지정된 DNS 요청을 커널이 처리하도록 합니다. 예시의 any:53은 목적지 포트가 53인 DNS 트래픽을 가로챈다는 뜻이지만, 현재 시스템에 적합한지는 로컬 DNS·LAN 기기·다른 VPN 앱을 함께 고려해야 합니다.

일반적인 TUN 스택 선택 방법

system: 운영체제 네트워크 스택에 더 의존하며 일반적으로 성능 손실이 적어 데스크톱 시스템에서 먼저 테스트하기 좋습니다.
gVisor: 사용자 공간 네트워크 스택으로 일부 연결을 처리합니다. 호환성이 다를 수 있으므로 특정 UDP 또는 앱 문제가 발생했을 때 비교 테스트에 사용할 수 있습니다.
mixed: 트래픽 유형에 따라 조합해 처리합니다. 지원 여부와 구체적인 동작은 mihomo 버전에 따라 다르므로 구형 설정을 옮긴 뒤 시작 로그를 확인해야 합니다.

TUN을 켠 뒤 인터넷에 연결되지 않는다고 해서 커널 자체를 사용할 수 없는 것은 아닙니다. 먼저 TUN을 끄고 일반 시스템 프록시로 연결되는지 확인한 다음 관리자 권한·가상 네트워크 인터페이스·기본 라우팅·DNS를 점검하세요. Windows에서는 다른 VPN 가상 인터페이스와의 충돌, macOS에서는 시스템 확장 또는 VPN 권한, Android에서는 활성 VPN 서비스가 하나만 남아 있는지를 중점적으로 확인해야 합니다.

DNS 동작 차이: Fake-IP 설정은 규칙 및 TUN과 함께 확인하세요

Clash 계열 커널에서 흔히 사용하는 DNS 강화 모드로는 fake-ip와 redir-host가 있습니다. Fake-IP는 먼저 앱에 예약 주소를 반환한 뒤 연결 단계에서 원래 도메인을 복원하므로, 도메인 규칙이 더 일찍 매칭에 참여할 수 있습니다. 일부 환경에서는 반복 조회를 줄일 수 있지만, 실제 LAN 주소에 의존하는 기기 검색·프린터·게임 플랫폼·사내 네트워크 도메인에 영향을 줄 수도 있습니다.

mihomo는 Fake-IP 필터·DNS 분기·폴백 조회·nameserver-policy 등을 더 다양한 방식으로 조합할 수 있습니다. 설정이 복잡할수록 각 DNS 그룹의 용도를 명확히 해야 합니다. 모든 도메인을 여러 업스트림에 동시에 맡긴다고 반드시 빨라지는 것은 아니며, 결과가 서로 달라질 수도 있습니다. 가정용 네트워크에서는 우선 주요 리졸버 한 그룹, 직접 연결 규칙 한 그룹, 필요한 Fake-IP 필터부터 구성하는 것이 좋습니다.

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

예시는 커널 DNS를 1053 포트에서 수신하도록 설정하고, 198.18.0.1/16을 Fake-IP 주소 대역으로 사용합니다. 이 주소 대역을 노드 서버의 실제 주소로 보면 안 됩니다. 로그에 198.18.x.x로 연결하는 항목이 보이면 도메인 매핑과 함께 판단해야 하며, 곧바로 잘못된 대상이라고 단정하지 마세요.

설정 호환성: 시작되는 것은 첫 단계일 뿐입니다

Clash Meta와 mihomo는 Clash YAML 구조를 최대한 이어가지만 호환성이 양방향인 것은 아닙니다. 기본 Clash 설정은 mihomo가 읽기 쉬운 편이지만, mihomo의 새 프로토콜·새 규칙 유형·확장 DNS 필드를 사용하는 설정은 오리지널 또는 Premium에 그대로 넘길 수 없습니다. 클라이언트가 저장 과정에서 설정을 다시 작성할 수도 있으므로, 직접 수정하기 전에 ‘구독이 생성한 설정’과 ‘로컬 오버라이드 설정’을 구분해야 합니다.

Premium에서 mihomo로 옮길 때 확인할 목록

기존 클라이언트의 혼합 포트·LAN 접근 설정·작동 모드·현재 선택된 프록시 그룹을 기록합니다.
원본 YAML 사본을 보관한 뒤 새 클라이언트에 구독을 가져오세요. 유일한 설정 파일을 바로 덮어쓰지 마세요.
먼저 TUN을 끄고 7890 같은 로컬 프록시 포트가 정상적으로 연결되는지만 테스트합니다.
로그에 사용 중단된 필드·중복 키·규칙 집합 로드 실패·프록시 유형 오류가 있는지 확인합니다.
DIRECT·REJECT·노드 선택 그룹·자동 속도 측정 그룹을 하나씩 테스트해 규칙 동작이 예상과 일치하는지 확인합니다.
마지막으로 TUN과 DNS 가로채기를 켜고 브라우저·명령줄·게임·LAN 기기를 각각 테스트합니다.

자동 속도 측정 그룹도 사용감에 차이를 만들 수 있습니다. 일반적인 url-test는 지정 URL에 주기적으로 접속해 연결 시간을 기준으로 노드를 선택합니다. 테스트 간격을 300으로 설정하면 5분마다 확인합니다. 지연 시간이 가장 짧다고 다운로드 속도가 가장 빠른 것은 아닙니다. 테스트는 보통 DNS·TCP·TLS 또는 짧은 HTTP 요청만 포함하므로 장시간 연결의 대역폭이나 혼잡 시간대의 품질을 대변하지 못합니다.

proxy-groups:
  - name: Auto
    type: url-test
    proxies:
      - Node-A
      - Node-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

tolerance: 50은 후보 노드의 지연 시간 차이가 작을 때 잦은 전환을 줄인다는 뜻입니다. 회의·다운로드·연속 재생에서는 매번 테스트 후 몇 ms를 쫓기보다 안정적인 연결이 더 중요합니다. 커널을 바꾼 뒤 노드 전환이 눈에 띄게 늘었다면 규칙만 조정하지 말고 테스트 URL·간격·허용 오차를 확인하세요.

플랫폼별 커널 선택 방법

Windows와 macOS

새로 설치할 때는 mihomo 사용 여부를 명확히 표시하고, 커널 버전을 보여 주며 로그 메뉴를 제공하는 클라이언트를 우선 선택하세요. 데스크톱 시스템에서는 TUN·프로세스 규칙·규칙 제공자가 필요한 경우가 많아 mihomo의 지원 범위가 더 넓습니다. 설치 후 ‘설정’ → ‘커널 버전’, ‘설정’ → ‘구독’, ‘로그’를 차례로 확인해 화면에 표시된 버전과 실제 커널이 별도로 업데이트되는 상태가 아닌지 점검하세요.

구형 클라이언트가 아직 Premium을 사용하고 구독도 기본 프로토콜만 제공한다면 단기간에는 계속 작동할 수 있습니다. 그러나 운영체제 업데이트·지리 데이터 만료·새 노드 유형 추가가 발생하면 문제 해결 비용이 점차 커집니다. 마이그레이션 전에 규칙과 포트 설정을 보존하고 mihomo 클라이언트에서 하나씩 복원하는 편이 구형 커널에 새 프로토콜을 억지로 추가하는 것보다 일반적으로 간단합니다.

Android

Android 클라이언트는 시스템 VPN 인터페이스를 통해 트래픽을 가로채므로, 데스크톱의 시스템 프록시 설정보다 앱 자체에 mihomo가 통합되어 있는지가 더 중요합니다. 선택할 때는 커널 설명·앱별 프록시·IPv6·UDP·백그라운드 실행 정책을 확인하세요. 시스템에서는 주 VPN 서비스를 하나만 동시에 실행할 수 있으므로 Clash 계열 클라이언트와 다른 VPN 또는 DNS 필터 앱이 동시에 트래픽을 가로채지 못하는 경우가 많습니다.

iPhone과 iPad

iOS에서는 보통 mihomo라는 독립 커널 프로그램을 직접 설치하지 않고, Clash 설정 또는 유사한 규칙 체계를 지원하는 네트워크 도구를 사용합니다. 앱마다 구현이 다를 수 있으므로 설정 파일 확장자만 보고 전체 호환성을 추정해서는 안 됩니다. 가져오기 전에 앱 설명에서 지원하는 프로토콜·규칙 유형·TUN 동작을 확인하세요. 특히 VLESS Reality·Hysteria 2·복잡한 rule-providers는 주의가 필요합니다.

라우터·NAS 및 명령줄 환경

라우터와 NAS에서는 CPU 아키텍처·메모리 사용량·시작 방식·방화벽 통합이 더 중요합니다. 커널을 다운로드할 때 amd64·arm64 등 실제 아키텍처에 맞춰야 합니다. 명령줄에서 실행한 뒤에는 버전 명령이나 컨트롤 인터페이스로 커널 종류를 확인하고, 7890·9090·1053 등의 포트가 기존 서비스와 충돌하지 않는지도 점검하세요. 메모리가 적은 기기에서는 규칙 제공자 수와 업데이트 빈도를 제한해야 합니다.

사용 시나리오	권장 선택	우선 확인할 항목
새로 설치하는 데스크톱 클라이언트	mihomo	TUN 권한·커널 버전·구독 프로토콜
기존 설정 계속 유지	먼저 Premium 호환성을 확인한 뒤 마이그레이션을 계획	규칙 집합·스크립트·구형 필드
Android 앱별 프록시	mihomo가 통합된 클라이언트	VPN 권한·백그라운드 제한·UDP
iOS 설정 가져오기	앱의 실제 호환 범위에 따라 선택	프로토콜·규칙 제공자·시스템 VPN 제한
라우터 및 NAS	아키텍처에 맞는 mihomo	아키텍처·메모리·라우팅·포트 충돌

최종 판단: 이름의 신구가 아니라 필요한 기능으로 선택하세요

오리지널 Clash는 설정·프록시 그룹·규칙 체계의 기반을 마련했고, Premium은 당시 중요한 TUN과 고급 규칙 기능을 보완했습니다. Clash Meta는 커뮤니티 개발을 이어받아 mihomo라는 이름으로 계속 유지보수되고 있습니다. 일반 사용자라면 Meta와 mihomo를 서로 배타적인 두 기술로 볼 필요가 없습니다. 핵심은 클라이언트에 내장된 실제 버전과 설정 호환 범위입니다.

기본 Shadowsocks·VMess·Trojan 노드만 사용하고 시스템 프록시에 의존한다면 구형 커널과 mihomo의 체감 차이가 작을 수 있습니다. VLESS Reality·Hysteria 2·TUIC·완전한 규칙 제공자·GEOSITE·프로세스 규칙·세밀한 TUN 및 DNS 제어가 필요하다면 mihomo를 현재 기준으로 삼는 편이 적합합니다.

커널을 정한 뒤 ‘일반 프록시 연결 → 기본 규칙 → DNS → TUN → 확장 규칙’ 순서로 확인하세요. 기능을 한 단계 추가할 때마다 로그를 확인하고 포트·모드·테스트 결과를 기록합니다. 이렇게 하면 클라이언트가 업데이트되거나 구독 구조가 바뀌어도 문제가 노드·규칙·DNS·시스템 라우팅 중 어디에 있는지 빠르게 파악할 수 있습니다.