Windows 스토어 앱에서 Clash 프록시가 작동하지 않을 때: UWP 루프백 예외 설정 방법
UWP 네트워크 격리로 로컬 루프백 연결이 차단되는 이유와 클라이언트 내장 도구 또는 CheckNetIsolation 명령으로 스토어 앱의 제한을 해제하는 방법을 안내합니다.
먼저 확인하기: 로컬 루프백이 차단됐나요?
브라우저는 인터넷에 연결되는데 특정 스토어 앱만 연결에 실패한다면 루프백 제한을 먼저 확인해 보세요. 브라우저에서도 웹사이트가 열리지 않는다면 설정이 활성화됐는지, 노드를 사용할 수 있는지, 프록시 포트가 수신 대기 중인지부터 확인해야 합니다. 루프백 예외로는 만료된 구독, 잘못된 비밀번호, 연결할 수 없는 서버를 해결할 수 없습니다.
UWP는 Windows 앱 플랫폼 중 하나입니다. 이러한 앱은 보통 AppContainer라는 격리 환경에서 실행되며, 이 환경에서는 앱의 접근 범위가 제한됩니다. 로컬 루프백은 127.0.0.1 또는 ::1처럼 앱이 이 컴퓨터의 주소에 접속하는 것을 뜻합니다. Clash의 로컬 프록시는 흔히 이러한 주소에서 수신 대기하므로, 시스템 프록시가 Clash로 설정되어 있어도 격리된 앱은 연결하지 못할 수 있습니다.
다만 Microsoft Store에서 설치했다고 해서 반드시 UWP 앱인 것은 아닙니다. 스토어에서는 기존 데스크톱 프로그램과 패키징된 데스크톱 프로그램도 배포합니다. 앱 유형, 프록시 설정, 연결 로그를 함께 확인하고, 스토어 앱의 모든 네트워크 문제를 루프백 제한 탓으로 돌리지 마세요.
| 확인된 증상 | 우선 확인할 항목 | 다음 단계 |
|---|---|---|
| 브라우저와 대상 앱 모두 연결 실패 | 코어, 포트, 노드 및 규칙 | 먼저 로컬 프록시 연결 확인 |
| 브라우저는 정상인데 격리된 앱은 실패하고 Clash에 관련 연결이 없음 | 루프백 제한 또는 앱이 시스템 프록시를 사용하지 않음 | 대상 패키지에 예외를 추가한 뒤 다시 테스트 |
| Clash에 앱 요청은 표시되지만 연결 시간 초과 | 적용된 정책, 노드, DNS 및 원격 서비스 | 연결 세부 정보를 확인하고 예외를 반복해서 추가하지 않기 |
| 스토어 화면은 정상인데 다운로드 작업 실패 | 다운로드 서비스와 백그라운드 구성 요소의 네트워크 경로 | 화면에서 발생하는 트래픽과 백그라운드 다운로드 트래픽 구분 |
작업 전 확인: 시스템 프록시와 로컬 포트
먼저 실제 포트를 확인한 다음 격리 제한을 해제하세요. 아래에서는 127.0.0.1:7890을 예시로 사용합니다. 모든 클라이언트의 기본 주소는 아닙니다. HTTP 포트는 HTTP 프록시 요청을 받으며, 혼합 포트는 보통 HTTP와 SOCKS 요청을 모두 받습니다. Windows 수동 프록시에는 HTTP 프록시를 지원하는 포트를 입력해야 합니다. SOCKS만 지원하는 포트를 잘못 입력하지 마세요.
- 클라이언트를 열어 사용할 수 있는 설정이 선택되어 있는지 확인하고, 포트 설정이나 실행 중인 설정에서
port,mixed-port항목을 확인합니다. 현재 적용 중인 설정을 기준으로 판단하세요. - 클라이언트에서 ‘시스템 프록시’를 활성화합니다. Windows 11에서는 「설정」→「네트워크 및 인터넷」→「프록시」→「수동 프록시 설정」→「편집」으로 이동해 주소와 포트를 확인하세요.
- Windows 10에서는 「설정」→「네트워크 및 인터넷」→「프록시」에서 ‘프록시 서버 사용’을 확인합니다. 클라이언트가 이 값을 자동으로 설정할 수 있으므로, 확인 과정에서 같은 값을 다시 수동으로 변경할 필요는 없습니다.
- 먼저 정상 작동이 확인된 HTTPS 페이지를 브라우저에서 열고, 클라이언트의 ‘연결’ 또는 ‘로그’ 패널을 살펴보세요. 브라우저가 별도의 프록시 확장 프로그램을 사용한다면, 브라우저에서 연결에 성공해도 Windows 시스템 프록시가 정상이라는 뜻은 아닙니다.
명령으로 포트 수신 상태 확인
PowerShell에서 다음 명령을 실행합니다. 실제 포트가 7897이라면 명령에 있는 7890을 7897로 바꾸세요. 수신 대기 기록이 표시되면 이 컴퓨터의 프로그램이 해당 포트를 사용 중이라는 뜻입니다. 다만 그 프로그램이 현재 사용 중인 코어인지도 확인해야 합니다.
Get-NetTCPConnection -State Listen -LocalPort 7890 |
Select-Object LocalAddress, LocalPort, OwningProcess
Test-NetConnection -ComputerName 127.0.0.1 -Port 7890
TcpTestSucceeded : True는 이번 TCP 연결이 성공했다는 뜻일 뿐, 원격 웹사이트나 노드가 정상이라는 의미는 아닙니다. PowerShell은 보통 대상 앱의 격리 환경 밖에서 실행되므로, 이 결과만으로 UWP 앱의 루프백 접근이 허용됐다고 판단할 수도 없습니다.
방법 1: 클라이언트 내장 UWP 도구 사용
클라이언트에 UWP 도구가 있다면 앱별로 선택하는 방법을 먼저 사용하세요. 일부 Windows 클라이언트에는 루프백 예외 설정 화면이 포함되어 있으며, ‘UWP 루프백’, ‘Loopback’ 또는 ‘UWP Loopback’이라는 이름으로 표시될 수 있습니다. 이는 그래픽 클라이언트의 부가 기능이며 Clash나 mihomo 코어에서 공통으로 제공하는 메뉴는 아닙니다.
예를 들어 구버전 Clash for Windows 0.20.x에서는 「General」 페이지에서 「UWP Loopback」 메뉴를 찾을 수 있습니다. 이 경로는 기존에 설치된 버전을 확인할 때만 참고하세요. 다른 클라이언트에 그대로 적용할 수는 없습니다. 현재 클라이언트에 같은 메뉴가 없다면 다음 절의 Windows 명령을 사용하세요.
- UWP 루프백 도구를 엽니다. Windows 권한 확인 창이 나타나면 작업을 실행하는 프로그램이 현재 클라이언트에 포함된 도구인지 확인한 후 권한 상승을 허용하세요.
- 앱 목록에서 대상 앱을 찾습니다. 목록에 표시된 이름은 시작 메뉴의 이름과 조금 다를 수 있으므로, 필요하면 게시자와 패키지 이름으로 확인하세요.
- 로컬 프록시를 사용할 앱만 선택한 다음 저장 또는 적용을 누릅니다. 도구에 따라 버튼 이름이 ‘Save Changes’ 또는 ‘Apply’로 표시될 수 있습니다.
- 대상 앱을 완전히 종료하고 백그라운드에서 계속 실행 중이지 않은지 확인한 다음 다시 열어 네트워크 연결이 필요한 작업을 실행합니다.
- Clash의 연결 또는 로그 패널에서 새로운 대상 도메인 요청이 표시되는지 확인합니다. 앱 첫 화면에 캐시된 내용이 표시되는 것만으로 성공 여부를 판단하지 마세요.
방법 2: CheckNetIsolation으로 루프백 예외 추가
Windows에 기본 포함된 CheckNetIsolation으로 예외 목록을 확인하고 변경할 수 있습니다. 아래에서는 Microsoft Store 앱 패키지를 예로 듭니다. 현재 사용자 계정으로 관리자 권한 PowerShell을 여세요. Windows 11에서는 시작 버튼을 마우스 오른쪽 버튼으로 클릭한 뒤 「터미널(관리자)」를 선택해도 됩니다. 다른 관리자 계정의 자격 증명으로 터미널을 실행하는 경우, 조회한 앱 패키지가 대상 사용자 계정에 속하는지 확인하세요.
1단계: 정확한 앱 패키지 패밀리 이름 확인
명령에는 PackageFamilyName이 필요합니다. 패키지 패밀리 이름이라고도 합니다. 이는 바탕 화면 바로 가기의 이름도, 버전 번호와 아키텍처가 포함된 PackageFullName도 아닙니다. 먼저 현재 사용자 계정에 설치된 스토어 앱 패키지를 조회하세요.
Get-AppxPackage -Name Microsoft.WindowsStore |
Select-Object Name, PackageFamilyName
일반적인 결과에서 패키지 패밀리 이름은 Microsoft.WindowsStore_8wekyb3d8bbwe이지만, 실제 작업에서는 이 컴퓨터의 출력값을 기준으로 해야 합니다. 대상이 스토어 앱이 아니라면 패키지 이름의 일부로 검색할 수 있습니다. 예를 들어 Xbox 관련 패키지는 다음과 같이 조회합니다.
Get-AppxPackage -Name "*Xbox*" |
Select-Object Name, PackageFamilyName
와일드카드 검색으로 여러 결과가 나올 수 있습니다. 모든 결과를 예외 목록에 추가하거나 표시 이름을 패키지 패밀리 이름으로 착각하지 마세요. 결과가 없다면 앱이 현재 계정에 설치되어 있는지, 그리고 이 방법으로 식별할 수 있는 앱 패키지인지 먼저 확인하세요.
2단계: 대상 패키지에 예외 추가
아래 PowerShell 코드는 현재 사용자의 Microsoft Store 패키지를 찾아 루프백 예외 목록에 추가합니다. 코드의 빈 값 확인은 앱이 설치되지 않은 경우 다음 작업이 실행되지 않도록 합니다. 다른 앱에 적용하려면 Microsoft.WindowsStore를 확인된 정확한 패키지 이름으로 바꾸세요.
$package = Get-AppxPackage -Name Microsoft.WindowsStore
if ($null -eq $package) {
throw "현재 사용자 계정에서 Microsoft.WindowsStore 앱 패키지를 찾을 수 없습니다."
}
$family = $package.PackageFamilyName
CheckNetIsolation.exe LoopbackExempt -a "-n=$family"
-a는 추가를 뜻하며, -n 뒤에는 패키지 패밀리 이름을 입력합니다. 시스템에서 액세스 거부 메시지가 표시되면 터미널이 관리자 권한으로 실행 중인지 먼저 확인하세요. 권한 문제를 우회하려고 시스템 보안 기능을 끄지 마세요.
3단계: 목록 확인 후 앱 다시 시작
CheckNetIsolation.exe LoopbackExempt -s
-s는 현재 예외 목록을 표시합니다. 대상 패키지 패밀리 이름이 포함되어 있는지 확인하세요. 일부 항목은 보안 식별자 형식으로 표시될 수도 있습니다. 명령에서 추가 성공을 확인했다면 대상 앱을 종료한 뒤 다시 열어 새 네트워크 요청을 발생시키세요. 필요한 경우 로그아웃했다가 다시 로그인해 이전 프로세스가 계속 실행 중인 영향을 배제할 수 있습니다.
적용 여부 확인 및 안전하게 되돌리기
앱의 동작과 Clash 연결 기록을 함께 확인하세요. 설정이 효과가 있는지 확인하려면 명령 실행이 성공했는지만 볼 것이 아니라 변경 전후에 같은 작업을 비교하는 것이 좋습니다. 테스트 중에는 같은 노드와 같은 설정을 유지해 여러 조건을 동시에 바꾸지 마세요.
- 변경 전 증상을 ‘스토어에서 검색 실패’처럼 구체적으로 기록하세요. ‘인터넷이 안 됨’처럼 막연하게 적지 마세요.
- 대상 패키지에 루프백 예외를 추가한 다음 앱을 완전히 종료하고 다시 엽니다.
- 같은 검색이나 새로고침 작업을 반복해 앱에 새로운 서버 응답이 표시되는지 확인합니다.
- Clash에서 해당 시각의 연결, 도메인, 정책을 확인하세요. 규칙 모드에서
DIRECT가 적용되었다면 요청이 직접 연결로 지정된 것입니다. 루프백 설정이 실패했다는 뜻은 아닙니다.
더 이상 필요하지 않으면 패키지별로 삭제
예외를 해제하려면 -d를 사용합니다. 아래에서도 Microsoft Store를 예로 들며 패키지 패밀리 이름을 다시 조회하므로 이전 터미널 세션의 변수에 의존하지 않습니다.
$package = Get-AppxPackage -Name Microsoft.WindowsStore
if ($null -eq $package) {
throw "현재 사용자 계정에서 Microsoft.WindowsStore 앱 패키지를 찾을 수 없습니다."
}
$family = $package.PackageFamilyName
CheckNetIsolation.exe LoopbackExempt -d "-n=$family"
CheckNetIsolation.exe LoopbackExempt -s
삭제한 뒤 목록을 다시 확인해 대상 항목이 제거됐는지 확인하세요. 앱 하나의 설정을 되돌리려고 예외를 모두 지우지 마세요. 다른 앱이나 개발 환경, 디버깅 도구도 기존 항목을 필요로 할 수 있습니다. 앱을 다시 설치한 뒤 패키지 패밀리 이름이 바뀌었다면 다시 확인해야 합니다. 이전 항목이 남아 있다고 해서 새로 설치한 앱에도 권한이 부여된 것은 아닙니다.
예외를 추가해도 프록시를 사용하지 않을 때: 트래픽 경로별 점검
시스템 프록시, 전역 모드, TUN은 서로 다른 설정입니다
‘전역 모드’가 모든 프로세스를 강제로 Clash에 연결하는 것은 아닙니다. 전역 모드는 주로 코어에 들어온 트래픽이 어떤 출구를 사용할지 결정합니다. 앱이 시스템 프록시를 사용하지 않는다면 전역 모드로 바꿔도 트래픽이 자동으로 코어에 들어오지 않습니다. 먼저 ‘요청이 들어오지 않는 문제’인지 ‘들어온 뒤 잘못된 출구로 나가는 문제’인지 구분하세요.
TUN은 가상 네트워크 인터페이스를 통해 트래픽을 처리하는 방식입니다. mihomo를 사용하는 클라이언트에서는 관련 설정에서 활성화할 수 있지만, 대상 트래픽을 처리할 수 있는지는 라우팅, DNS, 권한, 제외 항목에도 달려 있습니다. TUN은 루프백 예외의 다른 이름이 아니며, 모든 스토어 앱 문제를 해결한다고 보장할 수도 없습니다. TUN을 테스트하려면 먼저 현재 설정을 저장하고 한 번에 한 가지 조건만 변경한 뒤 연결 로그를 확인하세요.
화면에서 실행되는 앱과 백그라운드 다운로드는 서로 다른 프로세스일 수 있습니다
Microsoft Store 페이지 요청과 앱 다운로드·업데이트 작업은 서로 다른 구성 요소를 거칠 수 있습니다. 스토어 화면을 표시하는 앱에 예외를 추가했다고 해서 백그라운드 서비스도 같은 사용자 계정의 시스템 프록시를 사용한다고 단정할 수는 없습니다. ‘페이지는 열리지만 다운로드는 실패’하는 경우에는 관련 없는 앱 패키지를 계속 추가하기보다 Windows 다운로드 서비스, 네트워크 오류, 실제 연결 기록을 확인하세요.
WinHTTP 설정을 만능 해결책으로 취급하지 마세요
Windows 사용자 프록시 설정과 WinHTTP 프록시 구성은 완전히 같은 방식으로 작동하지 않습니다. WinHTTP는 일부 프로그램과 시스템 서비스가 사용하는 네트워크 인터페이스이므로, 프록시를 변경하면 다른 작업에도 영향을 줄 수 있습니다. 아래 읽기 전용 명령으로 현재 설정을 확인할 수 있지만, 요청이 어디에서 발생하는지 파악하기 전에 설정을 무작정 가져오거나 덮어쓰지 마세요.
netsh winhttp show proxy
로그에 대상 요청이 표시된다면 다음으로 도메인 확인, 규칙 적용 결과, 노드 상태를 점검하세요. 요청이 전혀 없다면 앱이 별도 프록시를 사용하는지, 다른 프로세스가 네트워크에 연결하는지, 실제로 루프백 제한을 받는 앱 유형인지 확인해야 합니다. 설정 항목을 확인하려면 YAML 매뉴얼을, 일반적인 연결 문제는 자주 묻는 질문을 참고하세요.