Windows 11에 Mihomo Party 설치 후 시스템 프록시와 TUN(mihomo): 처음 맞추는 분기 가이드 (2026)

1. Mihomo Party가 강조하는 축과 mihomo 코어

Mihomo Party 이름 그대로, 인터페이스와 배포 채널은 Verge류와 다르지만 밑바닥의 mihomo 코어가 하는 일은 비슷한 축입니다. 패킷은 결국 활성 프로필의 라우팅·DNS 규칙을 타고 노드로 나가고, Windows 입장에서는 (1) OS가 제공하는 프록시 자리표에 로컬 주소와 포트를 심거나, (2) TUN 가상 카드 아래 라우팅을 건드려 전체 프로그램의 IP 경로를 끌어오는 두 갈림길입니다. 따라서 초보자에게 가장 헷갈리는 「버튼 이름」보다 「윈도우 어디를 건드리는지」를 먼저 잡는 편이 이후 디버깅이 수월합니다.

Party 사용자들이 실제 채널 후기나 커뮤니티에서 반복 검색하는 말도 대개 구독 가져오기, 처음 설정, 「시스프 켠 것 같은데 터미널만 안 된다», 「TUN 켠 뒤로 메시지만 돈다」 같은 패턴입니다. 설치 ZIP이나 업데이터에서 경로 어림이 깨지더라도, 활성 노드 여부와 mixed-port처럼 문서화된 표준 이름은 그대로이므로 DNS·fake-ip 관련 안내를 곁에 두면 로그 단어가 줄줄 따라옵니다.

2. 설치와 첫 실행: 아키텍처·스마트스크린·방화벽

Windows 11 설치 전에는 시스템 정보에서 프로세서 아키텍처부터 맞춥니다. 최신 Surface나 Copilot+ PC처럼 arm64가 아닌지 확인하고 적절한 빌드를 내려받습니다. 패키지는 지속 업데이트되므로 UI 문구야 조금 바뀌어도, 첫 실행에서 나오는 Defender Microsoft 스마트스크린 처리 흐름은 동일한 편입니다. 발행 정보를 확인했으면 필요한 단계까지 눌러 실행을 허용합니다. 업무용 장비는 회사 에이전트가 드라이버 설치를 막거나 샌드박스 검사 때문에 지연이 크니, 테스트를 집 컴과 분리해서 생각해야 시간을 안 태웁니다.

설치 직후 Windows Defender 방화벽 팝업이 뜨면 사설망 규격으로 허용해 로컬 루프백 접속과 업데이터·구독 갱신이 막히지 않게 하는 것이 일반적입니다. 업데이트가 내려오면 프로그램이 다시 시작되며 간헐적으로 자체 방화벽 규칙을 물을 수 있습니다. 회사 라우팅 또는 별도 백신이 HTTPS 검사 중이면 초기 패치나 구독 URL 다운로드만 지연처럼 보일 수 있는데, 이 경우는 사용자 인증서 신뢰부터 같이 의심합니다.

설치 패키지는 항상 프로젝트 다운로드 허브처럼 운영 측이 안내하는 경로에서 받는 습관이 좋습니다. 서드파티 리패키징이 끼어 드라이버 레이어만 다른 경우가 간헐적으로 보고되어, 새로 깔았는데 「Wintun이 영 영 설치 안 된다」처럼 정상 설치 과정보다 빨리 패닉 상태에 빠지는 일을 줄입니다.

3. 구독 가져오기·프로필 활성화

검색 사용자가 많이 하는 구독 가져오기는 제공자별 URL을 붙여 넣거나 가져오기 페이지에서 일괄 삽입한 뒤 갱신을 눌러 패키지 노드를 채우는 흐름입니다. 새 프로필이 생기면 활성 상태로 만들고 규칙 모드가 기본이라면 테스트용 전역 선택으로 한두 사이트를 열어보면 코어 시작 여부까지 동시에 확인됩니다. 구독 가져오기 튜토리얼의 체크리스트를 그대로 옮겨 두면 이름은 달라도 단계 순서만 맞으면 빠져나옵니다.

처음 설정이라도 지연 테스트를 한 번이라도 실행해 두면 이후 증상이 「전부 안 됨」인지 「특정 앱만」인지 크게 좁습니다. 패널 어딘가에 있는 로그 뷰를 켠 채 테스트하면 실패 근거 문자열이 즉시 뜨므로 채널 채팅에 붙여넣기 편하기도 합니다. 정책 그룹이 많은 구성이라면 여러 구독을 합치는 글의 순서처럼 override와 병합을 나누어 생각해야 혼선이 줄어듭니다.

4. 시스템 프록시: 무엇이 잘 따라오나

시스템 프록시는 Windows 설정에 HTTP·HTTPS·SOCKS 같은 프록시 주소와 포트를 채워 주는 기능입니다. Edge를 비롯해 시스템 프록시를 존중하는 많은 데스크톱 애플리케이션은 즉시 Clash류가 들고 있는 mixed-port로 경로가 붙습니다. Party 같은 최신 패널에서는 토글과 함께 포트 값이 카드처럼 노출되는 경우도 있으니 숫자가 비어 있는지 먼저 확인합니다.

한계 역시 명확합니다. PowerShell 세션처럼 환경 변수에 프록시가 없으면 무조건 직통으로 나가거나, 브라우저마다 우회 규칙을 따로 가진 크롬 플래그 사용자, 또는 직결 소켓을 직접 여는 크로스플랫폼 게임 같은 경우에는 시스템 프록시만으로는 패킷이 비집니다. 이런 패턴일 때 사람들이 검색하지만 이름은 들쭉날쭉한 질문이 바로 「시스템 프록시 켠 것 같은데 터미널만 안 간다」, 「npm만 실패한다」처럼 풀립니다.

