mihomo와 기존 Clash 차이: 지원 프로토콜·규칙 세트·설정 항목 비교

먼저 커널 확인: 클라이언트 이름만으로 기능을 알 수 없습니다

구독을 가져온 뒤 unsupport proxy type 오류가 뜨거나 설정에 sniffer를 넣었는데도 기대한 대로 작동하지 않는다면, 노드 비밀번호부터 바꾸지 마세요. 먼저 클라이언트가 실제로 어떤 커널을 실행 중인지 확인해야 합니다. 클라이언트 UI는 구독 관리와 시스템 프록시 설정, 기능 켜기·끄기를 담당하고, 커널은 설정을 읽고 규칙을 적용해 연결을 맺습니다. UI 이름이 비슷하다고 지원하는 설정 항목까지 같지는 않습니다.

여기서 ‘기존 Clash’는 두 가지를 구분합니다. 기존 오픈 소스 커널과 한때 별도로 배포된 Clash Premium입니다. Premium의 TUN 및 규칙 세트 기능을 기존 오픈 소스 커널의 기능으로 간주해서는 안 됩니다. mihomo는 Clash Meta에서 발전했으며 Clash 설정 관례를 상당 부분 이어받았지만, 이름만 바꾼 프로그램은 아닙니다.

데스크톱 클라이언트: ‘정보’ 메뉴에서 커널 버전을 확인하고 시작 로그도 살펴보세요. 클라이언트마다 메뉴 이름이 다를 수 있으니 실제 화면을 기준으로 확인하세요.
명령줄 배포: 실제 실행 중인 바이너리에서 mihomo -v를 실행하세요. 다운로드 폴더에 있는 다른 프로그램의 버전만 확인해서는 안 됩니다.
라우터 또는 컨테이너: 플러그인에서 선택한 커널, 컨테이너 이미지, 프로세스 경로를 모두 확인하세요. 관리 UI를 업데이트해도 커널은 그대로일 수 있습니다.

프로토콜 지원: VLESS·Hysteria2·TUIC가 주요 차이

기존 구독에 Shadowsocks·VMess·Trojan 같은 전통적인 노드만 있다면 마이그레이션해도 차이를 체감하기 어려울 수 있습니다. 호환성 오류는 새 프로토콜이나 새로운 암호화 방식, 프로토콜별 전송 매개변수에서 주로 발생합니다. 노드 이름이 ‘Hysteria2’인지 여부는 중요하지 않습니다. 커널은 YAML의 type과 관련 설정 항목을 읽습니다.

프로토콜 또는 기능	기존 Clash	mihomo
Shadowsocks、VMess、Trojan	기본 프로토콜은 대체로 사용 가능하며, 세부 매개변수는 버전에 따라 다릅니다	지원하며 후속 기능도 확장됐습니다
VLESS	기존 오픈 소스 커널과 Premium 모두 이 프로토콜을 지원하지 않습니다	지원, 노드 유형은 `vless`
Hysteria2	지원하지 않음	지원, 노드 유형은 `hysteria2`
TUIC	지원하지 않음	지원, 노드 유형은 `tuic`
VLESS와 REALITY 조합	지원하지 않음	관련 설정을 지원하지만 서버 매개변수와 일치해야 합니다

오류가 발생한 단계에 따라 먼저 확인할 항목이 달라집니다

설정 테스트에서 곧바로 ‘지원하지 않는 프록시 유형’ 오류가 발생한다면 로컬 설정 파싱 단계의 문제이며, 아직 노드 연결 테스트까지 진행되지 않은 상태입니다. 반대로 설정은 정상적으로 로드됐지만 연결 시간이 초과된다면 프로토콜 미지원이라고 단정할 수 없습니다. 서버 주소와 포트, 인증 정보, 전송 네트워크를 추가로 확인하세요.

VLESS: UUID, TLS, servername, 전송 방식, flow를 확인하세요. REALITY를 사용하는 경우 공개 키와 short ID 등 관련 매개변수도 점검해야 합니다.
Hysteria2: QUIC 기반이므로 UDP 연결이 가능해야 합니다. 서버의 TCP 포트만 테스트해서는 해당 노드의 사용 가능 여부를 확인할 수 없습니다. Hysteria 1세대 설정의 이름만 바꿔 사용하지 마세요.
TUIC: UDP 네트워크 환경을 확인해야 하며, 인증 항목은 서버의 프로토콜 버전과 일치해야 합니다. 클라이언트가 TUIC를 지원한다는 사실만으로 서버 설정이 올바르다고 볼 수는 없습니다.

