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

Clash 클라이언트 서비스 종료 후 마이그레이션: 설정 내보내기, 대체 클라이언트와 구독 전환

클라이언트 유지보수가 종료된 후 기존 설정과 구독을 내보내고, 플랫폼별로 지원이 계속되는 대체 클라이언트를 선택한 뒤 규칙과 DNS를 점검해 전환 중 직접 연결을 방지하세요.

먼저 이전해야 할 대상이 설치 파일 하나가 아님을 확인하세요

Clash 클라이언트 유지보수가 중단된 뒤 실제로 옮겨야 하는 것은 구독 주소, 로컬 설정, 정책 선택, 시스템 프록시 상태입니다. 기존 프로그램 자체를 그대로 복사할 필요는 대개 없습니다. Clash for Windows를 예로 들면 프로젝트 업데이트가 중단된 후에도 이미 설치된 버전은 한동안 작동할 수 있지만, 커널, 프로토콜 구현, 시스템 호환성, 보안 수정은 더 이상 개선되지 않습니다. 시스템 업그레이드, 구독 형식 변경, 인증서 정책 조정으로 정상적으로 작동하던 설정이 갑자기 무효화될 수 있습니다.

마이그레이션 전에는 “클라이언트”와 “커널”을 구분해야 합니다. 클라이언트는 설정 관리, 트레이 메뉴, 시스템 프록시, 로그와 UI를 담당하고, 커널은 포트 수신, 규칙 해석, 프록시 연결을 담당합니다. 최신 클라이언트는 대체로 mihomo 커널을 사용하며, Clash Meta의 기능을 계승해 더 많은 프록시 프로토콜, 규칙 세트, 트래픽 스니핑과 완성도 높은 TUN 설정을 지원합니다. 기존 클라이언트의 클래식 Clash 설정은 대부분 mihomo로 가져올 수 있지만, 반대 방향의 호환성은 보장되지 않습니다.

마이그레이션 원칙

먼저 구독 주소와 현재 YAML을 저장한 다음 새 클라이언트를 설치하고 오프라인 점검을 완료하세요. 새 클라이언트가 시스템 프록시 또는 TUN을 인계할 수 있는지 확인한 뒤 마지막으로 기존 클라이언트를 종료합니다. 두 커널이 같은 포트를 동시에 수신하도록 설정하지 마세요.

저장해야 할 네 가지 항목

노드 이름만 복사하는 것으로는 충분하지 않습니다. 노드는 구독에서 다시 생성할 수 있지만, 직접 작성한 규칙, 오버라이드 스크립트, 프록시 그룹 선택과 DNS 제외 항목은 대개 클라이언트 로컬에 저장됩니다. 마이그레이션 후 “노드 속도 테스트는 되지만 웹페이지가 열리지 않는” 경우는 이런 로컬 설정이 동기화되지 않았기 때문인 경우가 많습니다.

구독과 설정 내보내기: 기존 클라이언트를 열 수 있을 때의 처리 순서

1단계: 구독 출처와 업데이트 시간 기록

기존 클라이언트의 설정 또는 Profiles 페이지를 열고 설정 이름, 구독 주소, 마지막 업데이트 시간과 자동 업데이트 간격을 하나씩 기록하세요. UI에 “구독 링크 복사”, “설정 편집” 또는 “폴더에서 보기”가 있다면 해당 메뉴를 우선 사용합니다. 로그에서 링크를 잘라내지 마세요. 로그에서는 토큰이 일부 생략되거나 리디렉션된 임시 주소가 표시될 수 있습니다.

마이그레이션 기록은 로컬 텍스트 파일 하나로 정리하는 것이 좋으며, 최소한 다음 필드를 포함하세요. 토큰 부분은 클라우드 드라이브의 공개 폴더, 코드 저장소 또는 스크린샷 공유 플랫폼에 올리지 마세요.

설정 이름: 일상 규칙
구독 출처: https://example.invalid/api/v1/client/subscribe?token=숨김
기존 클라이언트 업데이트 간격: 1440분
모드: rule
혼합 포트: 7890
외부 컨트롤 포트: 9090
자주 사용하는 정책: 노드 선택 → 자동 선택
로컬 오버라이드: dns.yaml、rules.yaml

