인텔 맥에서 Clash Verge Rev 설치: Apple 검증·권한·Mihomo 구독까지

왜 인텔 맥·x86_64 전용 설명이 필요한가

검색 결과는 대부분 최신 하드웨어 기준이라 arm64·M 시리즈 키워드가 앞에 섭니다. 그러나 교실·연구실·회사 재고로 남은 Intel Mac은 여전히 많고, 같은 macOS 설치 절차 안에서도 다운로드한 .dmg/.zip이 어떤 CPU용인지만 틀려도 첫날부터 막힙니다. Clash Verge Rev는 Verge 계열 GUI로 mihomo 코어를 깔아 두고 구독 기반 YAML을 돌리는 전형적인 「Meta 계열」 워크플로입니다. 즉 설치 글의 초점은 OS 버튼 이름보다 바이너리 아키텍처 정합성과 첫 구독 가져오기에 맞춰져야 합니다.

이 문서는 「이미 앱만 깔아 둔 상태에서 심화 설정만 손본다」가 아니라, 디스크에 복사한 앱을 처음 신뢰하고 열고, 패널이 요구하는 보안·개인 정보 보호 승인을 끝낸 뒤, 프로필 다운로드 → 활성 프로필 지정 → 프록시 토글까지 한 번에 끊기지 않게 잇는 흐름입니다. 이미 Verge를 쓰는 사용자는 「macOS에서 Clash Verge Rev 첫 설정」에서 커널·TUN 디테일을 보강하면 됩니다.

시작 전 확인: macOS 버전·관리자 권한·구독 형식

구독 서버가 「이미 프록시가 있어야만」 응답한다면 순환 의존이 생깁니다. 짧은 시간 동안만이라도 테더링, 다른 기기에서 YAML을 내려 받아 안전하게 옮기기, 제공자가 제시한 국내 접속용 미러 등을 검토하세요. mihomo 전용 문법이 섞인 패널은 Clash Premium 단독 코어로는 해석되지 않을 수 있으니 Verge 안에서 Meta 계열 커널이 선택돼 있는지까지 같은 세션에서 확인하는 것이 좋습니다.

다운로드 선택: x86_64·Intel·Universal 구분

릴리스 자산 이름에 x86_64, amd64, Intel, 64-bit Intel 같은 표기가 붙은 항목이 인텔 맥용입니다. Universal 2는 한 패키지에 arm64와 x86_64가 함께 들어 있어 Intel에서도 동작합니다. 반대로 arm64 전용 또는 Apple 실리콘만 언급된 파일은 이 머신에서 실행되지 않습니다. 오래된 Mac에서 스토어 밖 앱 설치 제한이 켜져 있으면 시스템 설정에서 허용 범위를 먼저 조정해야 합니다.

패키지 옆에 SHA256 같은 해시가 적혀 있으면 터미널의 shasum -a 256 파일명으로 맞춰 보세요. 공급자가 서명과 Apple 노터라이징을 명시한다면 릴리스 노트를 읽어 두면 Gatekeeper 단계에서 심리적 허들이 줄어듭니다. 설령 검증을 통과한 앱이라도 첫 실행 시 개발자 신뢰를 묻는 별도 창이 뜨는 것은 정상입니다.

Apple 검증(Gatekeeper)과 「차단됨」 대화상자

노터라이징(notarization)은 Apple이 맬웨어 스캔 외 골격 검사를 통과했다고 스탬프를 찍는 절차입니다. 통과한 앱은 기본적으로 다운로드 직후 더블클릭만으로 열리는 경우가 많지만, 모든 빌드가 즉시 허용되는 것은 아닙니다. 반대로 아직 스테이플이 안 붙은 내부 테스트 빌드는 경고 문구가 길게 나올 수 있습니다. 사용자 입장에서는 「차단」 화면에서 시스템 설정을 열어 허용하거나, Control+클릭 → 열기를 한 번 실행하는 패턴을 기억하면 됩니다.

.dmg를 연 뒤에는 곧바로 실행하지 말고 아이콘을 응용 프로그램 폴더로 복사하세요. 볼륨 안에서만 돌리는 습관은 권한 캐시·자동 업데이트·코드 서명 경로가 꼬이기 쉽습니다. 복사 후 첫 실행에서 로컬 네트워크나 입력 모니터링 같은 항목이 나오면 UI 설명을 읽고 필요한 최소 권한만 승인합니다. 보안 소프트웨어가 다운로드를 격리했다면 격리를 해제한 뒤 해시까지 다시 확인하는 편이 안전합니다.

