클라이언트 선택 예상 읽는 시간 12분

Clash for Windows 지원 종료 후 대안은? Clash Verge Rev로 마이그레이션하기

Clash for Windows 지원 종료 후 대안을 살펴보고 커널, 지원 플랫폼, 설정 호환성을 비교합니다. 구독과 사용자 지정 규칙을 유지하며 옮기는 방법도 안내합니다.

지원 종료 후 마이그레이션 핵심: 설정 출처, 커널, 트래픽 처리 방식

Clash for Windows(이하 CFW) 지원이 종료되어도 기존 설치본이 즉시 작동을 멈추는 것은 아닙니다. 다만 클라이언트 UI와 의존 구성 요소, 커널이 현재 네트워크 환경에 맞춰 더 이상 업데이트되지 않습니다. 일반적인 CFW 0.20.39 설치본은 기존 구독을 계속 처리할 수 있지만, 연결된다는 이유만으로 장기간 사용할 환경으로 적합하다고 볼 수는 없습니다. 마이그레이션할 때는 재사용할 수 있는 설정을 보존하고 새 클라이언트가 실제로 무엇을 불러왔는지 다시 확인해야 합니다.

세 가지 요소를 구분해야 합니다. 클라이언트는 구독 관리, 트레이 메뉴, 시스템 연동을 담당하고, 커널은 설정을 해석하고 규칙을 적용해 연결을 구성합니다. 구독에는 노드와 정책 그룹, 경우에 따라 규칙이 포함됩니다. 클라이언트를 바꿔도 구독은 유지할 수 있지만, 커널을 바꾸면 기존 필드와 스크립트, DNS 동작을 다시 점검해야 합니다.

  • 설정 출처: 구독 URL과 현재 로컬 YAML을 기록하고, 구독에서 가져온 설정과 로컬에서 덮어쓴 설정을 구분해 둡니다.
  • 커널 차이: Clash Verge Rev는 mihomo를 사용합니다. mihomo는 기존 Clash.Meta 프로젝트가 이후 채택한 이름이며, 이는 구형 CFW 화면만 다른 외형으로 바꾸는 것과는 다릅니다.
  • 트래픽 유입 경로: 시스템 프록시, TUN, 앱에 직접 입력하는 HTTP/SOCKS 프록시는 서로 다른 방식입니다. 스위치 하나만 보고 마이그레이션 성공 여부를 판단하면 안 됩니다.

대안 비교: Clash Verge Rev와 다른 선택지

Windows 데스크톱에서 구독 가져오기, 정책 선택, 로그 확인, TUN 기능이 주된 요구라면 Clash Verge Rev가 가장 간단한 마이그레이션 경로입니다. 다른 데스크톱 OS에서도 같은 종류의 설정을 사용하려면 macOS 및 Linux 버전을 고려할 수 있습니다. 모바일 기기에는 운영체제에 맞는 별도 클라이언트가 필요하며, 데스크톱 설치 파일을 Android나 iOS에서 그대로 사용할 수는 없습니다.

옵션 커널 및 플랫폼 설정 이전 시 확인할 점 적합한 경우
Clash Verge Rev mihomo；Windows、macOS、Linux 구독을 다시 가져오고 로컬 덮어쓰기와 시스템 트래픽 처리 설정을 다시 구성 데스크톱 인터페이스, 구독 관리, TUN이 필요한 경우
ClashX Meta Meta/mihomo 계열; macOS 배포 패키지의 커널 버전을 확인하고 메뉴 막대와 시스템 프록시 옵션을 다시 설정 주로 macOS 메뉴 막대에서 조작하는 경우
mihomo 명령줄 mihomo; 데스크톱 및 서버용 빌드 제공 YAML, 서비스 실행, 로그, 제어 인터페이스를 직접 관리 스크립트 배포나 상시 서비스 실행이 필요한 경우
당분간 CFW 유지 기존 설치본에 포함된 커널에 따라 다름 단기간 롤백용으로만 사용하고, 클라이언트 이름만으로 프로토콜 지원 여부를 판단하지 않음 마이그레이션 기간에 기존 설정의 동작을 재확인

호환되는 것은 설정의 의미이지 설정 폴더 전체가 아닙니다

일반적으로 proxies, proxy-groups, rules는 마이그레이션의 기반으로 사용할 수 있습니다. 하지만 클라이언트에 저장된 UI 상태와 구독 데이터베이스, 서비스 설치 정보는 서로 호환되지 않습니다. CFW 데이터 폴더 전체를 Clash Verge Rev 폴더에 덮어쓰거나, 기존 커널 실행 파일을 새 클라이언트 폴더에 복사하지 마세요.

