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

먼저 문제가 로컬 루프백 제한 때문인지 확인

Windows 10 또는 Windows 11에서 브라우저는 Clash를 통해 인터넷에 연결되지만 특정 UWP 앱에서 계속 연결 오류가 발생한다면, 먼저 해당 앱이 AppContainer 네트워크 격리의 영향을 받는지 확인하세요. Clash 시스템 프록시는 보통 127.0.0.1:7890 같은 로컬 주소를 가리킵니다. AppContainer에서 실행되는 앱은 일반 데스크톱 프로그램과 달리 기본적으로 로컬 루프백 서비스에 접근할 수 없으므로, 트래픽이 프록시 엔진에 도달하기도 전에 연결이 실패할 수 있습니다.

여기서 ‘루프백 예외’란 지정한 앱이 로컬 루프백 주소에 접근하도록 허용하는 설정입니다. 프록시 규칙을 해제하거나 계정 제한을 없애는 기능이 아니며, 앱에 네트워크 기능을 자동으로 추가하지도 않습니다. 설정 대상은 구독이나 프록시 노드가 아니라 앱 패키지입니다. Microsoft Store에서 설치했다고 해서 모든 앱이 UWP인 것은 아닙니다. 패키징된 데스크톱 앱 중에는 완전 신뢰 프로세스로 실행되는 것도 있으므로 설치 경로만으로 판단하지 마세요.

확인 대상: 같은 PC와 네트워크에서 브라우저 프록시는 정상인데 특정 AppContainer 앱만 연결에 실패하고, 로컬 시스템 프록시를 사용 중인 경우입니다.
먼저 클라이언트 문제 제외: 브라우저도 연결되지 않는다면 프록시 엔진 실행 상태, 수신 포트, 노드 연결 상태부터 확인하세요.
먼저 서비스 측 문제 제외: 특정 계정, 다운로드 작업 또는 도메인에서만 오류가 발생한다면 로그인 상태, 서비스 이용 가능 여부와 연결 로그도 함께 확인하세요.

1단계: 시스템 프록시와 로컬 포트 확인

Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’ → ‘수동 프록시 설정’ → ‘편집’으로 이동하세요. Windows 10에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 수동 설정 항목을 확인하면 됩니다. 프록시 서버 주소와 포트가 클라이언트 설정과 일치하는지 확인하세요. 클라이언트의 ‘시스템 프록시’ 스위치가 이 값을 관리한다면 설정이 서로 덮어쓰이지 않도록 클라이언트에서 전환하는 편이 좋습니다.

시스템 프록시에는 HTTP 프록시 포트나 HTTP를 지원하는 혼합 포트를 사용해야 합니다. SOCKS 전용 포트나 프록시 엔진의 컨트롤 인터페이스 포트를 입력하지 마세요. 컨트롤 인터페이스는 설정 관리와 상태 조회용이며, 앱의 HTTP 프록시 요청을 전달하지 않습니다.

PowerShell로 TCP 수신 상태 확인

PowerShell · 로컬 포트 확인

Test-NetConnection -ComputerName 127.0.0.1 -Port 7890

출력에서 TcpTestSucceeded 값을 확인하세요. True는 해당 TCP 포트에 연결할 수 있다는 뜻일 뿐, 노드·DNS·대상 사이트까지 정상이라는 의미는 아닙니다. False라면 먼저 프록시 엔진을 실행하거나 포트를 바로잡으세요. 수신 중인 서비스가 없다면 루프백 예외를 추가해도 해결되지 않습니다.

Windows에 기본 포함된 curl.exe로 프록시를 명시해 HTTP 프록시 연결 경로를 확인할 수도 있습니다. 아래 명령은 제한 시간을 15초로 설정한 진단 예시이며, 실제 테스트 결과를 뜻하지 않습니다. 대상 사이트에 접속할 수 없다면 이미 접속 가능 여부를 알고 있는 다른 HTTPS 주소로 확인하세요.

PowerShell · HTTP 프록시 명시 사용

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

