Clash 오픈 소스 계보: 원본 커널 유지보수 중단 후 mihomo와 GUI 클라이언트의 관계

먼저 커널, GUI 클라이언트, 구독의 세 계층을 구분하세요

“Clash 다운로드”를 검색하면 명령줄 프로그램, 데스크톱 설치 파일, 모바일 앱이 함께 나올 수 있습니다. 이들은 서로 다른 계층입니다. 커널은 프록시와 트래픽 분기를 처리하고, GUI 클라이언트는 커널을 관리하고 실행하며, 구독은 노드나 설정 데이터를 제공합니다. 세 계층을 구분해야 “클라이언트를 바꾸면 문제가 해결될까?”를 판단할 수 있습니다.

커널: 프록시 포트를 열고, 외부 연결을 맺고, 규칙을 적용하며, DNS를 처리합니다. mihomo가 이 계층에 속하며 GUI 없이 단독 실행할 수도 있습니다.
GUI 클라이언트: 구독 관리, 정책 그룹 선택, 시스템 프록시 전환, 백그라운드 서비스 설치를 담당하며 커널 로그와 연결 기록을 보여줍니다.
구독: 노드 목록만 제공할 수도 있고, DNS·규칙·정책 그룹이 포함된 전체 YAML을 제공할 수도 있습니다. 구독 서비스 자체가 커널 프로젝트인 것은 아닙니다.

예를 들어 클라이언트 창에 “실행 중”이라고 표시되어도 일부 프로세스나 서비스가 시작됐다는 뜻일 뿐, 구독에 포함된 노드에 연결된다는 보장은 없습니다. 반대로 브라우저에서 127.0.0.1:7890을 통해 인터넷에 접속할 수 있어도 TUN이 기기 전체의 트래픽을 처리한다는 의미는 아닙니다. 먼저 문제가 발생한 계층을 찾은 뒤 무엇을 업데이트할지 결정하면, 반복해서 재설치하는 것보다 시간을 아낄 수 있습니다.

Clash 원본, Premium, Meta에서 mihomo까지의 발전

Clash 원본: 설정 모델과 규칙 체계의 출발점

Dreamacro/clash는 이 생태계의 중요한 출발점입니다. Go로 작성됐으며 원본 오픈 소스 커널은 GPL-3.0 라이선스를 사용합니다. 현재도 쓰이는 설정 개념 중 상당수가 여기서 이어졌습니다. 예를 들어 proxies, proxy-groups, rules와 위에서 아래 순서로 규칙을 적용하는 방식이 있습니다. 2023년 11월경 원 프로젝트의 공개 유지보수가 중단됐지만, 기존 클라이언트와 튜토리얼이 인터넷에서 사라진 것은 아닙니다.

이 때문에 오래된 튜토리얼을 보면 혼란스러울 수 있습니다. HTTP 프록시와 규칙 순서 설명은 여전히 유효할 수 있지만, 설치 파일과 커널 기능, 시스템 권한 설정은 이미 다른 환경을 전제로 합니다. “Clash에서 이 필드를 지원한다”는 내용을 봤다면 어느 커널의 어떤 빌드를 가리키는지 확인해야 합니다.

Clash Premium: mihomo의 “유료 고급 버전”이 아닙니다

Clash Premium은 원래 생태계에서 별도로 배포되던 비공개 소스 커널 브랜치로, TUN과 스크립트 등의 확장 기능을 제공한 적이 있습니다. 여기서 Premium은 브랜치 이름이지, 특정 GUI 클라이언트의 유료 요금제를 뜻하지 않습니다. 전체 구현이 공개되지 않았으므로 후속 프로젝트인 mihomo를 “공개된 Premium 소스 코드가 계속 업데이트된 결과”라고 단순화해서 설명할 수는 없습니다.

Clash 오픈 소스 원본, Premium, Meta는 기능이 일부 겹치지만 설정 항목이 모두 동일하게 대응하는 것은 아닙니다. 특히 오래된 Premium 스크립트 규칙은 실행 파일만 mihomo로 바꾼다고 계속 작동한다고 볼 수 없습니다. 마이그레이션할 때는 대상 커널이 지원하는 규칙과 정책 그룹으로 다시 작성해야 합니다.

Clash.Meta → mihomo: 이름 변경과 기능 확장

