Clash for Windows 업데이트 종료 후 대응법: 대체 클라이언트 선택과 마이그레이션 절차

Clash for Windows를 더 이상 권하지 않는 이유

Clash for Windows(약칭 CFW)는 초기 Windows 플랫폼에서 가장 널리 쓰인 그래픽 클라이언트로, 원조 Clash 코어에 의존합니다. 원조 Clash 코어가 2023년 유지보수를 종료한 이후 CFW의 업데이트도 함께 멈췄습니다. 현재 다운로드 가능한 버전은 대부분 오래된 코어 분기에 머물러 있어, 프로토콜 호환성 수정도 받지 못하고 새로운 규칙 문법도 반영되지 않습니다.

구버전 CFW를 계속 쓰면 몇 가지 실질적인 문제가 생깁니다. 새로 배포되는 구독 노드의 일부 프로토콜(예: 특정 전송 계층 커스텀 파라미터)이 올바르게 해석되지 않을 수 있고, 규칙 세트에 등장하는 새로운 문법(예: RULE-SET 원격 규칙 조합, 프로세스명 매칭 규칙)이 구버전 코어에서 무시되거나 오류를 일으킬 수 있습니다. TUN 모드의 최신 시스템 버전 드라이버 호환성도 아무도 후속 수정을 하지 않습니다. 이런 문제는 단기적으로는 눈에 잘 띄지 않지만, 구독 제공처가 설정 형식을 업데이트할수록 구버전 클라이언트는 점점 더 버거워집니다.

현재 Windows 플랫폼에서 활발히 유지보수되는 대체 방안은 대부분 mihomo 코어를 중심으로 전개됩니다. 이는 커뮤니티가 원조 Clash 코어를 기반으로 이어서 개발한 분기로, 프로토콜 지원을 보강하고 다수의 오래된 문제를 수정했으며, 이 글에서 추천하는 세 클라이언트가 공통으로 사용하는 엔진입니다.

대체 클라이언트 3종 비교

마이그레이션은 "적당히 쓸만한 것 하나 설치"하는 문제가 아닙니다. 클라이언트마다 인터페이스 논리, 규칙 편집 방식, 리소스 점유가 꽤 다릅니다. 아래는 실제 사용 경험을 바탕으로 한 간단한 평가이며, 구체적인 버전 번호와 코어 파라미터는 다운로드 페이지의 최신 정보를 기준으로 확인하세요.

Clash Plus

인터페이스가 간결하고 진입 장벽이 낮으며, 구독 관리와 노드 전환이 단순화되어 설정 파일을 붙잡고 씨름하고 싶지 않은 사용자에게 적합합니다. 규칙 편집은 시각적 패널 방식으로, YAML을 직접 작성하지 않고도 대부분의 일상적인 조정을 마칠 수 있습니다. 다만 심화 커스터마이징 능력은 상대적으로 제한적이라, CFW에서 넘어왔지만 설정 문법을 깊이 파고들 생각이 없는 사용자에게 알맞습니다.

Clash Verge Rev

커뮤니티 활동이 가장 활발한 선택 중 하나로, mihomo 코어를 기반으로 만들어졌으며 규칙 엔진 동작이 안정적입니다. 설정 파일의 시각적 편집과 수동 편집을 자유롭게 전환할 수 있어, 그래픽 인터페이스를 원하면서도 설정 파일에 대한 통제력을 놓치고 싶지 않은 사용자에게 적합합니다. 데스크톱 3대 플랫폼(Windows/macOS/Linux)에서 경험이 거의 동일하며, CFW에서 넘어올 때 호환성 문제가 가장 적은 경로 중 하나입니다.

FlClash

플랫폼 지원 범위가 더 넓고 데스크톱과 모바일 경험이 통일되어 있으며, 인터페이스 스타일은 경량화 쪽에 가까워 여러 기기 간 동일한 사용 습관을 유지해야 하는 사용자에게 적합합니다. 규칙 편집 역시 그래픽 방식을 지원하며, 코어 업데이트 반영 속도도 꾸준히 안정적입니다.

세 제품 모두 오픈소스이자 무료이며 코어는 통일되게 mihomo를 사용합니다. 즉 프로토콜 호환성 관점에서 보면 마이그레이션 위험이 낮습니다. 진짜 차이는 사용 습관과 설정 관리 방식에 있으니, 규칙을 직접 손으로 작성할 필요가 있는지에 따라 선택하시면 됩니다.

마이그레이션 절차: 구독·규칙·설정 이전 방법

마이그레이션의 핵심 작업량은 "새 소프트웨어 설치"가 아니라, 구버전 클라이언트에 쌓아온 구독 주소·커스텀 규칙·사용 습관을 온전히 옮기는 데 있습니다. 아래 순서대로 진행하면 대체로 한 번에 마무리할 수 있습니다.

1단계: 구독 링크를 그대로 보관하기

CFW의 구독 관리 화면을 열어 각 구독의 전체 주소를 복사해 따로 저장해 둡니다(메모장이나 메모 앱이면 충분합니다). 구독 주소 자체는 클라이언트와 무관하므로 새 클라이언트에서는 이 링크들을 다시 가져오기만 하면 됩니다. CFW가 생성한 로컬 캐시 파일을 그대로 마이그레이션하려 하지 않아도 되고, 그렇게 시도하는 것도 권장하지 않습니다.

