2026-08-04 클라이언트 선택 예상 읽기 시간 12분

Clash for Windows 지원 종료 후 대체 클라이언트 비교 및 기존 설정 이전

지원이 종료된 클라이언트 현황과 유지 관리 중인 대체 앱을 비교하고, 구독·규칙·오버라이드 설정을 새 클라이언트로 옮기는 방법을 안내합니다.

먼저 결론부터: 클라이언트 전체가 아니라 설정만 이전하세요

Clash for Windows(이하 CFW)는 2023년에 지원이 종료됐으며, 마지막으로 공개된 버전은 일반적으로 0.20.39로 알려져 있습니다. 기존 설치본이 계속 실행되더라도 커널, 의존성, 시스템 호환성이 업데이트된다는 뜻은 아닙니다. 새 프로토콜을 인식하지 못하거나 시스템 업데이트 후 서비스에 문제가 생긴다면 같은 구버전 설치 파일을 반복해서 다시 설치하기보다 이전을 고려하세요.

Windows 사용자는 Clash Verge Rev와 Clash Nyanpasu를 먼저 비교해 볼 수 있습니다. 데스크톱과 Android에서 비슷한 방식으로 사용하고 싶다면 FlClash도 함께 살펴보세요. 선택할 때는 GUI 클라이언트와 포함된 커널의 배포 현황을 각각 확인해야 합니다. 이름에 Clash가 들어간다는 이유만으로 호환성을 판단하면 안 됩니다. 설치 파일 출처와 현재 지원 플랫폼 및 아키텍처는 클라이언트 다운로드 페이지에서 확인할 수 있습니다.

대체 클라이언트 선택 기준: 커널, 설정 입력 방식, 시스템 연동

GUI 클라이언트는 주로 구독, 트레이 메뉴, 시스템 프록시, 서비스 설치를 관리하고, 커널은 프록시 프로토콜, 규칙 매칭, DNS, 연결 전달을 담당합니다. Clash Meta는 이후 mihomo라는 이름으로 계속 개발되고 있지만, Clash라는 이름을 쓰는 모든 클라이언트가 같은 커널을 사용한다는 뜻은 아닙니다. 기존 UI 스크립트가 새 커널에서 그대로 실행된다는 의미도 아닙니다.

후보 클라이언트	우선 고려할 만한 사용 목적	이전할 때 확인할 항목
Clash Verge Rev	Windows·macOS·Linux 데스크톱에서 구독 및 시스템 연동	mihomo 설정 호환성, 서비스 모드, 설정 병합 및 스크립트 입력 방식
Clash Nyanpasu	다른 데스크톱 인터페이스와 설정 관리 방식 선호	실제로 사용하는 커널, 설정 처리 순서, 시스템 프록시 및 TUN 설정
FlClash	데스크톱과 Android를 함께 사용할 예정	플랫폼별 설치 파일, 백그라운드 실행 권한, 설정 오버라이드 기능
기존 CFW	이전 기간에 기존 설정을 오프라인으로 확인하는 용도	지원이 종료된 상태이므로 장기적인 업데이트용으로 사용하지 않음

다운로드 전에 세 가지 확인

운영체제와 아키텍처: Windows의 「설정」→「시스템」→「정보」에서 시스템 종류를 확인하세요. x64와 ARM64는 서로 다른 아키텍처이므로 파일 크기가 아니라 프로젝트에서 제공하는 패키지에 맞춰 선택해야 합니다.
프로젝트 배포 기록: 공식 저장소의 Releases, 최근 수정 내역, 운영체제 지원 안내를 확인하세요. 파생 클라이언트는 이름이 비슷해도 유지 관리 상태가 다를 수 있으므로 각각 확인해야 합니다.
필요한 기능: 웹 브라우저만 사용한다면 시스템 프록시로 충분할 수 있습니다. 시스템 프록시를 따르지 않는 앱까지 연결해야 하는 경우에만 TUN, 서비스 권한, DNS 설정을 살펴보세요.

‘옵션이 더 많다’는 점만으로 클라이언트를 선택하지 마세요. 기존 구독이 정상 작동하는 사용자라면 최종 설정을 확인할 수 있는지, 로컬 규칙을 보존할 수 있는지, 시스템 네트워크를 안정적으로 복구할 수 있는지가 실험적 옵션 하나보다 중요합니다.

이전 전 백업: 구독, 규칙, 인터페이스 설정을 따로 저장

