mihomo 코어와 원본 Clash 비교: 추가 프로토콜, rule-providers 및 TUN 기능

원본 오픈소스 코어, Premium, mihomo를 구분해서 보기

결론부터 말하면, mihomo는 Clash 설정 체계를 계승했지만 이름만 바뀐 동일한 바이너리로 볼 수는 없습니다. mihomo는 Clash.Meta의 개발 방향을 이어받아 프로토콜, 규칙, 트래픽 처리 기능을 확장했습니다. 마이그레이션할 때 기본 필드는 대체로 유지할 수 있지만, 새 설정을 구형 코어에서 다시 읽을 수 있다고 보장할 수는 없습니다.

‘원본 Clash’도 두 가지로 나눠 봐야 합니다. 원본 오픈소스 코어와 당시의 Clash Premium입니다. Premium은 규칙 세트와 TUN 등의 확장 기능을 제공했습니다. 둘을 하나로 묶어 ‘Clash는 rule-providers를 지원하지 않고 TUN은 mihomo만 지원한다’고 설명하면 정확하지 않습니다.

클라이언트: 인터페이스, 구독 관리, 시스템 프록시 전환을 담당하고 코어를 실행합니다. 클라이언트 버전과 코어 버전은 서로 다릅니다.
코어: 설정을 읽고 프록시 연결을 만들며 DNS를 해석하고 규칙을 적용합니다. 실제로 어떤 필드를 지원하는지는 실행 중인 코어에 달려 있습니다.
구독 변환: 대상 코어에 맞춰 노드 필드를 다르게 생성할 수 있습니다. 변환기는 출력 구조를 바꿀 수 있지만, 구형 코어에 새 프로토콜 구현을 추가해 주지는 않습니다.

먼저 클라이언트의 코어 정보나 시작 로그에서 코어 이름을 확인한 뒤 실제 실행 파일을 살펴보세요. 아래 명령은 독립 실행형 바이너리용입니다. GUI 클라이언트에 내장된 파일은 이름이 다를 수 있으니, 이를 이유로 코어를 하나 더 실행하지 마세요.

mihomo -v
clash -v

프로토콜 지원 비교: 노드를 가져올 수 있다고 연결까지 되는 것은 아닙니다

Shadowsocks, VMess, Trojan 등은 두 개발 계열에서 모두 흔히 지원하는 프로토콜입니다. mihomo는 VLESS, Hysteria2, TUIC 등을 추가로 지원합니다. 구체적인 전송 방식 조합과 매개변수는 현재 코어의 문서에서 확인해야 합니다. 과거 원본 빌드마다 차이가 있으므로 특정 구버전의 결과를 모든 빌드에 일반화해서는 안 됩니다.

기능	원본 오픈소스 Clash	Clash Premium	mihomo
SS、VMess、Trojan	일반적인 설정 지원	일반적인 설정 지원	지원하며 확장 매개변수 제공
VLESS, REALITY 관련 설정	지원 대상으로 보기 어려움	지원 대상으로 보기 어려움	해당 프로토콜 조합 지원
Hysteria2、TUIC	지원 안 함	지원 안 함	지원
rule-providers	Premium의 해당 기능은 지원하지 않음	지원	지원하며 형식과 사용법 확장
코어 TUN 인바운드	Premium의 TUN 기능 미제공	지원 여부는 플랫폼 및 빌드에 따라 다름	지원 여부는 플랫폼 및 권한에 따라 다름
sniffer 설정 가능	mihomo와 같은 이름의 설정 체계는 지원하지 않음	mihomo와 같은 이름의 설정 체계는 지원하지 않음	HTTP, TLS, QUIC 스니핑 설정 지원

마이그레이션 시 노드의 전송 계층 매개변수 확인

프로토콜 유형: 먼저 type을 확인하세요. 예를 들면 vless 또는 hysteria2입니다. 코어가 해당 유형을 인식하지 못하면 코어를 바꾸거나 구독 출력 대상을 변경해야 합니다.
인증 정보: 비밀번호, UUID, 인증 필드를 확인하세요. VMess 노드를 VLESS 유형으로 바꾸는 것만으로는 변환되지 않습니다.
전송 방식: WebSocket, gRPC 등의 전송 설정이 서버와 일치하는지 확인하세요. 특히 경로, Host, 서비스 이름을 점검해야 합니다.
TLS 매개변수: 서버 이름, 인증서 검증 설정, REALITY 매개변수를 확인하세요. 인증서 검증을 끄는 방식으로 문제를 피하려고 하지 마세요.

