mihomo 코어와 클래식 Clash 비교: 추가 프로토콜, 룰셋, TUN 개선

클라이언트·코어·설정을 먼저 구분하기

“구독은 가져왔는데 노드가 작동하지 않는다”고 해서 바로 구독을 바꾸지는 마세요. GUI 클라이언트는 구독 관리와 화면 표시, 시스템 설정을 담당하고, 코어는 설정을 해석해 프록시 연결을 만들고 트래픽을 분기합니다. 화면에 노드 이름이 표시된다고 해서 백그라운드 코어가 해당 프로토콜을 지원하는 것은 아닙니다. 문제를 확인할 때는 클라이언트 창의 버전 번호만 보지 말고 로그에서 실제 코어 이름과 버전을 확인하세요.

mihomo는 기존 Clash Meta 프로젝트가 이름을 바꾼 코어로, Clash 설정 체계를 이어받아 기능을 확장하고 있습니다. ‘클래식 Clash’를 이야기할 때는 과거의 오픈소스 코어와 비공개 Premium 코어를 구분해야 합니다. 두 코어의 기능은 완전히 같지 않으며, 특히 룰 프로바이더와 TUN 기능에 차이가 있습니다. 이를 구분하지 않으면 ‘옛날 Clash에는 룰셋이 전혀 없었다’와 같은 잘못된 결론에 이르기 쉽습니다.

비교 대상	확인해야 할 범위	마이그레이션 시 영향
클래식 오픈소스 Clash	과거 오픈소스 브랜치의 프로토콜 및 설정 기능	mihomo의 필드 구성을 그대로 적용할 수 없음
Clash Premium	과거 비공개 확장판으로, 룰셋과 TUN 등의 기능을 제공	일부 기능은 개념이 비슷하지만 필드와 동작을 다시 확인해야 함
mihomo	기존 Clash Meta로, 프로토콜·규칙·네트워크 제어 기능을 확장	널리 쓰이는 설정 문법을 다수 유지하지만, 모든 기존 설정이 그대로 작동하는 것은 아님

독립 코어를 직접 실행한다면 mihomo -v로 버전을 확인할 수 있습니다. GUI 클라이언트에서는 코어 정보나 시작 로그에서 실제로 불러온 실행 파일을 확인하세요. GUI 프로그램을 업그레이드해도 코어가 원하는 버전으로 바뀌었다고 단정할 수는 없습니다.

추가 프로토콜: 노드 사용 가능 여부를 가르는 첫 번째 기준

과거 클래식 Clash와 비교했을 때 mihomo의 주요 변화 중 하나는 VLESS, Hysteria2, TUIC 등 더 많은 프록시 프로토콜과 전송 방식 조합을 지원한다는 점입니다. 이들은 같은 프로토콜의 다른 이름이 아니며 설정의 type만 바꾼다고 서로 전환되지 않습니다. 서버에서 사용하는 프로토콜에 맞춰 인증, 전송 방식, TLS 매개변수를 설정해야 합니다.

VLESS와 REALITY는 별개로 확인하기

VLESS는 프록시 프로토콜이고 REALITY는 관련 연결에서 사용할 수 있는 보안 방식이므로 서로 같은 의미가 아닙니다. VLESS 노드는 일반 TLS를 사용할 수도 있고 REALITY를 사용할 수도 있습니다. 조합에 따라 network, servername, flow, reality-opts 등의 필드가 필요할 수 있습니다. 서버에 설정된 매개변수를 확인해 입력하고, VLESS라는 이유만으로 REALITY 설정을 임의로 추가하지 마세요.

UUID: VLESS 사용자 인증에 쓰입니다. 다른 프로토콜의 비밀번호로 대신할 수 없습니다.
서버 이름: servername은 TLS 핸드셰이크와 관련된 값으로, 잘못 입력하면 인증서나 핸드셰이크 오류가 발생할 수 있습니다.
REALITY 매개변수: 공개 키와 짧은 ID 등은 서버 설정과 일치해야 합니다. 노드 이름이 같다고 해서 매개변수까지 같은 것은 아닙니다.
전송 방식: TCP, WebSocket, gRPC 등의 설정은 양쪽이 일치해야 합니다. 한쪽 필드만 바꾸면 연결되지 않습니다.