구독 변환에도 한계가 있습니다. 변환기는 설정 항목의 순서를 바꿀 수 있지만 구형 커널에 프로토콜 구현을 추가할 수는 없습니다. 변환 후 노드가 사라졌다면 mihomo용 출력 형식을 선택했는지, 변환 서비스가 해당 프로토콜을 지원하는지 먼저 확인하세요. 호환되지 않는 구독을 같은 방식으로 계속 업데이트하지 마세요.

규칙 세트 비교: rule-providers는 mihomo만의 기능이 아닙니다

rule-providers는 규칙 세트의 출처를 선언하고, RULE-SET은 규칙 목록에서 해당 세트를 참조할 때 사용합니다. 기존 오픈 소스 Clash와 Premium의 지원 범위에는 차이가 있습니다. Premium은 이미 규칙 세트를 지원하므로 모든 규칙 세트 기능을 mihomo에서 새로 추가된 기능이라고 할 수는 없습니다. mihomo는 이를 바탕으로 더 다양한 형식과 사용 방법을 제공합니다.

설정 항목	마이그레이션 시 확인 사항
`rules`	기본 규칙 목록은 위에서 아래로 순서대로 검사하며, 처음 일치한 규칙의 정책을 적용합니다.
`rule-providers`	Premium은 지원하지만, 기존 오픈 소스 커널도 Premium과 같은 기능을 제공한다고 가정해서는 안 됩니다.
`behavior`	`domain`·`ipcidr`·`classical`을 구분하고 선언한 유형에 맞는 내용을 넣으세요.
`format: mrs`	mihomo에서 지원하는 규칙 세트 형식입니다. domain과 ipcidr에 사용할 수 있지만 classical에는 사용할 수 없습니다.
`type: inline`	mihomo에서는 규칙 내용을 provider의 payload에 직접 작성할 수 있지만, 구형 커널은 이를 지원한다고 가정할 수 없습니다.

먼저 로컬 YAML로 규칙 세트 동작을 검증하세요

아래는 mihomo 설정에 추가할 수 있는 규칙 예시입니다. 원격 다운로드를 사용하지 않으므로 ‘규칙 작성 오류’와 ‘규칙 파일 가져오기 실패’를 구분하기 쉽습니다. 설정은 내장 정책인 DIRECT와 REJECT만 사용하므로, 아직 정의하지 않은 노드 그룹에 의존하지 않습니다.

rule-providers:
  local-block:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-block.yaml

rules:
  - RULE-SET,local-block,REJECT
  - MATCH,DIRECT

설정 작업 디렉터리에 rules/local-block.yaml 파일을 만들고 아래 내용을 입력하세요. example.org는 규칙 동작을 보여 주기 위한 예약 도메인이므로 테스트 시 해당 도메인과 하위 도메인이 차단되는 것이 정상입니다.

payload:
  - '+.example.org'

behavior: domain에는 도메인 일치 항목을 작성합니다. 이곳에 DOMAIN-SUFFIX,example.org를 쓰면 안 됩니다. classical을 사용한다면 DOMAIN-SUFFIX,example.org처럼 해당 규칙 유형에 맞게 작성하세요. 규칙 세트 내부에는 최종 아웃바운드 정책을 추가하지 않습니다.

sniffer와 DNS: 도메인 식별은 트래픽 복호화가 아닙니다

마이그레이션 후 일부 연결이 IP 규칙 대신 도메인 규칙에 일치한다면 DNS 매핑이나 스니핑이 원인일 수 있습니다. mihomo의 sniffer는 HTTP의 Host, TLS의 SNI, 지원되는 QUIC 핸드셰이크 정보처럼 일부 프로토콜 핸드셰이크에서 호스트 이름을 추출합니다. 인증서를 설치하는 HTTPS 중간자 복호화 기능이 아니며 모든 연결에서 도메인을 식별할 수 있는 것도 아닙니다.

먼저 동작을 확인한 뒤 목적지 덮어쓰기를 켤지 결정하세요

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

