mihomo 커널의 새로운 기능은? 기본 Clash 커널과의 기능 차이 총정리

기본 Clash, Clash Meta, mihomo의 차이부터 알아보기

여기서 말하는 “기본 Clash”는 일반적으로 Dreamacro가 관리했던 Clash 오픈 소스 커널을 뜻합니다. YAML 설정을 읽고 프록시 연결을 구성하며 규칙을 적용하고, HTTP·SOCKS5·mixed-port를 통해 로컬 애플리케이션에 프록시 서비스를 제공합니다. 기본 프로젝트의 업데이트가 중단된 뒤 커뮤니티 포크인 Clash Meta가 프로토콜, 규칙, DNS, 투명 프록시 기능을 계속 확장했으며 이후 프로젝트명이 mihomo로 변경되었습니다.

따라서 Clash Meta와 mihomo는 둘 중 하나를 선택해야 하는 별개의 커널이 아닙니다. 전자는 이전 이름이고 후자는 현재 이름입니다. 일부 클라이언트 UI, 구독 변환기, 기존 설정에는 여전히 “Meta”가 표시될 수 있으므로, 판단할 때는 클라이언트 이름보다 실제 커널 버전을 확인해야 합니다.

빠른 확인: 터미널에서 mihomo -v를 실행하거나 그래픽 클라이언트에서 「설정」→「커널」→「커널 버전」으로 이동하세요. 출력에 Mihomo Meta 또는 구버전 Clash.Meta가 표시되면 Meta 계열 커널을 사용 중이라는 뜻입니다. 클라이언트마다 메뉴 이름은 조금씩 다를 수 있습니다.

커널과 그래픽 클라이언트도 구분해서 이해해야 합니다. 클라이언트는 트레이 메뉴, 설정 다운로드, 시스템 프록시 전환, 로그 표시를 담당하고, 실제로 proxies·rules·dns·tun 등의 필드를 인식하는 것은 커널입니다. 같은 설정이 두 클라이언트에서 다르게 동작한다면, 흔한 원인은 UI가 아니라 번들된 커널의 종류나 버전 차이입니다.

기능 비교의 기본 범위

기능	기본 Clash	mihomo
기본 규칙 기반 프록시	지원	호환 및 확장
최신 프록시 프로토콜	초기 세대 프로토콜 중심	VLESS, Reality, TUIC, Hysteria2 등 추가 지원
TUN 투명 프록시	오픈 소스 버전의 기능은 제한적이며, 한때 Premium 구현과 병존	다양한 프로토콜 스택과 자동 라우팅 통합
논리 조합 규칙	선형 규칙 중심	AND, OR, NOT 및 하위 규칙 지원
GEO 데이터	기본 GEOIP·GEOSITE 사용 방식	로드 방식, 다운로드 주소, 자동 업데이트 제어 추가
트래픽 스니핑	기능 제한	독립적인 sniffer 설정 구간 제공

프로토콜 지원: 추가된 것은 노드 유형만이 아니다

기본 Clash는 이미 Shadowsocks, VMess, Trojan, Snell, SOCKS5, HTTP 등 일반적인 노드를 처리할 수 있습니다. mihomo는 여기에 프로토콜과 전송 계층 구현을 계속 추가했으며, 대표적으로 VLESS, XHTTP, Reality, TUIC, Hysteria, Hysteria2, WireGuard와 다양한 Shadowsocks 플러그인 및 전송 조합을 지원합니다. 실제 사용 가능한 필드는 커널 버전에 따라 달라지므로, 구독에 새 필드가 등장하면 먼저 클라이언트에 포함된 mihomo가 충분히 최신인지 확인해야 합니다.

VLESS와 Reality

기본 Clash는 mihomo 설정에 포함된 VLESS 노드를 인식하지 못합니다. mihomo는 type: vless를 읽고 uuid·flow·network·tls 등의 필드를 처리할 수 있습니다. Reality를 사용할 때는 reality-opts·public-key·short-id가 함께 포함될 수도 있습니다. 이러한 필드를 기본 커널에 그대로 전달하면 일반적으로 설정 검증 단계에서 지원하지 않는 프록시 유형이나 필드라는 오류가 표시됩니다.

proxies:
  - name: vless-reality-example
    type: vless
    server: example.net
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    network: tcp
    tls: true
    udp: true
    servername: www.example.com
    reality-opts:
      public-key: example-public-key
      short-id: "01234567"
    client-fingerprint: chrome

