macOS에 Clash 클라이언트 설치하기: 네트워크 확장, VPN 권한 및 키체인 메시지 해결

설치 전에 칩 아키텍처와 클라이언트 유형 확인

macOS에서 “Clash”는 그래픽 클라이언트를 뜻할 수도 있고, mihomo 같은 명령줄 코어를 뜻할 수도 있습니다. 그래픽 클라이언트는 구독 가져오기, 정책 그룹 선택, 시스템 프록시 전환, 로그 표시를 담당하고, 코어는 설정을 읽고 로컬 포트를 열어 규칙을 실행합니다. 그래픽 클라이언트를 설치할 때 표시되는 네트워크 확장, VPN 구성 또는 보조 도구 권한 요청은 클라이언트의 트래픽 처리 방식에서 비롯된 것이며, 구독 서비스가 동일한 시스템 권한을 얻었다는 뜻은 아닙니다.

Apple Silicon과 Intel 설치 파일은 혼용할 수 없습니다

M1, M2, M3, M4 계열 칩이 탑재된 Mac은 Apple Silicon을 사용하며, 설치 파일에는 보통 arm64, aarch64 또는 Apple Silicon이라고 표시됩니다. 구형 Intel Mac은 x64, x86_64 또는 Intel에 해당합니다. 화면 왼쪽 상단의 Apple 메뉴에서 「이 Mac에 관하여」를 열면 “칩” 또는 “프로세서” 항목을 확인할 수 있습니다. 터미널에서 다음 명령을 실행해도 됩니다:

uname -m

• arm64가 출력되면 macOS ARM64 또는 Apple Silicon 빌드를 선택합니다.
• x86_64가 출력되면 macOS x64 또는 Intel 빌드를 선택합니다.
• Apple Silicon에서는 Rosetta 2를 통해 Intel 앱을 실행할 수 있지만, 장기간 사용할 때는 네이티브 ARM64 빌드가 일반적으로 더 적합합니다.

다운로드 페이지에서는 앱 설치 파일과 독립 실행형 코어도 구분해야 합니다. 일반적인 .dmg 파일은 디스크 이미지를 연 다음 앱을 “응용 프로그램” 폴더로 드래그합니다. .pkg 파일은 시스템 설치 프로그램으로 실행합니다. 압축을 풀어 나온 단일 실행 파일은 보통 코어이므로 그래픽 클라이언트처럼 메뉴 막대 아이콘을 찾으면 안 됩니다.

앱을 “응용 프로그램”에 넣은 뒤 처음 실행하기

1. 다운로드한 .dmg 파일을 엽니다.
2. 클라이언트 아이콘을 “응용 프로그램” 폴더로 드래그하고, 디스크 이미지나 “다운로드” 폴더에서 계속 실행하지 마세요.
3. 디스크 이미지를 추출한 다음 Finder의 「응용 프로그램」에서 클라이언트를 실행합니다.
4. 처음 실행한 뒤 메뉴 막대, Dock 또는 메인 창에 클라이언트 진입점이 나타나는지 확인합니다.

“응용 프로그램” 폴더에 고정해 두면 업데이트 후 경로가 바뀌는 일을 막을 수 있고, 로그인 항목·보조 도구·네트워크 확장의 호스트 앱도 시스템이 쉽게 식별할 수 있습니다. 읽기 전용 디스크 이미지에서 직접 실행하면 클라이언트가 자체 업데이트 파일을 쓰지 못할 수 있습니다. 임의의 압축 해제 폴더에서 실행하면 여러 번 다운로드하는 과정에서 이름은 같지만 버전이 다른 복사본이 남을 수도 있습니다.

“열 수 없음” 및 개발자 보안 경고 처리

macOS의 설치 보안 경고는 주로 Gatekeeper, 앱 서명, 공증 상태, 다운로드 격리 속성이 함께 작동해 발생합니다. 경고 문구에 따라 해결 절차도 달라집니다. “개발자를 확인할 수 없음”, “앱이 손상됨”, “앱을 업데이트해야 함”을 같은 문제로 취급하지 마세요.

“개발자를 확인할 수 없음”이 표시되면 한 번만 허용하기

