Clash 오리지널·Clash.Meta·mihomo 차이와 설정 호환성 비교

클라이언트·코어·구독 설정부터 구분하기

클라이언트가 ‘Clash 설정’을 지원한다고 해서 Clash.Meta나 mihomo의 모든 필드까지 지원하는 것은 아닙니다. 클라이언트는 창, 구독 관리, 시스템 프록시 전환, 서비스 설치를 담당하고, 코어는 포트 수신, 도메인 해석, 규칙 매칭, 프록시 연결을 처리합니다. 구독은 노드나 전체 설정을 제공합니다. 이 세 요소는 각각 업데이트되므로 ‘구독은 가져왔는데 노드가 시작되지 않는’ 상황은 가져오기 버튼이 아니라 코어의 기능 지원 여부가 원인일 수 있습니다.

예를 들어 그래픽 인터페이스는 여전히 Clash라는 제품명을 쓰지만 실제 코어는 mihomo일 수 있습니다. 반대로 YAML을 가져올 수 있는 구형 클라이언트가 예전 코어를 계속 포함할 수도 있습니다. 호환성을 확인할 때는 앱 이름만 보지 말고 코어 이름과 버전을 먼저 확인한 다음 설정의 프로토콜 및 기능 필드를 살펴보세요.

클라이언트 버전: 보통 ‘설정’ → ‘정보’에서 확인할 수 있으며, 인터페이스와 서비스 구성 요소의 버전을 파악할 때 사용합니다.
코어 버전: 클라이언트의 코어 정보나 실행 로그 첫 부분에서 확인하세요. 바이너리를 직접 실행한다면 mihomo -v를 사용할 수 있습니다.
실제로 적용된 설정: 클라이언트가 제공하는 실행 설정 미리보기나 시작 로그에서 설정 파일 경로를 확인하세요. 구독 원문이 실제로 불러온 파일과 일치한다고 볼 수는 없습니다.

Clash 오리지널·Clash.Meta·mihomo의 발전 과정

Clash 오리지널은 오픈소스 버전과 Premium을 구분해야 합니다

과거의 Clash 오리지널에는 오픈소스 코어와 Premium 분기가 있었습니다. 두 버전을 같은 기능 목록으로 이해하면 안 됩니다. TUN, 규칙 제공자 등의 기능은 Premium의 지원 범위와 관련된 적이 있습니다. 구형 가이드에 구체적인 분기를 밝히지 않고 ‘Clash는 TUN을 지원한다’고만 적혀 있으면 오픈소스 버전 사용자는 해당 기능을 찾지 못할 수 있습니다.

Clash 오리지널 관련 프로젝트는 2023년에 공개 유지보수가 중단됐습니다. 기존 시스템에서 예전 바이너리가 계속 실행될 수는 있지만, 이후 추가된 프로토콜이나 설정 옵션까지 인식한다는 뜻은 아닙니다. 새 설정을 불러올 수 있는지는 해당 바이너리가 실제로 구현한 기능을 기준으로 판단해야 합니다.

Clash.Meta는 분기 프로젝트이며, 후속 프로젝트명이 mihomo입니다

Clash.Meta는 Clash를 기반으로 프로토콜, DNS, 라우팅 기능을 확장했고, 이후 프로젝트명이 mihomo로 바뀌었습니다. 따라서 Clash.Meta와 mihomo는 설정을 한 줄씩 서로 변환해야 하는 완전히 별개의 체계가 아닙니다. 구형 가이드와 구독 버튼, 파일명에는 여전히 Meta라는 표현이 쓰이지만 실제로는 mihomo 설정을 가리킬 수 있습니다.

다만 같은 발전 계보에 속한다고 해서 모든 과거 버전의 기능이 같다는 의미는 아닙니다. 초기 Meta 바이너리는 최신 mihomo 옵션을 지원하지 않을 수 있습니다. 필드 오류가 발생하면 ‘Meta라면 다 지원한다’고 단정하지 말고 사용 중인 버전에 맞는 문서와 릴리스 노트를 확인하세요.

