코어 해설 예상 읽기 시간 12분

mihomo 코어의 새로운 기능: 기존 Clash와 기능 차이 총정리

mihomo의 신규 프로토콜, 규칙 세트와 GEO 데이터 처리, TUN 기능을 살펴보고 기존 Clash와 설정 방식의 차이를 비교합니다.

비교 대상: 기존 Clash, Premium, mihomo

mihomo는 Clash Meta 프로젝트가 이름을 바꾼 뒤 사용하는 코어 이름입니다. Clash의 YAML 설정 체계를 이어받았으며, 아웃바운드 프로토콜, 규칙 표현, DNS, 트래픽 가로채기 기능을 꾸준히 확장해 왔습니다. 클라이언트 창에 ‘Clash’나 ‘Meta’라고 표시되어도 실제로 기존 Clash가 실행 중이라는 뜻은 아닙니다. UI 이름, 설정 형식 이름, 코어 이름은 구분해서 확인해야 합니다.

이 글에서 ‘기존 Clash’는 원 프로젝트가 유지 보수를 중단하기 전의 오픈 소스 코어만을 가리키며, Clash Premium의 기능은 포함하지 않습니다. Premium은 TUN, 규칙 제공자 등의 확장 기능을 제공한 적이 있습니다. 따라서 ‘기존 오픈 소스 코어에 특정 기능이 없다’고 해서 ‘역대 모든 Clash 파생 버전에 그 기능이 없었다’고 볼 수는 없습니다. 이 구분은 특히 오래된 설정을 마이그레이션할 때 중요합니다.

기능기존 오픈 소스 Clashmihomo
HTTP, SOCKS, SS, VMess, Trojan 등 일반적인 아웃바운드지원. 세부 매개변수는 버전에 따라 다름계속 지원하며 일부 매개변수 확장
VLESS、REALITY、Hysteria2、TUICmihomo 설정 문법을 그대로 사용할 수 없음지원. 프로토콜과 서버 매개변수를 맞춰야 함
규칙 제공자 rule-providers기존 오픈 소스 코어의 기본 기능은 아님여러 동작 방식과 파일 형식 지원
GEOSITE 및 논리 규칙해당 mihomo 확장 문법은 지원하지 않음지원. 해당 데이터나 규칙을 준비해야 함
TUN 트래픽 가로채기 및 DNS 하이재킹mihomo의 해당 설정을 제공하지 않음지원. 시스템 권한과 라우팅 환경에 따라 달라짐
Fake-IP DNS관련 기능이 이미 있음기존 기능을 이어받아 확장했으며 처음 도입된 것은 아님

프로토콜 확장: 구독의 type과 전송 매개변수 확인

가장 눈에 띄는 차이는 지원되는 아웃바운드 프로토콜이 늘었다는 점입니다. 구형 코어에서 type: hysteria2 또는 type: vless를 만나면 로드 단계에서 지원하지 않는 프록시 유형이라고 표시될 수 있습니다. 아웃바운드 연결이 만들어지기 전의 문제이므로, 프록시 그룹을 바꾸거나 규칙 순서를 조정해도 해결되지 않습니다.

VLESS와 REALITY는 서로 바꿔 쓸 수 있는 두 가지 노드 유형이 아닙니다

VLESS는 프록시 프로토콜이고, REALITY는 해당 아웃바운드 설정에서 사용할 수 있는 보안 핸드셰이크 방식입니다. mihomo에서 VLESS 노드는 보통 type: vless로 선언하고, REALITY 관련 설정은 reality-opts에 작성합니다. 노드 유형을 reality로 바꾸는 것은 같은 설정으로 변환하는 방법이 아닙니다.

  • uuid는 인증 매개변수이며 서버 설정과 일치해야 합니다.
  • servername, reality-opts.public-key, short-id는 서버에서 제공한 정보에 따라 입력해야 합니다. 도메인만 보고 임의로 추측해서는 안 됩니다.
  • flow, 전송 방식, 핑거프린트 옵션은 서로 조합에 제약이 있습니다. 필드 하나만 추가한다고 기존 VMess 노드가 VLESS 노드로 바뀌지는 않습니다.

Hysteria2와 TUIC에는 사용 가능한 UDP 경로가 필요합니다

