Clash for Windows 지원 종료 후 대처법: mihomo 기반 클라이언트로 이전하는 완벽 가이드

이전할 대상이 클라이언트인지, 구독인지, 로컬 설정인지 먼저 확인하기

Clash for Windows의 유지보수가 종료되어도 이미 설치된 프로그램이 즉시 작동을 멈추는 것은 아닙니다. 구독 주소에 계속 접속할 수 있고 노드 프로토콜이 현재 커널에서 지원된다면 기존 클라이언트는 대개 설정을 불러와 트래픽을 전달할 수 있습니다. 진짜 문제는 커널이 장기간 업데이트되지 않으면 새로운 프로토콜 필드, 규칙 문법, DNS 동작과 시스템 호환성이 더 이상 개선되지 않는다는 점입니다. 구버전은 단기적인 과도기에는 활용할 수 있지만 장기적인 설정 관리 도구로 사용하기에는 적합하지 않습니다.

이전하기 전에 데이터를 세 가지로 구분해야 합니다. 클라이언트는 그래픽 인터페이스와 시스템 연동 계층이고, 구독은 서버에서 설정을 생성하는 진입점이며, 로컬 YAML에는 직접 작성한 노드, 규칙 집합, DNS와 TUN 매개변수가 포함될 수 있습니다. 세 가지를 하나의 파일처럼 다뤄서는 안 됩니다. 구독만 사용하는 경우에는 보통 구독 URL만 저장하면 됩니다. 직접 작성한 규칙이나 오버라이드가 있다면 설정을 별도로 내보내고 기기별 매개변수도 기록해야 합니다.

이전 목표

계속 유지보수되고 커널로 mihomo를 사용하며, 커널 버전을 표시하고 설정 검사를 지원하는 클라이언트를 우선 선택하세요. mihomo는 기존 Clash 설정 체계를 이어받으면서 프로토콜, 규칙 집합, DNS, TUN과 트래픽 스니핑 기능을 확장합니다. 기존 설정은 대체로 바로 가져온 뒤 기기에 맞게 수정할 수 있습니다.

이전 전에 저장해야 할 항목

구독 원본 URL과 구독 이름, 업데이트 시간, 잔여 트래픽 정보를 저장합니다.
현재 사용 중인 YAML 파일을 저장합니다. 클라이언트 화면을 캡처하는 것만으로는 충분하지 않습니다.
정책 그룹에서 직접 선택한 노드도 기록합니다. 예를 들어 「노드 선택」, 「스트리밍」, 「다운로드」에 각각 어떤 노드가 선택되어 있는지 확인합니다.
DNS, TUN, 규칙 추가, 프록시 우회 주소와 애플리케이션 분기 목록을 포함한 로컬 오버라이드 내용을 저장합니다.
시스템 프록시 포트입니다. 일반적인 혼합 포트는 7890이고 제어 포트는 보통 9090이지만, 실제 값은 기존 설정을 기준으로 확인해야 합니다.

Clash for Windows에서 설정 찾기

Clash for Windows에서 먼저 「Profiles」로 이동해 현재 설정 이름을 확인합니다. 구독 설정은 페이지에 표시된 구독 주소를 기록하고, 로컬 설정은 설정 메뉴에서 파일 위치를 엽니다. 일반적인 데이터 디렉터리는 %USERPROFILE%\.config\clash이지만 포터블 버전, 사용자 지정 Home Directory 또는 배포 패키지에 따라 다른 경로를 사용할 수 있으므로 클라이언트에 표시되는 디렉터리를 기준으로 해야 합니다.

디렉터리를 복사할 때는 config.yaml, 구독으로 생성된 YAML, Provider 캐시와 사용자 지정 스크립트를 중점적으로 확인합니다. 캐시 파일은 이전의 핵심 대상이 아니며, 새 mihomo 클라이언트가 프록시 Provider와 규칙 집합을 다시 다운로드합니다. 보존해야 할 것은 원본 설정과 설정을 다시 가져올 수 있는 주소입니다.

