Clash 오리지널·Clash.Meta·mihomo 코어 차이와 설정 호환성

이름과 계보: 오리지널, Premium, Meta 브랜치

Clash 설정을 옮길 수 있는지 판단하려면 먼저 GUI 클라이언트와 프록시 코어를 구분해야 합니다. 클라이언트는 구독 관리, 트레이 메뉴, 권한 요청, 설정 생성을 담당하고, 코어는 포트 수신, DNS 해석, 규칙 매칭, 아웃바운드 연결을 처리합니다. 같은 이름의 클라이언트라도 탑재된 코어 버전은 다를 수 있습니다. YAML을 가져올 수 있다고 해서 코어가 모든 필드를 실행할 수 있는 것은 아닙니다.

‘Clash 오리지널, Clash.Meta, mihomo’라는 표현은 검색할 때 편리하지만 엄밀한 프로젝트 계보를 나타내지는 않습니다. Clash.Meta는 Clash에서 파생된 브랜치이며, mihomo는 이 브랜치가 이후 사용하게 된 프로젝트 이름입니다. Clash.Meta와 무관한 별개의 세 번째 구현이 아닙니다. Premium은 기존 Clash 계열의 강화 버전으로, Meta와 동일하게 볼 수 없습니다.

Clash 오리지널: Dreamacro/clash를 대표로 하는 오픈소스 코어입니다. 널리 쓰이는 YAML 설정 구조와 규칙 모드, 정책 그룹, 제어 인터페이스의 기반을 마련했습니다.
Clash Premium: 원 개발자가 제공한 비공개 강화 코어입니다. 과거 TUN, 규칙 세트, 스크립트 등의 기능을 제공했으며, 오픈소스 버전의 기능표만으로 Premium 기능을 추측해서는 안 됩니다.
Clash.Meta: MetaCubeX가 유지 관리하는 파생 브랜치로, 프로토콜, DNS, 규칙, 트래픽 가로채기 기능을 확장합니다.
mihomo: Meta 브랜치가 이어서 사용하게 된 이름입니다. 구형 구독 템플릿, 클라이언트 옵션, 튜토리얼에는 여전히 Meta라는 이름이 나올 수 있으므로 호환성은 실제 코어 버전을 기준으로 확인해야 합니다.

시간순으로 보면 기존 Clash와 Premium의 배포 채널은 2023년 말 큰 변화를 겪었습니다. Meta 브랜치는 계속 발전했고, 이후 2024년에 mihomo라는 이름을 사용하기 시작했습니다. 구형 설치 파일이 여전히 실행되더라도 이후 추가된 프로토콜과 설정 필드를 자동으로 지원하는 것은 아닙니다.

기능 비교: 프로토콜, 규칙, 설정 호환 범위

아래 내용은 각 코어의 지원 방향을 비교한 것으로, 모든 과거 버전이 항목별로 동일하게 지원한다는 뜻은 아닙니다. 특히 mihomo는 새 프로토콜과 필드를 릴리스마다 차례로 추가합니다. 구독 설정에 type이 있더라도 현재 사용하는 코어가 해당 유형과 관련 매개변수를 지원하는지 확인해야 합니다.

항목	Clash 오픈소스 원본	Clash Premium	Clash.Meta / mihomo
일반적인 기본 프로토콜	Shadowsocks, VMess, Trojan 등을 지원하며 세부 매개변수는 버전에 따라 다릅니다.	오리지널의 기본 프로토콜 지원을 이어갑니다.	기본 프로토콜을 유지하면서 구현 범위를 계속 확장합니다.
VLESS、REALITY、Hysteria2、TUIC	이러한 신규 프로토콜이나 기능은 지원 대상이 아닙니다.	Meta의 확장 프로토콜을 대체하는 구현으로 볼 수 없습니다.	해당 버전에서 지원합니다. 전송 계층과 인증 매개변수도 확인해야 합니다.
기본 라우팅 규칙	도메인, IP, GEOIP, MATCH 등 일반적인 규칙을 지원합니다.	기본 규칙과 향상된 기능을 지원합니다.	기본 규칙에 더해 논리 매칭 등의 기능을 확장합니다.
규칙 세트와 스크립트	Premium의 규칙 세트 및 스크립트 기능과 동일하게 볼 수 없습니다.	규칙 세트와 특정 스크립트 메커니즘을 지원합니다.	규칙 세트를 지원하지만 Premium 스크립트 실행 환경과 호환된다고 단정할 수 없습니다.
TUN	Premium에 내장된 TUN 기능은 제공하지 않습니다.	TUN을 제공하지만 운영체제와 릴리스 버전에 따라 제한이 있습니다.	TUN을 제공하며, 프로토콜 스택과 라우팅 옵션은 해당 버전의 문서를 확인해야 합니다.

