mihomo 커널 기능 분석: 기존 Clash와의 설정 차이 및 마이그레이션 핵심

Clash 클라이언트에서 그래픽 인터페이스는 설정 가져오기, 정책 전환, 실행 상태 표시를 담당하지만, 연결·DNS·규칙 매칭·프록시 프로토콜을 실제로 처리하는 것은 커널입니다. mihomo는 Clash.Meta에서 이어져 개발된 호환 커널입니다. 이미 많은 클라이언트가 mihomo를 기본 커널로 사용하지만, 인터페이스에는 여전히 Clash, Meta 또는 Premium 같은 이름이 표시될 수 있습니다. 따라서 현재 기능을 판단할 때는 클라이언트 이름만 보지 말고 실제로 로드된 커널 종류, 커널 버전과 시작 로그도 확인해야 합니다.

기존 Clash 설정은 보통 마이그레이션의 출발점으로 사용할 수 있지만, '읽을 수 있다'고 해서 실행 결과까지 완전히 같다는 뜻은 아닙니다. mihomo는 프록시 프로토콜, 규칙 유형, DNS 제어, 트래픽 스니핑, TUN 라우팅과 규칙 집합 형식을 확장했으며 일부 필드도 더 명확한 방식으로 처리합니다. 마이그레이션의 핵심은 새 기능을 한꺼번에 모두 활성화하는 것이 아니라, 먼저 기존 분기 결과를 유지한 다음 강화 기능을 하나씩 켜는 것입니다.

커널의 역할과 호환 범위

기존 Clash, Clash.Meta와 mihomo의 관계

기존 Clash는 YAML 설정, 프록시 그룹, 규칙 분기와 외부 제어 인터페이스 같은 기본 구조를 마련했습니다. Clash.Meta는 이 구조를 기반으로 프로토콜, DNS, TUN, 규칙 표현식과 트래픽 식별 기능을 확장했습니다. 이후 프로젝트는 mihomo라는 이름으로 계속 유지 관리되고 있으므로, 설정 문서·로그 또는 클라이언트 설정에서 여전히 Meta라는 표기가 보일 수 있습니다. 마이그레이션 관점에서는 mihomo를 Clash 설정 모델을 계승하면서 더 다양한 네트워크 처리 기능을 추가한 커널로 이해하면 되며, 완전히 독립된 설정 체계로 볼 필요는 없습니다.

호환 범위는 주로 세 가지 계층의 영향을 받습니다. 첫째는 커널 자체로, 현재 mihomo 버전이 특정 필드를 지원하는지 여부입니다. 둘째는 클라이언트로, 인터페이스가 해당 필드를 실제 설정에 기록할 수 있는지와 시작 전에 병합·덮어쓰기를 수행하는지입니다. 셋째는 구독 제공처로, 원격 설정에 대상 커널이 인식하지 못하는 프로토콜이나 규칙이 포함되어 있는지입니다. 문제를 진단할 때는 이 세 계층을 분리해야 하며, 인터페이스의 토글만으로 최종 설정을 판단해서는 안 됩니다.

같은 YAML 설정에서 결과가 달라지는 이유

기존 커널에서 성공적으로 시작된 설정도 mihomo로 바꾸면 DNS 결과, 규칙 매칭 또는 라우팅 범위가 달라질 수 있습니다. 흔한 원인으로는 클라이언트가 DNS 설정을 자동으로 주입하는 경우, 커널마다 네트워크 인터페이스를 선택하는 방식이 다른 경우, GeoData 데이터베이스 버전 차이, TUN 스택과 시스템 라우팅 구현의 변화가 있습니다. 반대로 mihomo 전용 필드를 기존 Clash에 다시 넣으면 거부되거나 무시되거나 설정 로드 실패가 발생할 수 있습니다.

마이그레이션 전에 클라이언트에 '실행 설정 보기' 또는 '최종 설정 내보내기' 기능이 있는지 먼저 확인해야 합니다. 구독 원문, 클라이언트가 덮어쓴 설정과 커널이 실제로 로드한 설정은 서로 다른 파일일 수 있습니다. 포트, DNS와 라우팅이 현재 방식으로 작동하는 이유를 설명하려면 최종 설정을 확인해야 합니다.

