마이그레이션 예상 읽기 시간 12분

Clash 클라이언트 지원 종료 후 마이그레이션하는 방법: 설정 보존과 대체 프로그램 선택

기존 Clash 클라이언트의 마이그레이션 준비, 설정 이전 방법과 플랫폼별 대체 클라이언트를 안내합니다.

클라이언트, 코어, 설정을 먼저 구분하기

Clash 클라이언트의 유지보수가 중단되었다고 해서 기존 구독과 YAML 설정까지 동시에 사용할 수 없게 되는 것은 아닙니다. 마이그레이션에서 가장 먼저 해야 할 일은 그래픽 인터페이스, 프록시 코어, 설정 파일, 구독 서비스를 분리해서 이해하는 것입니다. 그래픽 클라이언트는 설정 다운로드, 프록시 그룹 전환, 시스템 프록시 제어와 연결 기록 표시를 담당합니다. 코어는 규칙 해석, 프록시 연결 수립, DNS 및 TUN 같은 네트워크 기능 실행을 맡습니다. 설정 파일에는 포트, 노드, 프록시 그룹과 규칙 사이의 관계가 저장됩니다.

일부 구형 데스크톱 클라이언트는 초기 Clash 코어를 사용하고, 다른 클라이언트는 이미 Clash Meta, 즉 현재 흔히 사용하는 Mihomo 코어로 전환했습니다. Mihomo는 Clash 설정 체계를 이어받으면서 더 많은 프로토콜, 규칙 세트, DNS 및 트래픽 가로채기 기능을 추가했습니다. Mihomo 클라이언트로 마이그레이션할 때 일반적인 proxies, proxy-groups, rules, proxy-providers는 대체로 계속 사용할 수 있습니다. 하지만 구형 클라이언트 전용 인터페이스 설정, 스크립트, 데이터베이스와 서비스 설치 상태는 범용 설정처럼 그대로 복사할 수 없습니다.

따라서 마이그레이션의 목표는 기존 프로그램 디렉터리 전체를 새 프로그램으로 옮기는 것이 아니라, 여러 클라이언트에서 재사용할 수 있는 데이터만 보존하고 새 클라이언트가 실행 환경을 다시 구성하도록 하는 것입니다. 이렇게 하면 구버전 캐시, 손상된 데이터베이스, 포트 점유와 잔여 드라이버로 인한 문제를 피할 수 있습니다.

마이그레이션 전에 저장해야 할 항목

기존 클라이언트를 삭제한 뒤에야 설정을 찾지 마세요. 일부 프로그램은 설정을 사용자 데이터 디렉터리에 저장하며, 삭제 과정에서 애플리케이션 데이터까지 함께 지워질 수 있습니다. 먼저 기존 클라이언트를 실행 가능한 상태로 유지한 채 아래 백업을 완료한 다음 기존 프로그램과 새 프로그램을 전환하는 것이 좋습니다.

구독 주소와 설정 파일

설정이 구독에서 제공된다면 먼저 원본 구독 주소를 기록하고 아직 업데이트 가능한지 확인하세요. 클라이언트 목록에 표시되는 설정 이름은 로컬 라벨일 뿐 구독 URL을 대신할 수 없습니다. 서비스 제공자가 전용 변환 링크를 제공한다면 원본 구독과 변환 규칙 사이의 관계도 기록해야 마이그레이션 후 다른 형식의 설정을 받는 일을 막을 수 있습니다.

직접 관리하는 설정은 노드 부분만 복사하지 말고 전체 YAML로 내보내야 합니다. 프록시 그룹은 노드 이름이나 Provider 이름을 통해 참조를 만들고, 규칙은 다시 프록시 그룹을 참조하므로 proxies 부분만 남기면 이 참조 연결이 끊어집니다. 설정에서 로컬 규칙 세트, 스크립트 또는 오버라이드 파일을 참조한다면 해당 파일도 함께 복사하세요.

로컬 오버라이드와 사용자 지정 규칙

