Clash for Windows 지원 종료 후 마이그레이션 방법: Verge Rev·FlClash 등 대체 클라이언트와 설정 이전

지원 종료 후 마이그레이션 범위: 클라이언트·커널·설정을 나눠서 이전

Clash for Windows는 보통 CFW라고 부르며, 2023년 11월에 유지 관리가 종료되었습니다. 기존 설치본은 계속 실행될 수 있지만, 이후 운영체제 변경이나 종속 구성 요소 문제, 프로토콜 호환성 문제는 원 프로젝트에서 더 이상 해결하지 않습니다. 마이그레이션의 목표는 새 클라이언트에서 기존 인터페이스를 그대로 재현하는 것이 아닙니다. 구독 출처, 노드, 프록시 그룹, 트래픽 분기 의도를 유지하면서 시스템 프록시와 네트워크 처리 설정을 다시 구성하는 것입니다.

먼저 세 가지를 구분해야 합니다. CFW는 그래픽 클라이언트이고, Clash·Clash Premium·Clash Meta·mihomo는 커널 관련 프로젝트입니다. YAML은 프록시, 규칙, 실행 매개변수를 담는 설정 형식입니다. Clash Meta는 이후 mihomo라는 이름으로 개발이 이어졌습니다. mihomo 기반 클라이언트를 설치해도 기존 CFW의 모든 인터페이스 설정이 자동으로 변환되는 것은 아닙니다.

마이그레이션 전에 확인할 6가지

현재 활성화된 Profile 이름과 구성이 구독 주소에서 온 것인지 로컬 YAML인지 기록합니다.
HTTP, SOCKS 또는 혼합 포트의 실제 번호를 확인합니다. 예: 7890. 기본값이라고 넘겨짚지 마세요.
실행 모드가 Rule, Global, Direct 중 무엇인지, 프록시 그룹에서 현재 어떤 노드를 선택했는지 기록합니다.
System Proxy, TUN, 시작 프로그램 등록, 백그라운드 서비스가 켜져 있는지 확인합니다.
Parsers, 사용자 지정 규칙, DNS 수정 또는 그 밖의 설정 가공 로직을 사용하고 있는지 확인합니다.
브라우저, 터미널, 개발 도구에서 프록시 주소를 별도로 지정했는지 확인합니다.

대체 클라이언트 비교: Verge Rev, FlClash, Nyanpasu

클라이언트를 고를 때는 인터페이스보다 운영체제와 설정 기능을 먼저 살펴보세요. 아래 플랫폼 범위는 프로젝트에서 일반적으로 제공하는 클라이언트 플랫폼을 뜻합니다. 운영체제 최소 버전, CPU 아키텍처, 커널 버전은 다운로드 페이지의 릴리스 정보를 확인하세요. ‘Windows 지원’을 모든 구형 Windows 버전에서 실행된다는 뜻으로 받아들이면 안 됩니다.

클라이언트	주요 플랫폼	커널 관계	마이그레이션 시 확인 사항
Clash Verge Rev	Windows、macOS、Linux	mihomo 기반	데스크톱에서 구독을 관리하기에 적합합니다. 오버라이드, 서비스, 시스템 프록시 설정은 다시 구성해야 합니다.
FlClash	Windows、macOS、Linux、Android	mihomo 기반	데스크톱과 Android를 함께 사용하는 경우에 적합합니다. 플랫폼별 네트워크 처리 방식은 서로 다릅니다.
Clash Nyanpasu	Windows、macOS、Linux	Clash 계열 커널을 관리할 수 있으며, 제공되는 옵션은 버전에 따라 달라집니다.	실제로 활성화된 커널을 확인하세요. 클라이언트 이름만으로 문법 지원 여부를 판단할 수 없습니다.

사용 방식에 맞춰 선택하기