프록시를 명시한 요청은 성공하지만 대상 앱만 실패한다면 그때 루프백 권한을 확인하세요. UWP 앱이 로컬 프록시에 접근하도록 하려고 ‘LAN 연결 허용’을 켜지는 마세요. 이 설정은 다른 기기에서 수신 서비스에 접근하도록 하는 기능으로, 로컬 AppContainer의 루프백 격리와는 별개입니다.

2단계: 앱 패키지 패밀리 이름 확인 및 기존 예외 기록

CheckNetIsolation.exe는 Windows에 포함된 네트워크 격리 관리 도구입니다. 예외를 추가하거나 삭제할 때는 관리자 터미널을 사용하세요. 앱을 조회할 때는 실제 앱을 실행하는 Windows 사용자 계정으로 확인해야 합니다. 다른 관리자 계정으로 권한을 높이면 Get-AppxPackage가 조회하는 사용자도 달라질 수 있어 대상 패키지를 찾지 못할 수 있습니다.

대상 앱과 남아 있을 수 있는 백그라운드 프로세스를 모두 종료하세요.
대상 사용자 계정의 PowerShell에서 아래 조회 명령을 실행해 앱을 찾으세요.
‘시작’을 마우스 오른쪽 버튼으로 클릭한 다음 ‘터미널(관리자)’ 또는 ‘Windows PowerShell(관리자)’을 선택하고 사용자 계정 컨트롤 안내를 승인하세요.
예외 목록을 조회하고 변경 전 결과를 저장해 두세요. 이후 설정을 확인하거나 복구할 때 필요합니다.

PowerShell · 앱 식별 정보 및 기존 목록 조회

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

CheckNetIsolation.exe LoopbackExempt -s

추가 명령에는 패키지 패밀리 이름인 PackageFamilyName이 필요합니다. 표시 이름이나 버전·아키텍처 등이 포함된 PackageFullName이 아닙니다. 패키지 패밀리 이름은 보통 앱 이름, 밑줄, 게시자 식별자로 구성됩니다. 설치 디렉터리 이름을 보고 직접 조합하지 마세요.

Windows 계산기를 사용한 명령 예시

아래에서는 Microsoft.WindowsCalculator를 사용해 조회 방법을 보여 줍니다. 계산기는 일반적인 계산에 프록시가 필요하지 않으므로 명령 형식을 설명하기 위한 예시일 뿐, 네트워크 복구 여부를 확인하는 대상으로는 적합하지 않습니다. 실제 작업에서는 앞 단계의 목록에서 대상 앱의 Name에 맞춰 검색 이름을 바꾸세요.

PowerShell · 패키지 이름으로 정확히 검색

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

조회 결과가 없다면 현재 계정에 앱이 설치되어 있는지, 이름이 일치하는지 먼저 확인하세요. Microsoft Store에 표시되는 앱 이름과 내부 패키지 이름은 다를 수 있으므로 전체 목록을 살펴볼 수 있습니다. 일반 설치 프로그램으로 설치되어 패키지 식별 정보가 없는 데스크톱 앱에는 패키지 패밀리 이름 명령을 적용하지 마세요.

3단계: CheckNetIsolation으로 앱 하나에 예외 추가

앱 식별 정보를 확인한 뒤 관리자 PowerShell에서 예외를 추가하세요. 아래 예시는 앞과 같이 계산기를 대상으로 하며, 패키지 패밀리 이름을 변수로 읽어 복사 실수를 줄입니다. 스크립트는 일치하는 패키지가 하나일 때만 진행합니다. 대상이 명확하지 않으면 중단되며 일괄 변경은 하지 않습니다.

관리자 PowerShell · 패키지 하나에 예외 추가

$apps = @(Get-AppxPackage -Name Microsoft.WindowsCalculator)
if ($apps.Count -ne 1) {
    throw "고유한 앱 패키지를 찾을 수 없습니다. 현재 사용자와 앱 이름을 확인하세요."
}
$pfn = $apps[0].PackageFamilyName
CheckNetIsolation.exe LoopbackExempt -a "-n=$pfn"
CheckNetIsolation.exe LoopbackExempt -s