확인 계층	중점 항목	자주 나타나는 현상
클라이언트	커널 선택, 덮어쓰기 스크립트, 실행 권한	인터페이스에는 저장됐지만 커널 매개변수가 바뀌지 않음
커널	버전, 지원 필드, 시작 로그	알 수 없는 필드, 규칙 집합 파싱 실패
설정	YAML 들여쓰기, 정책 참조, 포트	설정을 로드할 수 없거나 정책 그룹이 비어 있음
시스템 네트워크	라우팅, DNS, 네트워크 인터페이스, 방화벽	TUN은 시작됐지만 일부 프로그램이 인터넷에 연결되지 않음

mihomo의 주요 기능 차이

프록시 프로토콜과 아웃바운드 기능

기존 Clash 설정의 핵심은 여러 프록시 노드를 정책 그룹으로 묶은 뒤 규칙으로 정책을 선택하는 것입니다. mihomo는 이 구조를 유지하면서 사용할 수 있는 프로토콜과 전송 옵션을 확장했습니다. 실제 지원 범위는 구체적인 버전과 클라이언트의 패키징 방식에 따라 달라집니다. 구독 설정을 마이그레이션할 때 노드가 최신 프로토콜을 사용한다면, 먼저 현재 클라이언트에 포함된 mihomo 버전이 해당 필드를 파싱할 수 있는지 확인하고 서버 측 매개변수가 모두 갖춰졌는지 점검해야 합니다.

프로토콜을 지원한다고 해서 노드에 반드시 연결되는 것은 아닙니다. 인증서 이름, 전송 계층 매개변수, 사용자 식별자, 암호화 방식, UDP 지원 여부와 시스템 시간이 핸드셰이크에 영향을 줍니다. 특정 노드 하나가 실패하면 전체 모드를 반복해서 바꾸기보다 먼저 커널 로그에서 연결 단계부터 확인해야 합니다. 모든 노드가 실패한다면 클라이언트가 구독을 변환했는지, 네트워크가 대상 포트를 제한하는지, DNS가 서버 주소를 해석할 수 있는지를 점검합니다.

규칙 시스템과 규칙 집합

mihomo는 위에서 아래로 규칙을 매칭하는 방식을 이어받았습니다. 연결이 조건에 맞는 첫 번째 규칙에 매칭되면 지정된 정책으로 전달됩니다. 일반적인 규칙에는 도메인, 도메인 접미사, IP 대역, 프로세스, GeoIP, GeoSite와 원격 규칙 집합이 있습니다. 마지막에는 보통 MATCH를 사용해 아직 매칭되지 않은 트래픽을 처리합니다.

rules:
  - DOMAIN-SUFFIX,example.net,Proxy
  - GEOSITE,cn,DIRECT
  - GEOIP,cn,DIRECT,no-resolve
  - MATCH,Proxy

마이그레이션할 때는 규칙이 참조하는 정책 이름이 실제로 존재하는지 확인해야 합니다. 정책 이름은 문자를 정확히 구분하므로, 구독 업데이트 후 Proxy가 다른 이름으로 바뀌면 규칙 문법이 올바르더라도 예상대로 작동하지 않습니다. GeoSite와 GeoIP는 로컬 데이터 파일에도 의존합니다. 데이터베이스가 없거나 다운로드에 실패하거나 버전이 다르면 같은 도메인도 서로 다르게 판단될 수 있습니다.

규칙 집합을 사용하면 많은 도메인이나 네트워크 대역을 기본 설정에서 분리해 관리할 수 있습니다. mihomo는 여러 규칙 집합 동작과 형식을 지원하지만, 구형 클라이언트가 최신 형식을 인식하지 못할 수 있습니다. 초기 마이그레이션에서는 이미 검증한 YAML 또는 텍스트 규칙 집합을 유지하고, 안정성이 확인된 뒤 더 간결한 형식을 검토하는 편이 좋습니다. 한 번의 마이그레이션에서 커널, 규칙 데이터 소스와 모든 정책 이름을 동시에 바꾸지 마세요. 문제가 생겼을 때 원인을 찾기 어려워집니다.

