Windows UWP 앱이 프록시를 사용하지 않을 때: 루프백 예외로 로컬 연결 제한 해결

먼저 확인: 로컬 루프백 제한이 원인인지

브라우저는 정상적으로 접속되는데 특정 Windows 앱에서만 네트워크 오류가 계속 표시된다면, 먼저 구독을 바꾸지 마세요. 시스템 프록시를 사용할 때 Clash 클라이언트는 보통 앱이 127.0.0.1:7890 같은 로컬 프록시 포트에 연결하도록 설정합니다. AppContainer에서 실행되는 일부 UWP 앱은 네트워크 격리 제한 때문에 일반 데스크톱 프로그램처럼 이 로컬 엔드포인트에 직접 접속하지 못할 수 있습니다.

루프백 예외는 ‘앱이 로컬 프록시에 연결할 수 있는지’를 해결합니다. 구독을 불러오거나 작동하지 않는 노드를 고치지는 않으며, 앱 트래픽을 자동으로 프록시로 보내지도 않습니다. 아래 증상에 해당하는지 먼저 확인한 뒤 예외 목록을 수정하세요.

Clash 코어가 실행 중이고, 브라우저에서는 같은 시스템 프록시를 통해 대상 사이트에 접속할 수 있습니다.
시스템 프록시 주소가 127.0.0.1 또는 localhost로 설정되어 있고, 프록시 포트가 클라이언트 설정과 일치합니다.
모든 프로그램의 네트워크가 동시에 끊기는 것이 아니라 AppContainer를 사용하는 특정 앱에서만 문제가 발생합니다.
대상 앱을 다시 열어 요청을 보낸 뒤에도 클라이언트의 ‘연결’ 화면에 해당 요청이 표시되지 않습니다. 이는 문제를 좁히는 단서일 뿐, 단독으로 원인을 확정할 수는 없습니다.

127.0.0.1, 시스템 프록시와 AppContainer 이해하기

127.0.0.1은 현재 컴퓨터를 가리키는 IPv4 루프백 주소입니다. IPv6에 해당하는 주소는 ::1입니다. Clash의 HTTP 또는 혼합 프록시 포트는 루프백 인터페이스에서 수신 대기해 같은 컴퓨터의 앱이 사용할 수 있습니다. ‘시스템 프록시’를 켜면 Windows 프록시 설정을 따르는 앱이 해당 포트에 연결을 시도합니다.

AppContainer는 앱을 격리된 경계 안에서 실행합니다. 기본적으로 일반 UWP 앱은 로컬 루프백 서비스에 자유롭게 접근할 수 없습니다. 프록시 포트가 정상적으로 열려 있어도 네트워크 격리 정책이 앱의 연결을 막을 수 있습니다. 루프백 예외는 지정한 앱 패키지에 이러한 로컬 통신을 허용하는 설정이지, 모든 네트워크 권한을 여는 설정은 아닙니다.

설정	하는 일	대신할 수 없는 기능
시스템 프록시	이 설정을 지원하는 앱에 사용할 프록시 주소와 포트를 알립니다.	AppContainer의 루프백 제한을 해제하지 않습니다.
루프백 예외	지정한 앱 패키지가 로컬 루프백 엔드포인트에 접근하도록 허용합니다.	앱이 시스템 프록시 설정을 읽도록 강제할 수 없습니다.
규칙 모드	코어 규칙에 따라 DIRECT, 프록시 그룹 또는 다른 정책을 선택합니다.	앱과 로컬 포트 사이의 연결 실패를 해결하지 않습니다.
TUN 모드	가상 네트워크 어댑터로 라우팅 조건에 맞는 트래픽을 처리합니다.	시스템 프록시에 자동으로 예외를 추가하는 기능이 아닙니다.