설치 파일이 해당 클라이언트의 공식 상위 프로젝트 배포 경로에서 왔는지 확인했다면, 먼저 Finder에서 앱을 찾고 Control 키를 누른 채 앱을 클릭해 「열기」를 선택한 다음 확인 창에서 다시 「열기」를 클릭합니다. macOS 13 이상에서는 「시스템 설정」→「개인정보 보호 및 보안」으로 이동해 보안 영역에서 방금 차단된 앱을 찾고 「그래도 열기」를 선택할 수도 있습니다. 이는 해당 앱에 대한 일회성 확인이므로 Mac 전체의 보안 수준을 변경할 필요가 없습니다.

macOS 12 이하에서는 보통 「시스템 환경설정」→「보안 및 개인정보 보호」→「일반」을 사용합니다. 메뉴 이름은 다르지만 원칙은 같습니다. 먼저 앱을 실제로 한 번 실행해 시스템에 차단 기록을 남긴 다음, 보안 설정에서 앱 이름과 출처를 확인합니다.

“앱이 손상됨”은 단순히 확인되지 않은 앱이라는 뜻이 아닙니다

“손상되어 열 수 없음”은 다운로드 불완전, 서명 상태 이상, 앱의 2차 수정 또는 오래된 빌드와 현재 macOS의 비호환성 때문에 발생할 수 있습니다. 먼저 현재 복사본을 삭제하고 칩 아키텍처에 맞는 빌드를 다시 다운로드한 뒤, 앱이 “응용 프로그램” 폴더에 완전히 복사되었는지 확인하세요. 상위 프로젝트의 배포 안내에 최소 지원 시스템 버전이 명시되어 있다면 현재 시스템이 조건을 충족하는지도 확인해야 합니다.

추가 확인이 필요하면 터미널에서 앱 서명과 시스템 평가 결과를 확인할 수 있습니다. 다음 예시는 표준 폴더에 설치된 Clash Verge Rev를 기준으로 하며, 명령은 상태만 읽습니다:

codesign -dv --verbose=4 "/Applications/Clash Verge Rev.app" 2>&1
spctl --assess --type execute --verbose=4 "/Applications/Clash Verge Rev.app"

codesign 출력으로 식별자, 서명 기관, 런타임 설정을 확인할 수 있습니다. spctl은 시스템이 해당 앱을 허용하는지 평가 결과를 보여 줍니다. 앱 이름이 다르면 Finder에서 실제 앱을 터미널로 드래그해 정확한 경로를 입력하세요. 포럼에 남아 있는 오래된 명령을 따라 모든 앱의 보안 속성을 일괄 삭제하지 마세요.

네트워크 확장, VPN 구성, 시스템 프록시의 차이

Clash 클라이언트의 일반적인 트래픽 처리 방식에는 시스템 프록시와 TUN이 있습니다. 시스템 프록시는 주로 현재 macOS 네트워크 서비스의 HTTP, HTTPS 또는 SOCKS 프록시 설정을 변경합니다. TUN은 가상 네트워크 인터페이스를 통해 더 넓은 범위의 IP 트래픽을 처리합니다. 클라이언트가 네트워크 확장, VPN 구성 또는 관리자 권한을 요청하는지는 TUN 구현 방식에 달려 있으며, “규칙 모드”나 “글로벌 모드” 같은 프록시 정책이 결정하는 것이 아닙니다.

시스템 프록시만 사용할 때는 일반적으로 VPN 구성이 필요하지 않습니다

클라이언트에서 “시스템 프록시”를 켜면 현재 네트워크 서비스에 프록시 서버가 기록됩니다. 일반적인 로컬 주소는 127.0.0.1이고, 흔히 사용하는 mixed 수신 포트는 7890입니다. 오래된 설정에서는 HTTP 포트 7890과 SOCKS 포트 7891을 따로 사용할 수도 있습니다. 이 값은 모든 클라이언트에 적용되는 고정 표준이 아니므로 클라이언트의 「설정」→「포트 설정」, 실행 로그 또는 현재 설정의 mixed-port, port, socks-port를 기준으로 확인하세요.

