2026-05-06 클라이언트 선택 예상 읽기 시간 9분

Clash 클라이언트 유지보수 종료 후 마이그레이션 방법: 설정 내보내기와 대체 클라이언트 목록

Clash for Windows, ClashX 등 유지보수가 종료된 클라이언트는 코어가 낡고 규칙이 실패할 위험이 있습니다. 설정 파일과 구독 내보내기 방법, 플랫폼별 대체 가능한 활성 클라이언트, 마이그레이션 후 재확인할 설정 항목을 정리했습니다.

유지보수 종료 클라이언트의 세 가지 구체적 위험

Clash for Windows는 2024년에 업데이트가 중단되었고, ClashX와 ClashX Pro도 이미 오래전부터 관리되지 않고 있습니다. 이런 클라이언트는 여전히 실행되고 연결도 되지만, 장기간 사용하면 추상적인 "불안전"이 아니라 실제로 세 가지 구체적인 문제를 겪게 됩니다.

코어가 옛 버전에 고정.Clash for Windows에 내장된 코어는 원조 Clash 분기에 머물러 있어, 이후 프로토콜 파싱과 연결 안정성에 대한 모든 수정 사항이 반영되지 않습니다. 원조 Clash 프로젝트 자체도 이미 업데이트가 중단되어, 새로운 프로토콜 특성(일부 VLESS 확장 필드, 새로운 Hysteria2 파라미터 등)이 옛 코어에서 파싱 실패로 이어질 수 있습니다.
규칙 문법이 따라가지 못함.Clash Meta(mihomo) 코어는 새로운 규칙 유형과 정책 그룹 기능을 계속 추가하고 있습니다. 예를 들어 rule-providers의 행동 기반 규칙, dns.nameserver-policy를 통한 세밀한 DNS 정책 등입니다. 유지보수가 종료된 클라이언트의 코어는 이런 새 문법을 인식하지 못해, 설정 파일에 사용하면 바로 오류가 나거나 조용히 무시됩니다.
시스템 호환성 저하.macOS와 Windows의 시스템 업데이트는 네트워크 확장, 프록시 API의 동작 방식을 바꿉니다. 유지보수가 종료된 클라이언트는 이를 따라가지 못해, 시스템 프록시를 설정해도 적용되지 않거나 시스템 업그레이드 후 클라이언트 자체가 실행되지 않는 경우가 흔합니다.

판단 기준

"클라이언트가 오래됐다"는 이유만으로 서둘러 마이그레이션할 필요는 없습니다. 실제로 손을 써야 하는 신호는 설정 파일에서 새 코어 규칙 문법 오류가 나타나거나, TUN 모드가 새 시스템 버전에서 켜지지 않거나, 구독 노드가 옛 코어가 지원하지 않는 프로토콜을 사용하는 경우입니다. 이 중 하나라도 나타나면 마이그레이션을 계획해야 합니다.

마이그레이션 전: 설정 파일과 구독을 먼저 내보내기

마이그레이션의 핵심은 처음부터 다시 설정하는 것이 아니라, 기존 설정 자산을 통째로 새 클라이언트로 옮기는 것입니다. 이동 대상은 크게 로컬 설정 파일과 구독 링크 두 가지입니다.

설정 파일의 실제 위치 찾기

Clash for Windows의 설정 파일은 기본적으로 사용자 디렉터리의 .config\clash 폴더에 저장되며, 파일명은 보통 구독으로 생성된 .yaml입니다. ClashX 계열은 ~/.config/clash 디렉터리에 저장됩니다. 텍스트 편집기로 직접 열어 내용이 온전한지 확인하고, 다음 필드가 있는지 중점적으로 확인하세요.

proxies:
  - name: "노드 예시"
    type: vless
    server: example.com
    port: 443
rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://example.com/reject.yaml"
rules:
  - DOMAIN-SUFFIX,github.com,노드 선택
  - MATCH,다이렉트