CFW의 Parsers와 클라이언트 측 스크립트, Clash Premium의 스크립트 규칙은 서로 구분해야 합니다. 전자는 클라이언트 처리 과정에 해당하고, 후자는 커널 기능과 관련됩니다. 둘 다 mihomo에서 그대로 작동한다고 가정할 수 없습니다. 단순한 도메인 분기는 표준 규칙으로 바꿀 수 있지만, 복잡한 스크립트는 파일 확장자만 바꾸지 말고 기능별로 대체 방법을 확인해야 합니다.

마이그레이션 전 백업: 구독 외에 보관할 항목

먼저 CFW의 General 페이지에서 Home Directory를 눌러 실제 데이터 폴더를 여세요. 기존 설치본 중 상당수는 사용자 폴더 아래의 .config/clash를 사용하지만, 포터블 모드나 사용자 지정 경로를 쓸 수도 있으므로 현재 설치 화면에 표시된 위치를 기준으로 해야 합니다. 백업 중 설정 파일이 기록되지 않도록 먼저 프로그램을 종료하세요.

  1. 구독 주소 저장: Profiles에 등록된 각 구독의 이름과 원본 URL을 기록합니다. 구독 URL에는 접근 자격 증명이 포함되는 경우가 많으니 개인 백업에만 보관하고, 공개 문의 게시물이나 스크린샷, 온라인 변환 페이지에 붙여 넣지 마세요.
  2. 로컬 설정 저장: 현재 사용하는 YAML과 직접 관리하는 규칙 파일, 규칙 제공자, 스크립트를 복사합니다. 구독 캐시 파일을 직접 수정한 적이 있다면 따로 표시해 두세요. 이런 변경 사항은 업데이트 과정에서 덮어써질 수 있습니다.
  3. 실행 매개변수 기록: 프록시 모드, HTTP/SOCKS 또는 혼합 포트, LAN 연결 허용 여부, DNS, TUN, 제어 인터페이스 주소를 기록합니다. 제어 인터페이스 키를 노드 비밀번호처럼 옮기지 마세요.
  4. 선택 상태 기록: 주요 정책 그룹에서 현재 선택한 노드나 하위 그룹을 적어 둡니다. 그룹 이름이 같아도 새 클라이언트가 선택 결과를 이어받는다는 보장은 없습니다.
  5. 외부 의존성 확인: 브라우저 확장 프로그램, 터미널 환경 변수, Git, 개발 도구에 127.0.0.1:7890 같은 주소가 고정되어 있는지 확인합니다.

구독으로 복구할 수 있는 것은 서비스 제공자가 전달하는 내용뿐이며, 로컬에서 사용하던 설정까지 모두 복구되지는 않습니다. 예를 들어 기존 클라이언트에서 특정 업무 도메인을 직접 연결로 지정했지만 구독에 해당 규칙이 없다면, 다시 가져온 뒤 그 동작은 사라집니다. 이런 차이는 완성된 것처럼 보이는 실행 설정 하나만 보관하는 것보다 별도 목록으로 정리해 두는 편이 확인하기 쉽습니다.

Clash Verge Rev로 마이그레이션: 구독을 확인한 뒤 시스템 프록시 활성화

1단계: 설치 후 커널이 실행되는지 먼저 확인

운영체제와 프로세서 아키텍처에 맞는 설치 파일을 선택하세요. 설치 파일은 클라이언트 다운로드 페이지에서 받을 수 있습니다. CFW를 종료하고 기존 시스템 프록시와 TUN을 끈 다음 Clash Verge Rev를 실행하세요. 먼저 커널 상태와 로그를 확인합니다. 커널이 실행되지 않는다면 노드를 반복해서 바꾸기보다 설정 파싱 오류, 포트 충돌, 서비스 실행 오류부터 해결하세요.

2단계: 원본 구독 또는 로컬 YAML 가져오기

‘구독’ 페이지에서 가져오기 기능을 사용해 원본 구독 URL을 추가하세요. 기존에 로컬 YAML을 사용했다면 로컬 파일 가져오기 기능을 이용합니다. 버전에 따라 버튼 문구가 다를 수 있으므로, 가져온 결과가 커널에서 읽을 수 있는 Clash/mihomo 설정인지 확인해야 합니다. Base64 노드 목록이나 다른 클라이언트 전용 콘텐츠를 반환하는 링크는 완전한 YAML로 바로 사용할 수 없을 수도 있습니다.

가져온 뒤 설정을 선택하고 노드 목록, 정책 그룹, 규칙이 표시되는지 확인하세요. 파싱 오류가 발생하면 로그에 표시된 필드나 줄 번호부터 확인합니다. HTTP 401 또는 403 오류가 나면 구독 권한과 서비스 제공자 상태를 점검하세요. 구독 URL에 프록시 연결이 필요한 경우, 사용 가능한 기존 환경에서 설정을 내려받아 백업할 수 있지만 새 클라이언트로 전환할 때는 기존 커널을 종료해야 합니다.