DNS, Fake IP와 도메인 매핑

mihomo의 DNS 모듈은 업스트림 서버, 프록시 노드 도메인용 DNS 서버, 폴백 정책과 도메인별 리졸버를 독립적으로 지정할 수 있습니다. fake-ip 모드에서는 커널이 애플리케이션에 예약 주소를 반환하고 해당 주소와 원래 도메인의 매핑을 저장합니다. 이후 연결이 커널로 들어오면 도메인 규칙에 따라 계속 분기할 수 있습니다. 이 방식은 대상 IP만 제공하는 애플리케이션에 특히 중요하지만, DNS 요청이 실제로 커널에 도달해야 합니다.

시스템이 여전히 다른 로컬 서비스로 DNS 요청을 보내거나 브라우저에서 별도의 암호화 DNS를 사용하면 커널이 원래 도메인을 확인하지 못할 수 있습니다. 이 경우 도메인 규칙이 매칭되지 않거나, 감지 결과가 섞이거나, 일부 애플리케이션이 분기를 우회하는 현상이 나타납니다. TUN 환경에서는 DNS 가로채기를 함께 사용할 수 있지만, 포트 충돌·로컬 네트워크 DNS와 기업 네트워크 정책은 별도로 검토해야 합니다.

TUN, 스니핑과 애플리케이션 트래픽 가로채기

시스템 프록시는 일반적으로 운영체제의 프록시 설정을 따르는 프로그램에만 영향을 줍니다. 명령줄 도구, 게임, 일부 스토어 애플리케이션과 UDP 연결을 직접 생성하는 프로그램은 이를 우회할 수 있습니다. TUN 모드는 가상 네트워크 인터페이스와 시스템 라우팅을 통해 더 넓은 범위의 트래픽을 받아 커널에서 처리합니다. mihomo는 여러 TUN 스택과 자동 라우팅 옵션을 제공하지만, 운영체제마다 필요한 권한과 라우팅 구현이 다릅니다.

트래픽 스니핑은 이미 연결된 세션에서 도메인 정보를 식별해 대상 IP만 확인되는 상황에서도 규칙 매칭을 개선하는 기능입니다. 모든 프로토콜에서 동작하는 것은 아니며 올바른 DNS 설정을 대신할 수도 없습니다. 마이그레이션할 때는 먼저 일반 DNS와 규칙을 검증한 뒤 애플리케이션 범위를 정해 스니핑을 활성화하는 것이 좋습니다. 그래야 규칙 편차와 스니핑으로 인한 대상 변경을 한꺼번에 판단하지 않을 수 있습니다.

설정 필드와 문법 마이그레이션 핵심

기본 포트와 제어 인터페이스부터 유지하기

기본 필드는 두 커널 계열에서 비교적 유사합니다. 마이그레이션할 때는 혼합 포트, 로컬 네트워크 접근, 실행 모드, 로그 수준과 외부 제어 인터페이스를 우선 유지할 수 있습니다. 포트 번호는 클라이언트 인터페이스 및 시스템 프록시 설정과 일치해야 하며, 제어 인터페이스에는 접근 키와 적절한 수신 범위를 함께 적용해야 합니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
secret: "local-control-key"

mixed-port는 HTTP와 SOCKS 프록시 요청을 동시에 받아 대부분의 데스크톱 클라이언트에 적합합니다. 기존 설정에서 port와 socks-port를 পৃথ어 사용했다면 해당 포트를 호출하는 프로그램의 마이그레이션이 끝날 때까지 기존 구조를 유지한 뒤 통합할 수 있습니다. 여러 클라이언트가 같은 포트를 동시에 수신하지 않도록 하세요. 나중에 시작된 커널이 주소 사용 중 오류를 즉시 보고합니다.

규칙 제공자의 동작 유형