mihomo 클라이언트는 커널과 시스템 기능을 기준으로 선택하기

이전은 외관이 Clash for Windows와 완전히 같은 프로그램을 찾는 일이 아닙니다. 더 확실한 선택 방법은 먼저 커널을 확인한 다음 시스템 연동 방식과 설정 관리 기능을 살펴보는 것입니다. 데스크톱에서는 시스템 프록시, TUN, 시작 시 자동 실행과 설정 업데이트가 필요하고, Android에서는 Android VPN 권한, 애플리케이션별 분기, 백그라운드 실행과 배터리 정책 대응이 필요합니다.

데스크톱에서 확인할 항목

커널 정보 표시: 「설정」 또는 「정보」 화면에서 mihomo 사용 여부와 구체적인 버전 번호를 확인할 수 있어야 합니다.
명확한 설정 검사: 가져오기에 실패했을 때 단순히 시작 실패라고 표시하는 대신 YAML의 줄 번호나 필드를 알려줘야 합니다.
시스템 프록시 제어: HTTP, SOCKS 또는 Mixed 포트를 설정할 수 있어야 하며, 일반적인 기본값은 7890입니다.
TUN 상태 확인: 가상 네트워크 카드가 생성되었는지 표시하고 관리자 권한이나 서비스 설치 상태를 안내해야 합니다.
오버라이드와 구독 분리: 구독을 업데이트해도 로컬 포트, DNS와 TUN 수정 사항이 설정 전체와 함께 덮어써져서는 안 됩니다.

Android에서 확인할 항목

mihomo 설정을 지원하고 원격 구독 또는 로컬 YAML을 가져올 수 있어야 합니다.
Android의 VPN 인터페이스를 통해 트래픽을 제어하며, 시작할 때 시스템 VPN 권한 요청 창이 표시되어야 합니다.
「설정」→「네트워크」 또는 「설정」→「오버라이드」와 같은 메뉴를 제공해 DNS, IPv6, TUN 스택과 MTU를 조정할 수 있어야 합니다.
애플리케이션별 프록시를 제공해 선택한 앱만 프록시하거나 지정한 앱을 제외할 수 있어야 합니다.
로그 화면에서 연결 대상, 적용된 규칙, 정책 그룹과 아웃바운드 노드를 확인할 수 있어야 합니다.

클라이언트마다 화면의 메뉴 이름은 다를 수 있지만, 커널 기능은 실제 버전과 설정 테스트를 기준으로 판단해야 합니다. 가져온 뒤 로그에서 mihomo 시작 정보를 찾고 웹페이지에 접속해 연결 기록에 대상 도메인, 적용된 규칙과 아웃바운드 정책이 함께 표시되는지 확인하세요. 화면에 “연결됨”만 표시된다고 해서 DNS와 규칙 체인이 정상이라는 뜻은 아닙니다.

구독 이전: 원본 주소를 다시 가져오는 방법 우선

공급자 또는 서비스 업체의 구독만 사용하는 경우 가장 안정적인 방법은 Clash for Windows에서 생성된 config.yaml을 복사하는 것이 아니라 새 클라이언트에 원본 구독 URL을 다시 추가하는 것입니다. 데스크톱에서는 보통 「설정」→「새로 만들기」→「URL」에서 추가하고, Android mihomo 클라이언트에서는 보통 「설정」→오른쪽 위 “+”→「URL에서 가져오기」를 선택합니다. 이름을 입력한 뒤 즉시 한 번 업데이트하고 정책 그룹과 노드 수를 확인하세요.

