Clash 클라이언트 선택 방법: Windows·macOS·Android·iOS 비교

SELECTION BASELINE

코어, 트래픽 적용 방식과 유지보수 상태부터 확인하기

클라이언트 인터페이스와 프록시 코어는 서로 다른 계층입니다

Clash 클라이언트는 일반적으로 그래픽 인터페이스, 설정 관리 모듈, 프록시 코어로 구성됩니다. 그래픽 인터페이스는 구독 가져오기, 프록시 그룹 전환, 연결 기록 표시를 담당하고, 코어는 설정 해석, 규칙 매칭, 프록시 연결 수립, DNS 처리를 담당합니다. 외형이 비슷한 두 클라이언트라도 포함된 코어가 다르면 지원하는 설정 필드의 범위가 달라집니다.

현재 클라이언트 선택 과정에서는 Clash Premium 호환 설정과 Clash Meta(현재 널리 사용되는 프로젝트명은 mihomo) 확장 설정을 자주 접하게 됩니다. mihomo는 기존 Clash 설정 구조를 기반으로 규칙 제공자, 프록시 제공자, TUN, DNS 분기와 더 많은 프로토콜 기능을 계속 지원합니다. 구독에 rule-providers, proxy-providers, sniffer, tun 또는 최신 DNS 필드가 포함되어 있다면, 클라이언트가 최근까지 유지보수된 mihomo 코어를 실제로 사용하는지 먼저 확인해야 합니다.

시스템 프록시와 TUN의 사용 범위

시스템 프록시는 데스크톱 플랫폼에서 가장 직접적인 트래픽 적용 방식입니다. 클라이언트가 운영체제의 HTTP 또는 SOCKS 프록시 설정을 변경하면 해당 설정을 읽는 애플리케이션이 연결을 Clash로 전달합니다. 설정이 간단하고 필요한 권한도 적지만, 일부 게임, 명령줄 도구, 샌드박스 애플리케이션과 자체 네트워크 스택을 사용하는 소프트웨어는 시스템 프록시를 우회할 수 있습니다.

TUN 모드는 가상 네트워크 인터페이스를 만들어 더 낮은 계층에서 IP 트래픽을 처리하므로 적용 범위가 대체로 넓습니다. 대신 관리자 권한, VPN 권한 또는 시스템 네트워크 확장 승인 등이 필요하며, 다른 VPN, 가상 머신 네트워크 카드, 보안 소프트웨어, 기업용 네트워크 구성 요소와 충돌할 수 있습니다. 모바일 클라이언트에 표시되는 VPN 표시는 일반적으로 시스템이 애플리케이션의 트래픽 처리를 허용하는 표준 진입점이며, 원격 VPN 프로토콜의 종류와 같은 의미는 아닙니다.

오래된 튜토리얼 화면보다 중요한 유지보수 상태

Clash for Windows, 일부 초기 macOS 클라이언트와 구형 모바일 프로젝트는 검색 결과나 예전 튜토리얼에 여전히 등장하지만, 오래된 클라이언트는 장기간 업데이트되지 않았을 수 있습니다. 구버전을 계속 사용하면 최신 설정 필드를 해석하지 못하거나, 시스템 업데이트 후 프록시 전환이 작동하지 않거나, 코어 버전이 뒤처지는 문제가 생길 수 있습니다. 선택할 때는 최근 릴리스 기록, 코어 업데이트 주기, 현재 운영체제 호환성 안내를 확인해야 하며, 다운로드 수나 오래된 글의 추천 순위만 따라서는 안 됩니다.

데스크톱에서는 mihomo를 사용하고 지속적으로 유지보수되는 그래픽 클라이언트를 우선 검토할 수 있습니다. Windows, macOS, Linux를 지원하는 Clash Verge Rev와 Clash Nyanpasu 등이 그 예입니다. Android에서는 mihomo 계열 클라이언트와 FlClash 등을 비교해 볼 수 있습니다. 특정 이름이 유일한 기준은 아니며, 버전 출처, 코어 종류, 대상 플랫폼과 필요한 기능 범위가 서로 맞는지가 핵심입니다.

PLATFORM MATRIX

Windows·macOS·Android·iOS 비교

Windows: 기능 범위가 넓어 설정 디버깅에 적합

Windows 클라이언트는 일반적으로 구독 관리, 프록시 그룹 전환, 지연 시간 테스트, 연결 목록, 로그와 오버라이드 기능을 폭넓게 제공합니다. 규칙 매칭, DNS 요청 또는 프로세스 트래픽을 확인해야 하는 사용자는 데스크톱 인터페이스에서 더 직접적으로 상태를 살펴볼 수 있습니다. 클라이언트가 mihomo를 지원한다면 필요에 따라 TUN, 프로세스 규칙, 트래픽 스니핑과 규칙 세트를 활성화할 수도 있습니다.