시스템 프록시는 macOS 네트워크 프록시 설정을 따르는 앱에 적합하지만, 터미널의 curl, 패키지 관리자, 개발 도구, 일부 크로스 플랫폼 앱은 이를 무시할 수 있습니다. 이때 브라우저는 접속되는데 터미널은 실패한다고 해서 네트워크 확장이 손상된 것은 아닙니다. 앱 자체의 프록시 설정을 확인하거나 현재 터미널 세션에 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY를 명시적으로 설정하세요.

TUN을 활성화하면 VPN 또는 네트워크 콘텐츠 필터 메시지가 표시될 수 있습니다

클라이언트가 Apple Network Extension으로 TUN을 구성하면 macOS에서 앱이 VPN 구성을 추가하려 한다는 메시지나 네트워크 확장 허용 요청이 표시될 수 있습니다. 확인 대화상자의 앱 이름이 방금 조작한 클라이언트와 일치하는지 확인한 뒤 허용하면 됩니다. 권한 부여가 끝나면 macOS 13~15에서 「시스템 설정」→「네트워크」→「VPN 및 필터」를 열어 해당 클라이언트가 관리하는 항목을 확인할 수 있습니다.

일부 클라이언트는 권한이 필요한 보조 도구를 통해 가상 인터페이스를 만들거나 라우팅 테이블을 관리합니다. 서비스를 처음 설치할 때 관리자 계정 암호를 입력하거나 Touch ID를 사용하라는 요청이 나타날 수 있습니다. 이는 시스템 수준 권한 요청이며 구독 계정 로그인이 아닙니다. 현재 Mac 관리자 자격 증명을 입력해야 하며, macOS 인증 창에서 처리됩니다. 구독 링크, 프록시 노드 암호 또는 웹사이트 계정을 입력하면 안 됩니다.

키체인 접근 요청이 안전한지 올바르게 판단하기

macOS에는 혼동하기 쉬운 두 종류의 암호 창이 있습니다. 첫 번째는 시스템 관리자 인증 창으로, 보통 사용자 이름·암호 입력란 또는 Touch ID가 표시되며 보조 도구 설치, 네트워크 구성 변경, 권한이 필요한 서비스 시작에 사용됩니다. 두 번째는 키체인 접근 대화상자로, 특정 앱이 키체인의 특정 항목에 접근하려 한다는 내용과 함께 「거부」, 「허용」, 「항상 허용」 등의 선택지가 표시됩니다.

요청자, 키체인 항목, 요청을 유발한 동작부터 확인

1. 서비스 설치, TUN 활성화, 로그인 시 자동 실행 설정, 자격 증명 저장 등의 작업 직후에 표시된 요청인지 확인합니다.
2. 접근을 요청한 앱 이름이 현재 실행한 클라이언트와 일치하는지 확인합니다.
3. 키체인 항목 이름이 클라이언트, 보조 도구 또는 이미 설정한 인증 정보와 연결되는지 확인합니다.
4. 클라이언트를 실행하지 않았는데 요청이 반복되면 먼저 「거부」를 선택한 다음 로그인 항목, 이전 버전의 잔여 파일, 키체인 항목을 확인하세요.

「항상 허용」을 선택하면 이후 동일한 서명 ID의 앱이 해당 항목에 접근할 때 반복 확인이 줄어듭니다. 요청 항목을 이미 확인했고 클라이언트가 정상 작동하려면 실제로 필요한 경우에 적합합니다. 용도를 판단하기 어렵다면 먼저 한 번만 「허용」을 선택하고 클라이언트 기능이 복구되는지 확인하세요. 장기 접근 권한을 바로 부여하는 것보다 문제를 찾기 쉽습니다.

업데이트 후 반복되는 요청은 서명 또는 이전 항목과 관련될 수 있습니다

클라이언트 업데이트, 앱 이름 변경, 서명 ID 변경 또는 다른 배포 경로의 앱을 덮어 설치한 뒤에는 키체인이 새 버전을 다른 요청자로 인식할 수 있습니다. 먼저 같은 이름의 클라이언트를 모두 종료하고 “응용 프로그램” 폴더에는 사용할 버전 하나만 남겨 둔 뒤 다시 실행하세요. 그다음 「키체인 접근」을 열고 “로그인” 키체인에서 클라이언트 이름으로 검색해 항목 생성 시각과 “접근 제어” 목록을 확인합니다.

