Clash 다운로드나 설정 방법을 검색하다 보면 Clash, Clash Meta, Mihomo, Clash Verge Rev, FlClash 같은 이름을 한꺼번에 접하게 됩니다. 이들은 하나의 프로그램을 버전별로 부르는 명칭이 아니며, 단순히 “최신판”과 “구버전”으로 나눌 수도 없습니다. 각 프로젝트는 코어, 그래픽 클라이언트, 설정 파일, 라우팅 데이터, 구독 서비스 등 서로 다른 계층에 속합니다. 이름이 비슷한 이유는 같은 설정 방식과 프록시 분기 체계를 이어받았기 때문입니다.

현재 기기에 적합한 프로젝트인지 판단할 때는 이름에 Clash가 들어갔는지만 봐서는 안 됩니다. 어떤 코어를 사용하는지, 어떤 설정 필드를 지원하는지, 계속 버전이 출시되는지, 그래픽 인터페이스에서 시스템 프록시·TUN·DNS·설정 업데이트를 관리할 수 있는지를 확인하는 편이 정확합니다. 계층을 나누어 이해하면 클라이언트 마이그레이션, 구독 가져오기, 설정 문제 해결이 훨씬 명확해집니다.

먼저 코어, 클라이언트, 설정 데이터를 구분하기

Clash 생태계는 네트워크 연결을 처리하는 코어, 조작과 표시를 담당하는 클라이언트, 노드와 트래픽 분기 규칙을 정의하는 설정 데이터라는 세 가지 주요 계층으로 나눌 수 있습니다. 대부분의 사용 문제는 이 세 계층을 혼동하면서 발생합니다.

코어가 실제 프록시 처리와 규칙 매칭을 담당합니다

코어는 프록시 프로그램의 실행 주체입니다. 로컬 리스닝 포트를 열고 프록시 서버와 연결하며 DNS 설정을 해석하고 규칙 목록에 따라 정책 그룹을 선택합니다. 시스템 프록시, 브라우저 또는 다른 애플리케이션이 트래픽을 로컬 포트로 전달한 뒤 실제 연결 경로를 결정하는 것은 클라이언트 화면의 버튼 모양이 아니라 코어입니다.

기존 Clash 코어는 Go로 작성되었으며, 프록시 노드·프록시 제공자·정책 그룹·규칙 등의 개념을 포함한 YAML 설정 구조를 정립했습니다. 원 프로젝트의 활발한 유지보수가 중단된 뒤 생태계의 중심은 호환 포크로 이동했습니다. 현재 널리 사용되는 Mihomo는 Clash.Meta 포크에서 비롯되었고, Clash 설정 문법을 대폭 유지하면서 DNS·TUN·트래픽 스니핑·라우팅 데이터·프로토콜 관련 기능을 추가했습니다.

클라이언트가 그래픽 인터페이스와 시스템 연동을 제공합니다

클라이언트는 보통 데스크톱이나 모바일에서 실행되는 그래픽 프로그램입니다. 설정을 다운로드하고 전환하며, 노드 지연 시간을 표시하고, 시스템 프록시를 제어하고, TUN에 필요한 권한을 요청하고, 코어를 실행하며 로그를 보여줍니다. 클라이언트 자체는 네이티브 UI, 웹 기술 기반 데스크톱 셸, 크로스플랫폼 툴킷 등 다양한 방식으로 개발할 수 있습니다. 이는 내부에서 어떤 프록시 코어를 호출하는지와는 별개의 문제입니다.

일부 클라이언트는 코어를 설치 패키지에 포함해 클라이언트 업데이트와 함께 코어도 업데이트합니다. 다른 클라이언트는 코어 파일을 별도로 다운로드하거나 전환하거나 직접 지정할 수 있습니다. 따라서 같은 이름의 클라이언트라도 배포판에 따라 포함된 코어 버전이 다를 수 있습니다. 설정 필드가 적용되지 않을 때는 클라이언트 이름만 보지 말고 “정보”, “코어 설정” 또는 시작 로그에서 실제 코어 이름과 버전을 먼저 확인해야 합니다.

설정, 구독, 규칙 데이터는 클라이언트 본체가 아닙니다

