Clash UWP 루프백 예외 설정: Microsoft Store 앱에서 프록시가 작동하지 않을 때 해결 방법

먼저 로컬 루프백 제한인지 확인하기

브라우저에서는 Clash를 통해 웹페이지가 열리는데 특정 Microsoft Store 앱에서 로그인하거나 목록을 불러오거나 콘텐츠를 가져오지 못한다면 AppContainer의 네트워크 격리가 원인일 수 있습니다. 일반적인 연결 흐름은 앱이 시스템 프록시를 읽고 로컬 주소 127.0.0.1:7890에 연결을 시도하지만, Clash의 수신 포트에 도달하기 전에 차단되는 방식입니다. 이 경우 노드를 바꾸거나 라우팅 규칙을 조정해도 해당 단계의 결과는 달라지지 않는 경우가 많습니다.

UWP 앱은 보통 AppContainer에서 실행되며, 기본적으로 로컬 루프백 서비스에 자유롭게 접근할 수 없습니다. 루프백 예외는 지정한 앱 컨테이너가 로컬 서비스를 이용하도록 허용하는 설정입니다. 프록시 설정을 구성하거나 노드를 자동으로 지정하고 DNS를 변경하는 기능은 아닙니다. 앱이 계속 Clash를 거치는 네트워크 경로를 사용해야 합니다.

실행 전 확인할 세 가지

Clash 코어가 실행 중이고, 일반 브라우저에서 같은 프록시를 통해 대상 서비스에 접속할 수 있어야 합니다.
시스템 프록시나 앱 자체의 로컬 프록시 설정을 사용 중이어야 합니다. 클라이언트 창만 열어 둔 상태로는 부족합니다.
문제가 특정 앱에만 나타나야 합니다. 모든 앱에서 인터넷에 연결되지 않는다면 구독, 노드, 포트, 네트워크 연결부터 확인하세요.

이 문서의 명령은 Windows 10 및 Windows 11의 PowerShell에서 사용할 수 있습니다. 예시 포트는 7890으로 통일했으며, 실제 작업에서는 현재 적용된 설정을 기준으로 해야 합니다. 예시와 같다는 이유만으로 정상 작동 중인 클라이언트의 수신 포트를 바꾸지 마세요.

시스템 프록시와 Clash 수신 포트 확인

Windows 11에서는 「설정」→「네트워크 및 인터넷」→「프록시」로 이동합니다. Windows 10에서도 「설정」→「네트워크 및 인터넷」→「프록시」 경로에서 확인할 수 있습니다. 수동 프록시나 설정 스크립트가 클라이언트의 현재 상태와 일치하는지 살펴보세요. 로컬 수동 프록시를 사용한다면 주소는 보통 127.0.0.1이며, 포트는 Clash의 HTTP 또는 혼합 포트와 일치해야 합니다.

# 설정 예시: 수신 대기 필드만 설명하며 전체 설정은 아닙니다
mixed-port: 7890
allow-lan: false
mode: rule

mixed-port는 HTTP와 SOCKS 프록시 연결을 모두 받습니다. Windows의 수동 프록시는 HTTP 프록시를 사용하므로 SOCKS 연결만 받는 포트를 임의로 입력하면 안 됩니다. 설정에서 port와 socks-port를 별도로 사용한다면 전자를 선택하세요.

PowerShell에서 포트가 수신 대기 중인지 확인하고, 명시적 프록시 요청으로 시스템 프록시 설정의 영향을 분리해 확인합니다.

Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://www.microsoft.com/

수신 기록이 없다면 코어가 실행 중인지, 설정이 정상적으로 로드됐는지, 포트를 잘못 입력하지 않았는지 확인하세요.
정상적으로 수신 중인데 요청이 시간 초과된다면 Clash 로그에서 노드, 규칙, 대상 서비스를 확인하세요. 바로 루프백 예외를 추가하지 마세요.
HTTP 응답이 돌아오면 이번 데스크톱 프로세스의 프록시 요청은 완료된 것입니다. 리디렉션이나 접근 거부 응답이더라도 네트워크 연결 여부와 서비스 권한 문제를 구분해서 확인해야 합니다.

