먼저 커널, 클라이언트, 설정 체계를 구분하기
mihomo와 기본 Clash를 비교할 때 가장 흔한 오해는 커널, 그래픽 클라이언트, 구독 설정을 하나의 제품으로 보는 것입니다. 기본 Clash는 일반적으로 Dreamacro가 관리했던 Clash 오픈 소스 커널을 뜻합니다. 로컬 포트를 열고 프록시 연결을 수립하며 규칙을 실행하고 DNS를 처리한 뒤, 외부 제어 인터페이스를 통해 그래픽 화면에 실행 상태를 제공합니다. 원 프로젝트의 지속적인 유지보수가 중단된 뒤에도 기존 커널은 기존 설정으로 실행할 수 있지만, 새로운 프로토콜과 규칙 기능, 플랫폼 네트워크 변화에는 더 이상 대응하지 않습니다.
mihomo는 Clash.Meta에서 이어진 커널 프로젝트입니다. Clash 설정 체계와 정책 그룹, 규칙 매칭 방식을 유지하면서 프로토콜, DNS, TUN, 규칙 집합 및 트래픽 제어 기능을 확장했습니다. 이름이 바뀌었다고 설정 체계가 새로 설계된 것은 아닙니다. 여전히 Clash.Meta라는 표시를 사용하는 많은 클라이언트와 설정 디렉터리, 문서가 실제로는 mihomo를 연동하고 있습니다. 판단할 때는 애플리케이션 제목만 보지 말고 클라이언트 설정에 표시된 커널 이름과 버전을 확인해야 합니다.
그래픽 클라이언트는 커널 외부의 관리 계층으로, 일반적으로 구독 다운로드, 설정 전환, 정책 그룹 편집, 시스템 프록시 제어, 연결 기록 표시를 담당합니다. 하나의 클라이언트에서 여러 커널을 교체해 사용할 수 있고, 같은 설정을 여러 클라이언트가 읽을 수도 있습니다. 따라서 ‘클라이언트가 특정 필드를 지원한다’는 말에는 해당 클라이언트에 포함된 커널이 필드를 해석할 수 있는지와 화면에서 이를 올바르게 표시하고 수정할 수 있는지라는 두 가지 의미가 있습니다. 커널은 정상적으로 실행하지만 화면에 해당 설정 항목이 없는 경우도 드물지 않습니다.
프로토콜 지원 차이: mihomo의 범위는 더 넓지만 설정과 네트워크 제약은 여전히 존재
기본 Clash는 Shadowsocks, VMess, Trojan, Snell, HTTP, SOCKS 등 주요 프록시 유형을 지원해 기존 Clash 설정의 기본 요구를 충족할 수 있습니다. mihomo는 여기에 VLESS, Reality 관련 전송 방식, Hysteria, Hysteria2, TUIC, WireGuard 등을 추가하고 유지보수하며 프로토콜 매개변수 변화에도 계속 대응합니다. 실제 사용 가능한 범위는 설치된 mihomo 버전에 따라 달라집니다. 오래된 클라이언트에 포함된 커널은 새로운 필드를 인식하지 못할 수 있습니다.
프로토콜을 지원한다고 해서 가져온 뒤 반드시 연결되는 것은 아닙니다. VLESS 노드는 TLS, Reality, WebSocket, gRPC 또는 기타 전송 매개변수에 동시에 의존할 수 있습니다. Hysteria2와 TUIC는 주로 UDP를 사용하므로 UDP가 제한된 네트워크에서는 핸드셰이크 시간 초과가 발생할 수 있습니다. WireGuard 설정에는 주소, 개인 키, 공개 키, 라우팅, MTU도 포함됩니다. 구독 변환 과정에서 필드가 누락되면 커널이 해당 프로토콜을 지원하더라도 빠진 매개변수를 복구할 수 없습니다.
기본 Clash에서 mihomo로 마이그레이션할 때 기존 Shadowsocks, VMess, Trojan 노드는 대체로 호환성을 유지하기 쉽습니다. 반대로 마이그레이션할 때는 같은 방식으로 볼 수 없습니다. VLESS, Hysteria2, TUIC 또는 mihomo 전용 옵션이 포함된 설정을 기본 커널에 넘기면 알 수 없는 프록시 유형 오류가 바로 발생하거나, 지원하지 않는 필드를 읽는 단계에서 로딩이 중단될 수 있습니다. 설정 호환성은 두 커널이 양방향으로 완전히 동일하다는 뜻이 아니라, ‘mihomo가 기존 Clash 문법과 높은 호환성을 유지한다’는 의미에 가깝습니다.
프로토콜을 전환하기 전에 확인할 항목
- 클라이언트에 실제로 포함된 커널 버전과 커널을 별도로 업데이트할 수 있는지 확인합니다.
- 노드 프로토콜, 전송 계층, TLS, 서버 이름, 인증서 검증 등의 필드가 모두 갖춰져 있는지 확인합니다.
- 현재 네트워크에서 UDP를 사용할 수 있는지, 라우터·방화벽·기업 네트워크가 관련 트래픽을 제한하는지 확인합니다.
- 구독 업데이트 전에 변환 서비스를 거치는지, 변환 과정에서 새 프로토콜 매개변수가 보존되는지 확인합니다.
- 같은 이름의 정책 그룹이 여전히 유효한 노드를 참조하는지 확인해, 노드는 존재하지만 어떤 정책 그룹에도 선택되지 않는 상황을 방지합니다.
규칙과 정책 그룹: 기본 모델은 같지만 확장 기능은 다름
두 커널의 핵심 트래픽 분기 모델은 비슷합니다. 트래픽이 규칙을 순서대로 매칭하고, 일치하면 프록시 노드나 정책 그룹으로 전달됩니다. 일치하는 규칙이 없는 연결은 일반적으로 마지막의 MATCH 규칙이 처리합니다. DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, IP-CIDR, GEOIP, PROCESS-NAME 같은 주요 규칙은 마이그레이션하기 쉽고, select, url-test, fallback, load-balance 등의 정책 그룹도 Clash 사용자에게 익숙한 구성 방식을 이어갑니다.
mihomo는 규칙 표현 기능을 확장해 더 다양한 규칙 유형, 논리 조합, 인바운드 조건, 네트워크 유형 및 규칙 집합을 지원합니다. AND, OR, NOT 같은 논리 규칙은 ‘특정 도메인이면서 특정 인바운드에서 들어온 경우’ 같은 복합 조건을 표현하는 데 적합합니다. 다만 괄호, 쉼표, 하위 규칙 구조는 현재 커널 문법에 맞아야 합니다. 복잡한 규칙이 자동으로 정확도를 높여 주는 것은 아닙니다. 조건이 많을수록 연결 로그와 규칙 추적 정보를 함께 확인하며 매칭 결과를 점검해야 합니다.
규칙 집합은 데이터 형식도 구분해야 합니다. 기존 도메인 목록, IP CIDR 집합, 클래식 규칙 텍스트, 바이너리 규칙 집합은 behavior, format, 로딩 방식이 서로 다릅니다. rule-provider를 domain으로 선언했는데 내용에 쉼표로 구분된 전체 규칙을 넣으면 업데이트가 성공하더라도 예상대로 매칭되지 않을 수 있습니다. mihomo는 GEOSITE와 GEOIP 데이터를 이용한 분류도 지원하지만, 분류 이름은 사용하는 지리 데이터 파일에 따라 달라지며 모든 데이터 소스가 같은 태그를 포함하는 것은 아닙니다.
mode: rule
proxy-groups:
- name: 수동 선택
type: select
proxies:
- DIRECT
rule-providers:
local-direct:
type: file
behavior: domain
format: text
path: ./rules/direct.txt
rules:
- RULE-SET,local-direct,DIRECT
- MATCH,수동 선택위 예시는 규칙 집합과 정책 그룹 사이의 참조 관계만 보여 줍니다. 실제 설정을 마이그레이션할 때는 기존 프록시 노드, 프록시 제공자, 전체 정책 그룹도 함께 유지해야 하며, 이 조각만 현재 사용 중인 파일에 덮어쓰면 안 됩니다. 구독에서 가져온 설정이라면 다음 구독 업데이트 때 수정 내용이 사라지지 않도록 클라이언트의 오버라이드 또는 병합 기능을 이용해 사용자 지정 규칙을 추가하는 편이 좋습니다.
DNS와 TUN: 기능은 더 완전하지만 시스템 환경의 영향도 큼
Clash 계열 커널의 DNS 모듈은 도메인을 IP로 변환할 뿐 아니라 규칙 매칭, 프록시 서버 주소 확인, 시스템 DNS 우회 방지에도 영향을 줍니다. 기본 Clash는 이미 fake-ip, redir-host, nameserver, fallback, fallback-filter 등의 기능을 제공합니다. mihomo는 nameserver-policy, proxy-server-nameserver, direct-nameserver, fake-ip-filter 등의 설정을 추가해 프록시 노드 도메인, 직접 연결 도메인, 일반 조회에 서로 다른 해석 경로를 사용할 수 있도록 확장했습니다.
각 필드에는 명확한 역할 분담이 있습니다. nameserver는 일반 조회를 담당하고, proxy-server-nameserver는 프록시 서버 자체의 도메인을 확인해 프록시 연결 전에 발생할 수 있는 의존성 순환을 피하는 데 사용할 수 있습니다. nameserver-policy는 도메인별로 DNS 서버를 지정하며, fake-ip-filter는 가상 주소를 반환하기에 적합하지 않은 도메인을 제외합니다. respect-rules처럼 규칙에 따라 해석 경로를 선택하는 옵션을 사용할 때는 프록시 노드 도메인에 별도로 사용할 수 있는 DNS 서버도 보장해야 합니다. 그렇지 않으면 DNS 조회가 프록시에 의존하고, 프록시 연결은 다시 DNS 결과를 기다리는 상황이 발생할 수 있습니다.
fake-ip 모드는 도메인에 가상 주소를 할당한 뒤 커널이 연결을 가로챌 때 원래 도메인으로 되돌립니다. 따라서 일반적으로 안정적인 규칙 매칭을 기대할 수 있습니다. LAN 기기 검색, 일부 게임, 프린터 서비스, 실제 주소에 의존하는 애플리케이션은 필터 목록에 추가해야 할 수 있습니다. redir-host는 실제 DNS 결과를 반환해 기존 DNS와 동작이 더 가깝지만, 복잡한 트래픽 분기나 DNS 오염 환경에서는 상위 DNS 서버를 더 신중하게 구성해야 합니다. 마이그레이션할 때는 enhanced-mode 한 줄만 복사하지 말고 리슨 주소, IPv6, 필터 범위, 상위 프로토콜도 함께 확인하세요.
TUN 모드는 시스템 프록시 설정을 따르지 않는 트래픽을 가로채는 기능으로, 일부 명령줄 프로그램, 게임, 사용자 지정 네트워크 스택을 사용하는 애플리케이션이 대상입니다. mihomo는 TUN 라우팅, DNS 하이재킹, 자동 라우팅, 인터페이스 식별 기능을 비교적 폭넓게 제공하지만, 실제 사용 가능 여부는 운영체제 권한, 가상 네트워크 카드 드라이버, 방화벽, 다른 네트워크 소프트웨어에 함께 좌우됩니다. system, gVisor 등의 네트워크 스택은 성능, 호환성, 플랫폼 지원이 서로 다르므로 먼저 클라이언트의 기본 권장 항목을 사용한 뒤 구체적인 문제에 맞춰 조정하는 것이 좋습니다.
설정 호환성은 YAML 로딩 여부만으로 판단할 수 없음
mihomo가 설정을 성공적으로 해석했다는 것은 필드 문법 검사를 통과했다는 뜻일 뿐, 노드가 작동하거나 규칙이 올바르게 매칭되거나 외부 제어 화면과 완전히 호환된다는 의미는 아닙니다. 마이그레이션은 최소 네 계층으로 나눠 평가해야 합니다. YAML 구조, 커널 필드, 실행 리소스, 클라이언트 제어입니다. 들여쓰기 오류, 중복 키, 잘못된 데이터 유형은 YAML 계층에 해당합니다. 알 수 없는 프록시 유형과 정책 그룹 매개변수 불일치는 커널 계층의 문제입니다. 규칙 파일 누락과 지리 데이터베이스 미다운로드는 리소스 계층의 문제이며, 외부 제어 주소, 인증 키, API 차이는 그래픽 클라이언트에 영향을 줍니다.
mihomo는 일반적으로 기존 proxies, proxy-groups, rules, proxy-providers, rule-providers 구조를 읽을 수 있으며 mixed-port, socks-port, redir-port, allow-lan, mode, log-level 같은 주요 필드도 유지합니다. 다만 일부 오래된 설정은 특정 Clash Premium 동작에 의존하고, 다른 설정에는 클라이언트 전용 오버라이드가 추가되어 있을 수 있습니다. 같은 필드 이름이 보여도 값의 형식과 현재 버전 문서를 함께 확인해야 하며, 파일 확장자만으로 호환성을 판단해서는 안 됩니다.
외부 제어 인터페이스는 전반적으로 Clash API 사용 방식을 이어가므로 많은 제어 패널에서 트래픽, 연결, 정책 그룹, 로그를 계속 확인할 수 있습니다. 그러나 화면이 mihomo에 추가된 프록시 유형이나 설정 필드를 지원하지 않으면 기본 정보만 표시하거나, 설정을 저장할 때 알 수 없는 내용을 삭제할 수도 있습니다. 중요한 확장 항목은 별도의 설정 또는 오버라이드 파일에 두고, 클라이언트의 저장 동작이 원본 구독을 다시 작성하지 않는지 확인하세요.
자주 발생하는 호환성 문제와 점검 방향
- 시작하자마자 오류가 발생함: 먼저 오류가 표시된 줄 번호를 확인하고 YAML 들여쓰기, 필드 유형, 현재 커널의 해당 프록시 유형 지원 여부를 점검하세요.
- 설정은 로드되지만 모든 노드가 시간 초과됨: 노드 매개변수, 프록시 서버 DNS, 시스템 시간, UDP 조건, 구독 필드가 완전한지 확인하세요.
- 정책 그룹이 비어 있음: proxies, use, filter, exclude-filter를 확인하고 제공자 이름과 필터 표현식이 노드와 일치하는지 점검하세요.
- 규칙이 예상대로 매칭되지 않음: 규칙 순서, 규칙 집합 behavior, DNS 해석 결과, 연결이 TUN 또는 시스템 프록시에 실제로 인계되었는지 확인하세요.
- 화면에서 연결은 되지만 편집할 수 없음: 클라이언트가 아직 해당 설정 화면을 제공하지 않는 것일 수 있습니다. 지원되는 오버라이드 방식으로 확장 필드를 관리하세요.
기본 Clash에서 mihomo로 마이그레이션하는 순서
안정적인 마이그레이션의 핵심은 변경 변수를 줄이는 것입니다. 커널을 바꾸면서 DNS를 다시 작성하고 모든 규칙 집합을 교체하고 TUN까지 동시에 켜지 마세요. 문제가 발생했을 때 원인을 찾기 어려워집니다. 먼저 새 커널에서 기존 설정이 해석되고 기본 연결이 되는지 확인한 다음 mihomo 확장 기능을 하나씩 활성화하세요.
- 현재 설정과 클라이언트 설정을 보존합니다. 리슨 포트, 시스템 프록시 상태, 현재 정책 그룹 선택, DNS 모드, 외부 제어 주소를 기록하세요. 구독 주소와 로컬 오버라이드는 따로 저장해야 합니다.
- 설정 출처를 확인합니다. 로컬 YAML, 원격 구독, 프록시 제공자, 클라이언트 생성 설정을 구분하세요. 캐시 파일을 직접 수정하면 구독을 새로고침한 뒤 덮어써질 수 있습니다.
- mihomo로 문법을 검사합니다. 명령줄 환경에서는
mihomo -t -f config.yaml을 실행해 설정을 검사할 수 있습니다. 그래픽 클라이언트에서는 커널 로그에 표시된 구체적인 파일과 줄 번호를 확인하세요. - 기본 프록시부터 테스트합니다. 기존 규칙 모드를 유지하고 이미 작동이 확인된 노드 하나를 선택해 웹 접속, DNS 조회, 정책 전환이 정상인지 확인하세요. 이 단계에서는 새 프로토콜 노드를 추가하지 않습니다.
- 규칙과 제공자를 검증합니다. 원격 규칙 집합을 다운로드할 수 있는지, 정책 그룹에 구성원이 있는지, 마지막 MATCH 규칙이 존재하는지 확인하고 연결 로그에서 자주 사용하는 도메인의 실제 매칭 항목을 확인하세요.
- DNS 확장 기능은 별도로 활성화합니다. 필요에 따라 프록시 서버 DNS 해석, 도메인 정책, fake-ip 필터를 설정하세요. 한 번에 한 그룹의 필드만 조정하고 DNS 시간 초과나 순환 의존성이 발생하는지 관찰합니다.
- 마지막으로 TUN을 테스트합니다. 다른 프록시 클라이언트를 종료하고 가상 네트워크 카드 권한과 라우팅 복구 방식을 확인한 뒤 시스템 프록시를 사용하지 않는 프로그램을 테스트하세요. 인터넷이 끊기면 노드 매개변수를 계속 바꾸기보다 먼저 TUN을 종료해야 합니다.
mihomo -t -f config.yaml문법 검사를 통과한 뒤에도 실행 검증이 필요합니다. 커널 로그, 프록시 그룹 선택, DNS 조회, 연결 세부 정보, 시스템 라우팅 순서로 확인하는 것이 좋습니다. 기존 설정에 사용자 지정 필드가 많다면 먼저 최소 설정을 별도로 복사해 로컬 포트 하나, 노드 하나, 정책 그룹 하나, 마지막 규칙만 남겨 보세요. 최소 설정으로 연결할 수 있게 된 뒤 규칙 제공자, DNS, TUN 설정을 단계별로 복원하면 됩니다.
선택 기준: 설정 요구사항과 유지보수 상태를 기준으로 판단
기존 프로토콜 노드와 단순한 도메인 규칙을 사용하고 네트워크 환경이 장기간 변하지 않는 기기라면 기본 Clash 설정이 계속 작동할 수 있습니다. 그러나 기본 커널은 지속적인 유지보수가 중단되어 새로운 프로토콜, 운영체제 네트워크 변화, 장기적인 호환성 문제에 대응할 수 있는 방법이 제한적입니다. 새로 설치하거나 프로토콜 업데이트, 복잡한 규칙 집합, 세밀한 DNS, TUN 트래픽 가로채기가 필요한 사용자에게는 mihomo가 일반적으로 더 적합한 커널입니다.
그래픽 클라이언트를 선택할 때는 내장된 mihomo 버전, 커널 업데이트 방식, 설정 오버라이드 기능, 로그 확인 위치를 점검하세요. ‘Clash 설정 지원’이라고만 표시되어 있다고 해서 mihomo 확장 기능을 완전히 관리할 수 있다는 뜻은 아닙니다. 장기간 유지할 설정이라면 클라이언트 전용 필드에 대한 의존도 줄이고, 노드 출처, 정책 그룹, 규칙 집합, 로컬 오버라이드를 계층별로 관리하는 것이 좋습니다.
최종 판단 기준은 기능의 개수가 아니라 현재 설정을 검증하고 업데이트하고 되돌릴 수 있는지입니다. mihomo는 Clash 설정 체계의 범위를 넓혔지만, 각 확장 기능에는 그에 따른 매개변수와 환경 조건이 추가됩니다. ‘기존 설정과의 호환성을 먼저 확인한 뒤 새로운 기능을 추가한다’는 순서로 마이그레이션하면 프로토콜, DNS, 규칙, 시스템 트래픽 가로채기 문제를 나누어 처리할 수 있고 커널 업데이트 후 달라진 부분도 더 쉽게 찾을 수 있습니다.