예시는 필드 구조를 보여주기 위한 것일 뿐이며, 주소·UUID·공개 키·짧은 ID는 실제 서비스 설정에서 가져와야 합니다. Reality 관련 매개변수는 한 세트로 맞춰야 하므로 일반 VLESS 노드의 tls만 true로 바꿔서는 안 됩니다.

TUIC와 Hysteria2

TUIC와 Hysteria2는 모두 QUIC·UDP를 기반으로 하지만 설정 필드는 서로 호환되지 않습니다. TUIC의 주요 필드로는 uuid·password·congestion-controller·udp-relay-mode가 있고, Hysteria2에는 password·obfs·obfs-password와 대역폭 매개변수가 자주 사용됩니다. 제공받은 노드의 프로토콜 유형은 커널 설정의 type과 일치해야 합니다.

네트워크에서 TCP만 허용한다면 이러한 UDP 기반 프로토콜은 연결을 수립하지 못할 수 있습니다.
모바일 네트워크에서 Wi-Fi와 셀룰러 데이터 사이를 전환하면 QUIC 세션을 다시 연결해야 할 수 있습니다.
노드가 지연 시간 테스트를 통과했다고 해서 대용량 파일 전송 속도가 반드시 더 빠른 것은 아닙니다. 패킷 손실과 통신사 속도 제한도 확인해야 합니다.
클라이언트에 “설정 정상”이라고 표시되는 것은 YAML을 해석할 수 있다는 뜻일 뿐, 서버 측 매개변수까지 일치한다는 의미는 아닙니다.

전역 TLS 핑거프린트

mihomo는 global-client-fingerprint로 전역 클라이언트 핑거프린트를 설정할 수 있으며, 일부 프록시 노드에는 client-fingerprint를 개별 지정할 수도 있습니다. 자주 사용하는 값은 chrome·firefox·safari·ios·random입니다. 노드 수준 필드는 전역 필드보다 우선 적용되므로 설정을 옮길 때 충돌하는 값을 동시에 작성하지 않도록 주의하세요.

global-client-fingerprint: chrome
unified-delay: true
tcp-concurrent: true

unified-delay는 지연 시간 계산 방식을 통일해 테스트 결과가 전체 연결 과정에 더 가까워지도록 합니다. tcp-concurrent는 해석 결과에 포함된 여러 IP에 동시에 연결을 시도하고, 먼저 성공한 연결을 사용합니다. 둘 다 mihomo에서 자주 사용하는 최상위 확장 필드이므로 기본 Clash 설정에서는 이에 의존하지 않아야 합니다.

규칙 시스템: 개별 매칭에서 논리 조합까지

두 커널 모두 “위에서 아래로 확인하고, 처음 일치한 규칙에서 중지한다”는 기본 순서를 따릅니다. 기본 Clash에서 흔히 사용하는 규칙은 DOMAIN·DOMAIN-SUFFIX·DOMAIN-KEYWORD·IP-CIDR·GEOIP·PROCESS-NAME·RULE-SET과 마지막의 MATCH입니다. mihomo는 이러한 문법을 유지하면서 네트워크 속성과 논리 조합 기능을 더 확장했습니다.

AND, OR, NOT

논리 규칙은 “여러 조건을 동시에 만족하는 경우”나 “특정 조건을 제외하는 경우”를 표현할 때 유용합니다. 예를 들어 UDP이면서 목적지 포트가 443인 트래픽만 특정 정책 그룹으로 보내려면 네트워크 유형과 포트 조건을 조합할 수 있습니다. 논리 규칙은 괄호와 쉼표의 계층이 엄격하므로, 현재 사용 중인 설정을 바로 덮어쓰기보다 먼저 커널 검증 명령으로 확인하는 것이 좋습니다.

rules:
  - AND,((NETWORK,UDP),(DST-PORT,443)),QUIC 정책
  - OR,((DOMAIN-SUFFIX,example.com),(DOMAIN-SUFFIX,example.net)),프록시
  - NOT,((GEOIP,CN)),중국 본토 외 트래픽
  - MATCH,최종 선택

논리 조합의 가치는 규칙 수를 줄이는 데 있지 않고, 하나의 조건을 여러 개의 중복 목록으로 나누지 않아도 된다는 데 있습니다. 규칙이 복잡할수록 자주 사용하고 범위가 명확한 도메인 규칙을 앞에 두고, 범위가 넓은 GEOIP·규칙 세트와 MATCH는 뒤에 배치해야 합니다.

