macOS FlClash 설치 권한 완벽 가이드: 네트워크 확장 승인 및 키체인 팝업 해결

먼저 macOS 권한을 세 가지로 구분하기

macOS에서 FlClash를 실행하면 Gatekeeper, 관리자 승인, VPN 또는 네트워크 확장 승인이 필요할 수 있습니다. 각각 담당하는 시스템 구성 요소가 다르므로 하나의 암호 팝업으로 설명할 수 없습니다. 시스템 프록시만 사용하는 경우에는 일반적으로 앱 실행과 프록시 설정만 완료하면 됩니다. TUN 모드를 활성화할 때만 가상 네트워크 인터페이스, 라우팅 및 DNS 제어가 추가로 필요합니다.

알림 유형	발생 시점	처리 위치
개발자를 확인할 수 없거나 열 수 없음	앱 최초 실행	「시스템 설정」→「개인정보 보호 및 보안」
관리자 이름 및 암호	보조 구성 요소 설치 또는 TUN 활성화	macOS 시스템 승인 창
VPN 구성 또는 네트워크 확장 추가	TUN 최초 활성화	「시스템 설정」→「네트워크」→「VPN」 또는 확장 관리 페이지
키체인 항목 접근	저장된 자격 증명 읽기 또는 구성 요소 식별 정보 변경	「키체인 접근」 앱

설치 전 확인: 칩, 설치 위치 및 이전 버전 상태

Apple Silicon 또는 Intel 아키텍처 확인

「Apple 메뉴」→「이 Mac에 관하여」를 엽니다. 칩 항목에 Apple M1, M2, M3, M4 또는 이후 Apple 시리즈가 표시되면 arm64 설치 패키지를 선택해야 합니다. 프로세서 항목에 Intel이 표시되면 x64 또는 amd64 설치 패키지를 선택합니다. 아키텍처를 잘못 선택하면 앱이 실행되지 않거나 실행 직후 종료되며, Rosetta 변환이 필요할 수 있습니다.

앱을 “응용 프로그램”으로 이동하기

다운로드한 DMG 또는 압축 해제한 폴더를 엽니다.
FlClash를 Finder 사이드바의 「응용 프로그램」으로 드래그합니다.
「응용 프로그램」 폴더에서 실행하고, DMG나 다운로드 폴더 또는 외장 디스크에서 계속 실행하지 마세요.
이전 버전이 실행 중이면 먼저 메뉴 막대에서 종료한 다음 앱 파일을 교체합니다.

설치 경로를 고정하는 것은 중요합니다. macOS는 키체인 접근 제어, 코드 서명 식별 정보와 앱 경로를 함께 사용해 권한을 판단합니다. 앱을 매번 다른 폴더에서 실행하면 같은 키체인 항목에 접근해도 시스템이 계속 허용 여부를 물을 수 있습니다.

업데이트 전에 먼저 프록시 끄기

시스템 프록시가 이전 프로세스를 계속 가리키는 상태에서 앱을 덮어쓰면 사용할 수 없는 로컬 프록시 주소가 남을 수 있습니다. 먼저 FlClash에서 시스템 프록시와 TUN을 끄고 앱을 종료하는 것이 좋습니다. 시스템 프록시의 일반적인 수신 주소는 127.0.0.1:7890이지만 실제 포트는 현재 설정의 mixed-port를 기준으로 확인해야 합니다.

“개발자를 확인할 수 없음” 및 “앱이 손상됨”의 올바른 처리

최초 실행이 차단되면 먼저 Finder의 「응용 프로그램」에서 FlClash를 찾고, Control 키를 누른 채 앱 아이콘을 클릭한 다음 「열기」를 선택합니다. 그래도 Gatekeeper가 차단하면 「시스템 설정」→「개인정보 보호 및 보안」으로 이동해 아래쪽에서 방금 차단된 앱 기록을 찾고 「그래도 열기」를 클릭한 뒤 로그인 암호 또는 Touch ID로 확인합니다.

