1. 전제와 Clash Verge Rev·Mihomo 역할
Clash Verge Rev를 맥에 새로 올릴 때 흔한 혼동은 「앱 아이콘 하나가 모든 패킷을 다 만진다」는 인상입니다. 실제로는 GUI가 사람이 이해하기 쉬운 패널을 제공하고, 실행되는 Mihomo(구 생태계에서 Clash Meta로 불리던 계열)가 구성 파일을 읽어 프록시 체인·규칙·DNS를 계산합니다. 따라서 구독 가져오기에 성공했다는 말은 「원격 텍스트를 내려 받아 Mihomo가 병합·검증해 노드를 채웠다」에 가깝고, 그 다음에 OS와 앱이 127.0.0.1의 Mixed Port(또는 동등한 통합 포트)로 붙게 만드는 단계가 이어집니다.
이 문서는 법령과 서비스 약관을 지키는 개인 실험·개발 편의를 전제로 하며, 제공받은 노드·구독의 적법성은 사용자가 확인해야 합니다. 회사·학교 장비라면 정책이 허용하는지 먼저 따르세요. 한편 시스템 프록시는 켰는데도 증상이 남는 경우, 이 글의 범위를 넘어 macOS Clash Verge 시스템 프록시·네트워크 확장 글에서 권한 스택을 좁히는 편이 빠릅니다.
2. 칩 확인과 맞는 패키지·Clash Verge Mac 다운로드
메뉴 막대에서 이 Mac에 관하여를 열면 칩이 Apple M 시리즈인지, 혹은 Intel인지 바로 나옵니다. 이 글은 Apple Silicon을 기준으로 설명합니다. 배포 페이지에 aarch64·arm64·Apple Silicon 같은 표기가 붙은 패키지를 고르세요. Intel 전용 빌드를 억지로 쓰면 Rosetta 경유로 돌아갈 수 있지만, 전력·발열 측면에서 네이티브를 고르는 편이 일관됩니다.
Clash Verge Mac 다운로드는 공식 릴리스나 신뢰하는 출처에서 받는 것이 안전합니다. 체크섬·코드 서명 정보가 제공되면 검증하는 습관이 좋습니다. 동시에 검색 결과 상단의 “원클릭 번들 설치기”류는 Clash 계열과 섞지 마세요. 가짜 바이너리나 불필요한 확장 프로그램이 따라붙는 경우가 많습니다.
버전마다 파일 이름과 확장자가 .dmg·.zip 등으로 달라질 수 있으나, 첫 사용자에게는 dmg를 열고 아이콘을 응용 프로그램 폴더로 드래그하는 흐름이 가장 단순합니다. 나중에 여러 채널을 나란히 두고 싶다면 응용 프로그램 안에서 폴더를 나눠 두어도 됩니다.
3. dmg·Gatekeeper·첫 실행
dmg에서 응용 프로그램으로
디스크 이미지를 연 뒤 Clash Verge Rev 아이콘을 응용 프로그램으로 끌어다 놓습니다. 이전에 테스트용으로 사용자 폴더에만 두었다면 실행 정책과 업데이트 경로가 꼬일 수 있어, 장기 쓰임을 생각하면 응용 프로그램 설치를 권합니다. Finder 창을 넓게 두면 dmg 안의 화살표와 응용 프로그램 폴더를 한눈에 볼 수 있어 첫 설치에서 잘못 끌어다 놓는 실수를 줄일 수 있습니다.
보안·격리 속성
첫 실행에서 “손상되어 있어 열 수 없습니다”나 개발자 신뢰와 관련한 메시지가 나오면, 최신 macOS에서는 시스템 설정 → 개인정보 보호 및 보안에서 해당 앱에 대한 실행 허용 대화가 뜨기도 합니다. 인터넷에서 내려받은 앱에 격리 플래그가 붙어 있으면 터미널로 속성을 풀어야 하는 사례도 있으나, 출처가 명확할 때만 신중히 적용하세요. 팀 배포라면 MDM이나 공식 패키지 채널을 쓰는 편이 낫습니다.
방화벽과 알림
앱을 처음 키면 들어오는 연결 허용 같은 대화상자가 뜰 수 있습니다. 로컬 루프백에서 웹 브라우저가 붙는 전형적인 구성이라면 “허용”으로도 충분한 경우가 많지만, 설명을 읽고 환경에 맞게 고르세요. 이후 LAN에서 다른 기기를 붙이거나 외부에서 접속을 열 계획이라면 공유 범위를 다시 정해야 합니다.
관리자·후속 권한
macOS 설치 직후의 최소 목표가 시스템 프록시라면 굳이 TUN이나 커널 확장까지 같은 날 건드릴 필요는 없습니다. 반대로 가상 NIC까지 켜는 기능을 바로 켠다면 추가 비밀번호·프로파일·개인정보 보호 섹션으로 안내가 이어질 수 있습니다. 지금 단계에서는 GUI가 요구하는 대화만 따라가도 됩니다.
4. 구독 URL로 프로필 가져오기(구독 가져오기)
대시보드 형태의 서비스는 보통 구독 링크를 복사하게 합니다. Clash Verge Rev에서 프로필·구독 화면으로 들어가 새 항목을 만들고 URL 칸에 붙여 넣습니다. 이름은 나중에 여러 프로필을 섞을 때 구분이 되도록 짧고 명확하게 바꿉니다.
갱신(Update) 컨트롤을 눌러 원격 서버에서 Clash/Mihomo가 읽을 수 있는 텍스트를 다시 받습니다. 성공하면 노드 리스트에 지역·프로바이더 라벨이 채워집니다. 실패하면 로그에 HTTP 상태·TLS 오류가 남으므로, 같은 링크를 Safari로 열었을 때 파일이 내려오는지, 회사망에서 도메인이 차단됐는지부터 보는 것이 빠릅니다.
직접 편집하는 단일 YAML을 쓰는 경우라도 흐름은 같습니다. 저장 후 Mihomo가 문법 오류 없이 적재되는지 로그로 확인하세요. 구독은 받았는데 노드가 비는 문제는 별도 글에서 원인 축을 나눕니다.
5. 첫 구성: Rule·노드·Mixed Port
활성 프로필이 정해지면 상단이나 홈에서 모드를 고릅니다. 첫날에는 대개 Rule을 권장합니다. 모든 트래픽을 한 노드로 모을 때만 Global을, 프록시를 잠깐 끄고 싶을 때는 Direct 계열(제품 표기는 다를 수 있음)을 고릅니다.
노드 목록에서 지연 측정이 가능하면 한두 개를 찍어 보고, url-test·fallback 그룹이 YAML에 정의돼 있다면 클라이언트가 그 로직을 따릅니다. 중요한 것은 Mixed Port 또는 HTTP·SOCKS 통합 포트에 표시된 숫자를 메모하는 일입니다. 예시로 7890이 자주 나오지만, 본인 화면이 항상 기준입니다.
규칙 세트가 GEOIP나 국내 리스트를 포함했는지는 프로필 품질에 달려 있습니다. 잘못된 Rule은 전 구간을 프록시로 보내 속도만 느리게 만들거나, 반대로 필요한 구간을 직행으로 빼먹습니다. 첫날에는 화면에서 모드·노드·포트만 확실히 맞추고, 튜닝은 문서를 병행하는 편이 안전합니다.
6. macOS 시스템 프록시 적용
Clash Verge Rev에서 시스템 프록시에 해당하는 토글을 켭니다. 영문 UI면 “System Proxy”류 표기입니다. 켠 직후 macOS 시스템 설정 → 네트워크에서 사용 중인 인터페이스(Wi‑Fi 또는 유선)의 세부를 열고 프록시 항목을 확인합니다. 수동 웹 프록시(HTTP/HTTPS) 서버가 127.0.0.1이고 포트가 방금 적어 둔 Mixed Port와 같은지 글자와 숫자까지 대조하세요.
불일치가 보이면 다른 VPN·“네트워크 부스터”·구형 프록시 유틸이 값을 덮어썼을 수 있습니다. 경쟁 앱을 종료한 뒤 Verge에서 토글을 껐다 켜며 다시 기록됐는지 봅니다. 메뉴는 macOS 버전에 따라 조금씩 옮겨지므로, 검색 창에 “프록시”를 쳐 동등 화면으로 이동해도 됩니다.
여기까지 했는데도 브라우저 출구가 전혀 바뀌지 않으면 단순히 “노드가 나쁘다”로 넘어가기 전에, 권한·네트워크 확장·로그인 항목 축을 점검해야 합니다. 그때는 시스템 프록시 전용 macOS 글의 표를 따라가면 범위를 빠르게 줄일 수 있습니다.
7. Safari·Chrome으로 첫 연결 검증
기본 설정의 Safari와 Chrome은 대체로 macOS 시스템 프록시를 따릅니다. 비공개 창으로 열어 확장 프로그램 영향을 줄이고, 해외 출구 확인 페이지나 지연 측정 사이트를 열어 ASN·국가가 기대와 맞는지 봅니다. 같은 시각 Clash Verge Rev의 연결 로그에 해당 호스트가 찍히는지 보면 “프록시 체인을 탔는지”와 “규칙상 선택된 노드가 맞는지”를 동시에 확인할 수 있습니다.
Firefox는 자체 네트워크 설정을 기본으로 쓰는 경우가 많아, 시스템 설정을 따르게 바꾸거나 수동으로 127.0.0.1과 같은 포트를 넣어 줘야 합니다.
출구 IP는 맞는데 이름 해석만 이상하면 프로필의 DNS·fake-ip 구간을 건드려야 할 수 있습니다. 첫 검증에서는 IP 출구와 로그 존재 여부를 최소 통과 기준으로 삼고, DNS 미세 조정은 문서와 함께 천천히 진행하세요. 터미널 도구를 같은 맥에서 바로 쓰려면 환경 변수 경로가 별도일 수 있으니 터미널·프록시 환경 변수 글도 참고하면 좋습니다.
8. TUN·확장 권한은 다음 단계
시스템 프록시만으로 브라우저와 대부분의 데스크톱 앱을 커버하는 경우가 많습니다. 반면 시스템 프록시를 무시하는 프로세스까지 한 번에 정책 안으로 끌어오려면 TUN·가상 NIC 경로를 검토해야 하고, 그 순간 macOS 설치 이후 스택이 훨씬 복잡해집니다. 첫날 목표가 “웹이 의도한 노드를 탄다”는 확인이라면 TUN은 일부러 미루어도 됩니다.
TUN을 켠 뒤 전체 네트워크가 끊기면 어댑터 우선순위·충돌하는 필터·보안 소프트웨어를 의심합니다. 클라이언트 로그의 키워드를 메모해 두었다가 커뮤니티 이슈와 매칭하면 수리 시간을 줄일 수 있습니다.
9. 자주 막히는 지점
| 증상 | 먼저 볼 곳 |
|---|---|
| 구독 갱신 실패·빈 노드 | URL 복사, 토큰 만료, HTTPS 가로채기, 서버 rate limit |
| 앱은 켜졌는데 시스템 설정 프록시가 안 바뀜 | 토글 재적용, 다른 VPN 종료, Verge 재시작, 권한·NE 허용 여부 |
| 한 브라우저만 이상 | Firefox 독립 설정, 수동 프록시 확장, DNS만 다른 출구 |
| 속도만 유난히 나쁨 | Wi‑Fi 절전, 백그라운드 동기화, 노드 혼잡, Rule 오작동 |
한 번에 변수를 여러 개 바꾸지 마세요. 구독·노드·시스템 설정을 동시에 뒤집으면 어느 단계에서 깨졌는지 기억하기 어렵습니다. UI 패밀리가 헷갈리면 Clash Verge와 Clash for Windows 비교에서 메뉴 위치 감을 잡아도 좋습니다. 코어 계열을 Mihomo에 맞추는 것이 Verge Rev의 전제에 가깝습니다.
10. 자주 묻는 질문
Intel pkg를 M 칩에 설치해도 되나요?
가능한 한 arm64 전용 빌드를 쓰세요. Rosetta 경로로 돌아가면 그 자체가 오류는 아닐 수 있지만 전력과 반응 속도에서 불리해질 수 있습니다.
시스템 프록시는 켰는데 페이지 출구가 그대로예요.
프록시 문자열과 포트를 다시 대조하고, 다른 앱이 네트워크를 선점했는지 봅니다. 그다음 단계는 시스템 프록시 전용 macOS 글의 권한·Network Extension 절차입니다.
구독을 넣었는데 노드가 비어 있어요.
HTTP 응답과 TLS 로그부터 확인하세요. 동일 URL이 브라우저에서 파일을 주는지, 회사 프록시가 중간에서 잘리지 않는지 봅니다.
TUN을 처음부터 켜야 하나요?
아니요. 브라우저 중심이라면 Rule과 시스템 프록시만으로 먼저 목표를 달성하는 경우가 많습니다.
11. 요약과 Clash로 이어가기
Apple Silicon 맥에서 Clash Verge Rev를 처음 쓸 때의 뼈대는 단순합니다. arm64 패키지를 받아 응용 프로그램에 두고, 구독 가져오기로 Mihomo 프로필을 채운 뒤 Rule과 노드를 고르고, macOS 시스템 프록시 문자열을 127.0.0.1과 화면의 Mixed Port에 맞추면 Safari·Chrome 기준 첫 연결 검증까지 도달하기 쉽습니다.
설치 과정 전체를 한 번에 보려면 본 사이트 다운로드에서 클라이언트를 고르고, 규칙 개념은 문서와 함께 익히면 이후 튜닝 비용이 줄어듭니다. 생태계에는 한 앱에 모든 기능을 억지로 넣느라 무거워지거나, 규칙·프로파이더 생태가 약해 반복 설정이 커지는 경우도 있습니다. 반면 Clash·Mihomo 계열은 프로파이더와 정교한 Rule을 바탕으로 트래픽을 나누기 쉽고, 맥을 포함해 여러 OS에서 같은 구성 발상을 이어 가기 좋습니다. 장기적으로는 규칙 자산을 쌓을수록 재설치 부담이 줄고, 상황이 바뀌어도 YAML과 UI만 손보면 되어 유지 비용이 낮아집니다. 패키지를 한곳에서 받고 설치 준비를 마치려면 무료로 Clash 클라이언트 받기를 이용하면 됩니다.