2단계: 현재 적용 중인 YAML 내보내기

기존 클라이언트에서 “설정 편집”, “설정 파일 보기” 또는 “설정 디렉터리 열기”를 찾아 현재 적용 중인 YAML을 복사하세요. Windows의 일부 구버전 Clash 클라이언트는 사용자 디렉터리의 .config/clash에 데이터를 저장하며, macOS와 Linux의 구형 도구도 ~/.config/clash를 자주 사용합니다. 분기별로 애플리케이션 데이터 디렉터리를 사용할 수도 있으므로 UI의 “디렉터리 열기” 결과를 기준으로 삼고, 고정 경로만 보고 검색하지 마세요.

백업할 때는 기본 설정뿐 아니라 기본 파일이 참조하는 다른 리소스도 확인해야 합니다. 다음 필드는 설정이 외부 파일이나 원격 콘텐츠에 의존한다는 의미입니다.

3단계: 실행 캐시가 아니라 오버라이드 내용 저장

GeoIP 데이터베이스, 규칙 세트 캐시, 구독 캐시와 실행 로그는 새 클라이언트가 다시 내려받을 수 있습니다. 실제로 보존해야 하는 것은 사용자가 직접 편집한 오버라이드 파일입니다. 기존 클라이언트에 “전역 확장 설정”, “Mixin”, “사전 처리”, “오버라이드” 또는 “스크립트” 기능이 있다면 원문을 항목별로 복사하고, 기본 설정의 앞에서 실행되는지 뒤에서 실행되는지도 기록하세요. 실행 순서가 다르면 최종 dns, rules와 proxy-groups 결과도 달라집니다.

플랫폼별로 계속 유지보수되는 클라이언트 선택

대체 클라이언트를 선택할 때 UI만 비교하지 마세요. 먼저 운영체제 버전, 커널 유형, 설정 가져오기 방식, TUN 권한 절차와 업데이트 경로를 확인해야 합니다. 기존 Clash 설정을 보유한 사용자라면 mihomo 커널을 사용하고 URL과 로컬 YAML 가져오기를 지원하며 실제 실행 설정을 확인할 수 있는 클라이언트가 일반적으로 마이그레이션 비용이 낮습니다.

플랫폼 마이그레이션 중점 선택 시 확인할 항목
Windows 시스템 프록시, 서비스 모드, TUN 드라이버 기존 프록시를 정리할 수 있는지, mihomo를 지원하는지, 실행 로그를 제공하는지
macOS 네트워크 확장, 관리자 권한 승인, 키체인 알림 시스템 버전 요구 사항, TUN 승인 경로, 종료 시 프록시 복원 여부
Android VPN 권한, 배터리 최적화, 백그라운드 유지 로컬 설정, 앱별 분기, VPN 상시 사용을 지원하는지
Linux 데스크톱 프록시, 권한, 투명 프록시 배포판 아키텍처, 커널 권한, 트레이와 자동 시작 방식

FlClash는 Windows, macOS, Linux와 Android에서 사용할 마이그레이션 대상이 될 수 있습니다. 구독 설정, 로컬 설정, 시스템 프록시와 TUN 관련 메뉴를 제공하므로 기존 Clash 설정을 mihomo 실행 환경으로 옮기기에 적합합니다. 설치 전에는 다운로드 페이지에 표시된 운영체제와 아키텍처를 확인하세요. 예를 들어 Windows의 x64, Linux의 x64 또는 arm64를 확인해 아키텍처 불일치를 설정 오류로 오해하지 않도록 합니다.

두 클라이언트가 동시에 네트워크를 인계하지 않도록 하세요

기존 클라이언트와 새 클라이언트를 동시에 실행할 때 가장 흔한 충돌은 포트 사용입니다. 많은 Clash 설정이 HTTP, SOCKS 또는 혼합 포트로 7890을 사용하고, 외부 컨트롤러에는 9090을 자주 사용합니다. 기존 커널이 계속 수신 중이면 새 커널 로그에 address already in use 또는 바인딩 실패가 나타납니다.

  1. 기존 클라이언트에서 시스템 프록시와 TUN을 끄세요.
  2. 기존 클라이언트를 완전히 종료하고 트레이 아이콘이 사라졌는지 확인하세요.
  3. Windows에서는 터미널에서 netstat -ano | findstr :7890을 실행해 포트를 확인할 수 있습니다.
  4. macOS와 Linux에서는 lsof -i :7890을 실행해 포트를 사용하는 프로세스를 확인할 수 있습니다.
  5. 포트가 해제된 것을 확인한 뒤 새 클라이언트를 시작하세요.

