선택 결론: macOS와 iOS를 구분하고 설정 호환성을 확인하세요
Apple Silicon Mac에서는 arm64 빌드를 제공하고 커널 정보를 투명하게 공개하는 클라이언트를 우선 고려하세요. iPhone·iPad에서는 구독 형식과 네트워크 확장 지원 여부를 먼저 확인해야 합니다. Clash 스타일의 프록시 그룹과 규칙 구성을 유지하려면 Mac에서는 Clash Verge Rev, FlClash 등 mihomo 기반 GUI 클라이언트를, iOS에서는 Stash를 우선 살펴볼 수 있습니다. Shadowrocket과 Surge도 Apple 플랫폼에서 널리 쓰이는 프록시 도구지만, 전체 Clash YAML을 그대로 실행할 수 있다고 단정해서는 안 됩니다.
‘Clash 애플판’은 사용 목적을 나타내는 검색어이지, Mac과 iPhone을 모두 지원하는 하나의 공식 앱 이름은 아닙니다. GUI 클라이언트, 프록시 커널, 구독 설정은 서로 다른 계층입니다. 클라이언트는 연결과 설정을 관리하고, 커널은 프로토콜과 규칙을 처리하며, 구독은 노드와 경우에 따라 정책 설정을 제공합니다. 선택할 때 이 세 계층을 구분해야 문제가 가져오기, 구문 분석, 연결 중 어디에서 발생했는지 파악할 수 있습니다.
- 브라우저와 일반 데스크톱 앱만 사용할 때: 먼저 macOS 시스템 프록시만으로 충분한지 확인하세요. 기능이 많다는 이유만으로 TUN을 바로 켤 필요는 없습니다.
- 터미널, 게임 또는 시스템 프록시를 따르지 않는 앱을 사용할 때: 스위치 유무만 보지 말고 TUN, UDP, DNS, 라우팅 제어를 확인하세요.
- Mac과 iPhone에서 같은 규칙을 사용할 때: 두 플랫폼이 공통으로 지원하는 설정부터 선택한 다음, 플랫폼별 오버라이드 파일을 따로 관리할지 결정하세요.
주요 클라이언트 비교: 커널·설정·사용 방식
아래 내용은 각 프로젝트의 용도와 사용 범위를 비교한 것이며, 특정 설치 파일의 버전을 영구적인 기준으로 삼지 않습니다. 최소 시스템 요구 사항, 내장 커널 버전, 앱 스토어 제공 지역은 설치하려는 버전의 릴리스 노트나 앱 상세 페이지에서 확인하세요.
| 클라이언트 | 플랫폼 및 커널 특징 | 설정 및 트래픽 처리 방식 | 추천 사용 상황 |
|---|---|---|---|
| Clash Verge Rev | macOS 등 데스크톱 플랫폼, mihomo 사용 | Clash 스타일 YAML, 시스템 프록시 및 TUN | 구독 관리, 규칙 확인, 연결 내역이 필요한 경우 |
| FlClash | mihomo 기반 크로스 플랫폼 GUI 클라이언트 | Clash 스타일 설정 지원. 데스크톱 트래픽 처리 기능은 빌드별 확인 필요 | 여러 기기에서 비슷한 방식으로 사용하고 싶은 경우 |
| ClashX Meta | macOS 메뉴 막대 클라이언트, Meta 계열 | Clash 스타일 설정 지원. 강화된 트래픽 처리 기능은 버전별 확인 필요 | 메뉴 막대에서 조작하고 유지 관리 상태를 직접 확인할 수 있는 경우 |
| Stash | iOS·iPadOS 프록시 앱, 독자 구현 | Clash 스타일 YAML 지원, 시스템 네트워크 확장으로 트래픽 처리 | 프록시 그룹과 규칙 구성을 그대로 이어가고 싶은 경우 |
| Shadowrocket | iOS·iPadOS 프록시 앱, mihomo 클라이언트는 아님 | 여러 노드 구독 지원, 자체 설정 및 규칙 체계 사용 | 주로 노드를 가져오고 휴대폰 규칙은 별도로 관리할 경우 |
| Surge | macOS·iOS 네트워크 도구, 독자 구현 | 자체 설정 형식 사용, 세밀한 정책 및 네트워크 진단 기능 제공 | 상세한 진단 기능이 필요하고 설정 구문을 옮길 의향이 있는 경우 |
Stash, Shadowrocket, Surge의 구매 방식, 지역별 제공 여부, 라이선스 범위는 스토어나 제품 페이지에서 확인하세요. macOS와 iOS 라이선스가 서로 호환된다고 가정해서도 안 됩니다. Clash Verge Rev와 FlClash는 오픈 소스라 구현과 문제 기록을 살펴보기 쉽지만, 오픈 소스라는 사실만으로 현재 버전의 호환성 테스트를 대신할 수는 없습니다.
Apple Silicon arm64: 설치 파일과 커널 버전을 각각 확인
Mac 아키텍처를 확인하는 두 가지 방법
‘Apple 메뉴’ → ‘이 Mac에 관하여’를 여세요. Apple M 시리즈 칩이 표시되면 arm64, aarch64 또는 Apple Silicon으로 표시된 빌드를 선택하세요. Intel 프로세서라면 x86_64 또는 x64 빌드를 선택하면 됩니다. Universal 빌드에는 두 아키텍처가 모두 포함될 수 있지만, 지원되는 운영체제는 릴리스 노트에서 확인해야 합니다.
‘응용 프로그램’ → ‘유틸리티’ → ‘터미널’에서 아래 명령을 실행해도 됩니다. Apple Silicon에서 네이티브로 실행 중인 터미널은 보통 arm64를 출력합니다. 터미널이 Rosetta 변환 환경에서 실행 중이면 출력이 변환 환경을 반영할 수 있으므로, 하드웨어 확인은 ‘이 Mac에 관하여’를 기준으로 하세요.
uname -m
설치 후 ‘활성 상태 보기’를 열어 클라이언트 프로세스의 ‘종류’를 확인하면 Apple 아키텍처로 실행 중인지 판단하는 데 도움이 됩니다. GUI와 커널은 별도 프로세스인 경우가 많으므로 문제를 진단할 때 둘 다 확인하세요. GUI가 실행된다고 해서 커널도 올바른 아키텍처라고 단정할 수는 없습니다.
앱 이름만 기록하지 말고 GUI와 커널 버전을 각각 확인하세요
Clash 원본, 과거 Premium 브랜치, Clash Meta/mihomo는 같은 기능이 계속 함께 업데이트되는 하나의 계열로 볼 수 없습니다. Clash Meta는 이후 mihomo라는 이름으로 개발을 이어가고 있습니다. 과거 Clash 원본이나 Premium 빌드를 새 프로토콜 지원을 위한 기본 선택으로 간주해서는 안 됩니다. 클라이언트가 실행되더라도 오래된 커널은 새 설정 필드를 인식하지 못할 수 있습니다.
- 클라이언트의 ‘정보’ 또는 버전 정보 화면에서 GUI 버전을 확인하고 전체 버전 번호와 빌드 표기를 기록하세요.
- 커널 관리, 실행 로그 또는 커널 정보 화면에서 커널 이름과 전체 버전 번호를 확인하세요. 메뉴 이름은 클라이언트마다 다를 수 있습니다.
- 해당 커널 버전의 문서를 참고해
rule-providers,proxy-providers, DNS, 필요한 프로토콜 옵션을 확인하세요. 앱 아이콘만 보고 지원 여부를 추측하지 마세요.
이 글에는 확인되지 않은 ‘최신 버전 번호’를 기재하지 않습니다. GUI와 커널 업데이트는 서로 다른 주기로 배포될 수 있습니다. 업데이트 전에는 작동하던 설치 파일과 설정 사본을 보관하는 편이 버전 숫자만 비교하는 것보다 실용적입니다.
TUN과 시스템 프록시: 앱 트래픽에 맞춰 처리 방식 선택
macOS 시스템 프록시로 먼저 기본 동작을 확인하세요
시스템 프록시는 시스템 설정을 따르는 앱에 HTTP, HTTPS 또는 SOCKS 프록시를 제공하며, 모든 프로세스의 통신을 한 경로로 보내는 기능은 아닙니다. macOS 13 이후 버전에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’에서 실제 설정을 확인할 수 있습니다. 연결 유형과 시스템 버전에 따라 메뉴 이름이 다를 수 있습니다.
클라이언트에 mixed-port: 7890이 명시적으로 설정되어 있다고 가정하고, 아래 명령으로 로컬 HTTP 프록시를 별도로 테스트할 수 있습니다. 7890은 예시 포트이며 모든 클라이언트의 기본값은 아닙니다. 화면에 표시된 실제 수신 포트로 바꿔 사용하세요.
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --head https://example.com
이 테스트로 확인할 수 있는 것은 해당 요청이 지정된 프록시를 거치도록 시도할 수 있다는 점뿐입니다. 모든 앱의 트래픽이 처리된다거나 예상한 경로로 나간다는 뜻은 아닙니다. 명령은 성공하지만 브라우저에서 문제가 생기면 클라이언트를 바로 재설치하지 말고 브라우저 자체 프록시 설정, 확장 프로그램, DNS 동작을 확인하세요.
TUN은 더 많은 트래픽을 받을 수 있지만, 모든 연결이 원격으로 전달되는 것은 아닙니다
TUN은 가상 네트워크 인터페이스와 라우팅을 통해 해당 트래픽을 커널로 전달하므로 시스템 프록시를 사용하지 않는 앱에 적합합니다. 처리된 연결도 규칙에 따라 프록시, 직접 연결, 차단 중 하나로 선택됩니다. 로컬 네트워크, 제외 경로, 시스템 제한에 따라 처리 범위가 달라질 수 있습니다. UDP 사용 가능 여부는 노드 프로토콜, 서버, 네트워크 경로에도 영향을 받습니다.
- 권한 부여 방식: macOS 클라이언트는 권한이 필요한 보조 서비스를 사용하기도 하고 네트워크 확장을 사용하기도 합니다. 모든 TUN 스위치에 같은 종류의 시스템 확장 권한이 필요하다고 볼 수는 없습니다.
- DNS 동작: 클라이언트의 DNS 설정과 TUN의 DNS 처리 옵션을 확인하세요. 브라우저의 암호화 DNS, 다른 VPN, 보안 소프트웨어도 DNS 조회 경로를 바꿀 수 있습니다.
- 네트워크 충돌: 라우팅이나 DNS를 변경하는 다른 도구를 먼저 종료한 뒤 TUN을 테스트하세요. 회사 VPN의 분할 터널링 정책은 별도로 확인해야 합니다.
iOS 프록시 앱은 일반적으로 Network Extension을 통해 VPN 구성을 설정합니다. 처음 연결할 때 시스템에서 VPN 구성 추가를 허용하라는 안내가 나타나는 것은 이 트래픽 처리 방식의 일부이며, Mac에서 프록시 포트를 직접 입력하는 것과는 다릅니다. 일반적인 개인 사용 환경에서는 같은 VPN 경로를 두고 충돌할 수 있는 앱을 동시에 켜지 않는 것이 좋습니다. 관리형 기기에는 추가 제한이 적용될 수 있습니다.
구독 및 규칙 호환성: Mac·iPhone 공용 설정 확인 순서
구독 링크는 전체 YAML을 반환할 수도 있고 인코딩된 노드 목록만 반환할 수도 있습니다. 전체 설정에는 proxies, proxy-groups, rules가 포함될 수 있지만 노드 목록에는 완전한 트래픽 분기 정책이 없는 경우가 많습니다. 앱에서는 두 형식을 모두 ‘구독’이라고 부를 수 있으므로 링크 확장자만으로 가져오기 결과를 판단할 수 없습니다.
구조를 먼저 확인하고 클라이언트별 기능을 살펴보세요
- 프록시 그룹 확인: 설정에서 참조하는 그룹 이름이 실제로 있는지, 특히
rules의 대상 이름을 확인하세요. 노드를 가져왔더라도 프록시 그룹이 빠져 있으면 설정을 사용할 수 없습니다. - 원격 리소스 확인:
rule-providers와proxy-providers를 지원하는지, 리소스 URL에서 파일을 내려받을 수 있는지 확인하세요. 규칙 집합 형식과 동작 유형도 맞아야 합니다. - 플랫폼 전용 필드 확인: Mac의
tun, 수신 포트, 컨트롤 인터페이스, 로컬 파일 경로를 iOS에 그대로 적용하지 마세요. - 로컬 수정 사항의 저장 위치 확인: 원격 구독을 업데이트하면 직접 편집한 내용이 덮어써질 수 있습니다. 클라이언트에서 제공하는 오버라이드, 병합 또는 별도 로컬 설정 기능을 우선 사용하세요.
아래 예시는 필드 간 관계를 설명하기 위한 것으로, 인터넷에 연결할 수 있는 완성된 설정이 아닙니다. DIRECT는 기본 제공되는 직접 연결 정책입니다. TUN을 켜더라도 마지막 규칙에 일치하는 트래픽은 직접 연결되며, 자동으로 원격 프록시를 거치지 않습니다.
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
- MATCH,DIRECT
Shadowrocket이나 Surge로 옮길 때는 대상 앱의 형식에 맞춰 규칙과 정책을 다시 확인해야 합니다. 노드 변환만으로 설정 전체를 이전할 수는 없습니다. Stash가 Clash 스타일 구조를 지원하더라도 모든 mihomo 확장 필드와 호환되는 것은 아니므로 해당 버전의 설정 문서를 확인하세요.
화면 구성과 업데이트 주기: 같은 작업으로 클라이언트 비교
화면의 외관만으로 클라이언트를 고를 필요는 없습니다. 같은 테스트 설정으로 다음 작업을 해 보면 사용 방식이 잘 맞는지 확인할 수 있습니다. 구독 가져오기, 정책 선택, 특정 연결에 적용된 규칙 확인, DNS 오류 찾기, 이전 설정 복원. 메뉴 막대 도구는 상태를 자주 바꾸기에 편하고, 전체 창은 연결과 로그를 함께 확인하기 좋습니다.
| 확인 작업 | 기록할 결과 | 판단 기준 |
|---|---|---|
| 구독 한 번 업데이트 | 정책 선택과 로컬 오버라이드가 유지되는지 | 업데이트 때마다 다시 설정하지 않아도 되는지 |
| Wi-Fi와 휴대폰 핫스팟 전환 | 연결 복구 여부와 DNS 오류 로그 | 네트워크 변경 후 복구 가능한지 확인 |
| Mac 덮개를 닫았다가 다시 열기 | 시스템 프록시 또는 TUN이 복구되는지 | 일반적인 잠자기 상황에서 확인 |
| 클라이언트 재시작 | 프록시 상태, 규칙 모드, 포트가 유지되는지 | 설정이 저장되는지 확인 |
| 업그레이드 후 이전 버전으로 되돌리기 | 기존 설정을 계속 읽을 수 있는지 | 설정 이전 후 복구할 수 없는 상황 방지 |
최근 몇 차례 릴리스 노트를 살펴 업데이트 주기를 판단하세요. 커널 변경 사항을 설명하는지, 알려진 시스템 호환성 문제를 수정했는지, 아키텍처별 설치 파일을 제공하는지, 호환성을 깨뜨릴 설정 변경을 안내하는지 확인하면 좋습니다. 자주 출시된다고 해서 모든 버전을 바로 설치해야 하는 것은 아닙니다. 안정적으로 사용 중인 기기라면 특히 먼저 테스트한 뒤 교체하세요.
노드 지연 시간 테스트만으로 클라이언트 순위를 매기는 것은 적절하지 않습니다. 같은 노드라도 테스트 URL, 연결 재사용, DNS 캐시, 선택한 프로토콜에 따라 결과가 달라질 수 있습니다. 비교하려면 네트워크, 노드, 테스트 대상, 트래픽 처리 방식을 통일하고 지연 시간, 연결 성공 여부, 다운로드 성능을 각각 기록하세요. 이 글은 실측하지 않은 성능 수치를 제시하지 않습니다.
사용 상황별 선택: 세 가지 추천 기준
Apple Silicon Mac에서 주로 브라우저 사용
arm64 빌드를 제공하는 mihomo GUI 클라이언트부터 시작해 구독을 가져오고 시스템 프록시를 켜세요. 규칙 모드, 프록시 그룹, 실제 연결 경로가 예상대로인지 확인한 뒤 TUN이 필요한지 판단하면 됩니다. Clash Verge Rev와 FlClash를 모두 테스트 후보에 넣고, 로그의 명확성, 구독 오버라이드의 편의성, 현재 빌드의 macOS 지원 여부를 기준으로 선택하세요.
Mac과 iPhone에서 같은 정책 구조를 사용하려는 경우
두 기기에서 모두 지원하는 YAML 필드를 기반으로 삼고, Mac에서는 적합한 mihomo 클라이언트를 사용하며 iPhone에서는 Stash의 호환 범위를 확인하세요. 원격 설정에는 노드와 공통 규칙을 두고 포트, TUN, 기기 경로는 각 플랫폼의 로컬 설정에서 관리하세요. 규칙 몇 개로 먼저 검증한 뒤 원격 규칙 집합을 단계적으로 추가하면 차이를 더 쉽게 찾을 수 있습니다.
네트워크 진단이 필요하거나 휴대폰에서 노드만 관리하려는 경우
더 체계적인 진단 기능이 필요하다면 Surge를 검토하되, 설정 이전과 라이선스 비용도 함께 고려하세요. 주로 iPhone에서 노드 구독을 사용하고 규칙을 따로 관리할 수 있다면 Shadowrocket을 검토할 수 있습니다. 어느 앱을 선택하든 장기 사용에 앞서 구독 가져오기, 규칙 적용, 네트워크 전환, 앱 종료 후 복구를 확인하세요.
최종 선택 순서: 시스템 및 아키텍처 일치 → 설정 구문 분석 → 트래픽 처리 확인 → 업데이트와 롤백 관리. 클라이언트 이름이 비슷해도 동작이 같다는 보장은 없습니다. 검증된 설정 사본과 명확한 버전 기록을 보관하면 Mac, iPhone, iPad를 예측 가능한 방식으로 관리할 수 있습니다.