설치하기 전에 x64, ARM64 등 프로세서 아키텍처를 구분해야 합니다. 대부분의 Intel 및 AMD PC는 x64를 선택하고, Windows on ARM 기기는 ARM64 빌드를 우선 사용하세요. TUN을 켠 뒤 인터넷이 끊기면 가상 네트워크 카드 드라이버, 관리자 권한, 다른 VPN의 동시 실행 여부, 보안 소프트웨어의 네트워크 서비스 차단 여부를 확인해야 합니다. 웹 브라우징만 필요하다면 먼저 시스템 프록시로 기본 연결이 정상인지 확인한 후 TUN을 활성화하는 편이 좋습니다.

macOS: 칩 아키텍처와 네트워크 권한을 우선 확인

macOS 클라이언트는 일반적으로 메뉴 막대에 상주하며 시스템 프록시, 규칙 모드와 프록시 그룹을 빠르게 전환할 수 있습니다. Intel Mac은 x64 또는 x86_64 빌드, Apple 칩 기기는 arm64 또는 universal 빌드에 해당합니다. Rosetta로 일부 Intel 애플리케이션을 실행할 수 있지만, 장기적으로 사용할 클라이언트라면 네이티브 arm64 버전이 대체로 더 적합합니다.

시스템 프록시나 TUN을 처음 활성화할 때 macOS에서 관리자 암호 입력, 네트워크 확장 허용 또는 관련 시스템 권한 승인을 요구할 수 있습니다. 클라이언트를 종료한 뒤에도 시스템 프록시가 남아 있으면 브라우저에서 인터넷에 연결되지 않는 것처럼 보일 수 있습니다. 이때는 먼저 시스템 프록시를 끄거나 시스템 네트워크 설정에서 남은 항목을 삭제하세요. 회사 관리 기기에서는 구성 프로파일이 네트워크 확장 설치를 제한할 수도 있습니다.

Android: 백그라운드 유지와 앱별 프록시에 주목

Android 클라이언트는 일반적으로 시스템 VPN 인터페이스를 통해 트래픽을 처리하므로 상태 표시줄에 VPN 아이콘이 나타납니다. 모바일 환경에서 비교해야 할 핵심은 노드 지원뿐 아니라 앱별 프록시, IPv6, 핫스팟 공유, 로컬 네트워크 우회, DNS 모드와 배터리 절전 정책 대응입니다. 특정 앱은 직접 연결하고 일부 앱만 프록시를 사용하게 하려면, 클라이언트가 앱 포함 또는 제외 목록을 제공하는지 확인해야 합니다.

Android는 시스템과 제조사마다 백그라운드 관리 정책의 차이가 큽니다. 화면을 잠근 뒤 프록시가 끊기는 흔한 원인은 배터리 최적화 제한, 백그라운드 활동 차단 또는 시스템의 프로세스 자동 정리입니다. 클라이언트를 배터리 최적화 제외 대상으로 설정하고 백그라운드 실행을 허용하세요. TUN이나 복잡한 DNS 규칙을 장시간 사용하면 배터리 소모가 늘 수 있으므로, 기기 상황에 맞춰 불필요한 로그, 연결 통계와 잦은 상태 확인을 끄는 것이 좋습니다.

iOS: 데스크톱 클라이언트 이름보다 설정 형식을 먼저 확인

iOS에서 흔히 사용하는 것은 데스크톱 클라이언트를 그대로 옮긴 앱이 아니라 Clash 규칙 또는 구독 형식을 지원하는 네트워크 도구입니다. 이러한 앱은 Network Extension을 통해 트래픽을 처리하며 시스템 메모리, 백그라운드 실행과 앱 배포 규칙의 제약을 받습니다. Stash 등의 도구는 다양한 Clash 형식의 설정을 인식할 수 있고, Shadowrocket 등의 앱도 여러 노드 또는 구독 형식을 가져올 수 있지만 두 앱의 규칙 문법, 오버라이드 방식과 확장 필드 지원은 완전히 같지 않습니다.

“Clash 구독을 가져올 수 있다”는 말은 구독 내용이 변환되거나 해석될 수 있다는 뜻일 뿐, 데스크톱용 YAML을 완전히 지원한다는 의미는 아닙니다. mihomo 전용 필드, 스크립트 로직, 복잡한 규칙 제공자 또는 특정 DNS 동작이 포함된 설정은 iOS 클라이언트에서 무시되거나 수정되거나 오류가 보고될 수 있습니다. 구매 또는 설치 전에는 구독 링크가 열리는지만 보지 말고 클라이언트 문서에서 프로토콜, 규칙 유형, 원격 규칙 세트와 DNS 기능을 확인해야 합니다.

