Clash 오리지널·Clash Meta·mihomo 코어 비교: 프로토콜 지원과 유지보수 현황

선택 기준: 먼저 코어를 확인하고, 클라이언트 이름은 그다음

새 설정에서 VLESS, Hysteria2, TUIC 또는 최신 규칙 기능이 필요하다면 요구 사항을 충족하는 mihomo 빌드를 사용하는지 먼저 확인하세요. 기존 Clash Premium 설정은 마이그레이션의 출발점으로 활용할 수 있지만, 유지보수가 중단된 구형 코어를 새 환경의 기본값으로 삼는 것은 권장하지 않습니다. Clash Meta와 mihomo는 서로 무관한 두 프로토콜 체계가 아니라 같은 프로젝트가 발전하면서 사용한 이름입니다.

Clash 애플판 사용자는 다운로드 페이지의 앱 이름만으로 그래픽 인터페이스의 종류를 알 수 있을 뿐, 내장 코어의 프로토콜 지원 여부까지 판단할 수는 없습니다. 클라이언트에 따라 코어를 바꿀 수 있거나 특정 버전이 고정 포함될 수 있고, 앱과 코어 업데이트가 별도로 제공되기도 합니다. 문제를 확인할 때는 클라이언트 버전, 코어 이름과 버전, macOS 또는 iOS 버전을 함께 기록하세요.

Clash·Premium·Meta·mihomo의 관계

Clash 오리지널: 오픈소스 코어와 기본 설정 체계

Clash 오리지널은 프록시 노드, 정책 그룹, 규칙, 로컬 프록시 포트를 포함한 널리 쓰이는 YAML 설정 구조를 정립했습니다. 많은 클라이언트가 이 구조를 이어받아 앱마다 proxies, proxy-groups, rules를 사용하기도 합니다. 원 프로젝트는 2023년에 기존 공개 유지보수를 중단했습니다. 예전 빌드는 계속 실행될 수 있지만, 새로운 프로토콜이나 시스템 변화에 맞춰 업데이트될 것으로 기대해서는 안 됩니다.

Clash Premium: 과거의 비공개 코어 브랜치이며 유료 구독이 아닙니다

Clash Premium은 원 프로젝트가 제공했던 비공개 코어 브랜치로, TUN과 규칙 집합 등의 확장 기능을 포함했습니다. 여기서 Premium은 코어 브랜치를 가리키며, 노드 서비스의 유료 요금제와는 무관합니다. 특정 구독을 구매한다고 Clash 오리지널에 새 프로토콜이 추가되는 것도 아닙니다. 이 역시 과거의 유지보수 체계에 속하므로, 클라이언트 화면이 여전히 실행된다는 이유만으로 코어까지 계속 관리된다고 판단해서는 안 됩니다.

Clash Meta에서 mihomo로: 계승과 확장

Clash Meta는 Clash를 기반으로 발전한 포크이며, 이후 mihomo로 이름이 바뀌었습니다. 오래된 튜토리얼, 구독 변환 옵션, 클라이언트 설정에는 여전히 Meta라는 표기가 남아 있을 수 있습니다. 'Meta 코어'라는 문구를 보더라도 이름만으로 호환성을 판단하지 말고 실제 버전을 확인하세요. 최신 mihomo 설정이 초기 Meta 빌드에서 실행된다고 보장할 수는 없습니다.

프로젝트 이름: 유지보수 주체와 참고할 문서를 확인합니다.
코어 버전: 사용할 수 있는 필드와 프로토콜 옵션, 수정 사항이 포함됐는지 확인합니다.
클라이언트 버전: 인터페이스, 보조 서비스, 설정 병합 방식을 확인합니다.
시스템 버전: 네트워크 권한, 샌드박스, 확장 기능의 제한을 확인합니다.

프로토콜 지원 차이: 노드 이름만으로 프로토콜을 알 수 없습니다

노드 이름은 임의로 지정할 수 있으며, 실제 파싱 방식을 결정하는 것은 YAML의 type과 관련 필드입니다. 예를 들어 '고속 회선'이라는 이름의 노드는 Trojan을 사용할 수도, Hysteria2를 사용할 수도 있습니다. 호환성을 확인하려면 구독의 실제 내용을 살펴보세요. 설정 일부를 다른 사람에게 공유하기 전에는 비밀번호, UUID, 서버 주소, 구독 토큰을 삭제해야 합니다.

