Mihomo Party를 Win10 첫 세팅에 고르는 이유

업무·가정용 PC 가운데 Windows 10을 그대로 쓰는 비중은 여전히 크고, 검색엔진에는 “Win10 Mihomo Party 설치”처럼 OS를 명시한 질의와 함께 예전 Clash for Windows 튜토리얼이 함께 노출됩니다. 같은 계열이라도 패키지마다 이름이 다른 Clash Mihomo GUI 가운데 Mihomo Party는 실행 중인 mihomo 코어를 고르거나 교체하기 쉬운 편이라, 첫 화면에서 바로 구독 가져오기와 모드 전환에 집중하기 좋습니다.

사이트에는 같은 OS에서 Clash Verge Rev를 다룬 Windows 10 Verge Rev 설치 글도 있습니다. Verge와 Party는 메뉴 배치가 다르지만 YAML 프로필, 규칙 모드, mixed-port, 시스템 프록시 확인 순서는 공통입니다. 반대로 OS만 11이라면 UI 스크린샷 위치를 맞추려면 Windows 11 Mihomo Party 설치편을 열어두는 편이 빠릅니다. 클라이언트 갈래 선택은 클라이언트 선택 가이드를 참고하세요.

Windows 10은 기능 업데이트가 멈춘 빌드가 많아 디펜더·스토어 정책이 조직마다 제각각입니다. 그래서 “설치 파일은 열렸는데 트레이 아이콘이 안 보인다”처럼 증상만 보면 클라이언트 탓으로 오인하기 쉬운데, 실제로는 백신 격리나 S 모드, 그룹 정책이 앞에 서는 경우가 많습니다. 이 글에서는 그런 분기도 설치 전 점검에 넣어 두었습니다.

ℹ 메모: 회사 장비라면 우회 목적 사용이 금지될 수 있습니다. 테스트는 허용된 네트워크·정책 안에서만 진행하세요.

설치 전: 권한·SmartScreen·에디션·다른 터널

설치 프로그램이 Program Files 쪽에 쓰려면 UAC 프롬프트가 뜹니다. 표준 사용자 세션만 허용된 PC라면 관리자에게 배포 경로를 확인해야 합니다. 다음으로 Microsoft Defender SmartScreen이 “알 수 없는 앱” 경고를 띄우면 발행자와 체크섬을 확인한 뒤에만 실행하세요.

Windows 10 S 모드나 스토어 전용 정책이면 브라우저로 받은 .exe가 막힐 수 있습니다. 이 경우 먼저 에디션 전환 또는 승인된 패키지 채널이 있는지 확인해야 하며, 본 튜토리얼의 일반적인 “수동 설치” 경로와는 출발점이 달라집니다.

상용 VPN, 기업 무선 포털, 다른 로컬 프록시가 동시에 켜져 있으면 라우팅표가 반씩만 적용되는 패턴이 흔합니다. 첫 검증 구간에서는 한 줄기만 유지하고 나머지는 끄는 습관이 디버깅 시간을 줄입니다. 구독 URL은 유출 시 남용되기 쉬우니 복사·붙여넣기 후 앞뒤 공백과 줄바꿈까지 점검하고, HTTP 오류 분기는 구독 갱신 실패 안내와 같은 순서로 읽으면 이후에도 재사용하기 좋습니다.

다운로드와 첫 실행, 방화벽 프롬프트

패키지는 공식 릴리스 페이지에서 받는 것이 가장 분명합니다. 사내에서 GitHub 접근이 막히면 거울 사이트나 IT가 배포한 바이너리를 따라야 하며, 여기서는 특정 버전 문자열을 고정하지 않습니다. 흐름은 설치 파일 실행 → 동의 → 경로 선택 → 바로 가기 실행으로 동일합니다.

처음 실행 시 Windows Defender 방화벽이 뜨면 사설·공용 프로필을 구분하고 불필요하게 “모든 공용 네트워크”까지 열지 않도록 선택합니다. 설치 직후 대시보드나 트레이 아이콘에서 코어가 시작됐는지, 오류 배지가 없는지 먼저 확인합니다. 오래 멈춰 있으면 아래 로그 절차로 바로 넘어가세요.

Windows 10은 알림 센터 동작이 11과 다른 빌드가 있어, “백그라운드에서 막혔다”는 메시지를 놓치기 쉽습니다. 트레이에 숨겨진 보안 알림을 한 번쯤 펼쳐 보는 습관이 초반에 도움이 됩니다.

구독 가져오기와 프로필 갱신 루프