Hysteria2와 TUIC는 QUIC 기반 전송을 사용하므로 네트워크에서 해당 UDP 통신을 허용해야 합니다. 설정 테스트 통과는 필드를 읽을 수 있다는 의미일 뿐입니다. 외부 네트워크에서 UDP를 제한하면 연결은 여전히 실패할 수 있습니다. 코어를 바꿔도 네트워크 측 제한은 달라지지 않습니다.

rule-providers: 먼저 behavior를 확인하고 파일 형식을 점검하세요

rule-providers는 규칙 세트를 불러오는 기능이지 노드 구독이 아닙니다. 노드 공급자는 proxy-providers를 사용합니다. 규칙 세트를 선언한 다음에는 rules에서 RULE-SET으로 참조해야 실제 매칭에 적용됩니다.

Premium에서 mihomo로 옮길 때 기존의 일반 YAML 규칙 세트는 대체로 그대로 사용할 수 있습니다. 핵심은 behavior와 파일 내용이 일치하는지 확인하는 것입니다. classical에는 완전한 규칙 표현식을, domain에는 도메인 매칭 항목을, ipcidr에는 IP 대역을 넣습니다. 선언만 바꾸고 세 형식의 내용을 섞어서는 안 됩니다.

로컬 classical 규칙 세트 예시

아래 내용을 기존 기본 설정에 병합하세요. Proxy는 예시 정책 그룹 이름이므로 실제로 존재하는 그룹 이름으로 바꾸거나 기존 설정에 그룹을 정의해야 합니다. 경로는 코어의 작업 디렉터리를 기준으로 하며 GUI 클라이언트의 설치 디렉터리를 기준으로 하지 않을 수 있습니다.

rule-providers:
  local-sites:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-sites.yaml

rules:
  - RULE-SET,local-sites,Proxy
  - MATCH,DIRECT

rules/local-sites.yaml 파일을 만들고 다음 내용을 입력하세요. example.com은 예시 도메인이므로 실제 사용 시 트래픽을 분기할 도메인으로 바꾸세요.

payload:
  - DOMAIN-SUFFIX,example.com
  - IP-CIDR,192.168.0.0/16,no-resolve

format: yaml 형식의 규칙 파일에는 payload가 포함됩니다. 일반 텍스트 형식은 해당 형식의 요구사항에 따라 항목을 한 줄씩 작성해야 하며 YAML 외피를 씌우면 안 됩니다.
mihomo의 mrs는 바이너리 규칙 세트 형식으로, domain과 ipcidr에 사용할 수 있습니다. 임의의 classical 파일의 확장자만 바꿔서는 사용할 수 없습니다.
HTTP 유형 공급자는 실제로 접근 가능한 url도 필요합니다. 여기서 interval: 86400은 업데이트 간격이 86400초라는 뜻이지 연결 제한 시간이 아닙니다.
규칙은 여전히 위에서 아래 순서로 매칭됩니다. 범위가 넓은 규칙을 앞에 두면 뒤의 세부 규칙이 적용되지 않을 수 있습니다. MATCH는 보통 마지막에 둡니다.

도메인 스니핑: 도메인 정보를 보완할 뿐 HTTPS를 복호화하지는 않습니다

IP 연결에는 도메인 규칙에 바로 사용할 수 있는 대상 이름이 포함되지 않을 수 있습니다. mihomo의 sniffer는 HTTP Host, TLS 핸드셰이크의 서버 이름, 인식 가능한 QUIC 핸드셰이크 정보에서 도메인을 추출해 트래픽 분기를 돕습니다. HTTPS를 복호화하는 기능은 아니며, 모든 연결에서 도메인을 알아낼 수 있는 것도 아닙니다.

아래는 mihomo 스니핑 설정 예시입니다. 먼저 override-destination: false를 유지한 채 규칙 매칭을 확인하고, 연결 대상을 덮어써야 하는지 판단하세요. 모든 설정에서 반드시 활성화해야 하는 옵션은 아닙니다.

sniffer:
  enable: true
  override-destination: false
  sniff:
    HTTP:
      ports: [80, 8080-8880]
    TLS:
      ports: [443, 8443]
    QUIC:
      ports: [443, 8443]

스니핑과 Fake-IP의 차이

Fake-IP는 DNS를 통해 도메인과 가상 IP의 대응 관계를 저장하고, 스니핑은 연결 내용에서 도메인을 추출하려고 합니다. 두 기능은 서로 다른 정보를 이용합니다.
프로그램에 IP가 하드코딩되어 있거나 인식할 수 없는 프로토콜을 사용하거나 핸드셰이크 정보가 암호화되어 있으면, 스니핑으로 유효한 도메인을 얻지 못할 수 있습니다.
도메인 규칙이 필요한데 대상 IP만 보인다면 스니핑 범위를 바로 넓히기보다 먼저 DNS를 코어가 처리하는지, 매핑이 유효한지 확인한 다음 스니핑을 점검하세요.

