Windows UWP 앱에서 프록시가 작동하지 않을 때: Clash 루프백 제한 해제 방법
UWP 앱이 기본적으로 로컬 프록시 포트에 연결할 수 없는 이유를 설명하고, 클라이언트 내장 루프백 도구, CheckNetIsolation 명령, TUN 모드의 사용 조건과 설정 방법을 비교합니다.
UWP 루프백 제한: 브라우저는 되는데 Microsoft Store 앱은 연결되지 않는 이유
Windows에서 Clash의 ‘시스템 프록시’를 켜면 브라우저에서는 사이트가 열리는데 Microsoft Store나 일부 UWP 앱은 계속 로딩만 할 수 있습니다. 이럴 때 구독 설정부터 바꾸지 마세요. 브라우저에서 연결된다는 사실은 해당 브라우저의 프록시 경로가 작동한다는 뜻일 뿐, 샌드박스 앱도 같은 로컬 포트에 연결할 수 있다는 의미는 아닙니다.
UWP 앱은 보통 AppContainer 격리 환경에서 실행됩니다. 기본 설정에서는 이런 앱의 로컬 루프백 주소 접근이 제한됩니다. Clash 계열 클라이언트는 대개 127.0.0.1에서 HTTP 또는 혼합 프록시를 수신하고, 시스템 프록시 설정은 앱의 요청을 이 주소로 보냅니다. 앱이 시스템 프록시 설정을 읽더라도 샌드박스에서 루프백 포트 연결이 차단되면 요청은 mihomo 코어에 도달하기 전에 실패할 수 있습니다. 따라서 로그에도 해당 요청이 기록되지 않을 수 있습니다.
먼저 세 가지 기능을 구분하세요
- 시스템 프록시: 이 설정을 사용하는 앱에 요청을 로컬 프록시로 보내도록 안내합니다. 모든 프로그램의 트래픽을 가로채지는 않습니다.
- 루프백 예외: 지정한 AppContainer가 루프백 네트워크에 접근하도록 허용합니다. 앱에 프록시를 자동으로 설정하거나 Clash 규칙을 변경하지는 않습니다.
- TUN 모드: 가상 네트워크 인터페이스와 라우팅으로 조건에 맞는 트래픽을 처리합니다. 앱마다 HTTP 시스템 프록시를 직접 읽을 필요가 없습니다.
설정 전 확인: 수신 포트, 시스템 프록시, 규칙 적용 여부
먼저 클라이언트에서 실제 수신 포트를 확인하세요. 아래에서는 mixed-port: 7890을 예시로 사용합니다. 모든 클라이언트의 기본값이 이 포트인 것은 아닙니다. 화면에 혼합 포트가 7897로 표시된다면 이후 명령에도 7897을 사용하세요. 컨트롤러 포트를 프록시 포트와 혼동하지 마세요. external-controller는 코어를 관리하는 인터페이스이며 일반 HTTP 프록시 요청을 받지 않습니다.
- 구독이 정상적으로 불러와졌는지, 클라이언트가 실행 중인지 확인한 뒤 사용할 수 있는 프록시 그룹 출구를 선택하세요.
- Windows 11에서 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’를 열고 ‘수동 프록시 설정’의 주소와 포트가 현재 클라이언트 설정과 일치하는지 확인하세요. Windows 10에서도 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 확인할 수 있습니다.
- 두 가지 트래픽 처리 방식이 충돌하지 않도록 먼저 TUN은 끄고 시스템 프록시만 켜세요.
- PowerShell에서 로컬 포트를 테스트한 다음, 명시적 프록시를 통한 요청으로 프록시 연결을 확인하세요.
Test-NetConnection -ComputerName 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --head https://www.microsoft.com/
TcpTestSucceeded: True는 PowerShell을 실행한 데스크톱 프로세스가 로컬 TCP 연결을 맺을 수 있다는 뜻일 뿐, UWP 샌드박스에도 접근 권한이 있다는 의미는 아닙니다. 두 번째 명령은 HTTP 프록시가 HTTPS 터널 요청을 처리하는지 확인합니다. HTTP 응답 헤더가 나오면 이 테스트 경로에서 응답을 받았다는 뜻입니다. 다만 실제 연결이 어떤 출구를 이용했는지는 클라이언트 로그도 함께 확인해야 합니다.
‘연결’ 또는 ‘로그’ 화면에서 대상 도메인과 적용된 정책을 확인하세요. 앱 요청이 기록되고 DIRECT가 적용됐다면 루프백 예외를 더 추가하기보다 규칙을 먼저 점검하세요. 규칙은 위에서부터 순서대로 적용되므로 앞쪽 도메인 규칙이 마지막의 MATCH보다 먼저 적용됩니다. 루프백 설정은 직접 연결 규칙을 프록시 규칙으로 바꾸지 않습니다.
방법 1: 클라이언트에 내장된 UWP 루프백 도구 사용
일부 Windows용 Clash 클라이언트에는 루프백 예외 설정 기능이 있습니다. 메뉴 위치는 클라이언트와 버전에 따라 다르므로 설정에서 ‘UWP’, ‘루프백 잠금 해제’ 또는 ‘Loopback’을 찾아보세요. 실제로 해당 메뉴가 있는 경우에만 이 방법을 사용하면 됩니다. 메뉴가 없다고 해서 코어의 프록시 기능이 부족한 것은 아니므로 다음 절의 Windows 명령을 사용해도 됩니다.
- 내장 루프백 도구를 엽니다. Windows 사용자 계정 컨트롤 창이 나타나면 프로그램 출처를 확인한 뒤 권한을 허용하세요. 예외 설정을 변경하려면 보통 관리자 권한이 필요합니다.
- 앱 목록에서 문제가 발생한 패키지를 찾습니다. 예를 들어 Microsoft Store가 해당됩니다. 확인이 필요한 앱만 선택하고 목록 전체를 한꺼번에 허용하지 마세요.
- 도구에서 ‘저장’ 또는 ‘적용’을 누릅니다. 설정이 즉시 반영되는 도구라면 화면에 표시되는 안내를 따르세요.
- 대상 앱을 완전히 종료한 뒤 다시 실행합니다. 창을 닫아도 백그라운드에서 계속 실행되는 앱은 작업 관리자에서 해당 프로세스를 종료한 다음 다시 시도하세요.
- 실패했던 작업을 다시 시도하면서 Clash 연결 기록을 확인하세요. 다음 절의 조회 명령으로 예외가 실제로 등록됐는지도 확인합니다.
이런 도구는 Windows의 루프백 예외 목록을 관리할 뿐, 구독 내용을 바꾸지는 않습니다. 저장한 뒤에도 앱이 작동하지 않으면 올바른 패키지를 선택했는지, 앱을 실제로 재시작했는지 먼저 확인하세요. 화면에 체크 표시가 있다는 것만으로 설정이 적용됐다고 판단하지 마세요.
방법 2: CheckNetIsolation으로 예외를 추가하거나 취소하기
CheckNetIsolation.exe는 Windows에 포함된 네트워크 격리 진단 도구입니다. 클라이언트에 전용 메뉴가 없거나, 현재 예외 상태를 확인해야 하거나, 특정 앱 하나만 허용하려는 경우에 적합합니다. 추가와 삭제 명령은 현재 로그인한 사용자의 관리자 PowerShell에서 실행하세요. 다른 관리자 계정의 자격 증명을 사용한다면 조회된 앱이 대상 사용자에게 속하는지 반드시 확인해야 합니다.
1. 패키지 패밀리 이름 조회
시작 메뉴에서 PowerShell을 검색한 뒤 ‘관리자 권한으로 실행’을 선택하세요. 먼저 Microsoft Store의 패키지 정보를 조회합니다:
Get-AppxPackage -Name Microsoft.WindowsStore |
Select-Object Name, PackageFamilyName
명령 결과의 PackageFamilyName이 -n=에 입력할 패키지 패밀리 이름입니다. 버전 번호와 아키텍처 정보가 포함된 PackageFullName을 사용하거나 시작 메뉴에 표시되는 이름을 직접 입력하지 마세요. 다른 앱은 현재 사용자의 패키지 목록을 먼저 출력한 다음 Name으로 찾으면 됩니다:
Get-AppxPackage |
Sort-Object Name |
Select-Object Name, PackageFamilyName
2. 지정한 앱에 예외를 추가하고 결과 확인
다음 명령은 Microsoft Store의 패키지 패밀리 이름을 자동으로 가져오므로 직접 복사할 때 공백이 섞일 염려가 없습니다. 패키지를 찾지 못하면 빈 인수를 전달하는 대신 추가 작업을 중단하고 오류를 표시합니다:
$store = Get-AppxPackage -Name Microsoft.WindowsStore
if ($null -eq $store) {
Write-Error "현재 사용자에서 Microsoft.WindowsStore 패키지를 찾을 수 없습니다."
} else {
CheckNetIsolation.exe LoopbackExempt -a "-n=$($store.PackageFamilyName)"
}
CheckNetIsolation.exe LoopbackExempt -s
-a는 예외 추가, -s는 현재 예외 목록 조회를 뜻합니다. 결과에는 패키지 이름이나 해당 AppContainer SID가 표시될 수 있습니다. SID를 확인하려면 Get-AppContainerProfile -Name *을 실행하세요. 추가가 완료되면 Microsoft Store를 완전히 종료했다가 다시 실행하고 문제가 있던 작업을 재시도합니다.
3. 이번에 추가한 예외 취소
$store = Get-AppxPackage -Name Microsoft.WindowsStore
if ($null -ne $store) {
CheckNetIsolation.exe LoopbackExempt -d "-n=$($store.PackageFamilyName)"
}
CheckNetIsolation.exe LoopbackExempt -s
-d는 지정한 항목을 삭제합니다. 되돌릴 때는 이번에 변경한 항목만 취소하세요. 다른 앱에 영향을 줄 수 있으므로 전체 예외를 지우는 명령은 사용하지 마세요. 앱을 삭제 후 재설치했거나 패키지 정보가 바뀌었거나 시스템을 초기화했다면 이전 실행 결과만 믿지 말고 현재 상태를 다시 조회해야 합니다.
방법 3: 시스템 프록시를 읽지 않는 앱은 TUN으로 처리
대상 앱이 시스템 프록시 설정을 읽지 않는다면 루프백 예외를 추가해도 127.0.0.1:7890에 자동으로 연결되지는 않습니다. 이 경우 mihomo TUN을 지원하는 클라이언트를 사용해 앱이 실제 대상 주소로 연결을 시작하게 한 뒤 가상 네트워크 인터페이스에서 트래픽을 처리할 수 있습니다. 이 방식은 트래픽이 코어에 들어오는 경로를 바꾸는 것이지 Windows의 모든 네트워크 격리 정책을 해제하는 것은 아닙니다.
- 앱이 로컬 프록시 포트에 계속 연결을 시도하지 않도록 시스템 프록시를 먼저 끄세요.
- 클라이언트 안내에 따라 서비스 모드를 설치하거나 시작한 다음 ‘TUN 모드’를 켭니다. Windows에서 가상 인터페이스를 만들고 라우팅을 설정하려면 관련 권한이 필요할 수 있습니다.
- 다른 VPN이나 유사한 가상 네트워크 어댑터를 사용하는 프록시는 잠시 종료하세요. 기존 설정은 기록해 두고 시스템 라우팅을 바로 삭제하지 마세요.
- 대상 앱을 완전히 재시작한 뒤 연결 화면에서 대상 주소, 적용된 규칙, 프록시 그룹을 확인하세요.
- 연결 기록이 없다면 TUN 라우팅, DNS, 앱 자체의 네트워크 권한을 확인하세요. 연결 기록이 있다면 적용된 규칙을 기준으로 문제를 좁혀 가세요.
mihomo 설정을 직접 관리하는 경우 아래의 일반적인 TUN 항목을 참고하세요. 이 항목들을 기존 설정에 병합해야 하며 구독 전체를 아래 몇 줄로 대체하면 안 됩니다. 클라이언트 화면에서 TUN 설정을 생성한다면 실행 중 설정이 수동 설정을 덮어쓰지 않도록 화면 설정을 우선 사용하세요.
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
auto-route는 트래픽 라우팅을 자동으로 설정하고, auto-detect-interface는 출구 인터페이스를 감지합니다. dns-hijack 설정은 조건에 맞는 일반 DNS 트래픽에 적용되며 암호화된 DNS를 모두 가로채는 것은 아닙니다. 기존 dns 설정이 작동하는지, 현재 클라이언트와 코어가 선택한 네트워크 스택을 지원하는지도 확인하세요.
TUN은 모든 Microsoft Store 앱 문제를 해결하는 만능 방법이 아닙니다. AppContainer 권한 제한, 조직 정책, 앱의 프록시 구현 방식, 백그라운드 서비스의 네트워크 동작이 연결에 영향을 줄 수 있습니다. 앱이 로컬 HTTP 프록시에 명시적으로 연결한다면 루프백 제한이 여전히 문제일 수도 있습니다. 따라서 TUN을 테스트할 때는 시스템 프록시를 끄고 앱을 재시작하는 것이 중요합니다.
세 가지 방법 중 선택하기: 영향 범위를 좁게 시작하고 결과 확인
| 방법 | 적합한 상황 | 확인 및 되돌리기 |
|---|---|---|
| 클라이언트 내장 루프백 도구 | 앱이 시스템 프록시를 사용하고 클라이언트에 UWP 관리 메뉴가 있는 경우 | 예외 목록을 조회하고 대상 앱의 선택을 해제한 뒤 저장 |
| CheckNetIsolation | 패키지를 정확히 지정하거나 상태를 확인하고 특정 앱의 권한만 취소해야 하는 경우 | -s로 조회하고 -d로 지정 항목 삭제 |
| TUN 모드 | 앱이 시스템 프록시를 사용하지 않거나 더 많은 네트워크 트래픽을 처리해야 하는 경우 | 연결 기록과 라우팅을 확인하고 TUN을 끈 뒤 기존 트래픽 처리 방식 복원 |
먼저 로컬 포트가 작동하는지 확인한 뒤 대상 앱 하나에만 루프백 예외를 추가하는 것이 좋습니다. 그래도 앱 요청이 코어에 전혀 들어오지 않는다면 TUN을 별도로 테스트하세요. 한 번에 한 설정만 변경해야 연결이 복구됐을 때 어떤 조치가 효과가 있었는지 알 수 있습니다.
여전히 연결되지 않나요? 로그가 나타나는 단계에 따라 확인하세요
연결 기록이 없음
- 앱을 실제로 재시작했는지, 현재 사용자의 패키지에 설정을 적용했는지 확인하세요.
- 클라이언트를 재시작한 뒤 시스템 프록시 포트가 바뀌지는 않았는지, 다른 프록시 프로그램이 Windows 설정을 덮어쓰지는 않았는지 확인하세요.
- 회사나 학교에서 관리하는 기기는 루프백 예외, 가상 네트워크 어댑터, 라우팅 변경이 제한될 수 있습니다. 기기 관리 정책을 따르세요.
연결 기록은 있지만 DIRECT로 연결됨
이 경우 루프백 경로가 우선 의심 대상은 아닙니다. 적용된 규칙의 유형과 내용, 정책 그룹 선택을 확인해 해당 도메인이 직접 연결되어야 하는지 프록시를 거쳐야 하는지 점검하세요. Microsoft Store의 페이지, 로그인, 다운로드에는 서로 다른 도메인과 백그라운드 서비스가 사용될 수 있습니다. 한 번의 오류를 해결하려고 모든 Microsoft 도메인에 같은 정책을 강제로 적용하지 않는 것이 좋습니다.
프록시로 연결되지만 로그인이나 다운로드가 실패함
실패한 단계를 나누어 기록하세요. Store 홈 열기, 계정 로그인, 다운로드 주소 받기, 설치 파일 실제 다운로드 단계가 각각 다를 수 있습니다. 홈 화면이 열린다고 해서 다운로드 서비스도 같은 네트워크 경로를 사용하는 것은 아닙니다. 이 단계에서는 노드 연결 상태, DNS 결과, 시스템 시간, 인증서 오류를 확인하세요. netsh winhttp reset proxy를 만능 해결책으로 사용하지 마세요. WinHTTP 설정은 현재 사용자의 시스템 프록시와 별개입니다.
문제 해결이 끝나면 필요한 예외만 남기고 임시 변경은 되돌리세요. 시스템 프록시를 읽는 UWP 앱 하나가 로컬 프록시에 연결되게 하려는 경우에는 전체 시스템에서 TUN을 계속 켜 두는 것보다 루프백 예외가 상태를 확인하기 쉽습니다. 여러 프로그램이 시스템 프록시를 무시한다면 TUN이 전체 라우팅과 DNS에 미치는 영향을 검토하세요.