Windows 스토어 앱에서 Clash 프록시가 작동하지 않을 때: CheckNetIsolation으로 UWP 루프백 제한 해제

브라우저는 되는데 스토어 앱은 안 된다면: 루프백 제한부터 확인

Windows에서 Clash 시스템 프록시를 켠 뒤 브라우저에서는 웹사이트가 열리지만 Microsoft Store나 특정 UWP 앱에서 네트워크에 연결할 수 없다는 메시지가 표시될 수 있습니다. 이런 차이는 AppContainer의 네트워크 격리 때문일 수 있습니다. 시스템 프록시는 보통 127.0.0.1:7890처럼 로컬 주소를 가리킵니다. 격리된 앱은 Clash 코어에 연결하기도 전에 Windows에서 이 주소 접속이 차단될 수 있습니다.

단, 스토어에서 설치했다고 해서 모두 UWP 샌드박스에서 실행되는 것은 아닙니다. Microsoft Store는 일반 데스크톱 프로그램도 배포하며, MSIX로 완전 신뢰 데스크톱 앱을 패키징할 수도 있습니다. 루프백 예외를 설정하기 전에 대상 앱의 실행 방식을 먼저 확인해야 합니다. 앱이 시스템 프록시를 무시하거나 프록시 포트가 잘못 설정된 경우, 로그인 서비스에 문제가 있는 경우에도 비슷한 증상이 나타날 수 있습니다.

세 가지 증상을 함께 확인하세요

일반 데스크톱 브라우저에서는 같은 서비스에 접속할 수 있습니다: 현재 노드와 기본 프록시 연결이 정상일 가능성을 보여 줍니다. 다만 브라우저에 별도의 프록시 확장 프로그램이 설치되어 있다면 시스템 프록시가 적용됐다고 단정할 수 없습니다.
대상 앱을 조작해도 해당 연결 기록이 없습니다: Clash의 연결 또는 로그 화면을 열고 앱을 새로고침하세요. 기록이 없다면 연결이 사전에 차단됐거나 앱이 시스템 프록시를 사용하지 않는 것일 수 있습니다.
시스템 프록시 주소가 로컬을 가리킵니다: 주소가 127.0.0.1, localhost 또는 루프백 IPv6 주소인 ::1인지, 포트가 코어의 실제 수신 포트와 일치하는지 확인하세요.

UWP 샌드박스와 127.0.0.1 연결 방식

루프백 주소는 현재 컴퓨터를 가리키며 외부 네트워크의 노드를 뜻하지 않습니다. 일반적인 연결 경로는 '앱 → 로컬 HTTP 프록시 포트 → Clash 또는 mihomo 코어 → 규칙에 따라 선택된 출구'입니다. 시스템 프록시 설정은 해당 설정을 따르는 앱에 연결 위치를 알려 줄 뿐, 앱에 적용된 네트워크 격리를 해제하지는 않습니다.

UWP 앱은 보통 AppContainer에서 실행됩니다. Windows는 앱과 로컬 서비스 간의 격리 경계를 유지하기 위해 이런 앱의 로컬 루프백 서비스 접근을 기본적으로 제한합니다. 프록시 서비스가 실행 중이어도 앱이 127.0.0.1:7890에 연결하지 못할 수 있습니다. CheckNetIsolation LoopbackExempt를 사용하면 특정 앱 패키지에 루프백 예외를 설정해 로컬 서비스에 접근하도록 허용할 수 있습니다.

작업	실제 기능	추가 확인 사항
시스템 프록시 켜기	로컬 프록시 주소와 포트 지정	앱이 시스템 프록시를 사용하는지
루프백 예외 추가	지정한 AppContainer에서 루프백 서비스에 접근하도록 허용	프록시 수신 설정, 노드 및 분기 규칙
프록시 규칙 수정	코어에 들어온 연결의 출구 결정	연결이 코어에 먼저 도달하는지
TUN 사용	가상 네트워크 인터페이스로 IP 트래픽 연결	라우팅, DNS, 권한 및 앱의 네트워크 동작

따라서 예외를 추가해도 앱이 프록시 출구를 강제로 사용하게 되는 것은 아닙니다. 연결이 코어에 들어온 뒤에도 DIRECT 규칙이 적용되거나 REJECT로 차단될 수 있습니다. 루프백 제한과 트래픽 분기는 서로 다른 단계이므로, 먼저 연결이 코어에 도달하는지 해결한 다음 출구를 확인하세요.

작업 전에 시스템 프록시와 수신 포트 확인