많은 클라이언트는 구독 설정 외에 DNS 강제 변경, 규칙 추가, 수신 포트 변경 또는 LAN 접근 허용 같은 오버라이드 기능을 제공합니다. 이러한 내용은 클라이언트 데이터베이스에 저장될 수 있으며 구독 YAML에 기록되지 않습니다. 마이그레이션 전에 ‘오버라이드’, ‘전역 확장’, ‘설정 병합’ 또는 유사한 화면을 항목별로 확인하고 실제 적용 중인 설정을 기록하세요.

규칙 순서는 반드시 유지해야 합니다. Clash 규칙은 일반적으로 위에서 아래로 매칭되며, 연결은 첫 번째 규칙에 일치하면 이후 검사를 중단합니다. 사용자 지정 직접 연결 규칙을 MATCH 뒤에 추가하면 절대 적용되지 않습니다. 마이그레이션 시 규칙 텍스트가 완전히 같더라도 병합 위치가 바뀌면 라우팅 결과가 달라질 수 있습니다.

포트, LAN 및 컨트롤 인터페이스

기존 클라이언트가 사용하던 mixed-port, HTTP 포트, SOCKS 포트, LAN 연결 허용 여부와 외부 컨트롤러 주소를 기록하세요. 브라우저 확장 프로그램, 터미널 환경 변수, 다운로드 도구와 기타 애플리케이션이 여전히 기존 포트를 가리킬 수 있습니다. 새 클라이언트가 포트를 무작위로 할당했는데 외부 프로그램이 기존 포트로 계속 연결하면 ‘클라이언트는 정상인데 일부 프로그램만 인터넷에 연결되지 않는’ 현상이 발생합니다.

external-controller와 컨트롤 키는 주로 그래픽 인터페이스나 외부 패널에서 호출합니다. 같은 포트를 이미 사용 중인 병렬 인스턴스에 이를 그대로 복사해서는 안 됩니다. 기존 클라이언트와 새 클라이언트를 동시에 실행할 때도 동일한 프록시 포트를 수신하도록 설정해서는 안 됩니다.

민감한 정보의 보관 방법

구독 URL에는 계정 식별에 사용되는 접근 매개변수가 포함되는 경우가 많고, 전체 YAML에도 서버 주소, 인증 정보와 컨트롤 키가 들어갈 수 있습니다. 백업 파일은 접근이 제한된 디렉터리에 보관하고 전체 내용을 공개 질문 게시판, 스크린샷 또는 공개 코드 저장소에 올리지 마세요. 오류를 공유해야 한다면 필드 구조만 남기고 인증 값은 삭제하세요.

권장하는 Clash 설정 마이그레이션 단계

  1. 기존 설정을 업데이트하고 내보냅니다. 기존 클라이언트에서 구독을 한 번 업데이트하고 프록시 그룹과 노드 목록이 정상적으로 불러와지는지 확인한 다음 구독 주소, YAML과 사용자 지정 규칙을 저장하세요.
  2. 현재 네트워크 설정을 기록합니다. 프록시 포트, 시스템 프록시 상태, TUN 상태, DNS 모드와 LAN 스위치를 저장하세요. 터미널에 프록시 환경 변수가 별도로 설정되어 있다면 해당 변수에서 사용하는 포트도 기록해야 합니다.
  3. 기존 클라이언트의 트래픽 가로채기 기능을 끕니다. 먼저 시스템 프록시와 TUN을 끈 다음 기존 클라이언트를 완전히 종료하세요. 창만 닫아서는 백그라운드 코어가 중지되지 않을 수 있으므로 작업 관리자나 시스템 활동 모니터에서 프로세스가 종료되었는지 확인해야 합니다.
  4. 새 클라이언트를 설치하고 실행합니다. 처음 실행할 때는 기본 설정을 사용하고 기존 클라이언트의 데이터 디렉터리 전체를 바로 복사하지 마세요. 새 클라이언트의 코어가 정상적으로 실행되는지 확인한 뒤 설정을 가져오세요.
  5. 먼저 구독을 다시 추가합니다. 구독이 아직 유효하다면 새 클라이언트에서 URL을 다시 추가하는 편이 캐시 파일을 복사하는 것보다 일반적으로 안정적입니다. 수동 설정은 로컬 파일로 가져오고 연결된 파일의 상대 경로를 유지하세요.
  6. 오버라이드를 다시 적용합니다. 새 클라이언트가 지원하는 형식에 맞춰 DNS, 포트, 사용자 지정 규칙과 Provider를 설정하세요. 클라이언트마다 오버라이드 문법이 호환되지 않을 수 있으므로 파일 확장자만으로 판단해서는 안 됩니다.
  7. 일반 프록시를 먼저 확인한 뒤 TUN을 켭니다. 먼저 시스템 프록시로 웹페이지와 연결 기록을 테스트하여 노드, 프록시 그룹과 규칙이 정상인지 확인한 다음 TUN을 별도로 활성화하세요. 단계별로 검증하면 문제가 설정에서 발생했는지 트래픽 가로채기에서 발생했는지 쉽게 구분할 수 있습니다.
  8. 안정화된 뒤 기존 클라이언트를 제거합니다. 기존 설정 백업은 일정 기간 보관하되, 두 클라이언트가 동시에 시스템 프록시를 변경하거나 기본 라우트를 가로채도록 두지 마세요.

