Clash macOS 설치 후 네트워크 확장 프로그램 및 키체인 권한 설정

먼저 네 가지 권한을 구분하세요: 앱 실행, 보조 서비스, 네트워크 확장 프로그램, 키체인

macOS용 Clash 클라이언트는 네트워크 트래픽을 처리하는 방식이 서로 다릅니다. GUI에서 mihomo 코어를 호출하거나, 권한이 필요한 보조 서비스 또는 Network Extension을 사용할 수 있습니다. 다른 클라이언트의 권한 안내 화면을 참고하기 전에 현재 사용 중인 앱의 이름과 버전, 실행 모드를 확인하고 같은 절차가 필요한지 판단하세요.

먼저 Apple 메뉴 → ‘이 Mac에 관하여’에서 macOS 버전과 칩 종류를 확인하고, 클라이언트의 ‘정보’ 화면에서 앱 버전을 확인하세요. 코어 정보 화면이 있다면 mihomo 버전도 기록합니다. Apple Silicon용과 Intel용 설치 파일은 각각 맞는 아키텍처를 선택해야 합니다. 아키텍처가 맞지 않는 문제는 대개 실행 호환성 문제이므로 네트워크 확장 프로그램 승인으로 해결되지 않습니다.

경고 또는 기능	관련 권한	처리 시점
개발자를 확인할 수 없음, 앱이 손상됨	Gatekeeper, 서명, 다운로드 격리 속성	앱을 처음 열기 전
보조 도구 설치, 관리자 인증 요청	권한이 필요한 보조 서비스 또는 서비스 모드	클라이언트에서 서비스 설치를 명시적으로 요청할 때
시스템 확장 프로그램 승인, VPN 구성 추가	시스템 확장 프로그램, 네트워크 확장 프로그램 또는 VPN 구성	해당 기능을 처음 활성화할 때
키체인의 특정 항목에 접근	지정된 자격 증명 읽기 권한	앱에서 저장된 자격 증명을 읽을 때

첫 실행: 개발자 확인 경고와 ‘손상됨’ 알림을 따로 처리하세요

먼저 설치 위치와 다운로드 출처를 확인하세요

실행 중인 이전 버전을 종료하고, 디스크 이미지에서 앱을 ‘응용 프로그램’ 폴더로 드래그해 옮기세요. 설치 이미지에서 앱을 계속 실행하지 마세요.
설치 이미지를 추출한 다음 ‘응용 프로그램’ 폴더에서 앱을 여세요. 그래야 이후 권한 요청이 임시로 마운트된 경로의 복사본을 가리키는 일을 피할 수 있습니다.
다운로드 출처, 앱 이름, 프로세서 아키텍처를 확인하세요. 시스템에서 악성 소프트웨어가 포함되어 있다고 명시적으로 경고하면 실행을 중단하고 출처를 다시 확인하세요.

‘개발자를 확인할 수 없음’과 같은 경고가 표시되면 macOS 13 Ventura, 14 Sonoma 및 이후 버전에서는 보통 ‘시스템 설정’ → ‘개인정보 보호 및 보안’의 보안 섹션에 최근 차단된 앱에 대한 ‘그래도 열기’가 표시됩니다. macOS 12 Monterey에서는 ‘시스템 환경설정’ → ‘보안 및 개인정보 보호’ → ‘일반’에서 확인할 수 있습니다. 관련 차단이 발생했고 시스템에서 허용하는 경우에만 버튼이 나타납니다.

macOS 15 Sequoia에서는 일부 서명되지 않았거나 공증되지 않은 소프트웨어의 실행 절차가 변경되었습니다. 이전 안내처럼 Control 키를 누른 채 ‘열기’를 클릭하는 방법에만 의존하지 마세요. 현재 시스템의 경고 화면에서 보안 설정으로 이동해 앱을 확인한 뒤 승인하세요. 조직에서 관리하는 Mac은 우회가 제한될 수 있으므로 기기 관리자에게 문의하세요.

‘손상됨’ 경고는 일반적인 권한 설정 문제가 아닙니다

이 경고는 패키지 내용의 이상, 서명 만료 또는 다운로드 격리 처리와 관련이 있을 수 있습니다. 우선 현재 앱을 삭제하고 사용 중인 시스템과 호환되는 배포 파일을 다시 받으세요. 시스템 전체의 보안 검사를 먼저 끄지 마세요. 원인을 더 확인하려면 터미널에 아래 명령의 앞부분을 입력한 다음, ‘응용 프로그램’ 폴더에 있는 실제 앱을 터미널로 드래그해 경로를 붙여 넣으세요. 각 명령은 따로 실행해야 합니다:

터미널 · 읽기 전용 점검