이 예시는 HTTP와 TLS만 설정하며 모든 포트에서 스니핑해야 한다는 뜻은 아닙니다. override-destination: false는 스니핑 결과로 연결 목적지를 덮어쓰지 않는다는 의미입니다. 스니핑 정보는 도메인 식별과 규칙 판정에 계속 사용될 수 있습니다. 목적지 덮어쓰기 여부는 DNS와 앱 동작을 함께 테스트해 결정해야 하며, 무조건 켜야 하는 최적화 옵션으로 봐서는 안 됩니다.

도메인을 식별하지 못함: 연결이 설정된 포트를 통과하지 않았거나 핸드셰이크에 사용할 수 있는 도메인 정보가 없을 수 있습니다. 앱에서 관련 정보를 숨기는 방식을 사용할 수도 있습니다.
앱이 목적지 IP에 직접 연결: 스니핑으로 도메인을 복원하지 못할 수 있습니다. 필요한 IP 규칙을 유지하고 도메인 규칙만 남기지 마세요.
웹사이트 트래픽이 잘못 분기됨: 규칙 순서, DNS 응답, fake-ip 매핑, sniffer 설정을 함께 확인하세요. 처음부터 스니핑 범위를 넓히지는 마세요.

dns.enhanced-mode: fake-ip와 redir-host는 서로 다른 처리 방식이며, fake-ip는 mihomo만의 기능이 아닙니다. 마이그레이션할 때는 먼저 기존 DNS 모드를 유지하세요. 변경이 필요하다면 별도로 수정한 뒤 관련 DNS 캐시를 비우세요. 커널의 DNS 수신 주소는 시스템 또는 트래픽 가로채기 경로와 연결되어야 합니다. dns.listen만 설정했다고 시스템 요청이 자동으로 유입되는 것은 아닙니다.

TUN과 포트: 설정 호환성이 같아도 트래픽 경로는 다를 수 있습니다

브라우저에서는 접속되지만 게임이나 명령줄 프로그램 등 다른 앱에서 프록시를 사용하지 않는다면, 프로토콜을 바로 바꾸기보다 트래픽 진입 경로를 먼저 확인하세요. 시스템 프록시는 해당 설정을 따르는 앱에 주로 적용됩니다. TUN은 가상 네트워크 인터페이스로 트래픽을 받아 더 많은 앱에 적용할 수 있지만 권한과 라우팅, DNS 가로채기도 설정해야 합니다.

기존 Premium은 TUN을 제공하지만, 기존 오픈 소스 커널과 같은 것으로 취급해서는 안 됩니다. mihomo 역시 TUN을 지원하지만 구형 설정의 스택 선택, 인터페이스 매개변수, 라우팅 설정이 모든 운영체제에서 그대로 작동한다고 보장할 수는 없습니다. Windows·macOS·Linux는 권한과 서비스 관리 방식이 서로 다릅니다.

마이그레이션은 두 단계로 나눠 검증하세요

먼저 TUN을 끄고 명시적 프록시로 노드와 규칙이 정상인지 확인하세요. 예를 들어 mixed-port: 7897을 설정하면 연결 주소는 127.0.0.1:7897입니다. 7897은 여기서 사용한 예시 포트이며 모든 클라이언트의 고정 포트는 아닙니다.
터미널에서 아래 명령을 실행해 요청이 실제로 해당 프록시를 통과하는지 확인하세요. 테스트 주소는 기본 HTTPS 연결 확인용이며 모든 웹사이트의 접속 가능 여부를 보장하지 않습니다.
명시적 프록시가 정상 작동하면 클라이언트에서 TUN을 켜세요. 권한 상승 여부와 서비스 상태, 가상 인터페이스 및 라우트 생성 여부를 확인한 뒤 시스템 프록시를 사용하지 않는 앱을 테스트하세요.

curl --proxy http://127.0.0.1:7897 --connect-timeout 10 -I https://example.com

address already in use 오류가 발생하면 먼저 커널이 두 개 실행 중인지 확인하세요. 마이그레이션 중 이전 클라이언트가 종료되지 않아 로컬 수신 포트가 충돌하는 경우가 흔합니다. 기기 전체의 네트워크가 끊기면 새 클라이언트의 TUN과 시스템 프록시를 먼저 끄고 기본 네트워크를 복구한 뒤 하나씩 점검하세요. VPN이나 라우팅 가로채기 도구를 여러 개 동시에 사용하지 마세요.