방금 FlClash를 직접 실행한 후에만 이 차단 기록을 처리하세요.
팝업에 표시된 앱 이름이 Finder의 파일 이름과 일치하는지 확인합니다.
한 번 허용한 뒤에는 「응용 프로그램」에서 다시 엽니다.
새 폴더에 반복해서 압축을 풀지 마세요. 시스템이 새로운 앱 복사본으로 인식할 수 있습니다.

「개인정보 보호 및 보안」 페이지에 “그래도 열기”가 표시되지 않으면 Finder에서 다시 한 번 실행해 해당 기록을 생성하세요. 기업에서 관리하는 Mac은 MDM 정책의 제한을 받을 수도 있습니다. 이 경우 버튼이 숨겨지거나 비활성화되며, 기기 관리자가 앱을 승인해야 합니다. 로컬 일반 계정 설정을 수정하는 것으로 해결되지 않습니다.

네트워크 확장 승인: 시스템 프록시에서 TUN까지

시스템 프록시 모드의 작동 범위

시스템 프록시 모드는 macOS의 HTTP, HTTPS 또는 SOCKS 프록시를 로컬 수신 포트로 지정합니다. 일반적인 설정은 127.0.0.1:7890이고, 제어 인터페이스는 보통 127.0.0.1:9090입니다. 제어 인터페이스는 클라이언트와 mihomo 커널이 통신하는 용도이며 웹 프록시 포트로 입력하면 안 됩니다.

mixed-port: 7890
mode: rule
allow-lan: false
external-controller: 127.0.0.1:9090

이 설정을 사용하면 Safari, Chrome과 시스템 프록시를 읽는 앱이 규칙 기반 분배를 따릅니다. 터미널의 curl, 패키지 관리자 또는 일부 게임은 시스템 프록시를 읽지 않을 수 있으므로 “브라우저는 되지만 터미널은 직접 연결됨”이 반드시 오류를 뜻하지는 않습니다.

TUN 최초 활성화 승인 순서

FlClash의 「설정」→「네트워크 설정」으로 이동해 TUN 모드를 활성화합니다. macOS 버전에 따라 관리자 승인, VPN 구성 추가, 네트워크 확장 허용 단계가 서로 다른 순서로 표시될 수 있습니다. 팝업이 나타나면 FlClash를 계속 실행 상태로 두고 스위치를 연속해서 클릭하지 마세요. 여러 승인 요청이 동시에 생성될 수 있습니다.

관리자 승인 창에 현재 Mac 관리자 계정의 암호를 입력합니다.
VPN 구성을 추가할지 묻는 창이 나타나면 허용을 선택합니다.
macOS 15 및 이후 버전에서는 「시스템 설정」→「일반」→「로그인 항목 및 확장 프로그램」→「네트워크 확장」에서 상태를 확인할 수 있습니다.
macOS 13, 14에서 승인 알림이 표시되면 「시스템 설정」→「개인정보 보호 및 보안」으로 이동해 허용을 완료합니다.
「시스템 설정」→「네트워크」→「VPN」으로 돌아가 같은 이름의 항목이 연결과 연결 해제를 계속 반복하지 않는지 확인합니다.
FlClash로 돌아가 커널이 실행된 후 연결을 테스트합니다.

승인이 완료되면 시스템이 일반적으로 utun 가상 인터페이스를 생성합니다. 번호는 고정되지 않으며 utun3, utun7 또는 다른 값일 수 있습니다. 번호가 바뀌었다고 설치에 문제가 있는 것은 아닙니다. 실제로 확인해야 할 항목은 기본 라우팅, DNS 요청, 그리고 FlClash 커널이 모두 정상적으로 동작하는지 여부입니다.

mihomo TUN 설정의 핵심 필드

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip

