mihomo와 기본 Clash 차이: 추가 프로토콜·룰셋·설정 필드 비교

클라이언트, Clash, mihomo부터 구분하기

Windows용 Clash 클라이언트는 보통 GUI, 백그라운드 서비스, 프록시 코어가 함께 작동합니다. GUI에서는 구독을 가져오고 프록시 그룹을 선택하며 시스템 프록시를 설정합니다. 코어는 프로토콜 연결, DNS 처리, 규칙 매칭을 담당합니다. 같은 클라이언트라도 버전에 따라 사용하는 코어가 다를 수 있습니다. 따라서 YAML을 가져올 수 있다고 해서 코어가 모든 필드를 처리할 수 있는 것은 아닙니다.

이 글에서는 원 프로젝트의 오픈소스 Clash와 Clash Premium을 구분합니다. Premium은 원 프로젝트에서 제공했던 비공개 강화 코어로, 오픈소스 Clash와는 다릅니다. mihomo는 Clash Meta 프로젝트에서 시작해 프로토콜과 설정 기능을 확장한 코어입니다. ‘Clash 형식’이라는 표현만으로 코어 간 완전한 호환성을 보장할 수는 없습니다.

대상	주요 역할	이전할 때 확인할 점
기본 오픈소스 Clash	기본 프록시 프로토콜, 프록시 그룹, 규칙 매칭 제공	Premium의 TUN이나 rule-providers 같은 강화 기능이 있다고 가정하지 마세요.
Clash Premium	원 프로젝트의 강화 코어로, rule-providers와 TUN 등의 기능 지원	기존 rule-providers는 옮기기 전에 대조할 수 있지만, Premium 스크립트를 mihomo 기능으로 그대로 사용할 수는 없습니다.
mihomo / Clash Meta	프로토콜, 도메인 감지, DNS, 규칙 기능을 계속 확장하는 코어	구독 설정 필드, 클라이언트에 포함된 버전, 실제 실행 중인 코어를 함께 확인해야 합니다.
Windows GUI 클라이언트	설정, 코어 프로세스, 시스템 프록시, 서비스 관리	GUI 클라이언트 버전이 mihomo 코어 버전과 같은 것은 아닙니다.

추가 프로토콜: 노드가 표시되어도 연결된다는 뜻은 아닙니다

mihomo의 눈에 띄는 차이 중 하나는 지원 프로토콜의 폭이 넓다는 점입니다. VLESS, Hysteria2 또는 TUIC이 포함된 구독은 기본 Clash나 Premium에서 바로 사용할 수 없습니다. 같은 이름의 프로토콜이라도 코어 버전에 따라 전송 방식, TLS 핑거프린트, UDP 처리 옵션 등의 지원 여부가 다를 수 있으므로 사용 중인 버전을 확인해야 합니다.

프로토콜 또는 필드	기본 Clash / Premium	mihomo 설정 확인 항목
Shadowsocks、VMess、Trojan	기본 지원은 있지만 사용 가능한 암호화 및 전송 옵션은 버전에 따라 다릅니다.	암호화 방식, 전송 유형, TLS 설정이 서버 설정과 일치하는지 확인하세요.
`type: vless`	지원하지 않음	UUID와 전송 방식을 확인하세요. REALITY를 사용한다면 올바른 공개 키와 short-id도 필요합니다.
`type: hysteria2`	지원하지 않음	인증 정보, SNI, 포트, 서버에서 실제로 Hysteria2를 사용하는지 확인하세요.
`type: tuic`	지원하지 않음	서버 프로토콜 버전, UUID, 비밀번호, UDP 네트워크 연결 가능 여부를 확인하세요.
Shadowsocks 2022 계열 암호화	일반적인 Shadowsocks 지원 여부만으로 사용할 수 있다고 판단할 수 없습니다.	암호화 알고리즘 이름과 키 형식을 확인하고, 해당 암호화를 지원하는 코어 버전을 사용하세요.

Windows에서 ‘가져오기는 됐지만 노드를 사용할 수 없음’ 문제 해결

구독 또는 노드 세부 정보에서 type을 확인하세요. 노드 표시 이름만 봐서는 안 됩니다. 이름에 ‘고속’이나 ‘전용 회선’이라고 적혀 있어도 프로토콜 유형을 알 수 없습니다.
로그에서 지원하지 않는 프록시 유형, 알 수 없는 암호화 방식, 누락된 필드가 있는지 확인하세요. 설정 단계에서 오류가 발생했다면 속도 테스트를 반복하기보다 코어 호환성부터 해결하세요.
Hysteria2와 TUIC을 사용할 때는 현재 네트워크에서 해당 UDP 통신이 허용되는지 확인하세요. 웹사이트가 HTTP 프록시로 열린다고 해서 UDP 연결도 정상이라는 뜻은 아닙니다.
클라이언트에서 코어를 선택할 수 있다면, 해당 클라이언트가 지원하는 mihomo 코어를 선택하고 코어 프로세스를 재시작한 뒤 시작 로그를 확인하세요. 설정 파일 이름만 바꾸지 마세요.