루프백 문제를 해결하려고 수신 주소를 0.0.0.0으로 바꾸거나 ‘LAN 연결 허용’을 섣불리 켜지 마세요. 프록시에 접근할 수 있는 범위만 넓어질 뿐, 앱 샌드박스 제한이 해제되는 것은 아닙니다. 로컬에서만 사용할 경우 루프백 주소로 계속 수신 대기하세요.

프록시 포트와 Windows 설정 확인

두 곳의 포트 확인

클라이언트의 ‘설정’에서 ‘포트’, ‘혼합 포트’ 또는 mixed-port 항목을 찾으세요. 메뉴 이름은 클라이언트마다 다를 수 있으므로 현재 설정된 실제 값을 기준으로 확인합니다.
Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’ → ‘수동 프록시 설정’의 ‘프록시 서버 사용’ 옆에서 ‘편집’을 선택합니다. Windows 10에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’로 이동합니다.
주소와 포트가 일치하는지 확인하세요. 클라이언트의 혼합 포트가 7897인데 시스템 프록시에는 7890이 입력되어 있다면, 먼저 포트를 바로잡은 다음 UWP 문제를 확인하세요.

7890과 7897은 흔히 사용되는 예시일 뿐, 모든 클라이언트의 기본값은 아닙니다. HTTP 시스템 프록시에는 HTTP를 지원하는 수신 포트를 입력하세요. SOCKS만 지원하는 포트를 HTTP 프록시 항목에 입력하면 안 됩니다.

PowerShell로 로컬 포트 수신 확인

아래 예시는 실제 포트가 7890이라고 가정합니다. 클라이언트를 먼저 실행한 뒤 PowerShell에서 다음 명령을 실행하세요.

Test-NetConnection -ComputerName 127.0.0.1 -Port 7890

출력에서 TcpTestSucceeded 값을 확인하세요. True라면 현재 PowerShell 프로세스가 TCP 연결을 설정할 수 있다는 뜻입니다. UWP 앱의 접근이 허용되었거나 원격 노드가 작동한다는 의미는 아닙니다. False라면 먼저 코어 실행 여부, 포트 입력 오류, 로컬 보안 소프트웨어의 수신 차단 여부를 확인하세요.

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

일부 클라이언트는 그래픽 인터페이스에서 루프백 예외를 설정할 수 있습니다. 지원이 종료된 Clash for Windows의 구버전에서는 ‘Settings’ → ‘UWP Loopback’ → ‘Launch Helper’를 선택해 보조 도구를 열 수 있었습니다. 이는 구버전 클라이언트의 참고 경로일 뿐, Clash Verge Rev나 다른 mihomo 클라이언트에 공통으로 적용되는 메뉴는 아닙니다.

문제가 발생한 앱을 먼저 종료해 기존 연결을 계속 재사용하지 않도록 하세요. 백그라운드에서 실행 중인 앱도 완전히 종료한 뒤 테스트해야 합니다.
클라이언트에서 루프백 예외 도구를 여세요. Windows 사용자 계정 컨트롤 알림이 나타나면 도구의 출처를 확인한 후 실행을 허용합니다.
앱 목록에서 대상 항목을 찾으세요. 앱에 표시되는 이름이 스토어 이름과 다를 수 있으므로, 필요하면 패키지 이름으로 확인합니다.
로컬 프록시에 접근해야 하는 앱만 선택한 다음 도구의 ‘Save Changes’ 또는 저장 버튼을 누르세요.
대상 앱을 다시 실행해 새로고침하거나 로그인하고, 동시에 클라이언트의 ‘연결’과 ‘로그’를 확인하세요.

도구 목록에 대상 앱이 없다면 먼저 현재 Windows 사용자 계정에 앱이 설치되어 있는지 확인하세요. 다른 관리자 계정으로 도구를 실행하면 표시되는 앱 목록이 다를 수 있습니다. 계정 차이로 생긴 문제를 구독이나 노드 오류로 오해하지 마세요.

방법 2: CheckNetIsolation으로 예외 추가

현재 예외 목록과 앱 패키지 정보 확인