auto-route는 라우팅을 자동으로 작성하고, auto-detect-interface는 현재 출구 네트워크 인터페이스를 식별하며, dns-hijack는 지정된 DNS 트래픽을 커널에서 처리하도록 전달합니다. FlClash가 화면 설정에 따라 실행 설정을 생성할 수 있으므로 구독 파일과 화면 설정에서 서로 충돌하는 TUN 필드를 동시에 관리하지 마세요.

키체인이 계속 암호를 요구할 때: 요청 출처 확인

키체인 팝업에서는 먼저 “어떤 프로세스가 어떤 항목을 요청하는지” 확인해야 합니다. 정상적인 시스템 창에는 항목 이름과 접근을 요청한 앱이 표시됩니다. FlClash가 아직 실행되지 않았는데 팝업이 나타난다면 로그인 항목, 이전 버전의 보조 구성 요소와 다른 네트워크 도구를 먼저 확인하세요. 현재 앱의 요청이라고 바로 단정하면 안 됩니다.

먼저 한 번 “허용”해 보기

처음 나타났을 때 「허용」을 선택하고 현재 macOS 로그인 암호를 입력한 뒤, 같은 작업을 다시 수행할 때 팝업이 재발하는지 확인할 수 있습니다. 앱이 고정된 /Applications 경로에 있고 요청 항목이 명확하며 지속적인 접근이 필요한 경우에만 「항상 허용」을 고려하세요. 앱을 교체하거나 이동했거나 서명 식별 정보가 바뀌면 키체인이 다시 확인을 요구할 수 있습니다.

“로그인” 키체인이 잠겨 있는지 확인

「응용 프로그램」→「유틸리티」→「키체인 접근」을 엽니다.
왼쪽에서 「로그인」 키체인을 선택합니다.
키체인이 잠겨 있으면 마우스 오른쪽 버튼으로 클릭해 잠금 해제를 선택하고 현재 로그인 암호를 입력합니다.
팝업에 표시된 항목 이름으로 검색하고, 추측만으로 인증서나 암호를 일괄 삭제하지 마세요.
대상 항목을 이중 클릭한 뒤 「접근 제어」에서 이전 앱 경로가 남아 있는지 확인합니다.

Mac 로그인 암호를 변경한 뒤에도 로그인 키체인의 암호가 이전 암호로 남을 수 있습니다. 새 암호로 시스템 로그인은 성공하지만 여러 앱이 계속 이전 키체인 암호를 요구하는 것이 대표적인 증상입니다. 이 경우 먼저 “로그인” 키체인의 암호를 변경해 현재 계정 암호와 일치시키세요. 기본 키체인을 재설정하면 브라우저 암호, Wi-Fi 자격 증명 및 다른 앱의 저장 항목에 영향을 주므로 최후의 수단으로 사용하고, 실행 전에 사용 가능한 백업이 있는지 확인해야 합니다.

반복 요청을 일으키는 세 가지 조건 피하기

서로 다른 폴더에 있는 여러 FlClash.app을 동시에 보관하고 번갈아 실행하지 마세요.
업데이트할 때는 먼저 이전 프로세스를 종료한 다음 「응용 프로그램」에 있는 기존 버전을 덮어씁니다.
키체인 항목을 삭제했다면 앱도 함께 재시작하세요. 이전 프로세스가 만료된 참조를 계속 보유하게 두지 마세요.

승인 완료 후 확인할 네 가지 항목

로컬 수신 포트 확인

FlClash에서 커널 상태가 실행 중인지 확인한 다음 터미널에서 아래 명령을 실행합니다. 설정에서 7890이 아닌 포트를 사용한다면 실제 mixed-port 값으로 바꿔야 합니다.

lsof -nP -iTCP:7890 -sTCP:LISTEN
curl -I -x http://127.0.0.1:7890 https://example.com