Hysteria2와 TUIC은 QUIC 기반이므로, 연결 가능 여부는 코어 지원 여부만으로 결정되지 않습니다. 현재 네트워크에서 UDP가 차단되거나 심하게 제한되면 TCP 노드는 연결되지만 이 두 프로토콜은 시간 초과가 발생할 수 있습니다. Hysteria와 Hysteria2는 이름만 바꾸면 되는 같은 설정이 아니므로, 구독에 실제로 표시된 프로토콜 유형을 사용하세요.

예를 들어 서버가 UDP 443을 수신한다면 로컬 방화벽, 상위 네트워크, 서버 보안 그룹에서 해당 포트를 허용하는지 확인해야 합니다. 브라우저에서 TCP 443으로 웹페이지가 열린다고 해서 같은 주소의 UDP 연결도 사용할 수 있는 것은 아닙니다. 프로토콜을 바꾸면 반드시 속도가 빨라진다고 볼 수도 없습니다. 패킷 손실, 서버 용량, 속도 제한 정책에 따라 결과가 달라집니다.

규칙 세트 확장: 인라인 rules에서 별도 관리 데이터 파일까지

기존 Clash에도 순서에 따라 규칙을 매칭하는 기능이 있으며, mihomo 역시 첫 번째로 일치하는 규칙이 아웃바운드를 결정하는 기본 원리는 바꾸지 않았습니다. 확장된 부분은 규칙의 출처와 표현 방식입니다. rule-providers로 외부 규칙 세트를 관리한 다음 RULE-SET으로 참조할 수 있고, AND, OR, NOT 같은 논리 규칙으로 조건을 조합할 수도 있습니다.

로컬 규칙 제공자의 최소 구성

아래 두 부분을 각각 기본 설정 파일과 규칙 파일로 저장하세요. 예시에는 DIRECT만 있어 규칙 로드 구조를 확인할 뿐, 프록시 노드를 자동으로 만들지는 않습니다. 작업 디렉터리에 rules 폴더를 만든 뒤 파일을 넣으세요. 상대 경로는 코어의 실행 환경을 기준으로 해석되며, 데스크톱에서 보이는 구독 파일 위치와 다를 수 있습니다.

# 기본 설정의 관련 부분
rule-providers:
  work-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/work-domains.yaml

rules:
  - RULE-SET,work-domains,DIRECT
  - MATCH,DIRECT
# ./rules/work-domains.yaml
payload:
  - '+.example.com'
  - 'example.org'

behavior: domain은 파일 내용이 도메인 매칭 형식임을 뜻합니다. 여기에 IP-CIDR,192.168.0.0/16을 바로 섞어 넣으면 안 됩니다. 여러 유형의 규칙 문장을 하나의 규칙 세트에 포함하려면 classical을 선택하고 해당 형식에 맞춰 내용을 작성하세요.

  • domain: 도메인 목록에 적합합니다.
  • ipcidr: IP 대역 목록에 적합합니다.
  • classical: 여러 규칙 유형을 포함하는 규칙 세트에 적합합니다.
  • mrs: mihomo가 지원하는 바이너리 규칙 형식입니다. 주로 domain 및 ipcidr 동작에 사용하며, 임의의 YAML 파일에 확장자만 바꿔 붙인 형식은 아닙니다.

규칙 제공자와 프록시 제공자도 혼동하면 안 됩니다. rule-providers는 매칭 조건을 제공하고, proxy-providers는 프록시 노드를 제공합니다. 구독 업데이트가 성공했다는 것은 해당 리소스가 업데이트되었다는 뜻일 뿐, 다른 유형의 리소스까지 다운로드되거나 적용되었다는 의미는 아닙니다.

GEO 데이터: GEOIP는 IP 주소, GEOSITE는 도메인 분류를 확인

GEOIP 규칙은 mihomo만의 기능이 아닙니다. 기존 Clash도 지역 데이터 기반으로 IP를 매칭할 수 있었습니다. mihomo의 변화 중 하나는 GEOSITE 등 데이터 기반 기능과 다양한 GEO 데이터 로드 및 업데이트 옵션이 추가된 점입니다. 두 규칙은 매칭 대상이 다르므로 키워드만 서로 바꿔도 같은 결과를 얻을 수 없습니다.

규칙 예시매칭 기준사용 전 확인 사항
GEOIP,CN,DIRECT대상 IP의 데이터베이스 항목데이터 파일을 읽을 수 있어야 함. 도메인 연결은 이름 확인이 필요할 수 있음
GEOSITE,cn,DIRECT도메인이 지정된 분류에 포함되는지 여부GEOSITE 데이터를 로드했고 cn 분류가 포함되어 있어야 함
GEOIP,CN,DIRECT,no-resolve대상 IP의 지역 정보가 이미 있어야 함이 규칙을 위해 도메인을 추가로 확인하지 않음

