mihomo 코어와 원본 Clash의 차이: 기능, 설정 호환성 및 선택 가이드

비교 범위: 코어, 클라이언트 및 설정 파일

Clash와 mihomo의 차이를 살펴볼 때는 먼저 ‘코어’와 ‘클라이언트’를 구분해야 합니다. 코어는 YAML을 읽고, 프록시 연결을 수립하며, DNS를 조회하고, 규칙을 매칭하고, 로컬 리스닝 포트를 엽니다. 데스크톱 또는 모바일 클라이언트는 구독 관리, 시스템 프록시 전환, 로그 확인, 설정 편집, 서비스 설치 등의 화면을 제공합니다. 클라이언트가 mihomo 코어를 사용한다고 해서 모든 설정이 주 설정 파일에 기록되는 것은 아닙니다. 반대로 설정에 특정 필드가 있다고 해서 클라이언트 화면에 해당 스위치가 반드시 제공되는 것도 아닙니다.

이 글에서 말하는 ‘원본 Clash’는 주로 Dreamacro 프로젝트에서 형성된 고전적인 오픈 소스 코어와 그에 기반한 일반 설정을 뜻합니다. 과거에는 기능이 서로 다른 Premium 빌드도 존재했으므로, Clash라는 이름을 사용했던 모든 버전을 동일한 기능 세트로 묶어서는 안 됩니다. mihomo는 Clash Meta에서 이어진 코어 분기에서 출발했으며, 기존 설정 구조를 바탕으로 프록시 프로토콜, 규칙 유형, DNS 동작, TUN 인계 방식 및 외부 리소스 관리 기능을 확장했습니다.

두 코어의 공통 기반은 여전히 뚜렷합니다. 설정은 보통 YAML을 사용하고, 프록시 노드는 proxies, 정책 그룹은 proxy-groups, 분기 규칙은 rules에 작성하며, 실행 모드는 mode로 제어합니다. mixed-port, allow-lan, log-level, external-controller 같은 필드도 용도가 비슷하게 이어집니다. 기본 구조가 유사하기 때문에 많은 기존 설정을 mihomo가 읽을 수 있지만, ‘실행된다’는 것이 ‘동작이 완전히 같다’는 뜻은 아닙니다.

핵심 기능 차이: 프로토콜부터 트래픽 인계까지

기존 Clash 설정은 주로 HTTP, SOCKS5, Shadowsocks, VMess, Trojan, Snell 등의 프록시 유형을 중심으로 구성됩니다. mihomo는 이러한 유형을 유지하면서 VLESS, TUIC, Hysteria2, WireGuard 등을 추가하거나 개선했으며, 일부 프로토콜에 더 세밀한 전송 계층, TLS 지문, UDP 및 멀티플렉싱 매개변수를 제공합니다. 구독에 이미 이러한 최신 유형이 포함되어 있다면, 기존 코어에서는 해당 프로토콜 구현 자체가 없기 때문에 필드 이름만 바꿔 연결할 수 없는 경우가 많습니다.

트래픽 식별도 차이가 집중되는 영역입니다. mihomo는 설정에 따라 프로토콜 스니핑을 활성화하고, 실제 접속 도메인을 활용해 대상 IP만 포함된 연결을 처리할 수 있습니다. 또한 프로세스 이름, 프로세스 경로, 인바운드 유형, 네트워크 유형 및 대상 포트와 결합해 트래픽을 분기할 수 있습니다. 이러한 기능은 TUN 인계, 투명 프록시 또는 앱별 트래픽 분리가 필요한 환경에 적합하지만 설정 복잡도도 높입니다. 스니핑 범위, 제외 도메인 및 포트 목록을 잘못 설정하면 접속 대상이 예상한 규칙과 다르게 매칭될 수 있으므로, 모든 확장 옵션을 한꺼번에 활성화해서는 안 됩니다.

