Clash for Windows 지원 종료 후 마이그레이션 가이드: 대체 클라이언트 선택과 설정 이전

마이그레이션 결론: 클라이언트는 바꾸고 구독과 규칙은 유지

Windows 사용자는 Clash Verge Rev와 FlClash를 먼저 비교해 보세요. macOS라면 ClashX Meta를, Linux라면 배포판에 맞는 설치 패키지를 고려할 수 있습니다. Android 사용자는 FlClash부터 살펴보세요. 기존 CFW를 먼저 삭제할 필요는 없습니다. 백업한 뒤 새 클라이언트에 가져오고, 규칙·DNS·프록시 적용 여부를 확인한 다음 기존 프로그램의 자동 시작을 끄세요.

Clash for Windows는 보통 CFW라고 부르며, 원래 프로젝트는 2023년에 유지 관리가 중단됐습니다. 마지막 시기의 대표 버전은 0.20.39입니다. CFW는 그래픽 클라이언트이며 모든 Clash 커널이나 구독 서비스를 의미하지 않습니다. UI를 바꿔도 서비스 제공업체가 바뀌는 것은 아닙니다. 같은 구독을 사용한다면 실제로 이용할 수 있는 프록시는 구독 제공업체에 따라 달라집니다.

마이그레이션 전 세 가지 구성 요소부터 구분하세요

클라이언트: 구독, 시스템 프록시, 서비스 권한, 설정 오버라이드를 관리합니다. 메뉴와 파일 구조는 클라이언트마다 다릅니다.
커널: YAML을 파싱하고 프록시 프로토콜, 규칙, DNS를 처리합니다. Clash Meta는 이후 mihomo라는 이름으로 발전했습니다. 특정 필드의 지원 여부는 새 클라이언트가 실제로 사용하는 커널을 확인해야 합니다.
구독: 프록시 노드나 전체 설정을 제공합니다. 노드 목록과 완전한 Clash 설정은 서로 다른 입력 형식이므로 가져오기 전에 형식을 확인해야 합니다.

대체 클라이언트: 플랫폼과 설정 기능에 맞춰 선택

릴리스가 계속 업데이트되고, 커널 버전을 확인할 수 있으며, 설정 내보내기와 로그 확인을 지원하는 프로젝트를 우선 선택하세요. 유지 관리 상태는 바뀔 수 있으므로 아래 목록은 마이그레이션 후보일 뿐, 지속적인 유지 관리를 보장하지 않습니다. 설치 전 프로젝트 릴리스 페이지에서 최근 버전, 시스템 요구 사항, 알려진 문제를 확인하세요. 다운로드 링크는 클라이언트 다운로드 페이지에서 찾을 수 있습니다.

플랫폼	대체 클라이언트	이전 시 확인할 점
Windows	Clash Verge Rev、FlClash	오버라이드 방식, 서비스 모드, 시스템 프록시, TUN 권한을 확인하세요. CFW의 사용자 디렉터리 전체를 복사하지 마세요.
macOS	Clash Verge Rev、FlClash、ClashX Meta	Apple Silicon과 Intel용 설치 파일을 구분하고, 네트워크 트래픽을 처리하는 데 필요한 구성 요소를 다시 승인하세요.
Linux	Clash Verge Rev、FlClash	DEB, RPM 등 패키지 형식과 배포판 요구 사항을 확인하세요. 데스크톱 프록시 설정과 TUN 라우팅도 각각 검증해야 합니다.
Android	FlClash	기기 아키텍처에 맞는 패키지를 선택하고 VPN 권한, 앱별 프록시 분기, 백그라운드 실행 제한을 확인하세요.
iOS	해당 구독 형식을 지원하는 iOS 클라이언트	설정 형식과 네트워크 확장 기능부터 확인하세요. 데스크톱용 CFW를 설치할 수 없으며, CFW 스크립트가 그대로 실행된다고 가정해서도 안 됩니다.