포트·네트워크·프로세스 규칙

mihomo는 소스 포트, 목적지 포트, 인바운드 유형, 네트워크 프로토콜, 프로세스 경로에 따라 트래픽을 추가로 분기할 수 있습니다. 주요 필드는 SRC-PORT·DST-PORT·IN-TYPE·NETWORK·PROCESS-NAME·PROCESS-PATH입니다. 예를 들어 DNS는 보통 53번 포트, HTTPS는 443번 포트를 사용하며 로컬 mixed-port는 7890으로 설정하는 경우가 많습니다.

주의: 프로세스 규칙은 운영체제 권한과 커널의 조회 방식에 따라 동작합니다. TUN 모드에서 프로세스 이름이 계속 비어 있다면 find-process-mode를 확인하고, 클라이언트에 연결 소유 프로세스를 조회하는 데 필요한 시스템 권한이 있는지 점검하세요. 컨테이너·가상 머신·일부 샌드박스 앱은 호스트 프로세스를 안정적으로 반환하지 못할 수 있습니다.

규칙 제공자와 하위 규칙

rule-providers는 많은 도메인 및 IP 규칙을 관리하는 주요 방식입니다. mihomo는 domain·ipcidr·classical 등의 동작 유형과 YAML 텍스트 또는 MRS 같은 페이로드 형식을 지원합니다. 규칙 제공자의 behavior는 파일 내용과 일치해야 합니다. 순수 도메인 모음은 ipcidr로 표시하면 안 되며, 완전한 규칙 문법이 포함된 목록은 classical을 사용해야 합니다.

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

rules:
  - RULE-SET,private-domains,DIRECT
  - MATCH,프록시

interval: 86400은 86400초, 즉 24시간마다 한 번 업데이트를 확인한다는 뜻입니다. 원격 규칙을 처음 다운로드하지 못하면 커널이 내용을 임의로 생성할 수 없습니다. URL 접근 가능 여부, 파일 형식, 저장 디렉터리 권한, 로그의 HTTP 상태 코드를 확인해야 합니다.

TUN 모드: 더 넓은 인계 범위와 완성도 높은 프로토콜 스택

시스템 프록시는 프록시 설정을 직접 읽는 애플리케이션에만 영향을 줍니다. 브라우저는 일반적으로 시스템 프록시를 사용할 수 있지만, 게임·명령줄 도구·일부 스토어 앱·UDP 소켓을 직접 생성하는 소프트웨어는 이를 우회할 수 있습니다. TUN 모드는 가상 네트워크 카드를 만들고 라우팅 조건에 맞는 IP 트래픽을 커널로 전달하므로 더 넓은 범위를 인계합니다.

기본 오픈 소스 Clash와 구형 Premium 커널은 한때 TUN 기능의 범위가 서로 달랐습니다. mihomo는 TUN·DNS 하이재킹·자동 라우팅·트래픽 스니핑을 지속적으로 관리되는 하나의 설정 체계로 통합하고 system·gvisor·mixed 등의 프로토콜 스택 옵션을 제공합니다. 실제 사용 가능 여부는 운영체제와 클라이언트 권한의 영향도 받습니다.

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

세 가지 stack 중 무엇을 선택할까

system: 시스템 네트워크 스택을 더 많이 활용하므로 일반적으로 성능과 시스템 호환성이 좋지만, 운영체제 구현의 영향을 받습니다.
gvisor: 사용자 공간 네트워크 스택으로 더 많은 프로토콜 세부 사항을 처리합니다. 격리가 명확하며 특수한 네트워크 환경에서 문제를 비교해 볼 때 유용합니다.
mixed: 연결 유형에 따라 조합해 처리합니다. 많은 데스크톱 환경에서 흔히 사용하는 출발점이지만, 실제 클라이언트의 권장 설정을 우선해야 합니다.

auto-route는 라우팅을 자동으로 작성해 트래픽을 TUN으로 보냅니다. auto-detect-interface는 현재 출구 네트워크 인터페이스를 식별하고, strict-route는 우회 경로를 더 엄격하게 제한합니다. Windows·macOS·Linux의 라우팅 구현은 서로 다르므로, 활성화한 뒤 로컬 네트워크 프린터나 NAS에 접근할 수 없다면 프록시 노드를 바로 바꾸기보다 사설 네트워크 대역이 올바르게 직접 연결되는지 먼저 확인하세요.

