Clash for Windows 지원 종료 후 마이그레이션: 대체 클라이언트와 설정 호환성 가이드

지속적으로 관리되는 클라이언트를 먼저 선택한 뒤 구독과 규칙을 옮기세요

Clash for Windows의 유지보수가 중단된 뒤에는 장기적인 주력 클라이언트로 계속 사용하는 것을 권장하지 않습니다. 마이그레이션의 핵심은 화면이 완전히 같은 프로그램을 찾는 것이 아니라, 새 클라이언트가 사용하는 코어와 지원하는 설정 필드, 시스템 프록시 구현 방식 및 TUN 기능이 현재 요구 사항에 맞는지 확인하는 데 있습니다. Windows, macOS, Linux 데스크톱 환경에서는 mihomo 코어를 사용하면서 계속 유지보수되는 그래픽 클라이언트를 우선 검토하세요. 경량 배포나 원격 관리가 필요하다면 mihomo 명령줄 코어에 관리 패널을 조합해 사용할 수 있습니다. Android와 iOS는 각 플랫폼에서 지원하는 클라이언트에 구독을 새로 가져와야 하며, 데스크톱 프로그램 디렉터리를 그대로 복사해서는 안 됩니다.

대부분의 표준 구독은 새 클라이언트에서 다시 추가할 수 있으므로 기존 클라이언트의 실행 디렉터리 전체를 옮길 필요가 없습니다. 별도로 처리해야 하는 항목은 로컬 YAML 설정, 규칙 세트, 정책 그룹 선택, 오버라이드, 스크립트, 구독 업데이트 주소 및 LAN 공유 매개변수입니다. Clash for Windows의 화면 설정, JavaScript Parser, 특정 버전의 Profiles 데이터 구조와 시스템 프록시 상태는 범용 Clash 설정과 같지 않습니다. 그대로 복사하면 설정을 불러오지 못하거나 규칙 순서가 바뀌고 DNS 동작이 달라질 수 있습니다.

운영체제, 코어 및 유지보수 상태에 따라 대체 클라이언트 선택하기

대체 클라이언트는 이름이 비슷해도 같은 프로젝트의 연속 버전이 아닙니다. 선택할 때는 ‘그래픽 인터페이스’와 ‘프록시 코어’를 나누어 판단해야 합니다. 인터페이스는 설정 관리, 구독 업데이트, 시스템 프록시 전환 및 로그 표시를 담당하고, 코어는 프로토콜 연결, 규칙 매칭, DNS, TUN 및 트래픽 전달을 담당합니다. mihomo 코어를 사용하는 클라이언트는 일반적으로 최신 설정 필드를 더 많이 인식하지만, 실제 지원 범위는 클라이언트 버전, 코어 버전 및 운영체제 권한의 영향을 받습니다.

기존에 ‘규칙 모드, 구독 업데이트, 시스템 프록시’ 세 기능만 사용했다면, 주요 mihomo 데스크톱 클라이언트로의 마이그레이션은 대체로 간단합니다. 기존 환경에서 TUN, 스크립트 오버라이드, 복잡한 DNS, LAN 공유 또는 여러 프록시 프로바이더를 사용했다면 먼저 대상 클라이언트의 설정 문서를 읽고 소규모로 테스트하세요. 화면 캡처만 보고 호환성을 판단해서는 안 됩니다. 같은 클라이언트도 버전에 따라 코어를 바꾸거나 설정 저장 방식을 조정할 수 있습니다.

Windows 사용자는 서비스 모드를 우선 확인하세요

Windows의 일반 시스템 프록시는 시스템 프록시 설정을 따르는 앱에 주로 영향을 줍니다. 게임, 명령줄 프로그램, 일부 스토어 앱 및 자체 네트워크 스택을 사용하는 소프트웨어는 이 경로를 거치지 않을 수 있습니다. 더 많은 트래픽을 제어하려면 보통 TUN을 사용해야 합니다. TUN은 가상 네트워크 어댑터, 관리자 권한, 라우팅 테이블 및 DNS 제어와 관련되므로, 마이그레이션 후에는 먼저 일반 시스템 프록시를 확인하고 TUN은 별도로 활성화하세요. 여러 변수를 동시에 점검하는 상황을 피할 수 있습니다.

macOS와 Linux 사용자는 권한 및 데스크톱 환경을 확인하세요