로그인 키체인 전체를 한 번에 삭제하지 마세요. 특정 항목이 삭제한 이전 클라이언트에만 속한다는 사실을 확인했다면 이름을 기록한 뒤 해당 항목 하나만 삭제하고 현재 클라이언트가 다시 만들도록 하세요. 삭제 후 클라이언트가 프록시 인증 정보를 다시 입력하거나 보조 서비스를 다시 설치하라고 요청하면 현재 버전의 설정 절차에 따라 진행합니다.

처음 설정과 권한 부여를 순서대로 진행

여러 스위치를 동시에 켜면 문제를 찾기 어려워집니다. 먼저 클라이언트와 코어가 실행되는지 확인하고, 설정을 가져온 다음 로컬 포트를 확인하세요. 마지막으로 시스템 프록시 또는 TUN을 차례로 활성화하는 것이 안전합니다.

1단계: 클라이언트를 실행하고 코어 상태 확인

클라이언트를 연 뒤 먼저 「설정」 또는 「설정」→「코어 설정」으로 이동해 코어가 준비되었는지 확인합니다. 클라이언트에 따라 상태가 홈, 로그 또는 서비스 관리 화면에 표시될 수 있습니다. 로그에 설정 파싱 오류가 계속 나타나면 반복해서 권한을 부여하지 말고 설정부터 수정하세요. 흔한 오류로는 YAML 들여쓰기 오류, 존재하지 않는 프록시를 참조하는 정책 그룹, 정의되지 않은 PROXY 정책 그룹을 가리키는 규칙, 다른 프로세스가 이미 사용 중인 포트가 있습니다.

터미널에서 일반적인 포트가 이미 수신 중인지 확인할 수 있습니다:

lsof -nP -iTCP:7890 -sTCP:LISTEN
lsof -nP -iTCP:7891 -sTCP:LISTEN
lsof -nP -iTCP:9090 -sTCP:LISTEN

7890과 7891은 프록시 수신 포트로 자주 사용되고, 9090은 외부 제어 인터페이스로 설정되는 경우가 많습니다. 실제 포트는 현재 설정을 기준으로 확인해야 합니다. 같은 포트를 이전 클라이언트가 사용 중이면 여러 설정 파일을 임의로 수정하지 말고 이전 클라이언트를 완전히 종료하세요.

2단계: 구독을 가져오고 현재 설정 선택

1. 클라이언트의 「설정」 또는 「구독」 페이지로 이동합니다.
2. 구독 서비스에서 제공한 주소를 사용해 설정을 가져옵니다.
3. 다운로드가 완료될 때까지 기다린 뒤 업데이트 시간과 설정 이름을 확인합니다.
4. 새로 가져온 설정을 현재 설정으로 지정합니다.
5. 「프록시」 또는 「정책 그룹」으로 이동해 수동 선택이 필요한 정책 그룹에 사용할 수 있는 노드를 지정합니다.

가져오기에 성공했다는 것은 클라이언트가 설정 파일을 받았다는 뜻일 뿐, 시스템 트래픽이 이미 Clash로 들어갔다는 의미는 아닙니다. 코어가 정상적으로 로드되었고 정책 그룹에 선택 가능한 항목이 있으며, 시스템 프록시 또는 TUN 중 하나 이상의 트래픽 처리 방식이 켜져 있는지 추가로 확인해야 합니다. 구독을 업데이트하면 구독 내부에서 직접 수정한 내용이 덮어써질 수 있으므로, 장기적으로 사용할 사용자 지정 규칙은 클라이언트가 지원하는 오버라이드·병합·스크립트 기능을 사용하세요.

3단계: 먼저 시스템 프록시를 테스트하고 TUN 활성화 여부 결정

클라이언트의 “시스템 프록시”를 켠 뒤 scutil --proxy를 실행해 macOS의 현재 프록시 상태를 확인할 수 있습니다. 출력되는 HTTP, HTTPS 또는 SOCKS 스위치는 클라이언트 설정과 일치해야 합니다. 클라이언트에서는 켜졌다고 표시되지만 시스템 출력이 바뀌지 않으면 현재 네트워크 서비스가 올바른지, 네트워크 구성 변경에 필요한 권한을 클라이언트가 받았는지, 다른 프록시 도구가 설정을 덮어쓰고 있지 않은지 확인하세요.