트래픽 스니핑으로 도메인 정보 보완

TUN이 인계한 연결에는 대상 IP만 있고 원래 도메인이 없는 경우가 있습니다. mihomo의 sniffer는 TLS ClientHello·HTTP Host·QUIC 핸드셰이크에서 도메인을 추출한 뒤 도메인 규칙 매칭에 사용할 수 있습니다. 이를 통해 “도메인 규칙을 작성했지만 연결이 IP 규칙에만 매칭되는” 상황을 줄일 수 있습니다.

sniffer:
  enable: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
  skip-domain:
    - Mijia Cloud

스니핑은 DNS 조회를 대체하지 않으며 모든 암호화 연결에서 완전한 도메인을 복원할 수도 없습니다. 설정할 때는 포트 범위를 제한하고, 대상 정보를 변경하기에 적합하지 않은 것으로 알려진 서비스는 skip-domain으로 제외해야 합니다. 문제를 진단할 때는 먼저 스니핑을 끄고 결과를 비교해 문제가 노드·DNS·규칙·도메인 덮어쓰기 중 어디에서 발생하는지 확인하세요.

DNS와 GEO 데이터: 세분화된 제어 항목 확대

기본 Clash는 이미 nameserver·fallback·fallback-filter·enhanced-mode·fake-ip-filter를 제공합니다. mihomo는 이 필드를 유지하면서 default-nameserver·proxy-server-nameserver·direct-nameserver·nameserver-policy·respect-rules 등 세분화된 제어 항목을 추가했습니다.

nameserver별 역할

default-nameserver: 다른 DNS 서버의 도메인 이름을 조회하는 데 주로 사용하며, 일반적으로 직접 접근할 수 있는 IP 주소의 서버를 지정합니다.
nameserver: 일반적인 도메인 조회를 처리하는 DNS 설정의 주요 업스트림입니다.
proxy-server-nameserver: 프록시 노드 서버의 도메인 이름만 조회해 노드 주소 조회가 프록시 순환에 빠지는 것을 방지합니다.
direct-nameserver: 규칙에 따라 직접 연결로 판단된 도메인에 별도의 업스트림을 제공합니다.
nameserver-policy: 도메인이나 규칙 세트별로 DNS 업스트림을 지정해 더 세밀한 조회 경로를 구성합니다.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query

예시에서는 커널 DNS를 1053번 포트에서 수신하도록 설정해 시스템에서 흔히 사용하는 53번 포트를 직접 점유하지 않습니다. TUN의 dns-hijack는 조건에 맞는 53번 포트 조회를 커널로 전달합니다. 시스템에 이미 로컬 DNS 서비스가 있다면 먼저 포트 점유 상태를 확인해 두 프로세스가 같은 주소를 수신하지 않도록 해야 합니다.

GEOIP, GEOSITE와 GeoSite.dat

GEOIP는 대상 IP가 속한 지역을 기준으로 매칭하고, GEOSITE는 관리되는 도메인 분류를 기준으로 매칭하므로 서로 다른 데이터입니다. 도메인 규칙은 DNS 조회 전에 매칭될 수도 있지만, GEOIP는 일반적으로 대상 IP를 확인해야 합니다. 모든 트래픽을 GEOIP에 맡긴다고 도메인 분류를 대체할 수 있는 것은 아니며, 조회 후 매칭 비용이 늘어날 수도 있습니다.

mihomo는 geodata-mode·geodata-loader·geox-url·geo-auto-update·geo-update-interval 등의 최상위 설정을 제공해 데이터 형식·로드 방식·다운로드 위치·업데이트 주기를 제어합니다. 일부 버전은 GeoIP·GeoSite·MMDB·ASN 데이터에 별도 주소를 지정하는 기능도 지원합니다.

geodata-mode: true
geo-auto-update: true
geo-update-interval: 24
geox-url:
  geoip: https://example.net/data/geoip.dat
  geosite: https://example.net/data/geosite.dat
  mmdb: https://example.net/data/country.mmdb
  asn: https://example.net/data/ASN.mmdb

geo-update-interval: 24는 일반적으로 시간 단위로 해석하며, 24시간마다 업데이트를 확인한다는 뜻입니다. 실제 필드 지원 여부와 데이터 형식은 mihomo 버전에 따라 달라지므로 배포 전 현재 커널 문서와 시작 로그를 기준으로 확인해야 합니다. 다운로드 주소가 HTML 오류 페이지를 반환하면 HTTP 상태가 정상처럼 보여도 데이터 로드는 실패합니다.

