2026-10-17 클라이언트 선택 예상 읽는 시간 12분

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

지원이 종료된 Clash 클라이언트의 대안을 살펴보고, Clash Verge Rev와 FlClash의 지원 플랫폼 및 커널을 비교합니다. 구독, 규칙, 사용자 설정을 새 클라이언트로 옮기는 방법도 안내합니다.

마이그레이션 범위: 클라이언트·커널·설정 분리

Clash for Windows(이하 CFW) 프로젝트는 2023년에 개발이 중단됐습니다. 설치된 프로그램이 당장 작동을 멈추는 것은 아니지만, 이후의 시스템 호환성, 프로토콜 지원, 버그 수정은 기존 프로젝트에 기대할 수 없습니다. 마이그레이션의 목표는 설치 폴더 전체를 복사하는 것이 아니라 구독 출처와 트래픽 분기 의도, 필요한 설정을 보존한 뒤 새 클라이언트에서 실행 환경을 다시 구성하는 것입니다.

클라이언트는 UI, 구독 관리, 시스템 프록시, 서비스 제어를 담당하고, 커널은 설정을 해석해 연결을 구성하고 규칙을 적용합니다. CFW는 과거에 여러 방식으로 커널을 사용했으므로 클라이언트 이름만으로 기존 설정의 기능을 판단할 수 없습니다. 이전에 실제로 사용하던 커널 종류와 버전을 기록하고 새 클라이언트에 포함된 커널을 확인하세요. 두 프로그램의 클라이언트 버전만 단순 비교해서는 안 됩니다.

우선 이전: 구독 URL, 로컬 YAML, 사용자 규칙, 프록시 그룹 이름, 규칙 세트 출처.
별도로 다시 설정: 시스템 프록시, 시작 시 실행, 서비스 권한, TUN 어댑터 및 라우팅 설정.
필요한 항목만 유지: 프록시 그룹의 현재 선택, 속도 측정 설정, DNS 설정, 앱별 프록시 포트.
그대로 덮어쓰지 않기: 기존 클라이언트 데이터베이스, 커널 실행 파일, 캐시 폴더, 가상 네트워크 어댑터 드라이버.

대체 클라이언트: 플랫폼과 설정 방식에 맞춰 선택

Windows 데스크톱 사용자는 Clash Verge Rev와 FlClash를 우선 비교해 볼 수 있습니다. 두 클라이언트 모두 mihomo 커널 기반으로 설정을 관리하지만 UI 구성, 설정 확장 기능, 시스템 통합 방식에는 차이가 있습니다. Linux와 macOS 사용자는 설치 패키지의 아키텍처를 확인해야 하며, Android에서는 Windows용 패키지나 시스템 프록시 설정 방법을 사용할 수 없습니다.

클라이언트	지원 플랫폼	커널 및 마이그레이션 시 확인할 점
Clash Verge Rev	Windows、macOS、Linux	mihomo를 사용합니다. 데스크톱에서 구독을 관리하고 설정을 확장하며 시스템과 연동해 사용하는 경우에 적합합니다.
FlClash	Windows、macOS、Linux、Android	mihomo를 사용합니다. 데스크톱과 Android에서 비슷한 방식으로 사용하고 싶은 경우에 적합하지만, 권한은 플랫폼별로 설정해야 합니다.
Clash Nyanpasu	Windows, macOS, Linux. 이 사이트에서 제공하는 설치 패키지는 다운로드 페이지에서 확인하세요.	배포판에 따라 선택 가능한 커널이 다릅니다. 가져오기 전에 실제로 선택된 커널을 확인하고, mihomo 설정을 사용할 때는 호환되는 커널을 선택하세요.
ClashX Meta	macOS	Meta/mihomo 생태계용입니다. Windows의 서비스, 시작 항목, 네트워크 설정을 그대로 옮길 수 없습니다.

커널 버전은 해당 기기에서 실제로 확인한 값을 기준으로 합니다.

클라이언트 업데이트 버전과 커널 업데이트 버전은 서로 다른 체계이며, 같은 클라이언트에서도 커널을 바꿀 수 있습니다. 먼저 클라이언트의 커널 정보나 로그에서 버전을 기록하세요. 실제 커널 파일을 찾을 수 있다면 터미널에서 버전을 확인할 수도 있습니다. 아래 명령은 해당 실행 파일이 있는 디렉터리에서 실행해야 하며, 파일명은 설치된 파일에 맞춰 사용하세요.

# Windows PowerShell
.\mihomo.exe -v

# macOS / Linux
./mihomo -v