mihomo로 바꿔도 잘못된 서버 설정이 자동으로 수정되거나 일반 구독이 다른 프로토콜로 변환되지는 않습니다. 서버에서 해당 프로토콜을 활성화하지 않았다면 클라이언트의 type만 바꿔도 연결에 실패합니다.

rule-providers: Premium에도 있는 기능, mihomo는 형식 확장

rule-providers는 mihomo만의 기능이 아닙니다. Clash Premium도 이미 rule-providers를 지원합니다. 이전할 때는 규칙 동작, 파일 형식, 참조 순서를 비교하는 것이 중요합니다. mihomo는 대규모 도메인 및 IP 규칙에 적합한 MRS 바이너리 형식도 지원하지만, 이런 파일은 구형 코어에서 사용할 수 없습니다.

로컬 룰셋으로 참조 관계부터 확인하기

아래는 기본 설정의 일부이며, 전체 구독 설정이 아닙니다. 기본 제공 정책인 DIRECT와 REJECT를 사용하므로 특정 프록시 그룹 이름에 의존하지 않고 규칙만 따로 확인할 수 있습니다. 룰셋 파일은 코어가 접근할 수 있는 설정 디렉터리에 두세요. 상대 경로는 직접 연 YAML 파일의 위치가 아니라 코어의 작업 디렉터리를 기준으로 해석될 수 있습니다.

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

rules:
  - RULE-SET,local-direct,DIRECT
  - DOMAIN-SUFFIX,example.org,REJECT
  - MATCH,DIRECT

해당하는 rules/local-direct.yaml의 내용은 다음과 같습니다. classical 룰셋에는 매칭 조건만 작성하고 DIRECT는 붙이지 않습니다. 최종 동작은 기본 설정의 RULE-SET에서 지정합니다.

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

behavior: domain: 도메인 룰셋을 넣습니다. DOMAIN-SUFFIX,도메인과 같은 완전한 규칙 행을 섞어 넣지 마세요.
behavior: ipcidr: IP 대역을 넣습니다. 대상 IP를 기준으로 매칭할 때 적합합니다.
behavior: classical: 규칙 유형이 포함된 기존 형식의 규칙을 넣습니다. 도메인, IP 등 여러 조건을 함께 사용할 때 적합합니다.
format: mrs: 매칭에 사용하는 MRS 파일입니다. domain 및 ipcidr 동작을 지원하며, classical에는 사용할 수 없습니다. 확장자만 바꿔도 파일 형식이 변환되지는 않습니다.

룰셋 개수보다 규칙 매칭 순서가 중요합니다

일반 규칙은 순서대로 매칭되며, 먼저 일치하는 규칙이 연결 경로를 결정합니다. 룰셋 참조보다 앞에 MATCH를 두면 뒤에 있는 규칙은 연결을 처리할 기회가 없습니다. 원격 룰셋을 실제 구독에 연결한 뒤에는 동작에 지정한 프록시 그룹이 실제로 존재하는지도 확인하세요. Proxy, PROXY, 한국어 그룹 이름을 임의로 바꿔 쓸 수는 없습니다.

Windows 클라이언트에서는 설정 편집, 추가 설정 또는 오버라이드 기능을 통해 필드를 추가한 다음, 설정 검사와 로그에서 provider가 정상적으로 로드되었는지 확인하세요. 구독을 내려받아 생성된 파일을 직접 수정하면 다음 업데이트 때 덮어써질 수 있습니다. 전체 규칙 작성법은 YAML 설명서의 규칙 문법을 참고하세요.

sniffer 도메인 감지: 도메인 정보를 보완할 뿐, HTTPS를 복호화하지 않습니다

앱이 IP 주소에 직접 연결하거나 도메인과 IP의 매핑이 코어 DNS에 전달되지 않으면 도메인 규칙에 필요한 매칭 정보가 부족할 수 있습니다. mihomo의 sniffer는 HTTP Host나 TLS 핸드셰이크의 서버 이름 등에서 도메인을 가져올 수 있으며, QUIC 트래픽도 식별할 수 있습니다. 이는 기본 Clash 및 Premium과 구별되는 주요 설정 기능 중 하나입니다.

sniffer:
  enable: true
  override-destination: false
  sniff:
    HTTP:
      ports: [80, 8080-8880]
    TLS:
      ports: [443, 8443]
    QUIC:
      ports: [443]
  skip-domain:
    - "+.lan"