데스크톱 설정 관리가 우선이라면: Clash Verge Rev를 검토하고, 구독 업데이트와 오버라이드, 로그 메뉴가 현재 사용 방식에 맞는지 확인하세요.
컴퓨터와 Android를 함께 사용한다면: FlClash를 검토할 수 있습니다. Windows의 서비스 모드 절차를 Android에 그대로 적용하지 마세요. Android에서는 보통 시스템 VPN 권한을 통해 트래픽을 처리합니다.
커널을 확인하거나 전환해야 한다면: Clash Nyanpasu를 검토하세요. 가져오기 전에 커널 선택과 버전을 확인한 다음 구독 설정 항목을 사용할 수 있는지 살펴보세요.

CFW라는 이름에 Windows가 들어가지만 과거 릴리스에는 다른 데스크톱 플랫폼용도 포함되어 있었습니다. 이름이 비슷한 제품만 대안으로 고려할 필요는 없습니다. 설정을 불러올 수 있는지는 인터페이스가 CFW와 비슷한지가 아니라 대상 커널, 구독 출력 형식, 클라이언트의 오버라이드 구현에 달려 있습니다.

구독과 로컬 YAML 백업: 출처와 사용할 수 있는 사본을 모두 보관하기

구독 주소와 현재 설정의 스냅샷은 용도가 다릅니다. 주소는 이후 업데이트에 사용하고, YAML 스냅샷은 현재 사용할 수 있는 노드와 사용자 지정 내용을 보존합니다. 주소만 저장하면 직접 수정했지만 이후 덮어쓴 규칙을 되찾을 수 없고, YAML만 저장하면 자동 업데이트 기능을 잃을 수 있습니다.

CFW의 Profiles 페이지에서 현재 설정을 확인하세요. 원격 설정은 원래 구독 주소를 기록하고, 로컬 설정은 원본 파일을 저장합니다. 표시 이름만 보고 출처를 추측하지 마세요.
클라이언트에서 제공하는 설정 폴더 열기 기능으로 실제 데이터 폴더를 찾으세요. 포터블 방식으로 사용했다면 설치 위치에 따라 폴더가 달라질 수 있으므로 사용자 홈 폴더만 확인해서는 안 됩니다.
설정 폴더를 별도의 백업 폴더에 복사하고, 구독 주소와 설정 이름 및 각 항목의 연결 관계도 따로 저장합니다.
Parsers 내용, 직접 작성한 규칙, 로컬 리소스 파일을 보관하세요. YAML에서 상대 경로를 참조한다면 해당 파일도 함께 백업합니다.
백업할 때의 포트, 모드, 프록시 그룹 선택을 기록하세요. 관련 설정 화면을 캡처해도 되지만 스크린샷은 YAML과 구독 주소를 대신할 수 없습니다.

provider 참조와 상대 경로 확인하기

설정의 proxy-providers와 rule-providers는 원격 주소나 로컬 path에 의존할 수 있습니다. 기본 YAML만 복사했다고 모든 종속 항목까지 옮겨지는 것은 아닙니다. 새 클라이언트에서 데이터 폴더가 달라지면 같은 상대 경로가 다른 위치를 가리킬 수 있으므로 대상 클라이언트의 작업 디렉터리에 맞춰 다시 확인하세요.

가져오기 및 전환 절차: Rule 모드부터, 시스템 프록시는 나중에

처음 마이그레이션할 때는 일반 애플리케이션 트래픽만 처리하고 TUN은 잠시 꺼두는 것이 좋습니다. 이렇게 하면 설정이 올바른지와 시스템 라우팅이 올바른지를 따로 확인할 수 있습니다. 전체 과정에서 시스템 프록시는 한 클라이언트만 관리하게 하세요. 백그라운드 프로그램 두 개가 같은 설정을 반복해서 바꾸는 상황을 방지할 수 있습니다.