Hysteria2와 TUIC는 UDP 경로가 필요합니다

Hysteria2와 TUIC는 QUIC 기반 전송을 사용하므로 서버에 연결할 수 있는 UDP 경로가 필요합니다. 현재 네트워크에서 UDP가 제한된다면 일반 HTTPS 웹페이지가 열린다고 해서 이 노드도 연결된다는 뜻은 아닙니다. 이때는 규칙 모드를 반복해서 바꾸기보다 로그에서 시간 초과, 인증, TLS 오류를 확인하세요.

Hysteria 1세대와 Hysteria2도 서로 바꿔 쓸 수 없습니다. 구독 변환 과정에서 2세대 노드가 1세대 유형으로 출력되거나 필수 인증 매개변수가 누락되면 정책 그룹을 바꿔도 해결되지 않습니다. 가장 확실한 방법은 구독 서비스가 명시적으로 제공하는 mihomo 호환 설정을 선택하고, 변환된 노드 유형을 확인하는 것입니다.

룰셋: 규칙 재사용과 매칭 순서 제어

rule-providers를 사용하면 여러 규칙을 별도 리소스로 관리하고, 메인 규칙에서 RULE-SET으로 불러올 수 있습니다. mihomo에서 처음 도입한 기능은 아니며, 과거 Clash Premium에도 이에 해당하는 기능이 있었습니다. mihomo는 이 체계를 바탕으로 형식과 매칭 기능을 계속 확장하고 있으며, 실제 사용 가능한 필드는 실행 중인 코어 버전에 따라 달라집니다.

세 가지 규칙 동작부터 구분하기

domain: 도메인 항목을 대상으로 합니다. DOMAIN-SUFFIX,example.org처럼 유형이 붙은 전체 규칙을 일반 도메인으로 넣지 마세요.
ipcidr: IP 대역을 대상으로 합니다. 예: 192.168.0.0/16.
classical: 규칙 유형이 포함된 항목을 사용합니다. 예: DOMAIN-SUFFIX,example.org.

다음은 프록시 노드가 포함되지 않은 로컬 룰셋 예시입니다. 첫 번째 내용을 기존 설정에 합치고, 경로는 코어의 실제 작업 디렉터리를 기준으로 지정하세요. 해당 디렉터리에 두 번째 예시의 파일도 있어야 합니다. 이 예시는 파일 간 참조 방식만 보여 주며, 전체 구독 설정을 대체할 수는 없습니다.

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

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,DIRECT

rules/local-direct.yaml의 내용입니다. 두 항목은 각각 예시용 예약 도메인과 사설 IP 대역을 매칭합니다:

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

실제 마이그레이션에서는 최종 정책을 유지해야 합니다. 예시의 MATCH,DIRECT를 그대로 복사하고 트래픽이 프록시를 거칠 것으로 기대해서는 안 됩니다. 규칙은 일반적으로 위에서 아래로 매칭되므로, 범위가 넓은 직접 연결 규칙을 앞에 두면 뒤에 있는 프록시 규칙이 적용되지 않습니다. 참조하는 정책 그룹도 실제로 존재해야 하며 대소문자와 공백까지 일치해야 합니다.

룰셋 형식은 임의로 바꿔 쓸 수 없습니다

mihomo에서 지원하는 MRS 바이너리 룰셋은 적용 범위가 정해져 있으며, 주로 domain 및 ipcidr 동작에 사용됩니다. 아무 classical 파일이나 확장자만 바꿔 사용할 수는 없습니다. 원격 룰셋의 interval 단위는 초입니다. 예를 들어 86400은 하루를 뜻합니다. 이는 룰 리소스의 업데이트 주기이며 클라이언트 구독 프로필의 새로고침 주기와는 다릅니다.

TUN 개선: 더 넓은 트래픽을 제어하고 늘어나는 문제 해결 단계