Clash 클라이언트와 코어를 실행하고, 유효한 노드가 포함된 설정이 활성화되어 있는지 확인하세요.
Windows 11에서는 '설정' → '네트워크 및 인터넷' → '프록시' → '수동 프록시 설정' → '프록시 서버 사용'의 '설정'을 엽니다. Windows 10도 '설정' → '네트워크 및 인터넷' → '프록시'에서 설정하지만 스위치 배치는 다릅니다.
클라이언트에서 시스템 프록시를 켰을 때 적용된 주소와 포트를 확인하세요. 로컬 프록시를 사용한다면 주소는 보통 127.0.0.1이며, 포트는 현재 HTTP 포트 또는 혼합 포트와 일치해야 합니다.
PowerShell에서 해당 포트로 TCP 연결을 설정할 수 있는지 확인한 다음 앱 예외를 추가하세요.

Test-NetConnection -ComputerName 127.0.0.1 -Port 7890
netstat -ano | findstr ":7890"

TcpTestSucceeded : True는 현재 PowerShell 프로세스가 해당 포트에 연결할 수 있다는 뜻입니다. UWP 앱의 접근이 허용됐거나 프록시를 통한 외부 연결까지 가능하다는 뜻은 아닙니다. netstat 결과에 해당 포트의 LISTENING 항목이 있어야 수신 중임을 확인할 수 있습니다. 다른 연결 상태만 표시된다면 코어가 수신 중이라는 근거가 되지 않습니다.

방법 1: CheckNetIsolation으로 특정 앱에 예외 추가

아래에서는 Microsoft Store를 예로 설명합니다. 문제가 발생한 Windows 사용자 세션에서 '시작'을 열고 PowerShell을 검색한 뒤 '관리자 권한으로 실행'을 선택하세요. 다른 관리자 계정의 자격 증명을 입력해 권한을 높이면 현재 사용자 컨텍스트가 달라집니다. 이 경우 Get-AppxPackage의 기본 검색 결과가 문제가 발생한 사용자와 일치하지 않을 수 있으므로 조회 대상을 먼저 확인해야 합니다.

1. 앱 패키지 패밀리 이름 찾기

Get-AppxPackage -Name Microsoft.WindowsStore |
  Select-Object Name, PackageFamilyName, PackageFullName

예외를 추가할 때 사용하는 값은 PackageFamilyName입니다. 표시 이름이나 버전과 아키텍처가 포함된 PackageFullName이 아닙니다. Microsoft Store의 일반적인 패키지 패밀리 이름은 Microsoft.WindowsStore_8wekyb3d8bbwe이지만, 실제 값은 현재 컴퓨터의 검색 결과를 확인하세요.

다른 앱을 점검하려면 현재 사용자의 앱 패키지 목록을 확인한 뒤 앱 이름으로 필터링하세요. 앱에 표시되는 이름과 패키지 이름은 다를 수 있으므로 아이콘에 적힌 이름만 보고 패키지 패밀리 이름을 추측하지 마세요.

Get-AppxPackage |
  Sort-Object Name |
  Select-Object Name, PackageFamilyName

2. 예외를 추가하고 결과 확인

아래 명령은 설치된 Microsoft Store 패키지에서 이름을 가져와 직접 입력할 때 생길 수 있는 오타를 방지합니다. 패키지를 찾지 못하면 스크립트가 중단되므로 빈 인수로 명령을 실행하지 않습니다.

$store = Get-AppxPackage -Name Microsoft.WindowsStore
if (-not $store) {
  throw "현재 사용자에게서 Microsoft.WindowsStore 앱 패키지를 찾지 못했습니다"
}
CheckNetIsolation.exe LoopbackExempt -a "-n=$($store.PackageFamilyName)"
CheckNetIsolation.exe LoopbackExempt -s

-a: 지정한 패키지에 루프백 예외를 추가합니다.
-n=: 패키지 패밀리 이름으로 앱을 지정합니다.
-s: 현재 루프백 예외 목록을 표시합니다.

실행 후 목록에 대상 앱 이름 또는 해당 SID가 표시되는지 확인하세요. 목록에 항목이 있다는 것만으로 방금 추가한 앱이 포함됐다고 볼 수는 없습니다. 액세스 거부 오류가 표시되면 터미널이 관리자 권한으로 실행 중인지 확인하세요. 인수나 패키지 이름 오류가 발생하면 패키지 패밀리 이름을 다시 조회하고, 전체 패키지 이름으로 바꿔 가며 반복해서 시도하지 마세요.

3. 앱을 다시 시작하고 연결 확인

대상 앱을 종료한 뒤 다시 열고, 앞서 실패한 작업을 다시 해 보세요. 일부 앱은 창을 닫아도 백그라운드 프로세스가 계속 실행됩니다. 작업 관리자에서 대상 프로세스가 종료됐는지 확인하고, 필요한 경우 작업 내용을 저장한 다음 앱 프로세스를 종료하세요. 예외 항목 하나를 추가하려고 컴퓨터 전체를 다시 시작할 필요는 보통 없습니다.