macOS에서는 시스템 확장, 네트워크 권한 및 백그라운드 항목 설정이 TUN과 시작 시 실행에 영향을 줍니다. Linux에서는 데스크톱 환경의 프록시 설정, NetworkManager, systemd 서비스 및 커널 네트워크 권한을 고려해야 합니다. 클라이언트가 특정 플랫폼을 지원한다는 것은 실행할 수 있다는 뜻일 뿐, 모든 데스크톱 환경에서 시스템 프록시를 자동으로 설정한다는 의미는 아닙니다. 서버나 GUI가 없는 환경에서는 일반적으로 mihomo 코어와 설정 파일을 조합하는 편이 데스크톱 클라이언트보다 적합합니다.

구독을 가져올 수 있다고 해서 기존 설정을 그대로 복사할 수 있는 것은 아닙니다

Clash 설정은 보통 YAML을 사용하지만, ‘모두 YAML’이라고 해서 필드가 완전히 호환되는 것은 아닙니다. 표준 프록시 노드, 프록시 그룹 및 규칙은 높은 수준으로 옮길 수 있지만, 특정 코어·그래픽 클라이언트·운영체제에 결합된 부분은 다시 확인해야 합니다. 마이그레이션할 때는 내용을 구독 데이터, 코어 설정, 클라이언트 오버라이드 및 시스템 상태의 네 계층으로 나누어 보세요.

1. 구독 데이터: 구독 주소, 노드, 정책 그룹 및 원격 규칙 프로바이더를 포함합니다. 가장 안전한 방법은 새 클라이언트에 구독 주소를 다시 추가해 대상 클라이언트가 직접 다운로드하고 파싱하도록 하는 것입니다.
2. 코어 설정: 포트, 실행 모드, DNS, TUN, 규칙, 프록시 그룹, 외부 컨트롤러 및 LAN 수신을 포함합니다. 대상 코어의 문서에 따라 필드를 확인해야 합니다.
3. 클라이언트 오버라이드: 구독 병합, 전역 확장, 설정 전처리, 스크립트 및 인터페이스에 저장된 추가 항목을 포함합니다. 이 계층은 클라이언트 간에 그대로 재사용할 수 없는 경우가 많습니다.
4. 시스템 상태: 시스템 프록시, 가상 네트워크 어댑터, 서비스, 시작 항목, 방화벽 허용 및 로컬 포트 사용 상태를 포함합니다. 설정 파일을 복사해도 이러한 상태가 자동으로 이전되지는 않습니다.

대체로 유지할 수 있는 설정 항목

일반적인 proxies, proxy-groups, rules, proxy-providers 및 rule-providers는 마이그레이션의 기반으로 사용할 수 있습니다. DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, IP-CIDR, GEOIP 및 MATCH 같은 규칙 유형을 사용할 때는 위에서 아래로 매칭되는 순서를 유지해야 합니다. 처음 일치한 규칙이 트래픽의 경로를 결정합니다. 마이그레이션 중 클라이언트가 규칙이나 오버라이드 목록에 규칙을 자동으로 삽입하면 기존 환경과 결과가 달라질 수 있습니다.

다시 확인해야 하는 설정 항목

• tun 아래의 네트워크 스택, 자동 라우팅, 인터페이스 감지 및 DNS 하이재킹 옵션입니다.
• dns 아래의 enhanced-mode, Fake IP 범위, 대체 리졸버 및 도메인 필터 목록입니다.
• external-controller, 컨트롤러 수신 주소 및 접근 키입니다.
• allow-lan, bind-address 및 로컬 방화벽 규칙입니다.
• 기존 클라이언트에서만 해석되는 Parser, JavaScript 스크립트, 단축 명령 및 인터페이스 오버라이드입니다.
• 특정 코어에만 존재하는 프로토콜 매개변수, 규칙 유형 및 스니핑 설정입니다.

다음은 마이그레이션 검증에 사용할 수 있는 간소화된 구조입니다. 핵심은 새 코어가 포트, 모드, DNS 및 규칙을 불러오는지 확인하는 것입니다. 예시에는 실제 노드가 포함되어 있지 않습니다. 실제 사용에서는 구독에서 노드와 정책 그룹을 가져오고, 민감한 연결 정보를 공개 문서에 작성하지 마세요.

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

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