프로토콜 이름이 같아도 매개변수까지 모두 동일한 것은 아닙니다.

예를 들어 VMess 노드에는 WebSocket, TLS, 서비스 이름 또는 요청 헤더 설정이 필요할 수 있습니다. VLESS는 REALITY와 특정 흐름 제어 매개변수를 사용할 수 있습니다. REALITY는 관련 연결을 위한 보안 핸드셰이크 기능이지, 원하는 대로 type에 입력할 수 있는 독립 노드 프로토콜이 아닙니다. 노드 유형만 바꾸고 맞지 않는 전송 매개변수를 그대로 두면 일부 설정은 파싱되더라도 핸드셰이크 단계에서 실패할 수 있습니다.

파싱 실패: 프로토콜 유형, 필드 철자, YAML 들여쓰기, 필드 데이터 유형부터 확인하세요.
핸드셰이크 실패: 서버 주소, 포트, 인증 정보, TLS 서비스 이름, 전송 방식, 서버 설정을 확인하세요.
연결 시간 초과: 네트워크 연결 상태, UDP 지원 여부, 상위 네트워크의 차단, 로컬 방화벽도 확인해야 합니다. 코어 이름만 원인으로 단정하지 마세요.

설정 호환성: 유지할 항목과 다시 작성할 항목

오리지널 설정을 mihomo로 옮길 때 proxies, proxy-groups, rules 같은 기본 구조는 대체로 이어서 사용할 수 있습니다. 하지만 필드가 남아 있다고 해서 기본값과 실행 결과까지 모두 같다는 뜻은 아닙니다. 프로토콜 매개변수, 규칙 데이터, DNS, TUN, 클라이언트 재정의를 각각 확인해야 합니다.

기본 규칙: 정책 이름과 실행 순서부터 확인

proxy-groups:
  - name: 아웃바운드 선택
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,아웃바운드 선택
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,아웃바운드 선택

이 설정은 구조를 확인하기 위한 것으로 원격 프록시 노드는 포함되어 있지 않습니다. ‘아웃바운드 선택’에는 현재 DIRECT만 있으므로 이 정책이 선택되면 직접 연결됩니다. 실제 설정으로 옮길 때는 검증된 노드 이름을 정책 그룹에 추가해야 합니다. 규칙에서 참조하는 이름은 정책 그룹 또는 노드 이름과 정확히 일치해야 합니다.

규칙은 일반적으로 위에서 아래 순서로 매칭되므로 MATCH는 마지막에 두어야 합니다. 예시의 no-resolve는 해당 IP 규칙을 위해 도메인 조회를 새로 시작하지 않는다는 뜻입니다. 모든 DNS를 끄거나 도메인 규칙을 무효화하는 옵션은 아닙니다. 연결에 사용할 수 있는 대상 IP가 아직 없다면 이 규칙이 매칭되지 않을 수 있습니다.

규칙 세트: 파일 확장자보다 데이터 형식이 중요

rule-providers를 옮길 때는 type, behavior, format, path, 업데이트 주소를 함께 확인하세요. behavior: domain, ipcidr, classical은 각각 서로 다른 콘텐츠 형식을 요구합니다. 전체 규칙이 들어 있는 classical 데이터를 도메인 목록처럼 사용하면 파일명이 모두 YAML이라고 해서 호환되는 것은 아닙니다.

마찬가지로 mihomo가 지원하는 규칙 세트를 구형 코어에 그대로 넣지 마세요. 예를 들어 바이너리 규칙 세트는 이를 처리할 수 있는 구현이 필요하며, 확장자만 바꿔서는 변환되지 않습니다. 원격 규칙 세트를 내려받았더라도 파싱 로그와 실제 규칙 매칭 여부를 확인해야 합니다.

DNS와 TUN: 비슷한 필드라도 트래픽 가로채기 범위는 다릅니다