LoopbackExempt는 루프백 예외 관리를 뜻하고, -a는 추가, -n= 뒤에는 패키지 패밀리 이름을 지정합니다. -s는 현재 목록을 표시합니다. 도구는 AppContainer SID로 대상을 지정하는 방법도 지원하지만, 일반적인 문제 해결에서는 시스템에서 바로 조회할 수 있는 패키지 패밀리 이름을 사용하는 편이 식별 혼동을 줄여 줍니다.

추가 명령에서 오류가 보고되지 않았는지 확인하세요. 액세스 거부 메시지가 표시되면 터미널이 실제로 관리자 권한으로 실행 중인지 확인하세요.
-s 출력에서 대상 이름이나 해당 SID를 확인하세요. 명령이 끝났다는 이유만으로 앱의 네트워크 연결이 복구됐다고 판단하지 마세요.
대상 앱을 다시 열고 방금 실패했던 네트워크 작업을 동일하게 수행하세요.
Clash의 연결 화면이나 로그도 확인해 요청이 프록시 엔진에 도달했는지, 어떤 정책 그룹과 최종 출구가 선택됐는지 살펴보세요.

대안: 클라이언트의 UWP 루프백 도구 사용

일부 Windows GUI 클라이언트에는 루프백 예외 도구가 포함되어 있지만, 이는 Clash나 mihomo 설정 파일에 공통으로 적용되는 항목이 아닙니다. 사용 가능 여부와 버튼 이름, 메뉴 위치는 클라이언트와 버전에 따라 다릅니다. 해당 메뉴를 찾을 수 없다면 위의 Windows 명령을 사용하면 되며, YAML에 이른바 UWP 스위치를 추가할 필요는 없습니다.

구버전 Clash for Windows의 설정 경로

지원이 종료된 Clash for Windows에는 ‘General’ → ‘UWP Loopback’ → ‘Launch Helper’ 메뉴가 있었습니다. 해당 클라이언트가 이미 설치되어 있다면 보조 창에서 대상 앱을 선택하고 ‘Save Changes’를 눌러 저장하세요. 권한 안내가 나타나면 시스템 안내에 따라 허용하면 됩니다. 이 경로는 기존 설치를 설명하기 위한 것이며, 구형 클라이언트를 새로 설치하라는 뜻은 아닙니다.

도구 목록에서 대상 앱 이름을 확인하고 이번에 처리할 앱만 선택하세요.
저장한 뒤 대상 앱을 종료했다가 다시 열고 동일한 네트워크 작업을 반복하세요.
관리자 터미널에서 CheckNetIsolation.exe LoopbackExempt -s를 실행해 시스템에 적용된 결과를 확인하세요.
다른 클라이언트에 비슷한 메뉴가 있다면 현재 버전의 화면을 기준으로 사용하세요. ‘서비스 모드’, ‘시스템 프록시’, ‘루프백 예외’는 서로 다른 기능입니다.

GUI 도구와 명령줄은 같은 종류의 시스템 예외 설정을 변경하며 프록시 노드 품질에는 영향을 주지 않습니다. 보조 도구가 열리지 않거나 목록이 비어 있거나 저장에 실패하면 구독을 계속 바꾸기보다 패키지 식별 정보와 관리자 권한을 다시 확인하세요.

예외 추가 후에도 연결되지 않을 때: 요청 경로별 확인

증상	다음 확인 항목
로컬 7890 포트 연결 실패	실제 수신 포트와 프록시 엔진 실행 상태, 해당 포트의 HTTP 지원 여부를 확인하세요.
브라우저는 정상인데 예외 목록에 대상 패키지가 없음	앱 패키지 패밀리 이름과 현재 사용자, 추가 명령의 권한 및 오류 출력을 확인하세요.
예외는 있지만 클라이언트에 해당 요청이 나타나지 않음	앱이 시스템 프록시를 사용하는지, 다른 패키지나 백그라운드 서비스가 연결을 시작하는지 확인하세요.
로그에 요청이 표시되지만 DIRECT로 연결됨	규칙 순서, 대상 도메인과 정책 그룹을 확인하세요. 루프백 예외는 트래픽을 프록시로 강제하지 않습니다.
프록시에 요청이 도달한 뒤 시간 초과 또는 오류가 발생함	로그를 바탕으로 노드, DNS, 대상 사이트와 계정 상태를 확인하세요. 예외를 반복해서 추가하지 마세요.

