클라이언트 선택 예상 읽기 시간 13분

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

계속 사용할 수 있는 클라이언트를 정리하고 구독, 오버라이드 규칙, 시스템 프록시 설정을 이전하는 방법과 전환 전후 점검 항목을 안내합니다.

지원 종료의 영향과 마이그레이션 범위

Clash for Windows 지원이 종료되어도 이미 설치된 클라이언트가 즉시 작동하지 않게 되는 것은 아닙니다. 로컬 설정, 이미 다운로드한 구독과 프록시 규칙은 계속 작동할 수 있지만 운영체제 변경에 맞춘 업데이트가 중단되고, 새로운 mihomo 커널 필드와 TUN 구현, 보안 수정도 반영되지 않습니다. 구버전을 계속 사용할 때 흔한 문제는 “노드가 갑자기 모두 작동하지 않는 것”보다 구독 형식이 바뀐 뒤 내용을 완전히 읽지 못하거나, 시스템 프록시 상태가 제대로 복원되지 않거나, TUN 서비스가 최신 운영체제와 충돌하거나, 새 규칙 필드를 구형 커널이 무시하는 경우입니다.

마이그레이션할 때는 데이터를 세 가지로 나눠야 합니다. 첫째는 구독 진입 정보로 구독 주소, 원격 설정 업데이트 시간, 설정 이름이 포함됩니다. 둘째는 사용자 수정 사항으로 사용자 지정 규칙, 오버라이드 필드, 스크립트 처리, 정책 그룹 선택입니다. 셋째는 기기 트래픽 가로채기 상태로 시스템 프록시, 시작 시 실행, LAN 접근, TUN 서비스, DNS 설정이 해당합니다. YAML 파일 하나만 복사해서는 일반적으로 이 세 가지 데이터를 모두 옮길 수 없습니다.

일상적인 설정이 전적으로 구독에서 제공된다면, 마이그레이션의 핵심은 구독을 다시 가져오고 새 클라이언트에서 정책 그룹 선택을 복원하는 것입니다. Clash for Windows에서 Mixin, Parsers, Script를 사용했거나 설정을 직접 편집했다면 이러한 변경 사항을 별도로 기록해야 합니다. 그래픽 클라이언트마다 오버라이드 기능의 이름과 형식이 다르므로, 기존 클라이언트의 JavaScript 파서는 범용 설정으로 간주해 그대로 사용할 수 없습니다.

마이그레이션 전 구독과 로컬 변경 사항 백업

구독 진입 정보 기록

Clash for Windows의 Profiles 페이지를 열고 현재 사용하는 것이 원격 구독인지 로컬 설정인지 확인합니다. 원격 구독은 클라이언트 캐시에서 생성된 YAML만 보관하지 말고 원본 구독 주소를 저장해야 합니다. 원본 주소가 있으면 새 클라이언트에서 최신 노드, 정책 그룹, 규칙을 다시 가져올 수 있습니다. 캐시 파일은 특정 시점의 내용만 반영하며, 이후 원격 규칙 세트 경로가 바뀌면 로드에 실패할 수도 있습니다.

구독 주소에는 계정 식별에 사용되는 매개변수가 포함되는 경우가 많으므로 비밀번호와 같은 수준으로 관리해야 합니다. 주소를 공개 스크린샷, 문의 글, 공개 코드 저장소에 남기지 마세요. 서비스 제공자가 구독 링크 재설정을 지원하고 주소가 이미 노출되었다면, 먼저 링크를 재설정한 뒤 새 주소를 새 클라이언트에 가져오세요.

로컬 설정 내보내기

직접 관리하는 YAML은 클라이언트에서 설정이 저장된 디렉터리를 열고, 현재 사용하는 기본 설정과 참조 파일을 별도 디렉터리에 복사할 수 있습니다. 함께 확인해야 할 파일에는 프록시 제공자, 규칙 제공자, 로컬 규칙 세트, 인증서 관련 파일이 포함됩니다. 기본 설정의 상대 경로는 기존 디렉터리 구조에 의존하므로 파일을 옮긴 뒤에도 계층을 유지하거나 새 클라이언트에서 경로를 다시 지정해야 합니다.

설정에서 별도로 기록할 가치가 높은 필드는 다음과 같습니다.

  • mode: 현재 사용하는 규칙 모드, 글로벌 모드 또는 직접 연결 모드입니다.
  • proxies 및 proxy-providers: 수동 노드와 원격 노드 제공자입니다.
  • proxy-groups: 정책 그룹 이름, 유형, 참조 관계, 상태 확인 주소입니다.
  • rules 및 rule-providers: 사용자 지정 규칙 순서와 외부 규칙 세트입니다.
  • dns: DNS 활성화 여부, 작동 모드, 업스트림 서버, 제외 범위입니다.
  • tun: 가상 네트워크 인터페이스, 자동 라우팅, DNS 하이재킹, 인터페이스 선택입니다.