rule-providers에서 중요한 것은 다운로드 주소뿐 아니라 behavior, format, 로컬 경로와 업데이트 주기입니다. domain은 도메인 집합에, ipcidr은 IP 대역에 적합하며, classical은 유형과 정책 조건이 포함된 기존 규칙을 담을 수 있습니다. 동작 유형과 파일 내용이 일치하지 않으면 규칙 집합이 다운로드되더라도 파싱되지 않을 수 있습니다.

rule-providers:
  private-domains:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/private-domains.yaml
    url: https://example.invalid/rules/private-domains.yaml
    interval: 86400

rules:
  - RULE-SET,private-domains,DIRECT
  - MATCH,Proxy

규칙 제공자의 URL은 데이터 출처일 뿐이며, 최종적으로는 RULE-SET을 통해 순서가 있는 규칙 목록에 넣어야 합니다. 제공자를 정의했지만 참조하지 않으면 트래픽 분기에 참여하지 않습니다. 마이그레이션 후에는 연결 로그나 클라이언트 연결 화면에서 매칭된 규칙을 확인해 트래픽이 예상한 규칙 집합으로 들어가는지 점검해야 합니다.

검증 가능한 최소 DNS 설정 구조

DNS 설정은 단계적으로 늘리는 것이 좋습니다. 1단계에서는 커널 DNS와 수신 주소, 안정적인 업스트림만 설정합니다. 2단계에서 강화 모드를 활성화하고, 3단계에서 도메인별 정책, 프록시 노드 전용 리졸버와 필터 목록을 추가합니다. 아래 구조는 필드 간 관계를 보여주는 예이며, 구체적인 업스트림은 네트워크 환경과 사용 목적에 맞게 선택해야 합니다.

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query

proxy-server-nameserver는 주로 프록시 서버 자체의 도메인을 해석해 프록시 연결 전에 DNS 의존성이 생기는 것을 막는 데 사용됩니다. 노드 서버를 IP로 직접 입력했다면 이 항목의 영향은 작습니다. IPv6를 활성화하기 전에 로컬 네트워크, 프록시 노드와 규칙이 IPv6를 제대로 처리하는지 확인해야 합니다. DNS에서 IPv6 응답만 켠다고 해서 이후 연결에 사용 가능한 경로가 보장되는 것은 아닙니다.

TUN 필드는 시스템 환경과 분리해 복사할 수 없음

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

이 필드들은 일반적인 방향을 나타낼 뿐, 모든 시스템에서 동일한 값을 사용해야 한다는 뜻은 아닙니다. 가상 머신, 컨테이너, VPN, 기업 보안 소프트웨어와 다중 네트워크 인터페이스 환경은 기본 라우팅을 바꿀 수 있습니다. Windows에서는 가상 인터페이스 생성과 라우팅 수정 권한이 클라이언트에 필요할 수 있고, macOS에서는 네트워크 확장 또는 시스템 권한 승인이 필요할 수 있습니다. Linux에서는 해당 네트워크 관리 권한이 필요합니다. 활성화 후 로컬 네트워크 장치에 접근할 수 없다면 프록시 규칙을 바로 수정하기보다 라우팅 테이블과 제외할 대역을 확인하세요.

기존 Clash에서 mihomo로 마이그레이션하는 순서

