커널 심화 예상 읽기 시간 13분

mihomo 커널이 클래식 Clash보다 강력한 이유: 프로토콜·규칙 집합·TUN 모드 비교

클래식 커널과 비교해 mihomo의 확장 기능을 항목별로 살펴봅니다. 추가 아웃바운드 프로토콜, rule-providers 규칙 집합, TUN 모드와 스니핑 기능이 일상적인 설정에 미치는 영향까지 설명합니다.

커널과 클라이언트부터 구분하기

Clash, mihomo, FlClash는 서로 다른 계층에 속합니다. 커널은 YAML 설정을 읽고 프록시 연결을 만들며, 규칙 매칭, DNS 처리와 트래픽 전달을 담당합니다. 클라이언트는 구독 관리, 설정 편집, 시스템 프록시 전환, 로그 표시와 플랫폼 권한 요청을 담당합니다. FlClash는 그래픽 클라이언트이고 mihomo는 FlClash에서 사용할 수 있는 프록시 커널입니다. “클래식 Clash와 mihomo”를 비교할 때 실제 대상은 창 구성이나 버튼 수가 아니라 두 커널의 기능입니다.

일반적으로 클래식 Clash는 Dreamacro가 공개한 오픈 소스 Clash를 가리킵니다. 공개 버전은 v1.18.0에 머물러 있으며, 대표적인 기본 기능으로 HTTP, SOCKS5와 mixed 인바운드, 규칙 모드, 프록시 그룹, DNS 처리, Shadowsocks·VMess·Trojan 등의 프록시 유형을 제공합니다. Clash Meta는 원본 코드 체계에서 계속 확장되었고 이후 mihomo로 이름이 바뀌었습니다. 많은 설정 필드가 여전히 호환되므로 기존 구독을 바로 불러올 수 있는 경우가 많지만, 호환된다고 해서 두 제품의 기능이 완전히 같은 것은 아닙니다.

직접 확인할 수 있는 주요 차이

기능 클래식 Clash mihomo 일상적인 영향
기본 규칙과 프록시 그룹 지원 호환성을 유지하며 계속 확장 기존 설정의 마이그레이션 비용이 낮음
새로운 아웃바운드 프로토콜 지원 범위가 제한적 Hysteria2, TUIC, VLESS, WireGuard 등을 지원 구독에 새 노드가 포함되어도 커널을 바꿀 필요가 없음
규칙 집합 기본 rule-providers 체계 제공 형식, 매칭 동작과 업데이트 기능이 더 충실함 대규모 규칙을 나누어 관리 가능
TUN 배포 형태에 따라 기능이 다름 자동 라우팅, 엄격한 라우팅과 다양한 프로토콜 스택을 지속적으로 유지 시스템 프록시를 사용하지 않는 프로그램도 트래픽을 인계받을 수 있음
트래픽 스니핑 기능이 제한적 독립적인 sniffer 설정과 재정의 정책 투명 프록시에서도 도메인 정보를 복원할 수 있음

프로토콜 지원: 차이는 먼저 노드 유형에서 나타납니다

클래식 Clash의 일반적인 아웃바운드 유형은 기존 구독을 대부분 처리할 수 있습니다. Shadowsocks, VMess, Trojan, HTTP, SOCKS5, Snell 등이 대표적입니다. 문제는 프록시 프로토콜이 계속 발전한다는 점입니다. 서버가 Hysteria2, TUIC, VLESS Reality, ShadowTLS 또는 WireGuard 노드를 제공하면 구형 커널은 지원하지 않는 프록시 유형이라고 표시하거나, 구독을 해석한 뒤 해당 노드를 무시할 수 있습니다.

mihomo는 이러한 유형을 위한 네이티브 설정 항목을 제공하며, 통합 프록시 그룹·상태 확인·규칙 분기 체계에 포함합니다. 예를 들어 url-test 프록시 그룹 하나에 기존 Trojan 노드와 Hysteria2 노드를 함께 넣고 측정 지연 시간에 따라 자동으로 선택할 수 있습니다. 사용자 관점에서 중요한 향상점은 프로토콜 이름이 많아졌다는 사실이 아니라, 구독에 포함된 노드를 하나의 규칙 체계로 활용할 수 있다는 점입니다.

프로토콜이 늘었다고 해서 모두 활성화할 필요는 없습니다

