Clash 클라이언트 지원 종료 후: mihomo 기반 클라이언트로 마이그레이션하기
기존 Clash 지원 종료 후 달라진 생태계를 살펴보고, Android와 데스크톱에서 계속 업데이트되는 mihomo 클라이언트와 설정 파일 마이그레이션 시 확인할 항목을 정리합니다.
클라이언트와 코어 중 무엇이 지원 종료됐는지 확인하기
기존 클라이언트의 ‘정보’ 화면을 열어 앱 이름, 앱 버전, 코어 버전을 먼저 기록한 뒤 교체 대상을 정하세요. 클라이언트는 구독을 가져오고 노드를 표시해 서비스를 실행하는 인터페이스이며, 코어는 설정을 읽고 규칙을 적용해 프록시 연결을 만드는 프로그램입니다. 서로 다른 프로젝트이므로 업데이트 상태도 다를 수 있습니다.
2023년 기존 Clash 관련 프로젝트가 공개 업데이트를 중단했지만, 이미 설치한 앱이 날짜가 지났다고 자동으로 작동을 멈추는 것은 아닙니다. 기존 노드는 계속 연결될 수 있지만, 새 프로토콜 지원이나 시스템 호환성 수정, 이후 발생하는 문제에 대한 대응까지 보장되지는 않습니다. Clash for Windows, 기존 Clash for Android, mihomo를 이름이 비슷하다는 이유만으로 같은 업데이트 계열로 보면 안 됩니다.
mihomo는 Clash.Meta 프로젝트를 이어받은 프록시 코어입니다. 예전 가이드에서 말하는 ‘Meta 코어’는 보통 이 기술 계열을 가리키며, 별도의 구독 서비스가 아닙니다. 마이그레이션할 때는 계속 업데이트되고 mihomo를 실행할 수 있는 클라이언트를 선택한 뒤 구독과 로컬 설정을 나눠 옮기는 것이 핵심입니다.
Android와 데스크톱, 플랫폼별 마이그레이션 경로
운영체제에 맞는 앱을 고른 다음 공식 릴리스 기록, 지원 아키텍처, 코어 안내를 확인하세요. 아래는 mihomo 생태계에서 고려할 수 있는 마이그레이션 후보이며, 특정 구버전 설치 파일이 계속 관리된다는 보장은 아닙니다. 프로젝트 상태는 달라질 수 있으니 설치 당일 최근 릴리스와 이슈 대응 현황을 확인하고, 다운로드 파일의 수정 시각만으로 판단하지 마세요.
| 기기 플랫폼 | 마이그레이션 후보 | 설치 전 확인 사항 |
|---|---|---|
| Android | Clash Meta for Android、FlClash | Android 최소 버전, ARM 아키텍처, 코어 버전, VPN 권한 |
| Windows | Clash Verge Rev、Clash Nyanpasu、FlClash | 시스템 아키텍처, 사용할 코어, TUN 서비스 설치 요건 |
| macOS | Clash Verge Rev、FlClash、ClashX Meta | Apple Silicon 또는 Intel용 설치 파일, 네트워크 권한, 보조 서비스 |
| Linux | Clash Verge Rev、FlClash | 배포판 패키지 형식, 데스크톱 환경, TUN 권한, 서비스 실행 방식 |
Android: 설정부터 옮긴 뒤 트래픽 연결하기
기존 Clash for Android의 설정, 프록시, 로그 화면에 익숙하다면 Clash Meta for Android를 검토해 보세요. 휴대폰과 PC에서 비슷한 인터페이스를 원한다면 FlClash도 선택지가 될 수 있습니다. 두 앱의 메뉴, 백업 형식, 내장 설정은 완전히 같지 않으므로 앱 데이터 디렉터리 전체를 그대로 서로 옮기지 마세요.
최신 Android 휴대전화 대부분은 ARM64를 사용하지만, 출시 연도만 보고 판단하면 안 됩니다. 다운로드 안내에서 기기가 지원하는 ABI(애플리케이션 바이너리 인터페이스)를 확인하고 arm64-v8a 지원 여부를 확인한 뒤 ARM64 패키지를 선택하세요. 필요한 Android 버전도 해당 릴리스 안내를 기준으로 확인해야 합니다.
데스크톱: 시스템 프록시부터 확인하고 TUN은 나중에 설정하기
Windows와 macOS에서는 먼저 구독을 가져오고 노드를 선택한 다음 시스템 프록시만 켜서 브라우저 연결을 시험해 보세요. Clash Nyanpasu처럼 여러 코어를 선택할 수 있는 클라이언트는 코어 관리 화면에서 mihomo가 실행 중인지도 확인해야 합니다. 클라이언트 버전과 코어 버전을 혼동하지 마세요.
TUN은 기기의 네트워크 트래픽을 받는 가상 네트워크 인터페이스입니다. 시스템 프록시만 바꾸는 것보다 적용 범위가 넓은 경우가 많지만 라우팅, DNS, 시스템 권한과 관련됩니다. 기존 클라이언트에서 시스템 프록시가 정상 작동했다면 마이그레이션 첫 시험도 같은 방식으로 진행해 변수를 한꺼번에 늘리지 마세요.
기존 클라이언트에서 다음 네 가지를 먼저 백업하세요
- 구독 정보: 원본 구독 URL, 업데이트 간격, 제공업체 안내를 저장하세요. 구독 URL에는 계정 토큰이 포함되는 경우가 많으므로 공개 메모나 스크린샷, 온라인 변환 사이트에 올리지 마세요.
- 설정 파일: 현재 작동하는 YAML 파일을 내보내세요. YAML은 들여쓰기로 계층을 나타내는 텍스트 설정 형식입니다. 편집할 때 공백 들여쓰기를 유지하고 탭 문자를 섞지 마세요.
- 로컬 변경 사항: 사용자 지정 규칙, 오버라이드, 스크립트, DNS 설정을 기록하세요. 클라이언트가 실행 시점에 이 항목을 런타임 설정에 합칠 수 있으므로 구독 파일만 복사하면 빠뜨릴 수 있습니다.
- 시스템 설정: 프록시 포트, LAN 공유, 앱별 분할 설정, 자동 시작 설정을 기록하세요. Android의 앱 제외 목록이나 데스크톱 시스템 프록시 스위치는 일반적으로 공통 구독 설정에 포함되지 않습니다.
기존 화면에 ‘실행 설정 보기’가 있으면 비교용 사본을 추가로 저장해도 좋지만, 새 클라이언트의 작업 디렉터리 전체를 덮어쓰지는 마세요. 실행 설정에는 임시 경로, 제어 인터페이스 키, 펼쳐진 노드 비밀번호가 포함될 수 있어 기기 간 재사용에 적합하지 않고 공개 질문에도 올리면 안 됩니다.
설정 마이그레이션: 필드와 이름 참조를 하나씩 확인하기
새 클라이언트의 구독 또는 설정 화면에서 원본 URL로 설정을 추가한 뒤 직접 업데이트해 보세요. 로컬 파일만 있다면 ‘파일에서 가져오기’와 같은 메뉴를 이용하세요. 메뉴 이름은 클라이언트마다 다르지만 ‘구독 원본 파일’과 ‘앱 설정 백업’을 구분하는 것이 중요합니다. 둘은 서로 바꿔 쓸 수 없습니다.
프록시, 정책 그룹, 규칙이 서로 연결되는지 확인하세요
proxies에는 설정 파일에 직접 입력한 노드가 저장됩니다.proxy-providers에는 외부 노드 제공자가 지정됩니다. 후자를 사용한다면 다운로드 주소에 접속할 수 있는지, 로컬 캐시 경로에 쓸 수 있는지도 확인하세요.proxy-groups는 수동 선택 그룹과 같은 정책 그룹을 정의합니다. 그룹에서 참조하는 노드명, 다른 그룹명, 제공자명이 실제로 존재하는지 확인하고 대소문자와 공백도 일치시켜야 합니다.rules는 연결을 순서대로 검사합니다. 앞에 있는 규칙이 먼저 적용되므로, 뒤의 규칙까지 확인해야 하는 경우 포괄적인MATCH규칙을 그 앞에 두지 마세요.rule-providers는 외부 규칙 세트를 참조합니다.type,behavior,format이 실제 파일 내용과 맞는지 확인하세요. 도메인 목록을 classical 형식의 완전한 규칙 세트로 바로 사용할 수는 없습니다.
‘정책 그룹이 없습니다’라는 오류가 나오면 노드를 바로 바꾸지 말고 오류에 표시된 이름부터 확인하세요. 클라이언트 오버라이드에서 ‘프록시’를 ‘노드 선택’으로 바꿨는데 사용자 지정 규칙이 이전 이름을 참조하면 설정을 불러오지 못할 수 있습니다.
포트와 제어 인터페이스 설정을 통째로 복사하지 마세요
mixed-port는 HTTP와 SOCKS 프록시 연결을 모두 받는 로컬 포트입니다. external-controller는 인터페이스나 관리 도구가 호출하는 제어 인터페이스이지 프록시 포트가 아닙니다. 아래는 로컬 설정 일부일 뿐, 그대로 실행할 수 있는 완전한 구독 설정이 아닙니다:
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info이 예시에서는 7890을 사용하지만 모든 클라이언트의 기본 포트가 같다는 뜻은 아닙니다. 터미널이 기존에 127.0.0.1:7890에 연결되어 있었는데 새 클라이언트가 실제로 7897을 수신한다면 터미널 설정을 함께 바꾸거나 클라이언트에서 지원하는 설정 메뉴를 통해 포트를 조정하세요.
기존 파일의 external-controller, secret, external-ui, 절대 경로를 휴대전화에 그대로 옮기지 마세요. 새 클라이언트가 제어 인터페이스와 리소스 디렉터리를 자체 관리할 수 있습니다. 수신 주소를 0.0.0.0으로 바꾸면 인터페이스에 접근할 수 있는 범위가 넓어질 수도 있습니다. 명확한 이유가 없다면 앱에서 관리하는 로컬 설정을 유지하세요.
DNS, TUN, 기존 스크립트는 따로 확인하기
DNS: 새 클라이언트의 기본 설정부터 사용하기
DNS는 도메인 이름을 IP 주소로 바꾸는 과정입니다. 마이그레이션 후 ‘노드 지연 시간은 정상인데 웹페이지가 열리지 않는’ 문제가 생겨도 노드 프로토콜이 호환되지 않는다고 단정할 수 없습니다. 도메인 이름이 해석되는 경로가 달라졌을 수도 있습니다. 먼저 새 클라이언트가 권장하는 DNS 설정을 유지해 작동을 확인한 뒤 기존 사용자 지정 DNS 서버를 하나씩 옮기세요.
fake-ip는 합성 IP를 할당해 트래픽을 분류하는 모드입니다. 기존 설정에서 198.18.0.1/16 같은 주소 범위를 사용했다면 이를 노드의 실제 IP로 오해하지 마세요. DNS 모드를 바꾼 뒤에는 테스트 연결을 새로 설정해야 합니다. 필요하면 앱을 다시 시작하거나 시스템 DNS 캐시를 지워 이전 결과가 판단에 영향을 주지 않도록 하세요.
TUN: 휴대전화와 PC의 라우팅 매개변수를 함께 복사하지 마세요
Android 클라이언트는 보통 Android의 VpnService 인터페이스로 트래픽을 받으며, 처음 연결할 때 시스템 VPN 권한 요청이 표시됩니다. 데스크톱에서는 보조 서비스를 설치하거나 관리자 권한을 부여해야 할 수 있습니다. 두 환경 모두 트래픽을 처리할 수 있지만 시스템 권한을 얻는 방법, 라우팅 구현, 사용 가능한 옵션은 서로 다릅니다.
tun.stack, auto-route, dns-hijack는 대상 클라이언트와 운영체제에 맞춰 확인하세요. 기존 PC 설정에 특정 가상 네트워크 어댑터 이름이 있다고 해서 그 이름을 휴대전화 설정에 넣지 마세요. Android에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘VPN’에서 이전 앱 설정도 확인하세요. 일부 제조사는 메뉴를 ‘연결 및 공유’ 아래에 둡니다.
스크립트: 어느 계층에서 실행되는지 먼저 확인하기
기존 설정의 script:, 이전 인터페이스의 JavaScript 오버라이드, 서드파티 구독 변환 템플릿은 서로 다른 기능입니다. mihomo가 기존 Clash Premium 스크립트를 실행한다고 가정하거나 데스크톱 클라이언트용 오버라이드 스크립트를 Android에 그대로 가져오면 안 됩니다. 우선 스크립트를 비활성화하고 표준 규칙으로 기본 연결을 확인한 다음, 필요한 로직을 대상 클라이언트가 명확히 지원하는 규칙이나 오버라이드로 바꾸세요.
다섯 단계로 마이그레이션 결과 확인하기
- 설정이 불러와지는지 확인: 로그를 열어 YAML 들여쓰기 오류, 알 수 없는 프록시 유형, 정책 그룹을 찾을 수 없다는 메시지가 없는지 확인하세요. 불러오기에 실패하면 첫 번째 오류부터 해결하세요. 뒤에 표시되는 오류는 연쇄적으로 발생한 결과일 수 있습니다.
- 구독이 업데이트되는지 확인: 직접 한 번 업데이트하고 노드 수와 계정 만료일을 확인하세요. HTTP
401또는403응답이 오면 먼저 토큰과 접근 권한을 확인하세요. 이런 응답을 프록시 포트 충돌로 보면 안 됩니다. - 개별 노드 확인: 정책 그룹에서 노드 하나를 직접 선택해 연결 테스트를 실행하세요. 지연 시간 테스트는 지정된 테스트 요청의 결과만 보여 주며 모든 웹사이트와 프로토콜을 사용할 수 있다는 뜻은 아닙니다.
- 실제 규칙 적용 확인:
Rule모드를 유지하고 직접 연결할 대상과 프록시를 사용할 대상을 각각 방문하세요. 연결 목록에서 적용된 규칙, 정책 그룹, 최종 노드를 확인합니다. - 시스템 트래픽 처리 확인: 데스크톱에서는 브라우저와 터미널을 각각 시험하세요. Android에서는 브라우저와 대상 앱을 각각 확인하고, 화면을 잠갔다가 다시 켠 뒤에도 연결이 유지되는지 확인하세요.
예를 들어 데스크톱의 로컬 HTTP 프록시 포트가 7890으로 확인되었다면 아래 명령으로 프록시 요청만 따로 점검할 수 있습니다. 이 명령은 해당 요청에만 적용되며 시스템 프록시를 켜 주지 않고 TUN 라우팅이 정상이라는 점도 증명하지 않습니다.
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/여기서는 연결 시간 제한을 10초, 전체 요청 시간 제한을 20초로 설정했습니다. 이는 문제 해결을 위한 값이지 실제 속도 측정값이 아닙니다. 로그에 address already in use가 표시되면 기존 서비스가 포트를 계속 사용 중인지 먼저 확인하세요. no such host라면 해당 도메인의 DNS 조회 과정을 확인하고, context deadline exceeded라면 대상 주소와 연결 단계까지 함께 살펴봐야 합니다. 이 메시지만으로 구독이 만료됐다고 단정할 수는 없습니다.
되돌릴 방법을 남겨 두고 구독 업데이트가 수정 사항을 덮어쓰지 않게 하세요
첫 번째 점검을 마친 뒤 자동 시작, 백그라운드 실행, 사용자 지정 규칙을 다시 적용하세요. Android에서는 ‘설정’ → ‘앱’ → 대상 클라이언트 → ‘배터리’에서 백그라운드 제한을 확인할 수 있습니다. 메뉴 이름은 운영체제에 따라 다릅니다. ‘항상 사용 설정 VPN’ 또는 ‘VPN을 사용하지 않는 연결 차단’을 켰다면 새 클라이언트가 지정되어 있는지 확인하세요. 그렇지 않으면 기존 앱을 중지한 뒤 기기 전체의 인터넷 연결이 끊길 수 있습니다.
다음 구독 업데이트 후 사용자 지정 규칙이 남아 있는지 다시 확인하세요. 구독을 내려받아 생성한 YAML을 직접 수정하면 업데이트 때 덮어써지는 경우가 많습니다. 지속적으로 적용할 변경 사항은 클라이언트가 지원하는 오버라이드, 병합 설정, 별도 규칙 제공자에 넣고 최종 실행 설정에서 규칙 순서까지 확인하세요.
- 기존 설정과 새 설정을 각각 보관하고 파일명에 날짜를 넣어 서로 헷갈리지 않게 하세요.
- 호환성 문제를 확인할 수 있도록 클라이언트 버전, mihomo 코어 버전, 재현 절차를 기록하세요.
- 도움을 요청할 때는 구독 토큰, 노드 비밀번호, 제어 인터페이스 키를 삭제한 로그만 공유하세요.
- 이전 상태로 되돌릴 때는 먼저 새 클라이언트의 시스템 프록시나 VPN을 끈 다음 기존 서비스를 복구해 남아 있는 라우팅을 방지하세요.
마이그레이션 완료 여부는 새 화면이 열린다는 사실만으로 판단할 수 없습니다. 구독이 업데이트되고 규칙이 적용되며 대상 앱이 연결되고, 재부팅하거나 화면을 잠갔다가 켠 뒤에도 예상대로 작동해야 합니다. 이 최소 점검을 먼저 마친 다음 DNS, TUN, 복잡한 오버라이드를 조정하면 문제 범위를 더 쉽게 좁힐 수 있습니다.