macOS 권한과 시스템 확장: 무엇을 왜 허용하나

Verge 계열은 다음 권한을 동시에 요구할 수 있습니다. 각각의 목적을 알면 불필요한 공포 클릭을 줄일 수 있습니다.

• 로컬 네트워크: 대시보드와 코어가 127.0.0.1 포트로 말할 때 방화벽이 가로막지 않도록.
• 로그인 항목·백그라운드 실행: 재부팅 후 자동 기동. 거부해도 수동 실행은 가능.
• 키체인: 시스템 프록시 토글이 자격 증명을 저장하려 할 때. 오래된 항목이 남으면 토글이 실패할 수 있어 충돌 시 항목 정리가 필요.
• 시스템 확장·네트워크 확장: TUN 계열 가상 인터페이스. TUN을 쓰지 않는 초기 테스트에서는 나중으로 미룰 수 있지만, 켤 계획이라면 시스템 설정 → 개인 정보 보호 및 보안에서 개발자 이름을 허용하고 재부팅 안내가 있으면 따릅니다.

MDM으로 관리되는 기기는 확장 설치가 막혀 TUN을 기대하면 안 됩니다. 그럴 때는 시스템 프록시 + Rule 모드만으로 브라우저·메일 등 지원 앱 위주로 범위를 정해야 합니다. 회사 VPN과 동시에 켜면 라우팅이 꼬이므로 한 번에 하나의 터널 스택만 우선합니다.

Mihomo(Clash Meta) 코어와 Verge Rev UI 맵

설치 직후 설정 화면에서 커널 항목이 mihomo 또는 Meta라는 이름으로 잡혀 있는지 확인합니다. 구독에 vless, hysteria, tuic 같은 최신 프로바이더가 포함되면 Premium 단독으로는 파싱이 실패합니다. 커널을 바꿨다면 코어 재시작 또는 전체 리로드를 한 번 수행해 이전 프로세스가 남지 않게 합니다.

화면 이름은 빌드마다 조금씩 다르지만 구조는 같습니다. 프로필이 원격 구독에서 받은 YAML을 담고, 프록시 탭에서 노드 수가 표시되며, 시스템 프록시와 TUN 스위치가 트래픽을 붙잡는 출입구입니다. 첫날에는 시스템 프록시만 켠 상태에서 Rule을 유지하고 브라우저로 해외·국내 한 쌍 이상의 사이트를 열어 DIRECT와 프록시 경로가 갈리는지 먼저 봅니다.

구독 가져오기와 활성 프로필 지정

URL을 붙여 넣는 행위 자체가 끝이 아닙니다. 아래를 같은 세션에서 마쳐야 「연결이 안 된다」 오해를 줄일 수 있습니다.

1. 프로필 또는 구독 입력란에 토큰까지 포함한 전체 문자열을 넣고 다운로드·업데이트를 눌러 에러 없이 끝나는지 확인.
2. 새로 만든 프로필을 명시적으로 활성으로 선택. 가져오기만 하고 예전 빈 프로필이 돌아가는 경우가 흔합니다.
3. 프록시 목록에서 노드 수가 0이 아님을 확인한 뒤에야 지연 테스트나 브라우저 테스트를 진행.
4. 자동 갱신 간격을 현실적인 값(예: 12~24시간)으로 두고 만료·레이트 리밍에 대비.

대시보드의 HTML 페이지를 복사하면 스크립트가 아니라 장식용 마크업만 받는 일이 많습니다. 반드시 원시 YAML 또는 Clash 규격 응답이 보이는 URL인지 브라우저 주소창에서 한 번 검증하세요. 공백·줄바꿈·만료된 쿼리 토큰도 함께 점검합니다.

시스템 프록시와 TUN을 나눠 켜기

시스템 프록시는 HTTP/HTTPS를 인지하는 macOS 앱을 Clash의 로컬 리스너로 보냅니다. Safari·Chrome·대부분의 Electron 앱은 기본적으로 이 경로를 따릅니다. TUN은 네트워크 확장으로 트래픽을 한 번에 가로채므로 CLI나 프록시 설정이 없는 프로그램에도 영향을 줍니다. 인텔 맥에서도 TUN 경로는 Apple의 확장 승인 절차는 동일하지만, 발열·팬 소음이 있는 노트북에서는 불필요한 가상 인터페이스를 줄이는 것이 체감 성능에도 이롭습니다.