여기서 80, 443, 8443은 감지를 시도할 대상 포트이며, 새 로컬 수신 포트가 아닙니다. 예시에서는 override-destination을 false로 설정해 연결 대상을 처리하는 방식을 바꾸기 전에 도메인 감지와 규칙 매칭부터 확인합니다.

활성화 후 확인할 세 가지

클라이언트의 설정 편집 또는 오버라이드 메뉴를 열고 최상위 수준에 sniffer를 추가하세요. dns나 특정 노드 내부에 들여쓰기하면 안 됩니다.
다시 불러온 뒤 새 연결을 한 번 만들고, ‘연결’ 화면이나 로그에서 대상 도메인과 매칭된 규칙을 확인하세요. 이미 연결된 장시간 연결은 규칙을 수정해도 자동으로 다시 연결되지 않습니다.
특정 사내망 서비스에 문제가 생기면 먼저 도메인 감지를 끄고 다시 테스트한 다음, 실제 도메인을 기준으로 제외 항목을 추가하세요. 고급 옵션을 한꺼번에 여러 개 켜면 어떤 설정이 동작을 바꿨는지 판단하기 어렵습니다.

DNS 필드: 기본 설정을 유지하고 분할 라우팅은 단계적으로 추가

기본 Clash에도 DNS 모듈과 fake-ip 등의 기능이 있으므로, ‘fake-ip를 사용한다’는 것만으로 mihomo를 사용 중이라고 볼 수는 없습니다. mihomo는 DNS 라우팅과 정책 관련 필드를 더 제공하며, 예를 들어 proxy-server-nameserver, direct-nameserver, respect-rules가 있습니다. 모든 환경에서 이 필드를 켜야 하는 것은 아닙니다.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost"
  nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - 223.5.5.5

아래는 필드 간 관계를 설명하기 위한 기본 설정입니다. 127.0.0.1:1053은 로컬에서만 수신합니다. 198.18.0.1/16은 예시에서 fake-ip를 할당하는 데 사용하며, 상위 DNS 주소가 아닙니다. 223.5.5.5는 암호화되지 않은 DNS 예시로, 모든 네트워크에 적합하거나 DNS 트래픽을 암호화한다는 뜻은 아닙니다.

필드	역할	흔한 오해
`nameserver`	일반 도메인 조회에 사용할 상위 DNS 지정	주소를 입력해도 모든 앱의 DNS를 자동으로 가로채지는 않습니다.
`nameserver-policy`	조건에 따라 특정 조회에 사용할 상위 DNS 선택	DNS 조회의 경로를 결정할 뿐, 서비스 연결에 사용할 노드를 직접 정하지는 않습니다.
`proxy-server-nameserver`	프록시 서버 도메인 전용 조회 서버 지정	노드 도메인 조회에 실패한다면 일반 nameserver만 바꾸는 것으로 해결되지 않을 수 있습니다.
`direct-nameserver`	직접 연결에 필요한 도메인의 조회 서버 지정	직접 연결용 DNS 조회와 정책 매칭의 관계를 함께 이해해야 합니다.
`respect-rules`	DNS 상위 서버 연결에도 라우팅 규칙 적용	노드 도메인 조회에는 proxy-server-nameserver도 함께 설정해 순환 의존을 피해야 합니다.

Windows 시스템 프록시는 시스템 프록시 설정을 따르는 앱에 주로 영향을 줍니다. 모든 시스템 DNS 요청을 자동으로 1053으로 보내지는 않습니다. dns.listen만 설정하고 실제 조회가 해당 수신 포트로 전달되지 않으면 설정은 있어도 요청을 처리하지 못할 수 있습니다. 앱 자체의 암호화 DNS는 별도의 네트워크 연결로 조회 서버에 접속할 수 있으므로 따로 확인해야 합니다.

먼저 respect-rules의 기본 동작을 유지한 채 일반 접속과 노드 도메인 조회를 확인하세요. DNS 상위 서버를 분할 라우팅해야 할 때 이 필드를 추가하고, 규칙에서 상위 서버 연결을 명확히 처리하세요. 다른 필드는 DNS 설정 안내를 참고하고, 서로 다른 가이드의 설정을 통째로 덧붙이지 마세요.

TUN과 시스템 프록시: 트래픽 진입 경로를 별도로 활성화

mihomo는 TUN을 지원하지만, TUN은 Premium과 비교해 새로 추가된 기능이 아닙니다. 두 코어의 설정 필드와 플랫폼별 구현은 그대로 서로 바꿔 쓸 수 없습니다. Windows에서 시스템 프록시는 브라우저처럼 프록시 설정을 따르는 앱에 적합합니다. TUN은 가상 네트워크 어댑터와 라우팅을 통해 더 많은 IP 트래픽을 처리하며, 보통 클라이언트 서비스나 관리자 권한이 필요합니다.

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