외부 제어 인터페이스의 기본 개념은 두 코어에서 비슷하며, 클라이언트는 보통 제어 포트를 통해 연결, 로그 및 정책 그룹 상태를 읽습니다. 다만 제어 API의 구체적인 필드와 기능은 코어 버전에 따라 달라집니다. 구형 클라이언트가 최신 mihomo를 실행하더라도 새 정책 정보를 표시하지 못할 수 있고, 최신 클라이언트가 구형 코어에 연결하면 버튼은 보이지만 호출이 작동하지 않을 수도 있습니다. 코어와 클라이언트 셸은 배포자가 제공하는 조합에 맞춰 사용해야 합니다.

설정 호환성 범위: 파싱 가능, 실행 가능, 동일한 결과

설정 호환성은 세 단계로 나눠 확인할 수 있습니다. 첫째는 문법 파싱입니다. YAML 들여쓰기, 목록 및 데이터 유형이 올바르고 코어가 해당 필드를 인식하는지 확인합니다. 둘째는 리소스 사용 가능 여부입니다. 프록시 노드, 규칙 집합, Geo 데이터 및 DNS 업스트림을 불러올 수 있는지 봅니다. 셋째는 실행 동작입니다. 동일한 요청이 같은 정책 그룹으로 들어가는지, DNS가 예상한 결과를 반환하는지, 시스템 트래픽이 실제로 해당 인바운드를 거치는지 확인합니다. 마이그레이션 중 ‘설정 로드 성공’만 확인해서는 뒤의 두 단계를 검증할 수 없습니다.

다음은 두 설정에서 모두 자주 볼 수 있는 기본 구조입니다. 실제 노드 매개변수는 사용하는 설정 제공처에서 받아야 하며, 이 예시는 필드 간 관계에 초점을 둡니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies:
  - name: example-node
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - example-node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,DIRECT

mihomo로 옮길 때는 기존 필드를 대체로 유지한 뒤 필요에 따라 확장 항목을 추가할 수 있습니다. 반대로 기존 코어로 되돌리는 작업은 더 까다롭습니다. 설정의 최신 프로토콜 노드, rule-providers, sniffer, 확장 DNS 필드, 논리 규칙 또는 mihomo 전용 정책 매개변수는 구형 코어에서 거부되거나 원래 의도대로 실행되지 않을 수 있습니다. ‘알 수 없는 필드’를 삭제하는 것이 만능 해결책은 아닙니다. 삭제한 부분이 노드 연결이나 규칙의 정확한 매칭에 꼭 필요한 조건일 수 있기 때문입니다.

주 설정과 클라이언트 오버라이드를 구분하는 것도 중요합니다. 많은 그래픽 클라이언트는 코어를 시작하기 전에 제어 포트, 실행 디렉터리, TUN 스위치, 키, DNS 오버라이드 또는 시스템 프록시 포트 같은 로컬 설정을 병합합니다. 사용자가 편집한 YAML은 최종 설정의 일부에 불과할 수 있습니다. 호환성 문제를 점검할 때는 클라이언트에서 실제 실행 설정을 내보내거나 확인하고, 로그에서 코어가 최종적으로 읽은 경로를 확인해야 합니다. 로드되지 않은 파일만 계속 수정하는 일을 피할 수 있습니다.

마이그레이션 중 누락하기 쉬운 필드

• proxy-providers 및 rule-providers의 경로, URL, 업데이트 간격 및 동작 유형.
• 정책 그룹에서 참조하는 노드 이름과 제공자 이름, 그리고 규칙 끝에서 참조하는 정책 그룹 이름.
• external-controller, 인증 키 및 클라이언트 제어 인터페이스 주소.
• geodata-mode, Geo 데이터 로드 방식 및 해당 리소스 파일의 존재 여부.
• DNS의 enhanced-mode, fake-ip-range, 필터 목록 및 업스트림 그룹.
• TUN의 프로토콜 스택, 자동 라우팅, DNS 하이재킹 및 인터페이스 제외 설정.

규칙 지원: 유형이 늘어도 우선순위가 바뀌는 것은 아닙니다

