Clash for Windows 지원 종료 후 대안은? Verge Rev로 구독과 오버라이드 옮기기

1. 클라이언트, 코어, 구독부터 구분하기

Clash for Windows(약칭 CFW)는 지원이 종료됐지만 기존 설정으로 연결은 계속될 수 있습니다. 다만 클라이언트 호환성 개선, 의존성 업데이트, 오류 수정은 더 이상 제공되지 않습니다. 마이그레이션의 목적은 기존 폴더를 새 프로그램에 통째로 덮어씌우는 것이 아니라 구독 출처, 개인 규칙, 시스템 트래픽 처리 방식을 각각 복원하는 것입니다. 구버전 클라이언트의 데이터베이스와 서비스 구성 요소는 새 클라이언트와 호환되지 않습니다.

Clash Verge Rev는 데스크톱 GUI 클라이언트이며, Mihomo는 설정을 파싱하고 규칙을 적용해 연결을 처리하는 코어입니다. Mihomo는 Clash Meta의 기술 계보를 잇지만, 지원하는 설정 항목이 초기 Clash 코어와 같다고 볼 수는 없습니다. 구독은 노드, 프록시 그룹, 규칙, DNS 설정 등을 담을 수 있는 원격 설정 소스입니다. 각 요소를 따로 확인해야 하며, 구독을 가져왔다는 사실만으로 모든 설정이 정상이라고 판단해서는 안 됩니다.

2. 대체 클라이언트 선택: 설정 관리 방식부터 확인

Windows에서는 Mihomo를 사용하는 Clash Verge Rev, Clash Nyanpasu, FlClash 등을 우선 검토할 수 있습니다. 프로젝트가 계속 유지 관리되는지는 마이그레이션 시점의 릴리스 기록, 이슈 대응, 코어 업데이트를 확인하세요. 다운로드 페이지에 ‘최신 버전’이라고 적혀 있다는 이유만으로 판단하지 말고, 이름이 비슷한 포크를 같은 프로젝트로 착각하지 않도록 주의하세요.

후보 클라이언트	주요 마이그레이션 고려 사항	설치 전 확인 사항
Clash Verge Rev	구독 관리, 로컬 Merge 또는 스크립트 처리, 데스크톱 시스템 프록시 및 TUN	현재 버전의 오버라이드 연결 방식, 서비스 설치 상태, 코어 버전
Clash Nyanpasu	데스크톱 설정 관리와 설정 처리 흐름	현재 버전에서 사용하는 코어와 로컬 설정 처리 기능
FlClash	데스크톱과 모바일 기기에서 비슷한 방식으로 사용하고 싶은 경우	지원 플랫폼, 설정 가져오기 방식, 로컬 규칙 편집 방법

기존 CFW에서 주로 구독과 소수의 YAML 설정만 관리했다면 Verge Rev의 Merge 방식이 구조를 비교하고 옮기기 편한 편입니다. 복잡한 Parsers 스크립트에 의존한다면 화면이 비슷한지보다 스크립트 인터페이스, 실행 순서, 업데이트 동작을 우선 살펴보세요. 다른 플랫폼의 클라이언트는 클라이언트 비교에서 확인할 수 있습니다.

3. 기존 CFW에서 백업할 항목

기존 클라이언트가 실행될 때 백업을 진행하세요. CFW의 ‘Settings’에서 설정 폴더를 여는 항목을 찾아 사용자 데이터 디렉터리를 확인합니다. 설치 방식과 버전에 따라 위치가 다를 수 있으므로 설치 폴더만 검색하지 마세요. 사용자 설정 디렉터리 전체를 오프라인 백업 위치에 복사한 다음, 아래 항목을 별도로 정리하세요.