오버라이드가 필요하다면 설정 처리 방식부터 확인

구독을 가져와 프록시를 직접 선택하는 정도라면 설정이 간단한 클라이언트로도 충분합니다. 사용자 지정 규칙, DNS 또는 스크립트를 쓴다면 구독 위에 로컬 변경 사항을 지속적으로 적용할 수 있는지 먼저 확인하세요. Clash Verge Rev의 설정 병합과 스크립트 처리 방식은 CFW의 Parsers와 다릅니다. FlClash의 설정 처리 방식도 CFW 파일 구조를 기준으로 판단할 수 없습니다. 메뉴 이름은 설치된 버전의 UI에서 확인하세요.

‘mihomo 내장’이 ‘CFW의 모든 기능과 완벽하게 호환’을 뜻하지는 않습니다. 커널이 YAML 필드를 인식하는 문제와 UI가 설정을 저장·업데이트·생성하는 방식은 별개입니다. 클라이언트별 차이는 클라이언트 비교에서 더 확인할 수 있습니다.

백업 목록: 구독 주소, 최종 설정, 로컬 변경 사항

정리 도중 설정이 바뀌지 않도록 기존 CFW에서 구독 자동 업데이트를 먼저 끄세요. Profiles(프로필)에서 현재 활성화된 프로필, 구독 출처, 업데이트 시간을 기록합니다. Proxies(프록시)에서는 수동 선택 그룹마다 현재 선택된 항목을 적어 두세요. General(일반)과 Settings(설정)에서는 포트, 시스템 프록시, TUN, 설정 처리 옵션을 기록합니다.

구독 주소 저장: 쿼리 매개변수를 포함한 전체 URL을 보관하세요. 구독 URL에는 접근 토큰이 포함될 수 있으므로 비밀번호처럼 관리하고 공개 게시판에 붙여 넣지 마세요.
원본 YAML 저장: 현재 사용하는 설정을 복사하고, 구독 원본인지 처리된 파일인지 표시하세요. UI의 편집 기능이 실제 실행되는 최종 내용을 모두 보여 주는 것은 아닙니다.
오버라이드 원본 저장: Parsers 설정, 외부 스크립트, 사용자 지정 규칙, 규칙 제공자 주소, 로컬 파일을 각각 복사해 두세요.
실행 매개변수 기록: 실제 mixed-port 값(예: 7890), 수신 주소, 프록시 모드, DNS 모드, TUN 사용 여부를 적어 두세요. 7890은 흔히 쓰는 포트일 뿐 모든 기기에 고정된 값은 아닙니다.
특수 연결 방식 기록: 브라우저 확장 프로그램, 터미널 환경 변수, LAN 기기, 개발 도구가 기존 프록시 포트에 직접 연결되는지 확인하세요.

사용자 디렉터리는 백업용으로만 보관하고 새 프로그램에 덮어쓰지 마세요

Windows에서 CFW 사용자 설정은 보통 %USERPROFILE%\.config\clash에 저장되지만, 포터블 모드나 사용자 지정 디렉터리를 쓰면 위치가 다를 수 있습니다. 기존 클라이언트에 표시된 실제 경로를 기준으로 확인하세요. 디렉터리 전체를 복사해 롤백용으로 보관할 수는 있지만, 데이터베이스·캐시·클라이언트 설정을 새 클라이언트 디렉터리에 그대로 덮어쓰면 안 됩니다.

구독 이전: 원본 설정을 먼저 확인한 뒤 오버라이드 적용

처음 가져올 때는 새 클라이언트의 시스템 프록시와 TUN을 끄고 네트워크를 바로 전환하지 마세요. 새 클라이언트의 구독 또는 설정 가져오기 기능으로 기존 주소를 추가합니다. 구독에 일시적으로 접속할 수 없다면 백업한 YAML을 가져와 오프라인으로 검증할 수 있지만, 이후 노드가 자동으로 업데이트되지는 않습니다.