기존 클라이언트에서 구독 업데이트 시간, 노드 수와 주요 정책 그룹 이름을 기록합니다.
새 클라이언트에 같은 구독 주소를 추가하고 업데이트 주기를 설정합니다. 예를 들어 1440분으로 설정할 수 있습니다.
업데이트가 완료되면 해당 설정을 선택하고 커널이 다시 로드될 때까지 기다립니다.
「프록시」 화면에서 GLOBAL, DIRECT, REJECT와 사용자 지정 정책 그룹이 정상적으로 표시되는지 확인합니다.
최소 두 개의 노드를 차례로 테스트하고 지연 시간과 실제 연결 상태를 기록합니다.

지연 시간은 초기 선별에만 사용할 수 있습니다. 한 노드가 42ms로 표시된다고 해서 다운로드 속도가 95ms인 노드보다 반드시 빠른 것은 아닙니다. 이전 완료를 확인할 때는 다음 세 가지를 점검하세요. 웹페이지가 2초 안에 처음 열리는지, 1080p 동영상이 연속 재생 중 자주 버퍼링되지 않는지, 같은 테스트 파일의 안정적인 속도가 이전보다 크게 낮아지지 않았는지 확인합니다. 모든 노드에 문제가 있다면 구독을 반복해서 바꾸기보다 먼저 DNS, 시스템 프록시와 TUN을 점검해야 합니다.

구독 주소는 민감한 설정입니다

구독 URL에는 계정 식별에 사용되는 토큰이 포함되는 경우가 많습니다. 전체 주소를 공개 로그, 스크린샷, 코드 저장소나 공유 YAML에 남기지 마세요. 여러 기기에서 사용할 때는 각 기기의 클라이언트에 주소를 직접 저장해야 합니다.

생성된 설정을 장기간 복사해 사용하지 않는 이유

생성된 설정은 특정 시점의 구독 업데이트 결과이며, 노드 주소, 인증서 매개변수, 정책 그룹과 규칙은 이후에도 변경될 수 있습니다. 직접 복사하면 임시 복구에는 사용할 수 있지만 후속 업데이트를 자동으로 받지는 못합니다. 설정에 proxy-providers 또는 rule-providers가 포함되어 있다면 복사할 때 Provider URL이 여전히 유효한지 확인하고, 새 클라이언트가 로컬 캐시 경로를 다시 만들 수 있는지도 확인해야 합니다.

로컬 YAML 이전: 먼저 검사한 뒤 기기 관련 필드 수정하기

mihomo는 기존 Clash 설정과 높은 호환성을 제공하므로 일반적인 proxies, proxy-groups, rules, proxy-providers와 rule-providers를 계속 사용할 수 있습니다. 이전할 때는 문법을 대규모로 먼저 바꾸지 말고 원본 파일을 백업한 뒤 바로 가져와 처음 표시되는 명확한 오류를 확인해야 합니다. 한 번에 한 종류의 필드만 수정하면 문제를 더 쉽게 찾을 수 있습니다.

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

external-controller: 127.0.0.1:9090

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

proxy-groups:
  - name: 노드 선택
    type: select
    proxies:
      - 자동 선택
      - DIRECT

rules:
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택

위 예에서는 7890을 Mixed 인바운드 포트로, 9090을 외부 제어 포트로, DNS 수신 포트를 1053으로 사용합니다. 이 값은 데스크톱에서 사용할 수 있지만 모든 기기에 그대로 복사해서는 안 됩니다. Android 클라이언트는 보통 VPN 인바운드와 제어 인터페이스를 자체적으로 관리하므로 직접 작성한 수신 주소가 클라이언트 내장 서비스와 충돌할 수 있습니다.

대체로 그대로 유지할 수 있는 필드

proxies에 포함된 현재 mihomo 버전에서 지원하는 노드 프로토콜 매개변수입니다.
proxy-groups의 select, url-test, fallback과 load-balance 구조입니다.
rules의 도메인, IP, 프로세스와 규칙 집합 참조입니다. 단, 프로세스 규칙은 시스템 권한의 영향을 받습니다.
proxy-providers와 rule-providers의 원격 URL, 업데이트 간격과 상태 확인 로직입니다.
DNS의 nameserver, fallback, nameserver-policy와 fake-ip-filter 규칙입니다.