시스템 프록시는 프록시 설정을 따르는 앱에 주로 영향을 줍니다. TUN은 가상 네트워크 인터페이스와 라우팅을 이용해 더 많은 IP 트래픽을 제어하므로 시스템 프록시를 따르지 않는 프로그램을 처리하는 데 유용합니다. 과거 Premium에도 TUN이 있었으므로 ‘구버전에는 없고 신버전에만 있다’고 단순화해서는 안 됩니다. mihomo의 주요 차이는 지속적으로 관리되는 TUN 구현, 네트워크 스택 선택, 라우팅 및 DNS와 연동되는 설정 기능에 있습니다.

스택·라우팅·DNS는 각각 다른 기능입니다

설정 항목	주요 기능	확인할 점
`tun.stack`	system, gvisor, mixed 등 지원되는 처리 방식을 선택합니다	실행 중인 코어와 시스템의 지원 여부를 기준으로 확인하고, 이름만 보고 속도를 판단하지 마세요
`tun.auto-route`	TUN으로 트래픽이 들어오도록 라우팅을 자동 설정합니다	기존 VPN, 컨테이너 네트워크, 사용자 지정 라우팅과 충돌하는지 확인합니다
`tun.auto-detect-interface`	외부 인터페이스를 자동으로 감지합니다	네트워크 카드가 여러 개이거나 네트워크를 전환할 때 올바른 인터페이스를 선택하는지 확인합니다
`tun.dns-hijack`	조건에 맞는 기존 DNS 요청을 가로챕니다	이 설정만으로 앱 내부의 DoH 요청까지 자동으로 가로챈다고 볼 수는 없습니다

Linux에서 TUN 장치를 만들고 라우팅을 변경하려면 필요한 권한이 있어야 합니다. GUI 클라이언트는 설치된 권한 서비스로 작업을 처리할 수 있지만, 독립 코어는 권한과 서비스 관리를 직접 해야 합니다. 권한 오류가 발생하면 노드 전환을 반복하기보다 서비스 상태와 로그, /dev/net/tun 사용 가능 여부부터 확인하세요.

아래는 일반적인 TUN 설정 예시입니다. 기존 DNS, 노드, 규칙 설정에 추가한 뒤 테스트하세요. 완전한 DNS 리스너 설정은 포함되어 있지 않으며, 모든 기기에서 자동 라우팅을 바로 활성화해도 된다는 뜻은 아닙니다.

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

설정 호환성: 구문 분석 성공이 동일한 동작을 뜻하지는 않습니다

proxies, proxy-groups, rules 등의 구조는 여전히 익숙하지만, 설정을 한 번 복사하는 것만으로 마이그레이션이 끝나지는 않습니다. 기존 필드의 권장 작성 방식이 바뀌었을 수 있고, 새 필드는 구형 코어에서 거부되거나 무시될 수 있습니다. 구문 검사를 통과하더라도 DNS, 정책 그룹 선택, 프로세스 매칭 결과를 실제로 확인해야 합니다.

파일을 먼저 검증한 다음 트래픽을 가로채세요

mihomo -v
mihomo -t -f ./config.yaml

두 번째 명령은 설정을 검사하는 용도이지, 네트워크 연결을 완전히 테스트하는 명령이 아닙니다. 검사를 통과한 뒤에도 노드 핸드셰이크, DNS 조회, 트래픽 분기 결과를 확인해야 합니다. GUI 클라이언트는 시작 전에 구독 설정을 병합하거나 덮어쓸 수 있습니다. 직접 확인한 원본 YAML과 코어에 전달되는 최종 실행 설정이 서로 다를 수도 있습니다.

수신 포트 확인: 예를 들어 mixed-port: 7890을 사용할 예정이라면 브라우저나 시스템 프록시도 이전 설정의 다른 포트가 아니라 로컬 7890을 가리키는지 확인하세요.
컨트롤러 확인: external-controller는 프록시 포트와 용도가 다릅니다. 127.0.0.1:9090을 사용하는 경우 9090은 관리 인터페이스 포트이지 브라우저 인터넷 연결용 HTTP 프록시 포트가 아닙니다.
구독 내용 확인: 노드 목록만 포함된 구독에는 정책 그룹, DNS, 규칙이 없을 수 있습니다. 클라이언트가 이 설정을 어떻게 보완하는지는 설정 병합 방식을 확인하세요.
로컬 덮어쓰기 확인: 사용자 지정 규칙, 포트, DNS는 클라이언트에서 제공하는 지속성 있는 덮어쓰기 기능에 넣으세요. 원격 구독 파일을 직접 수정하면 새로고침 때 덮어써질 수 있습니다.