짧은 시간 동안 설정을 병렬 비교해야 한다면 새 클라이언트의 혼합 포트를 일시적으로 7891로 바꿀 수 있지만, 시스템 프록시 두 개 또는 TUN 두 개를 동시에 켜지는 마세요. 테스트가 끝나면 포트를 통일해 브라우저, 터미널과 개발 도구가 서로 다른 커널을 가리키지 않도록 합니다.

FlClash로 가져오기: 구독 우선, 로컬 YAML은 백업 수단

구독 URL로 가져오기

FlClash를 시작한 뒤 “설정” 페이지로 이동해 URL에서 설정 추가를 선택하고 저장해 둔 구독 주소를 붙여 넣어 업데이트하세요. 가져오기가 완료되어도 시스템 프록시를 바로 켜지 말고 설정에 노드, 프록시 그룹과 규칙이 생성되었는지 먼저 확인합니다. 정상적인 구독에는 최소한 프록시 노드, 하나 이상의 정책 그룹과 규칙 목록이 표시되어야 합니다. 노드만 있고 규칙이 없다면 전체 Clash 설정이 아닌 노드 구독일 수 있습니다.

자동 업데이트 간격은 구독 서비스의 변경 빈도에 맞춰 설정할 수 있습니다. 일상적인 사용에는 1440분, 즉 하루 한 번을 권장하며 노드 변경이 잦다면 360분으로 설정할 수 있습니다. 간격이 너무 짧으면 요청 횟수가 늘고 구독 서비스의 빈도 제한에 걸릴 수 있습니다. 마이그레이션 당일에는 먼저 수동 업데이트를 실행해 응답 내용이 유효한지 확인한 뒤 자동 업데이트를 활성화하세요.

로컬 YAML 가져오기

기존 구독 주소가 이미 만료되었지만 기존 클라이언트에 현재 설정이 표시된다면 백업한 YAML을 먼저 가져올 수 있습니다. 다만 로컬 YAML에는 내보낸 시점의 노드와 규칙 스냅샷만 저장되며, 서버의 이후 변경 사항을 자동으로 가져오지는 못합니다. 네트워크가 복구되면 유효한 구독으로 교체하거나 노드와 규칙을 직접 관리하는 설정으로 옮기세요.

가져오기 전에 mihomo의 설정 검사 명령으로 문법을 확인할 수 있습니다. 시스템에 독립 실행형 mihomo 파일이 있다면 터미널에서 다음을 실행하세요.

mihomo -t -f ./config.yaml

검사를 통과했다는 것은 YAML을 파싱할 수 있다는 뜻일 뿐, 모든 원격 규칙 세트, 노드 주소와 DNS 서버에 접근할 수 있다는 의미는 아닙니다. 들여쓰기 오류가 표시되면 YAML에서 Tab이 아닌 공백을 사용했는지 확인하세요. 중복 키 오류가 표시되면 설정을 병합하는 과정에서 같은 수준의 dns 또는 rules 필드가 두 개 생기지 않았는지 확인합니다.

매개변수 경로 확인

가져온 후 “설정” → “매개변수 설정”으로 이동해 실행 모드, 혼합 포트, LAN 접근과 외부 컨트롤 설정을 확인하세요. 설정 페이지는 구독 내용을 담당하고 매개변수 설정은 클라이언트 실행 방식을 담당하므로 둘을 혼동하지 않아야 합니다. 설정 파일에 mixed-port: 7890이 명시되어 있는데 UI에서 다른 포트를 설정했다면 클라이언트가 최종 생성한 실행 설정과 로그를 기준으로 삼으세요.

첫 실행 권장 사항

먼저 규칙 모드를 사용하고 TUN은 끈 상태에서 시스템 프록시만 활성화해 기본 연결을 테스트하세요. HTTP와 HTTPS 트래픽이 정상임을 확인한 뒤 TUN, 앱별 프록시 또는 LAN 접근을 설정합니다. 이렇게 하면 구독 문제와 가상 네트워크 어댑터 문제를 분리해 확인할 수 있습니다.