현재 기준 상태를 기록합니다.
원본 YAML, 클라이언트 덮어쓰기 규칙과 구독 주소를 저장하고, 현재 시스템 프록시 포트·제어 포트·DNS 모드·TUN 상태와 정상 작동하는 정책 그룹을 기록합니다. 스크린샷은 비교 자료로만 활용하고 복구 가능한 설정 파일을 반드시 보관하세요.
클라이언트가 실제로 사용하는 커널을 확인합니다.
클라이언트의 커널 설정, 정보 페이지 또는 시작 로그에서 커널 이름과 버전을 확인합니다. 일부 클라이언트는 커널을 전환한 뒤 완전히 재시작해야 하며, 설정만 다시 로드하면 기존 프로세스가 계속 트래픽을 처리할 수 있습니다.
문법을 검사합니다.
먼저 YAML 들여쓰기, 중복 키, 빈 정책 그룹과 존재하지 않는 정책 참조를 처리합니다. 문자열에 콜론, 샵 또는 특수 문자가 포함되면 따옴표를 사용하세요. 설정 파싱 오류는 로그에 표시된 줄 주변부터 확인하되, 실제 원인은 바로 앞 구간의 들여쓰기일 수 있습니다.
시스템 프록시로 기본 연결을 검증합니다.
TUN, 스니핑과 복잡한 DNS 덮어쓰기를 잠시 끄고, 사용 가능한 것으로 확인된 프록시 노드 하나와 단순한 규칙만 활성화합니다. 직접 연결, 프록시와 차단 세 정책이 각각 올바르게 매칭되는지 테스트합니다. 기본 연결이 실패하면 고급 기능을 추가하지 말고 노드와 포트를 먼저 점검하세요.
정책 그룹과 규칙 집합을 복원합니다.
select, url-test, fallback 등의 그룹 구성원이 유효한지 하나씩 확인하고, 규칙 대상과 정책 이름이 일치하는지 점검합니다. 자동 테스트 그룹의 테스트 URL, 간격과 허용 오차가 선택 결과에 영향을 주므로 한 번 지연 시간이 가장 낮았다고 장기적으로 최적이라고 판단해서는 안 됩니다.
DNS를 마이그레이션합니다.
먼저 커널의 수신 포트가 사용 중이 아닌지 확인한 다음, 시스템 또는 TUN이 해당 수신 주소로 쿼리를 전달하는지 점검합니다. 일반 도메인, 규칙 집합 도메인과 프록시 서버 도메인을 각각 테스트하고 로그에서 리졸버와 최종 규칙을 확인하세요.
마지막으로 TUN과 스니핑을 활성화합니다.
활성화한 뒤 기본 라우팅, 로컬 네트워크 접근, 절전 모드 복귀와 네트워크 전환을 확인합니다. 문제가 발생한 프로그램은 대상 주소, 프로토콜과 매칭 규칙을 기록한 뒤 제외 항목을 추가할지 스니핑 범위를 조정할지 결정하세요.

구독 마이그레이션에서는 '원격 설정'과 '로컬 덮어쓰기'도 구분해야 합니다. 원격 업데이트는 노드와 정책 그룹을 덮어쓸 수 있고, 로컬 덮어쓰기는 포트·DNS 또는 사용자 지정 규칙을 유지하는 데 사용됩니다. 클라이언트가 설정 병합을 지원한다면 병합 순서를 명확히 확인하세요. 그렇지 않으면 구독 업데이트 후마다 사용자 지정 필드가 남아 있는지 점검해야 합니다. 클라이언트가 관리하는 캐시 파일을 직접 편집하지 마세요. 다음 업데이트 때 다시 생성될 수 있습니다.

마이그레이션 후 자주 발생하는 문제와 진단 방법

설정은 로드되지만 커널을 통과하는 트래픽이 없음

먼저 시스템 프록시가 현재 mixed-port를 가리키는지 확인한 다음, 클라이언트 프로세스가 실제로 해당 포트를 수신 중인지 점검합니다. 브라우저에 이전 프록시 설정이 남아 있을 수 있고, 명령줄 프로그램은 환경 변수의 이전 포트를 읽을 수도 있습니다. TUN을 사용하는 경우에는 가상 인터페이스 생성 여부, 기본 라우팅 변경 여부와 현재 네트워크 인터페이스가 올바르게 인식되었는지도 확인해야 합니다.

도메인 규칙이 매칭되지 않고 IP 규칙만 표시됨

이는 대개 커널이 대상 도메인을 확보하지 못했다는 뜻입니다. 애플리케이션이 별도 DNS를 사용하는지, 시스템 쿼리가 커널로 들어오는지, Fake IP 매핑이 유효한지 확인하세요. 일부 프로토콜만 도메인을 제공하지 않는 경우에는 스니핑을 추가로 검토할 수 있지만, 모든 프로그램이 IP만 표시된다면 먼저 DNS 경로를 복구해야 합니다. 앞쪽의 IP 규칙이나 규칙 집합이 이미 트래픽을 먼저 처리했을 수 있으므로 규칙 순서도 확인하세요.