노드를 선택할 때는 서버 배포 품질, 경로의 패킷 손실과 한국 국내 네트워크 환경도 함께 확인해야 합니다. 한 번의 지연 시간 테스트는 당시 측정 URL의 왕복 시간만 보여 줍니다. 예를 들어 같은 네트워크에서 TCP 노드가 82 ms, QUIC 노드가 61 ms로 측정되었다고 해서 후자가 지속적인 다운로드에서도 반드시 빠른 것은 아닙니다. 통신사가 UDP를 제한한다면 QUIC 노드는 몇 분 뒤 큰 변동을 보일 수 있습니다.

rule-providers: 대규모 규칙을 설정 본문에서 분리하기

rule-providers의 핵심 용도는 규칙을 별도 파일에 저장한 뒤 기본 설정에서 RULE-SET으로 참조하는 것입니다. 이 개념은 mihomo가 갑자기 만든 것이 아닙니다. 클래식 Clash의 후기 설정 체계에서도 규칙 제공자를 확인할 수 있습니다. mihomo의 강점은 형식 지원, 매칭 유형, 업데이트 과정과 관련 동작을 지속적으로 다듬고 더 풍부한 규칙 문법과 함께 사용할 수 있다는 점입니다.

규칙이 수십 개뿐인 설정이라면 도메인을 rules 아래에 직접 작성해도 됩니다. 규칙이 수만 개로 늘어나면 계속 본문에 넣는 방식은 기본 파일을 읽기 어렵게 만들고 구독 오버라이드와 버전 관리도 복잡하게 합니다. 분리한 뒤에는 기본 설정에 규칙 집합 주소, 업데이트 주기와 대상 정책만 남기고 규칙 내용은 별도 파일로 관리할 수 있습니다.

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

  private-ip:
    type: http
    behavior: ipcidr
    format: yaml
    url: https://example.com/rules/private-ip.yaml
    path: ./ruleset/private-ip.yaml
    interval: 86400

rules:
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,private-ip,DIRECT,no-resolve
  - MATCH,노드 선택

behavior가 파일에 작성할 수 있는 내용을 결정합니다

interval: 86400은 원격 규칙을 86400초마다, 즉 24시간마다 확인한다는 뜻입니다. 요청할 때마다 다운로드한다는 의미는 아닙니다. 최초 다운로드에 성공하면 커널은 로컬 캐시를 사용하며, 원격 서버에 일시적으로 접속할 수 없어도 기존 파일은 대개 계속 매칭에 사용됩니다. 다만 규칙 주소 자체에 현재 네트워크로 접근할 수 있어야 하므로, 첫 실행 때 사용 가능한 캐시가 없을 수 있습니다.

mihomo는 규칙 집합을 위한 바이너리 mrs 형식도 지원합니다. 용량이 큰 도메인 또는 IP 규칙 집합에 적합하며 파싱 비용과 저장 공간을 줄이는 것이 목적입니다. mrs는 일반 텍스트가 아니므로 편집기로 한 줄씩 직접 수정할 수 없습니다. 사람이 관리해야 하는 비공개 규칙은 YAML이나 텍스트 형식을 계속 사용하는 편이 직관적입니다.

규칙 수보다 중요한 것은 규칙 순서입니다

Clash 규칙은 위에서 아래로 평가하며, 처음 일치한 규칙에서 처리를 멈춥니다. 규칙 집합 업데이트가 정상이어도 범위가 넓은 프록시 규칙을 직접 연결 규칙보다 앞에 두면 뒤의 직접 연결 항목은 실행되지 않습니다. 일반적으로 사설 도메인, LAN과 예약 주소를 앞에 두고, 서비스 규칙 집합을 중간에 배치하며, GEOIP나 다른 지역 판별 규칙은 뒤에 둔 다음 마지막에 MATCH로 마무리합니다.

TUN 모드: 시스템 프록시에서 전체 트래픽 인계로 확장

시스템 프록시는 보통 운영체제의 프록시 설정을 읽는 애플리케이션에만 영향을 줍니다. 브라우저는 대부분 지원하지만 게임, 명령줄 도구, 일부 스토어 클라이언트, 가상 머신 프로그램과 UDP 통신을 직접 수행하는 소프트웨어는 이를 우회할 수 있습니다. TUN 모드는 가상 네트워크 인터페이스를 만들고 라우팅 조건에 맞는 IP 트래픽을 커널로 전달하므로 더 넓은 범위를 처리합니다.