CORE COMPATIBILITY

구독 호환이 설정 전체 호환을 뜻하지는 않습니다

구독 서비스는 대체로 세 가지 유형의 콘텐츠를 반환할 수 있습니다. 전체 Clash YAML, 노드 정보만 포함한 설정, 웹 인터페이스가 클라이언트 유형에 맞춰 변환한 결과입니다. 전체 YAML에는 대개 프록시 그룹, 규칙, DNS와 규칙 제공자가 포함됩니다. 노드형 구독은 주로 프록시 서버만 제공하고 정책과 규칙은 클라이언트의 로컬 템플릿으로 생성합니다. 변환 결과는 서버가 선택한 대상 형식에 따라 달라집니다.

여러 기기에서 사용할 때 가장 안정적인 방법은 기본 구독 하나를 유지하고 플랫폼별로 별도의 오버라이드를 설정하는 것입니다. 데스크톱에서는 더 완전한 TUN, 스니핑과 프로세스 규칙을 활성화하고, 모바일에서는 필요한 프록시 그룹, 도메인 규칙과 DNS 설정만 유지할 수 있습니다. 특정 플랫폼 전용 필드를 모든 기기에서 설정을 가져오기 위한 필수 조건으로 만들지 마세요.

항목별로 확인해야 할 설정 필드

• 프록시 프로토콜: 화면에 프로토콜 이름이 표시되는지만 확인하지 말고, 클라이언트 코어가 구독에서 실제 사용하는 프로토콜과 매개변수를 지원하는지 확인하세요.
• 규칙 유형: DOMAIN, DOMAIN-SUFFIX, IP-CIDR, GEOIP, GEOSITE, RULE-SET 등의 규칙을 지원하는지 확인하세요.
• 원격 제공자: proxy-providers 또는 rule-providers를 사용할 때 클라이언트가 원격 리소스를 업데이트하고 해당 형식을 처리할 수 있는지 확인하세요.
• DNS 모드: fake-ip와 redir-host는 동작 방식이 다르며, 모바일에서는 시스템 비공개 DNS, IPv6와 다른 VPN 설정의 영향도 받습니다.
• TUN 매개변수: 네트워크 스택, 자동 라우팅, 인터페이스 감지와 DNS 하이재킹 필드의 구현은 코어 버전에 따라 달라질 수 있습니다.
• 오버라이드 방식: 클라이언트의 설정 병합, 전처리 스크립트와 로컬 패치는 일반적인 공통 형식이 아닌 경우가 많으므로 이전할 때 다시 설정해야 합니다.

다음 기본 구조는 설정 구성을 이해하는 데 도움이 되지만, 실제 프록시 그룹 이름은 구독 노드 또는 프록시 제공자와 일치해야 합니다. 규칙은 위에서부터 순서대로 매칭되며, 앞에서 일치하지 않은 연결은 마지막의 MATCH가 처리합니다.

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

dns:
  enable: true
  enhanced-mode: fake-ip

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

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

SCENARIO CHOICE

기기와 사용 환경에 맞는 클라이언트 선택

Windows 또는 macOS 한 대에서 일상적으로 사용

지속적으로 유지보수되고 최신 mihomo 코어가 내장되어 있으며 코어 버전을 명확히 표시하는 데스크톱 클라이언트를 우선 선택하세요. 기본적으로 필요한 기능은 구독 업데이트, 프록시 그룹 전환, 규칙 모드, 시스템 프록시, 연결 로그와 지연 시간 테스트입니다. 애플리케이션이 시스템 프록시를 우회할 때만 TUN을 활성화하면 권한 문제와 네트워크 충돌을 줄일 수 있습니다.

컴퓨터와 Android에서 같은 구독 사용

데스크톱에서는 YAML, 로그와 규칙 매칭을 확인하고, Android에서는 모바일 네트워크에서 앱별 트래픽을 처리하는 방식으로 역할을 나누는 것이 좋습니다. 양쪽에서 같은 노드 구독을 사용할 수 있지만 로컬 오버라이드는 각각 별도로 저장하세요. Android에서는 상태 확인 주기를 늘리고 프록시가 필요하지 않은 로컬 앱을 제외하세요. 데스크톱에서는 더 상세한 로그와 규칙 제공자 업데이트 설정을 유지할 수 있습니다.

컴퓨터와 iPhone 또는 iPad에서 같은 설정 사용

먼저 iOS 앱이 지원하는 구독 유형을 확인한 다음 직접 가져올지, 서버에서 호환 설정을 생성할지 결정하세요. 데스크톱 설정에 복잡한 mihomo 확장이 포함되어 있다면 iOS용 간소화 버전을 별도로 준비하고 지원되는 노드, 프록시 그룹과 규칙만 남기는 것이 좋습니다. 프록시 그룹 이름은 변환 과정에서 참조가 어긋나지 않도록 안정적인 영문이나 짧은 한글 이름을 사용하세요.