규칙 제공자 업데이트 실패

다운로드 URL, 네트워크 경로, 파일 형식과 로컬 디렉터리 권한을 확인합니다. 처음 시작할 때는 원격 규칙이 아직 캐시되지 않았을 수 있습니다. 다운로드 자체가 아직 설정되지 않은 프록시 정책에 의존하면 시작 단계에서 의존성 문제가 발생합니다. 먼저 규칙 소스에 명확한 접근 경로를 제공하고 파일이 정상적으로 저장된 뒤 전체 분기를 복원할 수 있습니다. 로그의 HTTP 상태, 파싱 오류와 파일 경로가 인터페이스의 일괄적인 '업데이트 실패' 메시지보다 진단에 더 유용합니다.

TUN 활성화 후 로컬 네트워크 또는 일부 애플리케이션 연결 끊김

먼저 TUN을 끄고 문제가 가상 라우팅과 관련 있는지 확인한 뒤 사설 네트워크 대역, 게이트웨이, 로컬 네트워크 DNS와 다른 VPN을 점검합니다. 다중 네트워크 인터페이스 장치에서는 자동 감지가 현재 인터넷에 연결된 인터페이스를 선택했는지도 확인해야 합니다. 특정 UDP 애플리케이션만 이상하다면 노드의 UDP 지원 여부, 정책 그룹이 올바른 아웃바운드를 선택했는지, 시스템 방화벽이 가상 인터페이스 트래픽을 허용하는지를 확인하세요.

구독 업데이트 후 정책 이름이 변경됨

규칙, 규칙 집합과 클라이언트의 빠른 선택 기능 모두 정책 이름을 참조할 수 있습니다. 업데이트 후 정책 이름이 바뀌면 기존 규칙은 존재하지 않는 대상을 가리키게 됩니다. 해결 방법은 인터페이스에서 한 번 다시 선택하는 것이 아니라 이름을 통일하고 모든 참조를 확인하는 것입니다. 장기간 유지할 사용자 지정 규칙에는 안정적인 로컬 정책 그룹을 중간 계층으로 사용하고, 구독 노드는 해당 그룹에 넣는 방법이 좋습니다.

mihomo 마이그레이션 체크리스트

클라이언트에 표시된 실제 실행 커널이 원하는 mihomo 버전입니다.
원본 설정, 구독 정보와 클라이언트 덮어쓰기를 각각 별도로 백업했습니다.
HTTP, SOCKS 또는 혼합 포트가 다른 프로세스와 충돌하지 않습니다.
모든 규칙이 참조하는 정책 그룹이 존재하며, 각 그룹에 하나 이상의 사용 가능한 구성원이 있습니다.
규칙은 구체적인 조건부터 기본 조건 순서로 배치되며, 마지막 MATCH가 명확한 정책을 가리킵니다.
GeoIP, GeoSite와 원격 규칙 집합을 정상적으로 로드하고 업데이트할 수 있습니다.
DNS 쿼리가 예상한 수신 주소로 들어가며 프록시 서버 도메인을 해석할 수 있습니다.
시스템 프록시 모드에서 직접 연결과 프록시 트래픽이 모두 규칙에 따라 매칭됩니다.
TUN 활성화 후 기본 라우팅, 로컬 네트워크 접근과 네트워크 전환이 정상적으로 유지됩니다.
구독 업데이트 후에도 로컬 덮어쓰기, 정책 이름과 사용자 지정 규칙이 유효합니다.

mihomo의 가치는 지속적으로 유지 관리되는 커널 기능, 더욱 완성도 높은 규칙 및 DNS 제어, 현대적인 네트워크 가로채기 환경에 대한 대응력에 있습니다. 마이그레이션 성공 여부는 연결 로그, 규칙 매칭, DNS 경로와 시스템 라우팅의 실제 결과로 판단해야 합니다. 기본 프록시, 규칙, DNS, TUN 순서로 계층별 검증을 진행하면 기존 Clash 설정을 대체로 안정적으로 전환하면서도 문제 발생 시 명확한 복구 지점을 확보할 수 있습니다.