Clash 계열 코어의 규칙은 보통 위에서 아래로 매칭되며, 일치하면 해당 줄에 지정된 정책을 사용합니다. mihomo는 더 많은 규칙 유형을 추가했지만 ‘더 구체적인 규칙이 자동으로 우선한다’는 방식을 일반적인 대체 규칙으로 삼지는 않습니다. 포괄적인 DOMAIN-SUFFIX가 정확한 DOMAIN보다 앞에 있으면 전자가 요청을 먼저 가로챌 수 있습니다. MATCH가 앞에 나오면 뒤의 규칙은 실행될 기회를 얻지 못합니다.

일반적인 규칙에는 DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, IP-CIDR, IP-CIDR6, GEOIP, DST-PORT, SRC-IP-CIDR, PROCESS-NAME 및 MATCH가 있습니다. mihomo 환경에서는 GEOSITE, RULE-SET, NETWORK, PROCESS-PATH 및 논리 조합 규칙도 자주 사용합니다. 실제로 사용할 수 있는 유형은 코어 버전 문서와 시작 로그를 기준으로 확인해야 합니다.

RULE-SET 자체가 규칙을 자동으로 만들어내는 것은 아닙니다. rule-providers에 정의된 외부 규칙 집합을 참조할 뿐입니다. 규칙 집합에서 흔히 사용하는 동작 유형은 domain, ipcidr 및 classical입니다. domain은 도메인 항목에, ipcidr은 IP 대역에, classical은 규칙 유형이 포함된 기존 형식 항목에 적합합니다. 동작 유형과 실제 콘텐츠가 맞지 않으면 파일 다운로드는 성공해도 항목이 예상대로 로드되지 않을 수 있습니다.

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

rules:
  - RULE-SET,private-domains,DIRECT
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,PROXY

no-resolve는 규칙 매칭 단계에서 도메인을 능동적으로 조회하지 않도록 IP 계열 규칙에 사용하는 경우가 많습니다. 이것이 전체 연결에 DNS가 필요 없다는 뜻은 아니며 DNS 모듈을 끄지도 않습니다. 해당 규칙을 매칭할 때 조회를 실행할지 여부만 바꿉니다. 모든 규칙 뒤에 기계적으로 추가해도 모든 상황에서 속도가 빨라지는 것은 아니며, 조회 결과에 의존하던 매칭 경로가 달라질 수도 있습니다.

프로세스 규칙의 사용 가능 여부도 운영체제에 따라 완전히 같지 않습니다. 데스크톱 시스템은 일반적으로 프로세스 이름이나 경로를 더 쉽게 얻을 수 있지만, 모바일 시스템은 권한과 네트워크 스택의 제약을 받으므로 클라이언트가 코어에 동일한 정보를 제공하지 못할 수 있습니다. PROCESS-NAME에 의존하는 데스크톱 설정을 휴대폰으로 옮길 때는 규칙 텍스트가 같으면 결과도 같을 것이라고 가정하지 말고 도메인 또는 IP 규칙을 보완책으로 준비해야 합니다.

DNS와 TUN: 차이를 가장 쉽게 잘못 판단하는 영역

일반 시스템 프록시는 HTTP 또는 SOCKS 프록시를 명시적으로 사용하는 앱의 트래픽을 주로 받는 반면, TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 연결을 인계합니다. mihomo의 TUN 설정에서 자주 사용하는 필드는 enable, stack, auto-route, auto-detect-interface 및 dns-hijack입니다. 이 필드가 실제로 작동하는지는 운영체제 권한, 라우팅 테이블, 방화벽, 클라이언트 서비스 및 다른 VPN 소프트웨어가 네트워크 인계 기능을 동시에 사용하고 있는지에 따라서도 달라집니다.

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

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

이 설정은 필드 간 관계를 보여 주는 예시이지, 모든 기기에서 그대로 적용해야 하는 정답은 아닙니다. 지원되는 TUN 프로토콜 스택 옵션은 mihomo 버전에 따라 바뀔 수 있고, 클라이언트가 관련 필드를 자동으로 생성할 수도 있습니다. 클라이언트가 이미 TUN을 관리한다면 구독 설정에 별도의 매개변수 세트를 중복 작성할 경우 업데이트 때마다 덮어써지거나 로컬 라우팅 설정과 충돌할 수 있습니다.

