2026-05-28 마이그레이션 예상 읽기 시간 9분

Clash for Windows 업데이트 중단 후 대안은:설정 마이그레이션 절차와 대체 클라이언트 비교

클라이언트 업데이트 중단 후 실질적인 위험과 걱정할 필요 없는 부분을 정리하고, 구독·규칙·오버라이드 설정의 전체 마이그레이션 경로를 제시하며 Clash Plus, Clash Verge Rev, FlClash의 대체 역량을 비교합니다.

업데이트 중단이 의미하는 것과 의미하지 않는 것

Clash for Windows(커뮤니티에서 흔히 CFW로 부름)는 개발자가 아카이브 처리를 발표한 이후 더 이상 새 버전이 나오지 않고, 취약점도 수정되지 않으며, 새로운 코어 기능에도 적응하지 않습니다. 이는 명확한 사실이지만, "지금 당장 쓸 수 없다"거나 "설정 파일이 전부 무효가 됐다"는 식으로 과도하게 해석되곤 하는데, 두 가지 모두 정확하지 않습니다.

먼저 위험의 범위를 명확히 하겠습니다. 업데이트 중단이 가져오는 실질적인 영향은 크게 세 가지입니다. 첫째, 클라이언트에 내장된 코어 버전이 아카이브 시점의 버전으로 고정되어, 이후 코어에 추가되는 새 프로토콜 유형(예: 개선된 전송 계층 난독화 방식)이나 규칙 문법 확장을 CFW는 더 이상 지원하지 않습니다. 둘째, 클라이언트 자체에 수정되지 않은 UI나 연결 안정성 문제가 있어도 더 이상 패치가 나오지 않습니다. 셋째, 운영체제가 업그레이드된 뒤(특히 Windows의 네트워크 스택 변경) 구버전 클라이언트와 시스템 구성 요소 간의 호환성 문제는 사용자가 스스로 우회하는 수밖에 없으며, 공식적인 대응 창구가 없습니다.

걱정할 필요 없는 부분도 마찬가지로 명확히 짚어둘 만합니다. 먼저, 이미 작성된 구독 링크, 규칙 세트, DNS 설정 등의 내용은 모두 자신의 설정 파일 안에 저장되어 있으며 클라이언트 자체에 종속되지 않으므로, 클라이언트를 바꾸는 것이 모든 것을 다시 설정해야 한다는 뜻은 아닙니다. 다음으로, mihomo(Clash Meta) 코어는 여전히 활발히 유지보수되고 있으므로, 새 클라이언트가 더 최신 mihomo 코어를 내장하고 있다면 이전에 겪었던 프로토콜 미지원이나 규칙 미적용 문제가 오히려 함께 해결될 수도 있습니다. 셋째, 설정 파일 문법(YAML 구조, 프록시 그룹 작성법, 규칙 매칭 로직)은 주요 클라이언트 간에 높은 호환성을 가지므로, 마이그레이션의 핵심 작업량은 설정을 다시 작성하는 것이 아니라 기존 파일을 새 클라이언트에 올바르게 불러오고 소수의 필드 차이를 대조하는 것입니다.

신중하게 다뤄야 하는 경우

설정 파일에 수동으로 작성한 커스텀 규칙이나 오버라이드 스크립트가 많고, 이 내용이 CFW 고유의 필드 작성법에 의존한다면 마이그레이션 전에 원본 파일을 먼저 백업하고 항목별로 대조한 뒤 진행하는 것이 좋으며, 구 클라이언트를 바로 삭제하지 마세요.

마이그레이션 전 준비: 백업과 목록 정리

클라이언트를 교체하기 전에 기존 자산을 완전히 백업해두면, "마이그레이션 후 규칙이 사라졌다"는 대부분의 문제를 피할 수 있습니다.

설정 파일 디렉터리 찾기