원본 구독 주소: 구독마다 이름, 주소, 업데이트 간격을 기록하세요. 토큰이 포함된 구독 주소는 계정 접근 정보와 같으므로 공개된 문의 게시판에 올리지 마세요.
Parsers 내용: 매칭 조건, YAML 수정 항목, 스크립트 원문을 보관하고 각각 어느 구독에 적용되는지 적어 두세요.
로컬 규칙: 규칙 순서, 참조하는 프록시 그룹 이름, 규칙 세트 주소, 로컬 파일 의존성을 기록하세요.
포트 및 시스템 트래픽 처리: HTTP, SOCKS, 혼합 포트와 LAN 허용 여부, 시스템 프록시 및 TUN 상태를 기록하세요.
개인 설정: 규칙 모드, 자주 쓰는 프록시 그룹에서 선택한 노드, 사용자 지정 DNS 항목을 기록하세요.

구독에서 임시로 생성된 노드 목록만 유일한 백업으로 삼지 마세요. 구독이 업데이트되면 노드 이름, 인증 정보, 프록시 그룹이 바뀔 수 있습니다. 현재 YAML만 복사하면 이후 업데이트 기능을 잃기 쉽습니다. 원본 주소를 찾을 수 없다면 현재 YAML을 로컬 설정으로 가져와 우선 확인한 뒤, 구독 제공자에게 업데이트 경로를 문의하세요.

백업을 마쳤다면 CFW의 시스템 프록시, TUN, 시작 시 실행을 끄고 프로그램을 종료하세요. 기존 서비스가 여전히 네트워크 트래픽을 처리한다면 먼저 중지해야 합니다. 문제가 생겼을 때 되돌릴 수 있도록 기존 프로그램은 보관하되, 두 클라이언트가 시스템 프록시나 가상 네트워크 어댑터 경로를 동시에 제어하지 않도록 하세요.

4. 구독 가져오기: 오버라이드 없는 기본 상태부터 확인

Clash Verge Rev를 실행하고 ‘구독’ 페이지에서 새 구독 추가 또는 가져오기 기능을 사용해 원본 구독 주소를 등록하세요. 버튼 이름은 버전에 따라 다를 수 있습니다.
구독을 업데이트하고 현재 설정으로 지정하세요. 프록시 그룹과 노드가 표시되는지 확인하세요. 구독 이름만 있고 노드가 없다면 가져오기가 완료된 것이 아닙니다.
‘프록시’ 페이지에서 규칙 모드를 선택한 다음 주요 프록시 그룹의 선택 항목을 확인하세요. 자동 선택 그룹과 수동 선택 그룹은 동작이 다르며, 기존 클라이언트에서 선택한 항목은 보통 자동으로 옮겨지지 않습니다.
TUN은 잠시 끄고 시스템 프록시만 켠 상태에서 브라우저로 직접 연결 사이트와 프록시가 필요한 사이트에 각각 접속하세요. 그런 다음 ‘연결’ 페이지에서 규칙과 아웃바운드를 확인합니다.

가져오기 오류 유형별 해결 방법

HTTP 401 또는 403 오류라면 토큰, 계정 권한, 구독 주소를 확인하세요. 시간 초과는 DNS 문제인지, 네트워크에 연결할 수 없는지, 다운로드 경로에 문제가 있는지 구분해야 합니다. YAML 파싱 오류가 발생하면 응답 내용이 실제 설정이 아니라 웹페이지나 오류 메시지인지 확인하세요. 프록시 그룹 누락이나 존재하지 않는 노드 참조 등의 오류는 시스템 프록시를 반복해서 전환하기보다 코어 로그를 확인해야 합니다.

기존 구독을 온라인 변환 사이트에 함부로 제출하지 마세요. 변환이 필요하면 먼저 구독 제공자가 Mihomo 설정을 직접 지원하는지 확인하세요. 제3자 변환 서비스를 이용하면 구독 인증 정보도 외부에 전달될 수 있습니다. 기본 설정이 정상적으로 작동하기 전에는 DNS, 규칙, TUN을 추가로 변경하지 마세요.

5. Parsers를 Merge로 옮기기: 수정 결과를 기준으로 마이그레이션

