증상부터 짚어보면: 왜 크롬과 스토어만 다르게 느껴질까?
Microsoft Store 다운로드 느림이나 업데이트 진행 줄이 거의 안 움직이는 패턴은, 사람마다 환경이 달라서 한 가지 원인만으로 설명하기 어렵지만, 사용자들이 많이 겪는 대표적인 착각은 「브라우저에서 되면 나머지도 자동이다」입니다. 크롬·엣지는 확장 프로그램이나 앱별 프록시를 따로 쓸 수 있고, UWP 프록시 규격은 브라우저와 같은 스택이라고 보장되지 않습니다. Xbox 앱 프록시나 Xbox Game Pass 라이브러리도 같은 맥락에서, Windows 설정의 시스템 프록시를 따르는지·아니면 앱 컨테이너 차원에서 차단되는지가 갈립니다.
Sandbox된 UWP(앱 컨테이너에서 돌아가는 Microsoft Store 클라이언트 등)은 기본적으로 로컬 루프백, 즉 같은 PC 안의 다른 인터페이스로 빠져나오는 접속에 제약이 있습니다. 사용자가 「Clash Windows UWP 프록시」를 검색해 보통 찾게 되는 127.0.0.1:7890 같은 루프백 종착점은, 브라우저와 달리 UWP에서는 막히거나 규제가 까다로울 수 있습니다. 그래서 확장 프로그램이나 플러그인 레벨이 아니라, Windows 전역에 가깝게 맞춰야 하는 경우가 자주 있습니다.
설치 순서부터 맞추고 싶다면 Windows용 Clash Verge Rev 초기 세팅과, 포트가 겹치는지 모를 때 도움이 되는 7890 포트·mixed-port 점검 글도 함께 보세요. 같은 PC에서 라우팅 레이어까지 손보는 경우는 아래에서 TUN 모드와 묶어 설명합니다.
먼저 말부터 맞춥니다: 시스템 프록시, 브라우저, TUN
시스템 프록시라는 이름은 사람마다 WinHTTP·WinINET·WinRT 스택까지 한 단어로 퉁치는 경향이 있지만, 사용자 입장에서는 「Windows 설정 > 네트워크 및 인터넷 > 프록시」에 들어 있는 수동 설정이나 PAC가 실제로 어떤 API를 타는지」보다, Clash 클라이언트가 같은 값을 적어 줄 수 있는지가 핵심입니다. 많은 클라이언트에 있는 시스템 프록시 켜기 기능은 브라우저가 기본값으로 따라가도록 맞춰 주지만, 각 Win32·UWP 앱이 그 신호를 존중하는지는 따로 문제입니다.
반대로 TUN 모드는 OS나 앱 설정에 의존하지 않고, 가상 어댑터 쪽으로 트래픽을 받아 규칙에 따라 처리하는 패턴입니다. 개념·주의점은 TUN 모드 상세 글에 두껍게 정리돼 있습니다. 사용자가 검색했을 때 흔한 대비표는 다음과 같이 이해하면 혼선이 줄어듭니다. (1) 앱과 OS가 「시스템 프록시를 본다」는 전제 안에서 진행 줄이 빨간색으로만 남거나 인증 페이지가 반복된다면, 먼저 수동 프록시와 Clash 포트를 맞춥니다. (2) 시스템 설정을 따라도 특정 마켓 앱만 막히면 UWP 특유의 차단까지 의심합니다. (3) 그래도 애매하면 TUN으로 「일단 패킷이 Clash 레이어에 오는지」부터 나누고, 규칙·DNS 문제는 로그와 함께 좁혀 나갑니다.
터미널이나 명령줄까지 같은 mixed-port 한 벌을 쓰고 싶다면 git·curl·환경 변수, WSL이라면 호스트 경로 개념이 다른 WSL2 가이드를 참고하면 됩니다. 본 글은 그중에서도 「스토어·Xbox·UWP」에 초점을 둔 편이라, 가정용 무선 라우팅 대신 같은 PC 안에서 처리하는 패턴 중심으로 설명합니다. 라우터나 다른 기기까지 프록시를 퍼뜨리는 시나리오는 LAN 프록시 공유 글과 목적이 겹치니 비교해서 읽으면 좋습니다.
1단계: Clash 포트 확인 후 시스템 프록시와 같은 숫자로 맞추기
구성 설정에서 mixed-port(또는 HTTP 전용 포트)가 무엇인지 먼저 확인합니다. 예를 들어 7890이라면 수동 프록시 주소가 127.0.0.1, 포트가 그 숫자와 같은지 검증합니다. 이 때 이미 다른 프로그램이 같은 포트를 쓰고 있으면 Clash가 바인딩에 실패하거나, 사용자가 브라우저만 다른 포트로 보내고 있어서 혼란이 생깁니다. 앞에서 인용한 포트 충돌 글의 순서로 PID를 따라가 두면 디버깅이 빨라집니다.
GUI에서는 「시스템 프록시 설정」 같은 스위치를 켜고, 같은 창 안에 노출되는 주소 형식과 일치하게 Windows 설정에 반영되는지 확인합니다. 일부 사용자는 회사 또는 학교 장비라 GPO 때문에 수동 설정이 회색이라서, 사용자 수준에서는 절약 모드 같은 정책과 충돌할 수 있습니다. 또한 사용자 계정별로 레지스트리나 정책이 다르면, 테스트 계정에서는 되고 원래 계정에서만 안 되는 패턴도 나옵니다.
설정 변경 뒤에는 스토어를 완전히 닫았다가 다시 열고, Xbox 앱이라면 서비스 쪽 업데이트 큐까지 잠깐 초기화해 보는 것이 좋습니다. 큰 패치라도 순서가 나뉘는 경우가 많아 「한두 번 새로 고침」으로는 결과가 분리 안 됩니다.
2단계: UWP 한정으로 localhost·루프백이 필요할 때 예외 허용
시스템 프록시가 「로컬이 아니라 회사 WAN 쪽 종착 노드까지 직접 나간다」는 구조라면 문제가 줄어들지만, 실제 많은 사람의 집에서는 Clash 인스턴스가 같은 머신의 루프백 IP에서 듣고 있습니다. 일부 마켓 앱은 호스트 이름을 그대로 쓰거나, 업데이트 모듈이 내부적으로 루프백 테스트를 하는 식이라, Loopback 예외(루프백 면제) 항목이 없으면 막히는 증상이 보고되곤 합니다.
Microsoft 문서류에서도 검색되는 패턴처럼, 관리자 권한이 있는 명령 프롬프트나 PowerShell에서 CheckNetIsolation 계열 명령을 사용해 해당 앱 컨테이너 패밀리에 로컬 루프백 허용을 추가하는 접근입니다. 패키지 풀 네임은 버전별로 미묘하게 달라서, 한 번에 문자열을 외워서 적기보다 「현재 사용자 PC에 깔린 앱 패키지명을 조회한 뒤」 그 와일드카드 패밀리에 맞춰 등록한다는 순서가 안전합니다. 제거가 필요하면 동일 세트 안에 차단 목록 명령이 정리돼 있으니 과도한 허용만 남지 않도록 점검합니다.
# Example: enumerate Store-related packages, then exempt as needed with CheckNetIsolation
Get-AppxPackage *store* | Select Name, PackageFullName
보안 장비 또는 가정용 안심 필터·유해 사이트 차단 기능이 깔려 있는 환경에서는, 루프백뿐 아니라 SNI 검사나 DNS 필터링 때문에 스토어 CDN 접속 이름이 허용 목록에 없어서 줄이 진행되는 것처럼 보이는데 사실 차단 신호만 오는 경우도 있습니다. 이 경우 클라이언트 로그보다는 해당 보안 패널 로그 우선이라, 증상이 비슷해도 원인 레이어는 다릅니다.
대안 패턴: TUN으로 우회할 수 있는 경우와 할 수 없는 경우
UWP 앱 업데이트를 통째로 TUN 레이어에 올린다면, 이론상 시스템 프록시에 손 안 대도 동일 규칙으로 나올 가능성이 큽니다. 다만 회사 장비에서는 WFP, 가상 어댑터 드라이버, 또는 그룹 정책이 TUN 자체를 막거나, 사용자 모드 프로그램이 설치 레벨이 아니면 기동 불가 같은 제약도 있습니다. 그래서 무조건 TUN만이 정답은 아니고, (a) 시스템 프록시, (b) 루프백·앱 패키지, (c) TUN이라는 순서로 범위를 줄이면 재현 가능한 순서표가 만들어 집니다.
게임 패스용 콘솔 기능을 끌어오는 과정이라면 업데이트 서버 문자열과 인증 문자열이 갈라질 수 있습니다. GEOIP 또는 url-test 기반 정책이 너무 자주 출구를 바꾸면, 웹에서는 상단만 불러와도 다운로드 큐 하나에서만 줄이 새는 것처럼 느껴질 수 있습니다. 이때는 브라우저와 동일한 노드 고정이라는 접근 외에, 관련 규칙 순서 조정 방법을 연결 로그로 확인하는 게 도움이 됩니다. 패턴 참고만 하려면 로그·규칙 적중 Troubleshooting 글을 활용하면 됩니다.
추가로 손보는 곳: 배달 최적화, 캐시, 업데이트 서비스
프록시를 올바르게 타고 있어도 P2P 내부망 업데이트(배달 최적화)·배경 업데이트 큐 때문에 스토어만 느리게 느껴지는 사람도 있습니다. 설정 앱에서 전달 최적화나 동일 계열 옵션을 제한했을 때 패턴이 달라졌는지 비교하면, 문제가 네트워크 종단이 아니라 전송 레이어라는 신호일 수 있습니다. 임시로 Microsoft Store 또는 관련 업데이터 쪽 캐시를 비우거나 앱 초기화는 공식 방법을 따르는 편이 안전합니다.
악성 프로그램이 아닌데 Windows Defender 예외 때문에 실행 파일 자체가 격리됐던 경험이 있다면, Clash 재실행 순서부터 맞춰야 하므로 Defender 글을 먼저 정리하고 본 페이지로 돌아오는 게 좋습니다. 프록시 자체보다 우선 순위가 높은 단계였기 때문입니다.
실무에서 묻게 되는 소질문 몇 가지
VPN과 Clash를 동시에 켜두면 어떻게 하나요? 스택 순서 문제로 인터페이스 메트릭이 꼬이면 증상이 난해해집니다. 통상적으로 테스트할 때에는 한 줄기만 켜두고 패킷 출구부터 확정하기를 권장합니다.
브라우저 확장 프로그램만 되고 전역은 안 된다구요? 그 설명은 종종 크롬에만 패치가 깔린 상황을 말하는 것이라, 같은 맨션에서도 본 페이지에서 말하는 Xbox 앱 프록시와는 접점이 다른 경우가 많습니다. 확장이 아니라 OS 경로부터 다시 따라가세요.
언어팩 업데이트나 Xbox 클립을 같이 깔았는데 순서 차이? 일부 패키지는 순차 설치 순서 때문에 스토어마다 체크하는 호스트 문자열 수가 많아져서 줄이 두 단계처럼 느려집니다. 이 경우 시간대만 보지 말고, 연결 패널 로그 문자열까지 같이 확인하는 게 좋습니다.
마무리
정리하면, Microsoft Store 다운로드 느림이나 UWP 프록시 문제는 크롬과 브라우저 확장이 통하는 순간에는 드러나지 않던 UWP 전용 구간이 무엇인지 손보는 일입니다. Clash 시스템 프록시 설정과 같은 mixed-port 문자열부터 맞추고, 루프백을 요구하면 앱 패키지 기준 예외 명령을 검토합니다. 거기까지 갔을 때 패턴을 나누기 위해선 TUN 모드 같은 상위 레이어를 순서표에 넣는 편이 낫습니다.
클라이언트를 아직 깔 여유가 없다면, 동일 기능군별로 패키지를 비교해서 보는 사람도 많습니다. 무엇보다 설치 패스와 업데이트 안내가 한곳에서 정돈되어 있어야 따라가기 쉬우므로 → Clash 공식 다운로드 페이지에서 지금 플랫폼별 바이너리를 받아 테스트해 보실 수 있습니다. 준비가 되었다면 → Clash를 무료로 내려받아 Wi-Fi와 홈망 규모에 맞춰 차분히 검증해 보세요.