시스템 프록시는 보통 시스템 프록시 설정을 따르는 앱에만 적용됩니다. TUN은 가상 네트워크 인터페이스와 라우팅 규칙을 이용해 조건에 맞는 IP 트래픽을 가로채므로 시스템 프록시 설정을 읽지 않는 프로그램에 유용합니다. 그렇다고 모든 트래픽이 반드시 원격 프록시를 거치는 것은 아닙니다. 트래픽을 가로챈 뒤에도 규칙 매칭을 거치며 DIRECT, 차단, 프록시 등 서로 다른 결과가 나올 수 있습니다.

가상 네트워크 인터페이스를 켜기 전에 DNS부터 확인

마이그레이션할 때는 먼저 TUN을 끄고 로컬 프록시 포트로 노드와 라우팅 규칙을 검증한 다음 DNS 가로채기와 라우팅 처리를 추가하는 것을 권장합니다. 이렇게 하면 ‘프록시 연결 실패’와 ‘시스템 DNS 요청이 코어에 전달되지 않음’을 구분할 수 있습니다. 다음은 mihomo 설정 예시입니다. 기존 설정에 합치고 최상위 dns 또는 tun을 중복 정의하지 마세요.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

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

127.0.0.1:1053은 로컬 DNS 수신 주소입니다. 이 주소에서 수신하도록 설정해도 모든 앱이 자동으로 해당 주소를 사용하는 것은 아닙니다.
198.18.0.1/16은 예시용 fake-ip 주소 풀입니다. 매핑에 사용할 가상 주소를 제공하며, 원격 프록시 서버 주소가 아닙니다.
enable: false는 먼저 TUN을 사용하지 않는 경로를 검증하기 위한 설정입니다. 권한과 라우팅을 준비한 뒤 true로 바꾸세요.
dns-hijack은 가로채기 조건에 맞는 DNS 트래픽을 처리합니다. 앱이 직접 연결하는 모든 DoH 또는 DoT를 일반적인 53번 포트 DNS 요청처럼 취급해서는 안 됩니다.

운영체제별 차이: 권한과 라우팅을 함께 확인

Windows에서는 보통 클라이언트 서비스 모드나 적절한 권한 상승이 필요합니다. macOS에서는 권한이 필요한 보조 프로그램이나 앱별 네트워크 가로채기 기능을 사용할 수 있습니다. Linux에서는 TUN 장치와 네트워크 관리 권한을 확인해야 합니다. Android 클라이언트는 시스템 VPN 인터페이스로 트래픽을 가로채는 경우가 많아, GUI 설정이 데스크톱용 원본 YAML과 일대일로 대응하지 않을 수 있습니다.

다른 VPN, 가상 머신 네트워크, 기업 보안 소프트웨어를 함께 실행하면 기본 경로와 DNS 설정이 서로 덮어쓸 수 있습니다. TUN을 끄자 연결이 복구되더라도 문제 지점이 트래픽 가로채기 경로라는 뜻일 뿐, 특정 프로토콜의 비호환성을 바로 입증하는 것은 아닙니다. 기본 게이트웨이, DNS 주소, 경로 변경, 로그 시간을 기록한 뒤 하나씩 원인을 확인하세요.

마이그레이션 검증: 설정 검사, 포트 테스트, 롤백

안정적으로 옮기려면 재현 가능한 순서로 진행해야 합니다. 코어 업그레이드, 구독 교체, DNS 변경, TUN 활성화를 한꺼번에 하지 마세요. 문제가 생겼을 때 원인을 찾기 어려워집니다. 기존 설정을 별도로 보관하고 새 클라이언트에서는 독립된 설정으로 검증하세요.

기준 상태 기록: 현재 작동하는 노드, 정책 선택, DNS 모드, 수신 포트를 저장하고 시스템 프록시와 TUN 사용 여부를 기록합니다.
대상 코어 확인: mihomo인지 구형 Meta 바이너리인지 확인하고 실제 버전을 살펴보세요. 구독 템플릿 제목만으로 판단하지 마세요.
설정 검사: 먼저 설정을 테스트한 다음 수신을 시작하세요. 테스트를 통과해 설정을 불러올 수 있더라도 노드 핸드셰이크와 규칙 업데이트까지 성공했다는 뜻은 아닙니다.
단일 연결 검증: 노드 하나를 고정하고 동일한 대상 주소로 직접 연결과 명시적 프록시 연결을 비교하세요. 자동 속도 측정 그룹은 사용하지 마세요.
부가 기능 복원: 규칙 세트, DNS, TUN, 시작 시 자동 실행을 차례로 복원하고 각 단계마다 로그와 연결 기록을 확인하세요.