버전 숫자를 높이려고 기존 클라이언트의 커널을 바로 교체하지 마세요. 제어 인터페이스, 실행 인자, 디렉터리 구조가 서로 맞지 않을 수 있습니다. 클라이언트를 선택할 때는 먼저 구독에 필요한 프로토콜을 확인하고, 대상 클라이언트의 실제 커널이 이를 지원하는지 살펴보세요. ‘Clash 설정을 가져올 수 있다’는 것이 모든 mihomo 확장 필드를 지원한다는 뜻은 아닙니다.

마이그레이션 전 백업: 원본 파일과 최종 적용 설정 보관

기존 클라이언트에서 보이는 구독 파일이 커널에서 최종적으로 읽는 내용과 다를 수 있습니다. CFW의 Parsers, Mixin 또는 수동 수정으로 구독을 가져온 뒤에도 포트, 규칙, 프록시 그룹이 변경될 수 있습니다. 구독 URL만 저장하면 추가한 규칙이 새 클라이언트에서 사라지기 쉽습니다.

현재 상태 기록. 클라이언트 버전, 커널 버전, 현재 설정 이름, 실행 모드를 적고 시스템 프록시와 TUN의 활성화 여부를 저장하세요.
구독 정보 백업. 원본 구독 URL과 제공업체 이름을 저장하세요. 구독 URL에는 접근 토큰이 포함되는 경우가 많으므로 공개 메모나 스크린샷에 남기지 마세요.
로컬 파일 복사. 기존 클라이언트에서 설정 폴더를 열고 YAML, 참조 중인 로컬 규칙 세트, 사용자 스크립트를 별도의 백업 폴더에 복사하세요.
처리 결과 기록. 기존 클라이언트에서 실행 설정을 확인할 수 있다면 최종 설정도 별도로 저장하고 원본 구독과의 차이를 표시하세요. 실행 설정에는 노드 인증 정보가 평문으로 들어 있을 수 있으므로 민감한 파일로 취급해야 합니다.
시스템 설정 저장. HTTP/SOCKS 포트, LAN 공유, 우회 목록, 브라우저나 명령줄 도구에 별도로 지정한 프록시 주소를 기록하세요.

Windows에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 현재 수동 프록시를 확인할 수 있습니다. 기존 설정에서 127.0.0.1:7890을 사용했다면 주소와 포트를 기록하세요. 이는 흔히 쓰이는 예시일 뿐 모든 컴퓨터가 7890을 사용하는 것은 아닙니다. macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’에서 확인하세요. 메뉴 이름은 시스템 버전에 따라 조금씩 다를 수 있습니다.

구독 가져오기: 연결을 먼저 확인한 뒤 확장 기능 복원

새 클라이언트의 구독 또는 설정 페이지에서 원본 구독 URL을 추가하고 업데이트가 끝나면 해당 설정을 선택하세요. 배포판에 따라 메뉴 이름이 ‘설정’, ‘구독’, ‘Profiles’ 등으로 다를 수 있습니다. 중요한 것은 다운로드와 커널 로드가 성공하고 노드 목록이 비어 있지 않은지 확인하는 것입니다. 구독 제공업체에 다시 로그인해 링크를 발급받아야 한다면 새 링크 형식이 mihomo와 호환되는지 먼저 확인하세요.

기존 클라이언트의 시스템 프록시, TUN, 백그라운드 서비스를 끈 다음 프로그램을 종료하세요. 창만 닫으면 트레이 프로세스가 계속 실행될 수 있습니다.
새 클라이언트에 설정 하나를 가져온 뒤 먼저 규칙 모드로 사용하세요. TUN, LAN 공유, 시작 시 실행은 아직 켜지 마세요.
정상 작동이 확인된 노드를 선택하고 연결 로그를 살펴보세요. 그런 다음 시스템 프록시를 켜고 평소 사용하는 사이트에 접속하세요.
기본 연결이 정상인지 확인한 뒤 사용자 규칙, DNS 설정, 규칙 세트, 설정 확장 기능을 추가하세요.
구독을 한 번 수동으로 업데이트하고 확장 설정이 계속 유지되는지 확인하세요. 현재 파일에서만 수정된 상태로 남지 않도록 주의해야 합니다.

포트 충돌이 나면 설정을 계속 바꾸지 말고 프로세스부터 확인하세요

기존 커널과 새 커널은 같은 주소의 같은 포트를 동시에 사용할 수 없습니다. 로그에 address already in use가 표시되면 포트를 연달아 바꾸기보다 먼저 7890을 사용 중인 프로세스를 확인하세요. 아래는 진단 예시입니다.