마이그레이션 후 반드시 확인할 규칙, DNS와 TUN

규칙 순서가 유지되었는지

Clash 규칙은 위에서 아래로 매칭되며 일치하면 검색을 중단합니다. 마이그레이션 과정에서 모든 규칙이 남아 있어도 순서가 바뀌면 결과가 달라집니다. 최종 규칙에서 LAN과 직접 연결 도메인을 먼저 처리하고, 그다음 서비스 규칙과 프록시 규칙을 처리한 뒤 마지막에 기본 규칙을 두었는지 확인하세요. 전형적인 구조는 다음과 같습니다.

rules:
  - DOMAIN-SUFFIX,example.cn,DIRECT
  - DOMAIN-KEYWORD,streaming,미디어 정책
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택

MATCH는 마지막에 있어야 합니다. 앞에 배치하면 뒤의 규칙은 절대 적용되지 않습니다. 마이그레이션 후에는 프록시 그룹 이름이 규칙의 세 번째 항목과 공백, 대소문자와 문자까지 완전히 일치하는지도 확인하세요. 규칙은 “노드 선택”을 가리키는데 프록시 그룹 이름이 “프록시 선택”으로 바뀌면 커널에서 정책을 찾을 수 없다고 보고합니다.

DNS가 기존 작동 모드를 유지하는지

mihomo에서 자주 사용하는 DNS 향상 모드는 fake-ip와 redir-host입니다. 기존 클라이언트가 fake-ip을 사용했다면 새 클라이언트에서 검토 없이 모드를 변경하지 마세요. 대표적인 Fake IP 주소 풀은 198.18.0.1/16이며, 이 대역은 벤치마크 테스트용이므로 실제 공인 IP 주소로 취급해서는 안 됩니다. 도메인이 198.18.x.x로 해석된다고 해서 DNS 장애라는 뜻은 아닙니다.

다음 필드를 중점적으로 확인하세요.

마이그레이션 후 프록시 노드 도메인만 조회에 실패한다면 먼저 proxy-server-nameserver를 확인하세요. 이 필드는 프록시 서버 자체의 도메인을 조회하는 데 사용되며, 아직 연결되지 않은 프록시에 의존하면 조회 루프가 발생할 수 있습니다. 테스트할 때는 로그에서 DNS, lookup, timeout과 노드 도메인을 검색하세요.

TUN 모드는 단계적으로 활성화

TUN은 시스템 프록시보다 더 많은 트래픽을 인계하며, 운영체제의 프록시 설정을 읽지 않는 앱도 포함합니다. Windows에서 처음 활성화할 때는 관리자 권한과 가상 네트워크 어댑터 구성 요소가 필요할 수 있고, macOS에서는 네트워크 확장을 승인해야 하며, Android에서는 VPN 연결 권한 승인 화면이 표시됩니다. 마이그레이션 시에는 먼저 일반 시스템 프록시가 작동하는지 확인한 뒤 TUN을 켜세요.

활성화한 후 auto-route, strict-route, DNS 하이재킹과 인터페이스 선택을 확인하세요. LAN 장치에 접근할 수 없다면 사설 네트워크 대역이 잘못 프록시로 전송되고 있지 않은지 먼저 확인합니다. 대표적인 사설 주소는 10.0.0.0/8, 172.16.0.0/12와 192.168.0.0/16입니다. 기업 VPN과 TUN을 함께 실행하면 기본 경로를 두고 충돌할 수도 있으므로 조직 네트워크 요구 사항에 따라 대상 대역을 직접 연결로 유지하세요.

원활한 전환을 위한 검증 목록

