이 글이 맞는 독자
이미 Clash Verge Rev 설치 글을 보았는데 검색 결과에 Mihomo Party가 따로 뜨고, «둘이 같은지 다른지»부터 구분하고 싶은 경우가 가장 흔합니다. 또 한 가지는 새 PC에 Windows 11을 올린 뒤 «Mihomo 브랜드가 붙은 GUI 중 무엇을 쓰는지»만 빠르게 정하고 싶은 사용자입니다. 터미널에서 바이너리만 직접 돌리는 방식이 익숙하다면 이 문서는 UI 메뉴 설명 비중이 높아 다소 장황하게 느껴질 수 있습니다. 반대로 마우스 위주로 «일단 화면에 노드가 뜨고 브라우저가 프록시를 타는지»만 확인하고 싶다면 흐름이 잘 맞습니다.
한국어 검색에서는 «클래시», «미호모 파티», «메타 코어」처럼 표기가 들쭉날쭉합니다. 중요한 것은 이름이 아니라 다운로드 URL이 어느 GitHub 조직의 Releases를 가리키는지와, 설치 파일 디지털 서명이 그 릴리스 설명과 동치인지입니다. 문장에 적어 둔 고정 링크는 빠르게 낡으므로, 습관처럼 공식 저장소 페이지를 여는 편이 안전합니다.
Mihomo Party와 Clash Verge Rev는 어디가 다른가요
둘 다 최종적으로는 Mihomo 엔진이 규칙·프록시 체인을 처리합니다. 차이는 프로젝트 분기와 화면·설정 항목 배치, 업데이트·번들 정책에 가깝습니다. Verge Rev 글에서 익힌 «구독 붙여 넣기 → 노드 선택 → 시스템 프록시» 큰 줄기는 Party에서도 통하지만, 메뉴 이름·아이콘·고급 탭 위치가 조금씩 달라 처음에는 헤맬 수 있습니다.
검색 의도를 «같은 PC에 둘을 동시에 깔아 비교»까지 넓히면 서비스 포트·자동 실행이 겹칠 수 있어 추천하지 않습니다. 보통은 하나를 기본으로 정하고, 교체할 때는 완전히 종료한 뒤 설치하는 편이 덜 피곤합니다. 코어만 최신으로 유지하는 주제는 Verge든 Party든 공통이므로 Meta·Mihomo 코어 업그레이드 글을 함께 북마크해 두면 이후 질문이 줄어듭니다.
Windows 11에서 설치 전에 손볼 것
일반 사용자 권한으로도 설치 자체는 되는 경우가 많지만, 나중에 TUN이나 드라이버성 구성을 켤 때는 다시 UAC를 마주칩니다. 회사·학교 장비는 가상 어댑터나 프록시 변경이 정책으로 막혀 있을 수 있으니, 설치 전에 안내 문서를 읽는 편이 시간을 아낍니다.
백신·EDR 제품은 신규 실행 파일을 잠시 격리하는 일이 있어, 격리 로그의 해시를 공식 릴리스와 맞춰 보는 습관이 필요합니다. 임의 미러 사이트에서 받은 설치 파일은 체크섬 확인이 생략되기 쉬워 피하는 것이 좋습니다.
이미 다른 상용 VPN이 TUN 슬롯을 쓰고 있다면 라우팅이 겹칩니다. 우선 Party만 단독으로 켜서 증상을 재현하는 것이 원인 분리에 유리하고, 공존 절차는 TUN·시스템 프록시 종합 가이드를 참고하세요.
GitHub Releases에서 공식 Windows 패키지 받기
mihomo-party-org 네임스페이스의 저장소에서 Releases 탭을 열고, 자신의 아키텍처에 맞는 설치 파일을 고릅니다. 대부분의 최신 데스크톱은 x64이며, ARM 기기는 arm64 자산이 분리돼 있으면 그쪽을 선택해야 합니다. 파일 이름에 버전 번호가 박혀 있으므로, 브라우저 다운로드 폴더에 여러 세대가 쌓이지 않게 정리하는 것도 혼동을 줄입니다.
다운로드 후 파일 속성의 디지털 서명 탭에서 발행자를 확인하세요. 서명이 없거나 발행자 문자열이 릴리스 설명과 어긋나면 공식 빌드가 아닐 가능성을 의심해야 합니다. 포터블(.7z 등)을 고를 경우에는 압축 해제 위치와 자동 업데이트 동작이 설치형과 다를 수 있으니, 처음에는 설치 마법사형을 쓰는 편이 질문이 적습니다.
winget으로 Mihomo Party 설치하기
winget 매니페스트가 공식 릴리스를 가리키면, 터미널 한 줄로도 동일한 바이너리를 재현할 수 있습니다. PowerShell에서 winget search mihomo처럼 검색해 Id가 mihomo-party.mihomo-party 형태인지, Publisher가 프로젝트와 일치하는지 먼저 확인하세요. 커뮤니티에 떠도는 명령을 그대로 붙여넣기보다, 자신의 PC 검색 결과를 보고 고르는 습관이 중요합니다.
설치 뒤 winget list로 버전을 확인하고, Party 앱의 정보 화면 문자열과 맞는지 대조하면 업데이트가 꼬였는지 빠르게 알 수 있습니다. 조직 프록시 뒤에서는 winget 다운로드가 막히는 경우가 있어, 그때는 IT에 예외를 요청하거나 릴리스 페이지에서 직접 받는 우회를 택해야 합니다.
설치 마법사와 UAC
마법사는 사용자별 설치와 전체 사용자 설치, 시작 메뉴 바로가기, 자동 실행 같은 옵션을 묻습니다. 처음에는 기본값으로 올리고 동작을 본 뒤 필요하면 재설치해도 늦지 않습니다. 전체 사용자 설치를 고르면 이후 권한 상승 빈도가 늘 수 있지만 가족·공용 PC에서는 합리적인 선택이 되기도 합니다.
사용자 계정 컨트롤(UAC)은 시스템 디렉터리 쓰기나 서비스 등록처럼 민감한 작업에서 뜹니다. 발행자 정보가 비어 있거나 «알 수 없음»에 가깝다면 무조건 허용하지 말고 파일을 폐기하고 공식 경로에서 다시 받는 것이 맞습니다.
첫 실행: 스마트 스크린과 방화벽
처음 실행 시 스마트 스크린이 «자주 다운로드되지 않은 앱»으로 막는 경우가 있습니다. 오픈소스 GUI는 버전 주기가 빠르면 상용 앱보다 평판 점수가 낮게 보일 수 있어, 무조건 «실행»을 누르기보다 추가 정보에서 서명·이름을 다시 확인하세요.
방화벽 질문이 뜨면 로컬 루프백과 외부 대역을 나누어 생각합니다. 불필요하게 공용 프로필까지 열어 두면 와이파이 환경에서 공격 면이 넓어질 수 있으니, 우선 개인 네트워크 범위에서만 허용하고 필요할 때만 확장하는 편이 좋습니다.
첫 구독 URL 가져오기
서비스 제공자가 준 HTTPS 구독 링크를 Party의 프로필·구독 입력란에 붙여 넣고 새로고침합니다. 응답은 보통 YAML이거나 Base64로 감싼 노드 정보이며, 클라이언트가 파싱해 목록을 채웁니다. 링크에 토큰이 섞여 있다면 다른 사람과 공유하지 말고, 메모 앱에 평문으로 오래 보관하지 않는 습관이 안전합니다.
자동 갱신 주기를 너무 짧게 잡으면 공급자 측 빈도 제한에 걸릴 수 있고, 너무 길면 실제 서버 구성과 화면이 어긋납니다. 기본값이 있으면 그것부터 쓰고, 오류가 보이면 간격을 조정하세요. 패턴 정리는 구독 자동 업데이트 문제 해결 글과 짝을 이룹니다.
클립보드에서 긴 설정 덩어리를 직접 붙여 넣는 기능이 있다면, 그 안에 외부 스크립트 URI나 의심스러운 external-controller 노출이 없는지 한 번 더 읽습니다. 타인이 준 «테스트 프로필»이라도 그대로 신뢰하지 마세요.
Mihomo 코어와 Party 번들
Party는 UI일 뿐이고 실제 연결 상태를 만드는 축은 Mihomo 코어입니다. 설정 화면에서 코어 버전과 업데이트 채널을 확인하고, 릴리스 노트에 깨질 수 있는 규칙 문법 변경이 없는지 읽습니다. 프리릴리스 채널은 신규 프로토콜을 빨리 쓰게 해 주지만, 기존 프로필과 충돌할 수도 있습니다.
고급 사용자는 바이너리만 교체하는 시나리오도 가능하지만, 첫 설치 단계에서 필수는 아닙니다. «업데이트를 눌렀는데도 특정 전송이 없다»는 질문은 앱 번들·외부 릴리스의 타이밍 차이에서 자주 나오므로, 숫자 버전을 말로 적어 두면 커뮤니티 질문에도 도움이 됩니다.
시스템 프록시부터: TUN은 두 번째 과제
처음 연결을 확인할 때는 시스템 프록시만 켠 상태에서 브라우저를 점검하는 편이 단순합니다. Windows 설정 앱의 네트워크 및 인터넷 > 프록시에 127.0.0.1과 앱이 안내한 포트가 반영되는지 확인하세요. Edge·크롬 계열은 기본적으로 이 경로를 따르는 경우가 많습니다.
TUN은 프록시를 무시하는 앱에도 트래픽을 끌어오는 데 유리하지만 드라이버·UAC·타 VPN과의 충돌 이슈가 커집니다. 전체 단절이 있으면 우선 TUN부터 끄고 복구하는 순서를 몸에 익히고, 세부 점검표는 TUN 종합 가이드를 보세요. Microsoft Store 앱만 이상하면 UWP·localhost 루프백 이슈일 수 있습니다.
연결 검증과 짧은 체크리스트
노드를 바꾼 뒤에는 같은 탭을 새로고침만 하지 말고 시크릿 창을 열어 확장·캐시 영향을 줄입니다. 지역 표시 페이지를 볼 때 DNS와 IP가 서로 엇나가는 패턴이 없는지 함께 봅니다. Fake-IP를 쓰는 프로필은 내부 사이트가 막히는 부작용이 있을 수 있어 Fake-IP vs Redir-Host 표를 곁들이면 좋습니다.
로그에 특정 도메인만 DIRECT로 찍힌다면 구독보다 규칙을 의심합니다. 반대로 프록시를 타는데 지연만 크다면 노드 품질·UDP·혼잡이 원인인 경우가 많습니다. 첫 설치 직후에는 규칙을 대대적으로 고치기보다 기본 프로필이 의도대로 움직이는지부터 확인하는 편이 스트레스가 적습니다.
막힐 때 바로 옆 문서
구독은 성공인데 노드 지표만 전부 나쁘게 보일 때 Ping·TCP 측정 UI가 실제 앱 트래픽과 다른 프로토콜을 보여 주는 오해가 있습니다. 실제 사이트를 열어 체감을 확인하세요. 중간 SSL 검사 장비가 끼면 TLS 단계에서만 실패하기도 하며, 그때는 TLS·SNI 문제 해결 글과 맞물립니다.
방화벽이 로컬 인바운드를 막으면 브라우저가 프록시 포트에 연결조차 못 합니다. 다른 기기와 포트를 공유할 계획이면 LAN 공유·방화벽 글을 읽되, 불필요한 대역 개방은 피하세요.
WSL2나 개발 도구를 같이 쓴다면 호스트 프록시 포트와 터미널 환경 변수를 맞추는 별도 절차가 필요합니다. WSL2·Windows 연동 글이 직접적인 연장선입니다.
자주 묻는 질문
Mihomo Party와 Clash Verge Rev를 같이 깔아도 되나요?
가능은 하지만 자동 실행·포트·프로필 경로가 겹치기 쉬워 혼선이 납니다. 비교가 목적이면 하나를 완전히 끄고 번갈아 켜는 편이 디버깅에 유리합니다.
winget 설치본이 진짜 Party가 맞는지 확인하려면?
패키지 ID·퍼블리셔·버전을 Releases 페이지와 대조하고, 실행 파일 속성의 서명 문자열까지 확인하세요.
UAC가 설치 후에도 자주 뜹니다.
TUN·서비스·관리자 권한 업데이트가 섞여 있으면 드물지 않습니다. 평상시 웹만 볼 때도 반복되면 자동 실행 목록을 점검해야 합니다.
구독만 넣었는데 목록이 비어요.
URL 유효기간, UA 제한, 회사망 필터, 시스템 시각 오류를 순서대로 의심하고, 브라우저 직접 호출과 앱 로그를 비교하세요.
정리와 다음 단계
이제 «Windows 11에서 Mihomo Party를 공식 Releases나 winget으로 받고, UAC·스마트 스크린을 통과한 뒤 구독 URL로 Mihomo 노드를 띄우는» 최소 루트를 갖췄습니다. 다음 단계는 DNS 모드·정책 그룹·TUN 같은 난이도를 한 단계씩 올리면 됩니다.
이름만 비슷한 옛 클라이언트나 업데이트가 끊긴 포크는 설치는 쉬워 보여도 코어가 낡아 최신 전송·취약점 대응이 뒤처지는 경우가 많습니다. 메뉴 구조도 제각각이라 검색만 해도 시간을 잃기 쉽습니다. Clash Verge Rev처럼 커뮤니티가 두텁게 붙은 선택지와, 지금 글에서 다룬 Mihomo Party처럼 검색 의도가 분명히 갈리는 선택지를 헷갈리지 않고 출처만 맞춰도 실패 확률은 크게 줄어듭니다. ClashNote는 이런 분기마다 한 화면에서 릴리스 채널과 한국어 설명을 이어 주는 역할을 목표로 두었기 때문에, 글이 길어지는 대신 «어느 문서를 먼저 열어야 하는지»를 끊기지 않게 잡아 두었습니다. 무료 GUI라도 다운로드 검증과 구독 비밀 관리는 사용자 책임이므로, 습관이 장기적으로 가장 비용을 줄여 줍니다.
규칙을 손대기 시작하면 YAML 전체 흐름이 필요해지니 규칙·정책 그룹 가이드로 이어가면 학습 경로가 끊기지 않습니다.