YAML 설정은 포트, 노드, 정책 그룹, DNS와 규칙을 정의합니다. 구독 URL은 설정 데이터를 가져오는 진입점이며, 반환되는 내용은 완전한 Clash 설정일 수도 있고 노드 목록만 포함할 수도 있습니다. 후자의 경우 클라이언트나 구독 변환 서비스가 정책 그룹을 추가로 생성합니다. GeoIP, GeoSite, MMDB와 규칙 집합 파일은 트래픽 분기 데이터에 속합니다. 코어가 이를 읽고 업데이트할 수 있지만, 이 파일들은 코어 프로그램 자체가 아닙니다.

따라서 그래픽 클라이언트를 바꾼다고 기존 구독이 반드시 무효가 되는 것은 아니며, 코어를 바꾼다고 기존 설정을 그대로 사용할 수 없는 것도 아닙니다. 마이그레이션 가능 여부는 구독 출력 형식, 설정에 사용된 확장 필드, 대상 코어의 해당 필드 지원 여부에 따라 달라집니다.

Clash, Clash Meta, Mihomo의 유지보수 관계

기존 Clash는 설정 모델과 규칙 라우팅 방식을 정립했습니다. 원 프로젝트의 지속적인 출시가 중단되면서 커뮤니티 포크가 새로운 프로토콜 지원, 운영체제 호환성, 기능 확장을 맡기 시작했습니다. Clash.Meta는 그중 영향력이 큰 포크였고, 이후 Mihomo라는 이름으로 유지보수가 이어졌습니다. 따라서 현재 생태계에서 “Clash 설정”은 호환 가능한 설정 형식을 뜻하는 경우가 많으며, 실제로 기존 Clash 코어가 실행 중이라는 의미는 아닐 수 있습니다.

포크는 프로젝트 이름만 바꾼 것이 아닙니다. Mihomo는 기존 설정을 기반으로 여러 기능을 확장했으며, 서로 다른 시기에 출시된 버전 사이에서도 필드, 기본값, 리소스 형식이 변경될 수 있습니다. 어떤 설정 파일이 Mihomo에서 로드된다고 해서 오래된 Clash 코어가 그 내용을 모두 인식할 수 있다는 뜻은 아닙니다. 특히 복잡한 TUN 매개변수, 확장 DNS 동작, 트래픽 스니핑, GeoSite 규칙, 특정 프록시 프로토콜은 버전 호환성의 영향을 받기 쉽습니다.

다음은 계층 관계를 설명하기 위한 간단한 설정 예시입니다. 클라이언트가 파일을 읽어 코어를 실행하면 코어가 로컬 포트를 열고 정책 그룹과 최종 규칙에 따라 연결을 처리합니다.

mixed-port: 7890
mode: rule

proxies: []

proxy-groups:
  - name: 노드 선택
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,노드 선택

실제 구독에는 노드 정의, 프록시 제공자, DNS, 규칙 제공자와 더 완전한 정책 그룹이 추가되는 경우가 많습니다. “설정 파싱 실패”가 발생하면 전체 설정 구간을 바로 삭제하지 말고 로그에서 문제가 된 필드를 찾아야 합니다. YAML은 들여쓰기에 민감하며, 필드 지원 여부는 코어 종류와 버전에 따라 달라집니다. 두 문제는 따로 판단해야 합니다.

프로젝트가 계속 유지보수되는지 확인하는 방법

프로젝트 이름에 Rev, Next, Meta 또는 Community가 들어간다고 해서 유지보수 상태가 보장되지는 않습니다. 유지보수 여부를 확인하려면 최근 정식 버전, 릴리스 노트, 코드 커밋, 이슈 처리 기록, 지원 운영체제 버전을 살펴보는 것이 좋습니다. 클라이언트 설치 패키지만 제공되는 프로젝트라면 포함된 코어 버전도 함께 업데이트되는지 확인해야 합니다.

  • 코어 버전: 실행 로그나 클라이언트 정보 화면에서 Mihomo, 기존 Clash 또는 다른 호환 구현 중 무엇인지 확인합니다.
  • 클라이언트 버전: 클라이언트 버전과 코어 버전은 보통 별도의 번호 체계를 사용하므로 서로 대신할 수 없습니다.
  • 출시일: 프로젝트 이름에 적힌 “신규 버전”이라는 표현보다 정식 버전이 꾸준히 출시되는지가 더 중요한 참고 기준입니다.
  • 플랫폼 지원: 현재 사용하는 Windows, macOS, Linux 또는 Android 버전이 여전히 지원 범위에 포함되는지 확인합니다.
  • 업데이트 방식: 코어가 클라이언트와 함께 업데이트되는지, 아니면 설정에서 별도로 업데이트해야 하는지 확인합니다.