CFW의 설정 파일은 일반적으로 사용자 디렉터리 아래의 .config\clash나 클라이언트 설치 디렉터리 내의 profiles 폴더에 저장되며, 파일명은 보통 구독 생성 시 생긴 문자열에 .yaml 또는 .yml 확장자가 붙습니다. 모든 구독에 해당하는 설정 파일을 찾아 새로 만든 임시 폴더에 복사하세요.
구독 원본 링크 기록하기

설정 파일은 구독을 가져온 뒤 생성된 결과물이므로, 더 안전한 마이그레이션 방식은 기존 파일을 그대로 옮기는 것이 아니라 구독 링크로 설정을 다시 생성하는 것입니다. CFW의 구독 관리 화면을 열어 각 구독의 원본 URL을 전부 복사해 별도의 텍스트 파일로 저장하세요.
오버라이드 스크립트 사용 여부 확인하기

CFW에서 특정 구독에 오버라이드 규칙이나 자바스크립트 오버라이드 스크립트(포트 강제 변경, 규칙 추가, 광고 차단 그룹 제거 등에 사용)를 추가한 적이 있다면, 이 내용은 구독 링크를 따라 자동으로 마이그레이션되지 않으므로 스크립트 본문을 별도로 복사해 새 클라이언트에 다시 붙여넣어야 합니다.
시스템 프록시와 TUN 설정 확인하기

현재 시스템 프록시 모드를 쓰고 있는지 TUN 모드를 쓰고 있는지, 그리고 혼합 포트(mixed-port), LAN 연결 허용(allow-lan) 등 필드 값을 적어두세요. 이는 마이그레이션 후 가장 쉽게 놓치지만 인터넷 접속 여부에 직접적인 영향을 주는 설정 항목입니다.

설정 파일 마이그레이션의 구체적인 절차

백업과 목록 정리가 끝나면, 본격적인 마이그레이션 작업은 세 가지 방식으로 나뉩니다. 자신의 실제 사용 습관에 맞게 선택하면 됩니다.

방법 1: 구독 링크 재등록(권장)

새 클라이언트의 구독 관리 화면에 원본 구독 URL을 붙여넣어, 새 클라이언트가 직접 가져와 설정 파일을 생성하도록 합니다. 이 방식의 장점은 설정 내용이 계속 구독 제공자에 의해 유지보수되므로, 이후 노드 목록이나 규칙 세트가 업데이트되어도 수동으로 동기화할 필요가 없다는 것입니다. 단점은 기존 클라이언트에서 수동으로 수정한 부분(예: 특정 프록시 그룹의 정책 조정)이 함께 넘어오지 않아 다시 설정해야 한다는 점입니다.

방법 2: 로컬 설정 파일 직접 가져오기

백업해둔 .yaml 파일을 새 클라이언트의 "파일에서 가져오기" 기능으로 불러옵니다. 이 방식은 직접 수정한 내용을 전부 그대로 유지하지만, 구독 제공자가 이후 업데이트할 경우 새 버전으로 덮어쓸지 스스로 판단해야 합니다.

# 일반적인 Clash / mihomo 설정 파일 최상위 구조. 마이그레이션 시 필드가 새 클라이언트에서 인식되는지 확인하세요
mixed-port: 7890
allow-lan: true
mode: rule
log-level: info
dns:
  enable: true
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
proxies:
  - name: "예시 노드"
    type: vmess
    server: example.com
    port: 443
proxy-groups:
  - name: "자동 선택"
    type: url-test
    proxies: ["예시 노드"]
rules:
  - DOMAIN-SUFFIX,example.com,자동 선택
  - MATCH,DIRECT

가져온 뒤에는 세 가지를 중점적으로 확인하세요. 첫째, proxy-groups에서 참조하는 노드 이름이 proxies 목록과 완전히 일치하는지(대소문자, 공백 차이로도 매칭이 실패합니다). 둘째, rules에 쓰인 정책 그룹 이름이 실제로 존재하는지—새 클라이언트가 정의되지 않은 그룹에 오류를 낸다면 대개 이 문제입니다. 셋째, DNS 설정 블록의 작성법으로, 신버전 코어는 nameserver-policy, fake-ip-filter 등의 필드를 구버전 코어보다 더 엄격하게 해석할 수 있습니다.