시작 메뉴에서 ‘Windows PowerShell’을 검색하고 ‘관리자 권한으로 실행’을 선택하세요. 아래 명령은 Windows 10과 Windows 11에서 사용할 수 있습니다. 회사나 학교의 관리 정책으로 설정 변경이 제한될 수 있으므로, 관리 장치에서는 조직의 지침을 먼저 따르세요.

CheckNetIsolation.exe LoopbackExempt -s

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

첫 번째 명령은 기존 예외를 표시하고, 두 번째 명령은 현재 사용자의 앱 패키지를 나열합니다. 추가할 때는 PackageFamilyName을 사용하고 PackageFullName으로 대체하지 마세요. 전체 패키지 이름에는 보통 버전과 아키텍처 정보가 포함되지만, 패키지 패밀리 이름은 같은 계열의 앱 패키지를 식별하는 데 사용됩니다.

설치된 패키지로 추가 방법 확인

패키지 이름이 Microsoft.WindowsCalculator인 Windows 계산기를 예로 들어 값을 조회하고 권한을 추가하는 과정을 살펴봅니다. 계산기에 프록시가 필요하다는 뜻은 아닙니다. 실제 문제 해결 시에는 위 목록에서 대상 앱을 찾고 조회 이름을 해당 앱의 정확한 Name으로 바꾸세요. 스크립트는 패키지가 하나만 조회된 경우에만 진행하므로 값이 비어 있거나 결과가 여러 개일 때 잘못 처리되는 것을 방지합니다.

$packages = @(Get-AppxPackage -Name 'Microsoft.WindowsCalculator')

if ($packages.Count -eq 1) {
    $family = $packages[0].PackageFamilyName
    Write-Output "루프백 예외 추가 준비: $family"
    CheckNetIsolation.exe LoopbackExempt -a "-n=$family"
} else {
    Write-Warning '앱 패키지를 하나로 특정하지 못했습니다. 현재 사용자와 패키지 이름을 확인하세요.'
}

LoopbackExempt -a는 예외 추가를 의미합니다. -n= 뒤에 패키지 패밀리 이름을 입력합니다. 명령을 실행한 뒤 목록을 다시 확인하세요. 터미널에 뚜렷한 오류가 없다는 이유만으로 설정이 성공했다고 판단하면 안 됩니다.

CheckNetIsolation.exe LoopbackExempt -s

목록에 대상 패키지 패밀리가 표시되는지 확인한 다음 앱을 완전히 종료하고 다시 실행하세요. 추가에 실패했다면 터미널의 오류 메시지 전체를 보관하세요. 권한 부족, 앱 패키지 정보 없음, 장치 정책 제한은 각각 해결 방법이 다르므로 프록시 노드를 계속 바꿔도 대개 해결되지 않습니다.

결과 확인: 루프백, 규칙, 노드를 나눠서 점검

예외를 추가한 뒤에는 프록시 포트와 노드를 그대로 둔 상태에서 같은 앱의 같은 작업을 먼저 테스트하세요. 한 번에 하나씩만 바꿔야 어느 단계에서 문제가 해결됐는지 알 수 있습니다. 다음 순서대로 확인하면 됩니다.

예외 목록 확인. CheckNetIsolation.exe LoopbackExempt -s를 실행해 대상 패키지가 목록에 남아 있는지 확인하세요.
요청이 코어에 도달하는지 확인. Clash 클라이언트의 ‘연결’을 열고 앱에서 새로고침을 다시 실행하세요. 연결에 프로세스 이름이 표시되지 않을 수도 있으므로 대상 도메인, 주소, 요청을 보낸 시점을 함께 확인하세요.
적용된 규칙 확인. 요청이 표시되면 DIRECT로 처리되는지 프록시 그룹을 거치는지 확인하세요. 앱에서 여전히 접속할 수 없다면 정책, 노드, DNS, 대상 서비스 상태를 이어서 점검합니다.
로그 오류 확인. 연결 시간 초과, 도메인 확인 실패, 원격 연결 거부를 모두 UWP 루프백 제한 탓으로 돌려서는 안 됩니다.