마이그레이션 가능한 기본 설정은 일반적으로 참조 관계가 명확합니다. 아래 예시는 구체적인 노드를 생략하고 Provider로 노드를 제공한 뒤 프록시 그룹과 규칙에서 이를 계속 참조합니다.

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

proxy-providers:
  provider-main:
    type: http
    url: "https://example.com/profile.yaml"
    path: ./providers/main.yaml
    interval: 86400
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 600

proxy-groups:
  - name: PROXY
    type: select
    use:
      - provider-main

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

가져온 뒤 ‘Provider가 없음’ 또는 프록시 그룹이 비어 있는 문제가 발생하면 Provider 이름, 다운로드 상태와 프록시 그룹의 use 참조를 순서대로 확인하세요. 파일 경로가 설정 파일 위치를 기준으로 하는데 YAML만 옮기고 규칙 세트나 Provider 캐시를 옮기지 않으면 로드에 실패할 수 있습니다. 원격 Provider는 새 클라이언트에서 다시 다운로드할 수 있으므로 기존 데이터베이스에서 억지로 복사할 필요가 없습니다.

플랫폼별 대체 클라이언트 선택 방법

대체 프로그램은 인터페이스가 비슷한지만 보고 선택해서는 안 됩니다. 더 실용적인 판단 기준은 지속적인 유지보수 여부, 사용하는 코어, 기존 설정 가져오기 지원 여부, 시스템 프록시와 TUN 지원 여부, 문제 해결에 유용한 로그 제공 여부, 설치 패키지가 운영체제와 프로세서 아키텍처에 맞는지입니다. Mihomo 코어를 사용하는 클라이언트로 마이그레이션하면 일반적인 Clash 규칙 구조는 계속 사용할 수 있는 경우가 많지만 그래픽 인터페이스의 조작 경로는 달라집니다.

Windows

Windows 사용자는 지속적으로 유지보수되고 Mihomo 코어를 명확히 표시하며 서비스 모드나 TUN 관리를 지원하는 데스크톱 클라이언트를 우선 선택하는 것이 좋습니다. 일반 웹페이지와 대부분의 데스크톱 프로그램은 시스템 프록시만 사용하면 됩니다. 게임, 명령줄 프로그램 또는 시스템 프록시를 읽지 않는 애플리케이션에만 TUN이 필요할 수 있습니다. TUN을 켜면 관리자 권한, 네트워크 어댑터와 시스템 서비스가 관련되는 경우가 많으므로 먼저 일반 프록시 테스트를 완료해야 합니다.

설치 패키지의 아키텍처도 확인하세요. 대부분의 최신 컴퓨터는 x64를 사용하며 Windows on ARM 장치는 arm64 빌드가 필요할 수 있습니다. 마이그레이션 중 시스템 프록시 스위치를 복구할 수 없다면 먼저 모든 프록시 클라이언트를 종료한 뒤 Windows 프록시 설정에서 수동 프록시가 여전히 기존 포트를 가리키는지 확인하세요.

macOS

