macOS Clash 클라이언트 설치: 네트워크 확장 권한, 키체인 암호 팝업, ‘손상되어 열 수 없음’ 해결

설치 차단, 네트워크 권한, 자격 증명 문제를 구분하세요

macOS에서 Clash라는 이름이 들어간 클라이언트는 설치 및 권한 부여 방식이 서로 다릅니다. 그래픽 인터페이스, 프록시 코어, 권한이 필요한 보조 프로그램, 네트워크 확장은 각각 다른 구성 요소일 수 있습니다. Clash Meta는 현재 mihomo로 불립니다. mihomo 코어를 사용한다고 해서 클라이언트가 반드시 Apple 네트워크 확장으로 TUN을 구현하는 것은 아닙니다. 팝업을 처리하기 전에 클라이언트 이름과 버전, macOS 버전, 전체 경고 문구를 기록하고, 모든 암호 입력 창을 같은 권한 요청으로 취급하지 마세요.

표시되는 시점과 안내 문구	주요 확인 항목	다음 단계
최초 실행 시 개발자를 확인할 수 없음 또는 손상됨 안내	설치 파일 출처, 아키텍처, 서명 및 격리 속성	먼저 해당 기기에 맞는 설치 파일을 다시 받은 다음 시스템 차단 정보를 확인하세요
보조 도구 설치 중 관리자 암호 요청	권한이 필요한 보조 프로그램 또는 서비스 모드	요청 프로그램의 이름이 설치 작업과 일치하는지 확인하세요
TUN을 켤 때 VPN 구성 추가 또는 확장 승인 요청	클라이언트의 네트워크 트래픽 처리 방식	시스템에 표시된 구성 또는 확장 유형에 맞게 승인하세요
키체인 항목에 접근하라는 안내	저장된 자격 증명 및 앱 접근 제어	항목 이름, 요청 앱, 로그인 키체인 상태를 확인하세요

설치 전에 칩 아키텍처와 앱 위치 확인하기

Apple 칩은 arm64, Intel 모델은 x64 선택

Apple 메뉴 → ‘이 Mac에 관하여’를 여세요. Apple M 시리즈 칩이 표시되면 macOS arm64 또는 Apple Silicon용 빌드를 우선 선택하세요. Intel 프로세서가 표시되면 x64 또는 x86_64 빌드를 선택하세요. Universal 빌드에는 두 아키텍처가 모두 포함될 수 있으므로 릴리스 안내를 확인하세요. Apple 칩에서 Rosetta로 일부 Intel 앱을 실행할 수는 있지만, 해당 앱의 보조 프로그램까지 호환된다는 보장은 없습니다.

로컬 프록시 포트를 이전 프로세스가 계속 점유하지 않도록 실행 중인 동명의 클라이언트를 종료하세요.
DMG를 열고 앱을 ‘응용 프로그램’으로 드래그하세요. 디스크 이미지나 ‘다운로드’ 폴더에서 계속 실행하지 마세요.
DMG를 추출한 다음 ‘응용 프로그램’에서 클라이언트를 실행하세요. 이후 권한 승인은 이 위치에 설치된 사본을 대상으로 해야 합니다.
먼저 설정을 가져오고 시스템 프록시를 테스트하세요. 기본 연결이 정상인지 확인한 뒤 TUN을 켜세요.

동일한 앱을 여러 위치에 두면 로그인 항목, 키체인 접근 기록, 실제 실행 경로가 서로 맞지 않을 수 있습니다. 업데이트할 때는 앱을 종료한 후 ‘응용 프로그램’ 폴더의 기존 사본을 교체하세요. 이전 버전을 실행한 채 새로 받은 사본을 실행해 권한을 승인하지 마세요.

‘손상되어 열 수 없음’: 먼저 확인한 뒤 차단 해제 여부를 결정하세요

‘손상됨’은 다운로드가 중간에 끊겼다는 뜻만은 아닙니다. 서명 만료, 앱 콘텐츠 변경, 시스템 평가 실패가 원인일 수도 있습니다. ‘개발자를 확인할 수 없음’이라는 안내가 표시되는 경우도 흔합니다. 두 경고는 같은 의미가 아니며, 안내가 떴다고 시스템 보안 검사를 바로 끄면 안 됩니다.

먼저 시스템에서 제공하는 앱별 차단 해제 기능을 사용하세요

