설치 글 다음에 TUN·Strict를 분리하는 이유
검색 의도를 한 줄로 적으면 이렇게 됩니다. “Mihomo Party로 Windows 11에 넣었는데 일부 앱만 안 된다.” 초반에는 시스템 프록시와 mixed-port만으로 브라우저 검증을 끝내는 편이 빠르고, 그 흐름은 동일 제품 설치·구독 글에 이미 모아 두었습니다. 그런데 동일한 노드와 규칙을 쓰는데도 터미널·런처·게임 UDP가 따로 노는 패턴은 대개 TUN 모드가 꺼져 있거나, 켜져도 스택과 Strict Route가 환경과 안 맞아 생깁니다.
다른 글이 원리 위주라면 여기서는 단일 기능점에만 집착합니다. 화면 이름은 빌드마다 조금씩 다르지만 “가상 어댑터·터널·TUN” 같은 레이블과, 스택 후보(gvisor, system, mixed 등) 목록, Strict Route 토글 위치만 찾아 순서대로 맞추면 재현 가능한 안정 구간을 만들 수 있습니다. 개념 보강은 TUN 심화 글과 함께 읽으면 “왜 브라우저만 되었는지”가 한 번에 정리됩니다.
Win11에서 보는 TUN 스택: gVisor·system·mixed
TUN 스택은 같은 “TUN을 켠다” 한 줄 안에서도 패킷이 거치는 경로가 달라집니다. system은 운영체제가 제공하는 네이티브 경로에 더 가깝게 붙고, 하드웨어 가속·오프로드와 상호작용하는 방식이 단순해 보이는 대신 특정 보안 제품이나 가상 스위치 조합에서 예외가 튈 수 있습니다. gVisor 계열은 사용자 공간에서 처리하는 층을 두는 형태에 가깝게 이해하면 되고, 게임·리전 클라이언트·일부 anti-cheat 조합에서는 오히려 여기가 더 매끈할 때가 있습니다. mixed라는 이름은 빌드마다 의미가 살짝 다를 수 있으니, 실제 선택지 설명 문구를 함께 읽고 “IPv4·IPv6·UDP 우선순위가 어떻게 적혀 있는지”를 확인하세요.
Win11은 하이퍼바이저 기반 보안 기능과 필터 드라이버가 겹치기 쉬워서 “문서상 추천 스택”보다 직접 바꿔 본 결과가 우선입니다. 한 번에 두 가지 이상을 바꾸면 원인 분리가 어렵습니다. 스택만 바꾸고 노드·규칙·DNS는 고정하는 방식으로 한 세션을 유지한 채 재측정하세요. 증상이 UDP 편향이면 스택 변경 전에 동일 노드에서 규칙 매치 로그부터 확인하고, TCP만 문제면 DNS fake-ip나 스니핑 설정을 의심하는 편이 빠릅니다.
Strict Route가 막는 것과 풀리는 증상
Strict Route를 한국어로 풀면 “기본 게이트웨이와 겹치지 않게 필요한 트래픽만 터널 쪽으로 모으려는 제약에 가깝다” 정도로 보면 됩니다. 꺼져 있을 때 자주 보이는 패턴은 다음과 같습니다. 해외 사이트는 되는데 특정 국내 CDN만 기형적으로 느리다, 동일 도메인인데 브라우저와 CLI의 출구 ASN이 다르다, 앱을 종료했는데 라우트 표에 이상한 행이 남아 트래픽이 반씩 새는 느낌이 든다. 이때 켜 두면 분류 규칙과 코어가 의도한 한 줄기 출구에 더 가깝게 붙는 경우가 많습니다.
반대로 켰더니 사내망 주소대나 프린터 같은 로컬 세그먼트가 끊기면, 프로필의 bypass 계열 필드나 DNS 설정을 함께 봐야 합니다. 증상이 복합적일 때는 Strict Route를 잠시 끄고 스택만 조정해 안정 구간을 만든 다음 다시 켜는 두 단계 접근이 디버깅 비용을 줄입니다. 규칙 해석 순서 자체를 손보는 작업은 GEOIP·RULE 순서 글과 같이 보는 편이 안전합니다.
적용 전 체크: 권한·다른 VPN·DNS·프로필
Windows 11에서 TUN은 드라이버와 라우트 표를 건드립니다. 다른 상용 VPN, 기업 Always-On VPN, 일부 “네트워크 최적화” 유틸이 동시에 켜져 있으면 절반만 적용되는 것처럼 보입니다. 테스트 구간에서는 한 줄기만 남기고, Mihomo Party가 관리자 권한으로 실행해야 하는 빌드라면 트레이 아이콘을 우클릭해 상승 여부부터 확인합니다.
DNS가 ISP나 회사 리졸버로 고정돼 있으면 fake-ip 프로필과 충돌해 “연결은 되는데 이름만 깨진다” 패턴이 나옵니다. 이때는 코어 로그의 DNS 관련 줄과 브라우저만 성공하는지부터 분리하세요. 프로필을 YAML에서 직접 고치기 전에 GUI에서 동일 스위치가 있는지 찾아 두면 롤백이 쉽습니다. 백업할 파일 경로와 버전 문자열은 설치 글의 코어 절차와 동일하게 기록해 두면 재현 속도가 빨라집니다.
1단계: Mihomo Party에서 TUN 켜기
대시보드나 설정 탭에서 TUN, Virtual Adapter, 시스템 프록시와 함께 쓰는 터널 같은 레이블을 찾습니다. 토글을 켠 직후 어댑터 목록에 새 인터페이스가 생겼는지 Windows 설정에서 확인하면 “켜졌는데 실제로는 실패” 패턴을 빨리 잡습니다. 처음부터 시스템 프록시와 TUN을 동시에 켜면 증상 해석이 어려울 수 있으니, 브라우저 검증은 이미 끝났다는 전제라면 TUN만 단독으로 켠 상태에서 터미널 한 줄 테스트부터 하는 편이 분리에 유리합니다.
방화벽 프롬프트가 다시 뜬다면 허용 범위를 과하게 넓히지 말고 현재 네트워크 프로필을 확인합니다. 실패 로그에 WinTun 관련 문자열이 보이면 재설치나 드라이버 차단 여부를 먼저 점검하세요. 같은 증상 대응은 Verge 계열 글과 메커니즘이 겹치므로 Windows 11용 Verge Rev TUN 글의 실측 순서를 참고해도 됩니다. 메뉴 이름만 다를 뿐 확인 포인트는 대부분 동일합니다.
2단계: 스택 선택과 A·B 테스트 루프
스택 드롭다운에서 gvisor를 고르고 동일한 노드로 게임·개발 도구·브라우저를 각각 짧게 호출합니다. 지연과 재연결 빈도를 메모한 뒤 system으로 바꿔 같은 시나리오를 반복합니다. 여기서 “어느 한쪽만 QUIC가 특이하게 튄다”거나 “특정 포트대만 리셋된다”면 노드 품질 문제와 분리된 스택 이슈일 가능성이 큽니다. mixed가 있다면 설명 문구에 IPv6 처리 방식이 적혀 있는지 확인하고, 듀얼 스택 회선이라면 IPv6 우선 앱에서 재현되는지 따로 봅니다.
스택을 바꿀 때마다 캐시된 연결 때문에 체감이 달라질 수 있으니 각 변경 후에는 브라우저를 완전히 닫거나 짧게 대기한 뒤 측정합니다. PowerShell에서 호출하는 도구는 프로시 버전에 따라 시스템 프록시를 무시합니다. 이때는 문서에 적힌 mixed-port를 환경 변수로 넣거나 TUN만으로 검증해 원인을 분리하세요. 포트 충돌 메시지가 보이면 포트 사용 중 글 절차를 먼저 밟는 편이 좋습니다.
3단계: Strict Route 적용과 재시작 순서
스택 후보 가운데 하나를 일단 고정한 상태에서 Strict Route를 켭니다. GUI에서 스위치 이름이 다를 수 있으나 의미는 동일하게 “라우트를 더 단단히 묶는다”로 이해하면 됩니다. 켠 직후 코어가 재시작되면 트레이 상태가 잠깐 회색으로 돌아갈 수 있습니다. 이때 과도하게 연속 클릭하지 말고 로그 패널에서 재시작 한 줄이 성공으로 끝났는지 확인합니다.
Strict Route를 켠 뒤 로컬 장비가 끊기면 우선 끄고, 프로필의 국내 직행 규칙과 DNS 폴백 순서를 확인합니다. 특정 앱만 문제면 그 앱이 시스템 프록시 대신 자체 소켓을 쓰는지 살펴보고, 필요하면 앱별 예외나 규칙 추가를 검토합니다. 이 단계에서 규칙 파일 자체를 크게 바꾸기보다는 “스택·Strict Route·DNS” 삼각형만 움직여 증상 폭을 줄입니다.
4단계: 분류·라우트·로그로 검증
Mihomo Party의 연결 로그에서 동일 호스트가 어떤 정책으로 매치되는지 확인합니다. 규칙 이름과 노드 이름이 기대와 다르면 표면적으로는 TUN 문제처럼 보여도 실제로는 매치 순서 문제일 때가 많습니다. 로그에 TLS 핑거프린트나 리셋 문자열이 반복되면 연결 로그 TLS 글과 패턴을 대조합니다.
운영체제 쪽에서는 라우트 출력에서 터널 어댑터로 향하는 행이 과하게 넓은지, 종료 후에도 유령 행이 남는지 확인합니다. IPv6가 켜져 있다면 v4만 문제인지 v6만 문제인지 나눠 보세요. 브라우저만 성공할 때는 WebRTC나 확장 프로그램 간섭도 의심합니다. WebRTC 누출 글을 함께 보면 “분류는 맞는데 체감 출구가 다르다”는 문의를 빠르게 줄일 수 있습니다.
5단계: 끌 때 라우트와 프록시까지 정리
TUN을 끄기 전에 Mihomo Party 안에서 시스템 프록시 토글 상태를 확인합니다. 외부에서 시스템 프록시만 남으면 브라우저가 빈 포인트를 향하는 패턴이 나옵니다. 종료 순서를 바꿔도 증상이 남으면 Windows 설정의 프록시 페이지가 실제로 꺼졌는지 다시 열어 검증하세요. 라우트가 남는 경우에는 전용 안내가 더 빠릅니다. 종료 후 인터넷 복구 글과 같은 순서로 점검하면 재부팅 없이도 회복되는 경우가 많습니다.
클라이언트를 업데이트하거나 코어 바이너리를 교체할 때는 TUN과 Strict Route 스위치 상태를 메모해 두었다가 동일하게 되돌립니다. 버전마다 기본값이 달라지면 “업데이트 후에만 깨진다”는 문의가 생깁니다. 기본값이 바뀌었는지 릴리스 노트에서 확인하는 습관이 장기 운영에 유리합니다.
YAML에서 같이 보는 tun 블록
GUI 스위치와 동일한 내용이 프로필 YAML의 tun: 블록에 반영됩니다. 편집은 고급 사용자에게만 권장하지만, 값이 무엇으로 저장됐는지 확인하는 용도로는 안전합니다. 아래는 필드 이름을 맞추기 위한 예시이며 실제 키 이름은 코어 버전에 따라 다를 수 있으니 오류 줄을 기준으로 조정하세요.
tun:
enable: true
stack: gvisor
strict-route: true
stack을 system으로 바꾸거나 strict-route를 끄는 식으로 저장하면 다음 시작부터 동일하게 적용됩니다. YAML과 GUI를 동시에 편집하면 레이스가 생길 수 있으니 한쪽만 고치는 규칙을 정합니다. 프로필 문법 오류가 나면 코어가 아예 올라오지 않으니 작은 변경도 백업 후 진행하세요.
자주 묻는 질문
gVisor 스택과 system 스택 차이는 무엇인가요?
짧게 말하면 패킷 처리 경로가 다릅니다. 어떤 조합에서는 system이 더 빠르고, 다른 조합에서는 gVisor가 충돌이 적습니다. 문서보다 직접 A·B 테스트하는 편이 Win11에서 재현성이 높습니다.
Strict Route를 켜면 로컬 LAN이 끊길 수 있나요?
네, 프로필의 국내 직행·DNS·fake-ip 설정과 충돌하면 로컬 세그먼트가 우회될 수 있습니다. 일시적으로 끄고 규칙을 정리한 뒤 다시 켜 검증하세요.
TUN을 껐는데도 인터넷이 이상하면?
잔류 시스템 프록시나 라우트 엔트리가 남았을 가능성이 큽니다. 앞서 안내한 종료 순서 글과 Windows 설정 화면을 함께 확인하세요.
Mihomo Party 말고 다른 클라이언트에도 같나요?
Meta·mihomo 호환 클라이언트라면 개념과 필드 이름이 대부분 같습니다. 메뉴명만 다르니 확인 순서를 공유하면 됩니다.
맺음말
Mihomo Party처럼 그래픽으로 묶인 클라이언트가 늘어날수록 사용자는 같은 증상 문구로 검색하게 됩니다. 브라우저만 된다, 게임만 튄다, 종료 후 사이트가 안 연다. 해결책도 결국 비슷하게 수렴합니다. TUN 모드를 실제로 올렸는지, 그 안에서 스택이 환경과 맞는지, Strict Route가 출구를 한 줄기로 묶어 주는지, 끌 때 라우트와 시스템 프록시가 함께 내려갔는지. 이 네 가지를 순서대로 고정하면 문서 제목만 다른 글을 헤매는 시간이 줄어듭니다.
다만 클라이언트 제품마다 릴리스 속도와 설명 문자열이 제각각이라, 특정 앱 이름에만 매달린 커뮤니티 답변은 버전이 바뀌면 빠르게 낡습니다. 반대로 스택·Strict Route·DNS라는 축은 코어가 바뀌어도 오래 유지되는 편이라, 검증 순서를 한 페이지에 적어두는 편이 더 큰 자산이 되기도 합니다.
오픈 소스 계열 그래픽 클라이언트는 기능은 비슷하지만 패키징·업데이트 주기·문서 품질에서 차이가 납니다. 빌드가 갈라질수록 “어디서 받았는지·어떤 코어 문자열인지”를 사용자가 직접 추적해야 하는 부담이 커집니다. Clash V.CORE는 이런 반복 질문을 줄이려고 배포와 설명을 한 브랜드 축으로 묶고, Win·mac·모바일까지 같은 검증 습관으로 돌아올 수 있게 정리하는 데 초점을 둡니다. Mihomo Party로 TUN까지 맞춘 뒤에는 규칙 고도화와 로그 읽기에 시간을 쓰고 싶다면, 패키지 확인과 다운로드 기준점을 Clash V.CORE 다운로드 페이지에 두는 편이 업데이트 추적에 유리합니다.