대상	주요 용도	마이그레이션 시 확인할 점
Clash 오리지널 오픈소스	기본 프록시, 정책 그룹, 규칙 기반 분기	Premium 또는 Meta 확장 기능을 기본 지원한다고 볼 수 없음
Clash Premium	오리지널 체계의 확장 분기	스크립트 모드 등의 기능을 mihomo와 동등하다고 볼 수 없음
Clash.Meta	프로토콜과 라우팅 기능을 확장한 분기	이름은 널리 이어져 왔지만, 세부 기능은 버전에 따라 다름
mihomo	Meta 후속 프로젝트명	새 필드, 클라이언트의 설정 적용 방식, 실제 실행 설정 확인

프로토콜·규칙·TUN의 실제 차이

노드 프로토콜 지원 여부에 따라 구독을 실제로 사용할 수 있는지가 달라집니다

Clash 오리지널의 일반적인 설정은 Shadowsocks, VMess, Trojan, SOCKS5, HTTP 등의 프록시 유형을 사용합니다. mihomo는 여기에 VLESS, Hysteria2, TUIC 등의 확장 프로토콜을 추가로 지원하지만, 각 프로토콜의 전송 방식과 인증 매개변수, 세부 옵션은 버전 요구 사항을 따릅니다. 특정 프로토콜을 지원한다고 해서 해당 프로토콜의 모든 구현과 매개변수를 지원하는 것은 아닙니다.

구형 코어는 type: hysteria2처럼 알 수 없는 프록시 유형을 만나면 해당 노드를 정상적으로 불러오지 못하는 경우가 많습니다. 일부 클라이언트는 변환 또는 가져오기 단계에서 노드를 미리 걸러내기도 합니다. 구독을 갱신한 뒤 노드가 20개에서 0개로 줄었다면 먼저 가져오기 로그와 프로토콜 유형을 확인하고, 그다음 서비스 만료 여부를 살펴보세요. 바로 DNS를 바꿀 필요는 없습니다.

기본 규칙은 대체로 그대로 사용할 수 있지만, 확장 규칙은 확인이 필요합니다

DOMAIN, DOMAIN-SUFFIX, IP-CIDR, MATCH와 같은 기본 규칙은 호환성이 좋은 편입니다. 더 복잡한 논리 규칙, 프로세스 매칭, 규칙 집합 형식은 코어 지원 여부와 운영체제 기능, 데이터 파일 사용 가능 여부를 함께 확인해야 합니다. 규칙은 기본적으로 위에서 아래 순서로 매칭됩니다. 기본 처리용 MATCH를 앞에 두면 뒤에 있는 규칙은 적용되지 않습니다.

예를 들어 아래는 독립된 규칙 일부이며 전체 설정은 아닙니다. 기존 설정에 ‘프록시 선택’이라는 이름의 정책 그룹이 있다고 가정합니다. 이름이 정확히 일치해야 합니다. YAML 형식이 올바르더라도 이름이 다르면 참조 오류가 발생합니다.

rules:
  - DOMAIN-SUFFIX,example.com,프록시 선택
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,프록시 선택

여기서 no-resolve는 이 IP 규칙이 도메인 조회를 별도로 요청하지 않는다는 뜻이지, 코어 전체의 DNS가 꺼진다는 뜻은 아닙니다. 192.168.0.0/16도 사설 네트워크 대역 하나만 포함하므로, 이 예시는 전체 LAN 우회 규칙 목록이 아닙니다.

TUN은 트래픽 처리 방식이지 노드 프로토콜이 아닙니다