# Windows PowerShell
Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -ltnp 'sport = :7890'

7891로 변경해야 한다면 브라우저 확장 프로그램, 터미널 환경 변수, 기타 수동 프록시 클라이언트도 함께 수정해야 합니다. 시스템 프록시 설정은 보통 시스템 설정을 따르는 앱에만 적용되므로 모든 프로그램이 자동으로 변경되는 것은 아닙니다.

규칙 및 사용자 설정: 참조, 순서, 덮어쓰기 확인

mihomo는 다양한 Clash 형식의 설정을 처리할 수 있지만, 마이그레이션이 모든 필드를 그대로 복사하는 작업은 아닙니다. 먼저 proxies, proxy-providers, proxy-groups, rules 사이의 이름 참조를 확인하세요. 프록시 그룹 이름을 바꿨는데 규칙의 대상이 이전 이름으로 남아 있으면 로드에 실패할 수 있습니다. 규칙은 위에서 아래 순서로 적용됩니다. 최종 대체 규칙인 MATCH는 맨 아래에 둬야 뒤의 규칙이 무시되지 않습니다.

최소 구성으로 로컬 설정 로드 확인

아래는 새 클라이언트에서 로드 여부를 확인하기 위한 최소 YAML입니다. 직접 연결만 포함하며 프록시 노드는 없으므로 실제 구독을 대체할 수 없습니다. 커널이 로드되는 것을 확인한 다음 실제 노드나 provider와 프록시 그룹을 연결하세요. 이 구성 예시로 구독 파일을 덮어쓰지 마세요.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: 트래픽 출구
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,트래픽 출구

여기서 트래픽 출구는 프록시 그룹 이름과 규칙 대상에 모두 등장하므로 두 곳의 이름이 같아야 합니다. mixed-port는 하나의 포트에서 HTTP와 SOCKS 프록시를 제공합니다. 이 예시에는 external-controller가 설정되어 있지 않아 제어 인터페이스가 추가로 열리지 않습니다. 클라이언트가 제어 인터페이스를 직접 관리한다면 클라이언트가 생성한 설정을 따르세요.

구독 확장 및 규칙 세트 항목별 이전

Parsers 및 Mixin: 범용 커널 설정 항목이 아니라 클라이언트 측 처리 기능입니다. 기존 스크립트를 그대로 실행할 수 있다고 가정하지 말고, 실제 처리 결과를 새 클라이언트의 병합 또는 스크립트 기능으로 다시 구성하세요.
규칙 세트: rule-providers의 출처, behavior, format, 업데이트 간격을 유지하고 RULE-SET에서 이름을 참조하는 부분을 확인하세요.
로컬 경로: 기존 폴더의 상대 경로는 새 작업 폴더에서 작동하지 않을 수 있습니다. 로컬 규칙 파일을 옮긴 뒤 커널이 실제로 해석하는 경로와 파일 읽기 권한을 다시 확인하세요.
기존 스크립트 방식: 기존 설정이 Clash Premium의 스크립트 기능에 의존했다면 mihomo에서도 같은 방식으로 실행된다고 가정할 수 없습니다. 트래픽 분기 요구사항을 대상 커널이 지원하는 규칙이나 클라이언트 처리 로직으로 바꾸세요.
프록시 그룹 상태: 그룹 정의를 옮겨도 현재 선택한 노드까지 옮겨지는 것은 아닙니다. 출구를 다시 선택한 뒤 자동 속도 측정과 장애 전환이 예상대로 작동하는지 확인하세요.

DNS 및 TUN: 마지막에 켜고 별도로 검증

먼저 시스템 프록시로 연결과 규칙을 확인한 다음 TUN을 활성화하세요. DNS, 라우팅, 권한 문제를 한꺼번에 진단해야 하는 상황을 줄일 수 있습니다. TUN은 가상 네트워크 어댑터 단계에서 트래픽을 처리하므로 보통 시스템 권한이나 백그라운드 서비스가 필요합니다. Windows 서비스 설치, macOS 네트워크 권한, Android VPN 권한은 서로 다른 방식이므로 각 대상 시스템에서 따로 설정해야 합니다.

DNS 설정은 전체 구성을 함께 옮겨야 합니다. fake-ip 모드는 도메인 이름에 대응하는 주소를 반환하지만, DNS 요청이 반드시 프록시를 통과하도록 보장하지는 않습니다. DNS 업스트림, nameserver-policy, 관련 라우팅, TUN의 DNS 하이재킹 설정도 확인하세요. 브라우저의 보안 DNS, 앱 내 DoH, 다른 VPN이 DNS 확인 경로를 바꿀 수도 있습니다.