주요 그래픽 클라이언트는 생태계의 어느 계층에 속할까요?

Clash Verge Rev, Clash Nyanpasu, FlClash 등은 우선 그래픽 클라이언트에 해당하며, 일반적으로 Mihomo 또는 호환 코어를 기반으로 설정 관리와 시스템 연동을 제공합니다. 이들의 주요 차이는 프록시 규칙의 원리가 아니라 지원 플랫폼, UI 구현 방식, 코어 관리 방법, TUN 권한 처리, 설정 오버라이드 기능과 업데이트 주기입니다.

데스크톱 클라이언트는 일반적으로 시스템 프록시 전환, 노드 선택, 연결 기록, 설정 구독 업데이트, 지연 시간 테스트를 제공합니다. Windows와 macOS에서는 시작 시 자동 실행, 시스템 프록시 복원, 관리자 권한, 시스템 트레이 동작도 처리해야 합니다. Linux는 데스크톱 환경이 다양하므로 시스템 프록시를 적용하는 방식과 트레이 호환성이 배포판에 따라 달라질 수 있습니다. 따라서 같은 클라이언트라도 데스크톱 환경에 따라 사용 경험이 완전히 같지는 않습니다.

Android 클라이언트는 보통 시스템 VPN 인터페이스를 통해 트래픽을 가로채며, 이는 데스크톱에서 “시스템 프록시”를 선택하는 방식과 다릅니다. 앱별 분기, 백그라운드 상시 실행, IPv6와 프라이빗 DNS 지원 여부도 클라이언트 구현과 시스템 제한에 따라 달라집니다. 데스크톱과 모바일 클라이언트가 모두 Mihomo를 사용한다고 해서 모든 UI 기능과 네트워크 동작이 동일하다고 볼 수는 없습니다.

과거에 널리 사용된 Clash for Windows는 데스크톱 그래픽 클라이언트이며 오픈소스 Clash 코어와는 다릅니다. 현재는 유지보수가 중단되었습니다. 예전 튜토리얼에서 해당 인터페이스를 기준으로 설명한 특정 메뉴 이름, 설정 오버라이드 위치, 서비스 모드 설치 방법은 현재 클라이언트에 그대로 적용해서는 안 됩니다. 설정의 노드와 규칙은 마이그레이션할 수 있지만, UI 설정은 새 클라이언트에서 다시 확인해야 합니다.

클라이언트 선택 시 확인해야 할 호환성 범위

클라이언트를 선택할 때는 UI를 비교하기 전에 플랫폼부터 확인해야 합니다. 데스크톱에서는 운영체제 버전과 프로세서 아키텍처를 확인해야 합니다. 예를 들어 Windows x64, Windows ARM64, macOS Apple 실리콘, Intel 프로세서용 패키지는 서로 다를 수 있습니다. 설치 패키지의 아키텍처가 맞지 않으면 프로그램이 실행되지 않거나 호환 레이어를 통해서만 실행될 수 있습니다.

코어 및 설정 호환성

현재 설정에 Mihomo 확장 필드가 포함되어 있다면 Mihomo를 명확히 사용하고 코어 업데이트도 빠른 클라이언트를 우선 선택하는 것이 좋습니다. 가져온 뒤에는 먼저 시작 로그에서 설정 파싱이 성공했는지 확인하고 정책 그룹 전환과 DNS를 테스트해야 합니다. 노드 목록이 보인다고 해서 전체 설정이 정상 적용된 것은 아닙니다. 클라이언트가 인식하지 못한 오버라이드 항목을 무시했거나 이전에 캐시된 설정을 계속 사용하고 있을 수 있습니다.

구독 호환성은 “완전한 설정 구독”과 “노드 구독”도 구분해야 합니다. 완전한 설정에는 보통 정책 그룹과 규칙이 이미 포함되어 있어 가져온 뒤 바로 사용할 수 있습니다. 노드 구독은 서버 정보만 제공하므로 클라이언트 템플릿이나 로컬 설정으로 그룹과 규칙을 보완해야 합니다. 두 URL 모두 가져오기가 가능하더라도 최종 라우팅 결과는 크게 다를 수 있습니다.

시스템 프록시와 TUN 모드