5. TUN 모드: Wintun·UAC·가상 어댑터와 충돌

Party에서 TUN 또는 유사 이름의 전역 라우팅 스위치를 조작하면, 백단 mihomo가 Windows에 가상 인터페이스를 붙입니다. 초회에는 거의 빠지지 않게 Wintun 패키지를 설치하라거나 관리자 권한 상승 확인을 받습니다. 대화 창만 닫아 두면 기능은 꺼진 채로 UI만 반짝였다 가는 상태가 되어, 사용자는 「로그에는 뭔데 화면엔 적용됐대」 같은 혼선을 보고합니다. 따라서 초기 한 번이라도 허용 절차를 끝까지 밟아 두었는지 장치 관리자에서 어댑터가 깨지지 않았는지 같이 확인하는 습관이 좋습니다.

동시에 켠 상용 VPN, 제로트러스트 클라이언트, 과거 Clash 더미 드라이버 잔존 상태는 경로 두 겹 문제를 만듭니다. 또 Hyper-V 내장 스위치, WSL 브리지, Docker 데스크톱이 붙어 있으면 우선 순위 때문에 일부 프로그램만 예외처럼 직통으로 보입니다. 이럴 때 라우팅 테이블을 직접 만지진 않더라도, 로그 패턴과 실패 프로그램을 같이 놓으면 진단 속도가 나옵니다. DNS 레이어도 TUN에서는 fake-ip 같은 정책과 충돌 메시지가 자주 따라오니 프로파일 수정과 UI 토글을 동시에 돌려보진 않도록 주의합니다.

# Sample: quick connectivity probe in PowerShell (adjust timeouts if needed)
curl.exe -sI --connect-timeout 8 https://www.cloudflare.com | Select-Object -First 3

TUN 켠 상태와 시스프만 켠 상태에서 위 테스트 결과가 크게 바뀌면, 프로그램이 OS 프록시를 무시하는지 여부부터 추정할 수 있습니다. 실패 문자열 자체가 곧 라우팅 이슈인지 노드 차단인지 DNS인지 분기 기준이 됩니다.

6. 추천하는 처음 순서

실무에서는 다음 순으로 움직이면 헛발질을 줄였습니다. 먼저 설치 후 스마트스크린·방화벽을 정리하고, 그다음 구독 가져오기로 프로필을 채워 코어 시작을 확인합니다. 이어서 시스템 프록시만 켠 채 브라우저·사무 프로그램이 의도 규칙을 타는지 본 다음, 명령행·러스트 cargo·pnpm 단계처럼 직통이 필요한 프로그램이 보이면 그때에야 TUN 준비에 들어갑니다. 가상 카드 허용을 회사 규칙 때문에 못 하면 즉시 터미널 변수나 IDE 내장 프록시 설정으로 우회해야 합니다.

Party를 이미 깐 다른 PC 설정을 옮길 계획이라면 레지스트리가 아니라 내보낸 프로필과 자동 실행 옵션을 동시에 점검합니다. 과거 브러시된 Wintun이 남았는지 깨끗이 재설치가 필요하면 제거 프로그램이나 디바이스 관리자 명령을 병행해 충돌 잔류를 줄입니다. 새 OS 빌드를 올릴 때마다 Windows 기능 업데이트가 네트워크 스택을 재구성하면 TUN 상태가 초기처럼 흔들리기도 해서 업데이트 직후에야 다시 테스트하는 패턴도 흔합니다.

7. UWP·CLI·게임·다른 VPN

Microsoft Store 형식(UWP류) 프로그램은 격리 정책 때문에 시스프만으로는 패킷이 안 붙거나 루프백 허용이 필요한 경우가 있습니다. TUN을 켠 뒤에도 증상이 계속된다면 TUN과 UWP 루프백 가이드의 체크를 그대로 이어 붙입니다. 명령행 도구들은 새 터미널에 HTTPS_PROXY를 비워 둔 채 테스트하면 헷갈리니, 사용자 프로필에 영구 변수를 줄지 세션 변수로만 줄지 선택을 분명히 합니다. Git처럼 별도 프록시 키를 갖는 앱도 있어 Git·SSH 연계 글까지 같이 놓습니다.

온라인 게임 안티치트는 가상 카드를 비정상으로 분류하기도 해 TUN까지 킨 상태로 계정 규약을 어길 우려가 있으면 과감하게 시스템 프록시와 게임 자체 허용 옵션까지만 두는 선택이 현실적입니다. 동시 실행 금지가 확실한 상용 VPN 역시 테스트 구간에서는 한쪽만 전역 트래픽을 처리하게 해야 「연결했다는데 사이트는 여전히 직통」 같은 혼란 줄어듭니다. Docker나 WSL2가 붙은 환경은 WSL2 네트워크 글처럼 mirror 모드 차이 때문에 Party에서 본 상태와 게스트 OS 생각이 엇갈릴 수 있으니 교차 검증이 필요합니다.

8. 증상 나누기 체크리스트

첫 번째 확인은 패널에서 시스템 프록시 스위치와 TUN 스위치 조합입니다. 두 번째는 활성 프로필 이름과 선택 중인 노드 풀이 오류 상태인지, 구독 일자 문제인지 봅니다. 세 번째는 Windows 설정 > 네트워크·인터넷 > 프록시에 실제로 값이 채워졌는지, 넷째는 장치 관리자에서 가상 카드 상태, 다섯째는 다른 필터 구동 VPN이나 회사 패킷 검사 프로그램 흔적 여부입니다. 로그 줄에서 어떤 정책 이름에 매칭됐는지 보는 순서까지 넣어두면 DNS와 라우팅을 동시 의심하는 실수도 줄었습니다.

9. 자주 묻는 질문