geodata-mode: true는 GEOIP 데이터 처리 방식을 전환하며, 일반적으로 GeoIP.dat를 사용합니다. 기본값의 다른 방식은 MMDB 데이터를 사용합니다. GEOSITE는 자체 도메인 분류 데이터를 사용하므로, GEOIP 모드를 활성화한다고 모든 도메인 분류를 확인할 수 있는 것은 아닙니다. 리소스 파일, 코어 버전, 분류 이름을 함께 확인하세요.

cn을 실시간 네트워크 측정 결과로 이해하지 마세요. 데이터 세트는 관리자가 정리하므로 도메인이 특정 분류에 포함되는지, IP 대역이 어느 지역에 속하는지는 버전에 따라 달라질 수 있습니다. 트래픽이 잘못 분기된다면 먼저 실제로 일치한 규칙과 로컬 데이터의 업데이트 시점을 확인한 뒤, 더 앞쪽에 정확한 도메인 규칙을 추가할지 판단하세요.

TUN 강화: 트래픽 가로채기와 모든 트래픽의 프록시 전송은 다릅니다

시스템 프록시는 일반적으로 시스템 프록시 설정을 따르는 앱에만 영향을 줍니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 더 많은 IP 트래픽을 가로챕니다. mihomo의 TUN은 시스템 프록시를 사용하지 않는 프로그램을 처리할 때 유용하지만, 여전히 라우팅, 권한, 규칙의 영향을 받습니다. TUN을 켜도 DIRECT에 일치하는 연결은 직접 연결됩니다.

# 인터넷 연결이 정상인 기존 mihomo 설정에 병합
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1

이 설정은 트래픽 가로채기와 DNS의 연관성만 보여 주며 프록시 노드는 포함하지 않습니다. 1053은 내장 DNS의 수신 포트이고, dns-hijack의 53은 가로챌 기존 DNS 대상 포트입니다. 두 값을 같게 설정할 필요는 없습니다. 예시에 사용된 상위 DNS는 설명용이므로, 실제 환경에서는 연결 가능하고 네트워크 정책에 맞는 DNS 서버로 바꾸세요.

stack과 권한을 각각 점검하세요

  • system, gvisor, mixed는 서로 다른 네트워크 스택 처리 방식을 나타냅니다. mixed는 일반적으로 TCP에 시스템 스택을, UDP에 gVisor를 사용합니다. 사용 가능 여부는 현재 플랫폼과 버전에서 확인해야 합니다.
  • Windows에서는 일반적으로 관리자 권한이나 클라이언트가 설치한 권한 서비스가 필요합니다. Linux에서는 필요한 네트워크 관리 권한을 확인하고 /dev/net/tun도 점검하세요. macOS에서는 클라이언트 안내에 따라 권한을 허용해야 합니다.
  • auto-route는 라우팅 구성을 변경합니다. 다른 VPN, 가상 머신 네트워크, 기업용 접속 도구와 함께 사용할 때는 먼저 다른 트래픽 가로채기 도구를 끄고 비교 테스트하세요.
  • 앱 내장 DoH는 HTTPS를 사용하므로 기존 DNS의 53번 포트를 가로채도 같은 DNS 경로로 자동 전환되지 않습니다.

DNS와 스니핑: 도메인 정보를 보완하지만 프록시 규칙을 대체하지는 않음

Fake-IP는 먼저 도메인에 매핑 주소를 할당하고, 연결이 코어로 들어올 때 도메인 정보를 복원하는 방식입니다. 예시의 198.18.0.1/16은 이 용도로 자주 쓰이는 벤치마크 전용 예약 주소 범위에 속합니다. 이와 같은 DNS 응답을 봤다고 해서 공용 DNS 장애라고 단정해서는 안 됩니다. 연결을 시작한 앱의 트래픽도 같은 코어가 가로채고 있는지 확인하세요.

mihomo의 스니핑 기능은 HTTP Host, TLS SNI 등의 프로토콜 정보에서 도메인을 가져와 IP 주소만 있는 연결도 도메인 규칙에 매칭되도록 도울 수 있습니다. HTTPS를 복호화하는 기능은 아니며 모든 연결에서 도메인을 알아낼 수 있는 것도 아닙니다. 핸드셰이크 정보가 암호화되어 있거나 비표준 프로토콜, 앱별 연결 방식을 사용하는 경우에는 사용할 수 있는 도메인을 얻지 못할 수 있습니다.