확인 항목	Clash 오리지널	Clash Premium	mihomo
SS, VMess, Trojan 등 기본 프로토콜	일반적인 설정 지원	일반적인 설정 지원	지원함. 세부 옵션은 버전별로 확인
VLESS 및 REALITY 관련 설정	호환 대상으로 삼지 않는 것이 좋음	호환 대상으로 삼지 않는 것이 좋음	관련 설정 지원, 필드 확인 필요
Hysteria2、TUIC	이러한 최신 프로토콜은 지원하지 않음	완전한 지원을 전제로 해서는 안 됨	지원함. 프로토콜 버전과 매개변수가 일치해야 함
내장 TUN	오픈소스 원본 버전에는 없음	과거 구현 제공	제공함. 플랫폼과 권한에 따라 달라짐
유지보수 방향	과거 버전 호환 및 기존 설정 마이그레이션	과거 버전 호환 및 기존 설정 마이그레이션	프로젝트 릴리스 기록을 기준으로 지속 확인

이름이 같은 프로토콜도 매개변수가 다를 수 있음

특정 프로토콜을 지원한다고 해서 모든 전송 방식, 암호화 방법, 확장 옵션까지 지원하는 것은 아닙니다. VLESS 노드는 flow, TLS, REALITY, 전송 계층 설정이 관련될 수 있으며, TUIC의 프로토콜 버전도 서로 그대로 혼용할 수 없습니다. 로그에 unsupported proxy type이 표시되면 먼저 코어 유형을 확인하세요. 설정은 불러왔지만 핸드셰이크에 실패한다면 인증 정보, 시간, TLS 매개변수, 네트워크 연결 상태를 점검합니다.

구독 변환은 입력 내용을 대상 형식으로 바꿀 뿐, 코어에 프로토콜 구현을 추가하지는 않습니다. Hysteria2 노드를 'Clash'라는 이름의 YAML로 변환해도 Clash 오리지널에서 Hysteria2를 지원하게 되는 것은 아닙니다. 변환 대상을 선택할 때는 기존 Clash 호환 형식인지 mihomo 확장 형식인지 구분하세요.

규칙과 DNS: 문법이 비슷해도 실행 결과는 다를 수 있습니다

일반적인 DOMAIN, DOMAIN-SUFFIX, IP-CIDR와 마지막의 MATCH는 마이그레이션 후에도 비교적 쉽게 유지할 수 있습니다. 규칙은 순서대로 적용되며, 앞에서 일치한 규칙이 보통 트래픽의 출구를 결정합니다. 범위가 넓은 규칙을 앞쪽에 배치하면 뒤의 세부 규칙이 적용되지 않을 수 있습니다. 정책 그룹 이름은 규칙에서 참조하는 이름과 정확히 일치해야 하므로, 노드만 옮기고 그룹을 빠뜨리지 않도록 주의하세요.

규칙 집합과 확장 규칙은 항목별로 확인해야 합니다

외부 규칙 집합: rule-providers 형식과 출처, 업데이트 방식, RULE-SET 참조의 유효성을 확인하세요. Premium이나 mihomo의 전체 규칙 집합 기능이 모든 Clash 오리지널 빌드에서 지원된다고 가정하지 마세요.
지리 데이터: GEOSITE 등의 규칙은 코어 지원과 해당 데이터 파일이 필요합니다. 규칙 텍스트만 복사해도 데이터 리소스의 다운로드와 로드를 대신할 수는 없습니다.
프로세스 규칙: 시스템에서 프로세스 정보를 제공할 수 있는지에 따라 달라집니다. macOS에서의 동작을 iOS 네트워크 확장 환경에 그대로 적용할 수는 없습니다.
스크립트 정책: Premium에서 사용하던 과거 스크립트 문법을 mihomo와 일반적으로 호환되는 인터페이스로 간주해서는 안 됩니다. 마이그레이션할 때는 명확한 규칙과 정책 그룹으로 바꾸는 것이 좋습니다.

DNS 설정에 따라 규칙에서 확인할 수 있는 정보가 달라집니다

fake-ip와 redir-host는 서로 다른 DNS 작동 모드입니다. fake-ip는 주소를 매핑해 코어가 도메인과 연결을 연관 짓도록 돕고, redir-host는 조회된 주소를 반환합니다. 어떤 네트워크 환경에서나 서로 바꿔 쓸 수 있는 설정은 아닙니다. 마이그레이션 후 '노드 지연 시간은 측정되는데 웹페이지가 열리지 않는' 문제가 생기면 DNS 업스트림 연결, 도메인 분기 규칙, 시스템이 실제로 코어 DNS를 사용하는지 함께 확인하세요.

macOS와 iOS의 TUN 구현 차이