설치 파일이 해당 프로젝트의 공식 배포 채널에서 제공되었는지 확인하고 시스템 요구 사항과 칩 아키텍처를 대조하세요.
설치 파일을 다시 다운로드해 기존 사본을 완전히 교체한 다음 한 번 실행해 보세요.
‘시스템 설정’ → ‘개인정보 보호 및 보안’을 열고 ‘보안’ 영역에 해당 앱의 차단 기록이 있는지 확인하세요.
앱이 맞는지 확인한 뒤에만 시스템에서 제공하는 ‘그래도 열기’ 등의 작업을 선택하고 안내에 따라 인증하세요.

macOS 15에서는 올바르게 서명되거나 공증되지 않은 일부 앱의 차단 해제 방법이 변경되었습니다. 이전 안내에 나온 ‘마우스 오른쪽 버튼 클릭 → 열기’만으로 항상 경고를 우회할 수 있다고 생각하지 마세요. 시스템에서 악성 소프트웨어이거나 앱이 컴퓨터를 손상시킬 수 있다고 명확히 경고하면 실행을 중단하고 출처를 다시 확인하세요. 일반 앱의 차단 해제 절차를 이런 경고에 적용하면 안 됩니다.

터미널 검사는 대상 앱을 확인한 뒤에만 진행하세요

실제 설치 경로가 /Applications/Clash Verge.app인 클라이언트를 예로 듭니다. 앱 이름이 다르면 Finder에서 실제 경로를 확인하세요. 앱을 터미널 창으로 드래그하면 경로를 입력할 수 있습니다. 아래 세 명령어는 각각 격리 속성 확인, 코드 서명 무결성 검증, 시스템 실행 평가를 요청하며 네트워크 권한을 부여하지는 않습니다.

xattr -p com.apple.quarantine "/Applications/Clash Verge.app"
codesign --verify --deep --strict --verbose=2 "/Applications/Clash Verge.app"
spctl --assess --type execute --verbose=4 "/Applications/Clash Verge.app"

첫 번째 명령어가 ‘No such xattr’를 반환하면 해당 속성이 없다는 뜻이지 설치 실패가 아닙니다. 서명 검증에 성공해도 배포자를 신뢰할 수 있다는 사실이 단독으로 입증되는 것은 아닙니다. 출처와 서명 주체도 확인해야 합니다. 서명 검증에 실패하면 다시 다운로드하거나 유지 관리자에게 문의하세요. 실패 원인을 감추려고 다시 서명하지 마세요.

출처와 앱 무결성을 확인했고 격리 해제의 위험을 이해한 경우에만 해당 앱의 격리 속성을 삭제하는 방법을 고려하세요:

xattr -d com.apple.quarantine "/Applications/Clash Verge.app"

이 명령어는 손상된 프로그램을 복구하거나 서명을 보완하거나 공증을 완료하지 않으며, 실행 실패를 해결하지 못할 수도 있습니다. 대상을 ‘응용 프로그램’ 폴더 전체로 바꾸지 말고, 습관적으로 재귀 옵션이나 관리자 권한을 추가하지 마세요. Gatekeeper를 전역으로 끄는 것도 금물입니다. 계속 실패하면 오류 내용을 보관하고 프로젝트 설치 안내를 다시 확인하세요.

TUN 최초 설정: 네트워크 확장과 보조 서비스는 각각 확인하세요

TUN은 가상 네트워크 인터페이스와 라우팅을 이용해 트래픽을 처리하므로 시스템 프록시를 따르지 않는 일부 앱에도 적용할 수 있습니다. 다만 실제 적용 범위는 라우팅, 제외 항목, 프로토콜 지원에 따라 달라집니다. 시스템 프록시는 주로 앱에 HTTP, HTTPS 또는 SOCKS 프록시 설정을 제공하며 대개 네트워크 확장 설치가 필요하지 않습니다. 한 모드의 권한 요구 사항으로 다른 모드의 권한을 단정할 수 없습니다.

먼저 클라이언트의 구현 방식을 확인하세요

권한이 필요한 보조 프로그램 또는 서비스 모드: 클라이언트가 커널의 TUN 인터페이스 생성, 라우팅 조정, DNS 설정을 위해 보조 도구 설치를 요청할 수 있습니다. 이 방식은 네트워크 확장 목록에 표시되지 않을 수도 있습니다.
Network Extension: Apple 네트워크 확장을 사용하는 클라이언트는 VPN 구성 추가, 터널 제공자 실행 또는 관련 확장 승인을 요청할 수 있습니다. 현재 설치된 앱에 해당하는 항목만 승인하세요.
콘텐츠 필터: 네트워크 콘텐츠를 필터링한다는 안내가 별도로 표시되면 프로젝트 문서에서 실제로 필요한 기능인지 확인하세요. 모든 Clash 클라이언트에서 TUN을 켜기 위한 공통 필수 조건은 아닙니다.

