Clash 원본·Meta·mihomo 커널 차이: 기능 범위와 클라이언트 선택

Clash 클라이언트가 현재 환경에 적합한지 판단할 때 소프트웨어 이름이나 화면만 봐서는 부족합니다. 실제로 연결 가로채기, 규칙 매칭, DNS 처리, 프록시 프로토콜 해석을 담당하는 것은 커널입니다. 데스크톱 클라이언트는 대개 설정, 트레이 메뉴, 시스템 프록시 전환, 로그 확인을 위한 화면일 뿐이며, 설정 항목을 인식할 수 있는지, TUN이 어떻게 작동하는지, 새 프로토콜로 연결할 수 있는지는 커널 버전에 달려 있습니다.

“Clash 원본”, “Clash.Meta”, “mihomo”는 자주 함께 언급되지만, 세 가지가 계속 동기화되며 동일한 기능을 제공하는 별도 제품인 것은 아닙니다. Clash 원본은 설정 모델과 규칙 체계의 중요한 출발점이고, Clash.Meta는 후속 확장 브랜치가 한때 사용하던 이름이며, mihomo는 해당 확장 브랜치가 이름을 바꾼 현재 프로젝트입니다. 많은 클라이언트, 설정 디렉터리, 구독 변환 템플릿에 여전히 Meta라는 표기가 남아 있어 화면에 표시된 이름과 실제 실행 커널이 다를 수 있습니다.

프로젝트 관계: 원본·Meta·mihomo는 세 개의 병렬 제품군이 아닙니다

Clash 원본은 범용 설정 모델을 정립했습니다

일반적으로 Clash 원본이라고 하면 Dreamacro가 유지관리하던 Go 언어 기반 규칙 프록시 커널과 그 설정 체계를 가리킵니다. 프록시 노드, 정책 그룹, 규칙, DNS, 인바운드 포트, 외부 컨트롤러 같은 핵심 개념이 여기서 정립되었습니다. 많은 클라이언트와 구독 서비스가 이 항목들을 그대로 사용해 왔기 때문에, 현재 다른 호환 커널을 실행하더라도 설정 파일을 흔히 Clash 설정이라고 부릅니다.

원본 오픈 소스 프로젝트는 현재 보관 처리되어 지속적인 기능 개발이 이루어지지 않습니다. 과거에는 기능 범위가 달랐던 Premium 빌드도 있었으며, 오래된 문서에서는 오픈 소스 버전, Premium 버전, 그래픽 클라이언트를 한데 묶어 설명하기도 합니다. 예전 튜토리얼을 참고할 때는 먼저 어떤 빌드를 설명하는지 확인해야 하며, 특히 구형 Premium의 동작을 모든 원본 커널의 기능으로 간주해서는 안 됩니다.

Clash.Meta는 확장 브랜치의 이전 이름입니다

Clash.Meta는 Clash의 주요 설정 구조를 이어받으면서 프록시 프로토콜, 규칙 기능, DNS, TUN, 트래픽 스니핑, 실행 제어 등을 계속 확장했습니다. 일반적인 Clash 설정을 큰 비용 없이 옮길 수 있게 하면서도 더 많은 필드를 설정 파일에서 사용할 수 있도록 하는 것이 주요 목표 중 하나였습니다. 호환 범위가 넓었기 때문에 많은 데스크톱·모바일 클라이언트가 제품명, 커널 전환 메뉴, 설정 디렉터리에 “Meta”를 직접 표기했습니다.

mihomo는 Meta 브랜치가 이름을 바꾼 현재 명칭입니다

mihomo는 Clash.Meta와 별개로 새롭게 등장한 병렬 커널이 아닙니다. 정확히는 Clash.Meta 프로젝트가 mihomo로 이름을 변경했으며 코드와 유지보수 관계도 이어졌습니다. 이 글의 기준일 현재 새 버전, 버그 수정, 새로운 설정 기능을 확인할 때는 mihomo의 최신 문서를 우선 참고해야 합니다. 오래된 화면에 “Meta 커널”이라고 표시되더라도 버전 출력을 다시 확인해야 합니다. 실제로는 mihomo를 패키징했지만 클라이언트의 표시 문구가 아직 바뀌지 않았을 수 있습니다.

기능 범위: 차이는 트래픽 가로채기 방식, 프로토콜, 규칙 처리에 집중됩니다