macOS 대체 클라이언트는 Apple 실리콘 또는 Intel 프로세서에 맞아야 합니다. Apple 실리콘은 일반적으로 arm64 또는 universal 빌드를 선택하고 Intel 기기는 x64 빌드를 선택합니다. 시스템에서 처음 실행할 때 네트워크 확장, 보조 서비스 또는 VPN 설정을 승인하라는 메시지가 표시될 수 있습니다. 이러한 권한은 TUN 가로채기 절차에 해당하며 YAML 설정의 일부가 아닙니다.

기존 클라이언트에서 마이그레이션한 뒤 메뉴 막대에는 프록시가 활성화된 것으로 표시되지만 애플리케이션이 여전히 직접 연결된다면 현재 네트워크 서비스에 시스템 프록시가 올바르게 기록되었는지 확인하세요. macOS에는 Wi-Fi, 유선 네트워크와 기타 네트워크 서비스가 동시에 존재할 수 있습니다. 클라이언트가 수정한 서비스와 실제 사용 중인 서비스가 다르면 프록시가 켜진 것처럼 보여도 트래픽이 코어를 통과하지 않을 수 있습니다.

Android

Android의 Clash 계열 클라이언트는 일반적으로 데스크톱 시스템 프록시가 아니라 시스템 VPN 인터페이스를 통해 트래픽을 가로챕니다. 마이그레이션의 핵심은 구독을 다시 가져오고 VPN 연결 생성을 허용한 뒤 앱별 프록시, 우회 설정과 배터리 백그라운드 제한을 확인하는 것입니다. 기존 클라이언트에서 내보낸 앱별 분기 목록을 새 클라이언트가 인식하지 못할 수 있으므로 어떤 앱을 프록시로 연결할지 다시 선택해야 합니다.

기기에 다른 VPN, 광고 차단 도구 또는 업무 프로필 네트워크가 이미 있으면 일반적으로 여러 VPN 인터페이스를 동시에 활성화할 수 없습니다. 새 클라이언트를 테스트할 때는 먼저 다른 VPN 서비스를 중지하세요. Android 설치 패키지도 arm64-v8a 같은 프로세서 아키텍처에 맞아야 합니다. 확실하지 않다면 클라이언트가 공식 제공하는 범용 빌드를 선택할 수 있지만 파일 크기는 대개 더 큽니다.

Linux

Linux 사용자는 그래픽 클라이언트를 선택하거나 Mihomo 코어를 직접 실행하고 systemd로 관리할 수 있습니다. 데스크톱 환경의 시스템 프록시는 해당 설정을 따르는 프로그램에만 영향을 주며, 터미널 도구는 여전히 http_proxy, https_proxy, all_proxy 환경 변수가 필요할 수 있습니다. TUN을 사용할 때는 코어 권한, 라우팅 테이블과 DNS 관리 방식도 확인해야 합니다.

그래픽 클라이언트에서 명령줄 코어로 마이그레이션할 때는 설정에서 참조하는 상대 디렉터리와 작업 디렉터리를 특히 잘 보존해야 합니다. 같은 YAML이라도 실행 디렉터리가 다르면 외부 규칙 파일과 Provider 경로가 다른 위치로 해석될 수 있습니다. 설정, Provider와 규칙 세트를 고정 디렉터리에 배치한 뒤 서비스 매개변수로 설정 경로를 명시하는 것이 좋습니다.

iPhone 및 iPad

iOS와 iPadOS에는 데스크톱 또는 Android용 Clash 클라이언트를 직접 설치할 수 없습니다. 플랫폼에서 설치를 허용하고 필요한 프로토콜과 규칙 형식을 지원하는 네트워크 도구를 선택한 뒤, 해당 도구의 가져오기 기능에 맞춰 설정을 변환해야 합니다. Clash YAML을 모든 iOS 클라이언트가 원본 그대로 읽을 수 있는 것은 아니며, 프록시 그룹, 스크립트, 규칙 세트와 DNS 필드는 대상 앱 문서에 맞게 조정해야 할 수 있습니다. 마이그레이션 전에 구독 서비스가 해당 형식을 제공하는지 확인하는 편이 노드를 수동으로 복사하는 것보다 안전합니다.

구독, 규칙 및 DNS 호환성 확인