게임, 명령줄 도구와 시스템 프록시를 읽지 않는 앱

이런 환경에서는 대개 TUN이 필요합니다. Windows와 macOS에서는 TUN 실행 상태, 네트워크 인터페이스와 오류 로그를 표시할 수 있는 클라이언트를 선택하세요. Android와 iOS는 시스템 VPN 인터페이스를 통해 트래픽을 처리합니다. 활성화한 뒤 먼저 직접 연결 사이트, 프록시 연결 사이트와 로컬 네트워크 기기를 확인하고 대상 앱을 테스트하세요. DNS, 라우팅과 노드 문제를 한꺼번에 다루는 일을 피할 수 있습니다.

복잡한 규칙을 편집하고 연결 문제를 점검해야 하는 경우

규칙 유지보수에는 데스크톱 클라이언트가 더 적합합니다. 연결 목록에는 대상 도메인, 대상 IP, 매칭된 규칙, 사용한 정책과 아웃바운드 노드가 표시되어야 하며, 로그는 설정 해석 오류, DNS 실패, 프록시 핸드셰이크 실패와 시간 초과를 구분할 수 있어야 합니다. 모바일은 실행 결과를 확인하기에는 적합하지만 화면과 시스템 제약으로 대규모 YAML 편집 환경으로는 적합하지 않습니다.

MIGRATION CHECKLIST

설치 및 이전 점검 목록

1. 시스템 버전 확인: 클라이언트가 지원하는 최소 Windows, macOS, Android 또는 iOS 버전을 확인하세요.
2. 프로세서 아키텍처 확인: 데스크톱에서는 x64, ARM64와 universal을 구분하고 파일 이름의 운영체제 표기만 보고 선택하지 마세요.
3. 코어 유형 확인: 클라이언트 설명이나 설정 페이지에서 mihomo, 구형 Clash 코어 또는 자체 호환 구현 중 무엇을 사용하는지 확인하세요.
4. 필요한 정보 백업: 구독 주소, 로컬 규칙, 프록시 그룹 선택과 특수 DNS 설정을 저장하고 불필요한 캐시는 복사하지 마세요.
5. 기존 클라이언트 먼저 중지: 기존 클라이언트의 시스템 프록시, TUN과 시작 시 자동 실행을 끄고 두 프로그램이 동시에 네트워크 설정을 변경하지 않도록 하세요.
6. 먼저 가져온 뒤 설정 변경: 기본 구독이 정상적으로 해석되는지 확인하고 노드 하나로 연결을 테스트한 다음 오버라이드와 원격 규칙 세트를 활성화하세요.
7. 트래픽 적용을 단계적으로 활성화: 먼저 시스템 프록시를 테스트하고 필요에 따라 TUN을 활성화하세요. 모바일에서는 VPN 권한을 먼저 부여한 뒤 백그라운드 정책을 확인합니다.
8. 규칙 매칭 확인: 직접 연결해야 하는 대상과 프록시를 사용해야 하는 대상에 각각 접속해 연결 기록의 정책과 아웃바운드 결과를 확인하세요.
9. DNS 확인: 도메인은 열리지 않지만 IP 연결은 정상이라면 시스템 비공개 DNS, fake-ip, IPv6와 DNS 하이재킹 설정을 확인하세요.
10. 복구 경로 확보: 시스템 프록시를 끄는 위치와 TUN을 중지하는 방법을 기록해 두고, 네트워크가 끊기면 먼저 직접 연결 환경을 복원하세요.

최종 선택 정리

Windows 사용자는 mihomo 코어, TUN 상태 표시와 로그 기능을 우선 확인해야 합니다. macOS 사용자는 Apple 칩 네이티브 지원과 네트워크 확장 권한도 점검해야 합니다. Android 사용자는 앱별 프록시, 백그라운드 안정성과 배터리 소모를 중점적으로 비교하고, iOS 사용자는 Clash YAML, 규칙 세트와 DNS 필드를 앱이 실제로 어느 범위까지 지원하는지 먼저 확인해야 합니다.

구독을 가져와 노드만 전환하면 되는 경우에는 활발히 유지보수되고 인터페이스가 명확한 최신 버전을 선택하면 됩니다. 여러 플랫폼에서 복잡한 설정을 동기화해야 한다면 노드 구독과 플랫폼별 오버라이드를 분리하고 각 클라이언트의 설정 문서를 기준으로 삼으세요. 클라이언트 이름은 바뀔 수 있지만, 코어 기능, 시스템 트래픽 적용 방식과 설정 호환성이 장기적으로 유효한 선택 기준입니다.