Clash 클라이언트 업데이트 종료 후 마이그레이션 방안: 설정 이전과 대체 클라이언트 선택

클라이언트가 업데이트 종료 상태인지 판단하는 방법

Clash 생태계의 클라이언트는 대부분 동일한 프록시 코어(초기에는 Clash Premium, 지금은 Clash Meta와 그 후속 프로젝트인 mihomo가 주로 사용됨)를 감싸는 그래픽 인터페이스 껍데기입니다. 코어는 규칙 매칭, 프로토콜 해석, 트래픽 전달을 담당하고, 클라이언트는 설정 관리, 화면 표시, 플랫폼 대응을 담당합니다. 특정 클라이언트 프로젝트의 저장소가 몇 달 동안 커밋이 없고, Release 페이지가 옛 버전에 머물러 있으며, Issue란에 응답 없는 호환성 문제가 쌓여 있다면 업데이트가 종료된 상태라고 판단할 수 있습니다.

업데이트 종료 자체보다 더 주목해야 할 것은 종료된 이유입니다. 유지관리자가 다른 후속 프로젝트로 역량을 옮긴 경우(저장소 README에 "XXX로 이전하세요"라고 명시하는 것이 일반적)라면 이전 경로가 대체로 매끄럽고 설정 형식도 거의 바뀌지 않습니다. 반면 상위 코어의 API 변경으로 클라이언트가 완전히 대응할 수 없게 되었거나, 배포 관련 정책 문제로 프로젝트 자체가 내려간 경우라면 더 신중하게 접근해야 하며, 옛 클라이언트에서 계속 기다리기보다 구조가 다른 대체 방안으로 바로 전환하는 것이 좋습니다.

업데이트 종료 여부를 교차 검증할 수 있는 구체적인 신호도 몇 가지 있습니다. 클라이언트를 실행해도 새 버전 알림을 오랫동안 받지 못하는 경우, 내장된 규칙 세트의 업데이트 소스가 계속 404를 반환하는 경우, 개발자가 커뮤니티(텔레그램 그룹, 디스코드, GitHub Discussions)에 명확히 종료 공고를 올린 경우입니다. 단일 신호만으로는 일시적인 네트워크 문제이거나 오판일 수 있으므로, 최소 두 가지 이상이 확인된 뒤에 마이그레이션을 시작하는 것이 좋습니다. 그래야 프로젝트가 잠시 조용한 시기에 불필요하게 이전 작업을 벌이는 일을 피할 수 있습니다.

설정과 구독을 그대로 재사용할 수 있는지 확인하기

마이그레이션의 첫 단계는 옛 클라이언트를 서둘러 삭제하는 것이 아니라, 기존 설정 파일과 구독 링크가 새 클라이언트에서 그대로 인식되는지 먼저 확인하는 것입니다. Clash 계열 설정 파일은 본질적으로 YAML이며, 핵심 필드(proxies, proxy-groups, rules)는 클라이언트가 아니라 코어 규격을 따르기 때문에 대부분의 클라이언트 사이에서 공통으로 사용됩니다. 하지만 클라이언트 고유의 확장 필드는 공통되지 않으며, 흔히 발생하는 차이점은 다음과 같습니다:

• 일부 클라이언트가 지원하는 proxy-providers 원격 프록시 제공자 문법 버전이 서로 달라 필드명이나 필수 항목에 약간의 차이가 있을 수 있습니다;
• GUI 클라이언트는 설정 파일의 맨 앞이나 맨 뒤에 자체 전용 필드(예: 인터페이스 테마, 트레이 아이콘 설정 등)를 삽입하는 경우가 많은데, 이런 필드는 새 클라이언트로 옮겨도 무시되어 프록시 기능에는 영향이 없지만 그대로 이어지지도 않습니다;
• TUN 모드의 구현 방식은 코어 버전마다 차이가 있어서, 일부 구버전 클라이언트가 사용하는 tun 필드 구조(예: stack 값의 범위)는 최신 mihomo 코어에서 이미 변경된 상태이므로 그대로 복사하면 수동으로 조정해야 할 수 있습니다.