macOS 버전별 권한 설정 위치 확인하기

macOS 13 및 14에서는 먼저 ‘시스템 설정’ → ‘개인정보 보호 및 보안’ 하단에 차단된 시스템 소프트웨어 또는 확장 안내가 있는지 확인하고, ‘네트워크’의 VPN 또는 필터 항목도 살펴보세요. macOS 15에서는 ‘시스템 설정’ → ‘일반’ → ‘로그인 항목 및 확장 프로그램’ → ‘네트워크 확장’을 확인할 수 있습니다. VPN 구성은 시스템 설정의 ‘VPN’ 페이지에서 확인하세요. 어떤 항목이 표시되는지는 클라이언트 구현 방식과 설치 진행 상태에 따라 다릅니다.

다른 VPN, 다른 프록시 클라이언트의 TUN, 라우팅을 변경할 수 있는 테스트 도구를 먼저 종료하세요.
현재 클라이언트에서 문서가 요구하는 보조 서비스를 설치하고 시스템 인증 창에 표시된 프로그램 이름을 확인하세요.
TUN을 켜고 이번 작업으로 직접 표시된 구성 또는 확장 요청을 처리하세요. 시스템에서 재시작을 요구할 때만 재시작하면 됩니다.
클라이언트 로그를 확인해 권한 부족, 인터페이스 생성 실패, 라우팅 충돌을 구분하세요. 스위치가 켜져 보이는지만 확인해서는 안 됩니다.

조직에서 관리하는 Mac은 기기 관리 정책으로 확장 프로그램이나 VPN 구성이 제한될 수 있습니다. 이 경우 부팅 보안을 낮추거나 시스템 무결성 보호를 비활성화하지 말고 관리자에게 문의하세요. 이런 클라이언트를 정상적으로 설치하기 위해 시스템 보호 기능을 끄는 것이 일반적인 사전 조건은 아닙니다.

키체인 팝업이 반복될 때: 암호, 앱 식별 정보, 항목 권한 확인하기

일반적인 키체인 창에는 ‘어떤 앱이 키체인에 저장된 기밀 정보를 사용하려고 합니다’라는 안내와 구체적인 항목 이름이 표시됩니다. 이는 보조 도구 설치 중 나타나는 ‘이 작업을 허용’ 인증 창과 다릅니다. 먼저 요청 내용을 읽고 ‘한 번 허용’, ‘항상 허용’ 또는 거부를 선택하세요.

로그인 키체인 암호는 현재 로그인 암호와 다를 수 있습니다

일반적으로 로그인 키체인은 계정에 로그인할 때 자동으로 잠금 해제됩니다. 계정 복구나 다른 관리자를 통해 로그인 암호를 재설정한 뒤에도 이전 키체인은 기존 암호를 사용할 수 있습니다. 이 경우 새 로그인 암호를 반복해서 입력해도 실패할 수 있습니다. ‘Spotlight 검색’으로 ‘키체인 접근’을 열어 ‘로그인’ 키체인이 잠겨 있는지 확인한 다음 이전 암호로 잠금 해제를 시도해야 하는지 판단하세요.

이전 암호를 모른다고 해서 팝업을 없애려고 키체인을 바로 재설정하지 마세요. 재설정하면 이전 키체인에 저장된 암호, 인증서, 토큰에 더 이상 접근하지 못할 수 있습니다. 먼저 시스템 안내를 읽고 백업 및 계정 복구 방법을 확인한 뒤 처리 방법을 결정하세요.

업데이트 후 앱 식별 정보가 바뀌면 다시 승인해야 할 수 있습니다

배포 채널을 바꾸거나 다른 브랜치로 이전하거나 서명이 다른 빌드를 사용하거나, 같은 앱을 여러 경로에서 실행하면 기존 접근 권한이 더 이상 적용되지 않을 수 있습니다. 모양과 이름이 같아도 시스템이 인식하는 코드 식별 정보까지 같다는 뜻은 아닙니다.