CFW Parsers는 클라이언트에서 설정을 처리하는 기능이지, 코어 공통 설정 항목이 아닙니다. 기존 파일의 parsers:, 매칭 조건, JavaScript 함수는 Mihomo 기본 설정에 그대로 붙여 넣을 수 없습니다. 먼저 기존 설정이 ‘무엇을 바꿨는지’ 파악한 다음 Verge Rev의 Merge나 스크립트 처리 방식으로 다시 구현하세요.

기존 Parsers 동작	마이그레이션 방법	중점 확인 항목
스칼라 또는 객체 필드 덮어쓰기	가능하면 Merge를 사용하고 대상 설정과 같은 YAML 구조로 작성	필드 계층, 값 형식, 실행 후 최종값
규칙을 앞이나 뒤에 추가	현재 버전에서 명시적으로 지원하는 목록 조작을 사용하고, 지원하지 않으면 스크립트 사용	구독 원본 규칙의 유지 여부와 규칙 삽입 위치
노드 이름 변경, 조건에 따른 프록시 그룹 수정	새 클라이언트 인터페이스에 맞게 스크립트 다시 작성	이름 참조도 함께 수정하고 스크립트가 전체 설정을 반환하는지 확인
구독 주소에 따라 처리 방식 구분	해당 오버라이드를 각 구독에 연결	구독을 바꿨을 때 다른 설정에 잘못 적용되는지 확인

Merge 예시: 로그 수준과 DNS 캐시 정책 옮기기

아래 YAML은 현재 코어가 cache-algorithm을 지원하는 경우에 사용할 수 있습니다. 두 개의 특정 필드만 수정하는 예시이며, 구독의 업스트림 DNS, 프록시 그룹, 규칙은 변경하지 않습니다. 기존 Parsers에서 이 두 항목을 설정했다면 ‘구독’ 페이지에서 Merge 유형의 로컬 처리 항목을 만든 다음, 현재 버전에서 제공하는 관리 기능을 통해 대상 구독에 연결하세요.

log-level: info
dns:
  cache-algorithm: arc

저장한 뒤 설정을 다시 적용하고 실행 중인 설정에서 log-level이 info인지, dns.cache-algorithm이 arc인지 확인하세요. 코어에서 알 수 없는 필드 오류가 나오면 실제 코어 버전과 설정 문서를 확인하세요. 오류를 무시하는 방식으로 마이그레이션을 끝내서는 안 됩니다. 원래 구독에서 DNS를 활성화하지 않았다면 이 예시만으로 DNS가 켜지지는 않습니다.

규칙 목록을 일반 필드처럼 그대로 옮기면 안 됩니다

YAML의 rules는 순서가 있는 목록이며 보통 위에서부터 처음 일치하는 규칙이 적용됩니다. 규칙 두 개만 담은 rules:를 Merge에 넣는다고 해서 ‘규칙 앞에 두 개 추가’되는 것은 아닙니다. 목록 처리 방식은 클라이언트 구현과 버전에 따라 달라지며 기존 목록을 덮어쓸 수도 있습니다. 기존 Parsers의 prepend-rules도 Mihomo에 그대로 전달할 수 있는 필드가 아닙니다.

먼저 DOMAIN,example.com,DIRECT처럼 적용 범위가 좁은 테스트 규칙 하나로 확인하세요. 처음부터 전체 트래픽의 기본 처리 방식을 바꾸지 마세요.
최종 규칙 목록을 확인하세요. 테스트 규칙이 예상한 위치에 있고, 구독의 기존 규칙도 남아 있으며, MATCH가 마지막에 있어야 합니다.
구독의 프록시 그룹을 참조할 때는 그룹 이름이 완전히 일치해야 합니다. 공백, 대소문자, 기호가 다르면 참조가 실패할 수 있습니다.
기존 스크립트에 조건문이 있다면 새 클라이언트의 스크립트 시그니처에 맞춰 다시 작성하세요. CFW에서 사용하던 인수, 헬퍼 함수, 반환 방식을 그대로 사용할 수 있다고 가정하지 마세요.