방법 3: 혼합 마이그레이션

먼저 구독 링크로 기본 설정을 생성한 뒤, 기존 설정의 오버라이드 스크립트 본문을 새 클라이언트의 오버라이드 기능에 별도로 붙여넣습니다. 대다수의 장기 사용자가 실제로 채택하는 방식으로, 구독 제공자의 지속적인 유지보수를 누리면서도 자신의 커스텀 내용을 잃지 않을 수 있습니다.

마이그레이션 후 검증 체크리스트

전환이 끝나면 순서대로 확인하세요: 노드 목록에서 속도 테스트가 정상적으로 되는지, 프록시 그룹의 자동 선택 정책이 적용되는지, 지정한 도메인이 올바른 그룹으로 라우팅되는지(규칙에 설정한 도메인으로 실제 테스트), DNS 해석에 이상이 없는지(명령줄 도구로 도메인 해석 결과를 한 번 조회). 네 가지가 모두 정상이면 그때 구 클라이언트를 제거하세요.

세 가지 대체 클라이언트 비교

CFW가 업데이트를 중단한 뒤 커뮤니티에서는 점차 몇 가지 공인된 대체 방향이 형성되었으며, 각각 접근 방식에 차이가 있습니다. 선택할 때는 아래 기준으로 자신의 실제 필요와 대조해보면 됩니다.

클라이언트	기술 방식	인터페이스 스타일	적합한 사용자
Clash Plus	mihomo 코어 기반, 공식이 지속적으로 유지보수	CFW의 기존 조작 습관과 유사, 적응 비용이 낮음	마이그레이션 후 조작 방식 변화를 최소화하고 싶은 사용자
Clash Verge Rev	Rust로 작성된 셸 + mihomo 코어, 커뮤니티가 활발히 유지보수	경량이며 그래픽 규칙 편집과 구독 관리 제공	세부 커스터마이징을 좋아하고 설정을 직접 다루는 것을 즐기는 사용자
FlClash	크로스플랫폼 셸, 데스크톱과 모바일에서 통일된 경험 지원	간결하며 다중 기기 설정 동기화의 일관성을 강조	여러 기기를 오가며 사용하는 사용자

클라이언트

기술 방식

인터페이스 스타일

적합한 사용자

Clash Plus

mihomo 코어 기반, 공식이 지속적으로 유지보수

CFW의 기존 조작 습관과 유사, 적응 비용이 낮음

마이그레이션 후 조작 방식 변화를 최소화하고 싶은 사용자

Clash Verge Rev

Rust로 작성된 셸 + mihomo 코어, 커뮤니티가 활발히 유지보수

경량이며 그래픽 규칙 편집과 구독 관리 제공

세부 커스터마이징을 좋아하고 설정을 직접 다루는 것을 즐기는 사용자

FlClash

크로스플랫폼 셸, 데스크톱과 모바일에서 통일된 경험 지원

간결하며 다중 기기 설정 동기화의 일관성을 강조

여러 기기를 오가며 사용하는 사용자

세 클라이언트의 공통 기반은 모두 mihomo 코어이며, 이는 프로토콜 지원 범위와 규칙 문법의 핵심 능력이 동일하다는 뜻입니다. 실질적인 차이는 인터페이스 조작의 깊이, 구독 관리의 편리함, 그리고 추가적인 그래픽 설정 기능을 제공하는지 여부에서 드러납니다. 기존에 CFW에서 가장 기본적인 구독+규칙 방식만 사용했다면 어느 클라이언트로 바꿔도 기능이 부족하다는 느낌은 거의 없을 것입니다. CFW의 특정 세부 기능(예를 들면 특정한 트래픽 통계 표시 방식)에 의존했다면, 소규모 테스트로 새 클라이언트가 동등한 기능을 제공하는지 먼저 확인한 뒤 정식으로 전환하는 것이 좋습니다.