가져오기 로그를 확인해 로그인 페이지나 오류 페이지, 프록시 링크만 포함된 텍스트가 아니라 YAML 설정이 들어왔는지 확인하세요.
프록시 수, 그룹 이름, 규칙 수를 확인하고 기존에 수동으로 선택하던 그룹이 그대로 있는지 살펴보세요.
설정을 활성화한 뒤 먼저 커널 설정 검사를 실행하고, 시작 로그에서 미지원 필드, 존재하지 않는 대상, 파일 읽기 실패가 나타나는지 확인하세요.
실제로 생성된 설정을 확인하세요. 클라이언트의 전역 설정이 구독에 포함된 포트, DNS 또는 TUN 값을 덮어쓸 수 있습니다.
원본 설정이 정상적으로 시작되는 것을 확인한 다음 오버라이드를 하나씩 추가하세요. 한 번에 한 종류의 변경 사항만 이전합니다.

구독을 성공적으로 가져와도 이전과 똑같이 작동한다는 보장은 없습니다

기존 설정이 CFW 전용 사전 처리에 의존했다면 서비스 제공업체가 반환하는 원본에는 해당 변경 사항이 없을 수 있습니다. 반대로 구독에 새 커널이 지원하는 프로토콜이 들어 있어도 기존 클라이언트가 이를 제대로 인식하지 못했을 수 있습니다. mihomo로 옮긴 뒤 프록시 목록에 차이가 생길 수도 있습니다. ‘가져오기 성공’만으로 이전이 끝났다고 판단하지 말고 실제 생성된 설정을 비교하세요.

기존 서비스 제공업체가 제공하는 호환 구독 주소를 보관하세요. 형식 변환이 필요하다면 제공업체나 클라이언트가 명시적으로 지원하는 방법을 우선 사용하세요. 토큰이 포함된 주소를 출처를 알 수 없는 온라인 변환 사이트에 입력하면 구독 정보가 노출될 위험이 커집니다.

사용자 지정 규칙과 스크립트: 인터페이스를 복사하지 말고 결과를 옮기세요

CFW의 Parsers는 구독 URL 매칭, 필드 병합, JavaScript를 통한 설정 수정 등을 지원합니다. 새 클라이언트의 스크립트 진입점, 매개변수, 반환값, 실행 환경은 다를 수 있습니다. JavaScript를 사용한다는 이유만으로 기존 파일이 그대로 실행된다고 보장할 수 없습니다. 스크립트가 하는 일을 규칙 추가, 정책 그룹 조정, DNS 변경, 프록시 이름 수정 등으로 나눠 먼저 정리하세요.

규칙은 복사 개수보다 적용 순서가 중요합니다

규칙은 일반적으로 위에서부터 순서대로 평가되며, 조건에 처음 일치하는 항목의 대상이 적용됩니다. 구체적인 도메인 규칙은 포괄적인 규칙보다 앞에 두고, 마지막 기본 처리 규칙인 MATCH는 맨 아래에 배치하세요. 아래는 전체 설정에 추가할 수 있는 규칙 조각의 예입니다. 로컬 이름과 사설 IPv4 주소를 직접 연결하는 내용만 있으며 프록시 노드는 포함하지 않으므로 완전한 구독 설정이 아닙니다.

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

이전할 때는 이 항목을 기존 규칙의 적절한 위치에 넣으세요. 조각으로 전체 rules 목록을 대체하면 안 됩니다. 배열을 뒤에 추가할지, 앞에 넣을지, 통째로 덮어쓸지는 새 클라이언트의 오버라이드 방식에 따라 다르므로 생성된 설정에서 확인해야 합니다.