설정을 가져올 수 있다는 것은 YAML 문법이 통과했다는 뜻일 뿐, 모든 연결이 예상대로 라우팅된다는 의미는 아닙니다. 마이그레이션 후에는 구독 업데이트, 노드 연결, 프록시 그룹 참조, 규칙 매칭과 DNS 해석의 다섯 가지 영역을 확인해야 합니다.

구독 업데이트 실패

오류가 다운로드 단계에서 발생했는지 파싱 단계에서 발생했는지 먼저 확인하세요. 다운로드 시간 초과는 네트워크, 구독 주소 또는 프록시 루프와 관련된 경우가 많습니다. 파싱 실패는 반환된 내용이 YAML이 아니거나 구독 변환 형식이 잘못되었거나 현재 코어가 인식하지 못하는 필드를 설정에 포함했기 때문일 수 있습니다. 클라이언트가 ‘프록시를 통해 구독 업데이트’를 지원하더라도 처음 실행할 때는 신중하게 사용하세요. 아직 작동하는 노드가 없어 업데이트 의존성이 생기기 쉽습니다.

규칙 세트를 불러올 수 없음

기존 설정은 rule-providers를 통해 원격 규칙 세트를 참조할 수 있습니다. 마이그레이션 후에는 동작 유형, 형식, URL, 저장 경로와 규칙에서 사용하는 참조 이름을 확인하세요. 규칙 Provider의 이름과 프록시 그룹 이름은 서로 다른 개념이므로 바꿔 사용할 수 없습니다. GEOIP, GEOSITE 등의 규칙을 사용할 때는 클라이언트가 해당 지리 데이터베이스를 다운로드하고 로드할 수 있는지도 확인해야 합니다.

DNS 동작 변화

기존 클라이언트와 새 클라이언트는 기본 DNS 설정이 다를 수 있습니다. fake-ip를 활성화하면 코어가 애플리케이션에 예약 주소를 반환한 뒤 내부 매핑을 통해 실제 연결을 처리합니다. redir-host는 해석 경로가 다릅니다. 마이그레이션할 때 기존 설정을 충분히 이해하지 못한 상태에서 DNS 섹션 전체를 바로 복사하지 마세요. 특히 수신 주소, 업스트림 서버, 폴백 규칙과 Fake IP 제외 목록을 확인해야 합니다.

웹페이지가 간헐적으로 열리지 않거나 LAN 기기의 도메인이 작동하지 않거나 일부 앱의 로그인이 비정상일 때는 사용자 지정 DNS 오버라이드를 일시적으로 끄고 새 클라이언트의 기본값으로 다시 테스트할 수 있습니다. 기본 설정이 정상이라면 기존 설정을 하나씩 복원하세요. DNS 필드를 여러 개 동시에 변경하면 문제 해결을 위한 비교 기준을 잃게 됩니다.

TUN 모드 마이그레이션과 일반적인 문제

TUN 모드는 가상 네트워크 인터페이스를 만들고 라우팅 또는 시스템 네트워크 확장을 통해 더 많은 트래픽을 코어가 처리하도록 전달합니다. 시스템 프록시를 따르지 않는 애플리케이션까지 다룰 수 있지만 일반 시스템 프록시보다 운영체제 권한에 더 크게 의존합니다. 기존 클라이언트의 TUN 드라이버, 서비스 등록 정보와 라우팅 상태를 새 클라이언트로 복사해서는 안 됩니다.

올바른 순서는 기존 클라이언트에서 TUN을 끄고 완전히 종료한 뒤 가상 인터페이스가 더 이상 작동하지 않는지 확인하는 것입니다. 그 다음 새 클라이언트의 절차에 따라 서비스를 설치하거나 권한을 요청하세요. 기존 클라이언트와 새 클라이언트에서 동시에 TUN을 활성화하면 기본 라우트 경쟁, DNS 설정 반복 변경, 네트워크 루프 또는 인터넷 연결 끊김이 발생할 수 있습니다.

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

  • 현재 프록시 그룹이 사용 가능한 노드를 선택했는지, 최종 규칙이 존재하는 프록시 그룹을 가리키는지 확인하세요.
  • 시스템에 다른 VPN, 프록시 도구 또는 네트워크 필터 프로그램이 라우팅을 점유하고 있지 않은지 확인하세요.
  • 클라이언트 서비스에 필요한 권한이 있고 가상 인터페이스 생성 과정에서 오류가 발생하지 않았는지 확인하세요.
  • 사용자 지정 DNS와 복잡한 라우팅 설정을 일시적으로 끄고 클라이언트 기본 TUN 설정으로 테스트하세요.
  • TUN을 끈 뒤 일반 시스템 프록시가 여전히 작동하는지 확인하여 노드 문제와 트래픽 가로채기 문제를 구분하세요.