spctl --assess --type execute --verbose=4
codesign --verify --deep --strict --verbose=2
xattr -l

위 명령은 모두 앱 경로를 인수로 받아야 합니다. 세 줄을 한꺼번에 붙여 넣어 완전한 진단 명령처럼 실행하면 안 됩니다. 첫 번째 명령은 시스템의 실행 평가 결과를 확인하고, 두 번째 명령은 기존 서명을 검증하며, 세 번째 명령은 확장 속성을 나열합니다. com.apple.quarantine이 표시된다는 것은 격리 표시가 있다는 뜻일 뿐, 앱이 유해하거나 안전하다는 증거는 아닙니다. 서명 검증에 성공해도 시스템 공증을 통과했다는 의미는 아닙니다.

네트워크 확장 프로그램 승인: macOS 버전별 확인 위치

먼저 클라이언트에서 확장 프로그램이 필요한 기능을 한 번 실행한 뒤 시스템 알림을 확인하세요. 시스템 확장 프로그램은 보통 앱이 활성화 요청을 보내야 등록됩니다. 앱을 ‘응용 프로그램’ 폴더로 복사하는 것만으로는 승인 대기 항목이 생기지 않을 수 있습니다. 승인하기 전에 개발자 이름과 클라이언트의 배포 안내를 확인하세요. 알림이 표시된 시점만으로 요청 출처를 판단해서는 안 됩니다.

macOS 버전	주요 확인 위치	확인할 내용
12 Monterey	시스템 환경설정 → 보안 및 개인정보 보호 → 일반	시스템 소프트웨어 차단 알림이 나타나면 설정을 잠금 해제하고 개발자를 확인한 뒤 허용하세요
13 Ventura / 14 Sonoma	시스템 설정 → 개인정보 보호 및 보안	보안 섹션에서 확장 프로그램 승인 알림을 확인하세요
15 Sequoia	시스템 설정 → 일반 → 로그인 항목 및 확장 프로그램 → 네트워크 확장 프로그램	세부 정보에서 해당 앱의 네트워크 확장 프로그램을 확인하고 활성화하세요

정확한 위치는 확장 프로그램의 패키징 방식과 macOS 세부 버전에 따라 달라집니다. ‘VPN 구성 추가’ 알림이 나타나면 요청한 앱 이름을 확인한 뒤 허용 여부를 결정하세요. VPN 구성은 시스템의 ‘VPN’ 또는 ‘네트워크’ 관련 화면에서 확인할 수 있습니다. VPN 구성 승인과 시스템 확장 프로그램 승인은 별개의 설정이며, 콘텐츠 필터는 TUN 터널과 같지 않습니다.

클라이언트를 켜 둔 상태에서 해당 네트워크 기능을 활성화하세요.
시스템 안내에 따라 설정으로 이동해 앱과 일치하는 개발자 또는 확장 프로그램을 승인하고, 필요한 인증을 완료하세요.
클라이언트로 돌아와 해당 기능을 껐다가 다시 켜세요. 컴퓨터 재시동은 시스템에서 명시적으로 요구할 때만 하세요.
승인 대기 항목이 없다면 클라이언트 로그, 확장 프로그램 설치 안내, 서비스 상태를 확인하세요. 아직 요청되지 않은 권한을 찾느라 같은 화면을 반복해서 확인하지 마세요.

systemextensionsctl list 명령으로 시스템 확장 프로그램 메커니즘에 등록된 항목과 상태를 확인할 수 있습니다. 다만 이 명령이 모든 네트워크 구성 요소를 보여 주는 것은 아닙니다. Network Extension의 종류에 따라 전부 표시되지 않을 수 있으며, 권한이 필요한 서비스 방식의 TUN은 목록에 항목이 있는지만으로 정상 여부를 판단할 수 없습니다.

키체인 알림: 요청 프로세스, 항목 이름, 암호 유형을 확인하세요

키체인 접근 알림에는 보통 두 가지 핵심 정보가 표시됩니다. 접근을 요청한 프로세스와 읽으려는 항목입니다. 해당 항목은 구독 자격 증명, 프록시 인증 정보 또는 앱 자체의 접근 토큰을 저장하는 데 쓰일 수 있으며, 정확한 용도는 클라이언트 구현에 따라 다릅니다. 세부 정보를 펼쳐 내용을 확인한 뒤 ‘허용’ 또는 ‘항상 허용’을 선택하세요.

세 가지 선택 항목의 의미

거부: 이번 요청에 자격 증명을 제공하지 않습니다. 앱에서 다시 로그인하거나 인증 정보를 입력하라고 하거나, 자격 증명을 읽지 못했다는 메시지가 표시될 수 있습니다.
허용: 이번 접근만 승인합니다. 다음에 읽을 때 다시 물어볼 수 있습니다.
항상 허용: 해당 항목에 현재 앱의 접근 권한을 저장합니다. 확인된 앱에서 계속 읽어야 하는 경우에 적합합니다.