기기에 따라 확인하거나 수정해야 하는 필드

external-controller: 127.0.0.1로 제한하는 것을 권장합니다. 기존 설정이 0.0.0.0:9090에서 수신하도록 되어 있다면 제어 인터페이스가 로컬 네트워크에 노출됩니다.
secret: 원격 제어를 사용할 때는 별도의 값을 설정하고 해당 패널의 연결 설정에도 같은 값을 입력해야 합니다.
interface-name: Windows, Linux와 Android는 네트워크 인터페이스 이름이 다르므로 이전 후 기존 값을 삭제하거나 다시 선택해야 하는 경우가 많습니다.
routing-mark: 주로 Linux 정책 라우팅에 사용되며 Windows나 Android에 복사해도 같은 효과가 없습니다.
tun: 플랫폼마다 지원하는 stack, 자동 라우팅과 DNS 하이재킹 방식이 다릅니다.
Provider의 로컬 path: C:\Users\...와 같은 Windows 경로는 Android에서 사용할 수 없으므로 상대 경로로 바꾸거나 클라이언트가 관리하도록 해야 합니다.

TUN 설정 전체를 플랫폼 간에 그대로 복사하지 않기

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: true
  dns-hijack:
    - any:53

데스크톱의 TUN은 일반적으로 관리자 권한이나 시스템 서비스가 필요하고, Android에서는 시스템 VPN 인터페이스에 의존합니다. 하나의 Android 기기에서는 동시에 하나의 주요 VPN 제어 도구만 유지할 수 있습니다. 휴대폰에서 다른 VPN, 기업용 업무 프로필 VPN 또는 로컬 방화벽을 함께 실행 중이면 mihomo 클라이언트가 인터페이스를 만들지 못할 수 있습니다.

이전 후 웹페이지는 열리지만 앱이 인터넷에 연결되지 않는다면 먼저 「설정」→「네트워크」에서 TUN stack을 system에서 mixed 또는 gvisor로 바꿔 비교해 보세요. 그런 다음 애플리케이션별 프록시 목록을 확인합니다. 전환 후에는 서비스를 완전히 중지했다가 다시 시작해 기존 가상 인터페이스 상태가 결과에 영향을 주지 않도록 해야 합니다.

데스크톱과 Android 여러 기기에서 일관성을 유지하는 올바른 계층 분리

여러 기기의 설정을 일치시킨다고 해서 모든 기기에서 완전히 같은 YAML 파일을 사용해야 하는 것은 아닙니다. 더 합리적인 구조는 노드, 원격 규칙과 정책 그룹을 공통 계층으로 두고 포트, TUN, 로컬 네트워크 접근, 애플리케이션별 분기와 시스템 권한을 기기 계층으로 분리하는 것입니다. 공통 계층은 구독 또는 Provider가 업데이트하고 기기 계층은 각 클라이언트의 오버라이드 기능에 둡니다.

여러 기기에서 공유하기 좋은 항목

노드 구독과 proxy-providers입니다.
정책 그룹 이름과 기본 선택 로직입니다.
도메인 규칙, IP 규칙과 원격 rule-providers입니다.
DNS 업스트림과 도메인 분기 정책입니다.
자주 사용하는 직접 연결, 거부와 프록시 규칙입니다.

각 기기에서 별도로 관리해야 하는 항목

데스크톱의 Mixed, HTTP, SOCKS와 제어 포트입니다.
로컬 네트워크 기기의 연결 허용 여부와 수신 주소입니다.
Windows 서비스 모드, 시작 시 자동 실행과 TUN 드라이버 상태입니다.
Android 애플리케이션별 프록시, VPN 상시 실행, 배터리 최적화와 모바일 네트워크 동작입니다.
IPv6 활성화 여부, MTU 값과 구체적인 TUN stack입니다.