클래식 Clash의 일부 버전과 배포 형태에도 TUN 기능이 제공된 적이 있지만, 설정과 플랫폼 대응 및 유지 관리 상태는 통일되어 있지 않았습니다. mihomo는 TUN의 자동 라우팅, DNS 하이재킹, 다양한 네트워크 프로토콜 스택, 인터페이스 선택과 엄격한 라우팅을 계속 확장해 왔으며, 이것이 현대적인 그래픽 클라이언트가 mihomo를 널리 채택하는 중요한 이유입니다.

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

각 필드의 역할

FlClash에서는 먼저 설정을 가져와 일반 시스템 프록시가 정상적으로 작동하는지 확인한 다음, 「설정」→「네트워크 설정」에서 TUN 모드를 활성화하는 것이 좋습니다. Android와 데스크톱 운영체제에서는 VPN 또는 가상 네트워크 인터페이스 생성을 요청합니다. 권한을 승인한 뒤 로그에서 TUN 초기화 결과를 확인하세요. 클라이언트 버전에 따라 메뉴 이름이 조금 다를 수 있으므로 「설정」에서 TUN, VPN 서비스 또는 네트워크 인터페이스 관련 항목을 찾으면 됩니다.

TUN에서 자주 발생하는 충돌

  1. 다른 VPN이 동시에 실행 중인 경우: 두 프로그램이 모두 기본 라우팅을 인계하려 하면 인터넷이 끊기거나 라우팅이 반복해서 전환될 수 있습니다.
  2. LAN 접속 이상: 프린터, NAS 또는 개발 장치가 있는 네트워크 대역을 직접 연결 규칙에 추가해야 합니다. 대표적인 사설 네트워크는 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12입니다.
  3. 가상 머신 및 컨테이너 네트워크: Docker, WSL, Hyper-V 등은 가상 네트워크 카드를 생성합니다. 자동 인터페이스 감지가 올바르지 않다면 출구 인터페이스 선택과 제외 라우팅을 확인해야 합니다.
  4. DNS를 중복으로 인계받는 경우: 시스템 보안 소프트웨어, 암호화 DNS 도구와 mihomo가 동시에 DNS를 수신하거나 리디렉션하면 조회 시간 초과가 발생할 수 있습니다.

스니핑 기능: 투명 프록시에서도 도메인 복원

규칙 엔진은 도메인을 기준으로 트래픽을 판단할 때 더 효과적이지만, TUN이 처음 확인하는 대상은 IP인 경우가 많습니다. 예를 들어 애플리케이션이 자체적으로 DNS 조회를 마친 뒤 203.0.113.10:443에 직접 연결하면, 커널이 IP만 받은 상황에서는 DOMAIN-SUFFIX 규칙을 바로 적용할 수 없습니다. 스니퍼는 연결 초기 데이터를 분석해 TLS의 서버 이름, HTTP Host 또는 QUIC 정보에서 대상 도메인을 추출하고 이를 규칙 매칭에 사용합니다.

sniffer:
  enable: true
  parse-pure-ip: true
  override-destination: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443

parse-pure-ip는 대상이 순수 IP로 표시된 연결에서 도메인 식별을 시도하게 합니다. override-destination은 스니핑 결과로 원래 대상 정보를 덮어쓸지 결정합니다. 포트 범위는 실제 서비스에 맞게 설정해야 하며, “전체를 처리한다”는 이유로 모든 포트에서 모든 파서를 활성화하는 것은 좋지 않습니다. HTTP, TLS 또는 QUIC이 아닌 사설 프로토콜은 이러한 파서로 유효한 도메인을 얻을 수 없습니다.

스니핑은 DNS를 대체하지 않습니다

스니핑은 연결이 수립되는 단계에서 동작하고, DNS는 도메인을 어떻게 해석할지 결정하므로 두 기능의 역할은 다릅니다. 안정적인 설정을 위해서는 nameserver, fallback, fake-ip, redir-host 같은 DNS 필드도 적절히 설정해야 합니다. Fake IP를 사용하면 커널이 도메인을 예약 주소 풀에 매핑한 뒤 연결 단계에서 도메인을 복원합니다. 스니핑은 커널 DNS를 우회하거나 IP에 직접 연결하는 트래픽을 보완할 수 있습니다.

일부 애플리케이션은 인증서 고정, 암호화된 클라이언트 인사 또는 사용자 지정 QUIC 동작을 사용하므로 스니핑으로 유효한 이름을 얻지 못할 수 있습니다. 연결 대상이 잘못 덮어써졌다면 먼저 로그에서 원래 대상과 스니핑 대상을 확인하세요. 그런 다음 전체 스니핑을 끄기보다 도메인 제외 또는 소스 주소 제외 규칙으로 특정 서비스만 제외하는 방법이 좋습니다.