같은 종류의 클라이언트를 모두 종료하고 ‘응용 프로그램’에 있는 사본 하나만 실행하세요.
‘키체인 접근’에서 팝업에 표시된 정확한 항목 이름을 검색하세요. 이름에 Clash가 포함된 항목을 한꺼번에 삭제하지 마세요.
해당 항목의 세부 정보를 여세요. ‘접근 제어’ 옵션이 있는 암호 항목이라면 접근을 허용한 앱이 이전 사본을 가리키는지 확인하세요.
현재 앱이 해당 자격 증명과 실제로 관련이 있는지 확인한 뒤 시스템 팝업에서 접근을 허용하세요. 모든 앱이 접근할 수 있도록 설정하지 마세요.

권한을 승인해도 웹페이지가 열리지 않을 때: 포트, 프록시, TUN 로그 확인

앱이 실행되고 키체인 팝업이 사라졌다는 것은 설치 또는 자격 증명 문제가 처리되었다는 뜻일 뿐, 프록시 연결이 정상이라는 보장은 아닙니다. 커널 리스닝, 로컬 프록시 진입점, 노드 연결, 시스템 트래픽 처리 여부를 각각 확인해야 합니다.

포트를 지정해 로컬 진입점 테스트하기

클라이언트 설정에 mixed-port: 7890이 명시되어 있다고 가정하면 아래 명령어를 사용할 수 있습니다. 7890은 여기서 사용하는 예시이며 모든 클라이언트의 고정 포트가 아닙니다. 현재 적용 중인 설정에서 실제 포트를 확인하세요.

lsof -nP -iTCP:7890 -sTCP:LISTEN
scutil --proxy
curl -I --connect-timeout 10 --max-time 20 \
  --proxy http://127.0.0.1:7890 https://example.com/

리스닝 기록이 없음: 커널이 실행 중인지, 설정 파싱이 성공했는지, 포트가 다른 값으로 바뀌었는지 확인하세요.
리스닝 프로세스가 이전 클라이언트임: 이전 프로세스를 정상 종료한 뒤 현재 클라이언트를 실행하세요. 정체를 모르는 시스템 프로세스를 강제 종료하지 마세요.
명시적 프록시 테스트에서 HTTP 응답을 받음: 이번 요청이 로컬 진입점을 통과했다는 뜻이지만, 모든 웹사이트나 규칙이 정상이라는 보장은 아닙니다.
명시적 프록시는 작동하지만 브라우저는 실패함: 현재 네트워크 서비스의 시스템 프록시, 브라우저 자체 프록시 정책, DNS 설정을 확인하세요.

scutil --proxy는 시스템 프록시 상태를 확인하는 명령어입니다. TUN만 사용하는 경우 HTTP 프록시 항목이 없어도 정상일 수 있습니다. TUN을 테스트할 때는 로그에서 인터페이스, 라우팅, DNS 오류를 확인한 뒤 --proxy 없이 요청을 보내세요. utun 인터페이스가 있다는 사실만으로 Clash가 트래픽을 처리한다고 볼 수는 없습니다. 시스템 서비스나 다른 VPN도 이런 인터페이스를 만들 수 있습니다.

종료 및 복구: 네트워크를 복원한 뒤 계속 점검하세요

인터넷이 끊기면 ‘TUN 끄기 → 시스템 프록시 끄기 → 클라이언트 정상 종료’ 순서로 진행하세요. 클라이언트가 이미 강제 종료된 경우 ‘시스템 설정’ → ‘네트워크’ → 현재 Wi-Fi 또는 이더넷 서비스 → ‘세부사항’ → ‘프록시’에서 127.0.0.1을 가리키는 설정이 남아 있는지 확인하고, 이번 클라이언트가 추가한 항목만 제거하세요.

시스템 ‘VPN’ 페이지에도 이번 클라이언트가 활성화한 연결이 남아 있는지 확인하세요. 조직에서 설정한 항목, 다른 VPN의 네트워크 확장, 직접 설치한 인증서는 삭제하지 마세요. 네트워크가 복구되면 클라이언트를 다시 열고 시스템 프록시를 먼저 확인한 다음 TUN을 별도로 테스트하세요. 여러 조건을 동시에 바꾸면 원인을 판단하기 어렵습니다.

문제를 문의할 때 macOS 버전, 칩 아키텍처, 클라이언트 및 커널 버전, 오류 발생 시점, 민감 정보를 가린 로그를 제공하세요. ‘최초 실행 실패’, ‘보조 서비스 설치 실패’, ‘키체인 접근 거부’, ‘TUN 라우팅 실패’를 명확히 구분하면 반복해서 재설치하는 것보다 원인 파악에 도움이 됩니다.