기본 HTTP, SOCKS, 혼합 포트, 프록시 그룹, 도메인 규칙만으로는 커널을 구분하기 어렵습니다. 대부분의 일반적인 구독은 이런 내용을 생성할 수 있습니다. 실제 선택에 영향을 주는 것은 시스템 트래픽이 커널로 들어오는 방식, DNS 요청을 처리하는 주체, 구독에 새 프록시 프로토콜이 포함되어 있는지, 규칙셋이 mihomo 확장 문법에 의존하는지입니다.

TUN과 시스템 트래픽 가로채기

시스템 프록시는 프록시 설정을 능동적으로 읽는 애플리케이션에만 영향을 줍니다. 브라우저와 일부 데스크톱 프로그램은 대체로 시스템 프록시를 사용할 수 있지만, 명령줄 프로그램, 게임, 가상 머신, 일부 스토어 앱, 자체 네트워크 스택을 구현한 소프트웨어는 이 설정을 우회할 수 있습니다. TUN 모드는 가상 네트워크 인터페이스로 더 넓은 범위의 IP 트래픽을 받아 통합 가로채기에 적합하지만, 관리자 권한, 라우팅 테이블, DNS 하이재킹, 네트워크 어댑터 충돌, 방화벽 규칙도 함께 고려해야 합니다.

Clash 오픈 소스 원본 커널, 과거 Premium 빌드, 최신 mihomo의 TUN 기능을 하나의 버전처럼 다뤄서는 안 됩니다. mihomo는 현재 비교적 완전한 TUN 설정과 다양한 프로토콜 스택 및 자동 라우팅 관련 옵션을 제공합니다. 클라이언트에서 실제로 활성화할 수 있는지는 운영체제, 서비스 모드, 권한에 따라 달라집니다. mihomo를 지원하는 클라이언트라고 해서 필요한 기능이 있다는 뜻일 뿐, 드라이버·서비스·라우팅 설정까지 자동으로 끝났다는 의미는 아닙니다.

프록시 프로토콜과 전송 매개변수

초기 Clash 설정은 당시 널리 사용되던 Shadowsocks, VMess, Trojan, SOCKS 등의 유형을 주로 다뤘습니다. mihomo는 이후 유지보수 과정에서 여러 프로토콜과 전송 매개변수를 추가하거나 확장했습니다. 구독에 새 프로토콜, 새로운 암호화 방식, 확장 전송 필드가 포함되어 있으면 구형 원본 커널이 로드 단계에서 바로 오류를 내거나 알 수 없는 필드를 무시할 수 있으며, 결과적으로 노드를 사용할 수 없게 됩니다.

여기서는 노드 목록에 표시되는지만 비교해서는 안 됩니다. 그래픽 화면이 구독을 먼저 해석해 노드를 그릴 수는 있지만, 실제 연결을 시작할 때 설정을 커널에 넘기는 경우가 많습니다. 노드가 목록에는 보이지만 속도 측정에 실패한다면, 프런트엔드는 필드를 받아들였으나 커널 버전이 해당 프로토콜을 지원하지 않는 것이 흔한 원인 중 하나입니다. 진단할 때는 커널 로그에서 해석 오류, 핸드셰이크 오류, 알 수 없는 필드 메시지를 확인해야 합니다.

규칙셋, 하위 규칙, 매칭 기능

기본 Clash 규칙은 보통 규칙 유형, 매칭 내용, 대상 정책으로 구성됩니다. 예를 들면 도메인 접미사, IP 대역, 프로세스 이름, 최종 매칭 등이 있습니다. mihomo는 이를 바탕으로 더 다양한 규칙과 규칙셋 기능을 제공하며, 설정에 따라 원격 규칙셋, 조합 논리, 하위 규칙을 구성할 수 있습니다. 대규모 설정은 이를 활용해 기본 파일의 길이를 줄이고 업데이트 주기별로 데이터를 나눌 수 있습니다.

확장 기능은 마이그레이션 제약도 가져옵니다. mihomo만 지원하는 규칙 유형을 설정에 사용한 순간, 원본으로 바로 되돌릴 수 있다고 가정해서는 안 됩니다. YAML 문법이 올바르더라도 구형 커널은 알 수 없는 규칙 때문에 시작을 거부할 수 있습니다. 여러 클라이언트와 호환해야 한다면 대상 기기에서 기능이 가장 제한적인 커널을 기준으로 삼거나, 커널별로 설정을 따로 생성해야 합니다.