기존 클라이언트의 트래픽 처리를 중지합니다. CFW의 General → System Proxy에서 시스템 프록시를 끄고, TUN이 켜져 있다면 먼저 끕니다. 그런 다음 CFW를 종료하고 시작 프로그램에 등록되어 다시 실행되지 않는지 확인하세요.
대상 클라이언트를 설치합니다.클라이언트 다운로드 페이지에서 운영체제와 아키텍처를 선택하세요. 처음 실행하면 먼저 커널이 정상적으로 작동하는지 확인한 다음 서비스 모드 등 추가 기능을 설정합니다.
설정을 하나 가져옵니다. 원격 설정에는 원래 구독 주소를, 로컬 설정에는 저장해 둔 YAML을 사용하세요. 클라이언트마다 메뉴 이름이 ‘설정’ 또는 ‘구독’일 수 있으므로 설치한 버전의 인터페이스를 기준으로 찾으세요.
방금 가져온 설정을 활성화합니다. 목록에 표시된다고 커널에서 사용 중인 것은 아닙니다. 현재 설정 표시와 로드 로그를 확인해 YAML 구문 오류나 지원하지 않는 항목이 없는지 살펴보세요.
Rule 모드를 선택합니다. 해당 프록시 그룹을 열고 사용할 수 있는 노드를 하나 직접 선택하세요. 프록시 그룹 이름이 같아도 이전에 선택한 상태까지 유지되는 것은 아닙니다.
수신 포트를 확인합니다. 새 클라이언트에서 실제 사용하는 포트를 확인한 뒤 시스템 프록시를 켜세요. 브라우저에 프록시 확장 프로그램이 있다면 먼저 확장 프로그램의 프록시 처리를 끄거나 시스템 설정을 따르도록 지정합니다.

포트 변경 예시: 7890에서 17890으로

기존 클라이언트가 127.0.0.1:7890을 사용하고 새 클라이언트가 127.0.0.1:17890을 사용한다면, 이전 주소가 고정 입력된 터미널 변수와 도구 설정을 모두 업데이트해야 합니다. 아래는 mihomo의 일부 매개변수 예시이며 노드와 규칙이 포함된 완전한 구독 설정이 아닙니다. 실제 적용은 클라이언트가 지원하는 설정이나 오버라이드 기능을 사용하세요.

mixed-port: 17890
allow-lan: false
mode: rule
log-level: info
tun:
  enable: false

mixed-port는 HTTP와 SOCKS 프록시 연결을 모두 받습니다. 커널 제어 인터페이스 포트와는 다릅니다. 제어 인터페이스는 관리용이므로 브라우저의 HTTP 프록시 입력란에 넣지 마세요. 특정 애플리케이션에서 별도의 SOCKS 수신 포트를 사용한다면 새 설정에서도 해당 포트를 다시 확인해야 합니다.

규칙·오버라이드·TUN: 그대로 옮길 수 없는 설정

CFW Parsers는 다시 구현해야 합니다

Parsers는 CFW의 설정 가공 방식이지, mihomo YAML에서 공통으로 사용하는 최상위 항목이 아닙니다. Parsers 원문을 구독 파일에 붙여 넣어도 같은 결과가 자동으로 적용되지 않습니다. 먼저 로컬 네트워크 직접 연결 규칙 추가, DNS 수정, 프록시 그룹 추가 등 실제로 수행하던 작업을 정리한 뒤, 대상 클라이언트가 지원하는 설정 병합이나 스크립트 오버라이드로 하나씩 구현하세요.

원본 구독을 먼저 저장하고 사용자 지정 수정 사항도 따로 보관하세요. 다운로드한 원격 YAML을 직접 수정하면 다음 업데이트에서 변경 내용이 덮어써질 수 있습니다. 확인 방법은 간단합니다. 사용자 지정 규칙 하나를 기록하고 구독을 한 번 업데이트한 다음, 실행 설정에 규칙이 남아 있는지와 위치가 올바른지 확인하세요.

규칙 순서와 그룹 이름을 함께 확인하기