설정 파일이 구독 링크를 통해 자동 생성된 것이라면(직접 작성한 것이 아니라면), 로컬 생성 파일을 옮기기보다 구독 링크를 다시 찾아 사용하는 편이 더 안전합니다. 로컬 파일은 이전 업데이트 시점의 옛 버전일 수 있지만, 구독 링크는 서비스 제공자의 최신 노드 목록을 받아올 수 있습니다.

구독 링크 찾는 곳

대부분의 구독 서비스 제공자는 구매 이메일, 사용자 패널, 또는 서비스 사이트의 "내 구독" 페이지에 링크를 남겨둡니다. 로컬 클라이언트의 구독 이름이 서비스 패널의 요금제 이름과 일치한다면, 구독 주소를 바로 복사하면 되고 고객 지원팀에 연락할 필요는 없습니다. 구독 링크를 찾을 수 없다면 클라이언트 설정 안에 "설정 관리" 또는 "Profile" 같은 화면이 있는지 확인하세요. 보통 원본 구독 URL을 볼 수 있어 바로 복사할 수 있습니다.

플랫폼별로 바로 대체할 수 있는 활성 클라이언트

마이그레이션할 때 "기능이 가장 많은" 클라이언트를 고를 필요는 없습니다. 기존 클라이언트의 조작 방식과 비슷하고 코어가 계속 업데이트되는 클라이언트를 고르면 됩니다. 아래는 플랫폼별로 바로 대체 가능한 선택지입니다.

Windows: Clash Verge Rev 또는 Clash Plus

Clash Verge Rev는 커뮤니티 활동이 활발한 대체품으로, 화면 구성이 Clash for Windows와 상당히 비슷해 규칙 편집이나 정책 그룹 전환의 조작 경로가 거의 동일하며 적응 부담이 적습니다. mihomo 코어를 기반으로 해서 규칙 문법과 새 기능도 함께 따라옵니다. Clash Plus는 더 완성된 그래픽 설정 안내를 제공해, YAML을 직접 작성하고 싶지 않은 사용자에게 적합합니다. 둘 다 TUN 모드와 구독 자동 업데이트를 지원하므로 마이그레이션 후 구독 링크만 다시 등록하면 됩니다.

macOS: ClashX Meta 또는 Clash Verge Rev

ClashX Pro의 유지보수가 종료된 뒤, ClashX Meta는 조작 습관이 가장 비슷한 선택으로, 마찬가지로 메뉴바 아이콘 방식을 사용하며 코어는 지속적으로 업데이트되는 mihomo로 교체되었습니다. 메뉴바 아이콘 방식보다 창 형태 인터페이스를 선호한다면 Clash Verge Rev의 macOS 버전도 사용할 수 있으며, Apple 칩과 Intel 칩용 설치 파일이 나뉘어 있으므로 다운로드할 때 구분에 주의하세요.

Android: FlClash 또는 Clash for Android

Android용 원조 Clash for Android 프로젝트는 업데이트 빈도가 낮지만 여전히 관리되고 있으며, 설정 가져오기 방식은 옛 클라이언트와 동일합니다. FlClash는 업데이트가 더 활발한 선택으로, 인터페이스가 현대적으로 개선되었고 Android와 데스크톱 플랫폼을 동시에 지원합니다. 여러 플랫폼을 자주 오가며 사용한다면 FlClash로 통일하면 학습 부담을 줄일 수 있습니다.

Linux: Clash Verge Rev

Linux 데스크톱 환경에서는 Clash Verge Rev가 deb와 rpm 두 가지 설치 파일을 제공해 주요 배포판의 패키지 관리 방식을 대부분 지원하며, 설정 가져오기 방식이 Windows 버전과 동일해 마이그레이션 경험이 가장 순조롭습니다.

기존 클라이언트	추천 대체 클라이언트	마이그레이션 요점
Clash for Windows	Clash Verge Rev / Clash Plus	기존 구독 링크를 바로 가져오기, 규칙 문법 거의 호환
ClashX / ClashX Pro	ClashX Meta	메뉴바 조작 습관 동일, 코어만 교체
구버전 Clash for Android	FlClash	인터페이스 변화가 큰 편이라 설정 항목을 처음부터 다시 확인 권장