2단계: 커스텀 규칙과 정책 그룹 기록하기

CFW에서 수동으로 추가한 규칙이 있다면(예: 특정 도메인에만 프록시 정책을 지정, 특정 광고 도메인을 차단), 이런 내용은 보통 구독 설정의 오버레이 계층이나 로컬 규칙 파일에 적혀 있습니다. 마이그레이션 전에 항목별로 스크린샷을 찍거나 텍스트를 복사해 백업해 두고, 새 클라이언트 설치가 끝난 뒤 수동으로 다시 입력하는 것을 권장합니다. 설정 파일이 클라이언트 간에 그대로 읽힐 것이라고 기대하지 마세요. 클라이언트마다 설정 필드의 확장 문법이 완전히 일치하지 않아, 파일을 그대로 재사용하면 필드 충돌이 생기기 쉽습니다.

3단계: 새 클라이언트 설치 및 구독 가져오기

1. 다운로드 페이지에서 해당 플랫폼용 설치 파일을 내려받아 안내에 따라 설치를 완료합니다.
2. 클라이언트의 구독 관리 화면을 열고, 앞서 저장해 둔 구독 주소를 붙여 넣어 가져옵니다.
3. 노드 목록 로딩이 끝나면 먼저 연결 테스트를 한 번 실행해 지연 데이터가 정상적으로 반환되는지 확인합니다.
4. 앞서 기록해 둔 커스텀 규칙을 새 클라이언트의 규칙 편집 영역에 다시 입력합니다.
5. 프록시 모드(규칙 / 전역 / 직접 연결)와 TUN 모드 스위치를 확인해 마이그레이션 전 사용 습관과 일치하는지 확인합니다.

4단계: 시스템 프록시와 자동 시작 확인하기

새 클라이언트 설치가 끝나면 시스템 프록시 스위치, 부팅 시 자동 시작 옵션은 다시 한 번 설정해야 합니다. 이는 시스템 차원의 설정이라 클라이언트 전환에 따라 자동으로 이어지지 않습니다. 마이그레이션 완료 당일에는 CFW를 바로 삭제하지 말고 새 클라이언트를 하루 이틀 실행해 안정성을 확인한 뒤 구버전을 제거하는 것을 권장합니다. 그러면 연결 공백이 생기지 않습니다.

흔한 마이그레이션 함정과 점검 방법

실제 마이그레이션 과정에서 가장 자주 걸리는 문제는 다음 몇 가지에 집중됩니다. 미리 알아두면 점검 시간을 많이 아낄 수 있습니다.

• 구독 가져오기 후 노드 목록이 비어 있음: 구독 주소에 구버전 클라이언트 전용 파라미터 태그가 붙어 있을 가능성이 큽니다. 링크 끝의 불필요한 파라미터를 제거하고 다시 가져오거나, 구독 제공처에 링크 형식이 바뀌었는지 문의해 보세요.
• 커스텀 규칙 이전 후 적용되지 않음: 규칙의 매칭 유형 작성 방식이 새 클라이언트의 규칙 엔진 문법과 일치하는지 확인하세요. 예를 들어 도메인 매칭 규칙의 작성 순서, 프로세스명 매칭의 대소문자 구분 등은 클라이언트마다 세부적으로 다를 수 있습니다.
• TUN 모드 활성화 후 인터넷 연결 안 됨: 새 클라이언트에서 처음 TUN 모드를 켤 때는 보통 추가 시스템 권한 확인(관리자 권한 또는 가상 네트워크 카드 드라이버 설치)이 필요합니다. 클라이언트가 표시하는 안내에 따라 권한을 순서대로 부여하면 되며, 권한 요청 단계를 건너뛰지 마세요.
• 두 클라이언트가 시스템 프록시 포트를 동시에 점유: 구버전 CFW를 삭제하기 전에는 반드시 먼저 시스템 프록시 스위치를 꺼야 합니다. 그렇지 않으면 신구 클라이언트가 같은 포트를 두고 충돌해 프록시가 끊겼다 이어졌다 하는데, "네트워크 불안정"처럼 보이지만 실제로는 포트 충돌입니다.
• 규칙 세트 업데이트 후 지연 데이터가 사라짐: 일부 클라이언트는 규칙 세트 갱신 중에 지연 테스트 결과가 잠시 비워집니다. 자동 재측정이 끝날 때까지 기다리면 되며, 클라이언트를 재시작할 필요는 없습니다.

전반적으로 보면 CFW에서 mihomo 코어 기반 클라이언트로 옮길 때 핵심 작업량은 "구독 이전 + 규칙 보완 + 시스템 설정 재승인" 이 세 가지에 집중되며, 프로토콜 호환성 자체는 장애물이 아닙니다. 30분 정도 절차대로 진행하면 대체로 매끄럽게 전환할 수 있고, 이후로도 코어와 규칙 문법의 지속적인 업데이트 지원을 받을 수 있습니다.