이 설정의 PROXY는 실제로 존재하는 프록시 그룹을 가리켜야 합니다. 그렇지 않으면 코어가 정책 대상이 존재하지 않는다고 보고합니다. DNS 주소 역시 구조를 보여 주기 위한 예시일 뿐이므로 네트워크 환경, 개인정보 보호 요구 및 구독 안내에 따라 선택하세요. 마이그레이션 전에 redir-host를 사용하다가 fake-ip으로 전환하면 LAN 도메인, 특정 앱 및 연결 테스트 도구의 동작이 달라질 수 있습니다. 따라서 처음 가져올 때 DNS 모드까지 함께 변경하지 마세요.

실행 상태 전체가 아니라 설정의 출처를 백업하세요

마이그레이션을 시작하기 전에 기존 클라이언트에서 현재 정상적으로 작동하는 기준 상태를 기록하세요. 백업의 목적은 ‘기존에 어떻게 연결했는지’를 설명할 수 있게 하는 것이지, 두 클라이언트가 같은 데이터 디렉터리를 공유하게 하는 것이 아닙니다. 클라이언트마다 설정 인덱스, 캐시 및 정책 선택 기록을 동시에 저장할 수 있으므로 디렉터리를 공유하면 파일 형식 충돌이 발생하기 쉽습니다.

보관을 권장하는 항목

• 유효한 구독 주소와 용도. 주 구독, 테스트 구독 및 로컬 설정을 구분해 기록하세요.
• 직접 관리하는 YAML 파일, 규칙 파일, 프록시 프로바이더 및 규칙 프로바이더 주소입니다.
• 현재 사용하는 프록시 모드. 예: 규칙, 전역 또는 직접 연결입니다.
• 자주 사용하는 정책 그룹의 선택 결과. 예: 자동 선택, 장애 조치 또는 지정 노드입니다.
• 혼합 포트, HTTP 포트, SOCKS 포트 및 외부 제어 포트입니다.
• DNS 향상 모드, TUN 상태, LAN 접근 상태 및 수신 주소입니다.
• 보존해야 하는 Parser 또는 오버라이드 로직과 해당 로직이 어떤 필드를 수정하는지에 대한 설명입니다.

구독 주소와 로컬 설정에는 접근 자격 증명이 포함될 수 있으므로 공개 로그, 스크린샷 또는 온라인 포맷터에 붙여 넣지 마세요. 백업 파일은 현재 계정이 제어할 수 있는 위치에 보관해야 합니다. 운영체제를 재설치할 예정이라면 클라이언트 버전, 코어 버전 및 시스템 아키텍처도 기록하세요. 같은 설정이라도 코어 버전에 따라 동작이 달라질 수 있습니다.

기존 클라이언트를 종료하기 전에 포트 사용 상태를 기록하세요

Clash 계열 클라이언트는 7890과 같은 로컬 포트를 자주 사용하지만 실제 포트는 변경되어 있을 수 있습니다. 마이그레이션 후 새 클라이언트가 수신에 실패한다고 표시하면 기존 프로세스가 종료되지 않았거나, 다른 프록시 프로그램이 포트를 사용 중이거나, 시스템 서비스가 백그라운드에서 계속 실행 중일 가능성이 있습니다. 창을 닫는 것만으로 프로세스가 종료되지는 않습니다. 클라이언트 메뉴에서 정상적으로 종료한 뒤 작업 관리자나 시스템 프로세스 목록을 확인하세요.

최소 설정으로 연결을 만든 뒤 고급 기능을 하나씩 복원하세요

기존 설정을 한 번에 모두 가져오면 장애 원인을 찾기 어려워집니다. 더 안정적인 순서는 클라이언트와 코어의 시작을 먼저 확인한 다음 구독 파싱, 노드 연결, 규칙 매칭을 검증하고 마지막으로 TUN, DNS 오버라이드 및 LAN 공유를 처리하는 것입니다.

1. 시스템과 프로세서 아키텍처를 확인하세요.

   Windows에서는 x64, ARM64 등 아키텍처를 구분해야 하고, macOS에서는 Apple 칩과 Intel 모델을 구분해야 합니다. Linux에서는 배포판, 패키지 형식 및 데스크톱 환경도 확인해야 합니다. 설치 패키지의 아키텍처가 맞지 않으면 프로그램이 시작되지 않거나 시스템 서비스를 설치하지 못할 수 있습니다.