예를 들어 데스크톱에서는 mixed-port: 7890을 유지해 브라우저나 개발 도구가 127.0.0.1:7890에 수동으로 연결하도록 할 수 있습니다. Android에서는 다른 앱이 이 포트를 입력할 필요 없이 VPN 인터페이스가 통합적으로 트래픽을 제어합니다. 데스크톱 포트 설정을 “모든 기기에 필요한 항목”으로 취급하면 Android 시작 충돌이나 불필요한 설정이 발생할 수 있습니다.

정책 그룹 선택은 자동으로 동기화되지 않습니다

데스크톱과 Android가 같은 구독을 사용하더라도 클라이언트에서 로컬로 선택한 노드는 대개 자동 동기화되지 않습니다. 데스크톱의 「노드 선택」에서 홍콩 노드를 선택해도 휴대폰이 즉시 같은 노드를 선택하는 것은 아닙니다. 여러 기기에서 동작을 안정적으로 유지하려면 주 정책 그룹이 url-test 자동 측정 그룹을 참조하도록 하고, 적절한 테스트 주소, 간격과 허용 오차를 설정하세요.

proxy-groups:
  - name: 자동 선택
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: 노드 선택
    type: select
    proxies:
      - 자동 선택
      - DIRECT

여기서 interval: 300은 300초마다 한 번씩 테스트한다는 뜻이고, tolerance: 50은 지연 시간 차이가 50ms 이하일 때 잦은 전환을 줄인다는 뜻입니다. 테스트 URL은 안정적으로 유지되며 용량이 작은 응답을 반환해야 합니다. 네트워크 환경에 따라 결과는 달라질 수 있으므로 휴대폰이 셀룰러 네트워크를 사용할 때 선택되는 노드가 데스크톱의 광대역 연결과 다를 수 있습니다.

이전 후 검증 순서와 자주 발생하는 문제

이전이 끝난 뒤 웹페이지 하나만 확인해서는 안 됩니다. 설정 로드, DNS, 규칙 적용, 노드 연결과 시스템 연동의 다섯 계층을 순서대로 검증해야 합니다. 이를 통해 문제가 설정 구문 분석, 도메인 해석, 정책 선택 또는 가상 네트워크 카드 중 어디에서 발생했는지 판단할 수 있습니다.

설정 로드: 로그에 YAML 구문 분석 오류, 중복 포트 또는 Provider 다운로드 실패가 없어야 합니다.
DNS 해석: 도메인 요청이 결과를 반환해야 하며 로그에 연속적인 timeout, SERVFAIL 또는 반복 조회가 없어야 합니다.
규칙 적용: 자주 사용하는 사이트에 접속했을 때 연결 기록에 예상한 규칙과 정책 그룹이 표시되어야 합니다.
노드 연결: 서로 다른 지역의 노드를 최소 두 개 테스트해 단일 노드 장애를 배제합니다.
시스템 연동: 시스템 프록시를 끄거나 VPN을 중지했을 때 네트워크 경로가 예상대로 바뀌고, 다시 시작하면 복구되어야 합니다.

가져오기는 성공했지만 모든 노드가 시간 초과되는 경우

먼저 휴대폰이나 컴퓨터의 시스템 시간을 확인하세요. 인증서 핸드셰이크는 시간 오차에 민감합니다. 그런 다음 구독을 업데이트해 노드 매개변수가 오래된 캐시가 아닌지 확인합니다. 도메인 노드만 시간 초과되고 IP 노드는 사용할 수 있다면 DNS를 중점적으로 점검해야 합니다. 로그에 connection refused가 표시되면 노드 서버 포트에 연결할 수 없는 것일 수 있고, i/o timeout이 표시되면 로컬 네트워크, 라우팅과 방화벽도 확인해야 합니다.

규칙 모드에서 일부 앱이 인터넷에 연결되지 않는 경우