시스템 프록시는 운영체제의 프록시 설정을 따르는 프로그램에 주로 영향을 줍니다. 대부분의 브라우저와 데스크톱 애플리케이션이 여기에 해당하지만, 터미널 도구·게임·가상 머신·자체 네트워크 스택을 구현한 프로그램은 시스템 프록시를 우회할 수 있습니다. TUN 모드는 가상 네트워크 인터페이스를 생성해 더 넓은 범위의 트래픽을 가로채지만, 일반적으로 관리자 권한이나 시스템 VPN 승인이 필요하며 라우팅·DNS·방화벽 호환 문제도 발생할 수 있습니다.

따라서 TUN 지원을 단순히 UI에 스위치가 있다는 뜻으로 이해해서는 안 됩니다. 클라이언트가 서비스를 제대로 설치하는지, 종료 시 네트워크 설정을 복원하는지, 현재 운영체제가 필요한 권한을 허용하는지도 확인해야 합니다. TUN을 켠 뒤 인터넷이 끊기면 노드를 반복해서 전환하기보다 먼저 TUN을 끄고 기본 연결을 복구한 다음 코어 로그, DNS 리스닝 충돌, 라우팅 루프백, 다른 VPN 프로그램을 점검해야 합니다.

설정 관리 및 업데이트 방식

장기간 사용할 때는 한 번 가져오기에 성공했는지보다 설정을 어떻게 관리하는지가 중요합니다. 클라이언트에서 구독 업데이트 주기를 설정하고, 로컬 오버라이드를 보존하고, 여러 설정을 전환하며, 업데이트 실패 시 이전의 유효한 설정을 계속 사용할 수 있는지 확인해야 합니다. 일부 클라이언트는 구독 업데이트 후 설정을 다시 생성하므로 로컬에서 직접 수정한 내용이 덮어써질 수 있습니다. 따라서 규칙 변경은 클라이언트가 지원하는 오버라이드, 병합 또는 스크립트 기능에 넣어야 합니다.

클라이언트 자동 업데이트와 코어 자동 업데이트도 별개로 이해해야 합니다. UI 프로그램 업데이트가 성공했다고 코어까지 업데이트된 것은 아니며, 반대로 코어만 교체하면 관리 인터페이스 변경으로 클라이언트 호환 문제가 생길 수 있습니다. 안정적으로 사용하려면 클라이언트가 지원하는 업데이트 경로를 이용하고, 업그레이드 전에 현재 클라이언트 버전·코어 버전·정상 작동하는 설정을 기록해 두는 것이 좋습니다.

기존 Clash 클라이언트에서 Mihomo 클라이언트로 마이그레이션하기

마이그레이션 전에 기존 구독 URL, 현재 사용하는 YAML 파일, 수동 규칙과 정책 그룹 선택 상태를 보존해야 합니다. 클라이언트 설치 디렉터리만 복사하는 방법은 신뢰하기 어렵습니다. 프로그램마다 설정 저장 위치, 파일명, 데이터베이스 형식이 다르기 때문입니다. 가장 범용적인 마이그레이션 대상은 구독 URL과 읽을 수 있는 YAML 설정입니다.

  1. 현재 상태 기록: 기존 클라이언트와 코어 버전을 저장하고 로컬 리스닝 포트, 시스템 프록시 상태, TUN 상태 및 현재 정책 그룹 선택을 기록합니다.
  2. 설정 내보내기: 완전한 YAML 파일을 저장하고 직접 추가한 규칙, DNS 설정, 설정 오버라이드를 별도로 정리합니다.
  3. 대상 클라이언트 설치: 운영체제와 프로세서 아키텍처에 맞는 설치 패키지를 선택하고, 처음 실행할 때는 TUN을 활성화하지 않습니다.
  4. 구독 또는 파일 가져오기: 먼저 설정이 로드되는지 확인한 뒤 노드, 정책 그룹, 규칙이 모두 정상적으로 표시되는지 점검합니다.
  5. 기본 프록시 테스트: 시스템 프록시를 켜고 브라우저 접속, DNS 확인, 정책 전환이 정상인지 확인합니다.
  6. 필요할 때 TUN 활성화: 기본 프록시가 안정적으로 작동한 뒤 권한을 요청하고 터미널, 게임 또는 시스템 프록시를 따르지 않는 다른 프로그램을 테스트합니다.
  7. 기존 설정 정리: 새 클라이언트가 정상 작동하는 것을 확인한 뒤 기존 클라이언트의 시작 시 자동 실행과 백그라운드 서비스를 끄고 두 프로그램이 같은 포트를 동시에 사용하지 않도록 합니다.