구독에서 설정을 가져오는 경우 구독이 생성한 YAML을 장기간 직접 수정하는 것은 권장하지 않습니다. 다음 업데이트에서 변경 내용이 덮어써질 수 있습니다. 새 클라이언트로 옮긴 뒤에는 클라이언트가 제공하는 오버라이드, 확장 스크립트 또는 설정 병합 기능으로 사용자 변경 사항을 저장하고, 구독이 업데이트될 때마다 해당 기능이 다시 실행되는지 확인해야 합니다.

마이그레이션 기록 작성

기존 클라이언트를 종료하기 전에 현재 선택한 정책 그룹 노드, 시스템 프록시 포트, LAN 연결 허용 여부, TUN 활성화 여부, 프록시에 의존하는 애플리케이션을 기록합니다. 정책 그룹 선택은 대개 클라이언트 자체 데이터베이스나 캐시에 저장되며 구독 YAML에 기록되지 않을 수 있습니다. 그룹 이름과 노드 이름이 완전히 같더라도 새 클라이언트에서 처음 로드할 때 그룹의 첫 번째 항목으로 돌아갈 수 있으므로 직접 다시 선택해야 합니다.

대체 클라이언트 선택 방법

대체 클라이언트를 고를 때는 인터페이스만 비교해서는 안 됩니다. 커널, 플랫폼 지원, 설정 호환성, 트래픽 가로채기 방식을 더 중요하게 봐야 합니다. 현재 지속적으로 업데이트되는 클라이언트는 대부분 mihomo를 핵심으로 사용합니다. mihomo는 Clash 설정 체계를 이어받으면서 규칙 세트, DNS, 트래픽 스니핑, TUN 등의 기능을 확장했습니다. 클라이언트는 설정 관리와 시스템 통합을 담당하고, 커널은 설정을 해석하고 연결을 수립하며 규칙을 실행합니다.

클라이언트 유형 사용 환경 마이그레이션 시 핵심 사항
Clash Verge Rev Windows, macOS, Linux 데스크톱 기기 구독 관리, 시스템 프록시, mihomo TUN에 적합합니다. 기존 Mixin은 새 클라이언트가 지원하는 오버라이드 방식으로 다시 작성해야 합니다.
Mihomo Party 데스크톱 그래픽 인터페이스와 설정 관리가 필요한 기기 먼저 설치 패키지의 아키텍처를 확인한 뒤, 해당 클라이언트의 설정 확장 방식에 맞춰 로컬 변경 사항을 옮깁니다.
Clash Nyanpasu 멀티플랫폼 데스크톱 클라이언트가 필요한 사용자 현재 버전에서 사용하는 커널, 구독 업데이트 방식, TUN 권한 안내를 확인합니다.
FlClash 데스크톱 및 일부 모바일 기기 환경 비슷한 사용 흐름을 유지하고 싶은 사용자에게 적합합니다. 가져온 뒤에도 규칙 모드와 DNS를 다시 확인해야 합니다.
명령줄 mihomo 서버, 라우터 또는 직접 관리하는 서비스 환경 설정 경로, 시작 매개변수, 로그, 업데이트, 시스템 서비스를 직접 관리해야 합니다.

Windows 사용자는 설치 패키지가 x64, ARM64 등 기기 아키텍처에 맞는지 확인해야 합니다. macOS에서는 Apple 실리콘과 Intel 프로세서를 구분해야 합니다. Linux 사용자는 아키텍처뿐 아니라 데스크톱 환경, 패키지 형식, 시스템 서비스 권한도 확인해야 합니다. 클라이언트가 실행되는 것은 첫 단계일 뿐이며, 시스템 프록시 스위치와 TUN 드라이버 또는 서비스가 제대로 설치되는지가 트래픽을 안정적으로 가로챌 수 있는지를 결정합니다.

기존 설정에 mihomo 전용 필드가 포함되어 있다면 mihomo 커널을 명시적으로 사용하고 지속적으로 업데이트되는 클라이언트를 선택해야 합니다. 설정이 기본 포트, 일반 노드, 정책 그룹, 규칙만 포함한다면 Clash 설정을 지원하는 대부분의 클라이언트에서 읽을 수 있습니다. 반면 그래픽 클라이언트의 오버라이드 데이터베이스, 인터페이스 환경설정, 단축 설정은 YAML 표준에 속하지 않으므로 대개 클라이언트 간에 그대로 복사할 수 없습니다.

