왜 지금 Apple Silicon Mac에서 Mihomo Party를 쓰는가
Apple Silicon 이후 macOS는 전력 효율과 백그라운드 프로세스 패턴이 달라졌고, 그래픽 Clash 계열 앱도 네이티브 ARM 빌드를 내려받는 것이 체감 지연과 발열 양쪽에서 유리한 경우가 많습니다. Mihomo Party는 mihomo 코어를 바로 선택·교체하기 쉬운 쪽으로 UI가 정리된 클라이언트로, “YAML은 알겠는데 메뉴 이름이 자꾸 바뀐다”는 사용자에게 구독 가져오기와 프록시 모드 스위치 위치를 빠르게 찾게 해 줍니다.
같은 주제라도 플랫폼만 바뀌면 막히는 지점이 다릅니다. Windows 쪽은 SmartScreen·WinHTTP 이야기가 많고, Mac 쪽은 시스템 프록시 토글과 시스템 설정 > 네트워크의 프록시 패널이 “앱에서는 켰는데 OS에는 반영이 애매하다”는 문의로 이어지기 쉽습니다. 따라서 Win 글만 읽고 메뉴 위치를 복붙하면 헷갈릴 수 있어, macOS 화면 흐름을 한 번에 적어 두는 편이 검색 의도와 맞습니다.
독자 입장에서 비교 축은 두 가지입니다. 첫째, 이미 익숙한 Verge Rev on Mac과 버튼 레이블만 다를 뿐 개념은 같다는 점. 둘째, Windows 11용 Mihomo Party와 동일하게 Meta·mihomo 프로필을 그대로 옮길 수 있다는 점입니다. 세 문서를 번갈아 보고도 “지금 Mac에서 무엇을 눌러야 하는지”가 흔들리지 않게 하려면, 아래 순서표만 머리에 두면 됩니다.
첫 실행 전: 게이트키퍼·방화벽·중복 터널
릴리스 패키지를 내려받은 뒤 처음 실행하면 게이트키퍼가 “개발자를 확인할 수 없음”류 대화 상자를 띄울 수 있습니다. 공식 문서나 릴리스 노트에 안내된 방식(시스템 설정 > 개인 정보 보호 및 보안에서 허용 등)을 따르고, 출처를 모르는 파일만 무작정 허용하지 않습니다. Apple Silicon용과 Intel용 바이너리가 나뉘어 있다면 현재 맥의 칩에 맞는 빌드를 고르고, 유니버설 패키지라면 Rosetta 필요 여부를 미리 확인합니다.
Mihomo Party를 켠 직후 방화벽 또는 보안 제품이 로컬 리스닝에 대한 허용 창을 띄우면, 테스트 구간에서만 제한적으로 허용하는지·영구 규칙으로 둘지 구분합니다. 동시에 상용 VPN, 기업 Zero Trust 클라이언트, 다른 리버스 프록시가 같은 경로를 잡고 있으면 라우팅 표가 반씩만 적용되는 경우가 많으니, 재현 가능한 순서를 만들 때는 한 줄기만 남기는 것이 디버깅 비용을 줄입니다.
mihomo 코어 버전이 GUI보다 낮으면 새 프로필 문법에서 깨집니다. 설정 어딘가에 코어 경로·업데이트 메뉴가 있으면 버전 문자열을 한 번 적어 두었다가 갱신 후 비교하세요. 이 패턴은 Win 안내와 동일하고, mac에서도 “로그에 특정 키가 없다”는 오류가 뜨면 가장 먼저 의심할 부분입니다.
구독 가져오기와 갱신 루틴
구독 가져오기는 공급자가 준 구독 URL을 복사해 클라이언트의 구독·프로필 패널에 붙이는 작업입니다. 버튼 이름이 “추가”, “가져오기”, “업데이트”처럼 달라도 핵심은 한 번에 원격 YAML을 내려받아 노드 목록이 채워지는지 확인하는 것입니다. 붙여 넣을 때 앞뒤 공백·줄바꿈이 섞이면 403이 나는 일이 잦으니, 실패 루프가 길어지면 구독 404·403 대응 글의 체크리스트와 같은 순서로 점검합니다.
갱신 주기는 제공자 안내 시간에 맞추는 편이 서버·캐시 분쟁을 줄입니다. 과도하게 짧은 자동 새로고침은 불필요한 요청을 늘리고, 반대로 너무 길면 노드 교체 시 체감이 늦어집니다. 장기적으로 URL·만료일·백업 습관은 구독 유지 보수 가이드에 맞추면 운영 부담이 줄어듭니다.
구독이 들어오면 규칙과 프록시 그룹 정의가 같이 따라옵니다. 이름이 화려해도 실제로는 “지역별 선택기”, “자동 지연”, “메인 출구” 정도로 읽으면 규칙 모드 해석이 쉬워집니다. 세부 우선순위 이해에는 규칙 라우팅 모범을 곁들이면 좋습니다.
활성 프로필과 정책 그룹 읽는 법
여러 프로필을 두었다면 활성 프로필이 지금 스위치들이 가리키는 YAML인지 먼저 확인합니다. 모드나 시스템 프록시를 바꿔도 반응이 없으면 대개 여기가 엇갈린 경우입니다. 대시보드나 사이드바에 프로필·구성류 레이블이 있으면 그 줄을 따라가면 됩니다.
정책 그룹 화면에는 지연이나 URL 테스트 버튼이 붙은 빌드가 많습니다. 숫자만 보고 고정하기보다, 실제로 쓰는 사이트·터미널 패턴에 가깝게 짧게 여러 번 호출했을 때 끊김이 없는지 보는 편이 낫습니다. 재생·대용량 동기화처럼 부하가 큰 작업은 별도 세션에서 확인하면 “낮은 지연 숫자인데 체감은 다르다”는 착시를 줄일 수 있습니다.
규칙 모드·글로벌 모드·직연결 전환
일상 사용의 기본값은 대부분 규칙 모드입니다. 국내 트래픽은 직접, 필요한 해외만 프록시로 보내는 구조라 검색 체감과 비용이 균형 잡히기 때문입니다. 로그를 읽을 때는 한시적으로 글로벌 모드로 옮겨 “규칙 매치가 빗나간 것인지, 노드 품질 문제인지”를 나누면 분석이 빨라집니다. 반대로 회사망·은행·캡티브 포털처럼 프록시를 타면 깨지는 구간은 직연결(Direct)로 두고 테스트해야 합니다.
메뉴 위치는 빌드마다 조금씩 다르지만 패턴은 같습니다. 상단 툴바·플로팅 패널·트레이 메뉴 중 한 곳에 Rule·Global·Direct(또는 한글 라벨)가 묶여 있고, 클릭 한 번에 현재 활성 프로필에 대한 모드가 바뀝니다. 전환 직후 연결 로그에서 첫 줄에 리셋·TLS 오류가 없는지 확인하면 상태를 빠르게 읽을 수 있습니다.
“전역”이라는 말이 헷갈릴 수 있는데, 여기서 말하는 글로벌 모드는 프로필 전체를 한 출구로 몰아보내는 클라이언트 동작을 뜻합니다. 운영체제의 지역 설정이나 DNS 영역 이름과 직접 대응하지 않으니, 문서를 옮겨 적을 때 단어만 같다고 섞지 않도록 하세요.
시스템 프록시와 mixed-port 맞추기
Safari·Chrome 계열은 시스템 프록시를 잘 따르는 편이라, Mihomo Party에서 시스템 프록시 토글을 켠 뒤 시스템 설정 > 네트워크 > 고급 > 프록시(경로는 macOS 버전에 따라 소문자 차이)에서 실제로 체크박스와 포트 숫자가 채워졌는지 비교합니다. 앱 UI는 켜졌는데 OS 패널이 비어 있으면 권한·다른 네트워크 프로필·보안 소프트웨어가 가로막는지 의심합니다.
터미널·일부 개발 도구·패키지 매니저는 시스템 설정을 무시합니다. 이 경우 GUI에 표시된 mixed-port 값을 기준으로 환경 변수를 잠시 지정하는 방법이 있습니다. 표시 번호는 프로필마다 다를 수 있으니 문서에 7890을 고정으로 적지 말고, 본인 화면의 숫자로 교체하세요.
예: 현재 터미널 세션에만 프록시를 넣습니다(포트는 설정 화면 값으로 바꿉니다).export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"export를 셸 설정 파일에 영구로 넣어 두면 프록시를 꺼도 CLI가 옛 주소를 붙잡습니다. 테스트 후엔 세션을 닫거나 변수를 주석 처리해 정리하세요.
포트가 이미 사용 중이면 코어가 뜨지 않거나 즉시 재시작 루프에 들어갑니다. mixed-port 충돌 안내에서 macOS용 확인 순서를 같이 보세요. 방화벽이 로컬 루프백을 막는 특수 환경은 드물지만, 보안 스택을 겹쳐 쓰는 경우엔 예외 규칙을 다시 점검합니다.
검증과 TUN으로 넘어갈 타이밍
브라우저에서 IP 확인 페이지까지 열어 기대한 ASN으로 보이면 1차 성공입니다. 다음으로 Mihomo Party의 연결·코어 로그를 열고 TLS 실패나 반복 타임아웃 문자열이 있는지 봅니다. 패턴 매칭 순서는 연결 로그 TLS 글과 병행하면 좋습니다.
브라우저만 되고 게임 런처·특정 UDP·작은 앱이 계속 직행한다면 다음 단계는 TUN입니다. 개념 정리는 TUN 심화를 읽고, Mac에서 시스템 확장 충돌·프록시 이중 적용 문제는 macOS TUN·프록시 충돌 글 순서를 따르는 편이 안전합니다. Party에서 TUN 토글이 있다면, 시스템 프록시와 동시에 어떤 조합이 권장되는지 릴리스 노트를 함께 확인하세요.
종료 후 인터넷이 돌아오지 않는 현상은 잔류 시스템 프록시 때문인 경우가 많습니다. 앱을 끄는 순서와 수동 복구는 종료 후 인터넷 복구 글에 맞춰 점검합니다.
macOS에서 자주 걸리는 증상
DNS만 깨지는 패턴은 규칙과 무관하게 보이기도 합니다. 브라우저 확장·다른 DNS 클라이언트·VPN 잔상을 함께 의심하고, 필요하면 사이트 FAQ의 DNS 항목과 맞춰 읽습니다. WebRTC 누수가 의심되면 WebRTC 가이드도 참고합니다.
iCloud·Apple ID·로컬 콘텐츠처럼 지역 정책이 강한 트래픽은 규칙 모드에서도 예외 구간이 많습니다. 무작정 글로벌 모드로 몰아넣으면 오히려 로그인이 꼬일 수 있어, 제공자가 안내한 국내 직행 목록을 먼저 존중하는 편이 낫습니다.
동일 프로필을 Windows와 Mac에서 번갈아 쓸 때 경로 표기나 인코딩 차이로 깨지는 경우는 드뭅니다. 대신 자동 시작 항목에 옛 클라이언트가 남아 같은 포트를 잡는 경우는 흔하니, 로그인 항목과 LaunchAgents를 함께 봅니다.
자주 묻는 질문
규칙 모드인데 특정 사이트만 안 될 때는?
해당 도메인이 어떤 규칙에 매치되는지 로그와 정책 그룹을 확인합니다. 빠르게 분리하려면 잠시 글로벌 모드로 옮겨 같은 노드에서 통과되는지 보고, 통과된다면 규칙 쪽을, 통과되지 않는다면 노드·TLS 쪽을 의심합니다.
시스템 프록시를 켰는데 터미널 앱은 그대로일 때는?
CLI가 macOS 프록시 테이블을 따르지 않는 경우가 많습니다. 앞선 export 예처럼 mixed-port를 직접 지정하거나, 앱이 TUN 경로를 지원한다면 다음 단계 가이드로 넘어갑니다.
Intel Mac에도 같은 메뉴가 적용되나요?
Mihomo Party의 화면 흐름은 동일한 편이며 차이는 바이너리 종류와 성능입니다. 구독 가져오기·모드 전환 순서는 그대로 따라도 됩니다.
맺음말
그래픽 클라이언트가 늘어날수록 문서 제목은 갈라지지만, 실무 질문은 같은 곳으로 수렴합니다. 구독이 갱신됐는지, 활성 프로필이 맞는지, 규칙 모드와 글로벌 모드 중 무엇을 켰는지, 시스템 프록시와 mixed-port 숫자가 일치하는지, 마지막으로 mihomo 코어 문자열까지 맞는지. 이 순서가 흔들리면 제품 이름만 다른 비슷한 글을 헤매는 시간만 늘어납니다.
다만 패키지별로 릴리스 속도와 설명 문자열이 제각각이라, 특정 앱 이름에만 매달린 안내보다 “재현 가능한 확인 순서”를 한 페이지에 두는 방식이 더 오래 버티는 경우가 많습니다. 여러 포크가 공존하는 시장에서는 문서가 분산될수록 첫 설치 시간이 길어지고, 그만큼 잘못된 프록시 설정이 남을 위험도 커집니다.
Clash V.CORE는 그런 분산을 줄이고, 배포·버전 확인·문제 해결 글을 한 브랜드 축으로 묶어 두려는 쪽에 가깝습니다. Meta·mihomo 호환 라인을 쓰는 사용자는 클라이언트 레이블이 바뀌어도 동일한 검증 루프를 재사용할 수 있어야 하고, Apple Silicon Mac에서 Party로 일상 모드를 전환하는 흐름도 그 연장선에 있습니다. 같은 순서로 패키지를 받아 확인하려면 Clash V.CORE 다운로드 페이지를 기준으로 두는 편이 낫습니다.