mihomo 코어와 오리지널 Clash 비교: 규칙 문법, DNS, TUN 신기능
mihomo(Clash Meta) 코어와 오리지널 코어의 핵심 차이를 비교합니다: 새로 지원하는 프로토콜, 규칙셋과 GeoSite 활용법, DNS 분산 전략, TUN 모드 구현 방식을 살펴보고, 기존 설정을 이전할 때 챙겨야 할 호환성 포인트도 함께 설명합니다.
mihomo(Clash Meta) 코어와 오리지널 코어의 핵심 차이를 비교합니다: 새로 지원하는 프로토콜, 규칙셋과 GeoSite 활용법, DNS 분산 전략, TUN 모드 구현 방식을 살펴보고, 기존 설정을 이전할 때 챙겨야 할 호환성 포인트도 함께 설명합니다.
Clash 프로젝트의 초기 코어 저장소는 원작자가 유지보수했으며, 프로토콜 지원과 규칙 문법이 비교적 보수적이어서 안정적이지만 기능이 제한된 버전에 오랫동안 머물러 있었습니다. 커뮤니티는 이를 기반으로 Clash Meta 브랜치를 만들어 새로운 프로토콜, 새로운 규칙 유형, 더 완성도 높은 DNS/TUN 구현을 계속 추가했고, 이후 독립적으로 mihomo로 이름을 바꾸며 사실상 커뮤니티의 주류 버전이 되었습니다. 현재 대부분의 클라이언트(본 사이트에 수록된 Windows, macOS, Android 버전 대다수 포함)는 이미 mihomo를 기본 또는 선택 가능한 코어로 채택했으며, 오리지널 코어의 업데이트 빈도는 눈에 띄게 줄었습니다.
두 코어의 차이를 이해하면 '특정 규칙이 적용되지 않는 이유', '특정 프로토콜에 연결되지 않는 이유', '설정 파일을 새 클라이언트로 옮기면 오류가 나는 이유' 같은 문제를 판단할 때 큰 도움이 됩니다 — 대부분의 근본 원인은 설정 파일 자체의 오류가 아니라 코어 차이에 있습니다.
오리지널 코어가 지원하는 프로토콜 집합은 기본적으로 Shadowsocks, ShadowsocksR, VMess, Trojan, Snell 등 초기 주류 프로토콜에 고정되어 있습니다. mihomo는 이를 기반으로 다음 기능을 추가로 보완했습니다:
구독 노드에 vless, hysteria2, tuic 같은 필드가 있는데 클라이언트에서 노드 유형이 지원되지 않는다는 메시지가 뜬다면, 대부분 아직 오리지널 코어를 사용 중이기 때문이며 mihomo 코어 버전으로 바꾸면 해결됩니다. 구독을 교체하거나 노드를 다시 생성할 필요는 없습니다.
오리지널 코어의 규칙 유형은 DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, IP-CIDR와 내장된 GEOIP에 집중되어 있으며, 규칙셋은 전체 목록 형태로 설정 파일에 직접 작성하거나 별도로 관리해야 해서 업데이트와 유지보수 비용이 높습니다. mihomo는 더 세분화된 규칙 유형과 더 효율적인 규칙셋 메커니즘을 도입했습니다:
rule-providers:
reject:
type: http
behavior: domain
url: "https://example-ruleset/reject.txt"
path: ./ruleset/reject.yaml
interval: 86400
rules:
- RULE-SET,reject,REJECT
- GEOSITE,category-ads-all,REJECT
- GEOSITE,cn,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY
여기서 rule-providers는 원격에서 주기적으로 가져와 로컬에 캐시하는 기능을 지원하며, GEOSITE 규칙은 사전 컴파일된 도메인 분류 데이터베이스(예: category-ads-all, cn)를 직접 참조하므로 도메인을 일일이 나열할 필요가 없습니다. 이런 문법은 오리지널 코어에서는 인식되지 않으므로, 설정 파일에 rule-providers나 GEOSITE가 있는데 오리지널 코어에서 실행하면 바로 문법 오류가 발생하거나 규칙이 적용되지 않습니다. 규칙 오작동을 진단할 때 가장 먼저 확인해야 할 부분입니다.
오리지널 코어의 DNS 모듈은 기능이 단순해서 보통 하나의 업스트림 서버 그룹만 설정할 수 있고, 대상 도메인별로 세밀하게 분산 처리하기 어려워 '중국 본토 도메인이 해외 DNS로 해석되어 접속이 느려지는' 문제나 'DNS가 실제 위치 정보를 유출하는' 문제가 자주 발생합니다. mihomo의 DNS 모듈은 전략별 그룹 설정을 지원합니다:
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- 223.5.5.5
- 119.29.29.29
nameserver-policy:
"geosite:cn": [223.5.5.5, 119.29.29.29]
"geosite:geolocation-!cn": [https://1.1.1.1/dns-query]
fake-ip-filter:
- "*.lan"
- "+.local"
nameserver-policy는 GeoSite 분류별로 서로 다른 해석 서버를 지정할 수 있어, 중국 본토 도메인은 본토 DNS로, 해외 도메인은 암호화 DNS로 처리하여 불필요한 우회를 근본적으로 줄일 수 있습니다. enhanced-mode도 오리지널의 비교적 단순한 구현에서 더 안정적인 fake-ip 모드로 확장되어, TUN과 함께 사용할 때 호환성이 더 좋습니다.
오리지널 코어 설정을 mihomo로 이전할 때, DNS 섹션의 오래된 필드(예: 일부 초기 버전에서 사용하던 단순한 dns.fallback 목록)는 그대로 복사하지 말고 새 문법에 맞춰 다시 작성하는 것이 좋습니다. 그렇지 않으면 오류는 나지 않지만 실제로는 적용되지 않을 수 있습니다.
TUN 모드는 Clash가 가상 네트워크 카드 형태로 시스템 전역 트래픽을 처리하도록 하여, 애플리케이션 계층의 시스템 프록시 설정에 의존하지 않습니다. 프록시 프로토콜을 지원하지 않는 프로그램(게임, 일부 커맨드라인 도구)에서 특히 중요합니다. 오리지널 코어의 TUN 구현은 등장이 비교적 늦었고 설정 항목이 적으며 플랫폼 지원도 제한적이어서, 초기에는 주로 Linux에서만 사용 가능했고 Windows/macOS 지원은 완전하지 않았습니다.
mihomo의 TUN 모듈은 네트워크 스택 처리 로직을 새로 작성했으며, 일반적인 설정은 다음과 같습니다:
tun:
enable: true
stack: system
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
stack은 system, gvisor 등 여러 네트워크 스택 구현을 선택할 수 있어 호환성과 성능을 모두 고려할 수 있습니다. auto-route와 auto-detect-interface는 라우팅 테이블을 자동으로 설정하고 출구 네트워크 카드를 자동으로 인식하여 수동 설정 단계를 줄여줍니다. Windows, macOS, Android 클라이언트의 현재 TUN(또는 가상 네트워크 카드/VPN 모드) 진입점은 대부분 mihomo 코어를 기반으로 구축되어 있으며, 이는 코어 버전을 선택할 때 mihomo를 우선 고려해야 하는 직접적인 이유 중 하나입니다.
오리지널 코어의 설정 파일을 mihomo 코어로 이전하면 대부분의 경우 그대로 사용할 수 있습니다. mihomo가 오리지널 문법에 대해 하위 호환성을 유지하기 때문입니다. 다만 다음 몇 가지는 주의해야 합니다:
MATCH나 FINAL을 마지막에 두어 기본 처리로 사용했는데, 이 규칙은 mihomo에서도 반드시 맨 끝에 유지해야 합니다. 그렇지 않으면 이후 규칙이 무시됩니다;type 필드에 mihomo에서는 smart, load-balance 등의 옵션이 추가되었습니다. 오리지널 코어가 인식하지 못하는 새 유형을 잘못 오래된 코어 설정에 넣으면 시작 실패로 이어질 수 있습니다;종합적으로 보면 mihomo는 이미 현재 대다수 클라이언트의 기본 선택이 되었으며, 새로운 프로토콜 지원, 더 세밀한 규칙 문법, 분류별 DNS 전략, 더 완성도 높은 TUN 구현 모두 오리지널 코어가 단기간에 따라잡기 어려운 격차입니다. 특별한 호환성 요구가 없다면 일상적으로는 mihomo 코어가 통합된 클라이언트 버전을 바로 선택하고, 설정 파일은 새 문법에 맞춰 점진적으로 조정하면 되며 기존 작성 방식을 억지로 유지할 필요는 없습니다.