먼저 CFW의 「Profiles」에서 현재 활성화된 설정을 기록하고, 「Proxies」에서 모드와 각 프록시 그룹의 선택 항목을 확인하세요. 그런 다음 「Settings」에서 실제 설정 폴더를 찾아 엽니다. 기본 설치에서 흔히 사용하는 경로는 %USERPROFILE%\.config\clash이지만, 포터블 설치나 사용자 지정 경로에서는 다를 수 있으므로 클라이언트에서 연 폴더를 기준으로 삼으세요.

구독 출처 저장: 구독 URL, 업데이트 간격, 서비스 제공업체의 안내를 기록하세요. 구독 링크에는 보통 접근 자격 증명이 포함되므로 보호된 로컬 저장소에 보관하고 공개 게시판이나 스크린샷에 노출하지 마세요.
설정 파일 백업: CFW를 종료한 뒤 설정 폴더를 복사하고, 현재 설정의 YAML 텍스트도 따로 저장해 항목별로 비교할 수 있게 하세요. 내보낸 노드 목록은 구독 URL을 대신할 수 없으므로 이후 자동 업데이트에는 원래 구독 주소가 필요합니다.
사용자 지정 항목 별도 저장: Parsers, Mixin, 사용자 지정 규칙, 규칙 세트 URL, 로컬 파일, DNS 오버라이드를 포함해 보관하세요. 구독에서 제공된 항목과 나중에 직접 추가한 항목을 구분해 기록합니다.
시스템 연동 설정 기록: HTTP·SOCKS·mixed 포트, 시스템 프록시, 시작 시 실행, 서비스 모드, TUN 활성화 여부를 저장하세요. 캐시, 기존 서비스 프로그램, 구형 커널을 새 설치 폴더에 함께 덮어쓰지 마세요.

백업 폴더에는 노드 비밀번호, 구독 토큰, 외부 컨트롤 인터페이스 키가 포함될 수 있습니다. 이전이 끝난 뒤에도 안전하게 보관하세요. 실수로 공개했다면 로컬 스크린샷만 삭제하지 말고 해당 서비스에서 자격 증명을 변경해야 합니다.

구독 이전: 먼저 원본 설정을 정상 작동시키기

첫 단계에서는 구독만 가져오고 기존 스크립트는 활성화하지 않기

CFW를 종료하고 시스템 프록시, TUN, 시작 시 실행을 끄세요. 새 클라이언트를 열어 구독 관리에서 기존 구독 URL을 가져옵니다. 예를 들어 Clash Verge Rev에서는 보통 「구독」 페이지에서 가져올 수 있으며, 버튼 이름과 위치는 설치된 버전에 따라 다를 수 있습니다. 가져오기에 성공하면 직접 한 번 업데이트한 뒤, 목록에 표시되기만 하는 것이 아니라 해당 설정이 선택되어 활성화됐는지 확인하세요.

이어서 프록시 그룹이 빠짐없이 표시되는지 확인하세요. 특히 자동 선택, 장애 조치, 직접 이름을 지정한 분기 그룹을 살펴봐야 합니다. 기존 클라이언트에서 저장한 노드 선택은 이전되지 않을 수 있으며, 그룹 이름이 같아도 동일한 노드가 선택된 것은 아닙니다. 먼저 사용 가능 여부를 아는 노드를 직접 선택한 다음 규칙 모드를 켜고 기본 연결을 테스트하세요.

가져오기에 실패하면 오류 유형별로 확인

HTML 또는 로그인 페이지가 반환됨: 구독이 만료됐는지, 웹페이지 주소를 복사했는지, 구독 URL을 새로 발급받아야 하는지 확인하세요. 웹페이지가 열린다고 해서 응답이 YAML인 것은 아닙니다.
알 수 없는 프록시 유형 또는 필드 오류: 실제 실행 중인 커널과 구독 형식을 확인하세요. 먼저 서비스 제공업체가 안내하는 Clash 또는 mihomo용 구독을 사용하고, 오류를 피하려고 노드 필드를 임의로 삭제하지 마세요.
프록시 그룹에서 참조 대상을 찾을 수 없음: 그룹 내 노드 이름, 중첩 그룹 이름, use에서 참조하는 provider 이름을 확인하세요. 이름이 정확히 일치해야 합니다.
로컬 설정은 작동하지만 온라인 업데이트에 실패함: 시스템 시간, 구독 서버 연결 상태, 업데이트 요청에 사용되는 네트워크 경로를 확인하세요. 먼저 규칙 모드 문제라고 단정하지 마세요.

로컬 YAML을 이전할 때는 rule-providers와 proxy-providers의 상대 경로를 특히 확인하세요. 기존 파일을 새 폴더로 복사해도 참조 경로가 그대로 유효하다는 보장은 없습니다. 외부 규칙 세트 형식도 지정된 type 및 behavior와 일치해야 합니다.