정책 그룹 참조: 기존 규칙에서 참조하는 그룹 이름은 완전한 설정의 proxy-groups에 있어야 하며, 대소문자까지 정확히 일치해야 합니다.
규칙 제공자: rule-providers를 옮길 때는 behavior, 형식, URL, 로컬 경로를 함께 확인하세요. RULE-SET 항목만 복사해서는 안 됩니다.
로컬 파일: 기존 디렉터리의 절대 경로는 새 클라이언트에서 대개 유효하지 않습니다. 상대 경로도 어느 설정 디렉터리를 기준으로 하는지 확인해야 합니다.
중복 규칙: 구독에 이미 포함된 사설망 직접 연결 규칙을 중복해서 추가할 필요는 없습니다. 규칙의 위치와 대상이 올바른지 확인하는 것이 중요합니다.

스크립트는 기능별로 나눠 다시 작성하세요

먼저 순수 YAML로 표현할 수 있는 변경 사항을 옮긴 뒤, 스크립트가 꼭 필요한 부분을 처리하세요. 실행할 때마다 정책 그룹, 규칙, DNS를 비교하고 스크립트가 노드 이름을 바꿔 정책 그룹이 이전 이름을 계속 참조하지 않는지 확인합니다. 기존 스크립트의 파일 접근, 네트워크 요청, 외부 의존성이 새 환경에서도 지원된다고 가정하지 마세요.

구독을 업데이트한 뒤 다시 확인하세요. 사용자 지정 규칙이 사라진다면 변경 사항이 임시 생성 파일에만 반영되고 지속되는 오버라이드 계층에는 적용되지 않은 것입니다. 관련 필드는 YAML 설정 안내에서 확인할 수 있습니다.

포트·DNS·TUN: 네트워크 전환 시 이중 실행 방지

설정이 정상적으로 시작되는 것을 확인한 뒤 네트워크 적용 방식을 전환하세요. 먼저 CFW의 시스템 프록시와 TUN을 끄고 CFW를 정상 종료합니다. 백그라운드 서비스나 남은 프로세스가 포트를 계속 사용하지 않는지 확인한 다음 새 클라이언트의 시스템 프록시를 켜세요. 두 프로그램이 시스템 프록시나 라우팅을 동시에 제어하면 연결이 불안정해질 수 있습니다.

mixed-port가 바뀌면 앱 내부의 프록시 설정도 바꾸세요

기존 클라이언트가 127.0.0.1:7890에서 수신하고 새 클라이언트는 127.0.0.1:7897에서 수신한다고 가정해 보겠습니다. 브라우저 확장 프로그램, 터미널, 개발 도구에 수동으로 설정한 프록시 주소도 모두 업데이트해야 합니다. 기존 포트를 계속 사용할 수도 있지만, 먼저 이전 프로세스가 해당 포트를 놓았는지 확인하세요. 아래는 수신 설정 예시이며 실제 값은 새 클라이언트의 최종 실행 설정을 기준으로 해야 합니다.

mixed-port: 7897
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info

mixed-port는 HTTP와 SOCKS 프록시 진입점을 함께 제공하는 포트이며, 외부 제어 API 포트와는 다릅니다. 이전을 위해 외부 제어 인터페이스를 모든 네트워크 어댑터에 개방하지 마세요. LAN 공유가 필요했던 기기라면 수신 범위, 방화벽, 접근 제한을 별도로 확인해야 합니다.

DNS를 이전할 때 기존 캐시까지 그대로 옮기지 마세요

기존 설정에서 fake-ip와 redir-host 중 어떤 방식을 사용했는지, 업스트림 리졸버·도메인 정책·필터 목록은 무엇인지 기록한 뒤 새 클라이언트가 이를 덮어쓰지 않는지 확인하세요. 이전 후 ‘노드는 연결되는데 웹사이트가 열리지 않는’ 문제가 생기면 노드를 바로 바꾸기보다 DNS 요청과 규칙 적용 결과를 살펴보세요. 캐시 삭제나 모드 전환은 근거를 바탕으로 한 문제 해결 단계일 뿐, 설정 확인을 대신할 수 없습니다.

TUN은 마지막에 켜세요