Clash 연결 기록에서 대상 도메인, 적용된 규칙, 정책 그룹 및 실제 노드도 확인하세요. 연결이 기록되는데도 페이지가 열리지 않는다면 트래픽 분기, DNS, 서비스의 지역 요건 또는 로그인 상태를 점검하세요. 앱 예외를 더 추가해도 이런 문제는 해결되지 않습니다.

방법 2: 클라이언트에 내장된 UWP 루프백 도구 사용

일부 Windows GUI 클라이언트에는 'UWP 루프백', 'Loopback' 또는 비슷한 메뉴가 있습니다. 이 기능도 Windows의 루프백 예외 목록을 관리합니다. 클라이언트 인터페이스에 포함된 도구일 뿐 Clash 설정에서 공통으로 사용하는 YAML 필드가 아니며, 모든 mihomo 클라이언트에 제공되는 것도 아닙니다.

구형 Clash for Windows 0.20.x에서는 일반적으로 'Settings' → 'System' → 'UWP Loopback' → 'Launch Helper'에서 실행할 수 있었습니다. 이 구버전의 메뉴 경로는 기존 설치를 확인하는 데 참고만 하세요. 새 클라이언트를 선택하는 기준으로 삼지 마세요. 다른 클라이언트에서는 현재 버전의 설정 메뉴를 확인하고, 해당 기능이 없다면 위의 Windows 명령을 사용하면 됩니다.

루프백 도구를 실행하고 시스템 안내에 따라 관리자 권한을 부여하세요.
앱 목록에서 로컬 프록시에 접근해야 하는 실제 대상 패키지를 찾으세요.
해당 앱을 선택하고 변경 사항을 저장하세요. 새 앱을 설치한 뒤에는 도구에 새로고침 버튼이 있다면 목록을 갱신하세요.
CheckNetIsolation.exe LoopbackExempt -s를 실행해 저장된 시스템 목록을 대조 확인하세요.
대상 앱을 다시 시작하고 연결이 코어에 도달하는지 확인하세요.

루프백 예외 취소 및 점검 기록 보관

로컬 시스템 프록시를 더 이상 사용하지 않거나 원인 확인을 위해 임시로 예외를 추가했다면 대상 앱의 예외만 취소할 수 있습니다. 아래에서는 추가할 때와 동일한 패키지 패밀리 이름을 사용해 Microsoft Store를 예로 설명합니다.

$store = Get-AppxPackage -Name Microsoft.WindowsStore
if (-not $store) {
  throw "현재 사용자에게서 Microsoft.WindowsStore 앱 패키지를 찾지 못했습니다"
}
CheckNetIsolation.exe LoopbackExempt -d "-n=$($store.PackageFamilyName)"
CheckNetIsolation.exe LoopbackExempt -s

-d는 지정한 패키지의 예외를 삭제합니다. 이후 목록을 다시 확인해 해당 항목이 제거됐는지 확인하세요. 다른 앱이나 개발·디버깅 환경에서 기존 항목을 사용할 수 있으므로 예외 목록 전체를 지우는 것은 권장하지 않습니다. 대상 앱을 이미 삭제했다면 이전에 저장한 패키지 패밀리 이름이나 목록의 SID로 기존 항목을 찾으세요. 검색 결과가 없는 앱 조회에서 계속 값을 가져오려 해서는 안 됩니다.

변경 전에 대상 앱의 패키지 패밀리 이름과 기존 예외 목록에 포함되어 있었는지 기록하세요.
프록시 주소와 포트, 클라이언트에서 사용 중인 설정 이름을 기록해 두면 예외 변경과 설정 변경의 영향을 구분하기 쉽습니다.
테스트 후 필요한 항목만 남기고, 임시로 허용한 앱은 각각 예외를 취소하세요.

TUN 모드 대안: 루프백을 허용하는 대신 트래픽을 가로채기

앱이 시스템 프록시를 사용하지 않는다면 루프백 예외를 추가해도 Clash를 사용하게 만들 수 없습니다. TUN을 지원하는 mihomo 클라이언트는 가상 네트워크 인터페이스와 라우팅을 통해 IP 트래픽을 처리할 수 있어, 원래 직접 인터넷에 연결하던 앱의 트래픽도 규칙에 따라 처리할 수 있습니다. 앱이 로컬 HTTP 프록시에 직접 연결하는 방식과는 다르므로, 적절한 라우팅과 DNS 설정을 사용하면 로컬 프록시 포트에 의존하지 않을 수 있습니다.

