먼저 구분하세요: 실행 차단, 네트워크 승인, 키체인은 서로 다른 문제입니다
Mac용 Clash 클라이언트는 보통 그래픽 인터페이스와 프록시 코어, 필요에 따라 설치하는 백그라운드 보조 서비스를 포함합니다. 일부 클라이언트는 네트워크 확장도 사용합니다. ‘손상됨’ 경고는 앱 실행을 확인하는 단계에서 발생하고, 네트워크 확장 승인은 네트워크 연결을 제어할 때 필요하며, 키체인 팝업은 자격 증명 접근과 관련됩니다. 각각 해결 경로가 다르므로 관리자 암호를 반복해서 입력해 한꺼번에 해결할 수는 없습니다.
| 표시되는 증상 | 먼저 확인할 항목 | 우선 하지 말아야 할 일 |
|---|---|---|
| ‘손상되어 열 수 없음’ | 설치 파일 출처, 다운로드 상태, 서명 및 격리 속성 | 시스템 보안 검사를 바로 끄지 마세요 |
| ‘개발자를 확인할 수 없음’ | ‘개인정보 보호 및 보안’의 앱 허용 메뉴 | 구독 문제로 단정하지 마세요 |
| 앱은 열리지만 TUN이 시작되지 않음 | 코어 로그, 서비스 모드 또는 네트워크 확장 권한 | 키체인 항목을 먼저 삭제하지 마세요 |
| 키체인 접근 허용을 반복해서 요청함 | 요청 앱 이름, 항목 이름, 로그인 키체인 상태 | 정체를 알 수 없는 프로그램에 ‘항상 허용’을 선택하지 마세요 |
시작하기 전에 macOS 버전, 클라이언트 이름과 버전, 코어 이름, 오류 메시지 원문을 기록하세요. 아래 시스템 설정 경로는 macOS 13, 14, 15를 기준으로 합니다. 다른 버전에서는 메뉴 이름이 다를 수 있으니 실제 화면을 확인하세요. ‘Clash가 안 열림’이라고만 적으면 앱 실행 차단과 코어 시작 실패를 구분할 수 없습니다.
설치 전에 Apple Silicon·Intel 여부와 앱 위치 확인
아키텍처를 먼저 확인한 다음 권한을 설정하세요
- Apple 메뉴 → ‘이 Mac에 관하여’를 여세요. ‘칩 Apple M 시리즈’로 표시되면
arm64또는aarch64설치 파일을 우선 선택하세요. Intel 프로세서로 표시되면x64또는x86_64를 선택하세요. - Universal 표기 앱에는 보통 두 아키텍처가 모두 포함되어 있지만, 클라이언트가 요구하는 최소 macOS 버전도 확인해야 합니다. 지원 시스템 버전은 각 릴리스에 따라 다르며, ‘Clash’라는 이름만으로 결정되지 않습니다.
- 디스크 이미지를 연 뒤 앱을 ‘응용 프로그램’ 폴더로 드래그하고, 디스크 이미지를 추출한 다음 ‘응용 프로그램’에서 실행하세요. 다운로드 폴더나 압축 파일, 마운트된 설치 디스크에서 계속 실행하지 마세요.
- 시스템 프록시, 라우팅, DNS 설정을 여러 프로그램이 동시에 변경하지 않도록 다른 프록시 클라이언트를 종료하세요.
‘응용 프로그램’ → ‘유틸리티’ → ‘터미널’에서 다음 읽기 전용 명령을 실행해 시스템 버전과 현재 터미널 아키텍처를 기록할 수도 있습니다.
sw_vers -productVersion
uname -m
Apple Silicon에서 네이티브로 실행 중인 터미널은 보통 arm64, Intel Mac에서는 보통 x86_64를 출력합니다. 터미널이 Rosetta로 변환 실행 중이면 결과가 변환 환경을 나타낼 수 있으므로 ‘이 Mac에 관하여’를 기준으로 판단하세요. Apple Silicon에서 Intel 앱을 실행하려면 Rosetta가 필요할 수 있지만, Rosetta를 설치해도 손상된 서명이나 누락된 네트워크 권한은 복구되지 않습니다.
‘손상되어 열 수 없음’: 먼저 출처를 확인한 뒤 격리 속성을 살펴보세요
1단계: 신뢰할 수 있는 설치 파일 다시 받기
앱을 종료하고 프로젝트 관리자의 릴리스 페이지에서 설치 파일을 다시 다운로드하세요. 출처를 알 수 없는 재패키징 버전은 사용하지 마세요. 시스템에 ‘컴퓨터를 손상시킵니다’라는 경고가 표시되거나 악성 소프트웨어가 감지되면 실행을 중단하세요. 일반적인 개발자 확인 경고를 해제하는 방법을 적용해서는 안 됩니다.
‘손상됨’ 경고가 반드시 파일 전송 중단을 뜻하는 것은 아닙니다. 서명 문제, 앱 파일 변경 또는 Gatekeeper의 평가 결과 때문일 수도 있습니다. 격리 속성을 제거해도 앱 자체가 복구되는 것은 아니며, 프로그램이 안전하다는 증거도 아닙니다.
2단계: 시스템에서 허용 메뉴를 제공하는지 확인
앱을 한 번 실행해 본 다음 Apple 메뉴 → ‘시스템 설정’ → ‘개인정보 보호 및 보안’으로 이동해 아래쪽 ‘보안’ 영역을 확인하세요. 해당 앱의 ‘그래도 열기’가 표시되면 앱 이름과 출처를 먼저 확인한 뒤 시스템 안내에 따라 인증하세요. 모든 차단에 이 버튼이 표시되는 것은 아닙니다. 메뉴가 없다면 Gatekeeper를 전역으로 꺼서 강제로 실행하지 마세요.
3단계: 신뢰할 수 있는 앱에 한해 격리 속성 확인
아래 명령은 앱이 /Applications/Clash Verge.app에 설치된 경우를 예로 듭니다. 앱 이름이 다르면 Finder에서 실제 경로를 확인하거나 앱을 터미널로 드래그해 경로를 입력하세요. 경로가 맞지 않는 명령을 그대로 실행하지 마세요.
xattr -p com.apple.quarantine "/Applications/Clash Verge.app"
spctl --assess --type execute --verbose=4 "/Applications/Clash Verge.app"
codesign --verify --deep --strict --verbose=2 "/Applications/Clash Verge.app"
xattr은 격리 표시를 확인하는 명령입니다. 속성이 없다는 메시지는 해당 표시가 설정되지 않았다는 뜻일 뿐입니다. spctl은 시스템 실행 평가를 확인하고, codesign은 서명 무결성을 검사합니다. 뒤의 두 명령 결과는 릴리스 안내와 함께 판단해야 합니다. 서명 검사를 통과해도 출처가 신뢰할 만하다는 뜻은 아니며, 평가에 실패했다고 해서 곧바로 ‘격리 속성을 삭제해야 한다’고 결론 내릴 수도 없습니다.
xattr -d com.apple.quarantine "/Applications/Clash Verge.app"
이 명령은 지정한 앱 패키지 자체의 격리 속성만 제거합니다. 폴더 전체를 재귀적으로 처리하거나 전역 보안 정책을 변경하지 않습니다. 실행 후에도 문제가 계속되면 릴리스 안내와 서명 결과를 다시 확인하세요. ‘응용 프로그램’ 폴더 전체로 작업 범위를 넓히거나 관리자 권한을 임의로 추가하지 마세요.
네트워크 확장 허용 위치: 클라이언트가 실제로 사용하는 기능인지 먼저 확인
Clash는 클라이언트와 코어 생태계를 통칭하는 이름으로 쓰이며, 모든 앱이 같은 macOS 네트워크 방식을 사용하는 것은 아닙니다. 일부 클라이언트는 Network Extension을 사용하고, 일부 mihomo 그래픽 클라이언트는 권한이 필요한 보조 서비스를 통해 TUN 인터페이스를 만듭니다. 시스템에 네트워크 확장 스위치가 없다고 해서 설치 실패로 단정할 수는 없습니다.
네트워크 확장을 사용하는 클라이언트
- 먼저 클라이언트에서 VPN, 네트워크 제어 또는 TUN 관련 기능을 켜 시스템 권한 요청을 표시하세요. 해당 클라이언트가 실제로 이 방식을 사용하는 경우에만 관련 안내가 나타납니다.
- macOS 15에서는 ‘시스템 설정’ → ‘일반’ → ‘로그인 항목 및 확장 프로그램’ → ‘네트워크 확장’에서 해당 개발자 또는 앱이 허용되어 있는지 확인하세요.
- macOS 13, 14에서 시스템 소프트웨어가 차단되었다는 안내가 표시되면 ‘시스템 설정’ → ‘개인정보 보호 및 보안’에서 관련 메시지를 확인하세요. VPN 설정은 ‘시스템 설정’ → ‘VPN’에서도 확인할 수 있습니다. 확장 유형에 따라 설정 경로가 다를 수 있습니다.
- 개발자 이름을 확인한 후 승인하세요. 시스템에서 명시적으로 요청할 때만 재시동하면 됩니다. 클라이언트로 돌아가 기능을 다시 켜고 로그에 권한 오류가 남아 있는지 확인하세요.
‘VPN 구성 추가 허용’과 ‘시스템 확장 허용’은 같은 권한이 아닙니다. Clash TUN을 사용하려고 기본적으로 시동 보안을 낮추거나 SIP를 끄거나 알 수 없는 커널 확장을 설치하지 마세요. 일반적인 최신 사용자 공간 프록시 방식에서는 이런 조치를 통상적인 설치 조건으로 요구하지 않습니다.
조직에서 관리하는 기기에서는 직접 허용하지 못할 수 있습니다
스위치를 변경할 수 없거나 조직에서 관리한다고 표시되면 ‘시스템 설정’에서 기기 관리 정보를 확인하세요. MDM 정책은 VPN, 시스템 확장, 백그라운드 서비스를 제한할 수 있습니다. 이런 제한은 기기 관리자에게 문의해야 하며, 클라이언트를 반복해서 다시 설치해도 관리 정책을 우회할 수 없습니다.
서비스 모드 설치: 관리자 암호와 키체인 암호 요청은 다릅니다
mihomo 데스크톱 클라이언트는 TUN, 라우팅 또는 관련 네트워크 설정을 구성하기 위해 서비스 모드에서 권한이 필요한 보조 프로그램을 실행할 수 있습니다. 서비스 모드 설치에 성공했다고 TUN이 켜진 것은 아닙니다. 클라이언트가 해당 작업을 수행하는 데 필요한 권한을 갖추는 과정입니다.
- 앱이 ‘응용 프로그램’ 폴더에 있는지 확인한 뒤 그 위치에서 실행하세요.
- 클라이언트 ‘설정’에서 ‘서비스 모드’, ‘서비스 설치’ 또는 ‘서비스 복구’를 찾으세요. 예를 들어 Clash Verge Rev의 관련 메뉴는 보통 ‘설정’ → ‘서비스 모드’에 있습니다. 버튼 이름은 설치된 버전에 따라 다를 수 있습니다.
- 시스템에서 관리자 승인을 요청하면 앱 이름을 확인하세요. 입력할 암호는 현재 Mac에서 관리자 권한이 있는 계정의 암호입니다. 구독 암호나 Apple 계정 암호가 아닙니다.
- 설치가 끝나면 서비스 상태를 확인한 다음 TUN을 켜세요. 클라이언트 로그에서 권한 부족, 코어 시작 실패, 주소 충돌 등의 오류가 계속되는지 확인하세요.
업데이트 후 실행할 때마다 서비스를 다시 설치하라는 메시지가 나오면 먼저 이전 인스턴스를 종료한 뒤 클라이언트 자체의 서비스 제거 및 재설치 기능을 사용하세요. 출처를 알 수 없는 안내를 따라 /Library/LaunchDaemons의 파일을 직접 삭제하지 마세요. 다른 소프트웨어의 서비스를 잘못 지우면 새로운 문제가 생길 수 있습니다.
서비스 설치 실패는 오래된 보조 프로그램, 앱 위치 변경 또는 관리 정책 때문일 수도 있습니다. 이때는 암호를 반복해서 입력하지 말고 실패 시각과 오류 로그를 기록하세요. TUN을 끈 상태에서도 일반 시스템 프록시는 작동할 수 있으므로, 이를 통해 권한이 필요한 서비스 문제와 구독·노드 문제를 구분할 수 있습니다.
키체인 팝업: 요청 앱을 확인한 뒤 허용 여부를 결정하세요
‘앱이 키체인에 저장된 기밀 정보를 사용하려고 합니다’라는 메시지는 프로그램이 저장된 자격 증명이나 앱 키를 읽으려 한다는 뜻인 경우가 많습니다. 요청 내용은 클라이언트 구현에 따라 다르며 모든 Clash 클라이언트에서 나타나는 것은 아닙니다. 백그라운드 서비스 설치 시 진행하는 관리자 인증과는 별개의 절차입니다.
팝업이 나타나면 다음 순서로 확인하세요
- 요청 앱 확인: 방금 실행한 클라이언트 또는 식별 가능한 구성 요소인지 확인하세요. 낯선 이름이나 경로라면 먼저 ‘거부’를 선택한 뒤 출처를 확인하세요.
- 항목 이름 확인: 현재 앱이나 사용 중인 기능과 관련된 항목이어야 합니다. 관련 없는 브라우저, 메일 또는 다른 앱의 자격 증명에 접근하려 한다면 바로 허용하지 마세요.
- 암호 종류 확인: 로그인 키체인에는 보통 Mac 로그인 암호를 사용합니다. 계정 암호를 재설정했다면 이전 키체인에 예전 암호가 설정되어 있을 수 있습니다.
- 먼저 한 번만 허용: 기능이 정상적으로 복구되는지 확인한 다음 필요한 경우에만 ‘항상 허용’을 선택하세요. 민감한 항목의 접근 허용 목록에 모든 앱을 추가하지 마세요.
암호가 맞는데도 팝업이 반복되면 어떻게 하나요?
Spotlight에서 ‘키체인 접근’을 검색하고 ‘로그인’ 키체인을 선택한 다음 현재 클라이언트와 관련된 항목을 찾으세요. 키체인이 잠겨 있다면 먼저 잠금을 해제하고 다시 시도하세요. 클라이언트 업데이트 후 문제가 시작됐다면 서명 식별자나 항목 접근 제어가 변경되었을 수 있으니 해당 버전의 안내부터 확인하세요.
용도를 정확히 알고 있고 다시 로그인하거나 설정을 가져올 수 있는 경우에만 현재 앱과 관련된 단일 항목 삭제를 고려하세요. 삭제 전에 내보낼 수 있는 설정을 백업하세요. 기본 키체인 전체를 먼저 재설정하면 다른 앱에 저장된 암호도 영향을 받습니다.
승인 후 시스템 프록시와 TUN을 나눠서 점검하세요
시스템 프록시와 TUN을 동시에 켜고 어느 쪽이 작동하는지 추측하지 마세요. 먼저 시스템 프록시를 테스트한 다음 끄고 TUN을 테스트하세요. 매번 조건 하나만 바꿔야 실제 문제 지점을 확인할 수 있습니다.
1차 테스트: 시스템 프록시 포트 확인
클라이언트에서 실제 혼합 프록시 포트를 확인하세요. 아래 예시는 로컬 주소 127.0.0.1:7890을 사용합니다. 클라이언트에 다른 포트가 표시되면 실제 값으로 바꾸세요. 먼저 시스템 프록시를 켜고 터미널에서 다음을 실행하세요.
scutil --proxy
lsof -nP -iTCP:7890 -sTCP:LISTEN
curl -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com
scutil --proxy는 시스템 프록시 설정을 확인하고, lsof는 포트가 연결을 대기 중인지 확인합니다. 마지막 명령은 HTTP 프록시를 명시해 요청을 보냅니다. HTTP 응답을 받으면 해당 요청 경로가 응답했다는 뜻이지만 모든 앱이 시스템 프록시를 사용한다는 의미는 아닙니다. 터미널 도구가 macOS 그래픽 인터페이스의 프록시 설정을 자동으로 따르는 것도 아닙니다.
2차 테스트: TUN만 따로 확인
- 시스템 프록시를 잠시 끄고 현재 테스트용 터미널에 직접 설정한 프록시 환경 변수를 지우세요.
- TUN을 켜고 로그에서 인터페이스 생성, 라우팅, DNS 초기화 결과를 확인하세요.
--proxy없이 요청을 다시 보내고 클라이언트의 연결 기록에서 대상, 적용된 규칙, 출구 정책을 확인하세요.
unset http_proxy https_proxy all_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY
curl -I --connect-timeout 10 --max-time 20 https://example.com
이 unset 명령은 현재 터미널 세션에만 적용됩니다. 일반 웹페이지는 직접 연결로도 열릴 수 있으므로 ‘웹페이지가 열린다’는 사실만으로 TUN이 작동한다고 판단할 수 없습니다. 연결 기록을 함께 확인하세요. 시스템에 utun 인터페이스가 있다고 해서 Clash가 만든 것이라고 단정할 수도 없습니다. 다른 VPN이나 시스템 기능도 같은 인터페이스를 만들 수 있습니다.
TUN을 켠 뒤 일부 도메인에 접속할 수 없다면 DNS, 규칙, 다른 VPN과의 충돌을 확인하세요. 권한 문제는 보통 시작 단계에서 명확한 오류로 나타납니다. 특정 사이트만 시간 초과된다면 노드, 적용 규칙, DNS 응답을 추가로 확인하면 됩니다. 앱의 격리 속성을 다시 처리할 필요는 없습니다.
자주 묻는 질문과 복구 방법
앱이 열리는데 관리자 암호를 왜 입력해야 하나요?
실행 검사를 통과했다는 것은 macOS에서 앱을 실행할 수 있다는 뜻일 뿐입니다. 권한이 필요한 보조 서비스를 설치하는 작업은 별개이며 관리자 승인이 필요할 수 있습니다. 팝업이 서비스 설치 중 나타났는지 키체인 접근 중 나타났는지 먼저 확인한 뒤 해당 암호를 입력하세요.
‘네트워크 확장’이 보이지 않으면 설치 파일을 잘못 고른 건가요?
꼭 그렇지는 않습니다. 클라이언트가 네트워크 확장 방식과 보조 서비스 방식 중 무엇을 사용하는지 먼저 확인하세요. mihomo와 권한이 필요한 서비스로 TUN을 구현하는 클라이언트는 별도의 네트워크 확장 항목을 제공하지 않을 수 있습니다. 아키텍처 문제는 설치 파일 이름, 시스템 정보, 실행 오류를 확인해 판단하세요.
Clash를 종료한 뒤 인터넷이 안 되면 무엇부터 복구해야 하나요?
먼저 클라이언트로 돌아가 TUN과 시스템 프록시를 끈 다음 정상적으로 종료하세요. 앱을 실행할 수 없다면 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’에서 종료된 로컬 포트를 가리키는 HTTP, HTTPS 또는 SOCKS 프록시가 남아 있는지 확인하세요. 해당 클라이언트가 설정한 것으로 확인된 항목만 되돌리고, 회사에서 관리하는 프록시 설정은 함부로 삭제하지 마세요.
‘신뢰할 수 있는 설치 파일 → 올바른 아키텍처 → 실행 허용 → 서비스 또는 확장 승인 → 키체인 → 네트워크 테스트’ 순서로 점검하세요. 각 단계를 마칠 때마다 다시 테스트하고 구체적인 오류를 기록하세요. 반복 작업을 줄일 수 있고, 도움이 필요할 때 문제가 어느 단계에서 멈췄는지 정확히 설명할 수 있습니다.