예외를 추가했는데도 요청이 보이지 않는 이유는?

앱이 Windows 시스템 프록시 설정을 사용하지 않거나, 다른 보조 프로세스가 요청을 보낼 수 있습니다. 해당 앱이 애초에 이 제한의 영향을 받는 UWP 네트워크 경로를 사용하지 않는 경우도 있습니다. 루프백 예외는 이런 상황에 프록시를 자동으로 설정하지 않습니다. 먼저 앱 자체에 프록시 설정이 있는지 확인하고, 그다음 TUN 모드가 필요한지 판단하세요.

TUN 모드로 루프백 예외를 대신할 수 있나요?

mihomo 클라이언트의 TUN 모드는 가상 네트워크 어댑터를 통해 트래픽을 처리하므로 시스템 프록시를 지원하지 않는 일부 앱의 트래픽을 코어로 전달할 수 있습니다. 앱이 직접 소켓 연결을 사용한다면 접속 방식이 달라질 수 있습니다. 그러나 이미 시스템 프록시를 읽고 로컬 포트에 연결하려는 앱은 여전히 루프백 제한을 겪을 수 있습니다. 따라서 ‘TUN 켜기’를 모든 문제에 통하는 해결책으로 봐서는 안 됩니다.

TUN을 테스트하기 전에 클라이언트에서 요구하는 서비스 모드나 관리자 권한이 준비됐는지 확인하고, 기존 설정 상태를 기록해 두세요. 시스템 프록시, TUN, DNS 모드, 규칙을 동시에 바꾸지 마세요. Windows의 다른 VPN, 가상 네트워크 어댑터, 보안 소프트웨어도 라우팅에 영향을 줄 수 있습니다. 방화벽을 바로 끄기보다 항목별로 비교해 확인하세요.

루프백 예외 해제 및 이후 관리

앱이 더 이상 로컬 프록시에 접근할 필요가 없거나 이번에 추가한 예외가 문제 확인용이었다면 해당 예외를 삭제할 수 있습니다. 아래에서는 계산기 패키지를 예로 들지만, 실제로는 앞서 추가한 대상 패키지를 조회해 사용하세요.

$packages = @(Get-AppxPackage -Name 'Microsoft.WindowsCalculator')

if ($packages.Count -eq 1) {
    $family = $packages[0].PackageFamilyName
    CheckNetIsolation.exe LoopbackExempt -d "-n=$family"
} else {
    Write-Warning '앱 패키지를 하나로 특정하지 못했습니다. 해제할 항목을 확인하세요.'
}

CheckNetIsolation.exe LoopbackExempt -s

-d는 지정한 항목만 삭제합니다. 앱 하나의 예외를 해제하려고 목록 전체를 지우면 로컬 서비스에 의존하는 다른 앱에 영향을 줄 수 있습니다. 앱이 이미 제거되어 패키지를 조회할 수 없다면 이전에 저장한 예외 목록으로 패키지 정보를 확인한 뒤 해당 패키지 패밀리만 삭제하세요.

일반적인 버전 업데이트 후에도 패키지 패밀리는 대개 유지되므로 매번 다시 허용할 필요는 없습니다. 앱을 재설치하거나 다른 배포 경로로 바꾼 경우, 또는 Windows 사용자를 변경한 경우에는 다시 확인하세요.
문제가 발생한 앱 이름, 실제 프록시 포트, 예외 추가 전후의 증상, 클라이언트 로그의 오류 유형을 기록해 두면 나중에 문제를 재현하기 쉽습니다.
로그를 다른 사람에게 전달하기 전에 구독 주소, 액세스 토큰 및 기타 계정 정보를 삭제하세요. 루프백 제한을 확인하는 데 구독 링크 전체를 공개할 필요는 없습니다.