Clash for Windows에서 새 클라이언트로 이전하기

1단계: 기존 클라이언트의 트래픽 가로채기 해제

  1. Clash for Windows에서 System Proxy를 끕니다.
  2. TUN Mode가 켜져 있다면 먼저 TUN을 끄고 네트워크 인터페이스가 복구될 때까지 기다립니다.
  3. 클라이언트를 종료하고 백그라운드 프로세스가 완전히 끝났는지 확인합니다.
  4. 운영체제의 프록시 설정을 확인하고 기존 포트를 가리키는 수동 프록시가 남아 있지 않은지 확인합니다.

이 단계는 포트 충돌과 중복 라우팅을 방지하기 위한 것입니다. 두 클라이언트에서 시스템 프록시를 동시에 활성화하면 일반적으로 시스템 설정에 마지막으로 기록된 쪽이 진입점이 되지만, 다른 클라이언트가 포트를 계속 점유할 수 있습니다. 두 TUN을 동시에 실행하면 기본 경로 경쟁, DNS 조회 우회 또는 LAN 접근 이상이 발생할 수 있습니다.

2단계: 새 클라이언트 설치 및 최초 실행

클라이언트 프로젝트가 제공하는 배포 경로에서 운영체제와 프로세서 아키텍처에 맞는 설치 패키지를 받습니다. 처음 실행한 뒤에는 시스템 프록시나 TUN을 바로 켜지 말고, 먼저 커널 상태와 설정 디렉터리가 정상인지 확인합니다. 일부 클라이언트는 mihomo 커널을 별도로 업데이트합니다. 인터페이스에 커널이 준비되지 않았다고 표시되면 클라이언트 안내에 따라 코어 설치를 완료하거나 커널을 전환해야 합니다.

3단계: 구독 다시 가져오기

새 클라이언트의 구독 또는 설정 입력란에 원본 구독 주소를 붙여 넣고 다운로드한 뒤 현재 설정으로 지정합니다. 로드가 완료되면 노드 수, 정책 그룹 이름, 규칙 수가 기존 클라이언트와 대략 일치하는지 확인합니다. 마이그레이션 중 구독 서비스가 내용을 업데이트할 수 있으므로 수치가 완전히 같을 필요는 없지만, 설정이 비어 있거나 노드가 몇 개만 표시되거나 정책 그룹이 모두 사라져서는 안 됩니다.

구독에서 “형식 오류”가 반환되면 먼저 복사한 주소에 불필요한 공백이나 줄바꿈이 없는지 확인한 뒤, 브라우저나 서비스 제공자 콘솔에서 링크를 다시 발급받아 보세요. 구독 내용이 구버전 Clash 형식으로 생성되고 새 클라이언트가 mihomo를 사용하더라도 기본 필드는 대체로 읽을 수 있습니다. 실제로 자주 문제가 되는 부분은 잘못된 들여쓰기, 접근할 수 없는 참조 파일, 존재하지 않는 노드를 참조하는 정책 그룹, 또는 구독 응답이 실제로 로그인 페이지인 경우입니다.

4단계: 사용자 지정 규칙과 오버라이드 이전

기존 설정의 개인 규칙을 원래 순서대로 새 클라이언트가 지원하는 오버라이드 위치에 추가합니다. Clash 규칙은 위에서 아래로 매칭되며, 처음 일치한 규칙이 트래픽의 경로를 결정하므로 규칙 수보다 순서가 중요합니다. LAN 직접 연결, 특정 도메인 프록시, 애플리케이션 프로세스 규칙, 최종 기본 규칙의 순서를 임의로 바꾸면 안 됩니다.

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,example.net,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

위 예시는 순서 구조만 보여 줍니다. 실제로 사용할 때는 Proxy가 설정의 정책 그룹 이름과 완전히 일치해야 합니다. 그룹 이름에 공백이나 한글이 포함된 경우에도 한 글자씩 정확히 맞춰야 합니다. 구독이 업데이트될 때마다 정책 그룹을 다시 생성한다면 사용자 지정 규칙이 안정적으로 존재하는 그룹 이름을 가리키도록 설정해 업데이트 후 “정책 그룹을 찾을 수 없음” 오류를 피하세요.