Microsoft Store와 Xbox 관련 기능은 각각 확인

Store 페이지 로드, 계정 로그인, 앱 다운로드는 서로 다른 구성 요소가 요청을 보낼 수 있습니다. 한 화면이 복구됐다고 모든 백그라운드 전송이 같은 패키지 식별 정보나 프록시 설정을 사용한다고 볼 수는 없습니다. Xbox 관련 구성 요소도 별도 서비스와 UDP 트래픽, 서로 다른 네트워크 요구 사항을 사용할 수 있습니다. 실패한 작업과 시간, 로그를 각각 기록하고, 패키지 하나에 예외를 추가한 것만으로 모든 구성 요소에 적용됐다고 판단하지 마세요.

TUN 모드는 루프백 예외 설정이 아닙니다

mihomo의 TUN 모드는 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 처리하므로 앱이 로컬 HTTP 프록시에 직접 연결하는 방식과 경로가 다릅니다. 앱이 시스템 프록시를 사용하지 않는다면 TUN을 다른 문제 해결 경로로 고려할 수 있지만, 클라이언트 지원과 관련 권한, 올바른 라우팅 및 DNS 설정이 필요합니다. TUN이 모든 AppContainer의 네트워크 제한을 자동으로 해제하는 것은 아니며, 모든 UWP 네트워크 경로에서 작동한다고 보장할 수도 없습니다.

TUN을 테스트할 때는 한 번에 하나의 요소만 바꾸고 시스템 프록시, TUN, 대상 앱 상태를 기록하세요. DNS, 규칙, 노드, 예외 목록을 동시에 변경하면 연결이 복구되더라도 원인을 알 수 없습니다. 관련 개념은 용어 빠른 참조에서, 플랫폼별 설정은 전체 플랫폼 가이드에서 확인하세요.

복구 방법: 이번에 추가한 예외 삭제

루프백 예외는 시스템 설정에 저장되므로 Clash를 종료해도 자동으로 해제되지 않습니다. 테스트가 끝났거나 앱이 다른 네트워크 경로를 사용하게 됐거나 기존 격리 상태로 되돌리고 싶다면 -d로 지정한 패키지를 삭제할 수 있습니다. 아래 예시는 앞서 사용한 계산기에 해당합니다. 실제 복구 시에는 이번 작업에서 대상으로 삼은 패키지를 지정하세요.

관리자 PowerShell · 삭제 후 확인

$apps = @(Get-AppxPackage -Name Microsoft.WindowsCalculator)
if ($apps.Count -ne 1) {
    throw "고유한 앱 패키지를 찾을 수 없습니다. 작업 전에 기록한 패키지 패밀리 이름을 확인하세요."
}
$pfn = $apps[0].PackageFamilyName
CheckNetIsolation.exe LoopbackExempt -d "-n=$pfn"
CheckNetIsolation.exe LoopbackExempt -s

앱을 이미 제거했다면 현재 Get-AppxPackage 결과에 의존하지 말고, 이전에 저장한 패키지 패밀리 이름으로 삭제하세요. GUI 도구를 사용했다면 대상 앱의 선택을 해제해 저장한 뒤 시스템 명령으로 다시 확인하세요.

완료 후 대상 앱을 다시 시작해 삭제가 예상한 변화를 가져왔는지 확인하세요. 작업 전부터 해당 앱의 예외가 있었다면 ‘정리’를 위해 임의로 삭제해서는 안 됩니다. 복구의 목표는 원래 상태로 돌아가는 것입니다. 마지막으로 ‘로컬 포트 연결 가능’, ‘대상 패키지 예외 확인’, ‘로그에서 요청 경로 확인’, ‘앱 작업 성공’ 네 가지 결과를 기록하면 우연한 성공을 문제 해결로 오인하지 않을 수 있습니다.