DNS와 프로세스 규칙은 각각 검증하기

fake-ip와 redir-host는 DNS 처리 모드이지 프록시 모드가 아닙니다. 코어를 바꾸면서 DNS 모드, 업스트림 서버, TUN 설정을 동시에 변경하면 어느 단계에서 문제가 생겼는지 파악하기 어렵습니다. 우선 기존 DNS 구성을 유지해 기본 연결을 확인한 뒤 하나씩 조정하세요.

프로세스 이름이나 경로를 이용하는 규칙은 시스템 지원 여부, 코어 권한, 연결 정보를 올바르게 가져올 수 있는지에 따라 동작합니다. 규칙을 정확히 작성해도 프로세스를 식별하지 못하면 매칭되지 않을 수 있습니다. 연결 기록에서 프로세스 정보와 적용된 규칙을 확인하세요. 매칭 실패를 모두 규칙 순서 탓으로 돌려서는 안 됩니다.

마이그레이션 검증: 한 번에 변수 하나씩 변경하기

마이그레이션의 목적은 새로 사용할 수 있게 된 기능과 기존 설정이 예상대로 작동하는지를 확인하는 것입니다. 아래 순서대로 단계마다 결과를 기록하고 다음으로 넘어가세요. 모든 확장 기능을 한꺼번에 켜는 것보다 문제를 찾기 쉽습니다.

백업: 기존 프로필, 로컬 규칙, 덮어쓰기 설정, 현재 사용 중인 포트와 DNS 설정을 저장하세요. 구독 주소에 접속 정보가 포함될 수 있으므로 전체 주소를 공개 로그에 붙여 넣지 마세요.
기본 프록시: 먼저 TUN을 끄고, 사용 가능 여부가 확인된 노드로 로컬 7890 프록시를 테스트해 프로토콜 및 인증 오류를 점검하세요.
규칙 검증: 직접 연결되어야 하는 사이트와 프록시를 거쳐야 하는 사이트에 각각 접속하고, 웹페이지가 열리는지만 보지 말고 연결 기록에서 적용된 규칙과 최종 정책을 확인하세요.
룰셋 로드: 프로바이더의 로드 상태를 확인하세요. 파일 경로 오류, 다운로드 실패, 항목 형식 오류는 서로 다른 문제이므로 로그에 따라 각각 해결해야 합니다.
TUN 연결 제어: 마지막으로 TUN을 활성화하고 시스템 프록시를 따르지 않는 앱을 테스트하세요. 로컬 네트워크 접속, 다른 VPN, 네트워크 전환도 확인해야 합니다.
구독 새로고침: 한 번 직접 새로고침해 사용자 지정 설정이 유지되는지 확인한 다음 자동 업데이트를 설정하세요.

마이그레이션할지는 실제 필요에 따라 판단하면 됩니다. 구독에 VLESS·Hysteria2 노드가 포함되어 있거나 더 세밀한 규칙과 지속적으로 관리되는 TUN 기능이 필요하다면 mihomo로 전환할 이유가 분명합니다. 현재 연결에 문제가 있다면 노드 장애, 설정 오류, 시스템 네트워크 충돌부터 구분해야 합니다. 코어를 바꾸면 기능 부족은 해결할 수 있지만 서버 매개변수와 로컬 라우팅 확인까지 대신해 주지는 않습니다.

필드와 규칙에 관한 자세한 내용은 코어 및 설정 참고 가이드에서 확인하세요. 가상 인터페이스를 처음 설정한다면 TUN 모드 가이드를 참고해 권한과 트래픽 제어 범위를 하나씩 점검하세요.