Clash for Windows의 Parsers는 JavaScript를 사용해 구독 결과를 수정할 수 있지만, 이러한 로직을 모든 새 클라이언트에 그대로 붙여 넣을 수는 없습니다. 먼저 스크립트가 어떤 필드를 수정하는지 파악한 뒤 대상 클라이언트가 지원하는 오버라이드, 설정 병합 또는 확장 스크립트로 다시 작성해야 합니다. 실행 단계가 어떻게 되는지 모르는 상태에서 여러 오버라이드를 동시에 활성화하지 마세요. 포트가 중복 수정되거나 DNS 필드가 나중에 실행된 설정으로 덮어써질 수 있습니다.

5단계: 정책 선택 및 업데이트 주기 복원

정책 그룹을 하나씩 열어 자주 사용하는 노드나 자동 선택 방식을 복원합니다. url-test, fallback 같은 자동 그룹은 상태 확인이 실행되는지 확인하고, select 수동 그룹은 현재 선택 항목이 작동하지 않는 노드가 아닌지 확인합니다. 그런 다음 구독 업데이트 간격을 설정하고 한 번 수동 업데이트하여 오버라이드 내용이 계속 유지되는지 확인합니다.

시스템 프록시와 TUN 설정 복원 방법

구독 로드가 완료되었다고 해서 기기의 트래픽이 이미 Clash로 들어온 것은 아닙니다. 새 클라이언트에서 트래픽 진입점을 별도로 만들어야 합니다. 시스템 프록시와 TUN은 서로 다른 가로채기 방식이므로 먼저 시스템 프록시로 검증한 뒤, 애플리케이션 호환성에 따라 TUN을 켜야 합니다.

먼저 시스템 프록시 테스트

새 클라이언트의 시스템 프록시를 켜면 운영체제가 시스템 프록시 설정을 지원하는 HTTP 또는 SOCKS 트래픽을 로컬 수신 포트로 보냅니다. 브라우저와 대부분의 데스크톱 애플리케이션은 일반적으로 이 방식을 바로 사용할 수 있습니다. 클라이언트의 연결 기록을 열고 테스트 사이트에 접속해 로그에 도메인, 매칭된 규칙, 최종 정책 그룹이 표시되는지 확인합니다.

활성화 후 인터넷에 전혀 연결되지 않으면 새 클라이언트의 수신 포트를 다른 프로그램이 사용 중인지, 시스템 프록시가 올바른 로컬 주소에 기록되었는지, 설정이 Rule 모드인지 확인합니다. 클라이언트를 종료한 뒤에도 인터넷이 되지 않는다면 운영체제 네트워크 설정에서 남아 있는 수동 프록시를 삭제해야 합니다.

그다음 TUN 구성

게임, 명령줄 도구, 일부 스토어 애플리케이션, 시스템 프록시를 읽지 않는 소프트웨어는 TUN 가로채기가 필요할 수 있습니다. TUN은 가상 네트워크 인터페이스를 만들고 라우팅 조건에 맞는 IP 트래픽을 mihomo로 전달합니다. 처음 활성화할 때는 일반적으로 관리자 권한이 필요하며, 시스템 서비스나 가상 네트워크 인터페이스 구성 요소를 설치할 수도 있습니다.

TUN을 이전할 때 기존 클라이언트의 스위치 상태를 그대로 따라 하지 마세요. 먼저 새 클라이언트가 권장하는 기본 설정을 사용하고 가상 인터페이스가 정상적으로 생성되는지 확인한 다음 auto-route, strict-route, DNS 하이재킹, 인터페이스 자동 인식을 점검합니다. 운영체제마다 이러한 필드의 구현이 다르며 새 클라이언트가 인터페이스를 통해 해당 설정을 생성할 수도 있습니다.

TUN을 켠 뒤 LAN 프린터, NAS 또는 라우터 관리 페이지에 접근할 수 없다면 먼저 사설 네트워크 대역이 직접 연결로 유지되는지 확인하고, 엄격한 라우팅이 로컬 접근 경로를 바꾸었는지 살펴보세요. 도메인으로만 접근이 안 되고 직접 IP로는 정상이라면 노드를 계속 바꾸기보다 DNS 모드, Fake-IP 제외 목록, 업스트림 DNS 접근성을 중점적으로 확인해야 합니다.

마이그레이션 후 점검 목록