6. 포트 마이그레이션: 기존 연결 방식은 유지하고 기본값을 그대로 복사하지 않기

기존 CFW에서는 HTTP 포트로 7890, SOCKS 포트로 7891을 자주 사용했지만 실제 값은 변경됐을 수 있습니다. Verge Rev의 기본 포트도 버전이나 기존 사용자 데이터에 따라 다를 수 있습니다. ‘설정’의 포트 항목과 실행 중인 설정을 기준으로 삼으세요. 기존 포트를 유지하거나, 연결하는 모든 앱의 설정을 새 포트에 맞춰 함께 바꿔야 합니다.

예를 들어 혼합 포트를 127.0.0.1:7890으로 통일하려면 클라이언트의 해당 포트 설정에서 값을 지정한 뒤 최종 설정을 확인하세요. 혼합 포트는 HTTP와 SOCKS 요청을 모두 받지만, 기존의 개별 포트가 자동으로 이 포트에 전달되는 것은 아닙니다.

mixed-port: 7890
allow-lan: false

이 설정은 로컬 혼합 포트만 지정합니다. GUI에서 관리하는 필드는 Merge의 같은 이름 항목보다 우선 적용될 수 있으므로 클라이언트의 해당 설정에서 변경하세요. 일반적인 로컬 사용에는 LAN 접근을 허용할 필요가 없습니다. 다른 기기에 프록시를 제공해야 한다면 수신 주소, 인증, 방화벽 범위를 별도로 설정하세요.

Windows에서 확인할 두 가지 항목

netstat -ano | findstr :7890
curl.exe --proxy http://127.0.0.1:7890 https://example.com/ -I

첫 번째 명령은 포트 사용 여부와 프로세스 ID를 확인합니다. 기존 클라이언트가 포트를 사용 중이면 해당 프로세스를 먼저 중지하세요. 두 번째 명령은 HTTP 프록시를 명시적으로 거쳐 요청을 보내므로 프록시 주소의 연결 여부와 앱의 시스템 프록시 사용 여부를 구분하는 데 도움이 됩니다. HTTP 응답 상태는 대상 사이트와 함께 판단해야 합니다. 명령이 끝났다는 이유만으로 프록시 연결이 정상이라고 단정할 수는 없습니다.

터미널 환경 변수, Git의 프록시 설정, 브라우저 확장 프로그램, 다운로드 도구에 기존 포트가 남아 있을 수 있습니다. 시스템 프록시를 바꿔도 이런 앱의 개별 설정까지 자동으로 변경되지는 않습니다. 외부 제어 인터페이스인 external-controller는 관리 API이지 인터넷 연결용 프록시 포트가 아닙니다. 브라우저 프록시 주소로 지정하지 말고, 마이그레이션을 위해 모든 네트워크 인터페이스에 공개해서도 안 됩니다.

7. 마지막으로 TUN과 DNS 복원하기: 트래픽을 중복 처리하지 않도록 주의

시스템 프록시는 앱이 시스템 프록시 설정을 따를 때 작동하지만, TUN은 가상 네트워크 어댑터와 라우팅으로 더 많은 트래픽을 처리합니다. 두 기능은 같은 스위치가 아닙니다. 기본 설정과 오버라이드가 모두 안정적으로 작동한 뒤 클라이언트 안내에 따라 필요한 서비스를 설치하거나 시작하고, TUN을 켜서 가상 네트워크 어댑터, 라우팅, 로그를 확인하세요. Windows 서비스 권한 문제는 서비스 상태를 확인해 해결하고, 기존 CFW의 서비스 파일을 그대로 가져오지 마세요.