시스템 프록시와 TUN은 트래픽을 받는 위치가 다릅니다. 시스템 프록시는 프록시 설정을 따르는 앱에서 주로 사용됩니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 받아 시스템 프록시를 사용하지 않는 앱도 더 폭넓게 지원할 수 있지만, 모든 트래픽이 반드시 프록시 노드를 통과한다는 뜻은 아닙니다. 최종 출구는 라우팅, 제외 항목, 규칙, 직접 연결 정책에 따라 달라집니다.

macOS: 보조 서비스와 네트워크 확장은 다릅니다

macOS 클라이언트는 권한이 있는 보조 서비스로 TUN을 만들거나 Apple의 네트워크 확장 기능을 사용할 수 있습니다. 구현에 따라 권한 승인 절차가 다르므로 'TUN 활성화'가 언제나 '시스템 확장 승인 필요'를 뜻하지는 않습니다. macOS 13 이상에서는 먼저 '시스템 설정' → '네트워크'에서 VPN과 네트워크 서비스 상태를 확인하세요. 클라이언트에서 시스템 소프트웨어가 차단됐다고 명시적으로 알리면 안내에 따라 '시스템 설정' → '개인정보 보호 및 보안'에서 권한을 확인합니다.

mihomo TUN 설정에서 흔히 사용하는 항목은 auto-route, auto-detect-interface, dns-hijack입니다. 출구 인터페이스 자동 감지는 일반적인 단일 회선 환경에 적합하지만, 네트워크 인터페이스가 여러 개이거나 다른 VPN을 사용하거나 특수 라우팅이 적용된 환경에서는 실제 결과를 확인해야 합니다. macOS에 utun 인터페이스가 보인다고 해서 현재 클라이언트가 트래픽을 제대로 처리한다고 단정할 수 없습니다. 시스템이나 다른 VPN도 같은 종류의 인터페이스를 만들 수 있습니다.

iOS: 네트워크 확장과 앱 기능을 함께 확인해야 합니다

iPhone과 iPad는 보통 앱의 Network Extension 터널 확장으로 네트워크 기능을 실행하며, macOS용 실행 파일을 복사해 사용할 수는 없습니다. 처음 터널을 만들 때 VPN 구성을 추가하라는 확인이 표시되는 경우가 많습니다. 이후 '설정' → '일반' → 'VPN 및 기기 관리'에서 관련 항목을 확인할 수 있습니다. 앱에서 Clash 형식 설정을 불러올 수 있더라도, 실제로 지원하는 프로토콜과 필드는 해당 앱의 코어와 문서를 기준으로 확인해야 합니다.

따라서 '같은 YAML 파일을 Mac에서 불러올 수 있다'는 것은 Mac에서 파싱에 성공했다는 뜻일 뿐, iOS에서도 프로세스 규칙, 파일 경로, 백그라운드 업데이트 방식이 모두 같다는 의미는 아닙니다. 여러 기기에서 하나의 구독을 사용한다면 노드와 주요 분기 규칙은 통일하고, 플랫폼 권한과 파일 위치, 네트워크 트래픽 처리 설정은 기기별로 관리하세요.

mihomo로 마이그레이션: 최소 설정부터 단계적으로 복원

아래는 파싱, 포트 바인딩, 기본 규칙을 확인하기 위한 최소 설정입니다. 직접 연결 정책만 포함되어 있어 원격 노드의 연결 가능 여부를 테스트할 수는 없습니다. 예시에서는 HTTP와 SOCKS 혼합 포트를 7890으로 설정하고 로컬 루프백 주소에만 바인딩합니다. 이 포트 번호는 예시일 뿐 모든 클라이언트의 기본값은 아닙니다.

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
ipv6: false

proxy-groups:
  - name: DIRECT-TEST
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,DIRECT-TEST

먼저 문법을 확인하고 네트워크를 점검하세요

코어를 단독 실행할 때는 다음 명령으로 버전을 기록하고 설정을 테스트할 수 있습니다. 파일 경로는 현재 디렉터리를 기준으로 합니다. 그래픽 클라이언트를 사용하는 경우에는 클라이언트의 설정 검사 기능으로 최종 병합 결과를 확인하고, 포트를 놓고 충돌하지 않도록 코어를 두 개 동시에 실행하지 마세요.

./mihomo -v
./mihomo -t -f ./config.yaml
lsof -nP -iTCP:7890 -sTCP:LISTEN