DNS, 스니핑, 도메인 복원

Clash 계열 커널의 규칙 판단은 도메인에 의존하는 경우가 많지만 TUN으로 들어오는 연결에는 대상 IP만 나타날 수 있습니다. DNS 매핑, Fake IP, 트래픽 스니핑은 도메인 정보를 보완해 도메인 규칙이 계속 매칭되도록 합니다. mihomo는 리스너, DNS 서버 그룹, Fake IP 범위, 필터, 폴백, 스니핑 적용 범위 등을 포함해 관련 과정을 더 세밀하게 조정할 수 있는 필드를 제공합니다.

이 옵션은 많을수록 좋은 것이 아닙니다. 기업 내부망 도메인, 로컬 네트워크 기기, 게임 안티치트, 브라우저의 암호화 DNS, 시스템 자체의 DNS 캐시가 실제 경로를 바꿀 수 있습니다. 커널 선택은 사용할 수 있는 도구를 정할 뿐이며, 최종 설정은 네트워크 환경에 맞춰야 합니다. 문제를 해결할 때는 TUN, Fake IP, 폴백 서버를 한꺼번에 바꾸지 말고 시스템 DNS, 커널 DNS 로그, 규칙 매칭 결과, 실제 출구를 각각 확인해야 합니다.

설정 호환성: 기본 필드는 대체로 이어지지만 확장 필드의 역방향 호환은 보장되지 않습니다

원본 설정을 mihomo로 옮길 때 기본 구조는 대체로 유지할 수 있습니다. 포트, 실행 모드, 로그 수준, 프록시 목록, 정책 그룹, 일반 규칙은 익숙한 계층 구조를 그대로 사용합니다. 다음은 의도적으로 기본 기능만 사용한 예시입니다.

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

proxies:
  - name: example-node
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - example-node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,PROXY
  - MATCH,DIRECT

이런 설정은 특정 브랜치의 고급 기능을 사용하지 않으므로 마이그레이션 부담이 적습니다. 하지만 실제 구독에는 원격 규칙 제공자, 상태 확인, 인터페이스 바인딩, 트래픽 스니핑, 새 프로토콜 매개변수, 클라이언트 오버라이드가 포함될 수 있습니다. 파일 앞부분 몇 줄만 보고 전체 설정의 호환 여부를 판단할 수는 없습니다.

원본에서 mihomo로 마이그레이션

마이그레이션은 대체로 순조롭게 진행할 수 있습니다. 먼저 원래 설정으로 mihomo를 시작해 해석 및 실행 로그를 확인한 다음 새 기능을 하나씩 활성화하세요. 첫 실행부터 TUN으로 바꾸고 DNS 모드를 교체하며 규칙셋까지 다시 작성하지 마세요. 안전한 순서는 노드 연결 확인, 정책 그룹 전환 검증, 규칙 매칭 확인, 마지막으로 TUN과 DNS 처리입니다.

설정이 구독에서 제공되는 경우 클라이언트가 다운로드 후 오버라이드 내용을 추가할 수도 있습니다. 예를 들어 포트를 바꾸거나 로컬 규칙을 삽입하고, 정책 그룹을 교체하거나 LAN 접근을 활성화할 수 있습니다. 내보낸 YAML과 실행 시 설정이 완전히 같지 않을 수 있습니다. 동작이 다르면 클라이언트의 실행 설정 보기 기능을 사용하거나 외부 컨트롤러를 통해 커널이 실제로 로드한 내용을 확인해야 합니다.

mihomo에서 원본으로 되돌리기

역방향 마이그레이션에서는 확장 필드를 하나씩 삭제하고 모든 노드 프로토콜이 구형 커널에서 지원되는지 확인해야 합니다. 최상위 필드 하나만 삭제해서는 충분하지 않습니다. 호환되지 않는 내용이 프록시 노드, 규칙, DNS, TUN, 규칙 제공자, 정책 그룹 매개변수 안에 숨어 있을 수 있습니다. 원격 구독은 다음 업데이트 때 이런 내용을 다시 기록하므로, 임시 수동 수정만으로는 구독 템플릿을 조정한 것을 대신할 수 없습니다.