기본 Clash로 되돌릴 때 문제가 생기는 필드

기본적인 port·socks-port·mixed-port·allow-lan·mode·log-level·proxies·proxy-groups와 일반적인 rules는 대체로 호환됩니다. 실제 마이그레이션 실패의 원인은 mihomo 확장 노드 유형, 논리 규칙, 최상위 확장 설정인 경우가 많습니다.

필드 또는 작성 방식	mihomo 용도	마이그레이션 시 주의 사항
`global-client-fingerprint`	전역 TLS 클라이언트 핑거프린트 설정	기본 커널에서는 이 필드에 의존하면 안 됨
`sniffer`	HTTP·TLS·QUIC 트래픽에서 도메인 식별	관련 도메인 덮어쓰기 로직 제거 필요
`geox-url`	GEO 데이터 다운로드 주소 지정	기본 Clash는 데이터 관리 방식이 다름
`tcp-concurrent`	여러 조회 주소에 동시 연결 시도	구형 커널은 무시하거나 거부할 수 있음
`VLESS`、`TUIC`、`Hysteria2`	최신 프록시 프로토콜	노드를 변경하거나 mihomo를 계속 사용해야 함
`AND`、`OR`、`NOT`	논리 조합 규칙	기본 Clash가 인식할 수 있는 선형 규칙으로 나눠야 함
`listeners`	여러 사용자 지정 인바운드 리스너 정의	기본 Clash는 일반적으로 고정 포트 필드를 사용

검증 후 실행 설정 교체

YAML을 수정한 뒤 별도 디렉터리에서 먼저 검증할 수 있습니다. mihomo에서 자주 사용하는 명령 형식은 다음과 같으며, -d는 설정 및 데이터 파일이 들어 있는 작업 디렉터리를 가리키고 -f는 설정 파일을 지정합니다.

mihomo -t -d ./mihomo-work -f ./config.yaml

검증을 통과했다는 것은 문법·필드·로컬 파일을 기본적으로 읽을 수 있다는 뜻일 뿐입니다. 이후 실행 로그에서 노드 핸드셰이크, 규칙 제공자 다운로드, DNS 수신, TUN 라우팅도 확인해야 합니다. 최소한 네 가지 테스트를 권장합니다. 직접 연결되어야 하는 사이트 접속, 프록시를 사용해야 하는 사이트 접속, UDP 요청 1회 실행, 시스템 프록시를 끈 뒤에도 TUN이 대상 애플리케이션을 인계하는지 확인입니다.

mihomo가 필요한지 판단하는 방법

설정에 Shadowsocks·VMess·Trojan과 단순한 도메인 규칙만 있고 시스템 프록시로 모든 애플리케이션을 처리할 수 있다면, 커널을 바꿔도 눈에 띄는 변화가 크지 않을 수 있습니다. 설정의 안정성은 여전히 커널 이름 자체보다 노드 매개변수·규칙 순서·DNS 경로에 더 크게 좌우됩니다.

다음과 같은 환경에는 mihomo가 더 적합합니다. 구독에 VLESS Reality·TUIC·Hysteria2가 포함된 경우, TUN으로 게임과 명령줄 프로그램을 인계해야 하는 경우, 프로세스·인바운드·논리 조건으로 트래픽을 분기하려는 경우, 노드 도메인의 DNS를 독립적으로 관리해야 하는 경우, GEOSITE·ASN·MRS 규칙 세트나 GEO 데이터 자동 업데이트를 사용하는 경우, 투명 프록시 환경에서 스니핑으로 도메인을 복원해야 하는 경우입니다.

먼저 클라이언트의 「설정」→「커널」에서 실제 커널 이름과 버전을 확인하세요.
현재 설정을 내보낸 뒤 type: vless·type: tuic·type: hysteria2·sniffer:·geox-url:을 검색하세요.
설정을 검증하고 알 수 없는 필드·들여쓰기 오류·데이터 파일 누락 등의 문제를 해결하세요.
로그를 열고 수준을 일시적으로 info로 설정하세요. 복잡한 연결을 진단할 때만 짧은 시간 동안 debug를 사용하면 됩니다.
TUN·DNS 하이재킹·스니핑을 하나씩 활성화하고, 네트워크 경로를 한 번에 모두 변경하지 마세요.