구독 가져오기와 트래픽 가로채기 설정을 완료한 뒤 다음 순서로 점검합니다. 한 항목을 완료한 후 다음 항목으로 넘어가면 문제가 설정, 규칙, 시스템 진입점 중 어디에 있는지 빠르게 판단할 수 있습니다.

  1. 커널 상태: 클라이언트에 mihomo가 정상 실행 중으로 표시되고 지속적인 재시작이나 설정 해석 오류가 없습니다.
  2. 구독 업데이트: 수동 업데이트가 완료되고 업데이트 시간이 변경되며 노드와 정책 그룹이 정상적으로 표시됩니다.
  3. 설정 모드: 현재 필요한 Rule, Global 또는 Direct 모드인지 확인하고, 마이그레이션 후 인터페이스의 초기값을 기본으로 사용하지 않습니다.
  4. 정책 그룹: 수동 그룹의 선택이 복원되고 자동 그룹에서 지연 시간 테스트가 완료되며 규칙이 참조하는 그룹 이름이 모두 존재합니다.
  5. 시스템 프록시: 브라우저 접속 기록이 생성되고 시스템 프록시를 끈 뒤 네트워크 설정이 정상적으로 복원됩니다.
  6. DNS: 도메인 확인이 안정적이고 로그에 연속적인 시간 초과가 없습니다. LAN 도메인과 특수 도메인도 예상대로 처리됩니다.
  7. TUN: 꼭 필요한 경우에만 켜고 시스템 프록시를 읽지 않는 애플리케이션이 연결 기록에 나타나는지 확인합니다.
  8. LAN: 라우터, NAS, 프린터, 공유 서비스에 계속 접근할 수 있고 사설 주소가 잘못 프록시로 전달되지 않습니다.
  9. 시작 시 실행: 시작 항목에는 새 클라이언트만 남겨 두고 시스템 프록시 또는 TUN이 예상대로 복원되는지 확인합니다.
  10. 기존 클라이언트 처리: 일정 기간 안정적으로 사용한 뒤 기존 클라이언트를 제거하고, 제거 전에 백업 디렉터리가 애플리케이션 데이터 정리 범위에 포함되지 않는지 확인합니다.

일반적인 마이그레이션 장애 진단

구독을 가져왔지만 노드가 없음

먼저 구독 응답이 유효한 설정인지 확인합니다. 일부 주소는 서비스 제공자 콘솔에서 다시 생성해야 하며, 만료된 링크는 YAML 대신 안내 문구를 반환할 수 있습니다. 클라이언트에서 잘못된 구독 변환 템플릿을 사용하고 있지 않은지, 설정 파일의 노드 제공자 주소에 접근할 수 있는지도 확인해야 합니다.

설정은 로드되지만 모든 규칙이 기본 규칙으로 처리됨

사용자 지정 규칙이 MATCH 뒤에 배치되지 않았는지 확인합니다. MATCH는 최종 규칙이므로 뒤에 있는 항목은 실행되지 않습니다. 원격 규칙 제공자를 사용한다면 rule-providers 다운로드가 성공했는지, 규칙의 RULE-SET 이름이 제공자 이름과 일치하는지도 확인해야 합니다.

시스템 프록시를 켜도 일부 애플리케이션에서 적용되지 않음

이는 대개 구독 가져오기가 실패한 것이 아니라 애플리케이션이 운영체제 프록시를 읽지 않는다는 뜻입니다. 먼저 클라이언트 로그에서 브라우저 트래픽이 정상인지 확인한 뒤 대상 애플리케이션 자체에 프록시를 설정하거나, 권한과 라우팅 설정을 확인한 후 TUN을 사용하세요. 애플리케이션 하나에 기록이 없다는 이유만으로 전체 DNS 설정을 바로 변경하지 마세요.

TUN을 켠 뒤 인터넷 연결이 끊김

먼저 TUN을 끄고 시스템 프록시 모드가 계속 작동하는지 확인합니다. 그런 다음 가상 네트워크 인터페이스 서비스 권한, 기본 인터페이스 인식, 라우팅 충돌, DNS 업스트림을 점검합니다. 기기에서 실행 중인 다른 네트워크 필터, 가상 머신 네트워크, 기업용 VPN도 라우팅을 바꿀 수 있습니다. 문제를 찾을 때는 한 번에 하나의 가로채기 도구만 활성화하여 여러 변수가 동시에 바뀌지 않게 하세요.

구독 업데이트 후 사용자 지정 규칙이 사라짐

규칙이 구독 캐시 파일에 직접 기록되어 업데이트 때 원격 내용으로 덮어써졌다는 뜻입니다. 규칙을 새 클라이언트가 제공하는 영구 오버라이드 위치로 옮기고, 구독 해석 이후에 오버라이드가 실행되는지 확인해야 합니다. 마이그레이션을 마친 뒤 최소 두 번 수동 업데이트하여 규칙, DNS, 정책 그룹 변경 사항이 계속 유지되는지 검증하세요.

Clash 다운로드