이 curl.exe 명령은 UWP 앱을 테스트하는 용도가 아니라 로컬 프록시 연결 경로를 확인하는 용도입니다. netsh winhttp show proxy는 WinHTTP 프록시 설정을 보여 주며, 사용자 시스템 프록시 확인을 대신할 수 없습니다. UWP 앱 하나를 고치려고 컴퓨터 전체의 WinHTTP 설정을 바로 초기화하지 마세요.

방법 1: 클라이언트의 루프백 예외 도구 사용

일부 Windows용 Clash GUI 클라이언트에는 외부 루프백 관리 도구가 포함되어 있으며, 메뉴 이름은 「UWP 루프백 예외」, 「Loopback」 또는 「UWP Loopback」 등으로 표시될 수 있습니다. 메뉴 위치와 통합 여부는 클라이언트 및 버전에 따라 다르므로 모든 mihomo 클라이언트에 같은 메뉴가 있다고 가정하면 안 됩니다. 메뉴를 찾을 수 없다면 다음 절의 시스템 명령을 사용하세요. 다른 프록시 클라이언트를 설치할 필요는 없습니다.

현재 설정을 먼저 저장하고 문제가 발생한 앱 이름을 기록해 두세요.
클라이언트 설정에서 루프백 관리 메뉴를 찾아 도구를 실행합니다. 사용자 계정 컨트롤 창이 표시되면 프로그램 출처를 확인한 뒤 권한을 허용하세요.
앱 목록에서 대상 앱을 찾아 해당 항목을 선택합니다. 로컬 프록시에 실제로 접근해야 하는 앱만 허용하는 것이 좋습니다.
도구에서 저장 또는 변경 사항 적용을 누르세요. 항목을 선택하기만 하고 저장하지 않으면 시스템 예외 목록에 반영되지 않는 경우가 많습니다.
대상 앱을 완전히 종료한 뒤 다시 실행하고, 같은 로그인 또는 콘텐츠 로드 작업을 다시 시도하세요.

앱 목록에 대상 항목이 없다면 먼저 해당 앱이 현재 Windows 사용자 계정에 설치되어 있는지 확인하세요. 일부 앱은 여러 패키지나 별도 구성 요소로 이루어져 있어 화면에 표시되는 이름과 실제 요청을 보내는 패키지 이름이 다를 수 있습니다. 이 경우 이름이 비슷한 항목을 모두 선택하지 말고 PowerShell에서 패키지 식별자를 조회하세요.

방법 2: CheckNetIsolation으로 예외 추가

1. PackageFamilyName 조회

현재 로그인한 사용자의 PowerShell에서 다음 명령을 실행합니다. 아래는 Microsoft Store 패키지를 예로 든 것으로, 패키지 식별자를 조회하는 방법을 보여 줄 뿐 모든 다운로드 또는 로그인 문제를 루프백 예외로 해결할 수 있다는 뜻은 아닙니다.

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

일반적인 패키지 계열 이름은 Microsoft.WindowsStore_8wekyb3d8bbwe이지만, 실제로는 이 컴퓨터에서 출력된 값을 기준으로 해야 합니다. 다른 앱은 현재 사용자의 패키지 목록을 먼저 표시한 다음 Name을 확인해 범위를 좁히세요.

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

PackageFamilyName과 PackageFullName은 서로 다릅니다. 후자에는 보통 버전과 아키텍처 정보가 포함되므로 아래 -n 매개변수에 그대로 전달하지 마세요. 앱 설치 폴더 경로를 복사해서 넣어도 안 됩니다. 조회 결과가 없다면 패키지 이름, 설치된 사용자, 앱 유형부터 확인하세요.

2. 관리자 터미널에서 예외를 추가하고 확인

시작 버튼을 마우스 오른쪽 버튼으로 클릭하고 「터미널(관리자)」 또는 「Windows PowerShell(관리자)」를 선택합니다. 대상 앱을 사용하는 계정과 같은 계정에서 관리자 권한으로 실행하는 것이 좋습니다. 다른 관리자의 자격 증명을 입력해 터미널을 실행했다면 조회된 앱 패키지가 올바른 사용자 소유인지 확인하세요.

CheckNetIsolation.exe LoopbackExempt -s

CheckNetIsolation.exe LoopbackExempt -a -n="Microsoft.WindowsStore_8wekyb3d8bbwe"