마이그레이션 후 일부 사이트에서만 문제가 생기면 스니핑을 잠시 끄고 비교해 볼 수 있습니다. 한 번에 설정 하나만 바꾸고 연결 상세 정보의 대상 도메인, 적용된 규칙, 출구 정책을 확인하세요. 그래야 스니핑, DNS, 노드 문제를 혼동하지 않습니다.

TUN 기능: 프로토콜 스택, 라우팅, DNS 처리 여부를 따로 확인

TUN은 트래픽을 가상 네트워크 인터페이스로 보냅니다. 시스템 HTTP 프록시와는 다릅니다. 시스템 프록시 설정을 따르지 않는 프로그램도 라우팅을 통해 TUN으로 들어올 수 있습니다. 원본 Premium에도 TUN이 있었고 mihomo는 이 기능을 계속 확장해 왔으므로, ‘TUN 지원’ 자체를 mihomo만의 기능으로 보면 안 됩니다.

mihomo의 TUN 설정에서는 system, gvisor, mixed 등의 스택을 선택할 수 있으며, 사용 가능 여부는 플랫폼과 빌드에 따라 다릅니다. mixed는 시스템 TCP 스택과 gVisor UDP 스택을 함께 사용합니다. 스택 이름은 속도 순위가 아닙니다. 문제가 생기면 같은 네트워크와 노드에서 비교하세요.

최소 TUN 테스트 설정

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

아래는 기존 설정에 병합할 TUN 설정 일부이며, 유효한 dns 설정도 필요합니다. auto-route는 라우트를 자동 설정하고, auto-detect-interface는 출구 인터페이스를 자동으로 식별합니다. VPN이나 가상 네트워크 어댑터를 여러 개 함께 사용한다면 자동 식별 결과를 확인해야 합니다.

먼저 권한 확인: Windows에서는 보통 클라이언트 서비스나 관리자 권한으로 가상 인터페이스를 설정합니다. Linux에서는 필요한 네트워크 관리 권한이 있어야 합니다. 권한 오류를 노드 문제로 오해하지 마세요.
다음으로 라우팅 확인: 가상 인터페이스가 생성되었고 대상 트래픽이 실제로 코어에 들어오는지 확인하세요. 로그에 연결 기록이 전혀 없다면 우선 트래픽 처리 경로를 점검해야 합니다.
DNS는 따로 확인: any:53은 트래픽 처리 경로로 들어오는 일반적인 53번 포트 DNS를 대상으로 합니다. 브라우저 자체 DoH는 HTTPS를 사용하므로 이 설정만으로 자동으로 코어 DNS 조회로 바뀌지 않습니다.
마지막으로 UDP 테스트: 노드 프로토콜, 서버, 출구 네트워크, 클라이언트 프로그램 모두 UDP에 영향을 줄 수 있습니다. 웹페이지가 열린다고 게임이나 음성 통신도 정상이라는 뜻은 아닙니다.

기존 설정 마이그레이션: 단계별로 적용하고 롤백 경로 확보하기

가장 안전한 순서는 설정 파싱을 확인하고, 일반 프록시를 테스트한 다음, DNS·규칙 세트·TUN을 차례로 활성화하는 것입니다. 코어를 바로 교체하고 새 기능을 모두 켜면 실패 원인을 찾기 어렵습니다.

1단계: 실제 적용되는 설정 테스트

아래 명령은 config.yaml을 검사합니다. 클라이언트에서 덮어쓰기, 스크립트 또는 설정 병합을 사용한다면 구독에서 내려받은 원본 파일이 아니라 최종 생성된 실행 설정을 검사해야 합니다.

mihomo -t -f config.yaml

알 수 없는 프록시 유형이 나오면 구독 대상이 mihomo인지 확인하세요. 정책 그룹을 찾을 수 없다는 오류가 나오면 규칙 참조와 정책 그룹 이름을 점검하세요. 규칙 세트를 읽지 못하면 작업 디렉터리, 파일 경로, 형식을 확인하세요. 테스트 통과만으로 노드 인증, 네트워크 연결, 원격 규칙 세트 업데이트까지 성공했다고 볼 수는 없습니다.

2단계: 일반 프록시로 기준 상태 확인