“가져오기 성공”은 클라이언트가 설정을 받아들였다는 뜻일 뿐입니다. 마이그레이션을 실제로 완료하려면 시스템 프록시, 규칙 매칭, DNS, 구독 업데이트와 종료 후 복원을 확인해야 합니다. 아래 순서대로 실행하고 각 단계가 통과된 후 다음 단계로 넘어가는 것을 권장합니다.

  1. 커널 시작: 로그에 포트 사용 중, YAML 파싱 실패 또는 규칙 그룹 누락이 없어야 합니다.
  2. 노드 테스트: 지연 시간이 안정적인 노드를 하나 선택해 TCP 또는 URL 테스트를 진행하세요. 지연 시간은 테스트 대상에 도달할 수 있음을 나타낼 뿐 모든 웹사이트에 접근할 수 있다는 뜻은 아닙니다.
  3. 시스템 프록시: 시스템 프록시를 켜고 브라우저 트래픽이 연결 기록에 표시되는지 확인하세요.
  4. 규칙 매칭: 직접 연결되어야 하는 대상과 프록시를 사용해야 하는 대상을 각각 방문하고 로그의 정책 그룹 이름이 예상과 일치하는지 확인하세요.
  5. DNS 확인: 지속적인 조회 시간 초과가 없는지, LAN 도메인과 자주 사용하는 사이트가 모두 해석되는지 확인하세요.
  6. 구독 업데이트: 한 번 수동 업데이트하고 소요 시간과 응답 상태를 기록해 설정이 빈 내용으로 덮어써지지 않는지 확인하세요.
  7. TUN 테스트: 시스템 프록시가 통과된 후 TUN을 켜고 시스템 프록시를 읽지 않는 앱을 테스트하세요.
  8. 종료 후 복원: 새 클라이언트를 종료한 뒤 운영체제의 프록시 설정이 복원되고 브라우저가 종료된 127.0.0.1:7890을 더 이상 가리키지 않는지 확인하세요.

전환 중 트래픽 우회 방지

업무 환경에서 모든 외부 트래픽이 반드시 프록시를 거쳐야 한다면 마이그레이션 중 “빠른 전환”에 기대어 운에 맡기지 마세요. 보호가 필요한 업무 앱의 연결을 먼저 끊거나 일시적으로 네트워크를 종료한 뒤, 새 클라이언트에서 설정을 불러오고 시스템 프록시 또는 TUN을 활성화한 다음 연결을 복구할 수 있습니다. 브라우저의 기존 장기 연결, 다운로드 작업과 메신저 연결은 프록시 전환만으로 반드시 다시 연결되지 않으므로 관련 앱을 직접 재시작하세요.

Android에서는 시스템 VPN 설정에서 “항상 켜짐 VPN”과 “VPN을 사용하지 않는 연결 차단”을 확인할 수 있습니다. 실제 항목 이름은 제조사에 따라 다릅니다. Windows와 macOS에서는 기존 클라이언트 종료 후 수동 프록시가 남아 있는지도 확인해야 합니다. 시스템 프록시 주소가 여전히 127.0.0.1을 가리키는데 해당 포트를 수신하는 프로세스가 없다면 일반적으로 모든 브라우저 페이지가 열리지 않습니다.

자주 발생하는 마이그레이션 오류와 해결 방법

구독 업데이트는 성공했지만 노드 목록이 비어 있음

먼저 구독 응답이 완전한 Clash YAML인지 확인하세요. 일부 서비스는 User-Agent에 따라 다른 형식을 반환하며 로그인 페이지, 오류 JSON 또는 노드 링크만 포함된 텍스트를 반환할 수도 있습니다. 새 클라이언트의 구독 설정에서 호환되는 요청 방식을 선택해 보세요. 서비스에서 전용 User-Agent를 명시적으로 요구한다면 안내에 따라 설정합니다. 웹페이지의 계정 센터 주소를 구독 URL로 사용하지 마세요.

노드는 사용할 수 있지만 모든 트래픽이 직접 연결됨

실행 모드가 direct가 아닌지 확인하고 “설정” → “매개변수 설정”에서 모드가 규칙 모드인지 확인하세요. 그런 다음 규칙 마지막에 MATCH가 있는지, 해당 규칙이 가리키는 프록시 그룹에서 현재 DIRECT를 선택하고 있지는 않은지 확인합니다. 일부 설정은 정책 그룹 상태를 기억하지만 새 클라이언트는 처음 가져올 때 그룹의 첫 번째 항목을 사용할 수 있어 둘이 다를 수 있습니다.

웹페이지는 열리지만 명령줄 도구가 프록시를 사용하지 않음