mihomo -v
mihomo -t -f config.yaml

클라이언트의 혼합 포트가 7890이라면 다음 명령으로 명시적 프록시 경로와 직접 연결 경로를 비교할 수 있습니다. 실제 포트는 실행 중인 설정을 기준으로 확인하세요. 7890은 흔히 쓰이는 예시일 뿐 모든 클라이언트의 고정 기본값은 아닙니다.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://clashgrand.com/
curl --noproxy "*" --connect-timeout 10 --max-time 20 -I https://clashgrand.com/

두 명령은 속도 측정이 아니며 상태 코드만으로 출구를 판단할 수도 없습니다. 클라이언트 연결 기록을 함께 보고 대상 연결에 어떤 규칙이 적용됐는지, 어떤 정책과 최종 노드를 사용했는지 확인해야 합니다. 정책 그룹이 여전히 DIRECT를 선택하고 있다면 로컬 프록시 포트에 명시적으로 연결하더라도 대상에 직접 접속할 수 있습니다.

자주 발생하는 문제와 우선 확인 항목

증상	우선 확인할 항목	해결 방향
알 수 없는 프록시 유형 또는 필드 오류	실제 코어, 구독 대상 형식, 매개변수 데이터 유형	mihomo용 설정을 선택하거나 해당 필드를 지원하는 버전으로 업그레이드
포트 바인딩 실패	구형 클라이언트가 7890 또는 로컬 DNS 포트를 계속 사용 중인지 확인	구형 프로세스를 종료하거나 포트를 변경하고 앱 설정도 함께 업데이트
구독 노드는 표시되지만 연결되지 않음	클라이언트가 최종 생성한 노드 매개변수와 핸드셰이크 로그	모드를 계속 바꾸기보다 전송 매개변수, 인증 정보, 서버 프로토콜을 확인
설정을 직접 수정해도 재시작 후 사라짐	구독 업데이트, 설정 병합, 클라이언트 재정의	임시 실행 파일만 수정하지 말고 저장되는 재정의 또는 병합 설정을 수정
TUN을 켠 뒤 로컬 네트워크에 문제가 생김	내부 네트워크 라우팅, DNS, 다른 VPN, 트래픽 가로채기 범위	먼저 TUN을 끄고 확인한 다음 적절한 라우팅 예외를 설정

롤백할 때는 새 클라이언트의 시스템 프록시와 TUN을 먼저 끄고 새 프로세스를 종료한 뒤 구형 클라이언트와 기존 설정을 복원하세요. 두 코어가 동시에 수신 포트와 시스템 라우팅을 점유하지 않도록 해야 합니다. 제어 인터페이스도 우선 루프백 주소에 바인딩하세요. 원격 관리가 꼭 필요하다면 인증과 접근 범위를 별도로 설정해야 합니다.

코어 선택 결론: 설정 의존성을 기준으로 선택

기본 노드와 일반적인 라우팅 규칙만 사용: 대체로 간단하게 옮길 수 있습니다. 정책 이름, DNS 동작, 클라이언트 재정의를 중점적으로 확인하세요.
VLESS, REALITY, Hysteria2 또는 TUIC 사용: 해당 매개변수를 지원하는 mihomo 버전을 명확히 선택하고 서버 설정과 항목별로 맞추세요.
Premium 스크립트에 의존: 동작을 먼저 재작성하고 검증하세요. 바이너리만 바꾸면 마이그레이션이 끝난다고 볼 수 없습니다.
TUN 필요: 클라이언트의 권한 관리, 운영체제 지원, 라우팅 충돌까지 함께 평가해야 합니다. 코어 기능 이름만 비교해서는 안 됩니다.

새로 구성할 때는 유지 관리가 계속되고 코어 정보를 명확히 표시하는 클라이언트를 우선 선택한 뒤, 실제 구독 프로토콜에 맞춰 설정 형식을 결정하세요. 기존 환경에서는 재현 가능한 테스트와 롤백 절차부터 마련해야 합니다. 코어 선택의 핵심은 이름이 새것인지가 아니라 노드 핸드셰이크, 규칙 매칭, DNS 해석이 정상적으로 작동하고 트래픽 가로채기 범위가 기대에 맞는지입니다.