scutil --proxy
curl --proxy http://127.0.0.1:7890 https://example.org/

두 번째 명령은 요청을 로컬 7890 포트로 명시적으로 보내므로, “코어와 노드는 정상”인 상태와 “터미널이 시스템 프록시를 사용하지 않음”을 구분하는 데 유용합니다. 명시적 프록시는 성공하지만 curl https://example.org/를 직접 실행하면 실패하는 경우에는 네트워크 확장을 다시 설치하지 말고 터미널의 프록시 환경을 우선 확인하세요.

시스템 프록시를 따르지 않는 앱, UDP 트래픽 또는 더 폭넓은 앱 트래픽까지 처리해야 할 때만 TUN을 고려하세요. 활성화한 뒤 VPN 구성 또는 관리자 인증 요청이 나타나면 앞서 설명한 대로 앱 이름과 요청을 유발한 동작을 확인합니다. TUN이 정상적으로 구성되면 로그에서 가상 인터페이스, 라우팅 또는 DNS 모듈 시작 정보를 확인할 수 있습니다. 구체적인 인터페이스 이름은 클라이언트와 코어 구현에 따라 달라집니다.

권한을 부여한 뒤에도 연결되지 않을 때의 단계별 점검

시스템 프록시는 켜졌지만 브라우저에 트래픽이 없을 때

• 「시스템 설정」→「네트워크」→현재 사용하는 Wi-Fi 또는 이더넷→「세부사항」→「프록시」에서 서버가 127.0.0.1인지, 포트가 클라이언트와 일치하는지 확인합니다.
• 메뉴 막대에 UI만 상주하고 있는 것이 아니라 클라이언트 코어가 실행 중인지 확인합니다.
• 브라우저에 별도의 프록시 관리 확장이 설치되어 있거나 자체 프록시 설정을 사용하고 있는지 확인합니다.
• 규칙 매칭 로그를 확인해 요청이 REJECT로 처리되지 않았는지, 대상 정책 그룹에 사용 가능한 노드가 있는지 확인합니다.
• 시스템 프록시를 변경하는 다른 네트워크 도구를 잠시 종료해 여러 프로그램이 설정을 번갈아 덮어쓰지 않도록 합니다.

TUN을 켠 직후 인터넷이 끊길 때

먼저 TUN을 끄고 기본 네트워크가 복구되는지 확인한 다음, 클라이언트 로그에서 최초 오류를 확인합니다. 흔한 원인으로는 가상 인터페이스 생성 실패, 라우팅 충돌, DNS 수신 포트 충돌, 보조 서비스 미실행이 있습니다. 시스템 설정에 이전 클라이언트가 남긴 VPN 구성이 여러 개 있다면 사용하지 않는 구성만 먼저 비활성화하세요. 소속을 확인하지 않은 상태에서 회사 VPN, 원격 업무용 VPN 또는 다른 네트워크 확장을 일괄 삭제하면 안 됩니다.

현재 코어 버전과 설정의 DNS 부분이 호환되는지도 확인해야 합니다. mihomo가 지원하는 DNS 옵션은 버전에 따라 발전하므로 오래된 Clash 설정을 그대로 옮기지 못할 수 있습니다. “필드가 없음”, “유형 오류” 또는 수신 주소 충돌이 나타나면 macOS VPN 권한 문제로 단정하지 말고 현재 클라이언트에 포함된 코어 문서에 따라 설정을 조정하세요.

재부팅 후 프록시 스위치가 작동하지 않을 때

「시스템 설정」→「일반」→「로그인 항목 및 확장 프로그램」으로 이동해 클라이언트가 로그인 시 열리도록 허용되어 있는지, 관련 백그라운드 항목이 활성화되어 있는지 확인합니다. 클라이언트에 따라 “로그인 시 실행”, “자동 실행”, “실행 후 시스템 프록시 설정”이 서로 다른 옵션으로 제공될 수 있습니다. 첫 번째 옵션만 켜면 UI만 실행되고 트래픽을 자동으로 처리하지 않을 수 있습니다.