구독 링크 자체는 대체로 추가 작업이 필요 없습니다. 구독 주소는 표준 설정이나 Base64로 인코딩된 노드 목록을 반환할 뿐이고, 클라이언트는 이를 내려받아 해석하는 역할만 하기 때문에, 클라이언트를 바꿔도 같은 구독 주소를 다시 추가하면 되고 구독 제공업체 쪽에서는 아무런 변경도 필요하지 않습니다. 실제로 손수 옮겨야 하는 것은 옛 클라이언트에서 만들어 둔 로컬 오버라이드와 커스텀 규칙입니다. 이 내용은 로컬에만 존재하며 구독 소스에는 포함되지 않습니다.

로컬 오버라이드와 커스텀 규칙을 내보내는 구체적인 절차

로컬 오버라이드(override)는 대부분의 Clash 클라이언트가 제공하는 기능으로, 구독 원문을 수정하지 않은 채 전달받은 설정을 부분적으로 조정할 수 있게 해줍니다. 예를 들어 커스텀 규칙을 추가하거나, DNS 설정을 변경하거나, TUN 모드를 켜거나, LAN 리스닝 포트를 조정하는 식입니다. 이 내용은 클라이언트 로컬 저장소에만 존재하므로, 클라이언트를 바꾸기 전에 반드시 수동으로 내보내야 합니다. 그렇지 않으면 마이그레이션 후 모든 개인화 설정을 처음부터 다시 구성해야 합니다. 다음 순서로 진행하는 것을 권장합니다:

1. 오버라이드 파일의 실제 경로 찾기

   대부분의 클라이언트는 오버라이드 내용을 구독 파일에 직접 쓰지 않고, 설정 디렉터리 안에(보통 구독 캐시 파일과 같은 위치) 별도의 YAML 파일로 저장합니다. 이 디렉터리를 찾아 복사해 두는 것이 화면을 하나씩 캡처해 기록하는 것보다 훨씬 안전합니다.

2. 규칙 오버라이드와 파라미터 오버라이드 구분하기

   규칙 오버라이드(커스텀 DOMAIN, IP-CIDR 규칙)는 대체로 통째로 복사해 새 클라이언트의 해당 위치에 붙여 넣을 수 있습니다. 반면 파라미터 오버라이드(포트, DNS, TUN 인터페이스 이름)는 새 클라이언트의 필드 명칭에 맞춰 다시 입력해야 합니다. 클라이언트마다 화면상의 옵션명과 내부 필드명이 항상 일대일로 대응하지는 않기 때문입니다.

3. 정책 그룹의 커스텀 정렬 기록하기

   구독 기본 분류에만 의지하지 않고 정책 그룹 안의 노드 순서나 분류 로직을 직접 조정한 적이 있다면, 이 정보는 대개 오버라이드 파일에 반영되지 않고 클라이언트의 화면 상태에만 저장되어 있습니다. 따라서 별도로 캡처하거나 문서로 기록해 두었다가 새 클라이언트에서 다시 정렬해야 합니다.

4. 클라이언트 자체 실행 파라미터 백업하기

   부팅 시 자동 실행, 시스템 프록시 모드, 혼합 포트 설정 등이 여기에 포함됩니다. 이들은 모두 프록시 설정과 무관한 클라이언트 차원의 개인 설정이므로, 마이그레이션 후 새 클라이언트에서 하나씩 다시 체크해 주어야 합니다.

플랫폼별로 여전히 활발하게 유지보수되는 대체 클라이언트 선택하기

대체 클라이언트를 고를 때는 두 가지 확실한 지표를 먼저 확인해야 합니다. 저장소의 커밋 활발도, 그리고 최신 mihomo 코어 버전을 따라가고 있는지 여부입니다. 코어는 지원하는 프로토콜의 범위와 규칙 매칭의 정확도를 결정하는데, 클라이언트가 이를 늦게 따라가면 새로운 프로토콜(예: 신버전 Hysteria2 파라미터)을 사용할 수 없을 수 있습니다. 데스크톱과 모바일은 대체 논리가 다소 다르므로 나눠서 살펴보는 것이 명확합니다:

데스크톱(Windows / macOS / Linux): 현재 주류가 되는 대체 경로는 Tauri나 이와 유사한 경량 프레임워크 기반의 신세대 클라이언트로 넘어가는 것입니다. 이런 클라이언트는 리소스 사용량이 낮고 업데이트 주기도 더 안정적이며, 대부분 기본적으로 최신 mihomo 코어를 통합하고 있어 사용자가 직접 코어 파일을 교체할 필요가 없습니다. 마이그레이션 시에는 새 클라이언트의 시스템 프록시 적용 방식(PAC 방식인지 시스템 프록시를 직접 설정하는 방식인지)과, TUN 모드 사용 시 가상 네트워크 어댑터 드라이버를 추가로 설치해야 하는지를 중점적으로 확인해야 합니다.