시스템 프록시는 주로 운영체제 설정을 따르는 프로그램에 영향을 줍니다. 명령줄 도구는 HTTP_PROXY, HTTPS_PROXY 또는 ALL_PROXY를 명시적으로 설정해야 할 수 있으며 TUN으로 인계할 수도 있습니다. 혼합 포트가 7890이라면 임시 테스트에서 프록시 주소를 http://127.0.0.1:7890으로 설정할 수 있습니다. 테스트가 끝나면 터미널 환경 변수를 정리해 클라이언트 종료 후에도 명령이 사용할 수 없는 포트를 가리키지 않도록 하세요.

TUN을 켠 후 LAN 장치에 연결할 수 없음

먼저 TUN을 끄고 문제가 라우팅 인계 때문에 발생했는지 확인한 다음, 연결 기록에서 프린터, NAS 또는 라우터 주소에 적용된 정책을 살펴보세요. 사설 네트워크 대역은 일반적으로 직접 연결해야 하지만 기업 네트워크는 다른 주소 범위를 사용할 수 있습니다. TUN 설정을 모두 삭제하지 말고 실제 네트워크 대역에 맞춰 직접 연결 규칙을 추가하며, 엄격한 라우팅과 다른 VPN의 충돌도 확인하세요.

마이그레이션 후 기존 클라이언트를 삭제해도 될까요

최소 한 번의 구독 업데이트, 한 번의 시스템 재부팅과 한 번의 TUN 테스트를 완료한 뒤 기존 클라이언트를 제거하는 것이 안전합니다. 제거 전에는 YAML과 구독 기록을 보관하되 기존 클라이언트의 자동 시작은 더 이상 유지하지 마세요. Windows에서는 “설정” → “앱” → “시작 프로그램”에서 시작 항목을 확인하고, macOS에서는 “시스템 설정” → “일반” → “로그인 항목 및 확장 프로그램”에서 기존 프로그램의 백그라운드 실행 허용 여부를 확인하세요.

실행 가능한 마이그레이션 순서

설정이 단순하다면 전체 마이그레이션을 약 20~40분 안에 완료할 수 있습니다. 사용자 지정 규칙 세트, 기업 VPN과 TUN이 포함된 환경은 별도의 테스트 시간을 확보해야 합니다. 아래 순서대로 진행하면 롤백 비용을 줄일 수 있습니다.

  1. 기존 클라이언트에서 구독 URL을 복사하고 현재 YAML과 모든 오버라이드 파일을 내보냅니다.
  2. 모드, 포트, 정책 그룹 선택, DNS 모드와 TUN 스위치를 기록합니다.
  3. 시스템 아키텍처에 맞는 새 클라이언트를 다운로드하고 자동 시작은 잠시 활성화하지 않습니다.
  4. 기존 클라이언트의 시스템 프록시와 TUN을 끈 다음 기존 프로세스를 완전히 종료합니다.
  5. FlClash에 구독 URL을 가져옵니다. 주소가 만료된 경우에만 로컬 YAML을 가져옵니다.
  6. 프록시 그룹, 규칙 수, DNS 필드와 원격 규칙 세트 상태를 확인합니다.
  7. 먼저 시스템 프록시를 켜 브라우저와 규칙 매칭을 확인한 뒤 TUN을 활성화합니다.
  8. 구독을 수동으로 업데이트하고 시스템을 재부팅한 뒤 한 번 더 테스트합니다.
  9. 기존 클라이언트의 자동 시작을 끄고 새 클라이언트가 안정적으로 작동하는 것을 확인한 뒤 기존 프로그램을 제거합니다.

마이그레이션의 핵심은 기존 디렉터리를 새 디렉터리로 옮기는 것이 아니라 검증 가능한 설정 체인을 다시 구축하는 데 있습니다. 구독이 업데이트되고, YAML이 mihomo에서 파싱되며, 규칙이 존재하는 정책 그룹을 가리키고, DNS가 노드와 대상 도메인을 조회하고, 시스템 프록시와 TUN을 하나의 클라이언트만 인계해야 합니다. 항목별로 확인하면 클라이언트 유지보수가 중단되어도 모든 규칙을 다시 만들 필요가 없고 기존 구독 사용도 중단되지 않습니다.

FlClash 다운로드 플랫폼별 클라이언트 보기