브라우저는 정상인데 터미널만 실패함

이는 일반적으로 브라우저는 시스템 프록시를 사용하지만 터미널 프로그램은 시스템 프록시를 읽지 않는다는 뜻입니다. 터미널 도구가 새 클라이언트의 HTTP 또는 SOCKS 포트에 명시적으로 연결하도록 설정하거나, 올바르게 구성된 TUN을 활성화할 수 있습니다. 마이그레이션 후에는 환경 변수에 남아 있는 기존 포트도 함께 변경해야 합니다. 그래픽 클라이언트에서 수신 포트만 바꾼다고 shell 설정 파일이 자동으로 수정되지는 않습니다.

클라이언트를 종료했는데도 프록시가 계속 표시됨

클라이언트가 비정상 종료되면 시스템 프록시가 복원되지 않을 수 있습니다. 이때는 먼저 운영체제 네트워크 설정에서 수동 프록시를 끈 다음 새 클라이언트를 다시 시작하세요. 시스템 프록시 상태를 차지하려고 여러 구형 클라이언트를 반복해서 실행하지 마세요. 현재 설정을 판단하기가 더 어려워집니다. TUN 서비스가 백그라운드에서 계속 실행 중이라면 새 클라이언트의 서비스 관리 기능으로 중지하고, 필요하면 시스템을 재시작하여 임시 라우트를 정리하세요.

마이그레이션 완료 후 검증 체크리스트

마이그레이션 완료 여부를 ‘웹페이지가 열리는지’만으로 판단해서는 안 됩니다. 완전한 검증 과정에는 최소한 다음 항목이 포함되어야 합니다.

  • 구독을 수동으로 업데이트할 수 있고, 업데이트 후 사용자 지정 규칙이 사라지지 않는다.
  • 프록시 그룹에서 예상한 노드를 확인할 수 있고 자동 속도 측정 또는 상태 점검이 실행된다.
  • 서로 다른 유형의 사이트에 접속할 때 연결 기록이 예상한 규칙과 정책에 매칭된다.
  • 시스템 프록시를 끄면 트래픽이 직접 연결로 돌아가고, 다시 켜면 포트가 클라이언트 설정과 일치한다.
  • TUN을 켜고 꺼도 비정상 라우트가 남지 않으며 LAN 접근이 설정에 맞게 작동한다.
  • 터미널, 브라우저와 프록시가 필요한 독립 애플리케이션이 모두 올바른 포트를 사용한다.
  • 운영체제를 재시작한 뒤 클라이언트가 예상대로 실행되고 설정과 권한이 계속 유효하다.
  • 기존 클라이언트가 종료되어 더 이상 자동으로 시작하거나 시스템 프록시를 변경하지 않는다.

검증이 안정적으로 끝나면 기존 클라이언트를 삭제하고 정리된 설정 백업을 하나 보관할 수 있습니다. 백업에는 생성 날짜, 적용 코어와 종속 파일을 기록하여 몇 달 뒤에도 파일의 출처를 확인할 수 있게 하세요. 구독 설정은 클라이언트에서 정기적으로 업데이트하고, 로컬 사용자 지정 규칙은 별도로 저장하는 것이 구독 덮어쓰기로 인한 손실 위험을 줄이는 데 도움이 됩니다.

클라이언트 마이그레이션의 핵심은 더 많은 파일을 복사하는 것이 아니라 어떤 데이터가 공용 Clash 설정이고 어떤 상태가 기존 프로그램에 종속되는지 구분하는 데 있습니다. 먼저 구독과 규칙을 백업한 뒤 시스템 프록시, DNS와 TUN을 단계적으로 검증하면 지원이 중단된 클라이언트로 전환할 때의 위험을 추적 가능한 범위로 줄일 수 있습니다.

Clash 다운로드