공급자가 준 구독 URL을 복사해 클라이언트의 구독·프로필 화면에 붙입니다. 버튼 이름이 “추가”, “가져오기”, “업데이트”로 달라도 한 번의 동기화로 노드 목록이 채워지는지가 성공 신호입니다. 자동 갱신 주기는 제공자가 권장하는 간격보다 짧게 두면 캐시·레이트 리밋 이슈가 늘 수 있습니다.

실패가 반복되면 순서를 지킵니다. 브라우저에서 같은 URL이 직접 열리는지, 프록시를 꺼야 열리는지, 회사 DNS가 도메인을 차단하는지를 먼저 봅니다. 자세한 상태 코드 대응은 앞선 404·403 정리 글과 구독 유지 보수 가이드를 함께 두면 운영 단계까지 이어집니다.

프로필이 들어오면 정책 그룹과 규칙 묶음이 따라옵니다. 실제 트래픽이 어디로 가는지 추상화해서 읽는 연습에는 규칙 라우팅 모범이 도움이 됩니다. 노드 이름이 화려해도 “메인 선택”, “자동”, “규칙에 따름” 정도로 기능을 접으면 첫 실행 이후 조정이 수월합니다.

내장·mihomo 코어 경로와 버전 불일치

Mihomo Party는 설정 어딘가에 mihomo 코어 실행 파일 경로·업데이트 채널을 두는 경우가 많습니다. 새 프로필이 최신 문법을 쓰는데 GUI만 올리고 코어를 두면 YAML 검증 오류가 줄줄이 나옵니다. 버전 문자열을 메모장 하나에 적어 두면 업데이트 후 롤백이 빨라집니다.

교체 직후 백신이 바이너리를 스캔하면 시작이 지연된 것처럼 보일 수 있어 과도한 중복 클릭은 피합니다. 오류 메시지에 특정 키 이름이 찍히면 릴리스 노트·공급자 FAQ와 대조하고, 같은 파일을 다른 Meta 호환 앱에서 열어 비교 테스트하는 것도 방법입니다.

Windows 10의 실시간 보호 정책이 강한 PC에서는 “코어 파일만 간헐적으로 삭제된다”는 증상도 나옵니다. 예외 경로를 넣을 수 있는지 IT 정책을 확인하고, 개인 장비라면 격리 기록부터 봅니다.

규칙·글로벌·직연결과 정책 그룹

처음에는 규칙 모드(Rule)로 두고 국내·해외를 분리하는 패턴이 많습니다. 문제를 좁힐 때는 잠시 글로벌·직연결을 오가며 “노드 품질 이슈인지, 규칙 매치 이슈인지”를 나눕니다. 이렇게만 해도 로그 줄 읽기가 한층 단순해집니다.

지연 측정이 있는 빌드를 쓰더라도 한 번의 핑만 보지 말고, 실제 업무 패턴과 비슷하게 짧은 요청을 여러 번 보내 loss를 확인하는 편이 낫습니다. 대용량 동기화나 스트리밍 테스트는 별도 세션으로 잡으면 회선 상태를 오해하지 않습니다.

mixed-port 확인과 시스템 프록시

많은 사용자의 첫 성공 체감은 시스템 프록시를 켠 뒤 브라우저 검색 결과가 바뀌는 순간입니다. Party 계열도 설정·상태 패널에 같은 토글이 있는 경우가 대부분이며, 켠 직후 Windows의 프록시 설정 화면에 표시된 주소·포트가 클라이언트에 나온 숫자와 맞는지 비교하면 “앱만 켜졌다”는 착시를 바로 걷어냅니다.

터미널·일부 패키지 관리자는 시스템 프록시를 무시합니다. 이때는 GUI나 YAML에 적힌 mixed-port를 직접 참조해야 합니다. HTTP와 SOCKS를 함께 받는 포트가 열려 있으면 테스트 명령이 단순해집니다. 이미 사용 중이라는 메시지가 뜨면 포트 충돌 실측 글의 순서로 점유 프로세스를 찾습니다(Windows 10에서도 동일하게 적용됩니다).

예: 현재 PowerShell 세션에서만 프록시를 지정합니다(포트는 설정 화면 값으로 바꾸세요). 
$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
⚠ 주의: 사용자 환경 변수에 영구 저장하면 프록시를 꺼도 일부 프로그램이 옛 번호를 붙잡습니다. 테스트 후에는 값을 지우거나 세션을 닫고 정리하세요.

첫 실행 검증: 브라우저·포트 충돌·로그

크롬·엣지에서 해외 결과가 안정적으로 뜨면 1차 성공입니다. 가능하면 IP·ASN 확인 페이지까지 열어 기대 범위인지 봅니다. 그다음 Party의 연결 로그를 열고 TLS 오류·리셋 문자열이 반복되는지 확인합니다. 패턴 매칭 순서는 타임아웃·TLS 로그 가이드가 정리해 둔 흐름과 맞춰 읽으면 빠릅니다.