CheckNetIsolation.exe LoopbackExempt -s

-s는 현재 예외 목록을 표시하고, -a는 지정한 앱을 추가합니다. 첫 번째 조회 결과는 변경 전 상태를 기록하는 데 사용하고, 두 번째 조회 결과로 변경 사항을 확인합니다. 출력에는 앱 이름과 SID가 함께 표시될 수 있으므로, 명령 창에 오류가 없다는 점만 보지 말고 대상 항목이 맞는지 확인하세요.

추가한 뒤 대상 앱을 완전히 종료하고 다시 실행하세요. 필요한 경우 작업 관리자에서 프로세스가 종료됐는지 확인합니다. 일반적으로 Windows 전체를 재시작할 필요는 없습니다. 앱에 상주 백그라운드 프로세스가 있다면 창만 닫는 것으로는 새 연결이 만들어지지 않을 수 있습니다.

3. 앱 하나의 예외 삭제

CheckNetIsolation.exe LoopbackExempt -d -n="Microsoft.WindowsStore_8wekyb3d8bbwe"

CheckNetIsolation.exe LoopbackExempt -s

-d는 지정한 앱의 허용을 취소합니다. 문제를 확인하는 과정에서 모든 예외를 한꺼번에 지우지 마세요. 다른 개발 도구나 로컬 서비스가 기존 항목을 사용 중일 수 있습니다. 액세스 거부가 표시되면 먼저 터미널이 관리자 권한으로 실행됐는지 확인하세요. 조직 정책이 적용되는 장치라면 관리자에게 권한 범위를 문의하세요.

예외를 추가해도 해결되지 않을 때: 연결 단계별 점검

예외 목록에 대상 앱이 보인다는 것은 허용 설정이 기록됐다는 뜻일 뿐, 요청이 프록시를 거쳤다는 증거는 아닙니다. Clash에서 연결 기록이나 로그를 열고 대상 작업을 다시 시도하세요. 노드 변경, TUN 활성화, DNS 수정 등을 한꺼번에 하지 말고 한 번에 하나씩만 바꿔야 원인을 파악할 수 있습니다.

확인 결과	우선 확인할 항목	다음 조치
Clash에 해당 연결이 표시되지 않음	앱이 시스템 프록시를 사용하는지, 패키지 식별자가 맞는지	앱을 다시 시작하고 시스템 프록시와 실제 네트워크 요청 구성 요소를 확인
연결 기록에서 DIRECT로 표시됨	규칙 순서와 현재 실행 모드	실제로 일치한 규칙을 확인하고 예외를 계속 추가하지 않기
프록시에 연결됐지만 시간 초과	노드 상태, 출구 지역, 대상 서비스	같은 대상을 이용해 비교하고 연결 오류를 확인
도메인 이름을 확인할 수 없음	앱, 시스템, 코어에서 실제로 사용하는 DNS 조회 경로	DNS 요청을 처리하는 주체를 확인한 뒤 해당 설정을 조정
로그인 또는 다운로드만 실패	별도 백그라운드 서비스, 계정, 서비스 제한	로그인, 목록 표시, 다운로드 요청을 각각 확인

앱이 시스템 프록시를 사용하지 않음

루프백 예외를 추가해도 앱이 Windows 프록시 설정을 사용하도록 강제할 수는 없습니다. 앱이 별도의 네트워크 스택을 사용하거나 원격 서버에 직접 연결하거나, 시스템 서비스가 대신 요청을 보내는 경우에는 포그라운드 앱에 예외를 추가해도 실제 연결 경로가 달라지지 않을 수 있습니다. Store 페이지는 열리지만 다운로드에 실패한다면 다운로드 단계에서 다른 서비스 경로로 전환됐을 수도 있습니다.

규칙은 적용됐지만 출구가 요구 사항과 다름

연결이 Clash에 표시된다면 mode: rule에서 어떤 규칙이 적용됐는지, 정책 그룹이 최종적으로 어떤 항목을 선택했는지 확인하세요. 서버는 출구 지역, 계정 상태, 접속 빈도에 따라 오류를 반환할 수 있으며, 이런 응답은 루프백 권한을 추가해도 해결되지 않습니다. 노드 지연 시간 테스트가 성공했다는 이유만으로 대상 서비스도 정상 작동한다고 판단하지 마세요.