어떤 서버가 구형 커널에서 지원하지 않는 프로토콜만 제공한다면 설정 변환으로 이를 다른 프로토콜로 자동 변경할 수 없습니다. 구독 변환은 주로 필드 재구성, 노드 필터링, 규칙 결합을 담당할 뿐 서버가 실제로 제공하는 핸드셰이크 방식을 바꾸지는 못합니다. 이 경우 해당 프로토콜을 지원하는 mihomo 커널을 계속 사용하거나, 설정 제공처에서 호환 가능한 노드를 받아야 합니다.

클라이언트 선택: 시스템 통합을 먼저 보고 커널 버전을 확인하세요

일반 사용자는 커널을 단독으로 실행하기보다 그래픽 인터페이스가 있는 클라이언트를 설치합니다. 선택할 때는 “프런트엔드가 사용하기 편한가”와 “커널이 설정 요구 사항을 충족하는가”를 나누어 판단해야 합니다. 화면은 잘 다듬어졌지만 커널이 오래 업데이트되지 않은 클라이언트는 새 구독을 불러오지 못할 수 있습니다. 반대로 커널은 최신이지만 시스템 서비스 관리가 부족한 클라이언트는 TUN을 장기간 활성화하기에 적합하지 않을 수 있습니다.

Windows 데스크톱 환경

Windows 클라이언트에서는 mihomo 커널 버전, 서비스 모드, TUN 권한 처리, 시스템 프록시 복원, 로그 진입 경로를 중점적으로 확인해야 합니다. 브라우저와 일반 업무 프로그램만 사용한다면 시스템 프록시 모드가 대체로 관리하기 쉽습니다. 게임, 명령줄 프로그램, 스토어 앱, 시스템 프록시를 읽지 않는 프로그램까지 가로채야 한다면 TUN을 검토하세요. 활성화하기 전에 기존 DNS, 다른 가상 네트워크 어댑터, 보안 소프트웨어 상태를 기록해 두면 네트워크가 끊겼을 때 되돌리기 쉽습니다.

일부 Windows 클라이언트는 여러 커널 사이를 전환할 수 있습니다. 전환 후에는 화면만 다시 시작하지 말고 실행 로그에서 커널 이름과 버전이 실제로 바뀌었는지 확인해야 합니다. 기존 설정에 Premium 전용 필드가 있다면 클라이언트가 자동 변환하는지도 점검하세요. 시스템 프록시 포트와 커널 수신 포트가 일치해야 합니다. 그렇지 않으면 화면에는 활성화로 표시되어도 애플리케이션은 비어 있는 포트에 연결하게 됩니다.

macOS 데스크톱 환경

macOS에서는 클라이언트가 현재 프로세서 아키텍처, 시스템 확장 또는 네트워크 권한에 맞는지, 종료할 때 프록시 설정을 복원하는지 확인해야 합니다. 오래된 이름을 가진 클라이언트도 업데이트를 통해 mihomo를 패키징했을 수 있으므로 제품명만으로 커널을 판단할 수 없습니다. Apple Silicon 기기에서는 아키텍처에 맞는 빌드를 우선 사용해 호환 계층 문제를 프록시 커널 장애로 잘못 판단하지 않도록 하세요.

시스템 프록시를 사용할 때는 HTTP, HTTPS, SOCKS 항목이 클라이언트에 의해 올바르게 설정되는지 확인해야 합니다. TUN을 사용할 때는 가상 인터페이스, 기본 라우팅, LAN 접근을 점검해야 합니다. 기업 관리 기기에서는 네트워크 확장이나 관리자 승인이 제한될 수 있으며, 이는 시스템 정책의 범위이므로 설정 파일만 바꿔서는 해결되지 않습니다.

Linux 데스크톱 및 서버

Linux 데스크톱에서는 그래픽 인터페이스가 있는 mihomo 클라이언트를 선택하거나 커널을 직접 실행할 수 있습니다. 서버는 명령줄 설정과 systemd 서비스를 사용하는 편이 고정된 작업 디렉터리 지정, 권한 제한, 자동 재시작, journal을 통한 로그 확인에 유리합니다. 셸에서 HTTP_PROXY와 HTTPS_PROXY를 설정해도 해당 환경 변수를 읽는 프로그램에만 영향을 주며, 시스템 전체를 가로채는 것과는 다릅니다.