Clash.Meta는 Clash 오픈 소스 코드를 바탕으로 발전한 커뮤니티 브랜치이며, 이후 mihomo로 이름을 바꿨습니다. 저장소 이름은 MetaCubeX/mihomo입니다. 따라서 예전 문서의 “Meta 커널”이나 구독 플랫폼의 “Clash Meta 형식”은 대개 현재 논의되는 mihomo 생태계를 가리킵니다. 별도의 프로그램을 함께 설치해야 한다는 뜻은 아닙니다.

mihomo는 Clash 방식의 YAML 설정과 제어 인터페이스를 이어받아 프로토콜, 규칙, DNS 기능을 꾸준히 확장하고 있습니다. mihomo는 GPL-3.0 라이선스를 사용하지만, 이를 사용하는 GUI 클라이언트는 다른 라이선스를 적용할 수 있습니다. 소프트웨어 라이선스를 확인할 때는 설치 파일 이름만 볼 것이 아니라 프런트엔드와 커널의 LICENSE를 각각 확인해야 합니다.

관계도: 화살표의 의미를 각각 표시

Clash 원본 오픈 소스 코드
  └─ 커뮤니티 브랜치로 발전 → Clash.Meta
                       └─ 프로젝트 이름 변경 → mihomo

Clash Premium
  └─ 원래 생태계의 비공개 소스 커널 브랜치. mihomo의 공개 소스 업스트림은 아님

Clash Verge Rev / FlClash 등 GUI 클라이언트
  └─ 패키징·실행 후 제어 인터페이스로 관리 → mihomo

Verge, FlClash, Nyanpasu는 각각 어떤 계층에 속할까

이 이름들은 주로 GUI 클라이언트를 가리키며, 서로 완전히 다른 세 가지 프록시 프로토콜을 뜻하지 않습니다. 같은 종류의 커널을 실행하더라도 구독 병합, 백그라운드 서비스, 시스템 프록시 설정, 업데이트 방식은 다를 수 있습니다. 아래에서는 프로젝트 간 관계를 기준으로 구분하며, 인터페이스가 비슷하다는 이유만으로 코드가 이어졌다고 보지는 않습니다.

프로젝트 이름	계층	선택 시 확인할 항목
mihomo	프록시 커널	커널 버전, 설정 필드, 대상 아키텍처. 완전한 데스크톱 관리 인터페이스는 기본 제공되지 않음
Clash Verge	기존 데스크톱 클라이언트	원 프로젝트는 보관 처리됨. Rev의 릴리스 기록과 혼동하지 말 것
Clash Verge Rev	Verge 계보를 이어가는 데스크톱 클라이언트	Windows, macOS, Linux 설치 파일과 함께 제공되는 mihomo 버전
FlClash	Flutter 기반 GUI 클라이언트	데스크톱과 Android 버전의 기능 차이, 실제 패키지에 포함된 커널
Clash Nyanpasu	Verge 계보에서 나온 데스크톱 클라이언트	현재 릴리스에서 사용할 수 있는 커널 옵션, 설정 확장 방법, 서비스 모드
Clash for Windows	기존 데스크톱 클라이언트	유지보수 중단. 이름에 Windows가 들어가지만 Windows만 지원했던 것은 아님
Clash for Android	기존 Android 클라이언트	유지보수 중단. 설치할 수 있다는 이유만으로 새 설정을 지원한다고 판단하지 말 것

Clash Verge와 Clash Verge Rev는 구분해야 합니다

“Verge”를 약칭으로 쓰는 경우가 많지만, 원래 Clash Verge와 후속 Clash Verge Rev는 릴리스 경로가 서로 다릅니다. Rev는 원 프로젝트의 계보를 이어받아 mihomo 커널을 사용합니다. 예전 버전의 설치 안내를 찾았다면 작업 화면보다 먼저 프로젝트의 전체 이름과 릴리스 저장소를 확인하세요. 메뉴 이름은 같아도 백그라운드 서비스 구현은 달라졌을 수 있습니다.

FlClash와 FlClashs를 같은 배포판으로 보면 안 됩니다

FlClash는 Flutter로 인터페이스를 만들었으며 데스크톱과 Android 등 여러 플랫폼을 지원합니다. 다운로드 목록에 FlClashs가 함께 있다면 별도의 배포 이름으로 보고 유지관리자, 저장소, 패키지 이름, 안내 내용을 따로 확인해야 합니다. 철자가 한 글자 더 붙었다고 업데이트 기록이 동일하다고 가정하지 마세요. 사이트에 표시되는 이름, 설치 후 앱 이름, 업스트림 프로젝트 이름이 서로 다를 때도 있습니다.

