먼저 명칭부터 구분하기: 클라이언트, 커널, 프로젝트의 흐름
Clash 클래식, Clash.Meta, mihomo를 비교하기 전에 ‘클라이언트’와 ‘커널’을 먼저 구분해야 합니다. 커널은 YAML 설정을 읽고, 프록시 연결을 만들며, 규칙을 매칭하고, DNS를 처리한 뒤 그래픽 인터페이스에 제어 기능을 제공합니다. 데스크톱 클라이언트는 구독 관리, 설정 전환, 시스템 프록시 켜기·끄기, 로그 확인과 업데이트를 담당합니다. 사용자가 보는 앱 이름이 실제로 호출하는 커널 이름과 항상 같은 것은 아니며, 하나의 그래픽 클라이언트가 버전에 따라 다른 커널로 바뀌기도 합니다.
일반적으로 Clash 클래식이라고 하면 Dreamacro가 관리하던 전통적인 Clash 오픈 소스 커널과 그 설정 체계를 가리킵니다. 프록시 노드, 프록시 그룹, 규칙, 외부 컨트롤러 같은 핵심 구조를 정립했으며, 많은 구독 변환 서비스와 그래픽 클라이언트가 이 형식을 기반으로 합니다. 과거에는 기능 범위가 다른 Premium 빌드도 있었으므로, ‘Clash’라는 이름만 보고 어떤 필드를 지원하는지 단정할 수 없습니다.
Clash.Meta는 처음에는 Clash 설정 방식을 호환하는 확장 커널로 시작해 더 많은 프록시 프로토콜, DNS 옵션, 규칙 기능과 투명 프록시 관련 기능을 추가했습니다. 이후 프로젝트는 공식적으로 mihomo라는 이름을 사용하게 되었습니다. Clash.Meta와 mihomo는 완전히 독립된 두 커널 중 하나를 고르는 관계가 아니라, 같은 프로젝트 계보에서 시기별로 사용된 명칭으로 이해하면 됩니다. 예전 튜토리얼의 Meta 설정이나 구형 클라이언트의 Meta Core는 오늘날의 mihomo 계열을 가리키는 경우가 많습니다.
클래식 Clash 프로젝트의 활발한 유지 관리가 중단된 뒤에도 생태계가 이름과 함께 멈춘 것은 아닙니다. 구독 형식, 규칙 문법과 제어 인터페이스는 여전히 많은 소프트웨어에서 사용되고 있으며, 지속적으로 업데이트되는 클라이언트는 점차 mihomo로 전환되었습니다. 현재 새로 설치하거나 장기간 운영할 때는 가장 오래된 이름의 버전을 찾기보다 유지 관리 상태, 플랫폼 지원, 필요한 프로토콜과 설정 필드가 서로 맞는지 확인해야 합니다.
기능 범위: 공통 기반과 mihomo 확장 기능
두 커널의 공통 기반에는 YAML 설정, 프록시 노드, 프록시 그룹, 도메인 및 IP 규칙, DIRECT·REJECT 동작, HTTP/SOCKS 혼합 포트와 외부 제어 인터페이스가 포함됩니다. 일반적인 노드, 단순한 프록시 그룹과 기본 규칙만 사용하는 설정이라면 차이를 크게 느끼지 못할 수 있습니다. 차이는 구독에 새로운 프로토콜이 포함되거나, 복잡한 DNS를 사용하거나, TUN 모드를 활성화하거나, 원격 규칙 세트를 불러올 때 주로 나타납니다.
프록시 프로토콜과 전송 매개변수
클래식 Clash는 유지 관리되던 시기에 널리 쓰이던 주요 프로토콜을 지원하지만, 이후 등장한 새로운 프로토콜과 암호화 방식, 전송 확장은 자동으로 지원되지 않습니다. mihomo는 기존 설정과의 호환성을 유지하면서 프로토콜 구현과 매개변수 옵션을 계속 추가하고 있습니다. 구독의 노드가 ‘지원되지 않는 유형’으로 표시되거나 로그에 프록시 필드를 해석할 수 없다는 메시지가 나오면, 같은 구독을 반복해서 다시 가져오기보다 먼저 커널을 확인해야 합니다.
프로토콜 수만으로 판단할 수는 없습니다. 노드 유형이 같더라도 커널마다 TLS 지문, UDP, 멀티플렉싱, 전송 계층과 인증서 관련 매개변수의 지원 범위가 다를 수 있습니다. 선택할 때는 노드 이름이 목록에 보이는지만 보지 말고 실제 구독에서 생성된 필드를 기준으로 확인해야 합니다. 노드가 인터페이스에 표시된다고 해서 연결 매개변수가 모두 정확히 인식된 것은 아닙니다.
DNS와 규칙 시스템
기본 Clash 설정에는 이미 도메인 규칙, IP 규칙, GEOIP, 규칙 제공자 같은 일반적인 구조가 포함되어 있습니다. mihomo는 여기에 더 다양한 DNS 처리 방식, 규칙 집합 기능과 매칭 옵션을 제공하므로, 중국 본토와 해외의 DNS 조회를 구분하거나 Fake IP 예외를 처리하고, 대규모 규칙 세트를 불러오거나 트래픽을 세밀하게 제어해야 하는 설정에 적합합니다. 세부 필드는 커널 버전에 따라 바뀔 수 있으므로 현재 커널 문서와 시작 로그를 기준으로 판단해야 합니다.
규칙 기능이 늘어나면 설정 오류가 긴 파일 속에 숨어 발견하기 어려워집니다. 예를 들어 규칙 세트 이름은 선언했지만 참조 경로에 접근할 수 없거나, DNS nameserver에는 연결되지만 현재 라우팅 규칙에 의해 다시 프록시로 보내져 순환이 발생할 수 있습니다. 규칙 순서가 올바르더라도 앞의 광범위한 매칭 때문에 뒤의 세부 항목까지 도달하지 못할 수 있습니다. 커널 업그레이드가 규칙 검토를 대신할 수는 없으며, 로그의 매칭 결과가 여전히 가장 중요한 근거입니다.
TUN과 투명 프록시
시스템 프록시는 운영체제의 프록시 설정을 적극적으로 읽는 앱에 주로 영향을 줍니다. TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 IP 트래픽을 가로채므로, 시스템 프록시를 따르지 않거나 UDP가 필요하거나 앱 트래픽을 통합 처리해야 하는 환경에 적합합니다. 클래식 Clash는 빌드에 따라 TUN 지원이 서로 다르지만, mihomo는 TUN 스택, 라우팅, DNS 하이재킹과 플랫폼별 옵션을 계속 유지 관리하고 있어 최신 데스크톱 클라이언트와 게이트웨이 배포에서는 보통 mihomo를 더 많이 사용합니다.
TUN을 활성화한다고 설치 후 속도가 자동으로 빨라지는 것은 아닙니다. 권한, 라우팅 테이블, 가상 네트워크 어댑터, 방화벽과 DNS 경로라는 추가 변수가 생깁니다. 웹 브라우징만 하고 앱이 시스템 프록시를 따르는 경우에는 시스템 프록시가 관리하기 쉽습니다. 게임, 명령줄 프로그램, 샌드박스 앱 또는 개별 프록시 설정이 불가능한 소프트웨어의 트래픽을 가로채야 할 때 TUN을 활성화하는 편이 적절합니다.
설정 호환성: 기본 설정은 읽히는 경우가 많지만 확장 필드의 역방향 호환은 보장되지 않음
mihomo의 설계 목표 중 하나는 Clash 설정 생태계를 이어받는 것이므로, 기존의 포트, 노드, 프록시 그룹과 규칙 구조는 대체로 바로 읽을 수 있습니다. 호환 관계는 ‘새 커널이 기존 형식을 읽는 것’에 가깝지, 어느 방향으로든 완전히 동일하다는 뜻은 아닙니다. mihomo 전용 프로토콜, 규칙 유형, DNS 필드나 TUN 매개변수를 사용한 설정을 클래식 커널에 넘기면 시작 실패, 알 수 없는 필드 무시, 노드 누락 또는 동작 변경이 발생할 수 있습니다.
다음은 기본에 가까운 구조 예시입니다. 노드, 프록시 그룹과 규칙 사이의 참조 관계를 보여 주며, 그대로 운영 환경에 투입할 수 있다는 뜻은 아닙니다. 서버 주소와 인증 정보는 실제 구독에서 제공해야 합니다.
mixed-port: 7890
mode: rule
log-level: info
proxies:
- name: example-node
type: socks5
server: 192.0.2.10
port: 1080
username: demo
password: demo
proxy-groups:
- name: PROXY
type: select
proxies:
- example-node
- DIRECT
rules:
- DOMAIN-SUFFIX,example.org,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY이런 설정을 마이그레이션할 때 가장 먼저 확인할 것은 들여쓰기 외관이 아니라 참조 관계입니다. 프록시 그룹의 노드 이름은 노드 정의와 완전히 일치해야 하고, 규칙 끝의 정책 이름은 실제로 존재해야 하며, 원격 제공자의 이름도 프록시 그룹이나 규칙의 참조와 일치해야 합니다. YAML은 들여쓰기에 민감하므로 Tab과 공백을 섞거나, 콜론 뒤에 공백을 넣지 않거나, 같은 수준의 필드 들여쓰기가 맞지 않으면 불러오기에 실패합니다.
구독 링크가 고정된 커널 형식을 의미하는 것은 아님
구독 서비스는 클라이언트의 요청 헤더, 링크 매개변수 또는 변환 템플릿에 따라 서로 다른 내용을 반환할 수 있습니다. 같은 구독 주소라도 한 클라이언트에서는 Clash 기본 형식이, 다른 클라이언트에서는 mihomo 확장 필드가 포함된 설정이 반환될 수 있습니다. 클라이언트를 바꾼 뒤 노드 수가 달라졌다고 해서 곧바로 구독이 만료되었다고 판단해서는 안 됩니다. 먼저 설정을 내보내 노드 유형, 프록시 제공자, 프록시 그룹과 규칙 세트 필드를 비교하세요.
일부 클라이언트는 구독 주소만 저장하고 업데이트할 때 로컬 편집 내용을 덮어씁니다. 규칙을 추가해야 한다면 클라이언트가 오버라이드, 확장 스크립트 또는 설정 병합 기능을 제공하는지 확인하세요. 캐시 파일을 직접 수정하면 다음 구독 업데이트 전까지만 유지되는 경우가 많습니다. 커널은 최종 설정을 해석하고, 클라이언트는 구독을 다운로드·변환·병합하는 방식을 결정하므로 두 단계를 나누어 점검해야 합니다.
제어 인터페이스는 대체로 비슷하지만 관리 화면은 별도로 맞아야 함
많은 Clash 관리 패널은 외부 컨트롤러를 통해 프록시, 연결, 규칙과 로그를 읽습니다. mihomo는 자주 사용되는 인터페이스를 상당 부분 이어받았기 때문에 기존 패널이 계속 작동할 수 있지만, 새 기능이 구형 화면에 모두 표시된다는 보장은 없습니다. 커널은 정상적으로 실행되는데 화면에서 특정 설정이 보이지 않는다면, 커널 설정이 잘못된 것이 아니라 클라이언트나 패널이 해당 제어 항목을 아직 구현하지 않았을 가능성이 있습니다.
환경별 선택: 데스크톱, 서버와 기존 설정을 나누어 판단하기
새로 설치하는 데스크톱 클라이언트
Windows, macOS 또는 Linux 데스크톱 환경에 새로 설치한다면 계속 유지 관리되고 mihomo 커널 사용을 명확히 밝힌 클라이언트를 우선 선택하세요. 새로운 프로토콜 지원, 최신 운영체제 대응과 지속적인 오류 수정이 더 수월합니다. 설치 패키지를 고를 때는 운영체제 버전과 CPU 아키텍처도 확인해야 합니다. 예를 들어 x64와 ARM64는 파일 크기만으로 구분할 수 없습니다.
데스크톱 사용자가 구독을 가져오고 프록시 그룹을 선택한 뒤 시스템 프록시만 켜면 된다면, ‘기능이 더 많다’는 이유로 고급 설정을 바로 바꿀 필요는 없습니다. 먼저 클라이언트가 생성한 기본 포트와 DNS 설정을 사용해 브라우저 접속, 규칙 전환과 연결 해제 후 복구가 정상인지 확인한 다음 필요할 때 TUN을 활성화하세요. 처음부터 변수를 줄이면 문제 원인을 더 쉽게 찾을 수 있습니다.
서버, 라우터와 컨테이너 배포
서버나 사이드 게이트웨이는 완전한 그래픽 인터페이스가 없는 경우가 많으므로 커널 자체의 아키텍처 빌드, 시작 매개변수, 설정 경로와 서비스 관리 방식이 더 중요합니다. mihomo는 규칙 세트, 투명 프록시, 원격 제어와 지속적인 업데이트가 필요한 배포에 적합하지만, 실행 권한, 포워딩 규칙, DNS 진입점과 로그 로테이션도 함께 구성해야 합니다. 컨테이너에서 TUN을 활성화할 때는 필요한 장치와 네트워크 권한도 컨테이너에 제공해야 합니다.
게이트웨이 환경에서는 데스크톱 설정을 그대로 복사하지 않는 것이 좋습니다. 데스크톱의 수신 주소가 로컬 호스트에만 바인딩되어 있을 수 있으므로 LAN에서 사용하려면 허용할 인터페이스와 접근 제어를 명확히 지정해야 합니다. 외부 컨트롤러 역시 인증과 네트워크 제한 없이 노출해서는 안 됩니다. 규칙 수가 많다면 시작 시간, 메모리 사용량과 원격 규칙 업데이트 실패 시의 동작도 확인해야 합니다.
현재 안정적으로 실행 중인 클래식 설정
기능이 단순하고 실행 환경이 고정되어 있으며 현재 연결도 안정적인 클래식 Clash 설정이라면, 이름이 바뀌었다는 이유만으로 즉시 다시 작성할 필요는 없습니다. 더 안전한 방법은 격리된 디렉터리에 mihomo를 준비하고 설정을 복사해 문법 검사와 병행 검증을 진행하는 것입니다. 노드, 프록시 그룹, DNS 결과와 규칙 매칭이 일치하는지 확인한 뒤 서비스를 전환하세요.
구형 커널을 계속 사용할 때의 주요 제약은 이후 등장하는 프로토콜과 시스템 변화에 지속적으로 대응하기 어렵다는 점입니다. 구독 제공자가 노드 유형을 바꾸면 구형 커널이 갑자기 이를 해석하지 못할 수 있고, 운영체제 업데이트 후에는 구형 클라이언트에서 권한, 트레이, 가상 네트워크 어댑터 또는 서명 호환 문제가 발생할 수 있습니다. 사용 가능한 설정은 유지하되 마이그레이션 경로도 함께 준비하는 것이 좋습니다.
기존 필드나 구형 클라이언트에 의존해야 하는 경우
일부 자동화 스크립트, 제어 패널 또는 임베디드 장치는 특정 Clash API와 파일 구조만 대상으로 개발되어 있습니다. 이때는 먼저 의존 지점을 확인해야 합니다. 설정 문법인지, 제어 인터페이스인지, 바이너리 이름인지, 시작 매개변수인지 구분하세요. mihomo는 적절한 매개변수와 경로 설정으로 많은 흐름과 호환할 수 있지만, 모든 주변 도구를 수정 없이 사용할 수 있다고 가정해서는 안 됩니다. 기존 컨트롤러와 수신 포트가 충돌하지 않도록 테스트 포트에서 먼저 실행하세요.
Clash 클래식에서 mihomo로 마이그레이션하기: 항목별 점검
- 현재 상태를 기록합니다. 기존 설정, 구독 주소, 클라이언트 버전, 커널 버전, 수신 포트와 현재 활성화된 프록시 모드를 저장하세요. 문제가 생기면 정확히 되돌리고 비교할 수 있습니다.
- 환경에 맞는 빌드를 선택합니다. 운영체제와 CPU 아키텍처를 확인하세요. 데스크톱 클라이언트는 내장 커널 유형을 확인하고, 명령줄 배포는 해당 플랫폼용 mihomo 실행 파일을 내려받았는지 확인해야 합니다.
- 먼저 설정을 검증합니다. 첫 단계부터 현재 실행 중인 서비스를 교체하지 마세요. 새 커널로 YAML을 검사하고, 알 수 없는 프록시 유형, 중복 포트, 누락된 프록시 그룹과 읽을 수 없는 제공자를 처리하세요.
- 시작 로그를 확인합니다. 설정 해석, 규칙 세트 다운로드, DNS 수신, 외부 컨트롤러, TUN 장치와 포트 사용 여부를 중점적으로 살펴보세요. 로그에 ‘시작됨’이 표시되었다고 해서 모든 원격 리소스가 성공적으로 로드된 것은 아닙니다.
- 프록시 그룹을 검증합니다.수동 선택, 자동 속도 측정, 장애 조치 등 각 프록시 그룹에 예상한 노드가 포함되어 있는지 확인하세요. 구독 변환 후 노드 이름이 바뀌면 기존 참조가 무효화될 수 있습니다.
- DNS를 검증합니다.국내 도메인, 프록시 대상 도메인과 순수 IP 연결을 각각 확인하세요. 브라우저에서는 열리지만 명령줄에서는 실패하거나, 도메인만 실패하고 IP는 연결된다면 먼저 DNS 수신과 하이재킹 경로를 점검해야 합니다.
- 마지막으로 TUN을 활성화합니다. 시스템 프록시 모드가 정상 작동하는지 확인한 뒤 가상 네트워크 어댑터를 통한 트래픽 가로채기를 테스트하세요. 전체 네트워크가 끊기면 관리자 권한, 기본 경로, DNS 하이재킹, 다른 VPN 소프트웨어와 방화벽 규칙을 확인해야 합니다.
자주 발생하는 마이그레이션 오류
- 클라이언트는 업그레이드했지만 실제 커널은 구버전에 머물러 있으며, 인터페이스 버전과 커널 버전을 혼동한 경우입니다.
- Meta와 mihomo를 서로 무관한 두 형식으로 보고 구독을 중복 변환해 프록시 그룹이나 규칙이 두 번 가공된 경우입니다.
- mihomo 전용 필드를 클래식 Clash에 그대로 복사한 뒤 설정을 불러올 때 지원되지 않는 유형이나 매개변수임을 발견하는 경우입니다.
- 첫 화면이 열리는지만 확인하고 규칙 매칭, UDP, DNS, LAN 접속과 연결 해제 후 네트워크 복구를 점검하지 않은 경우입니다.
- 시스템 프록시와 TUN을 동시에 켠 뒤 문제가 발생했지만 두 가지 트래픽 처리 경로를 따로 테스트하지 않은 경우입니다.
새 커널을 시작한 뒤 네트워크가 전혀 연결되지 않으면 먼저 규칙 모드의 기본 설정으로 되돌리고 TUN을 잠시 끄세요. 혼합 포트 수신, 노드 핸드셰이크와 프록시 그룹 선택이 올바른지 확인한 다음 DNS 확장 기능과 규칙 세트를 하나씩 다시 활성화하세요. 고급 옵션을 한 번에 모두 가져오기보다 계층적으로 활성화하는 편이 문제를 찾기 쉽습니다.
결론: 새로 배포할 때는 mihomo를 우선하고, 기존 설정은 필요에 따라 마이그레이션
클래식 Clash는 오늘날에도 널리 사용되는 설정과 규칙의 기반을 마련했습니다. Clash.Meta는 확장 계보에서 사용되던 이전 명칭이고, mihomo는 현재 이 프로젝트가 사용하는 이름입니다. 세 가지는 단순히 버전 번호의 높고 낮음으로 나뉘는 관계가 아니라 유지 관리 단계, 기능 범위와 생태계 계승의 관계로 이해해야 합니다.
데스크톱 클라이언트를 새로 설치하거나 최신 프로토콜, 복잡한 DNS, 규칙 세트 또는 TUN이 필요한 사용자는 일반적으로 mihomo를 명확히 사용하며 지속적으로 유지 관리되는 클라이언트를 선택해야 합니다. 기존 클래식 설정이 장기간 안정적으로 작동한다면 먼저 유지하고 테스트 환경에서 마이그레이션을 완료하세요. 적합성을 판단하는 신뢰할 수 있는 기준은 이름이 아니라 현재 커널이 구독을 완전히 해석하고, 규칙을 정확히 실행하며, 운영체제에 맞고 지속 가능한 업데이트 경로를 제공하는지 여부입니다.
설치가 끝나면 먼저 커널 정보를 확인한 뒤 구독을 가져오고, 시스템 프록시를 검증한 다음 환경에 맞게 TUN을 활성화하세요. 시작 로그를 먼저 읽은 뒤 고급 필드를 수정하세요. 이 순서대로 진행하면 클래식, Meta와 mihomo의 명칭 차이가 문제 해결을 방해하지 않습니다.