위 내용은 TUN 설정의 일부이며, 활성화된 코어 DNS와 함께 사용해야 합니다. any:53은 TUN으로 들어오는 일반 DNS 요청을 처리하는 설정으로, DoH나 DoT처럼 다른 포트를 사용하는 암호화된 조회까지 자동으로 가로채지는 않습니다. auto-detect-interface도 여러 네트워크 어댑터가 있는 환경의 만능 해결책은 아닙니다. 기업 VPN이나 가상 머신 어댑터를 함께 사용한다면 실제 출구 경로와 라우팅을 확인하세요.

Windows 클라이언트에서 활성화하는 순서

먼저 일반 프록시 모드에서 노드와 규칙이 작동하는지 확인한 뒤 TUN을 고려하세요. 기본 연결부터 실패한다면 가상 네트워크 어댑터를 켜도 문제 해결 항목만 늘어납니다.
클라이언트 ‘설정’에서 서비스 모드 관련 메뉴를 찾고 안내에 따라 서비스를 설치하거나 활성화하세요. 권한이 필요하다는 안내가 나오면 요청을 확인하고 승인하세요.
화면에서 ‘TUN 모드’ 또는 ‘가상 네트워크 어댑터’를 켠 뒤 로그를 다시 확인하세요. 클라이언트가 tun 필드를 자동 생성할 수도 있으므로 병합된 설정을 기준으로 확인해야 합니다.
브라우저와 시스템 프록시를 사용하지 않는 앱 하나를 테스트하고, 연결 목록에서 트래픽이 실제로 코어에 들어오는지 확인하세요. 문제가 생기면 TUN을 끄고 다시 테스트한 뒤 로그를 보존하고 네트워크 어댑터와 라우팅을 확인하세요.

클라이언트마다 메뉴 구성이 다르므로 특정 GUI에서 스위치가 있는 위치를 코어 사양처럼 간주하지 마세요. 사용할 수 있는 기능은 클라이언트의 서비스 관리 방식, 코어 버전, 최종 설정에 따라 달라집니다. YAML에 enable: true가 있는지만으로 결정되지 않습니다.

이전 확인: 최종 설정과 실제 트래픽을 검증하세요

Premium이나 구형 Clash에서 mihomo로 이전할 때는 기존 설정을 복사해 두고 ‘기본 프록시 → 룰셋 → DNS → 도메인 감지 → TUN’ 순서로 활성화하는 편이 좋습니다. Premium의 script 기능을 mihomo의 동명 기능으로 그대로 사용할 수는 없습니다. 클라이언트의 JavaScript 오버라이드 스크립트는 설정을 생성하거나 수정하는 별도 계층이며, 코어 규칙 스크립트가 아닙니다.

설정 검사로 문법 오류와 연결 문제 구분하기

테스트할 파일을 config.yaml로 저장하고 별도의 테스트 디렉터리에서 다음 명령을 실행하세요. 클라이언트 환경에서는 병합된 실행 설정을 확인해야 합니다. 구독 원본 파일이 검사를 통과해도 오버라이드가 적용된 파일까지 통과한다는 보장은 없습니다.

.\mihomo.exe -t -f .\config.yaml

설정 검사는 파싱 오류, 누락된 참조, 일부 잘못된 필드를 찾는 데 유용하지만 노드 연결 가능 여부를 증명하지는 않습니다. 유효하지 않거나 지원되지 않는 모든 옵션이 오류로 표시되는 것도 아닙니다. 검사를 통과했는데 기능이 작동하지 않으면 시작 로그, 최종 설정, 실제 연결의 규칙 매칭 결과를 더 확인하세요.

고정 포트로 프록시 연결 확인하기

실제 실행 설정에 mixed-port: 7890이 있고 로컬 연결이 허용되어 있다고 가정하면, Windows PowerShell에서 다음 명령을 실행할 수 있습니다. 구버전 PowerShell에서 같은 이름의 별칭으로 인한 인자 차이를 피하기 위해 curl.exe를 명시합니다.

Test-NetConnection 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com/

TcpTestSucceeded: True는 로컬 포트에 연결할 수 있다는 뜻일 뿐, 원격 노드가 정상 작동한다는 뜻은 아닙니다.
대상 사이트에서 HTTP 응답을 받으면 연결 기록에서 매칭된 규칙과 출구를 확인하세요. 예시 사이트는 테스트용이며 속도 측정이나 모든 사이트의 접속 가능 여부를 판단하는 용도가 아닙니다.
클라이언트가 7890이 아닌 포트를 사용한다면 설정이나 최종 설정에서 실제 값을 확인한 뒤 명령을 수정하세요. 명령에 맞추려고 포트를 임의로 바꾸지 마세요.
HTTP 프록시 테스트만으로는 TUN, 앱 자체 DNS, UDP 통신을 확인할 수 없습니다. 각 항목은 새 연결을 만들어 따로 검증해야 합니다.