-t 검사가 통과했다는 것은 설정 검사가 성공했다는 뜻일 뿐, 노드와 DNS, 규칙까지 검증됐다는 뜻은 아닙니다. 일부 검사 과정에서는 로컬 리소스를 읽거나 외부 데이터를 가져오기도 합니다. 실패하면 문법 오류, 리소스 누락, 네트워크 요청 실패를 구분해 확인하세요. 로그에 address already in use가 표시되면 먼저 다른 클라이언트가 7890 포트를 사용 중인지 확인하세요. 오류를 피하려고 로컬 네트워크 접근을 무작정 허용해서는 안 됩니다.

백업: 기존 설정, 코어 버전, 클라이언트 덮어쓰기 설정, 현재 선택한 정책 그룹을 저장하고 바로 복원할 수 있는 사본을 보관합니다.
기본 기능 확인: TUN을 끄고 최소 설정으로 파싱과 로컬 포트가 정상인지 확인한 다음, 작동이 검증된 노드 하나를 불러옵니다.
분기 설정 복원: 정책 그룹, 규칙, 규칙 집합, DNS를 차례로 추가합니다. 한 번에 한 종류만 변경하고 연결에 실제로 어떤 규칙이 적용됐는지 확인하세요.
마지막으로 TUN 활성화: 권한, 기본 출구, DNS 가로채기를 확인한 뒤 브라우저 이외의 앱에서도 테스트합니다.
롤백 확인: 새 클라이언트를 종료한 후 시스템 프록시와 터널이 꺼졌는지 확인하고 이전 버전을 복원합니다. 두 도구가 동시에 라우팅을 변경하지 않도록 주의하세요.

자주 묻는 질문: 오류 메시지로 호환성 문제 찾기

설정을 불러올 수 있는데 활성화하자마자 실패하는 이유는 무엇인가요?

일부 클라이언트는 가져오는 단계에서 YAML 구조만 검사하고, 활성화할 때 코어에 실제 파싱을 맡깁니다. 먼저 시작 로그에서 지원하지 않는 프로토콜, 잘못된 필드, 정책 그룹 누락, 수신 포트 충돌을 구분하세요. 서비스 제공업체에서 여러 구독 형식을 제공한다면 현재 코어에 맞는 형식을 선택하세요. 구독 주소의 이름을 반복해서 바꾸는 것은 해결책이 아닙니다.

기존 Clash Meta 설정을 mihomo에서 그대로 사용할 수 있나요?

일반적인 노드와 기본 규칙은 대체로 호환되지만, 모든 확장 필드와 실험 기능, 기본 동작까지 완전히 같다고 보장할 수는 없습니다. 먼저 설정 검사를 실행한 뒤 릴리스 노트에서 DNS, TUN, 프로토콜 매개변수 관련 변경 사항을 확인하세요. 오류가 없더라도 연결 로그에서 규칙 적용 결과와 실제 출구를 검증해야 합니다.

Apple 칩 Mac에서 노드 지연 시간이 높은데 아키텍처를 잘못 선택한 건가요?

지연 시간만으로 아키텍처가 잘못됐다고 판단해서는 안 됩니다. '응용 프로그램' → '유틸리티' → '활성 상태 보기'에서 관련 프로세스 종류를 확인하고 클라이언트와 코어가 어떻게 실행되는지 살펴볼 수 있습니다. 네트워크 지연은 노드 회선, DNS, 테스트 대상, 다른 VPN의 활성화 여부를 확인하는 편이 좋습니다. 앱에서 한 번 측정한 지연 시간은 웹페이지 전체 로딩 시간과도 다를 수 있습니다.

코어를 업그레이드한 뒤 바로 TUN을 켜야 하나요?

그럴 필요는 없습니다. 먼저 시스템 프록시로 노드와 규칙을 확인하면 권한, 라우팅, DNS 가로채기에서 비롯되는 변수를 줄일 수 있습니다. 대상 앱이 시스템 프록시를 사용하지 않거나 더 폭넓은 트래픽 처리가 꼭 필요할 때 TUN을 별도로 활성화하세요. 자세한 문제 해결 방법은 문제 해결 가이드에서 로그와 네트워크 계층을 기준으로 확인할 수 있습니다.

최종 선택은 세 가지를 기준으로 해야 합니다. 구독의 프로토콜을 파싱할 수 있는지, 필요한 규칙이 올바르게 실행되는지, 현재 Apple 기기에서 네트워크 트래픽을 안정적으로 처리하는지 확인하세요. 코어 이름은 기술 방향을 파악하는 데 도움이 되지만, 호환성은 정확한 버전과 재현 가능한 테스트 결과로 확인해야 합니다.