시스템 프록시는 보통 시스템 프록시 설정을 따르는 앱에만 영향을 줍니다. TUN은 가상 네트워크 인터페이스로 트래픽을 처리해 적용 범위가 더 넓지만, 권한과 라우팅, DNS 설정이 함께 필요합니다. Clash 오리지널 Premium과 mihomo 모두 TUN 기능을 제공할 수 있으므로, 인터페이스에 ‘TUN’ 스위치가 있다는 이유만으로 코어가 같다고 판단해서는 안 됩니다.

마이그레이션할 때 구형 클라이언트의 가상 네트워크 어댑터, 백그라운드 서비스, 라우팅 설정을 새 클라이언트의 전제 조건으로 간주하지 마세요. 먼저 구형 클라이언트를 종료하고 트래픽 처리 기능을 끈 다음, 새 클라이언트에서 자체 서비스를 설치하거나 활성화하세요. TUN 두 개가 동시에 실행되면 기본 경로 충돌, DNS 루프, LAN 접속 오류가 발생할 수 있습니다.

기존 설정을 mihomo로 옮길 때 유지하거나 다시 확인할 항목

기존 설정 전체를 붙여 넣고 모든 기능을 한꺼번에 켜는 방식은 권장하지 않습니다. 먼저 백업한 뒤 최소한으로 동작하는 기반을 만드세요. 노드 연결, 정책 그룹 선택, 규칙 매칭을 확인한 다음 DNS 확장 기능과 TUN을 적용합니다. 이렇게 하면 각 단계에서 문제가 발생한 범위를 명확히 좁힐 수 있습니다.

필드 또는 항목	권장 조치	세부 확인 사항
`proxies`、`proxy-groups`	기본 구조부터 유지	프로토콜 옵션이 유효하고 정책 그룹 참조 이름이 존재하는지 확인
`rules`	순서를 유지하고 항목별로 검증	대상 정책 그룹이 존재하고 기본 처리 규칙이 마지막에 있는지 확인
`rule-providers`	출처와 형식 확인	`behavior`가 실제 규칙 내용과 일치하는지 확인
`dns`、`tun`	새 환경에 맞춰 다시 확인	포트, 네트워크 대역, 권한, 라우팅에 충돌이 없는지 확인
`script`	그대로 옮기지 않기	Premium 스크립트 분기 기능은 지원되는 규칙 로직으로 다시 작성
`external-controller`、`secret`	클라이언트의 트래픽 처리 방식 확인	컨트롤 포트가 충돌하지 않고 접근 키가 설정 파일에 노출되지 않는지 확인

포트와 로컬 경로는 특히 놓치기 쉽습니다

예를 들어 기존 설정에서 mixed-port: 7890을 사용하고 새 클라이언트도 7890을 수신 대기 중이라면, 기존 프로세스가 종료되지 않았을 때 포트 충돌이 발생할 수 있습니다. 새 클라이언트의 포트를 7897로 바꿨더라도 터미널의 프록시 환경 변수가 계속 127.0.0.1:7890을 가리키면 터미널 요청은 이전 포트로 전송됩니다. 여기의 숫자는 흔히 볼 수 있는 설정 예시일 뿐, 모든 클라이언트의 고정 기본값은 아닙니다.

규칙 제공자와 프록시 제공자의 상대 경로 path는 보통 코어의 작업 디렉터리를 기준으로 해석해야 합니다. YAML 파일을 다른 디렉터리로 옮겨도 관련 캐시 파일까지 함께 이동한다고 보장할 수 없습니다. 새 클라이언트에서 제공자를 다시 업데이트하고 로그에서 파일이 정상적으로 저장됐는지 확인하세요. 화면에 이전 노드 이름이 남아 있는지만 확인해서는 안 됩니다.

구독 업데이트로 수정 내용이 사라질 수 있습니다

일부 클라이언트는 구독을 업데이트할 때 설정을 다시 생성해 수동으로 수정한 dns나 rules를 덮어씁니다. 클라이언트가 지원하는 덮어쓰기, 병합, 확장 설정 기능을 우선 사용하고 실제 실행 설정에서 결과를 확인하세요. 병합 규칙을 뒤에 추가할지, 대체할지, 앞에 넣을지는 클라이언트마다 다르므로 덮어쓰기 파일만 보고 최종 순서를 판단할 수 없습니다.