마이그레이션 후 가장 흔한 충돌은 로컬 포트 중복입니다. 기존 프로그램이 백그라운드에서 7890, 7891 또는 다른 설정 포트를 계속 사용하면 새 코어가 시작되지 않습니다. 또 다른 문제는 시스템 프록시가 여전히 기존 포트를 가리키는 경우입니다. 새 클라이언트가 실행 중이어도 브라우저가 연결되지 않습니다. 이때는 새 클라이언트 로그에 표시된 리스닝 주소를 기준으로 시스템 프록시 설정을 다시 적용해야 합니다.

기존 설정이 클래식 Clash 필드를 사용하고 대상 클라이언트가 Mihomo를 사용한다면 대체로 먼저 직접 가져온 뒤 로그를 보며 차이를 처리할 수 있습니다. 반대 방향의 마이그레이션은 더 신중해야 합니다. Mihomo 확장 필드를 기존 코어가 인식하지 못할 수 있기 때문입니다. 알 수 없는 필드를 발견하면 해당 필드가 제어하는 기능을 확인한 뒤 대상 코어가 지원하는 동등한 표현으로 바꿀지 결정해야 하며, 기계적으로 삭제해서는 안 됩니다.

로그로 현재 실행 중인 프로젝트 확인하기

클라이언트 이름에는 Clash가 그대로 남아 있을 수 있지만, 시작 로그에는 더 직접적인 정보가 표시되는 경우가 많습니다. 문제를 확인할 때는 코어 이름, 버전 번호, 설정 파일 경로, 로컬 리스닝 포트, 외부 제어 포트, TUN 초기화 결과, 설정 파싱 오류를 확인해야 합니다. 로그에 표시된 클라이언트 버전은 UI 프로그램의 버전만 나타내며, 실제 규칙과 프로토콜 기능을 결정하는 것은 코어 버전입니다.

프로세스 목록을 통해 실제로 실행된 실행 파일을 확인할 수도 있습니다. 일반적인 클라이언트는 UI 프로세스와 코어 프로세스를 하나씩 실행하며, 서비스 모드를 활성화하면 코어가 시스템 서비스로 관리될 수도 있습니다. 클라이언트가 실행 중일 때 같은 코어를 수동으로 하나 더 실행하지 마세요. 리스닝 포트 충돌, 설정 파일 경쟁, 시스템 프록시 상태 불일치가 발생하기 쉽습니다.

노드 연결은 되지만 규칙이 예상과 다르게 적용될 때는 연결 기록에서 대상 도메인, 일치한 규칙, 최종 정책 그룹을 확인해야 합니다. 연결 기록에 IP만 표시된다면 DNS 확인 방식이나 트래픽 스니핑 설정과 관련이 있을 수 있습니다. 항상 MATCH에만 일치한다면 규칙 순서와 규칙 집합 로드 상태를 점검해야 합니다. 규칙은 위에서 아래 순서로 매칭되며 먼저 일치한 결과가 적용됩니다. 클라이언트 화면의 그룹명은 설정 관계를 보여주는 표시일 뿐입니다.

프로젝트 선택 결론

Clash는 생태계의 출발점이자 설정 체계를 가리키는 이름이고, Mihomo는 Clash.Meta에서 이어진 활발한 호환 코어입니다. Clash Verge Rev, Clash Nyanpasu, FlClash 등은 코어를 호출하고 시스템 연동을 제공하는 그래픽 클라이언트입니다. 구독, YAML 설정, GeoIP, GeoSite, 규칙 집합은 데이터 계층에 속하며 여러 클라이언트에서 사용할 수 있지만, 호환 범위는 코어 버전과 설정 확장 기능의 영향을 받습니다.

실제로 선택할 때는 플랫폼과 아키텍처, 클라이언트 유지보수 상태, 코어 종류, 설정 호환성, 시스템 프록시와 TUN 요구 사항을 차례로 확인해야 합니다. 기존 클라이언트를 마이그레이션할 때는 구독과 읽을 수 있는 설정을 보존하고 로그로 실제 실행 중인 코어를 대조하세요. UI, 코어, 데이터를 나누어 판단하면 비슷한 이름 때문에 잘못 다운로드하거나, 설정 호환성 문제를 겪거나, 문제 해결 방향을 잘못 잡는 일을 피할 수 있습니다.