2. 대상 클라이언트를 설치하고 코어를 확인하세요.

   처음 실행한 뒤 클라이언트에 표시되는 코어 이름과 버전을 확인하세요. mihomo 설정 확장을 사용할 예정이라면 클라이언트 이름만 보고 판단하지 말고 실제로 mihomo가 실행 중인지 확인해야 합니다.

3. 기존 클라이언트를 완전히 종료하세요.

   기존 클라이언트의 시스템 프록시와 TUN을 끈 다음 백그라운드 프로세스를 종료하세요. 새 클라이언트와 기존 클라이언트가 동시에 시스템 프록시, 라우팅 및 DNS를 변경하지 않도록 해야 합니다.

4. 구독을 다시 추가하세요.

   기존 구독 주소를 새 클라이언트에 추가해 설정을 만드는 방식을 우선 사용하세요. 업데이트가 완료되면 노드와 정책 그룹이 생성되었는지, 설정 화면에 파싱 오류가 없는지 확인합니다. 구독 서비스가 특정 클라이언트 전용 형식만 제공한다면 Clash 또는 mihomo 형식도 제공하는지 먼저 확인하세요.

5. 먼저 규칙 모드와 시스템 프록시를 활성화하세요.

   사용 가능한 노드나 정책 그룹을 선택하고 TUN은 끈 상태에서 브라우저로 기본 연결을 테스트하세요. 이때 코어 로그를 확인해 도메인 해석, 규칙 매칭 및 프록시 핸드셰이크가 모두 정상인지 확인합니다.

6. 사용자 지정 규칙과 오버라이드를 복원하세요.

   한 번에 한 종류의 변경만 추가하세요. 예를 들어 규칙 프로바이더를 먼저 복원하고, 그다음 프록시 그룹 조정, 마지막으로 DNS를 처리합니다. 추가할 때마다 설정을 다시 불러오고 오류 위치를 확인하세요.

7. 필요한 경우 TUN을 활성화하세요.

   일반 시스템 프록시가 작동하는 것을 확인한 뒤 필요한 권한을 부여하고 TUN을 켜세요. 테스트가 끝나면 클라이언트 종료 시 라우팅, DNS 및 가상 네트워크 어댑터가 올바르게 복원되는지 확인합니다.

8. 마지막으로 시작 시 실행과 LAN 공유를 설정하세요.

   일상적인 연결이 안정된 뒤에만 자동 시작을 설정하세요. LAN 공유에는 적절한 주소 바인딩과 방화벽 규칙 설정이 필요하며, 신뢰할 수 있는 네트워크에서만 사용해야 합니다.

코어 시작, 규칙 매칭부터 시스템 복구까지 단계별로 확인하세요

‘브라우저에서 웹페이지가 열린다’는 것은 일부 연결 경로만 정상이라는 뜻입니다. 완전한 마이그레이션을 위해서는 구독 업데이트, 예상한 규칙 결과, 필요한 다른 앱의 프록시 연결 및 클라이언트 종료 후 시스템 네트워크 복구까지 확인해야 합니다.

첫 번째 단계: 코어가 설정을 수락하는가

먼저 시작 로그를 확인하세요. YAML 들여쓰기 오류, 중복 필드, 존재하지 않는 프록시 그룹 참조, 규칙 프로바이더 다운로드 실패 및 포트 충돌은 대개 이 단계에서 나타납니다. 설정 파싱에 실패했을 때 노드를 계속 바꾸지 말고 로그의 필드명과 줄 번호부터 확인하세요. 로컬 설정은 불러와지는데 구독 설정만 불러와지지 않는다면 구독 형식이나 오버라이드 과정에 문제가 있을 가능성이 큽니다.

두 번째 단계: 노드와 DNS가 작동하는가

연결 테스트에서는 지연 시간 테스트와 실제 요청을 함께 관찰해야 합니다. 지연 시간 테스트가 성공해도 모든 대상 사이트에 접속할 수 있다는 뜻은 아닙니다. 테스트 주소, DNS 결과, 규칙 경로 및 프로토콜 핸드셰이크가 다를 수 있기 때문입니다. 도메인에는 접속할 수 없지만 IP 연결은 정상이라면 먼저 DNS를 확인하세요. 모든 노드에서 동시에 시간 초과가 발생한다면 로컬 네트워크, 방화벽, 구독 유효성 및 시스템 시간을 점검하세요.