첫 번째 명령은 해당 커널 프로세스가 수신 대기 중임을 표시해야 하고, 두 번째 명령은 HTTP 응답 헤더를 반환해야 합니다. 포트가 수신 대기 중이 아니면 커널 실행 로그를 우선 확인하고, 포트는 열려 있지만 요청 시간이 초과되면 구독 노드, 프록시 그룹 선택 및 규칙 매칭을 점검하세요.

시스템 프록시가 남아 있는지 확인

「시스템 설정」→「네트워크」→현재 사용 중인 Wi-Fi 또는 이더넷→「세부사항」→「프록시」를 엽니다. FlClash에서 시스템 프록시를 활성화하면 여기에 로컬 주소와 포트가 표시될 수 있습니다. 앱을 종료한 뒤에도 127.0.0.1:7890이 남아 있으면 시스템 프록시를 읽는 모든 프로그램이 이미 중지된 포트에 연결을 시도합니다.

네트워크 확장 및 VPN 상태 확인

systemextensionsctl list
scutil --nc list
ifconfig | grep utun

systemextensionsctl list는 등록된 시스템 확장을 확인하고, scutil --nc list는 네트워크 연결 서비스를 나열합니다. 마지막 명령은 현재 utun 인터페이스가 존재하는지만 확인하는 용도입니다. macOS 자체와 다른 VPN도 utun을 생성하므로 인터페이스가 존재한다는 사실만으로 FlClash에 속한다고 판단할 수 없습니다.

IP만 보지 말고 규칙을 확인하기

규칙 모드를 선택한 후 직접 연결되어야 하는 사이트와 프록시를 사용해야 하는 사이트에 각각 접속하고, FlClash 연결 기록에서 규칙 이름, 프록시 그룹 및 출구 노드를 확인합니다. 출구 IP만 확인하면 규칙 오매칭을 발견할 수 없습니다. 예를 들어 DIRECT 규칙의 우선순위가 너무 높으면 TUN과 네트워크 확장은 모두 정상이어도 대상 도메인이 직접 연결될 수 있습니다.

일반적인 문제와 해결 방법

네트워크 확장을 허용했지만 TUN이 시작되지 않음

다른 VPN, 이전 버전의 Clash 클라이언트와 기업용 프록시를 종료한 뒤 다시 시도합니다.
TUN을 끄고 FlClash를 종료한 다음 10초 후 다시 시작합니다.
앱이 DMG 마운트 볼륨이 아니라 「응용 프로그램」 폴더에 있는지 확인합니다.
설정에 중복된 DNS 수신 포트가 동시에 존재하는지 확인합니다.
127.0.0.1:1053을 다른 프로세스가 이미 사용 중이면 DNS 수신 설정을 변경하거나 충돌하는 프로세스를 중지합니다.

활성화 후 로컬 네트워크 기기에 접근할 수 없음

TUN 자동 라우팅은 로컬 네트워크 트래픽의 매칭 방식을 바꿀 수 있습니다. 설정에는 IP-CIDR,192.168.0.0/16,DIRECT,no-resolve, IP-CIDR,10.0.0.0/8,DIRECT,no-resolve, IP-CIDR,172.16.0.0/12,DIRECT,no-resolve와 같은 사설 주소 직접 연결 규칙을 유지해야 합니다. 프린터나 NAS에 로컬 네트워크 도메인으로 접속한다면 DNS가 로컬 도메인을 해석할 수 있는지도 확인하세요.

잠자기에서 깨어난 후 연결됨으로 표시되지만 접속할 수 없음

Wi-Fi 전환, 핫스팟 변경 또는 잠자기 해제 후에는 이전 기본 인터페이스가 더 이상 유효하지 않을 수 있습니다. TUN을 껐다가 다시 켜 auto-detect-interface가 출구 인터페이스를 재인식하도록 하세요. 유선 네트워크에서 Wi-Fi로 전환한 뒤에만 문제가 발생한다면 앱을 종료 후 다시 시작해 라우팅과 DNS 상태를 새로 구성합니다.