규칙과 오버라이드: 최종 생성된 YAML을 항목별로 이전

CFW의 Parsers는 클라이언트 측 설정 처리 기능이므로 mihomo 커널 필드처럼 사용할 수 없습니다. 기존 스크립트의 함수 진입점, 주입 대상, 실행 시점은 새 클라이언트와 다를 수 있습니다. 기존 로직을 ‘규칙 추가’, ‘DNS 변경’, ‘프록시 그룹 조정’처럼 구체적인 요구 사항으로 나눈 뒤 대상 클라이언트가 지원하는 설정 병합 또는 스크립트 기능으로 다시 작성하세요.

먼저 단순한 규칙을 옮기고 복잡한 처리는 나중에 복원

아래는 로컬 네트워크 직접 연결 규칙 두 개의 예시일 뿐, 전체 구독 설정이 아니며 기존 rules 목록을 그대로 대체해서도 안 됩니다. 이 규칙이 실제로 필요하다면 클라이언트의 규칙 우선 적용 기능이나 설정 편집 기능을 통해 기존 규칙 체인에 추가하고, 마지막 기본 규칙은 유지하세요:

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve

192.168.50.0/24는 예시 네트워크 대역이므로 실제 로컬 네트워크 주소에 맞게 조정하세요. 규칙은 보통 위에서 아래 순서로 매칭됩니다. 로컬 예외 규칙은 먼저 적용될 수 있는 포괄적인 규칙보다 앞에 배치하고, 마지막 MATCH가 나머지 트래픽을 처리하도록 하세요. 규칙 대상이 사용자 지정 프록시 그룹이라면 해당 그룹이 실제로 존재해야 합니다. 기존 이름을 그대로 복사했다고 설정이 유효해지는 것은 아닙니다.

DNS와 Fake-IP는 따로 이전

기존 DNS 설정 전체를 한 번에 복사하지 마세요. 먼저 새 클라이언트의 기본 설정으로 정상 작동하는 기준 환경을 만든 다음, 필요한 사용자 지정 DNS 서버, 도메인 정책, Fake-IP 제외 항목을 옮기세요. Fake-IP는 예약 주소를 사용해 도메인과 IP를 매핑하는 기능이지 실제 프록시 노드 주소가 아닙니다. 활성화 후 문제가 생기면 가상 주소만 보고 설정 오류로 단정하지 말고 클라이언트 DNS 로그와 앱 동작을 함께 확인하세요.

로컬 네트워크 검색, 사설 도메인, 고정 DNS에 의존하는 앱은 DNS 응답과 연결 경로를 각각 확인해야 합니다. DNS 모드를 변경한 뒤에는 해당 앱을 완전히 종료하고 다시 테스트하세요. Windows에서는 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 비울 수 있지만, 브라우저와 앱 자체 캐시까지 모두 삭제되는 것은 아닙니다.

포트, 시스템 프록시, TUN: 세 단계로 확인

1단계: 로컬 프록시가 연결을 수신하는지 확인

CFW에서 흔히 사용하는 HTTP 포트는 7890, SOCKS 포트는 7891이며 외부 컨트롤 인터페이스는 보통 9090입니다. 실제 값은 기존 설정을 기준으로 확인하세요. 새 클라이언트는 7897처럼 다른 포트를 사용할 수 있습니다. 컨트롤 인터페이스는 브라우저용 프록시 포트가 아니므로 앱의 HTTP 프록시 설정에 입력하면 안 됩니다.

새 클라이언트에 mixed 포트가 7897로 표시된 경우 PowerShell에서 다음 명령을 실행할 수 있습니다. 첫 번째 명령은 연결을 수신 중인 프로세스를 확인하고, 두 번째 명령은 지정한 프록시를 통해 테스트 주소에 접속합니다. 테스트 전에 시스템 프록시를 켤 필요는 없습니다.

Get-NetTCPConnection -State Listen -LocalPort 7897
curl.exe -I --proxy http://127.0.0.1:7897 https://example.com/

HTTP 응답을 받았다는 것은 해당 요청에 응답이 왔다는 뜻일 뿐, 모든 분기 규칙이 올바르다는 의미는 아닙니다. 연결 거부 오류가 표시되면 커널이 실행 중인지와 포트가 일치하는지 먼저 확인하세요. 포트 사용 중 오류가 나면 기존 클라이언트나 다른 프록시 프로그램이 백그라운드에서 실행 중인지 살펴보고, 정체를 알 수 없는 시스템 프로세스를 무작정 종료하지 마세요.