3단계: 포트를 확인한 다음 시스템 프록시 활성화

‘설정’에서 포트 설정 메뉴를 열어 실제 혼합 포트를 확인하세요. 일부 버전에서는 ‘Clash 설정’ 아래에 있습니다. 아래에서는 7897을 예시로 사용하지만, 모든 설치에서 고정으로 써야 하는 값은 아닙니다. 기존 포트 7890을 계속 사용하려면 해당 포트를 점유한 기존 프로세스가 없는지 먼저 확인하세요. 새 포트를 사용한다면 앱에 고정된 프록시 주소도 함께 변경해야 합니다.

  1. 실행 모드를 ‘규칙’으로 설정하고 사용할 수 있는 정책이나 노드를 지정하세요.
  2. ‘시스템 프록시’를 켜고 TUN은 일단 끈 상태로 둔 다음, 브라우저에서 자주 이용하는 사이트에 접속해 보세요.
  3. ‘연결’ 또는 로그에서 적용된 규칙, 정책 경로, 연결 결과를 확인해 요청이 새 커널로 전달되는지 점검하세요.
  4. 기본 프록시 연결을 확인한 뒤 시작 프로그램 등록, 서비스 모드, TUN을 하나씩 복구하세요. 여러 변수를 한꺼번에 바꾸지 마세요.

사용자 지정 규칙 유지: 덮어쓰기 위치와 정책 그룹 이름을 함께 이전

구독을 업데이트하면 일반적으로 원격 콘텐츠를 다시 가져옵니다. 계속 유지해야 하는 로컬 규칙은 다운로드된 구독 캐시를 직접 편집하지 말고, 클라이언트가 지원하는 확장 설정이나 병합 설정, 스크립트 기능에 넣어야 합니다. 구체적인 메뉴는 버전에 따라 달라질 수 있지만, 최종 설정에서 로컬 규칙이 실제 rules에 포함되었는지, 기본 규칙보다 앞에 배치되었는지 확인하는 것이 핵심입니다.

아래는 규칙 순서 예시일 뿐, 완전한 구독 설정은 아닙니다. 테스트용 도메인 example.com은 그대로 두었습니다. PROXY는 예시 정책 그룹 이름이므로 실제 설정과 철자까지 일치해야 합니다.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY
  • 순서: 규칙은 위에서 아래로 적용됩니다. MATCH 뒤에 놓인 일반 규칙은 기대한 대로 작동하지 않습니다.
  • 대상: DIRECT는 기본 제공 정책이고, PROXY는 실제로 존재하는 노드나 정책 그룹이어야 합니다. 구독에서 이름이 바뀌면 참조하는 항목도 함께 수정해야 합니다.
  • 병합: 사용하는 확장 기능이 규칙을 앞에 추가하는지, 뒤에 추가하는지, 배열 전체를 바꾸는지 확인하세요. rules를 잘못 교체하면 기존 구독의 분기 규칙이 모두 사라질 수 있습니다.
  • 규칙 세트: rule-providers의 URL, 형식, 동작 유형, 로컬 경로를 확인하세요. 기존 PC의 절대 경로는 다른 PC에서 그대로 사용할 수 없습니다.

기존 YAML의 최상위 필드를 모두 반드시 유지해야 하는 설정으로 보지 마세요. 새 클라이언트가 수신 포트, 제어 인터페이스, TUN 매개변수를 관리할 수 있습니다. 로컬 덮어쓰기와 UI 설정에서 같은 필드를 수정한다면 최종 적용 우선순위를 확인해야 합니다. 필드 설명은 설정 참고 자료에서 확인할 수 있습니다.

DNS와 TUN: 연결 여부를 넘어 앱 동작까지 확인

먼저 DNS를 점검하고 특수 도메인을 확인하세요

기존 커널에서 마이그레이션한 뒤에는 DNS의 fake-ip와 실제 주소 확인, DNS 요청의 출구, 규칙 적용 방식에 따라 접속 결과가 달라질 수 있습니다. 먼저 새 클라이언트의 기본 설정으로 일반 웹사이트에 접속되는지 확인한 다음 기존 DNS 사용자 지정 설정을 단계적으로 복구하세요. 특정 사이트 하나를 작동시키려고 출처가 불분명한 DNS 설정을 여러 개 겹쳐 적용하지 마세요.