TUN 배포에는 네트워크 네임스페이스, 라우팅 규칙, 포워딩 설정, 컨테이너 네트워크도 관련됩니다. Docker 컨테이너의 요청이 호스트의 mihomo를 거치는지는 네트워크 모드와 라우팅 설계에 달려 있습니다. 서버에서는 데스크톱 클라이언트가 생성한 설정을 그대로 복사하지 않는 편이 좋습니다. 화면에서만 사용하는 상대 경로, 컨트롤러 주소, 로컬 규칙 파일이 포함되어 있을 수 있기 때문입니다.

Android 및 iOS

모바일 운영체제는 대개 시스템 VPN 인터페이스를 통해 트래픽을 가로채므로, 데스크톱보다 프런트엔드 앱이 커널 수명 주기와 백그라운드 실행을 어떻게 제어하는지가 중요합니다. 앱에 실제로 통합된 커널, 지원하는 프록시 프로토콜, 앱별 분할 라우팅 기능, 운영체제 버전을 확인해야 합니다. 모바일 클라이언트에 표시되는 “VPN”은 로컬 트래픽 진입점을 뜻할 뿐, 트래픽이 반드시 전통적인 기업용 VPN에 연결된다는 의미는 아닙니다. 이후 직결 또는 프록시 전송 여부는 규칙과 정책 그룹이 결정합니다.

iOS에서는 데스크톱용 커널 파일을 앱에 직접 넣어 실행할 수 없습니다. 앱에서 사용할 수 있는 커널 기능은 패키지된 버전과 시스템 심사 아래 구현된 방식에 따라 달라집니다. Android 역시 제조사의 백그라운드 제한, 배터리 최적화, VPN 상시 실행 정책의 영향을 받습니다. 데스크톱에서는 정상인 노드가 모바일에서 자주 끊긴다면 구독만 바꾸지 말고 운영체제의 백그라운드 제한도 함께 확인해야 합니다.

사용 환경별 선택 결론

새로 배포한다면 지속적으로 유지보수되는 mihomo를 기준으로 삼는 것이 대체로 합리적입니다. 이는 이름이 새로워서가 아니라 설정 생태계, 프로토콜 변화, 운영체제 네트워크 스택이 계속 발전하기 때문입니다. 안정적으로 실행 중인 기존 환경은 백업과 테스트 없이 즉시 교체할 필요가 없습니다. 다만 현재 커널, 클라이언트 버전, 설정 출처, 시작 매개변수를 기록해 장애가 발생했을 때 재현 조건을 찾을 수 있도록 해야 합니다.

여러 기기를 하나의 구독으로 관리한다면 주요 커널 버전을 통일하고 데스크톱과 모바일에는 플랫폼별 오버라이드를 소량만 따로 저장하는 것이 좋습니다. 공통 부분에는 노드, 정책 그룹, 규칙을 유지하고, 플랫폼 부분에서는 TUN, 수신 주소, 인터페이스 바인딩, LAN 접근을 처리하세요. 이렇게 하면 한 기기에 맞추기 위해 모든 설정에 플랫폼 전용 필드를 넣는 일을 피할 수 있습니다.

마이그레이션 실행: 변수를 최소화해 단계별로 검증

1. 현재 상태를 기록합니다. 클라이언트 버전, 커널 이름, 커널 버전, 설정 출처, 시스템 프록시 포트, TUN 활성화 여부를 저장하세요. 스크린샷은 위치를 찾는 데 도움이 되지만, 비교에는 텍스트 로그와 설정 파일이 더 적합합니다.
2. 로컬 오버라이드를 백업합니다. 구독 주소는 보통 원격 본문만 제공하며, 로컬 규칙, 정책 그룹 조정, DNS 예외는 클라이언트 데이터베이스에 저장될 수 있습니다. 업그레이드 전에 클라이언트의 내보내기 기능으로 이 내용을 보존해야 합니다.
3. 먼저 기본 프록시를 테스트합니다. TUN과 복잡한 DNS 오버라이드를 끄고 시스템 프록시 또는 명시적 SOCKS 연결로 노드 하나를 검증하세요. 노드 핸드셰이크가 성공한 뒤 정책 그룹과 규칙을 확인합니다.
4. 규칙 매칭을 확인합니다. 직결되어야 하는 대상과 프록시를 사용해야 하는 대상을 각각 방문하고, 로그에서 대상 도메인, 규칙 유형, 최종 정책을 확인하세요. 웹페이지가 열리는지만으로 예상한 출구를 사용했는지 판단할 수 없습니다.
5. DNS 설정을 활성화합니다. 커널 수신 포트가 충돌하지 않는지 확인한 다음 도메인 해석이 예상한 서버에서 처리되는지 점검하세요. Fake IP를 사용할 때는 LAN 기기, 내부망 도메인, 호환되지 않는 애플리케이션을 별도로 검증해야 합니다.
6. 마지막으로 TUN을 활성화합니다. 관리자 권한, 가상 인터페이스, 자동 라우팅, DNS 하이재킹을 확인하세요. 네트워크가 끊기면 먼저 TUN을 끄고 시스템 프록시를 복원한 뒤 로그를 읽으세요. 여러 네트워크 도구를 연달아 전환하지 마십시오.
7. 재시작 후 검증을 완료합니다. 시스템 또는 서비스를 다시 시작해 클라이언트가 설정을 복원하는지, 구독이 핵심 설정을 덮어쓰지 않는지, 시스템 프록시와 라우팅이 예상대로 구성되는지 확인하세요.