규칙은 보통 순서대로 검사하며, 처음 일치하는 규칙이 이후 정책을 결정합니다. 우선 적용해야 하는 예외 규칙은 기본 처리 규칙보다 앞에 배치해야 합니다.
MATCH는 흔히 기본 처리 규칙으로 사용됩니다. 파일에 노드가 있는지만 보지 말고 실제로 어떤 정책 그룹을 가리키는지 확인하세요.
규칙에서 참조하는 프록시 그룹 이름은 정의된 이름과 대소문자, 공백, 기호까지 정확히 일치해야 합니다. 프록시 그룹 이름을 바꿨다면 참조하는 부분도 수정하세요.
구독에서 Clash와 Clash Meta 두 가지 출력을 제공한다면 mihomo에서는 서비스 제공자가 권장하는 호환 형식인지 먼저 확인하세요. 다른 형식의 파일 이름만 .yaml로 바꿔 가져오면 안 됩니다.

TUN과 DNS는 마지막에 별도로 켜기

TUN은 가상 네트워크 인터페이스를 만들고 라우팅과 DNS 처리 방식을 바꿀 수 있습니다. ‘더 강력한 글로벌 모드’가 아닙니다. TUN으로 트래픽을 처리하는 중에도 Rule 모드를 사용할 수 있습니다. 먼저 일반 시스템 프록시가 작동하는지 확인하고, 대상 클라이언트의 요구에 따라 서비스를 활성화하거나 권한을 부여한 다음 TUN을 켜세요.

TUN을 켠 뒤 내부 도메인, 회사 VPN, 로컬 기기 접속에 문제가 생기면 라우팅 제외 설정과 DNS 정책, 다른 VPN의 간섭 여부를 확인하세요. fake-ip는 DNS 처리 모드이므로 관련 필터와 규칙을 무시한 채 스위치 하나만 옮겨서는 안 됩니다. 어느 쪽이 더 빠른지 확인하려고 두 클라이언트의 TUN을 동시에 켜지 마세요. 문제 원인을 찾기 어려워집니다.

마이그레이션 확인: 설정 로드·프록시 연결·업데이트를 따로 테스트

노드 지연 시간이 표시되어도 특정 조건에서 테스트 대상이 응답했다는 의미일 뿐, 브라우저와 터미널, 규칙이 모두 정상이라는 뜻은 아닙니다. 아래 명령은 Windows PowerShell을 기준으로 하며 새 클라이언트의 혼합 포트가 17890이라고 가정합니다. 다른 포트를 사용한다면 명령에서도 바꾸세요.

1. 로컬 포트와 명시적 프록시 확인

Get-NetTCPConnection -State Listen -LocalPort 17890
curl.exe --proxy http://127.0.0.1:17890 --connect-timeout 10 --max-time 20 -I https://example.com/

첫 번째 명령은 해당 포트를 수신 대기 중인 프로세스가 있는지 확인합니다. 출력의 OwningProcess를 참고해 어떤 프로그램인지 추가로 확인할 수 있습니다. 두 번째 명령은 HTTP 프록시를 명시적으로 지정하며 연결 시간 초과는 10초, 전체 제한 시간은 20초입니다. 일부 PowerShell 환경에서 명령 별칭이 달라 생기는 문제를 피하려고 curl.exe를 사용합니다.

HTTP 응답을 받으면 해당 요청이 완료되었다는 뜻이지만 프록시 노드를 거쳤다는 의미는 아닙니다. Rule 모드에서 DIRECT 규칙이 적용됐을 수도 있습니다. 클라이언트의 연결 기록도 확인해 일치한 규칙, 정책 그룹, 최종 연결 경로가 예상과 맞는지 살펴보세요. 프록시를 명시하면 연결되지만 브라우저에서는 안 된다면 시스템 프록시, 브라우저 확장 프로그램, 프록시 예외 목록부터 확인하세요.

2. 터미널 변수와 시스템 설정 확인

Get-ChildItem Env:*proxy*
netsh winhttp show proxy