Invoke-WebRequest 결과가 브라우저와 다르면, 해당 PowerShell 버전이 시스템 프록시를 존중하는지부터 보고, 아니면 앞서 설정한 $env: 변수를 명시적으로 썼는지 확인합니다.

이름 해석만 실패하면 터널이 살아 있어도 페이지가 깨져 보입니다. DNS 관련 질문은 FAQ와 함께 보고, 브라우저만 이상하면 WebRTC 누출이나 확장 프로그램 개입을 의심합니다.

Windows 10에서 자주 걸리는 증상

TUN·가상 어댑터 단계로 나아가면 WinTun 설치·드라이버 허용 UI가 필요합니다. Party 기준으로는 우선 시스템 프록시·규칙 모드까지 검증한 뒤 확장하는 편이 안전합니다. 개념 정리는 TUN 심화 글을 먼저 읽어 “브라우저만 된다”는 착시를 줄일 수 있습니다.

클라이언트를 종료한 뒤에도 인터넷이 돌아오지 않으면 잔류 시스템 프록시를 의심합니다. 종료 순서와 복구는 종료 후 인터넷 복구 글을 참고하세요(프록시 설정 위치는 Win10·11이 대부분 같습니다).

구형 Wi-Fi 드라이버나 전원 절약으로 인해 재연결 루프가 생기면, 프록시와 무관하게 DNS 캐시만 비우면 잠깐 돌아오는 척하는 경우도 있습니다. 이때는 네트워크 스택 자체를 재시동하는 쪽이 근본일 때가 많습니다.

자주 묻는 질문

Windows 10과 11에서 Mihomo Party 설치 절차가 다른가요?

UAC·SmartScreen·방화벽 확인 흐름과 “구독→코어→mixed-port→시스템 프록시” 순서는 실질적으로 같습니다. 설정 앱 UI만 버전에 따라 조금 다르고, 11 화면에 맞춘 스크린샷이 필요하면 Windows 11 설치편을 병행하세요.

Win10에 Verge Rev 글만 있을 때 Mihomo Party는 어디에 맞나요?

같은 OS에서 다른 그래픽 클라이언트일 뿐, 프로필 포맷과 로그 의미는 크게 겹칩니다. Verge Rev Win10 글의 순서를 읽은 뒤 메뉴명만 Party에 맞춰 옮기면 됩니다.

시스템 프록시를 켰는데 일부 앱만 안 되는 이유는?

WinHTTP 무시나 자체 TLS, 게임 런처의 직접 연결 때문에 생깁니다. 개발 환경이라면 포트 환경 변수를 명시하고, 전역 터널이 필요하면 TUN 쪽 단계로 넘어가야 합니다.

맺음말

클라이언트 이름이 바뀌고 갈래가 늘어났지만, 작업 현장에서 돌아오는 질문은 비슷합니다. 구독 가져오기가 끝났는지, 선택한 노드와 규칙 매치가 의도대로인지, mixed-port와 시스템 프록시 숫자가 일치하는지, 마지막으로 mihomo 코어 문자열까지 맞는지. 이 네 가지가 흔들리면 기능이 비슷한 앱이라도 문서 검색 시간만 늘어납니다.

예전에는 특정 그래픽 래퍼 하나에 커뮤니티 글이 몰렸지만, 지금은 릴리스 속도와 번역 상태가 제각각이라 “한 제품 이름에 묶인 튜토리얼”만으로는 버티기 어렵습니다. 그래서 재현 가능한 설치 순서와 로그 읽기처럼 제품보다 오래 가는 자산을 한 페이지에 두는 접근이 더 실익이 큽니다. Windows 10을 계속 쓰는 환경에서는 그 점이 특히 분명합니다.

한편 이름이 여러 갈래로 나뉜 탓에 초보자는 “어느 패키지가 최신 문법을 잘 따라 주는지”를 놓치기 쉽고, 문서가 어긋나면 같은 증상도 반복해서 검색하게 됩니다. Clash V.CORE는 배포 정보와 설명을 한 줄기로 모으려는 정리 안에 있어서, 앱 이름이 바뀌어도 검증 루프는 유지하기 쉽습니다. Mihomo Party로 Win10에서 브라우저 검증까지 마쳤다면, 이후 심화 설정은 규칙·로그 쪽 시간을 줄이는 데 집중할 수 있습니다. 같은 흐름으로 패키지를 받아 확인하려면 Clash V.CORE 다운로드 페이지를 기준으로 두는 편이 낫습니다.