먼저 TUN은 끄고 기존 설정의 mixed-port를 사용하세요. 값을 7890으로 설정했다면 아래 요청을 실행할 수 있습니다. HTTP 프록시를 명시해 시스템 프록시 스위치의 영향을 배제합니다.

curl -I --proxy http://127.0.0.1:7890 https://example.com

응답이 돌아오는지, 연결 로그가 남는지, 어떤 규칙이 적용됐는지 함께 확인하세요. 이 테스트는 현재 HTTP 프록시 경로만 확인하며 UDP나 모든 앱의 트래픽 처리 여부를 검증하지는 않습니다. 포트를 구형 프로세스가 사용 중이라면 구형 코어를 먼저 종료하세요. 여러 포트를 동시에 실행하도록 임의로 변경하지 마세요.

3단계: 강화 설정을 하나씩 복구

규칙 세트를 복구하고 각 RULE-SET 참조와 다운로드 상태를 확인하세요.
DNS 설정을 복구한 뒤 enhanced-mode, nameserver, nameserver-policy의 실제 해석 경로를 확인하세요.
필요한 경우 스니핑을 활성화하고 대상 도메인 및 적용된 규칙을 비교하세요.
마지막으로 TUN을 활성화하고 인터페이스, 라우팅, DNS, UDP를 확인하세요.

구형 코어가 읽을 수 있는 설정 사본을 보관하세요. 롤백할 때는 바이너리뿐 아니라 해당 코어에 맞는 규칙 세트 형식과 필드도 복구해야 합니다. 새 코어가 생성한 설정으로 유일한 구형 설정 백업을 덮어쓰지 마세요.

선택 기준과 참고 자료

기존 설정이 기본 프로토콜과 일반 규칙만 사용한다면 유지 관리 상태, 플랫폼 지원, 클라이언트 통합을 중심으로 마이그레이션을 검토하세요. VLESS, Hysteria2, TUIC, mrs 또는 세밀한 스니핑 설정이 필요하다면 mihomo를 명확히 채택하고 필요한 기능을 제공하는 클라이언트를 선택해야 합니다. 클라이언트 인터페이스에 버튼이 보여도 현재 선택된 코어가 해당 기능을 실행할 수 있다는 뜻은 아닙니다.

이 문서는 기능 범위를 기준으로 비교하며 특정 릴리스의 동작을 영구적인 결론으로 간주하지 않습니다. 플랫폼 제한, 필드 기본값, 새 프로토콜 매개변수는 실제 설치 버전과 해당 문서를 기준으로 확인하세요. 아래 자료는 프로젝트 정보, 필드 정의, 변경 이력을 확인하는 데 사용할 수 있습니다.

mihomo 프로젝트 저장소: 프로젝트 소개, 소스 코드, 이슈 추적.
mihomo 규칙 세트 설정 문서: 공급자 유형, behavior, 파일 형식.
mihomo TUN 설정 문서: 스택, 라우팅, 플랫폼별 옵션.
mihomo 도메인 스니핑 문서: 지원 프로토콜 범위와 대상 덮어쓰기 설정.
mihomo 릴리스 기록: 현재 설치된 버전에 맞춰 수정 사항과 동작 변화를 확인하세요.

전체 설정 구조를 더 확인하려면 사이트의 고급 설정을 참고하세요. 처음 설치하고 구독을 가져오는 방법은 튜토리얼을 확인하면 됩니다. 마이그레이션은 ‘설정 파싱 성공, 노드 연결 성공, 규칙 정상 적용, 트래픽 처리 범위가 예상과 일치’하는지 네 가지로 검증하세요.

원본 오픈소스 코어, Premium, mihomo를 구분해서 보기

프로토콜 지원 비교: 노드를 가져올 수 있다고 연결까지 되는 것은 아닙니다

마이그레이션 시 노드의 전송 계층 매개변수 확인

rule-providers: 먼저 behavior를 확인하고 파일 형식을 점검하세요

로컬 classical 규칙 세트 예시

도메인 스니핑: 도메인 정보를 보완할 뿐 HTTPS를 복호화하지는 않습니다

스니핑과 Fake-IP의 차이

TUN 기능: 프로토콜 스택, 라우팅, DNS 처리 여부를 따로 확인

최소 TUN 테스트 설정

기존 설정 마이그레이션: 단계별로 적용하고 롤백 경로 확보하기

1단계: 실제 적용되는 설정 테스트

2단계: 일반 프록시로 기준 상태 확인

3단계: 강화 설정을 하나씩 복구

선택 기준과 참고 자료

Clash 클라이언트 다운로드