Nyanpasu의 커널 선택은 실제 릴리스 기준으로 확인하세요

Clash Nyanpasu도 GUI 관리 계층에 속합니다. 릴리스 시기에 따라 제공되는 커널 옵션이 다를 수 있으므로, 예전 스크린샷의 전환 메뉴를 항상 제공되는 기능 목록으로 간주하면 안 됩니다. 문제를 진단할 때는 “클라이언트 버전 + 현재 선택된 커널 + 커널 버전”을 기록하세요. “Nyanpasu 사용 중”이라는 정보만으로는 특정 설정을 읽을 수 있는지 판단하기 어렵습니다.

같은 구독인데 클라이언트마다 다르게 작동하는 이유

구독 호환성은 단순한 켜기·끄기 옵션이 아닙니다. 같은 URL을 가져와도 클라이언트가 서로 다른 요청 헤더를 보낼 수 있으며, 서버는 이에 따라 다른 내용을 반환할 수 있습니다. 응답이 같더라도 클라이언트가 로컬 설정을 덧붙인 뒤 서로 다른 버전의 커널에 전달할 수 있습니다. 비교할 때는 구독 편집창의 원문이 아니라 실제로 적용된 설정을 확인해야 합니다.

반환된 형식 확인: 완전한 Clash YAML에는 보통 proxies 또는 proxy-providers 같은 필드가 포함됩니다. 노드 링크 목록만 있는 내용은 완전한 설정으로 바로 불러올 수 없을 수 있습니다.
커널 지원 여부 확인: 오래된 커널은 새로운 프로토콜이나 필드를 지원하지 않을 수 있습니다. 로그에 unsupported proxy type과 같은 오류가 나타나면 같은 구독을 반복해서 업데이트하기보다 먼저 커널을 확인하세요.
로컬 설정 덮어쓰기 확인: 클라이언트가 mixed-port, dns, tun, external-controller를 덮어쓸 수 있습니다. 원본 설정에 7890이 적혀 있어도 최종 수신 포트가 7890이라는 보장은 없습니다.
규칙 참조 확인: 규칙에 적힌 정책 그룹 이름은 실제 이름과 일치해야 합니다. MATCH,PROXY의 PROXY는 참조하는 이름일 뿐, 모든 설정에 자동으로 존재하는 예약 그룹이 아닙니다.

명령으로 현재 실행 중인 커널 확인하기

설치 파일 이름만 보고 추측하지 마세요. 먼저 클라이언트의 “정보” 또는 커널 정보 화면에서 버전을 확인하세요. 메뉴 위치는 배포판마다 다릅니다. 독립 커널 파일을 확인하려면 해당 파일이 있는 디렉터리에서 아래 명령을 실행할 수 있습니다. 예시 파일 이름은 mihomo에서 흔히 쓰이는 이름입니다. 실제 파일 이름이 다르면 로컬 파일에 맞게 바꾸세요.

Windows PowerShell

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

macOS / Linux

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

-v는 커널 버전을 출력하고, -t는 설정을 검사하며, -d .는 현재 디렉터리를 작업 디렉터리로 지정해 로컬 데이터 파일을 찾기 쉽게 합니다. 원격 규칙 세트나 다른 리소스가 포함된 설정은 검사 과정에서 네트워크나 파일 경로의 영향을 받을 수 있습니다. 설정 검사를 통과했다는 것은 해당 검사에 통과했다는 뜻이지, 모든 노드에 연결됐다는 의미는 아닙니다.

클라이언트에서 로컬 제어 인터페이스를 활성화했다면 버전 정보를 확인할 수도 있습니다. 아래 방법은 제어 주소가 127.0.0.1:9090이고 제어 키를 설정하지 않은 로컬 환경에서만 사용할 수 있습니다. 키가 설정되어 있다면 설정에 맞춰 Bearer 인증을 추가하세요. 예제를 실행하려고 키를 삭제하지 마세요.

실행 중인 커널의 버전 정보 확인

curl http://127.0.0.1:9090/version

기존 클라이언트에서 마이그레이션하기: 설정·권한·트래픽 순으로 확인

1단계: 입력 데이터를 백업하고 디렉터리 전체를 덮어쓰지 않기