흔한 오판과 확인 방법

화면에 Meta라고 쓰여 있으니 반드시 구형 커널이다: 그렇지 않습니다. Meta는 클라이언트의 과거 명칭일 수 있습니다. 시작 로그나 커널 버전 인터페이스를 읽어 실제 바이너리를 확인해야 합니다.

구독 가져오기가 성공했으니 설정이 완전히 호환된다: 그렇지 않습니다. 프런트엔드 가져오기, 커널 해석, 노드 핸드셰이크, 규칙 실행은 서로 다른 단계입니다. 각 단계의 로그를 따로 확인해야 합니다.

mihomo로 전환하면 반드시 TUN을 켜야 한다: 그렇지 않습니다. mihomo도 HTTP, SOCKS, 혼합 포트를 지원합니다. 시스템 프록시로 요구 사항을 충족할 수 있다면 더 단순한 가로채기 방식을 계속 사용해도 됩니다.

설정 변환으로 모든 프로토콜 차이를 해결할 수 있다: 그렇지 않습니다. 변환기는 설정을 재배열할 수 있을 뿐 서버 프로토콜을 바꾸거나 구형 커널에 없는 구현을 추가할 수 없습니다.

이름이 같은 정책 그룹은 모든 기기에서 동일하게 동작한다: 반드시 그렇지는 않습니다. 상태 확인 간격, 지연 측정 주소, 네트워크 권한, 커널 버전이 자동 선택 결과를 바꿀 수 있습니다. 그룹 유형, 후보 노드, 테스트 매개변수를 비교해야 합니다.

결론: 새 배포는 mihomo를 기준으로, 기존 환경은 호환성을 확인하며 마이그레이션

Clash 원본은 널리 사용된 설정 및 규칙 모델을 제공했지만 프로젝트는 이미 보관 처리되었습니다. Clash.Meta는 확장 브랜치가 한때 사용하던 이름이며, mihomo는 해당 브랜치의 현재 명칭입니다. Meta와 mihomo를 동시에 경쟁하는 구형·신형 커널로 보면 버전을 잘못 판단하게 됩니다. 프로젝트의 흐름, 클라이언트 패키지 버전, 실행 로그를 함께 확인해 실제 커널을 판단해야 합니다.

선택할 때 기본 시스템 프록시, 단순한 규칙, 전통적인 노드 프로토콜은 커널 요구 사항이 낮습니다. 반면 새 프로토콜, 복잡한 규칙셋, 세밀한 DNS, 트래픽 스니핑, TUN 가로채기는 최신 mihomo 기능에 더 크게 의존합니다. 새로 설치한다면 지속적으로 유지보수되며 mihomo 통합을 명확히 밝힌 클라이언트를 우선 선택하세요. 기존 환경은 먼저 상태를 기록하고 최소 설정으로 마이그레이션을 테스트한 뒤 DNS, 규칙셋, TUN을 단계적으로 복원해야 합니다.

최종 판단 기준은 클라이언트 이름이나 구독 파일을 가져올 수 있는지가 아닙니다. 커널이 설정을 완전히 해석하고, 노드 연결을 안정적으로 수립하며, 규칙을 예상대로 매칭하고, 시스템 재시작 후 네트워크 상태를 복원할 수 있는지가 기준입니다. 이 네 가지를 중심으로 검증하면 커널 업그레이드를 한 번에 교체하는 작업이 아니라 관찰과 복구가 가능한 단계별 엔지니어링 작업으로 나눌 수 있습니다.