Android: 안드로이드 클라이언트는 대부분 VpnService 시스템 인터페이스를 기반으로 전역 프록시를 구현합니다. 클라이언트를 바꾸면 VPN 권한을 다시 승인해야 하고, 새 클라이언트를 시스템의 배터리 최적화 예외 목록에 다시 등록해야 하는지도 확인해야 합니다. 그렇지 않으면 백그라운드에서 시스템에 의해 종료되어 연결이 끊기는 문제가 자주 발생합니다. 앱별 프록시(패키지명 기준으로 프록시를 거칠 앱을 선택하는 기능) 목록도 새 클라이언트에서 다시 설정해야 하며, 옛 클라이언트의 목록은 자동으로 이전되지 않습니다.

iOS: iOS 클라이언트는 App Store 심사 정책의 영향을 많이 받으므로, 대체 클라이언트를 고르기 전에 대상 클라이언트가 현재 시스템 버전에서 정상적으로 설치되고 네트워크 확장 권한을 승인받을 수 있는지 먼저 확인해야 합니다. 설정 파일의 호환성 처리 방식은 데스크톱과 동일하며, 구독 링크는 그대로 재사용할 수 있습니다.

마이그레이션 완료 후 다시 확인해야 할 항목 목록

새 클라이언트에 설정을 가져온 뒤에는 모든 것이 그대로일 거라고 넘겨짚지 마세요. 다음 항목들은 실제 마이그레이션 과정에서 가장 쉽게 놓치는, "정상처럼 보이지만 실제로는 잘못된" 문제 지점입니다:

• DNS 설정: 새 클라이언트의 기본 DNS 정책은 옛 클라이언트와 다를 수 있습니다(예: fake-ip 모드 사용 여부). 이는 도메인 해석 결과와 분기 정확도에 직접 영향을 주므로, 옛 설정의 dns 필드와 하나씩 비교해 확인하는 것을 권장합니다.
• LAN 및 혼합 포트: 새 클라이언트에서는 포트 번호가 기본값으로 되돌아가 있을 수 있습니다. 라우터나 다른 기기가 고정 포트로 연결하고 있다면 마이그레이션 이전 값으로 다시 설정해야 합니다.
• 규칙 세트 업데이트 소스: 일부 클라이언트는 원격 규칙 세트(GeoIP, GeoSite 데이터베이스)를 기본으로 내장하고 있습니다. 클라이언트를 바꾼 뒤에는 이 규칙 세트의 업데이트 주소를 다시 설정해야 합니다. 그렇지 않으면 규칙이 클라이언트에 처음 내장된 버전에 머물러 점점 낡아집니다.
• 정책 그룹의 자동 속도 측정 파라미터: url-test, fallback 같은 자동 정책 그룹이 사용하는 측정 주소(url 필드)와 검사 간격(interval)이 새 클라이언트에서 기본값 그대로 남아 있으면, 특정 네트워크 환경에 맞춰 이전에 조정해둔 값과 달라져 자동 전환의 민감도에 영향을 줄 수 있습니다.
• 부팅 시 자동 실행과 시스템 프록시 적용: 가장 쉽게 빠뜨리는 항목입니다. 마이그레이션을 마친 뒤 부팅 시 자동 실행을 다시 체크하는 것을 잊어버려, 컴퓨터를 재부팅했을 때 프록시가 적용되지 않았는데도 원인을 알아차리지 못하는 경우가 많습니다.

마이그레이션 당일에는 옛 클라이언트를 삭제하지 말고 남겨 두고, 새 클라이언트를 하루나 이틀 정도 사용해 안정성을 확인한 뒤에 옛 버전과 설정 디렉터리를 완전히 정리하는 것을 권장합니다. 이렇게 하면 오버라이드 항목 중 빠진 것이 발견되더라도 언제든 옛 클라이언트로 돌아가 원본 설정을 확인할 수 있어, 기억에 의존해 다시 더듬어 찾을 필요가 없습니다.