기존 CFW의 TUN이 꺼져 있는지 확인하고 기본 경로를 제어할 수 있는 다른 VPN 도구를 종료하세요. 회사 VPN을 사용하는 경우에는 먼저 조직의 네트워크 정책을 따르세요.
Verge Rev의 TUN을 켜고 일반 웹사이트에 접속한 다음, 기존에 시스템 프록시를 따르지 않던 앱도 테스트하세요.
연결 페이지에서 해당 프로세스, 대상, 규칙이 표시되는지 확인하세요. 요청이 코어에 들어오지 않는다면 노드를 바꾸기보다 먼저 트래픽 처리 범위를 확인해야 합니다.
도메인 연결은 실패하지만 IP 주소로는 접속할 수 있다면 DNS 업스트림, DNS 가로채기 설정, 로그를 확인하세요. 해석 모드와 모든 서버를 한꺼번에 변경하지 마세요.

Fake-IP를 사용하면 앱이 가상 주소를 받을 수 있습니다. 흔히 쓰이는 주소 풀은 198.18.0.1/16이지만 실제 값은 설정을 기준으로 확인하세요. 이 주소는 실제 대상 IP가 아니며, 이 정보만으로 DNS 오염 여부를 판단할 수 없습니다. 기존 DNS 모드를 변경한 뒤에도 Windows에 이전 결과가 캐시되어 있다면 ipconfig /flushdns를 실행하고 영향을 받은 앱을 다시 시작하세요.

LAN 프린터, NAS, 사내 도메인에 문제가 생기면 내부 이름을 DNS에서 확인할 수 있는지, 규칙이 직접 연결을 적용하는지, TUN 경로에 해당 네트워크 대역이 포함되는지 각각 점검하세요. DIRECT 규칙을 하나 추가한다고 내부 DNS가 바로 작동하는 것은 아닙니다. 자세한 설정 항목은 고급 사용법에서 확인할 수 있습니다.

8. 마이그레이션 완료 전 확인 및 롤백 체크리스트

기존 환경을 제거하기 전에 구독 업데이트와 클라이언트 재시작을 각각 한 번 이상 진행하세요. 업데이트로 오버라이드가 별도로 유지되는지 확인할 수 있고, 재시작으로 서비스 자동 시작, 포트 저장, 시스템 프록시 복원 등의 문제를 발견할 수 있습니다. 아래 항목을 모두 통과해야 마이그레이션이 완료된 것입니다.

구독이 업데이트되고 노드와 프록시 그룹이 모두 표시되며, 선택된 구독도 예상한 항목인지 확인합니다.
규칙 모드에서 직접 연결 요청과 프록시 요청이 각각 올바른 규칙 및 아웃바운드로 처리되는지 확인합니다.
구독을 업데이트한 뒤에도 로컬 Merge 또는 스크립트가 적용되고 기존 규칙 목록이 사라지지 않는지 확인합니다.
브라우저, 터미널, 자주 쓰는 다운로드 도구가 새 포트를 사용하고 기존 프로세스는 더 이상 포트를 열어 두지 않는지 확인합니다.
TUN이 필요하다면 재시작 후 서비스와 가상 네트워크 어댑터가 정상인지 확인합니다. 필요하지 않다면 계속 꺼 둡니다.
디버깅용으로 올렸던 로그 수준을 평소 설정으로 되돌립니다. 로그를 공유하기 전에는 구독 토큰, 노드 인증 정보, 민감한 도메인을 삭제하세요.

계속 안정적으로 작동하지 않는다면 새 클라이언트의 시스템 프록시와 TUN을 끈 다음 종료하세요. 기존 클라이언트를 실행해 비교하기 전에 라우팅과 프록시 설정이 복원됐는지 확인해야 합니다. 롤백할 때도 한 번에 하나의 트래픽 처리 방식만 사용하세요. 두 클라이언트를 동시에 실행했을 때 가끔 접속된다는 이유로 정상이라고 판단하지 마세요. 실제 포트나 라우팅 충돌이 가려질 수 있습니다.