먼저 시스템 프록시로 브라우저를 확인하고, 시스템 프록시를 사용하지 않는 프로그램은 TUN을 켜서 검증하세요. Windows에서는 클라이언트 서비스와 관리자 승인이 필요할 수 있고, macOS에서는 해당 권한 구성 요소가 필요합니다. Linux에서는 충분한 네트워크 관리 권한이 있어야 하며, Android는 시스템 VPN 권한을 통해 작동합니다. 회사 VPN, 다른 프록시 프로그램, 가상 머신 네트워크를 함께 사용 중이라면 라우팅 및 DNS 충돌도 추가로 점검하세요.

최종 점검과 롤백: 구독을 한 번 업데이트한 뒤 CFW 삭제

이전이 끝났다고 볼 수 있는 기준은 기존에 하던 작업을 재현할 수 있는지 여부이지, 지연 시간 테스트에 숫자가 나오는지가 아닙니다. 아래 점검 항목을 하나씩 확인하고 결과를 기록하세요. 성공을 입증하려고 임의의 속도 측정값을 만들지 마세요. 같은 노드도 측정 시점에 따라 지연 시간이 달라지며, 지연 시간만으로 규칙과 DNS가 올바른지 확인할 수 없습니다.

웹 연결: 직접 연결되어야 하는 사이트와 프록시를 사용해야 하는 사이트를 각각 열고, 로그나 연결 목록에서 적용된 규칙과 정책 그룹을 확인하세요.
로컬 리소스: 라우터 관리 페이지, LAN 서비스, 사내 인트라넷에 정상적으로 접속할 수 있는지 확인하세요.
앱 연결: 브라우저 외의 개발 도구나 다른 프로그램도 확인하고, 시스템 프록시·수동 프록시·TUN 중 어떤 방식으로 연결하는지 구분하세요.
구독 업데이트: 구독을 한 번 수동으로 업데이트하고 사용자 지정 규칙, 정책 그룹 변경, DNS 오버라이드가 그대로 남아 있는지 확인하세요.
재시작 후 상태: 새 클라이언트를 재시작해 현재 설정, 선택된 프록시, 서비스 권한, 시작 시 자동 실행 상태를 확인하세요.
권한 정리: 기존 CFW의 자동 시작과 서비스를 끄고 오프라인 백업은 보관하세요. 새 프로그램을 종료했을 때 시스템 프록시가 정상적으로 복구되는지도 확인합니다.

문제가 생기면 계층별로 롤백하세요

새 프로그램이 시작되지 않으면 오버라이드를 제거하고 원본 구독부터 확인하세요. 시작은 되지만 인터넷에 연결되지 않으면 TUN을 끄고 시스템 프록시만 검증합니다. 브라우저는 되는데 특정 앱만 실패한다면 해당 앱의 프록시 주소와 라우팅을 확인하세요. 로그는 작업 시간 순서로 살펴보고 설정 또는 연결 오류가 처음 나타난 지점부터 찾으세요. 뒤이어 반복되는 시간 초과에 주의를 빼앗기지 않도록 합니다.

잠시 기존 클라이언트로 돌아가야 한다면 새 클라이언트의 네트워크 적용 기능을 끄고 종료한 뒤 백업한 기존 환경을 실행하세요. 시스템 프록시나 TUN을 두 프로그램에서 동시에 켜지 마세요. 백업에는 구독 토큰, 제어 인터페이스 키, 프록시 인증 정보가 포함될 수 있으므로 안전한 곳에 보관해야 합니다. 새 설정의 안정성, 업데이트, 재시작을 모두 확인한 뒤 기존 설치를 정리하세요.

마이그레이션에서 가장 중요한 네 가지는 구독 출처 보존, 추적 가능한 오버라이드 출처, 일치하는 포트와 네트워크 적용 설정, 업데이트 후에도 유지되는 규칙입니다. 이 순서대로 진행하면 클라이언트 교체가 전체 설정을 새로 만드는 작업으로 번지지 않습니다.