설정 마이그레이션 절차: 테스트·로드·규칙·연결을 나눠 검증하세요

설정을 ‘로드할 수 있다’는 것은 현재 단계의 파싱과 초기화가 통과됐다는 뜻일 뿐입니다. 모든 설정 항목이 적용됐거나 노드와 DNS가 정상이라는 의미는 아닙니다. 일부 알 수 없는 설정 항목은 눈에 띄는 오류 없이 무시될 수 있으므로 실행 로그와 실제 동작을 모두 확인하세요.

현재 상태 백업: 원본 구독, 병합된 실행 설정, 로컬 오버라이드 파일을 저장하세요. 구독 링크와 노드 인증 정보를 공개 토론방에 올리지 마세요.
구독 형식 확인: 구독 서비스가 Clash와 Clash Meta/mihomo 형식을 모두 제공한다면 실제로 실행할 커널에 맞는 출력을 선택하세요. 버튼 이름만 보지 말고 생성된 설정도 확인하세요.
먼저 설정 테스트: 실제 배포된 바이너리를 사용하고 설정 파일과 작업 디렉터리를 지정하세요. 상대 경로가 잘못된 위치를 가리키는 일을 방지할 수 있습니다.
프록시 진입점과 노드 확인: 먼저 명시적 프록시로 테스트한 뒤 연결 기록에서 선택된 노드나 정책 그룹을 확인하세요. 연결에 실패하면 오류가 발생한 전체 과정을 기록해 두세요.
규칙 세트 확인: provider가 정상적으로 로드됐는지, 규칙 항목이 있는지, 테스트 도메인이 실제로 어떤 규칙에 일치했는지 확인하세요.
마지막으로 고급 기능 켜기: DNS·sniffer·TUN 중 한 번에 하나씩만 변경하세요. 문제가 생겼을 때 직전의 정상 설정으로 되돌릴 수 있어야 합니다.

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

위의 /srv/mihomo는 Linux 배포 예시 경로입니다. 실행 전에 파일이 실제로 해당 경로에 있는지 확인하세요. Windows에서는 현재 설정 디렉터리에서 mihomo.exe -t -d . -f .\config.yaml을 실행해 테스트할 수 있습니다. 클라이언트가 커널을 관리하는 경우 구독과 오버라이드가 병합된 파일이 최종 적용될 수 있으므로 사용되지 않는 원본 파일만 테스트해서는 안 됩니다.

선택 기준: 노드 프로토콜과 유지 관리 요구 사항을 따르세요

VLESS·Hysteria2·TUIC·MRS 규칙 세트·sniffer 등이 필요하다면 mihomo의 기능 범위가 더 잘 맞습니다. 전통적인 프로토콜 설정만 유지한다면 설정 검증 가능 여부, 클라이언트의 유지 관리 상태, 문제 발생 시 원인을 추적할 수 있는지가 중요합니다. 커널을 바꾸면 지연 시간이 자동으로 줄어든다고 기대해서는 안 됩니다.

기존 설정이 안정적으로 작동: 백업을 보관하고 별도의 테스트 환경에서 새 커널을 먼저 검증하세요. 노드·규칙·DNS를 한꺼번에 변경하지 마세요.
구독에서 프로토콜 미지원 안내: 생성된 설정 형식과 실제 실행 중인 커널을 확인한 뒤 클라이언트나 커널을 바꿀지 결정하세요.
라우터 리소스가 제한적: 규칙 세트 용량과 로드 시간, 사용 가능한 메모리를 확인하세요. 형식을 선택하는 것만으로 실제 성능 확인을 대신할 수는 없습니다.
mihomo에서 이전하려는 경우: 대상 커널이 지원하지 않는 프로토콜과 설정 항목을 하나씩 제거한 뒤 설정 테스트와 연결 검증을 다시 진행하세요.

차이는 세 가지로 정리할 수 있습니다. 프로토콜은 노드를 인식할 수 있는지, 규칙과 DNS는 연결을 어떻게 분기할지, 시스템 프록시나 TUN은 트래픽이 커널에 유입되는지를 결정합니다. 여러 설정을 한꺼번에 바꾸기보다 이 세 단계에 따라 확인하면 원인을 찾기 쉽습니다.