첫 번째 명령으로 이전 포트를 가리키는 프록시 환경 변수가 남아 있는지 확인할 수 있습니다. 두 번째 명령은 WinHTTP 프록시 설정만 보여 주며 Windows 사용자 수준 시스템 프록시 전체 상태를 나타내지는 않습니다. Windows 11에서는 ‘설정 → 네트워크 및 인터넷 → 프록시’도 열어 현재 수동 프록시 주소와 포트를 확인하세요. 터미널 도구가 시스템 프록시를 읽는지는 도구 자체에 따라 다르므로 클라이언트의 스위치만 켜서 동작 여부를 판단할 수 없습니다.

3. 업데이트와 재시작 확인

구독을 수동으로 한 번 업데이트해 노드 목록이 계속 표시되고 사용자 지정 규칙이 사라지지 않는지 확인합니다.
직접 연결되어야 하는 대상과 프록시를 거쳐야 하는 대상에 각각 접속하고, 연결 기록에서 적용된 정책을 확인합니다.
새 클라이언트를 종료한 뒤 다시 실행하고 현재 설정, 모드, 프록시 그룹 선택이 예상대로 유지되는지 확인합니다.
TUN이 필요하다면 별도로 켠 다음 로컬 네트워크, DNS, 일상적으로 사용하는 애플리케이션을 테스트합니다.
시스템을 재시작한 뒤 새 클라이언트만 자동으로 시작되고, 기존 클라이언트가 포트나 시스템 프록시를 바꾸지 않는지 확인합니다.

자주 발생하는 마이그레이션 문제와 되돌리기

구독을 가져왔는데 노드 목록이 비어 있다면 먼저 무엇을 확인해야 하나요?

먼저 구독 요청과 설정 로드 로그를 확인하세요. 주소에서 유효한 YAML 대신 로그인 페이지, 오류 메시지, 호환되지 않는 형식이 반환될 수 있습니다. proxy-provider를 사용하지만 제공자 다운로드에 실패했거나 프록시 그룹의 use에서 참조하지 않은 경우도 있습니다. 원래 구독이 여전히 유효한지 먼저 확인한 뒤 대상 커널의 지원 여부를 살펴보세요. 설정 문제를 가리려고 시스템 프록시를 반복해서 전환하지 마세요.

새 클라이언트에서 포트가 사용 중이라고 나옵니다. 포트를 바로 바꿔도 되나요?

가능하지만 먼저 해당 포트를 점유한 프로세스를 확인하세요. 기존 CFW나 남아 있는 백그라운드 서비스라면 정상적으로 종료하거나 해당 서비스를 중지해야 합니다. 17890 같은 다른 포트로 바꿔야 한다면 브라우저의 수동 프록시, 터미널 변수, 개발 도구 설정도 모두 함께 업데이트하세요. 용도를 알 수 없는 시스템 프로세스를 강제 종료하지 마세요.

마이그레이션에 실패하면 기존 설정으로 어떻게 되돌리나요?

먼저 새 클라이언트의 시스템 프록시와 TUN을 끄고 클라이언트를 종료한 다음, 기존 클라이언트와 백업 설정을 활성화하세요. 되돌리기는 임시 복구 방법일 뿐 기존 프로젝트의 지원이 종료된 사실을 바꾸지는 않습니다. 당분간 프록시를 사용하지 않을 예정이라면 종료된 포트를 가리키는 수동 프록시 설정과 환경 변수도 함께 정리하세요. 그렇지 않으면 애플리케이션의 연결이 계속 실패할 수 있습니다.

마이그레이션이 완료되려면 원래 구독을 업데이트할 수 있고, 로컬 수정 사항이 유지되며, 규칙이 적용된 이유를 확인할 수 있고, 시스템을 재시작한 뒤에도 예상대로 트래픽을 처리해야 합니다. 이 항목을 모두 확인한 다음 기존 클라이언트의 자동 시작 항목과 서비스를 제거하고, 접근이 제한된 백업을 보관하세요. 설정 항목을 확인하려면 프로토콜 참고 자료를, 시스템 프록시 문제는 증상에 따라 도움말 센터를 참고하세요.