원인 파악을 위해서만 모드를 잠시 Global로 전환하세요. Global은 작동하지만 Rule이 작동하지 않는다면 문제는 대개 규칙, 정책 그룹 또는 규칙 집합 업데이트에 있습니다. 최종 MATCH가 가리키는 정책 그룹이 존재하는지 확인한 다음 해당 그룹에 사용 가능한 노드가 선택되어 있는지 확인하세요. 진단을 마치면 Rule로 되돌려야 하며 Global을 장기간 사용해 규칙 오류를 가려서는 안 됩니다.

Android에서 시작 후 곧바로 시스템이 중지하는 경우

Android 「설정」→「앱」→해당 클라이언트→「배터리」로 이동해 백그라운드 실행 허용 또는 제한 없음으로 설정합니다. 이어서 「설정」→「네트워크 및 인터넷」→「VPN」에서 연결 상태를 확인하세요. 제조사에 따라 메뉴 이름은 다를 수 있습니다. 항상 켜짐 VPN을 사용 중이라면 다른 VPN 앱이 같은 역할로 지정되어 있지 않은지도 확인해야 합니다.

구독 업데이트 후 로컬 규칙이 사라지는 경우

이는 수정 사항이 구독 생성 파일에 직접 기록되어 업데이트 과정에서 설정 전체가 덮어써졌다는 뜻입니다. 원래 구독을 복원한 뒤 기기별 규칙을 클라이언트의 오버라이드, 병합 설정 또는 별도의 Provider로 옮기세요. 공통 구독은 노드 업데이트를 담당하고 로컬 오버라이드는 고정 설정을 담당하도록 두 계층을 분리해야 지속적으로 관리할 수 있습니다.

롤백 기간 유지하기

새 클라이언트가 며칠 동안 안정적으로 실행된 뒤에 기존 디렉터리를 정리하세요. 그동안 두 클라이언트에서 시스템 프록시나 TUN을 동시에 활성화하지 마세요. 비교가 필요하면 먼저 한 클라이언트를 완전히 중지한 뒤 다른 클라이언트를 시작하고, 시스템 프록시 주소와 VPN 아이콘이 전환되었는지 확인합니다.

이전 완료 후 유지 관리 방법

이전이 끝나면 클라이언트 버전, mihomo 커널 버전, 구독 업데이트 주기와 주요 오버라이드를 기록하는 것이 좋습니다. 문제가 발생하면 최근 클라이언트 업데이트, 커널 업데이트와 구독 업데이트 시점을 먼저 비교하면 변경 범위를 빠르게 좁힐 수 있습니다. 클라이언트 UI 버전과 커널 버전은 서로 다른 개념이므로 프로토콜이나 규칙 동작을 점검할 때는 커널 버전을 우선 기록해야 합니다.

설정 파일도 읽기 쉽게 유지해야 합니다. 정책 그룹에는 안정적인 이름을 사용하고 규칙은 용도별로 나누며 Provider에는 명확한 업데이트 주기를 지정하세요. 수정하기 전에 정상적으로 시작되는 버전을 복사해 두고, DNS, TUN 또는 규칙 집합을 조정할 때는 한 번에 하나의 모듈만 변경한 뒤 로그에서 결과를 확인합니다. 이렇게 하면 나중에 다른 mihomo 클라이언트로 바꾸더라도 공통 설정을 계속 사용할 수 있습니다.

대부분의 사용자에게 이전 과정은 세 단계로 정리할 수 있습니다. 구독과 기존 YAML을 저장하고, 계속 유지보수되는 mihomo 클라이언트를 선택한 다음, 데스크톱과 Android의 기기별 매개변수를 각각 설정하세요. 구독은 노드 업데이트를 담당하고 공통 규칙은 트래픽 결정을 담당하며 로컬 오버라이드는 시스템 차이를 처리합니다. 이 경계를 지키는 방식이 기존 디렉터리 전체를 복사하는 것보다 안정적이고 이후 문제 해결도 쉽습니다.