구독 주소, 로컬 규칙, 정책 그룹 선택 기록, 설정 덮어쓰기 스크립트를 보관하세요. 새 클라이언트에서 구독을 다시 가져온 다음 로컬 변경 사항을 하나씩 옮기세요. 기존 앱의 데이터 디렉터리를 새 앱의 디렉터리에 통째로 덮어쓰지 마세요. 데이터베이스 구조, 경로 규칙, 스크립트 인터페이스가 다를 수 있습니다. YAML 형식이 비슷하다고 내부 저장 방식까지 호환되는 것은 아닙니다.

2단계: 명시적 프록시부터 확인한 뒤 TUN 활성화

새 클라이언트에서 실제 mixed-port 값을 확인하세요. 값이 7890이라고 가정하고 아래 명령으로 명시적 HTTP 프록시 연결을 먼저 검사할 수 있습니다. 예시 도메인은 명령 형식을 보여주기 위한 것이며, 응답 상태는 현재 네트워크와 규칙에 따라 달라집니다. 특정 “실측 지연 시간”을 전제로 하지 않습니다.

로컬 프록시를 통해 HTTPS 요청 보내기

curl -I --proxy http://127.0.0.1:7890 https://example.com

명시적 프록시가 작동하면 시스템 프록시와 TUN을 차례로 테스트하세요. 시스템 프록시는 주로 시스템 설정을 따르는 앱에 영향을 줍니다. TUN은 가상 네트워크 인터페이스를 통해 트래픽을 처리하며, 보통 백그라운드 서비스, 관리자 권한 또는 플랫폼의 VPN 승인이 필요합니다. Android 클라이언트는 대개 시스템 VPN 인터페이스를 사용하므로 데스크톱의 서비스 설치 절차와 다릅니다.

3단계: DNS, UDP, 절전 모드 복귀 확인

DNS: 일반 웹 브라우징과 앱 내 접속을 비교해 시스템의 DNS 요청이 예상대로 처리되는지 확인하세요. TUN을 켰다고 해서 모든 암호화 DNS가 자동으로 관리되는 것은 아닙니다.
UDP: 음성 통화, 게임, QUIC은 노드와 프로토콜 지원 여부에도 영향을 받습니다. 웹페이지가 열린다고 UDP까지 정상이라고 볼 수는 없습니다.
절전 모드 복귀: 기기가 절전 상태에서 깨어나 다시 네트워크에 연결된 뒤, 백그라운드 커널이 계속 실행 중인지와 시스템 프록시 포트가 여전히 열려 있는지 확인하세요.
종료 후 복구: 클라이언트를 종료한 뒤 시스템 프록시가 원래대로 복구되는지 확인하세요. 시스템 프록시가 종료된 7890 포트를 계속 가리키면 네트워크 전체가 끊긴 것처럼 보일 수 있습니다.

선택 기준: 이름보다 유지보수 계보를 확인하세요

데스크톱 사용자는 Clash Verge Rev, FlClash, Clash Nyanpasu의 설정 관리 방식, 서비스 권한, 커널 업데이트 경로를 비교해 보세요. Android 사용자는 시스템 VPN 승인, 백그라운드 실행 제한, 현재 배포 패키지가 지원하는 플랫폼 아키텍처를 중점적으로 확인해야 합니다. iOS 사용자는 앱별 설정 호환 범위를 별도로 확인하세요. 데스크톱 mihomo의 모든 기능을 그대로 적용할 수는 없습니다.

마지막으로 기록할 것은 추적 가능한 연결 관계입니다. 설치 파일 출처 → 클라이언트 배포판 → 실제 커널 버전 → 최종 적용 설정. 인터페이스만 바꿔서는 프로토콜 호환 문제가 해결되지 않을 수 있고, 커널만 업데이트해서는 시스템 프록시가 남는 문제를 해결하지 못할 수 있습니다. 각 계층을 명확히 적고 로그를 확인하면 프로젝트 계보가 이름 나열이 아니라 문제 해결 도구가 됩니다.

설치 절차를 확인하려면 전체 플랫폼 가이드를 참고하세요. TUN, 정책 그룹 같은 용어가 낯설다면 먼저 용어 설명을 읽어보세요. 다운로드할 때는 운영체제와 프로세서 아키텍처에 맞는 파일을 고르고 클라이언트의 유지보수 상태도 확인하세요.