브라우저는 정상인데 회사 내부 도메인에 접속할 수 없다면, 기존 시스템이 VPN에서 제공하는 내부 DNS에 의존했는지, 해당 도메인에 전용 DNS 정책이 필요한지 먼저 확인하세요. fake-ip 모드에서 합성 주소가 표시되는 것만으로 DNS 오류라고 볼 수는 없습니다. 앱에서 실제 IP가 필요한 경우에만 실제 설정을 바탕으로 필터링이나 도메인 해석 정책을 검토하세요.

TUN은 별도로 검증해야 합니다

시스템 프록시는 시스템 프록시 설정을 따르는 앱을 주로 지원합니다. TUN은 가상 네트워크 어댑터와 라우팅을 통해 더 많은 트래픽을 처리하지만, 모든 앱과 프로토콜, 네트워크 환경에서 자동으로 호환되는 것은 아닙니다. Windows에서는 클라이언트 안내에 따라 필요한 서비스를 설치하거나 활성화하고, 권한이 충분한지 확인한 뒤 TUN을 켜세요.

  • 자동 라우팅이 두 번 적용되지 않도록 기존 클라이언트의 TUN을 끄세요.
  • 브라우저, 시스템 프록시를 따르지 않는 앱 하나, LAN 주소를 각각 테스트하세요.
  • 회사 VPN, 가상 머신 네트워크, 보안 소프트웨어가 새 라우팅과 충돌하는지 확인하세요.
  • TUN을 켠 뒤 내부 네트워크에 문제가 생기면 먼저 TUN을 끄고 비교한 다음 라우팅과 DNS를 분석하세요. 여러 설정을 한꺼번에 삭제하지 마세요.

검증 및 롤백: 포트, 요청, 규칙 기록으로 문제 찾기

아래 PowerShell 명령은 새 혼합 포트가 7897임을 확인한 상태를 전제로 합니다. 첫 번째 명령은 포트에 연결할 수 있는지만 확인하고, 두 번째 명령은 HTTP 프록시를 명시해 요청을 보냅니다. 예시 사이트의 응답은 기본 연결 상태를 확인하는 용도일 뿐, 실제 업무 사이트 테스트를 대신하지 않습니다.

Test-NetConnection 127.0.0.1 -Port 7897
curl.exe --proxy http://127.0.0.1:7897 --connect-timeout 10 --max-time 20 -I https://example.com

TcpTestSucceeded : True는 로컬 포트에 연결할 수 있다는 뜻일 뿐, 노드나 원격 사이트가 정상이라는 의미는 아닙니다. 프록시를 명시한 요청은 성공하지만 브라우저에서 실패한다면 시스템 프록시와 브라우저 자체의 프록시 설정을 먼저 확인하세요. 요청도 실패한다면 클라이언트 로그에서 정책 선택, 노드 연결, DNS를 점검합니다.

증상먼저 확인할 항목다음 조치
커널 실행 실패YAML 파싱 오류, 수신 포트 충돌기존 프로세스를 종료하고 로그에 표시된 필드를 확인
브라우저는 정상이나 터미널에서 실패터미널 프록시 환경 변수가 기존 포트를 가리킴주소를 변경한 뒤 터미널을 다시 열어 테스트
기존 클라이언트와 규칙 적용 결과가 다름모드, 규칙 순서, 정책 그룹 이름연결 기록에서 실제로 적용된 규칙 확인
재시작 후 트래픽이 프록시를 거치지 않음서비스 실행 상태, 시스템 프록시, TUN 권한커널 실행 여부와 트래픽 처리 스위치를 각각 확인
구독 업데이트 후 사용자 지정 규칙이 사라짐캐시를 수정했는지 지속 확장 설정을 수정했는지 확인로컬 덮어쓰기를 다시 구성하고 업데이트 테스트

마이그레이션을 마치기 전에 구독 업데이트, 클라이언트 종료 후 재실행, 시스템 재부팅을 각각 한 번 이상 진행하고 직접 연결 사이트, 프록시 사이트, 내부 네트워크 리소스를 다시 확인하세요. 롤백해야 한다면 새 클라이언트의 시스템 프록시와 TUN을 먼저 끄고 새 커널을 종료한 뒤 기존 클라이언트를 복원하세요. 누락된 트래픽을 보완하겠다며 클라이언트 두 개를 동시에 실행하지 마세요.

새 환경이 안정적으로 작동하는 것을 확인한 뒤 기존 프로그램을 정리하고, 필요한 구독과 규칙 백업은 보관하세요. 이후에는 클라이언트 버전, 커널 버전, 구독 내용, 로컬 덮어쓰기를 각각 관리하고 문제가 생기면 한 번에 한 항목만 변경해야 합니다. 처음 설정하는 방법은 사용 가이드에서 확인하고, 연결 관련 문제는 문제 해결을 참고하세요.

Clash 다운로드운영체제와 설치 파일 선택