시스템 프록시를 껐는데도 계속 프록시를 사용함

TUN이 여전히 켜져 있는지, 또는 브라우저에 별도 프록시 확장이 설정되어 있는지 확인하세요. 시스템 프록시, 앱 내부 프록시와 TUN은 서로 다른 세 경로입니다. 하나를 껐다고 나머지 두 경로도 중지되는 것은 아닙니다. 터미널에서는 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 환경 변수가 여전히 로컬 포트를 가리키는지도 확인해야 합니다.

삭제 및 재설치: VPN, 확장 프로그램과 프록시 잔여 설정 정리

FlClash.app을 휴지통으로 바로 드래그하면 앱 본체만 제거됩니다. TUN이나 시스템 프록시를 사용한 적이 있다면 먼저 네트워크 설정을 원래대로 복원한 뒤 앱을 삭제하세요. 이렇게 해야 재설치 전에 사용할 수 없는 로컬 포트, VPN 항목 또는 이전 보조 구성 요소 권한이 계속 남는 것을 막을 수 있습니다.

FlClash에서 시스템 프록시를 끕니다.
TUN 모드를 끄고 상태 전환이 완료될 때까지 기다립니다.
FlClash를 종료하고 메뉴 막대 아이콘과 관련 프로세스가 모두 종료되었는지 확인합니다.
「시스템 설정」→「네트워크」→「VPN」으로 이동해 이전 설치에 해당하는 항목인지 확인한 후 삭제합니다.
macOS 15 및 이후 버전에서는 「일반」→「로그인 항목 및 확장 프로그램」→「네트워크 확장」으로 이동해 이전 항목의 상태를 확인합니다.
현재 네트워크의 「세부사항」→「프록시」로 이동해 127.0.0.1의 이전 포트를 가리키는 설정을 삭제합니다.
마지막으로 「응용 프로그램」에 있는 FlClash.app을 삭제하고 Mac을 재시동합니다.

기업용 기기에는 구성 프로파일이 설치되어 있을 수도 있습니다. 「시스템 설정」→「일반」→「기기 관리」에서 확인할 수 있으며, 프로파일의 출처와 용도를 명확히 알고 있을 때만 삭제하세요. 회사나 학교에서 배포한 네트워크 구성은 관리자에게 맡겨야 인증서, Wi-Fi 및 기타 보안 정책에 영향을 주는 일을 피할 수 있습니다.

profiles list
scutil --proxy
ps aux | grep -i clash

profiles list는 구성 프로파일을 확인하고, scutil --proxy는 현재 시스템 프록시 상태를 확인합니다. 마지막 명령은 이름에 Clash가 포함된 프로세스가 남아 있는지 확인하는 용도입니다. 명령 결과에는 다른 클라이언트나 이전 구성 요소가 포함될 수 있으므로 삭제하기 전에 경로를 반드시 확인하세요.

권장하는 안정적인 설치 순서

칩 아키텍처에 맞는 설치 패키지를 다운로드합니다.
FlClash를 「응용 프로그램」으로 옮긴 뒤 고정된 위치에서 실행합니다.
Gatekeeper 차단을 해제하고 구독을 가져옵니다.
먼저 시스템 프록시로 노드, DNS와 규칙을 확인합니다.
127.0.0.1:7890 등 실제 수신 포트가 정상적으로 작동하는지 확인합니다.
전체 트래픽 제어가 실제로 필요할 때만 TUN을 활성화하고 네트워크 확장 승인을 완료합니다.
화면의 스위치만 보지 말고 연결 기록에서 규칙 매칭을 확인합니다.

이 순서는 앱 실행, 구독 사용 가능 여부, 시스템 프록시와 TUN을 네 단계로 나눕니다. 어느 단계에서 실패했는지에 따라 해당 계층을 바로 확인할 수 있으므로 앱을 반복해서 삭제하거나 전체 네트워크 설정을 초기화할 필요가 없습니다.