알림에서 ‘로그인’ 키체인을 잠금 해제하라고 하면 일반적으로 현재 사용자 계정의 로그인 암호가 필요합니다. 구독 암호나 Apple 계정 암호가 아닙니다. 다른 방식으로 로그인 암호를 재설정했다면 키체인 암호는 이전 암호로 남아 있을 수 있습니다. 새 암호를 계속 입력해도 이전 키체인이 잠금 해제되지 않을 수 있습니다.

알림이 반복되면 다음 순서로 원인을 확인하세요

Finder에서 ‘이동’ → ‘유틸리티’ → ‘키체인 접근’을 선택하세요. Spotlight 검색으로 열어도 됩니다.
‘로그인’ 키체인을 선택한 다음 알림에 표시된 항목 이름을 검색하세요. 관련 없는 암호를 한꺼번에 삭제하지 마세요.
해당 항목을 열고 ‘접근 제어’에서 접근이 허용된 앱을 확인하세요. 일부 항목에는 동일한 편집 옵션이 없을 수 있으므로 실제 화면을 기준으로 확인해야 합니다.
앱 복사본이 두 개 설치되어 있는지, 업데이트 후 서명 식별 정보가 바뀌었는지 확인하세요. 먼저 설치 위치를 하나로 정리한 뒤 접근을 다시 요청하세요.

기본 키체인을 재설정하면 다른 저장된 자격 증명에도 영향을 줍니다. 따라서 첫 번째 문제 해결 방법으로 사용해서는 안 됩니다. 클라이언트 전용 항목을 삭제해야 한다면 관련 자격 증명을 다시 입력할 수 있는지 먼저 확인하고 항목 이름을 기록하세요. 삭제 후 클라이언트가 다시 저장하도록 하세요. 다른 앱의 접근 제어를 변경해 알림을 우회하지 마세요.

TUN 권한: 시스템 프록시부터 확인한 뒤 가상 인터페이스를 활성화하세요

시스템 프록시는 macOS 프록시 설정을 따르는 앱에 HTTP, HTTPS 등의 프록시 연결을 제공합니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 처리합니다. 터미널 도구가 시스템 프록시를 사용하는지는 도구마다 다릅니다. 따라서 ‘브라우저에서는 되지만 명령줄에서는 안 됨’만으로 권한 누락이라고 판단할 수 없습니다.

먼저 TUN을 끄고 로컬 프록시 포트와 규칙을 확인한 다음 라우팅을 처리하세요. 아래 예시에서는 127.0.0.1:7890을 사용하지만, 실제로는 클라이언트에 표시된 HTTP 또는 mixed 포트를 확인해야 합니다. 7890이 모든 클라이언트의 기본 포트는 아닙니다.

터미널 · 예시 포트 및 명시적 프록시 확인

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

lsof에 리스닝 항목이 표시되면 해당 프로세스가 현재 클라이언트인지 확인하세요. 아무것도 표시되지 않으면 먼저 코어 실행 여부와 실제 포트를 확인하세요.
scutil --proxy: 현재 적용 중인 시스템 프록시 정보를 확인합니다. TUN 라우팅이 설정되었는지는 확인할 수 없습니다.
curl에서 응답 헤더가 반환되면 이번 명시적 프록시 요청에 응답이 있었다는 뜻입니다. 요청 결과를 정확히 판단하려면 상태 코드와 클라이언트 연결 기록도 함께 확인하세요.

서비스와 실행 중인 설정 확인

클라이언트가 mihomo 권한 서비스를 사용하는 경우, 설정에서 서비스 설치 메뉴를 찾아 관리자 인증을 완료한 뒤 TUN을 활성화하세요. 메뉴 이름은 ‘서비스 모드’, ‘보조 서비스’, ‘서비스 설치’ 등으로 표시될 수 있으니 현재 버전의 실제 화면을 확인하세요. GUI 전체를 관리자 권한으로 계속 실행하지 마세요.

mihomo 런타임 필드 · 필요한 항목만 병합

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true

아래는 TUN 관련 필드만 포함하며, 단독으로 실행할 수 있는 완전한 설정이 아닙니다. stack에서 사용할 수 있는 값과 동작은 현재 코어 버전을 기준으로 확인하세요. 이 필드만으로 시스템 권한을 대신할 수는 없습니다. 클라이언트가 시작 시 구독 설정의 같은 이름 필드를 덮어쓸 수 있으므로, 다운로드한 YAML 파일만 볼 것이 아니라 최종 적용된 설정을 확인해야 합니다.