클라이언트에 권한이 필요한 서비스가 있다면 「설정」→「서비스 모드」 또는 「TUN 설정」에서 서비스 상태도 확인하세요. 업데이트 후 서비스 버전과 클라이언트 버전이 일치하지 않으면 클라이언트에서 제공하는 “서비스 다시 설치” 또는 “서비스 복구” 기능을 먼저 사용하고, 이후 표시되는 시스템 관리자 인증 창에 주의하세요.

클라이언트를 종료해도 시스템에 프록시가 남아 있을 때

비정상 종료로 시스템 프록시가 복원되지 않을 수 있습니다. 같은 클라이언트를 다시 열고 시스템 프록시를 한 번 켰다가 끄면 클라이언트가 정리 절차를 완료하는 데 도움이 됩니다. 「시스템 설정」→「네트워크」→현재 네트워크→「세부사항」→「프록시」에서 HTTP, HTTPS, SOCKS 항목을 확인해 필요 없는 스위치가 꺼져 있는지도 확인하세요.

업데이트·클라이언트 교체·삭제 시 권한 정리

같은 클라이언트를 덮어 업데이트하기 전에 이전 버전을 종료하고 메뉴 막대 아이콘이 사라졌는지 확인하세요. 설치 후 버전 번호, 코어 버전, 현재 설정, 시스템 프록시 상태를 확인합니다. 새 버전이 처음 실행할 때 네트워크 확장이나 보조 서비스 권한을 다시 요청하더라도 앱 서명과 출처를 확인한 뒤 필요한 경우 허용하세요. 시스템이 권한을 다시 확인한다고 해서 구독 설정이 사라진 것은 아닙니다.

클라이언트를 바꿀 때 시스템 네트워크를 동시에 제어하지 않기

ClashX Meta, Clash Verge Rev, FlClash 또는 다른 클라이언트로 전환할 때는 먼저 보존할 설정을 내보내거나 구독 주소를 기록한 뒤, 이전 클라이언트에서 시스템 프록시 끄기, TUN 끄기, 앱 종료를 차례로 진행하세요. 새 클라이언트를 실행해 로컬 포트를 확인한 다음 한 가지 트래픽 처리 방식만 활성화합니다. 두 클라이언트가 동시에 7890을 수신하거나 시스템 프록시를 동시에 변경하면 포트 충돌이 발생하고 표시 상태와 실제 설정이 달라질 수 있습니다.

삭제는 앱을 휴지통으로 드래그하는 것만으로 끝나지 않습니다

1. 클라이언트에서 시스템 프록시와 TUN을 끕니다.
2. 클라이언트에 “서비스 삭제” 또는 “보조 도구 제거” 기능이 있다면 먼저 설정 페이지에서 실행합니다.
3. 클라이언트를 종료하고 활성 상태 보기에서 같은 이름의 프로세스가 계속 실행 중이지 않은지 확인합니다.
4. 「시스템 설정」→「네트워크」→「VPN 및 필터」에서 해당 클라이언트가 만든 구성을 확인합니다.
5. 「시스템 설정」→「일반」→「로그인 항목 및 확장 프로그램」에서 로그인 항목과 백그라운드 항목을 확인합니다.
6. 로컬 설정이 더 이상 필요하지 않은지 확인한 뒤 앱과 전용 설정 폴더를 삭제합니다.

단순히 업데이트하거나 일시적으로 문제를 해결하는 중이라면 모든 설정을 먼저 삭제하지 않는 것이 좋습니다. 사용할 수 있는 설정 하나와 최근 로그를 보존하면 문제가 앱 업데이트, 코어 로드, 시스템 권한 또는 구독 내용 중 어디에서 발생했는지 판단할 수 있습니다. 설치 후 최소 검증 절차는 앱 실행 가능 여부, 코어 설정 오류 없음, 로컬 포트 수신 여부, 명시적 프록시 요청 성공, 시스템 프록시 또는 TUN 중 의도한 경로 하나만 활성화되었는지, 종료 후 시스템 네트워크가 복구되는지를 포함해야 합니다.