DNS와 fake-ip: 마이그레이션 후 조회 경로 다시 확인

fake-ip는 도메인에 가상 주소를 응답하고, 이후 연결에서 코어가 해당 주소를 원래 도메인과 연결하는 방식입니다. 특정 노드 프로토콜이 아니며 모든 DNS 요청이 지정한 리졸버를 거치도록 보장하지도 않습니다. 시스템 DNS, 브라우저의 보안 DNS, 앱 자체 DNS, TUN의 DNS 가로채기 범위가 최종 경로에 영향을 줍니다.

아래는 mihomo DNS 설정 일부로, 기존 설정에 병합해야 합니다. 예시에서는 일반적으로 사용하는 53 포트를 직접 점유하지 않도록 로컬 1053 포트에서 수신합니다. 다만 수신을 활성화하는 것만으로 운영체제의 DNS 조회가 자동으로 이 포트로 전송되지는 않습니다.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "+.example.com":
      - https://1.1.1.1/dns-query

가상 주소 범위: 198.18.0.1/16은 테스트용 주소 공간에 속합니다. 로컬 테스트 네트워크에서 이미 이 대역을 사용 중이라면 먼저 충돌을 해결해야 합니다.
도메인별 조회: nameserver-policy는 지정한 도메인에 사용할 리졸버를 정합니다. 해당 도메인의 연결을 특정 프록시 노드로 고정하는 설정은 아닙니다.
암호화된 조회: DoH는 해당 DNS 요청이 전송되는 구간을 보호합니다. 엔드포인트에 연결할 수 있는지, 요청이 어떤 경로로 라우팅되는지는 실제 네트워크 환경에서 확인해야 합니다.
주소 매핑: fake-ip 설정을 변경한 뒤에도 운영체제나 브라우저에 이전 주소가 캐시되어 있을 수 있습니다. 캐시를 비우거나 테스트 앱을 다시 시작한 뒤 새 연결을 확인하세요.

TUN으로 DNS를 처리하려면 기존 TUN 설정에서 dns-hijack을 확인하세요. 흔히 쓰이는 any:53과 tcp://any:53은 각각 일반 DNS의 UDP와 TCP 트래픽을 대상으로 합니다. 실제 가로채기 효과는 플랫폼과 라우팅 구현에도 영향을 받습니다. 앱이 HTTPS로 직접 전송하는 DoH는 53번 포트로 나가는 일반 DNS가 아니므로, 이런 가로채기가 DoH 요청까지 자동으로 바꿔 줄 것으로 기대해서는 안 됩니다.

설정 마이그레이션 검증: 문법 검사부터 TUN 적용까지

1단계: 설정을 불러올 수 있는지 확인

코어를 직접 사용하는 경우 먼저 아래 명령을 실행할 수 있습니다. Windows에서는 명령의 프로그램명을 로컬의 mihomo.exe로 바꾸고 설정 파일이 있는 디렉터리에서 실행하세요. 그래픽 클라이언트라면 실행 중인 포트를 두 프로세스가 함께 사용하지 않도록 클라이언트의 설정 검사 기능을 우선 사용하세요.

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

검사를 통과했다는 것은 해당 테스트에서 설정을 불러오는 조건을 충족했다는 뜻일 뿐, 노드 서버에 연결할 수 있거나 모든 규칙이 예상대로 동작한다는 뜻은 아닙니다. 오류가 특정 행을 가리키면 바로 앞 행의 들여쓰기, 콜론, 목록 기호도 함께 살펴보세요. YAML에서 탭으로 들여쓰기하거나 최상위 키를 중복해서 쓰면 알아채기 어려운 문제가 생길 수 있습니다.