sniffer:
  enable: true
  sniff:
    HTTP:
      ports: [80, 8080]
    TLS:
      ports: [443, 8443]

위 예시는 스니핑할 프로토콜과 대상 포트를 지정합니다. 특정 IP에 의존하거나 내부 인증서 도메인을 사용하거나 기능을 켠 뒤 연결 동작이 달라진다면, 먼저 스니핑을 끈 상태와 비교한 다음 현재 버전에서 지원하는 제외 조건으로 범위를 좁히세요. 스니핑을 모든 규칙 미매칭 문제를 해결하는 만능 스위치로 취급하지 마세요.

마이그레이션 순서: 문법 확인, 노드 테스트, 규칙 검증, 마지막에 TUN 활성화

마이그레이션한다고 기존 설정을 전부 다시 작성할 필요는 없습니다. 혼합 포트, 기존 노드, 간단한 규칙을 유지한 채 새 기능을 하나씩 추가하면 문제가 노드 매개변수, 규칙 데이터, 시스템 트래픽 가로채기 중 어디에서 비롯됐는지 구분하기 쉽습니다. 아래 순서는 독립 코어는 물론 GUI 클라이언트 점검에도 적용할 수 있습니다.

  1. 복구 가능한 사본을 저장하세요. 기존 클라이언트, 코어 버전, 설정 출처, 작업 디렉터리를 기록해 두세요. 클라이언트에 구독 오버라이드나 설정 병합 기능이 있다면 해당 내용도 보관하세요.
  2. 설정을 불러올 수 있는지 확인하세요. 아래 테스트 명령을 사용합니다. YAML 문법, 일부 필드, 리소스 로드 문제를 찾을 수 있지만 원격 노드에 반드시 연결된다는 뜻은 아닙니다.
  3. 먼저 프록시 포트를 테스트하세요. mixed-port가 실제로 수신 중인 포트를 확인한 다음 로컬 프록시를 통해 요청을 보냅니다. 아래 예시는 7890을 사용하므로 설정이 다르면 명령도 함께 바꾸세요.
  4. 규칙 매칭을 확인하세요. 연결 기록에서 대상 도메인, 일치한 규칙, 최종 아웃바운드를 확인합니다. GEOSITE나 RULE-SET을 추가한 뒤 같은 대상을 다시 테스트하세요.
  5. 마지막으로 TUN을 테스트하세요. 먼저 시스템 프록시 경로가 정상인지 확인한 뒤 TUN을 켜세요. 브라우저, 시스템 프록시를 사용하지 않는 앱, 로컬 네트워크 접속, DNS 확인을 각각 테스트합니다.
mihomo -v
mihomo -t -d ./mihomo-data -f ./config.yaml
curl -I --proxy http://127.0.0.1:7890 https://example.com/

기본 설정에서 상대 경로를 참조한다면 테스트 시 -d에 지정하는 경로가 예상 작업 디렉터리와 일치해야 하며, 규칙 파일도 미리 준비해야 합니다. 테스트 명령이 통과한 뒤에는 클라이언트가 코어에 실제로 전달하는 설정도 확인하세요. 일부 클라이언트는 구독, 오버라이드, UI 설정을 병합한 뒤 실행하므로 디스크에 저장된 구독 원문이 실제 적용 설정과 다를 수 있습니다.

오류 유형별 점검 경로 세 가지

  • 지원하지 않는 프록시 유형: 먼저 코어 이름과 버전을 확인한 뒤 구독이 mihomo 호환 형식으로 출력되는지 확인하세요. DNS부터 바꾸지 마세요.
  • 규칙 세트 또는 GEO 데이터 로드 실패: 경로, 파일 형식, 접근 권한, 다운로드 연결 상태를 확인하세요. 문제를 덮으려고 모든 트래픽 분기 규칙을 삭제하지 마세요.
  • 프록시는 되지만 TUN은 안 됨: 권한, 기본 네트워크 인터페이스, 충돌하는 라우팅, DNS 가로채기를 확인하세요. 이를 근거로 원격 노드가 고장 났다고 판단하지 마세요.

클라이언트와 설치 방법은 다운로드 센터에서 확인하고, 구독을 처음 가져오는 방법은 사용 가이드를 참고하세요. DNS, 프록시 그룹, TUN 필드를 더 자세히 확인하려면 설정 종합 가이드에서 항목별로 살펴볼 수 있습니다.

클라이언트 다운로드