활성화 후 ifconfig로 인터페이스를 확인하고, netstat -rn -f inet으로 IPv4 라우팅을, scutil --dns로 리졸버 상태를 확인할 수 있습니다. macOS 자체나 다른 VPN도 utun 인터페이스를 만들 수 있으므로 utun0 또는 다른 번호가 보인다는 사실만으로 현재 클라이언트의 인터페이스라고 단정할 수 없습니다. 활성화 전후의 변화, 클라이언트 로그, 실제 연결 기록을 함께 비교하세요.

권한 설정 후에도 연결되지 않으면 증상별로 범위를 좁히세요

확인된 증상	우선 확인할 항목	다음 단계
앱은 열리지만 로컬 포트가 리스닝하지 않음	코어 시작 로그, 설정 파싱 오류, 포트 충돌	시작 오류를 해결한 뒤 설정을 다시 불러오세요
명시적 프록시는 작동하지만 브라우저가 프록시를 사용하지 않음	시스템 프록시 상태, 브라우저 자체의 프록시 설정	현재 네트워크 서비스와 브라우저 확장 프로그램 설정을 확인하세요
시스템 프록시는 작동하지만 TUN 활성화에 실패함	권한 서비스, 확장 프로그램 상태, 인터페이스 또는 라우팅 오류	클라이언트의 실제 구현 방식에 맞는 권한을 확인하세요
TUN을 켠 뒤 도메인에 연결할 수 없음	DNS 설정, 조회 로그, 다른 VPN의 DNS 설정	네트워크 트래픽을 처리하는 구성 요소를 하나만 남기고 다시 테스트하세요
업데이트 후 키체인 알림이 반복됨	앱 복사본, 서명 식별 정보, 항목 접근 제어	요청 프로세스를 확인한 뒤 해당 항목의 접근 권한을 다시 부여하세요

구독을 성공적으로 가져왔다는 것은 클라이언트가 설정을 받았다는 뜻일 뿐, 노드 인증, DNS, 정책 그룹 선택, 시스템 라우팅이 모두 정상이라는 의미는 아닙니다. 연결 화면에서 대상 도메인에 적용된 규칙과 트래픽 출구를 확인하세요. DIRECT 규칙이 적용됐다면 시스템 확장 프로그램을 다시 승인하기보다 먼저 규칙 순서를 확인해야 합니다.

충돌을 점검할 때는 다른 VPN, 콘텐츠 필터 또는 패킷 캡처 도구를 먼저 일시 중지한 다음 현재 클라이언트만 켜세요. 한 번에 조건 하나만 변경하고 변경 전후의 로그 시간을 기록하세요. 앱 재설치, 키체인 삭제, DNS 변경을 동시에 진행하면 연결이 복구되더라도 어떤 조치가 실제로 효과가 있었는지 알기 어렵습니다.

업데이트 및 제거: 서비스 상태를 확인하고 복구할 수 있도록 네트워크 설정을 보존하세요

업데이트 전: 클라이언트 버전, 코어 버전, 현재 실행 모드를 기록하세요. 덮어쓴 뒤 사라지지 않도록 보존할 로컬 규칙을 저장해 두세요.
업데이트 후: 먼저 앱을 열고 서비스 업데이트가 필요한지 확인하세요. 새 권한 요청이 나타난 경우에만 내용을 확인한 뒤 다시 승인하세요.
제거 전: 클라이언트에서 TUN과 시스템 프록시를 끄고, 앱에 내장된 메뉴로 보조 서비스를 제거하거나 확장 프로그램을 비활성화한 다음 앱을 종료하세요.
제거 후: macOS 13 및 이후 버전에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’에서 남은 설정을 확인할 수 있습니다. macOS 12에서는 ‘시스템 환경설정’ → ‘네트워크’ → 현재 서비스 → ‘고급’ → ‘프록시’를 확인하세요.

다른 VPN의 구성을 삭제하지 말고, 127.0.0.1이 보인다고 무조건 설정을 지우지도 마세요. 해당 주소와 포트가 제거한 클라이언트에서 설정한 값인지 먼저 확인하세요. 업무용 네트워크에는 관리자가 설정한 별도의 프록시가 있을 수 있습니다. 기기가 관리 대상이라면 관련 설정을 관리자에게 확인하세요.

문제 해결을 마친 뒤에는 다음 네 가지를 각각 확인할 수 있어야 합니다. 앱이 정상적으로 실행되는지, 현재 모드에서 확장 프로그램이 필요한지, 키체인 요청이 확인된 앱에서 온 것인지, 프록시 또는 TUN 트래픽에 예상한 규칙이 적용되는지입니다. 비밀번호를 반복 입력하거나 계속 재시동하는 것보다 네 항목을 따로 확인하는 편이 원인을 찾기 쉽습니다.