마이그레이션 절차: 가져오기부터 검증까지

새 클라이언트 설치.다운로드 페이지에서 해당 플랫폼의 설치 파일을 선택하고, 설치가 끝나도 기존 클라이언트를 바로 삭제하지 말고 비교 대상으로 남겨두세요.
구독 또는 로컬 설정 가져오기.새 클라이언트에서 "구독 관리" 또는 "Profile" 항목을 찾아 구독 링크를 붙여넣고 업데이트하세요. 구독 링크가 없다면 로컬 YAML 파일을 가져오기로 선택하세요.
프록시 그룹과 규칙 수 확인.가져오기가 끝나면 새 클라이언트와 기존 클라이언트의 정책 그룹 수와 규칙 항목 수가 일치하는지 비교하세요. 차이가 크다면 일부 규칙이 파싱 과정에서 건너뛰어진 것이므로 로그 패널을 열어 구체적인 오류를 확인해야 합니다.
주요 사이트를 하나씩 테스트.모든 규칙을 테스트할 필요는 없습니다. 자주 쓰는 도메인 규칙 몇 개를 골라 각각 노드 선택으로 가는지 다이렉트로 가는지 확인해, 정책 분기 결과가 기존 클라이언트와 일치하는지 확인하세요.
문제가 없음을 확인한 뒤 기존 클라이언트 제거.며칠간 안정적으로 작동하는 것을 확인한 뒤 삭제하세요. 새 클라이언트에서 발견되지 않은 문제가 생겼을 때 대체 수단이 없는 상황을 피할 수 있습니다.

마이그레이션 후 재확인해야 할 설정 항목

설정 파일은 바로 가져올 수 있지만, 클라이언트 차원의 시스템 설정은 보통 자동으로 이어지지 않습니다. 다음 항목들은 놓치기 쉬우므로 하나씩 확인하는 것을 권장합니다.

시스템 프록시와 TUN 모드 스위치.새 클라이언트는 기본적으로 꺼져 있을 수 있으니 다시 수동으로 켜야 하며, 그렇지 않으면 트래픽이 프록시를 거치지 않습니다.
로컬 네트워크 연결과 포트 설정.이전에 로컬 네트워크의 다른 기기와 프록시를 공유하도록 설정했다면, 새 클라이언트에서도 포트 번호와 리스닝 주소를 동일하게 다시 입력해야 합니다. 그렇지 않으면 다른 기기의 연결이 실패합니다.
부팅 시 자동 실행.기존 클라이언트의 자동 실행 설정은 새 클라이언트로 이어지지 않으므로, 시스템 설정이나 클라이언트 설정에서 따로 체크해야 합니다.
DNS 설정.기존 설정에서 사용자 지정 DNS 서버나 fake-ip 모드를 사용했다면, 마이그레이션 후 새 클라이언트의 DNS 모듈 스위치 상태가 이전과 일치하는지 확인해야 합니다. DNS 설정 불일치는 마이그레이션 후 "노드는 연결되지만 웹페이지가 열리지 않는" 가장 흔한 원인입니다.
구독 자동 업데이트 주기.클라이언트마다 기본 구독 새로고침 간격이 다르므로, 기존에 익숙했던 업데이트 빈도로 수동 설정하는 것을 권장합니다. 노드 목록이 오랫동안 갱신되지 않아 만료된 노드가 쌓이는 것을 방지할 수 있습니다.

권장 사항

마이그레이션을 한 번에 완벽하게 끝내려고 하지 않아도 됩니다. 먼저 새 클라이언트에서 가장 자주 쓰는 몇 가지 시나리오를 정상적으로 돌려보고, 안정적임을 확인한 뒤 더 복잡한 사용자 지정 규칙을 차근차근 옮기는 편이 모든 설정을 한 번에 억지로 옮기는 것보다 오류가 적습니다.