TUN이 모든 UWP 네트워크 문제를 해결하는 것은 아닙니다. 앱이 여전히 시스템 프록시를 사용해 접근이 제한된 루프백 주소에 연결하려 한다면 TUN만 켜서는 달라지지 않을 수 있습니다. 원인을 분리하려면 기존 설정을 기록한 뒤 시스템 프록시를 끄고 TUN만으로 테스트하세요. 단, 현재 클라이언트가 대상 트래픽을 실제로 처리하고 있는지 먼저 확인해야 합니다.

순서대로 TUN 확인하기

코어가 TUN을 지원하는지 확인하세요. mihomo와 구형 Clash 코어의 기능은 다르므로 클라이언트 이름만으로 지원 여부를 판단할 수 없습니다.
클라이언트 안내에 따라 서비스를 설치하거나 관리자 권한을 부여하고, 가상 네트워크 인터페이스가 정상적으로 생성됐는지 확인하세요.
자동 라우팅이 활성화되어 있는지 확인하고, 출처가 불분명한 TUN 설정 여러 개를 복사해 함께 적용하는 대신 클라이언트가 생성한 최종 설정을 점검하세요.
DNS 요청이 예상대로 코어에 전달되는지 확인하세요. DNS 하이재킹, 시스템 DNS, 앱 자체 암호화 DNS는 서로 다른 경로를 사용할 수 있습니다.
기본 경로 충돌을 줄이려면 다른 VPN이나 네트워크 트래픽 관리 프로그램을 잠시 종료한 뒤 대상 앱을 테스트하세요.

사용 방법은 간단히 구분할 수 있습니다. 앱이 시스템 프록시를 따르고 문제가 루프백 격리에 한정된다면 해당 앱에만 예외를 추가하세요. 앱이 시스템 프록시를 우회하거나 더 많은 트래픽을 처리해야 한다면 TUN을 고려하세요. TUN으로 전환한 뒤에도 적용된 규칙을 확인해야 합니다. 연결을 가로챈다고 모든 연결이 프록시 노드를 거치는 것은 아닙니다.

자주 발생하는 결과와 다음 점검 단계

예외 추가에 성공했는데도 스토어에서 연결할 수 없다고 합니다. 무엇을 확인해야 하나요?

먼저 대상 패키지가 예외 목록에 실제로 있는지 확인하고 앱을 다시 시작한 뒤, 코어에 연결 기록이 나타나는지 확인하세요. 연결이 기록된다면 DIRECT 규칙이 적용됐는지, 노드에서 해당 도메인에 접속할 수 있는지, 시스템 날짜와 시간이 정확한지 살펴보세요. 스토어 문제는 계정, 서비스 상태, 지역 제한과도 관련될 수 있습니다. 추가 명령을 반복해서 실행하지 말고 앱의 오류 코드를 바탕으로 원인을 좁히세요.

netsh winhttp import proxy source=ie 명령을 사용해야 하나요?

이 명령은 사용자 프록시 설정을 WinHTTP 프록시 설정으로 가져옵니다. 다른 프록시 사용 환경에 영향을 주며 AppContainer의 루프백 격리를 해제하지는 않습니다. CheckNetIsolation과 같은 해결 방법으로 취급하지 마세요. 대상 구성 요소가 WinHTTP를 사용하는 것이 확실하고 시스템 범위의 영향을 이해한 경우에만 별도로 점검하세요.

Clash 클라이언트를 바꿨는데도 예외를 확인해야 하는 이유는 무엇인가요?

예외는 Windows에 저장되며 구독 파일이 아니라 앱 패키지를 기준으로 합니다. 클라이언트를 바꿔도 대상 앱의 예외 식별 정보는 보통 달라지지 않지만, 로컬 수신 포트와 시스템 프록시 주소, 연결 방식은 바뀔 수 있습니다. 앱을 업그레이드해도 패키지 패밀리 이름이 그대로라면 기존 항목을 계속 사용할 수 있는 경우가 많습니다. 패키지를 새로 만들거나 배포 채널을 바꿨다면 이름을 다시 조회하세요.

전체 점검 순서는 코어 실행과 포트 수신 여부 확인, 시스템 프록시 주소 확인, 대상 앱의 AppContainer 루프백 격리 여부 파악, 앱별 예외 추가, 연결 규칙과 출구 확인입니다. 한 번에 하나씩만 변경해야 Windows 연결 문제와 구독, 노드, DNS 또는 규칙 문제를 구분할 수 있습니다.

설정 단계별 차이를 더 알아보려면 트래픽 분기 규칙 안내와 코어 안내를 확인하세요. 처음 연결하는 방법은 프록시 연결 가이드에서 볼 수 있습니다.