2단계: 시스템 프록시 활성화

로컬 프록시 테스트를 통과한 뒤 새 클라이언트에서 시스템 프록시를 켜고, Windows의 「설정」→「네트워크 및 인터넷」→「프록시」에서 주소와 포트를 확인하세요. 브라우저는 접속되는데 특정 앱만 연결되지 않는다면 해당 앱이 시스템 프록시를 따르지 않거나 별도 프록시 설정 또는 다른 네트워크 제한을 사용하고 있을 수 있으므로 앱 설정부터 확인하세요.

3단계: 필요한 경우 TUN 활성화

TUN은 가상 네트워크 인터페이스를 통해 트래픽을 처리하며, 보통 서비스 권한, 라우팅, DNS 설정이 필요합니다. 시스템 프록시가 정상 작동하는 것을 확인한 뒤 클라이언트 안내에 따라 서비스 모드를 설치하거나 활성화하고, 마지막으로 TUN을 켜세요. 원인을 찾기 어려워지지 않도록 단계마다 테스트해 서비스, DNS, 라우팅을 한꺼번에 변경하지 마세요.

TUN을 켠 뒤 회사 VPN, 로컬 네트워크 접속, 가상 머신 네트워크에 문제가 생기면 먼저 TUN을 끄고 복구되는지 확인한 다음 라우팅 충돌과 제외 설정을 살펴보세요. 두 클라이언트에서 TUN을 동시에 실행하지 말고, TUN을 켜기 위해 모든 데스크톱 프로그램을 계속 관리자 권한으로 실행하지도 마세요.

이전 완료 확인 및 롤백 체크리스트

웹페이지 한 번 접속에 성공했다고 해서 모든 경로가 정상인 것은 아닙니다. 아래 항목을 확인한 뒤 기존 클라이언트를 제거하면 구독, 규칙, 시스템 트래픽 처리 중 무엇이 문제인지 구분하기 쉽습니다.

구독 업데이트: 수동 업데이트가 성공하고, 현재 활성 설정과 업데이트 시간이 올바르며, 업데이트 후에도 로컬 오버라이드가 유지됩니다.
규칙 매칭: 연결 목록이나 로그에서 직접 연결 요청과 프록시 요청을 각각 하나 이상 확인하고, 매칭된 규칙, 프록시 그룹, 최종 노드를 점검합니다.
앱별 확인: 브라우저, 개발 도구, 프록시가 필요한 다른 앱을 각각 테스트하세요. 브라우저 결과를 시스템 전체의 결과로 간주하지 마세요.
로컬 네트워크: 라우터 관리 페이지, 로컬 네트워크 서비스, 사내 도메인에 접속해 보세요. TUN을 사용한다면 특히 꼼꼼히 확인해야 합니다.
재시작 후 복구: 클라이언트를 다시 시작한 뒤 시스템도 재부팅하고, 시작 시 실행, 서비스, 프록시 그룹 선택, 시스템 프록시 상태가 예상대로 복구되는지 확인하세요.
종료 후 복구: 클라이언트를 정상 종료한 뒤 시스템 프록시가 원래대로 돌아오는지 확인하세요. 연결되지 않는 주소가 남아 있다면 Windows 프록시 설정에서 수동 프록시를 끈 다음 종료 절차를 점검하세요.

롤백해야 한다면 먼저 새 클라이언트의 시스템 프록시와 TUN을 끄고 커널을 종료하세요. 그런 다음 백업한 기존 설정을 복원하고 네트워크를 제어하는 클라이언트가 하나뿐인지 확인합니다. 롤백은 문제를 비교·진단하기 위한 방법일 뿐, 지원이 종료된 클라이언트가 다시 유지 관리된다는 뜻은 아닙니다. 새 환경이 안정되면 기존 프로그램을 제거하고, 더 이상 사용하지 않는 서비스는 기존 클라이언트의 안내에 따라 삭제하세요. 필요한 오프라인 백업만 보관하면 됩니다.

이전 과정에서 가장 중요한 것은 단계별로 확인하는 것입니다. 먼저 구독 원본을 유지한 뒤 사용자 지정 규칙을 옮기고, 로컬 포트를 확인한 다음 시스템 트래픽을 새 클라이언트가 처리하도록 설정하세요. 규칙, DNS, TUN의 관계를 더 알아보려면 사용 설명서를 참고하세요. 설치와 연결 문제는 자주 묻는 질문에서 증상별로 확인할 수 있습니다.