선택 시 실제로 고려할 몇 가지 판단 기준

규칙을 자주 수동으로 수정해야 하는가:규칙을 자주 추가·삭제한다면 그래픽 규칙 편집 화면을 제공하는 클라이언트를 우선 선택하면 YAML 파일을 직접 수정하다 오류가 나는 확률을 줄일 수 있습니다.
여러 기기에서 사용하는가:같은 설정을 컴퓨터와 휴대폰에서 오가며 써야 한다면, 설정 동기화 기능이 더 완비된 방안을 우선 고려해 구독을 중복으로 관리하는 부담을 줄이세요.
코어 업데이트 속도를 중시하는가:세 클라이언트 모두 mihomo 업스트림 업데이트를 따라가지만 배포 주기에는 차이가 있으므로, 새 프로토콜 기능이 급히 필요한 사용자는 각각의 업데이트 로그 빈도를 살펴보는 것이 좋습니다.

마이그레이션 완료 후 "두 번째 함정"을 피하는 법

클라이언트를 바꿨다고 모든 것이 끝난 것은 아닙니다. 다음은 실제 마이그레이션 과정에서 가장 자주 놓치고, 나중에 다시 손봐야 하는 세부 사항들입니다.

구독 업데이트 주기를 다시 확인해야 합니다.클라이언트마다 구독 자동 업데이트 간격을 설정하는 위치가 다르므로, 마이그레이션 후에는 구독 상세 정보를 다시 열어 자동 업데이트 주기(보통 시간 단위)가 예상대로 설정되어 있는지 확인해야 합니다. 그렇지 않으면 노드 정보가 오랫동안 갱신되지 않아 연결이 실패해도 원인을 찾기 어려워집니다.

부팅 시 자동 실행과 조용한 모드도 다시 체크해야 합니다.이 부분이 가장 쉽게 잊히는 항목입니다—구 클라이언트에서 설정한 부팅 시 자동 실행은 새 클라이언트로 넘어오지 않으므로, 재설치 후 시스템을 재부팅했을 때 프록시가 자동으로 켜지지 않는 것을 발견하게 됩니다. 새 클라이언트의 시스템 설정에서 다시 체크해야 합니다.

로컬 오버라이드 스크립트는 항목별로 테스트해야 합니다.오버라이드 스크립트에 CFW 고유의 API나 필드명에 의존하는 작성법이 있다면, 새 클라이언트가 해석할 때 오류 없이 조용히 무시할 수 있습니다. 일부 규칙을 하나씩 주석 처리한 뒤 순서대로 복원하며, 어느 부분이 적용되고 어느 부분이 적용되지 않는지 짚어보는 것이 좋습니다.

코어 버전 번호를 확인해야 합니다.마이그레이션 후 새 클라이언트에서 현재 사용 중인 mihomo 코어 버전 번호를 확인하고, 이전에 겪었던 문제와 대조해보면 코어 업그레이드로 이전 문제가 함께 해결됐는지, 아니면 추가 설정이 필요한지 확인할 수 있습니다.

권장하지 않는 방식

"귀찮다"는 이유로 업데이트가 중단된 CFW를 후속 위험을 전혀 신경 쓰지 않으면서 장기간 계속 사용하는 것은 권장하지 않습니다. 프로토콜 호환성 문제는 시간이 지날수록 점점 누적되며, 마이그레이션을 늦출수록 대조해야 할 설정 차이는 대체로 더 많아집니다.

전체적으로 봤을 때, CFW에서 대체 클라이언트로 옮기는 작업은 일회성이며 통제 가능한 작업량입니다. 핵심 절차는 구독 링크와 오버라이드 스크립트를 백업하고, mihomo 코어 기반의 새 클라이언트를 선택하고, 규칙과 DNS 필드를 항목별로 대조하고, 완료 후 검증 체크리스트를 한 번 거치는 것입니다. 순서대로만 진행하면 기존의 사용 습관과 설정 로직은 거의 손실 없이 유지될 수 있습니다.