DNS, 규칙과 TUN은 하나의 설정으로 함께 점검해야 합니다

mihomo의 확장 기능은 서로 연결되어 있습니다. TUN만 켜고 DNS를 처리하지 않으면 규칙에 필요한 도메인을 얻지 못할 수 있습니다. 스니핑만 활성화하고 규칙 순서를 올바르게 설정하지 않으면 복원된 도메인도 잘못된 정책에 매칭됩니다. 규칙 집합 설정이 올바르더라도 다운로드 주소가 현재 네트워크에서 차단되면 첫 실행 시 규칙 파일을 저장하지 못합니다. 문제를 점검할 때는 “인바운드 인계 → DNS → 스니핑 → 규칙 매칭 → 프록시 그룹 → 아웃바운드 연결” 순서로 로그를 확인하세요.

반복해서 사용할 수 있는 점검 절차

  1. 일반 시스템 프록시 모드에서 기본 노드 하나 이상이 TCP 연결을 수립하는지 확인합니다.
  2. mixed 인바운드 포트가 사용 중인지 확인하세요. 대표적인 값은 7890이며, 두 클라이언트가 같은 포트를 동시에 수신하지 않도록 해야 합니다.
  3. DNS 로그에서 결과가 반환되는지 확인하고, 반환된 주소가 실제 IP인지 Fake IP 주소인지 살펴봅니다.
  4. TUN을 활성화한 뒤 시스템 프록시를 끄고, 시스템 프록시를 읽지 않는 애플리케이션의 트래픽이 커널 로그에 나타나는지 테스트합니다.
  5. 연결 기록에서 Host, 대상 IP, 일치한 규칙과 최종 프록시 그룹을 확인해 스니핑 결과가 잘못 덮어쓰지 않았는지 점검합니다.
  6. 규칙 제공자를 수동으로 업데이트하고 HTTP 상태, 저장 경로와 업데이트 시간을 확인합니다. 그런 다음 interval의 전체 주기를 기다려 자동 업데이트를 검증합니다.
  7. TCP와 UDP를 각각 테스트하세요. 웹페이지가 열린다는 것은 TCP 경로가 기본적으로 정상이라는 뜻일 뿐이며, QUIC·게임 음성 채팅 또는 DNS의 UDP 경로가 정상임을 증명하지는 않습니다.

mihomo의 향상을 직접 체감할 수 있는 사용자

브라우저, 기본 Shadowsocks 노드와 몇 개의 도메인 규칙만 사용하는 사용자라면 커널을 바꿔도 속도 차이를 즉시 느끼지 못할 수 있습니다. mihomo의 가치는 “지원 범위와 설정 확장성”에 더 가깝습니다. 구독에 새로운 프로토콜이 추가되면 이를 해석할 수 있고, 애플리케이션이 시스템 프록시를 우회하면 TUN으로 인계할 수 있으며, 투명 트래픽에 도메인이 없으면 스니핑으로 보완할 수 있습니다. 대규모 규칙은 규칙 제공자를 통해 독립적으로 업데이트할 수 있습니다.

기존 설정을 mihomo로 옮길 때 모든 확장 기능을 한꺼번에 켤 필요는 없습니다. 먼저 노드와 프록시 그룹을 검증하고, 다음으로 규칙을 확인한 뒤 DNS를 조정하고, 마지막에 TUN과 스니핑을 활성화하는 편이 안전합니다. 이렇게 하면 문제가 발생했을 때 원인이 프록시 프로토콜인지, 해석 경로인지, 규칙 순서인지, 시스템 라우팅인지 빠르게 찾을 수 있습니다.

결론은 네 가지로 요약할 수 있습니다. 클래식 Clash는 설정 문법과 규칙 기반 프록시 모델을 마련했고, mihomo는 호환성을 이어가면서 새로운 프로토콜을 계속 추가하고 있습니다. 규칙 제공자는 대규모이면서 업데이트 가능한 규칙 데이터를 관리하는 데 적합합니다. TUN과 스니핑은 트래픽 분기를 “시스템 프록시를 지원하는 애플리케이션”에서 더 넓은 기기 트래픽으로 확장합니다. 실제 설정에서는 필드를 무작정 늘리기보다 필요한 기능을 중심으로 구성해야 합니다.

FlClash 다운로드 플랫폼별 클라이언트 보기