2단계: 노드 하나만 사용해 프록시 연결 확인

기존 클라이언트를 종료하고 새 클라이언트의 TUN을 잠시 끈 다음, 규칙 모드에서 정상 작동을 확인한 노드 하나를 선택하세요.
실제 혼합 포트를 확인하세요. 설정이 7890이라면 아래 명령에서 해당 포트를 지정해 테스트 도메인에 요청을 보낼 수 있습니다.
연결 기록에서 대상 도메인, 매칭된 규칙, 최종 노드를 확인하세요. 프록시를 명시해 연결이 성공한 뒤 시스템 프록시를 켜고 일반 앱에서도 확인합니다.
마지막으로 TUN을 활성화하고 브라우저, 터미널, 시스템 프록시를 따르지 않는 앱을 각각 테스트하세요. LAN 접속도 정상인지 확인합니다.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

여기서 10초 연결 시간 제한과 20초 전체 시간 제한은 테스트 대기 시간을 조절하는 값이지, 네트워크 속도 지표가 아닙니다. 로컬 포트 연결 실패가 표시되면 먼저 포트가 수신 중인지 확인하세요. 로그에 프록시 핸드셰이크 오류가 기록된다면 로컬 포트를 계속 바꾸기보다 노드 인증, 전송 매개변수, 연결 경로를 살펴봐야 합니다.

3단계: 구독 업데이트와 롤백 확인

구독과 규칙 제공자를 한 번 수동으로 업데이트한 다음, 사용자 지정 규칙, DNS 덮어쓰기, 정책 그룹 선택이 유지되는지 확인하세요. 완료되면 새 클라이언트의 실제 설정을 백업하고 기존 설정도 오프라인 사본으로 보관합니다. 이전 환경으로 되돌릴 때는 새 클라이언트의 트래픽 처리를 먼저 중지한 뒤 기존 환경을 복원해 두 클라이언트가 시스템 프록시와 라우팅을 동시에 변경하지 않도록 하세요.

코어 선택 결론: 설정 요구 사항과 유지보수 상태를 기준으로 판단

기존 Clash 형식 구독을 계속 사용하면서 최신 프로토콜, 규칙, DNS 기능이 필요하다면 mihomo를 명확히 통합했고 코어 버전과 실행 로그를 확인할 수 있는 클라이언트를 선택하세요. 기존 설정이 Premium에서 가져온 것이라면 프로그램 파일명만 바꾸기보다 스크립트 로직, 제공자, TUN, DNS를 중점적으로 옮겨야 합니다.

기본 트래픽 분기만 필요한 경우: 먼저 노드, 정책 그룹, 기본 규칙이 안정적으로 동작하도록 설정하세요. 기능 이름에 맞춰 모든 옵션을 한꺼번에 켤 필요는 없습니다.
새 프로토콜이 필요한 경우: 사용 중인 코어 버전과 프로토콜 필드를 확인하고, 서비스 제공자가 Meta 또는 mihomo 호환이라고 명시한 설정을 우선 사용하세요.
전체 트래픽을 처리해야 하는 경우: 플랫폼 권한, TUN 서비스, DNS 경로를 확인하고 ‘명시적 프록시 → 시스템 프록시 → TUN’ 순서로 검증하세요.
장기간 사용할 경우: 클라이언트와 코어 업데이트를 모두 확인하세요. 인터페이스 업데이트와 코어 업데이트는 별개이므로 업그레이드 후에도 주요 설정을 다시 점검해야 합니다.

Clash.Meta와 mihomo의 이름 관계는 출발점일 뿐입니다. 설정을 옮길 수 있는지를 실제로 결정하는 것은 실행 중인 코어 버전, 적용된 설정 내용, 로컬 포트와 권한, DNS 조회 경로입니다. 이 항목을 하나씩 기록해 두면 문제가 생겼을 때 해당 계층부터 정확히 확인할 수 있습니다.