DNS의 fake-ip 모드는 먼저 애플리케이션에 예약 주소 대역의 매핑 주소를 반환한 다음, 코어가 실제 도메인을 연결해 규칙을 실행합니다. 투명 인계 환경에서 도메인 정보를 유지하는 데 유리하지만, LAN 기기 검색, 일부 게임, 특정 인증 절차 및 실제 DNS 응답에 의존하는 프로그램은 fake-ip-filter에 추가해야 할 수 있습니다. redir-host는 처리 경로가 다르며, 호환성도 시스템과 앱에 따라 달라집니다. 모드는 필드 수만 비교하지 말고 실제 장애 증상을 기준으로 테스트해 선택해야 합니다.

mihomo는 nameserver-policy, proxy-server-nameserver, direct-nameserver처럼 DNS 역할을 더 세밀하게 나누는 기능도 제공합니다. 전자는 특정 도메인이 지정된 업스트림을 사용하도록 할 수 있고, 후자의 두 항목은 프록시 서버 주소와 직접 연결 대상의 조회 경로를 구분하는 데 사용됩니다. DNS 경로가 섞이는 것을 줄일 수 있지만, 잘못 설정하면 순환이 생길 수도 있습니다. 예를 들어 프록시 서버 도메인을 조회할 때 선택한 DNS 자체가 아직 수립되지 않은 프록시를 통해 접속해야 하는 상황입니다.

원본 Clash에서 mihomo로 마이그레이션하는 검증 절차

안전한 마이그레이션은 정상 작동하는 설정 사본에서 시작해야 하며, 유일한 파일에 수정 사항을 계속 누적해서는 안 됩니다. 먼저 기본 프록시를 검증한 뒤 규칙 집합, DNS 및 TUN을 차례로 추가하면 문제가 노드 연결, 규칙 매칭 또는 시스템 인계 중 어디에 속하는지 빠르게 판단할 수 있습니다.

1. 현재 실행 정보를 기록합니다. 기존 코어 버전, 클라이언트 버전, 리스닝 포트, 시스템 프록시 상태, DNS 모드 및 사용 가능한 정책 그룹을 저장합니다. 마이그레이션 후 동작이 달라졌을 때 비교 기준으로 사용할 수 있습니다.
2. YAML 구조를 확인합니다. 들여쓰기에 공백만 사용했는지, 노드 이름과 정책 그룹 참조가 정확히 일치하는지, 포트가 숫자인지, 불리언 값이 실수로 문자열로 작성되지 않았는지 확인합니다. 먼저 파싱 오류를 해결한 다음 네트워크 오류를 처리하세요.
3. 최소 연결 테스트를 구성합니다. 잠시 검증된 노드 하나, select 정책 그룹 하나 및 소수의 규칙만 사용합니다. 로컬 혼합 포트에 접근할 수 있는지 확인한 뒤 전체 구독 또는 프록시 제공자를 가져옵니다.
4. 규칙 리소스를 하나씩 복원합니다. 각 provider의 다운로드 상태, 파일 경로, behavior 및 format을 확인합니다. 규칙 집합 업데이트가 실패했을 때는 정책 그룹의 존재 여부만 보지 말고 로그에서 항목 수까지 확인해야 합니다.
5. DNS를 별도로 검증합니다. 프록시 서버 도메인, 직접 연결 도메인 및 프록시가 필요한 도메인을 각각 확인합니다. 도메인 접속은 실패하지만 IP 직접 접속은 정상이라면 문제는 노드 프로토콜보다 DNS 경로에 가까운 경우가 많습니다.
6. 마지막으로 TUN을 활성화합니다. 먼저 다른 VPN 또는 트래픽 인계 도구를 끄고 관리자 권한과 서비스 구성 요소가 정상인지 확인한 다음 라우팅 테이블, DNS 하이재킹 및 LAN 접근을 관찰합니다. 일반 시스템 프록시는 작동하지만 TUN만 작동하지 않는다면 시스템 계층 설정을 집중적으로 점검해야 합니다.
7. 최종 적용 설정을 확인합니다. 클라이언트가 오버라이드, 스크립트 또는 병합 기능을 지원한다면 병합 결과를 확인합니다. 구독을 업데이트한 뒤 로컬 규칙과 DNS 수정 사항이 여전히 유지되는지도 다시 확인하세요.