LAN 서비스: 공유기 관리 페이지, NAS, 프린터에 접속해 보세요. 로컬 도메인이 공유기 DNS에 의존한다면 해당 요청이 적절한 로컬 DNS 서버로 전달되는지도 확인하세요.
업무 네트워크: 회사 인트라넷 도메인과 VPN을 테스트하세요. 여러 가상 네트워크 어댑터가 기본 경로를 동시에 변경한다면 하나씩 끄면서 충돌 원인을 찾으세요.
DNS 캐시: Fake-IP 모드나 DNS 정책을 변경한 후 테스트할 앱을 다시 시작하세요. 필요하면 Windows에서 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 비울 수 있습니다.
수신 범위: 다른 기기에서 접속해야 하는 경우에만 LAN 공유를 켜고 방화벽 규칙을 확인하세요. 한 대의 기기만 옮기는 경우 프록시 포트를 LAN에 공개할 필요가 없습니다.

시스템 프록시에서는 정상인데 TUN을 켠 뒤 문제가 생겼다면 구독을 바로 바꾸지 말고 권한, 라우팅, DNS부터 확인하세요. 노드 속도 측정 성공은 테스트 요청 하나가 완료됐다는 뜻일 뿐 앱 트래픽이 제대로 처리된다는 보장은 아닙니다.

마이그레이션 검증 및 롤백: 구독 업데이트까지 확인한 뒤 기존 환경 종료

마이그레이션을 검증할 때는 일반 브라우저, 프록시를 직접 지정한 도구, TUN이 필요한 앱을 모두 확인해야 합니다. 아래 표는 점검 항목과 예상 결과를 정리한 것으로, 미리 측정한 성능 결과가 아닙니다. 같은 대상을 연속 세 번 테스트하고 시간, 적용 규칙, 출구를 기록하세요. 한 번 우연히 연결된 것을 마이그레이션 완료로 판단하지 않도록 합니다.

확인 항목	예상 결과	문제 발생 시 먼저 확인할 항목
직접 연결되어야 하는 사이트에 접속	연결 기록에 예상한 직접 연결 규칙이 적용됨	규칙 순서, 프록시 그룹 참조, 실행 모드
프록시를 거쳐야 하는 사이트에 접속	예상한 프록시 그룹이 적용되고 선택한 출구를 사용함	노드 선택, 구독 유효성, 앱 프록시 설정
LAN 기기와 인트라넷 도메인에 접속	주소에 연결할 수 있고 DNS 결과가 로컬 네트워크 요구사항에 맞음	로컬 DNS, Fake-IP 제외 설정, TUN 라우팅
구독을 수동으로 업데이트한 뒤 클라이언트 재시작	사용자 규칙이 계속 적용되고 설정 로드 오류가 없음	확장 기능 설정 위치, 덮어쓰기 순서, 파일 경로
운영체제 재시작	시작 항목, 서비스, 프록시 상태가 예상대로 작동함	기존 시작 항목 잔존 여부, 권한, 서비스 실행 상태

문제가 생기면 역순으로 롤백

먼저 새 클라이언트의 TUN과 시스템 프록시를 끄고 백그라운드 서비스를 중지한 다음 포트를 더 이상 사용하지 않는지 확인하세요. 이후 기존 클라이언트를 실행해 원래 설정과 프록시 상태를 복원합니다. 두 클라이언트가 시스템 프록시나 TUN 라우팅을 동시에 제어하게 두지 마세요. 새 클라이언트를 종료한 뒤에도 브라우저가 인터넷에 연결되지 않는다면, 시스템에 127.0.0.1:7890을 가리키는 수동 프록시 설정이 남아 있는지 확인하세요. 해당 포트에서 서비스를 제공하는 프로세스가 없을 수 있습니다.

구독 업데이트, 시스템 재시작, 주요 앱 테스트를 모두 마친 뒤 기존 시작 항목을 삭제하고 클라이언트를 제거하세요. 오프라인 설정 백업과 마이그레이션 기록을 보관하면서 새 클라이언트 버전, 실제 커널 버전, 포트, 확장 규칙 설정 위치를 기록하세요. 이후 구독 변경이나 시스템 업그레이드로 문제가 생기더라도 전체 연결 과정을 다시 추측하지 않고 클라이언트, 커널, 설정 중 어디에서 문제가 발생했는지 구분할 수 있습니다.