방화벽, 조직 정책, 네트워크 기능

로컬 방화벽, 엔드포인트 보안 정책 또는 앱이 선언한 네트워크 기능으로 인해 연결이 제한될 수도 있습니다. 루프백 예외는 모든 네트워크 제한을 해제하는 설정이 아닙니다. 구체적인 오류 코드와 발생 시각, 관련 로그를 기록하고 해당 프로세스에 적용되는 정책을 확인하세요. 장기적인 해결책으로 방화벽 전체를 끄는 것은 권장하지 않습니다.

TUN으로 전환할 때와 시스템 프록시를 유지할 때

앱이 시스템 프록시를 사용하지 않는 것이 확실하고 IP 트래픽을 Clash가 처리해야 한다면 mihomo의 TUN 모드를 검토할 수 있습니다. TUN은 가상 네트워크 인터페이스와 라우팅을 이용해 트래픽을 처리하므로 각 앱이 HTTP 프록시 포트에 직접 연결할 필요가 없습니다. 다만 적용 범위는 라우팅, 제외 규칙, DNS 설정, 시스템 권한의 영향을 받습니다.

로컬 프록시에 접근해야 하는 AppContainer 앱이 몇 개뿐이라면 시스템 프록시와 필요한 앱만 대상으로 한 루프백 예외를 먼저 사용하세요. 영향 범위를 관리하기 쉽습니다.
앱이 프록시 설정을 사용하지 않고 직접 연결한다면 기본 설정이 정상인지 확인한 뒤 TUN을 별도로 테스트하고 실제 연결 기록을 살펴보세요.
TUN을 켜도 시스템 프록시를 유지하면 앱이 계속 로컬 프록시에 직접 연결할 수 있습니다. 따라서 루프백 제한이 남을 수 있으며, TUN을 켜는 것만으로 예외가 반드시 불필요해진다고 볼 수 없습니다.
기업 VPN이나 다른 가상 네트워크 어댑터를 사용하는 장치라면 먼저 라우팅과 DNS 충돌을 확인하세요. 여러 트래픽 처리 방식을 동시에 켜고 해결되기를 기대하지 마세요.

allow-lan: true는 루프백 예외를 대신하지 않습니다. 이 필드는 다른 장치가 프록시 수신 포트에 연결하도록 허용하는 설정이며, 로컬 AppContainer가 루프백에 접근하도록 허용하는 것과는 다릅니다. UWP 문제를 해결하려고 수신 범위를 넓히면 추가적인 접근 제어 관리가 필요해집니다.

적용 후 확인 및 관리

LoopbackExempt -s를 변경 전과 변경 후에 실행해 결과를 보관하고, 예상한 앱만 추가됐는지 확인하세요.
대상 앱을 다시 실행해 로그인, 콘텐츠 로드, 다운로드를 각각 테스트하세요. 시작 화면만 확인하고 끝내지 마세요.
Clash 연결 기록에서 대상 도메인, 적용된 규칙, 실제 정책을 확인하고 트래픽 경로가 예상과 일치하는지 점검하세요.
문제 확인을 위해 일시적으로 변경한 전역 모드, DNS 설정, 기타 무관한 변경 사항을 되돌린 뒤 다시 테스트하세요.

일반적인 앱 업데이트만으로 패키지 계열 이름이 바뀌는 경우는 드물므로, 업데이트할 때마다 권한을 다시 설정할 필요는 없습니다. 앱을 삭제 후 재설치하거나 다른 배포 경로로 설치한 경우, Windows 계정을 바꾼 경우, 시스템을 재설치한 경우에는 패키지 식별자와 예외 목록을 다시 확인해야 합니다.

문제 해결의 결론은 구체적인 단계에서 찾아야 합니다. 로컬 포트가 수신 중인지, 앱이 루프백에 접근할 수 있는지, 요청이 코어에 도달했는지, 규칙이 요청을 어디로 보내는지, 대상 서비스가 어떤 응답을 반환하는지 순서대로 확인하세요. 이렇게 하면 AppContainer 권한 문제와 구독, 노드, DNS, 서비스 자체의 문제를 구분할 수 있습니다.