1. 메뉴 막대나 대시보드에서 시스템 프록시 ON, 모드는 Rule을 기본으로 유지.
2. 다른 프록시 클라이언트가 같은 로컬 포트를 점유하지 않았는지 확인하고 중복 실행은 종료.
3. TUN이 꼭 필요하면 헬퍼 설치 → 확장 허용 → 요청 시 재부팅 → TUN 스위치 ON 순으로 진행.

연결 확인: 지연 테스트·브라우저·로그 패턴

재설치는 최후의 수단으로 미루고, 아래 순서로 병목을 나눕니다.

1. 내장 지연 테스트에서 전 노드 타임아웃이면 TLS 가로채기·노드 전박 실패·구독 자체 문제부터 의심.
2. Rule에서 해외·국내 사이트를 동시에 열어 정책이 기대대로 분기되는지 확인.
3. 로그에 connection refused나 i/o timeout이 반복되면 출구 노드 쪽, DNS 관련 문자열이 섞이면 fake-ip나 DoH 조합을 의심.

아이콘은 초록인데 페이지만 돌 때는 「Clash 연결됐는데 인터넷이 안 될 때: DNS·fake-ip」 흐름을 이어 읽으면 노드를 무작정 바꾸지 않고도 원인을 좁힐 수 있습니다.

막혔을 때 빠른 분기

실행 아이콘이 즉시 종료되거나 회색

아키텍처 불일치를 먼저 의심합니다. arm64 단독 빌드를 받았는지, 시스템 무결성 보호나 회사 정책으로 서명되지 않은 코드가 막히는지 확인하세요. Universal 패키지라면 응용 프로그램에 복사했는지부터 다시 점검합니다.

구독만 실패

캡티브 포털 Wi‑Fi, 회사 프록시, 일시적 DNS 오염을 의심하고 다른 네트워크에서 URL을 직접 열어 봅니다. 구독 서버가 클라이언트 UA를 검사한다면 Verge 로그의 HTTP 코드를 확인하세요.

프록시는 켰는데 일부 앱만 직행

해당 앱이 시스템 프록시를 무시하는지, 자체 SOCKS5만 지원하는지 살펴봅니다. 필요하면 TUN으로 범위를 넓히되 확장 승인을 먼저 끝냅니다.

자주 묻는 질문

구형 인텔 맥에서 최신 macOS가 안 되면?

그 경우에도 해당 OS가 지원하는 마지막 Verge Rev 빌드를 써야 합니다. 보안 프레임워크 차이로 최신 dmg가 올라가지 않을 수 있으니 릴리스 페이지의 최소 시스템 요구를 먼저 읽고, 그에 맞는 태그를 체크아웃합니다.

Rosetta를 깔아야 하나요?

네이티브 x86_64 빌드를 쓰는 한 필요 없습니다. Rosetta는 arm 앱을 Intel에서 돌릴 수 없고, 반대 방향에서 arm 전용을 억지로 돌리려 할 때만 이야기가 됩니다.

요약: 인텔 맥에서 첫 연결까지 최단 루트

설치 글마다 칩 이름만 바꿔 올려 두면 독자는 여전히 다운로드 표기에서 시간을 잃습니다. 반면 화면만 예쁘게 포장한 일회성 패널형 앱은 규칙·로그 노출이 빈약해 첫 주말부터 커뮤니티 질문이 반복되곤 합니다. 인텔·x86_64 독점 서술은 실제 검색 질의와 맞닿아 있지만, 제품 문서가 그 차이를 짚어 주지 않을 때가 많습니다.

Clash 생태계는 코어와 패널이 늘 함께 진화하는 만큼, 동일한 구독 URL이라도 어떤 클라이언트에서는 로그 한 줄로 원인이 보이고 다른 클라이언트에서는 침묵합니다. 문서와 바이너리 출처·검증 절차를 한 번에 정리해 두면 같은 증상도 재현·공유가 쉬워집니다.

먼저 사용 중인 Mac에 맞는 패키지로 위 순서를 그대로 밟아 보고 싶다면 다운로드 허브에서 플랫폼별 빌드를 확인해 보시면 됩니다. Clash를 무료로 내려받고 macOS를 포함한 여러 환경에서 바로 시험해 보세요. 설치·검증 단계가 얼마나 복제 가능한지 비교하면 첫 연결 디버깅에 쓰는 시간 차이를 바로 체감할 수 있습니다.