로그의 오류 유형을 보면 문제 범위를 좁힐 수 있습니다. unknown field 또는 설정 파싱 실패가 나타나면 대개 필드와 버전이 맞지 않는 문제입니다. 규칙 제공자 다운로드 실패가 나타나면 URL, 네트워크 경로 및 저장 디렉터리를 확인해야 합니다. 연결 시간 초과가 발생하면 프록시 서버 조회, 전송 핸드셰이크, 라우팅 및 규칙 선택을 구분해 계속 확인하세요. 여러 오류가 동시에 나타난다고 해서 포트, DNS, 노드 및 TUN을 한 번에 바꾸지는 마세요. 일괄 변경을 하면 비교 가능한 기준을 잃게 됩니다.

선택 방법: 설정 출처와 실제 기능을 기준으로

현재 설정이 기존 프로토콜, 단순한 정책 그룹 및 소수의 도메인 규칙만 사용하고 클라이언트와 코어 조합이 오랫동안 안정적이었다면, 호환되는 기존 환경을 계속 사용하는 편이 변경 비용을 줄일 수 있습니다. 다만 프로젝트 유지 관리 상태, 운영체제 업그레이드 및 클라이언트 지원 여부를 확인해야 합니다. 특히 제어 인터페이스, 시스템 프록시 서비스 및 인증서 구성 요소가 여전히 정상적으로 연동되는지 살펴보세요.

구독에 VLESS, TUIC, Hysteria2 같은 최신 노드 유형이 포함되어 있거나, 설정이 GeoSite, 규칙 제공자, 논리 규칙, 프로토콜 스니핑, 세밀한 DNS 분기 및 지속적으로 유지 관리되는 TUN 기능에 의존한다면 mihomo가 일반적으로 더 적합합니다. 이 경우 사용하는 코어 버전을 명확히 표시한 클라이언트를 선택하고, 클라이언트·코어·설정 문법이 서로 지원되는 버전 범위에 있도록 구성해야 합니다.

선택할 때 필드 수가 가장 많은 환경을 굳이 찾을 필요는 없습니다. 일반적인 데스크톱 사용자는 안정적인 시스템 프록시, 업데이트 가능한 구독 및 명확한 정책 그룹만으로도 주요 요구를 충족할 수 있습니다. 게임 UDP, LAN 공유, 컨테이너 네트워크, 프로세스별 분기 또는 전체 TUN 인계가 필요한 사용자는 해당 운영체제에서의 구현을 중점적으로 테스트해야 합니다. 같은 YAML이라도 Windows, macOS, Linux, Android 및 iOS에서는 권한과 네트워크 프레임워크가 달라 동작이 달라질 수 있습니다.

선택 전 확인할 네 가지

• 구독의 노드 프로토콜을 대상 코어가 지원하는가.
• 규칙이 mihomo 전용 유형, Geo 데이터 또는 외부 규칙 집합에 의존하는가.
• 클라이언트가 필요한 TUN, 서비스 모드 및 시스템 프록시 설정을 관리할 수 있는가.
• 설정 업데이트 방식이 로컬 오버라이드와 사용자 지정 규칙을 보존하는가.

설정 관리 관점에서 mihomo는 확장 중인 규칙 및 프로토콜 요구를 담기에 더 적합하고, 기존 Clash 설정은 포트, 정책 그룹 및 위에서 아래로 적용되는 규칙 메커니즘을 이해하는 중요한 기반으로 남아 있습니다. 마이그레이션의 핵심은 기존 파일에 필드를 더 많이 추가하는 것이 아니라 프로토콜 구현, 리소스 파일, DNS 경로 및 시스템 인계 방식을 항목별로 확인하는 데 있습니다. 최소 작동 설정을 하나 유지하고 모든 변경을 검증 가능하게 만들면, 복잡한 설정을 그대로 복사하는 것보다 안정적인 결과를 얻기 쉽습니다.

자주 묻는 질문