세 번째 단계: 규칙이 예상대로 매칭되는가

클라이언트 연결 기록을 열어 대상 도메인이 어떤 규칙에 매칭되었고 최종적으로 어느 정책 그룹을 사용했는지 확인하세요. 트래픽이 예상과 달리 직접 연결된다면 우선순위가 높은 직접 연결 규칙이 이후 프록시 규칙을 덮고 있는지 확인합니다. 모든 트래픽이 프록시를 사용한다면 전역 모드를 잘못 선택했거나 MATCH 앞에 필요한 직접 연결 규칙이 없는지 확인하세요. 규칙 프로바이더를 사용하는 경우 원격 파일이 성공적으로 다운로드되고 설정에서 참조되는지도 확인해야 합니다.

네 번째 단계: 시스템 프록시와 TUN이 충돌하는가

TUN을 활성화한 뒤에도 일부 클라이언트가 시스템 프록시를 함께 유지하면 특정 환경에서 이중 제어나 문제 추적의 혼란이 발생할 수 있습니다. 대상 클라이언트의 구현 방식에 따라 권장 조합을 선택하세요. 브라우저만 작동하고 다른 앱은 작동하지 않는다면 일반 시스템 프록시는 적용되었지만 대상 앱이 해당 설정을 읽지 않는 것일 수 있습니다. TUN을 켠 뒤 전체 네트워크가 끊기면 가상 네트워크 어댑터 권한, 자동 라우팅, DNS 하이재킹 및 다른 VPN 소프트웨어를 확인하세요.

다섯 번째 단계: 종료 후 네트워크가 복구되는가

새 클라이언트를 종료한 뒤 시스템 프록시가 꺼졌는지, 브라우저가 직접 연결이 허용된 사이트에 접속할 수 있는지, DNS가 더 이상 작동하지 않는 로컬 수신 포트를 가리키지 않는지 확인하세요. Windows에서는 시스템 프록시 페이지를, macOS에서는 현재 네트워크 서비스의 프록시 항목을 확인할 수 있습니다. Linux에서는 데스크톱 환경과 시작 방식에 따라 환경 변수, 데스크톱 프록시 및 systemd 서비스를 확인하세요. 종료 후에도 인터넷에 연결되지 않으면 남은 프록시 상태를 먼저 지운 다음 가상 네트워크 어댑터와 라우팅을 점검하세요.

마이그레이션 완료 후 장기 유지보수 항목

새 클라이언트가 안정적으로 실행된 뒤에는 유지보수 출처도 정리해 두어야 합니다. 클라이언트, 프록시 코어, 구독 및 규칙 데이터베이스는 서로 독립적인 네 가지 업데이트 요소이므로 모든 문제를 클라이언트 탓으로 돌려서는 안 됩니다. 인터페이스 업데이트는 설정 관리 방식을 바꿀 수 있고, 코어 업데이트는 필드를 추가하거나 조정할 수 있습니다. 구독 업데이트는 노드와 정책 그룹을 바꾸며, 규칙 데이터베이스 업데이트는 도메인 및 주소 분류에 영향을 줍니다.

일상적으로는 구조가 단순한 비상용 설정을 하나 보관하고 현재 안정 버전도 기록해 두는 것이 좋습니다. 업데이트 전에 변경 사항을 읽고, 업데이트 후에는 코어 시작, 구독 새로 고침, 자주 쓰는 규칙 및 TUN을 순서대로 확인하세요. 업무 환경에서 연속성이 중요하다면 큰 버전 변경을 미루고 별도 설정에서 먼저 테스트할 수 있습니다. 클라이언트 대체의 최종 목표는 화면이나 기능 수를 계속 좇는 것이 아니라 검증과 롤백이 가능한 설정 경로를 구축하는 데 있습니다.

대상 클라이언트를 아직 정하지 못했다면 먼저 이 사이트의 클라이언트 비교와 개념 빠른 참조를 확인한 뒤, 운영체제, TUN 필요 여부, 로컬 규칙 관리 여부 및 LAN 공유 필요 여부에 따라 선택하세요. 설치가 끝나면 사용 가이드에 따라 최소한의 작동 설정을 만드는 편이 기존 데이터를 전부 가져오는 것보다 문제를 찾기 쉽습니다.