Windows UWP 앱에서 Clash 프록시가 작동하지 않을 때: 루프백 제한 해제 방법 2가지와 확인 절차

먼저 문제가 UWP 루프백 제한 때문인지 확인하기

대표적인 증상은 다음과 같습니다. Clash는 실행 중이고 브라우저도 정상적으로 접속되며 기존 데스크톱 프로그램도 프록시를 사용할 수 있지만, Microsoft Store, 구버전 메일, 사진, Xbox 및 일부 스토어 설치 앱은 계속 직접 연결되거나 로딩 시간이 초과되고 네트워크를 사용할 수 없다는 메시지가 표시됩니다. 이 경우 프록시 노드나 구독 자체에는 문제가 없을 가능성이 높으며, 차이는 Windows의 AppContainer 앱 네트워크 격리 규칙에서 발생합니다.

대부분의 Clash 그래픽 클라이언트에서 「시스템 프록시」를 켜면 Windows 프록시 서버가 로컬 주소로 설정됩니다. 예를 들어 HTTP 프록시는 127.0.0.1:7890이거나 mixed-port에 해당하는 동일한 포트를 사용합니다. 일반 Win32 프로그램은 이 로컬 수신 주소에 연결할 수 있지만, AppContainer 격리의 적용을 받는 UWP 앱은 기본적으로 로컬 루프백 인터페이스에 자유롭게 접근할 수 없습니다. 따라서 요청이 Clash 코어에 전달되지 않습니다.

네 가지 점검으로 원인 범위 좁히기

Clash 클라이언트에서 현재 구성이 활성화되어 있는지 확인하고 연결 가능한 정책을 선택합니다.
「설정」 또는 「일반」을 열고 「시스템 프록시」가 켜져 있는지 확인합니다.
Windows 「설정」→「네트워크 및 인터넷」→「프록시」에서 프록시 주소가 127.0.0.1이고 포트가 Clash의 현재 수신 포트와 일치하는지 확인합니다.
데스크톱 브라우저와 대상 스토어 앱을 각각 테스트합니다. 브라우저는 정상이고 대상 앱만 실패해야 루프백 격리의 일반적인 증상에 해당합니다.

포트가 항상 7890인 것은 아닙니다. mihomo 코어를 사용하는 클라이언트는 mixed-port: 7890을 사용할 수도 있고, 사용자가 7891, 7897 또는 다른 미사용 포트로 변경했을 수도 있습니다. 진단할 때는 현재 구성과 클라이언트 설정 화면에 표시된 포트를 기준으로 삼아야 합니다.

방법 1: Clash 클라이언트에 내장된 UWP 루프백 도구 사용

일부 Windows 그래픽 클라이언트에는 루프백 예외 관리자가 통합되어 있습니다. 패키지 이름이나 명령줄에 익숙하지 않은 사용자에게 적합한 방법입니다. 이 도구도 실제로는 Windows의 AppContainer 루프백 예외 목록을 수정하며, 클라이언트를 종료해도 시스템에 기록된 규칙은 보통 즉시 사라지지 않습니다.

일반적인 메뉴 위치와 실행 순서

클라이언트마다 메뉴 이름은 조금씩 다릅니다. 기존 Clash for Windows에서는 보통 「General」→「UWP Loopback」→「Launch Helper」에서 찾을 수 있으며, 다른 클라이언트에서는 「설정」→「시스템 설정」→「UWP 루프백」 또는 「네트워크 도구」에 있을 수 있습니다. 다음 순서로 진행하세요.

테스트 중인 UWP 앱을 먼저 종료해 이전 연결과 캐시가 결과에 영향을 주지 않도록 합니다.
Clash 클라이언트를 정상적으로 실행하고 유효한 구성을 불러옵니다.
UWP Loopback 또는 루프백 예외 도구를 엽니다. Windows에서 권한 확인 창이 표시되면 프로그램 출처를 확인한 후 이번 관리 작업을 허용합니다.
앱 목록에서 대상 프로그램을 찾습니다. 예를 들어 Microsoft Store, Xbox 또는 특정 스토어 앱을 선택할 수 있습니다.
대상 프로그램을 선택한 다음 「Save Changes」, 「변경 사항 저장」 또는 같은 기능의 버튼을 누릅니다.
클라이언트로 돌아가 시스템 프록시가 계속 켜져 있는지 확인한 뒤 대상 앱을 다시 실행합니다.

목록에서 대상 앱을 찾을 수 없을 때

먼저 대상 앱을 한 번 이상 실행합니다. 일부 패키지는 등록이 완료된 후에야 목록에 표시됩니다.
앱이 실제로 Microsoft Store에서 설치되었거나 AppX, MSIX 패키지 형식으로 설치되었는지 확인합니다. 일반 Win32 프로그램에는 UWP 루프백 예외가 필요하지 않습니다.
루프백 도구를 다시 시작해 등록된 패키지를 새로 읽도록 합니다.
계속 인식되지 않으면 뒤에서 설명하는 PowerShell 및 CheckNetIsolation 방법을 사용하세요.

일부 최신 앱은 Microsoft Store에서 설치했더라도 내부적으로 일반 데스크톱 프로세스를 실행할 수 있으며, 데스크톱 프로세스와 AppContainer 구성 요소를 함께 포함하는 경우도 있습니다. 따라서 「스토어에서 설치됨」이 곧 루프백 제한 적용을 의미하지는 않습니다. 실제 프로세스와 테스트 결과를 함께 확인해야 합니다.

방법 2: CheckNetIsolation으로 정확하게 예외 추가

CheckNetIsolation.exe는 Windows에 기본 포함된 네트워크 격리 관리 도구로, AppContainer 루프백 예외를 조회하고 추가하거나 삭제할 수 있습니다. 명령에는 대상 앱의 Package Family Name, 줄여서 PFN이 필요합니다. PFN은 시작 메뉴에 표시되는 이름이나 설치 폴더 이름이 아닙니다.

1단계: 앱의 Package Family Name 찾기

시작 버튼을 마우스 오른쪽 버튼으로 클릭하고 「터미널 관리자」 또는 「Windows PowerShell 관리자」를 엽니다. 먼저 앱 이름으로 설치된 패키지를 필터링합니다. 다음 예시는 이름에 Xbox가 포함된 패키지를 찾는 방법입니다.

Get-AppxPackage *Xbox* | Select-Object Name, PackageFamilyName

패키지 이름을 모른다면 현재 사용자의 모든 AppX 패키지를 표시한 다음 터미널에서 대상 이름을 검색할 수 있습니다.

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

출력에는 보통 두 개의 열이 표시됩니다. 복사해야 하는 값은 PackageFamilyName의 전체 값으로, 이름과 게시자 식별자가 결합된 긴 문자열입니다. PackageFullName은 복사하지 마세요. 이 값에는 보통 버전, 아키텍처 및 리소스 태그까지 포함됩니다.

2단계: 루프백 예외 추가

아래 명령의 예시 PFN을 실제 조회 결과로 바꿉니다. -a 매개변수는 추가를 의미하며, -n 뒤에는 패키지 패밀리 이름을 입력합니다.

CheckNetIsolation LoopbackExempt -a -n="대상 앱의 PackageFamilyName"

명령이 성공적으로 실행되면 보통 완료 메시지가 표시됩니다. 이어서 현재 예외 항목을 조회해 대상 패키지가 등록되었는지 확인합니다.

CheckNetIsolation LoopbackExempt -s

목록이 길다면 먼저 결과를 텍스트 파일로 저장한 뒤 패키지 패밀리 이름을 검색할 수 있습니다.

CheckNetIsolation LoopbackExempt -s > "$env:TEMP\loopback-list.txt"
notepad "$env:TEMP\loopback-list.txt"

3단계: 필요할 때 예외 삭제

앱이 더 이상 로컬 프록시에 연결할 필요가 없거나 잘못된 패키지 패밀리 이름을 추가했다면 -d를 사용해 해당 항목을 삭제할 수 있습니다.

CheckNetIsolation LoopbackExempt -d -n="대상 앱의 PackageFamilyName"

삭제한 후 CheckNetIsolation LoopbackExempt -s를 다시 실행해 해당 항목이 목록에서 사라졌는지 확인합니다. 예외 변경에는 보통 Windows 재부팅이 필요하지 않지만, 새 연결을 만들 수 있도록 대상 앱을 완전히 종료한 뒤 다시 열어야 합니다.

요청이 실제로 Clash에 전달되는지 확인하기

앱이 다시 인터넷에 연결된다고 해서 요청이 반드시 현재 프록시를 통과하는 것은 아닙니다. 확인할 때는 앱 동작, Clash 연결 기록 및 시스템 프록시 상태를 함께 살펴 캐시된 콘텐츠를 복구 성공으로 오판하지 않도록 해야 합니다.

확인 1: Clash 연결 기록 확인

클라이언트에서 「연결」, 「Connections」 또는 이에 해당하는 페이지로 이동합니다.
기존 기록을 지우거나 현재 시간을 기억해 둡니다.
대상 UWP 앱을 완전히 종료한 뒤 다시 열고 네트워크 요청을 한 번 발생시킵니다.
앱이 접속한 도메인에 해당하는 새 연결이 표시되는지 확인합니다.
연결에 적용된 규칙, 정책 그룹 및 최종 노드를 확인해 구성대로 처리되었는지 검토합니다.

연결 페이지에 대상 도메인이 표시되면 요청이 Clash 코어에 도달한 것입니다. 연결은 표시되지만 여전히 열리지 않는다면 루프백 예외를 반복해서 추가하지 말고 규칙 적용 결과, DNS 확인 및 노드 연결 상태를 계속 점검해야 합니다.

확인 2: 시스템 프록시 켜기/끄기 비교

대상 앱을 완전히 종료한 상태로 유지하고 Clash 시스템 프록시를 켠 뒤 한 번 테스트한 다음, 시스템 프록시를 끄고 다시 테스트합니다. 켰을 때 연결 기록이 나타나고 껐을 때 사라지며 앱의 네트워크 동작도 함께 달라진다면 연결 관계가 비교적 명확합니다. 테스트가 끝나면 원래 프록시 설정으로 되돌립니다.

확인 3: 로컬 수신 포트 점검

PowerShell에서 Clash가 예상 포트를 수신 중인지 확인합니다. mixed-port가 7890이라고 가정하면 다음 명령을 실행할 수 있습니다.

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

정상적인 결과에서는 포트가 Listen 상태로 표시됩니다. 결과가 없다면 코어가 해당 포트를 수신하지 않거나 클라이언트가 다른 포트를 사용 중인 것입니다. 이 경우 루프백 예외가 올바르게 설정되어도 UWP 앱은 프록시에 연결할 수 없습니다.

예외를 추가했는데도 작동하지 않을 때의 점검 순서

1. 시스템 프록시 포트와 Clash 수신 포트가 다름

가장 흔한 후속 문제입니다. 예를 들어 구성에는 mixed-port: 7897로 되어 있는데 Windows 프록시는 여전히 127.0.0.1:7890을 가리킬 수 있습니다. 클라이언트의 「설정」→「매개변수 설정」에서 혼합 포트를 확인한 다음 Windows 「설정」→「네트워크 및 인터넷」→「프록시」에서 주소와 포트를 대조하세요.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

allow-lan은 로컬 네트워크 장치가 Clash 수신 포트에 연결할 수 있는지를 제어하는 옵션이며, 로컬 UWP 루프백 제한을 해결하는 스위치가 아닙니다. 로컬 앱 문제만 해결하려고 이를 true로 변경할 필요는 대개 없습니다.

2. 대상 앱이 다른 패키지를 사용함

같은 제품에 정식 버전, 테스트 버전, 게임 서비스 구성 요소 및 독립 로그인 구성 요소가 함께 존재할 수 있습니다. 주 프로그램에 예외를 추가해도 실제 요청을 발생시키는 것은 다른 AppX 패키지일 수 있습니다. Get-AppxPackage를 다시 실행해 제품 이름과 관련 패키지를 확인하고 Clash 로그와 함께 하나씩 검증하세요.

3. 앱 프로세스가 완전히 종료되지 않음

창의 닫기 버튼을 눌러도 앱이 백그라운드에 남아 있을 수 있습니다. 「작업 관리자」→「프로세스」에서 해당 작업을 종료하고 5초 후 다시 실행하세요. 필요한 경우 현재 Windows 사용자 세션에서 로그아웃해 AppContainer 네트워크 상태를 다시 구성할 수 있습니다.

4. 규칙이 요청을 직접 연결로 처리함

루프백 수정은 요청이 Clash에 도달하도록 할 뿐 규칙 결과를 바꾸지는 않습니다. 연결 페이지에 DIRECT가 표시되면 도메인 또는 IP가 직접 연결 규칙에 일치한 것입니다. 구성의 도메인 규칙, 규칙 집합 순서 및 최종 일치 항목을 확인하고 루프백 문제와 프록시 규칙 문제를 혼동하지 마세요.

5. DNS 또는 TUN 모드에서 2차 문제가 발생함

TUN 모드를 켜면 일부 클라이언트가 더 많은 시스템 트래픽을 가로채지만, UWP 앱의 실제 동작은 클라이언트 구현, Windows 네트워크 스택 및 현재 구성에 따라 달라집니다. 시스템 프록시 모드가 정상적으로 복구된 후 TUN으로 전환해 비교하세요. 루프백, DNS, TUN 및 규칙을 동시에 변경하면 어떤 변경이 효과가 있었는지 확인하기 어렵습니다.

루프백 예외, 시스템 프록시 및 TUN의 관계

이 세 가지 개념은 서로 다른 계층에 있습니다. 시스템 프록시는 프록시 설정을 지원하는 프로그램에 HTTP 또는 HTTPS 요청을 로컬 포트로 전달하도록 알립니다. 루프백 예외는 격리된 AppContainer가 이 로컬 포트에 접근하도록 허용합니다. TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 IP 트래픽을 가로챕니다.

시스템 프록시: 브라우저와 Windows 프록시 설정을 따르는 앱에 적합하며, 일반적인 대상은 127.0.0.1:7890입니다.
UWP 루프백 예외: AppContainer가 로컬 프록시 수신 주소에 접근하지 못하는 문제를 해결하며, 노드 선택이나 규칙 변경을 담당하지 않습니다.
TUN 모드: 시스템 프록시를 읽지 않는 프로그램이나 더 복잡한 트래픽 가로채기 환경에 적합하며, 보통 드라이버, 서비스 또는 관리자 권한이 필요합니다.

한두 개의 UWP 앱만 켜진 시스템 프록시를 사용하지 못한다면 정확한 루프백 예외를 먼저 추가하는 것이 좋습니다. 변경 범위를 명확하게 유지할 수 있기 때문입니다. 시스템 프록시를 지원하지 않는 프로그램을 대량으로 처리해야 한다면 TUN 모드를 검토하세요. 모드를 전환하기 전 현재 작동하는 구성을 보존하고 mixed-port, DNS 및 규칙 모드를 기록해 두면 쉽게 복원할 수 있습니다.

처리 결과 확인 목록

Clash 코어가 실행 중이며 구성 파일을 불러올 때 오류가 없습니다.
현재 노드를 사용할 수 있고 데스크톱 브라우저가 동일한 구성으로 인터넷에 접속됩니다.
Windows 시스템 프록시 주소와 mixed-port가 완전히 일치합니다.
대상 UWP 앱의 Package Family Name이 루프백 예외에 추가되어 있습니다.
앱을 완전히 종료한 후 다시 실행했으며 이전 연결을 재사용하지 않습니다.
Clash 연결 페이지에서 대상 앱이 발생시킨 도메인 요청을 확인할 수 있습니다.
연결에 적용된 규칙과 정책이 예상과 일치하며 잘못해서 DIRECT로 처리되지 않았습니다.
테스트가 끝난 뒤 실제로 필요한 루프백 예외만 남겨 둡니다.

위 점검을 완료하면 세 가지 문제를 명확히 구분할 수 있습니다. 앱이 로컬 프록시에 연결하지 못하는 경우, 요청은 Clash에 들어왔지만 규칙 선택이 잘못된 경우, 노드 또는 DNS 자체를 사용할 수 없는 경우입니다. 연결 경로를 단계별로 확인하면 노드를 반복해서 바꾸거나 클라이언트를 다시 설치하는 것보다 원인을 쉽게 찾을 수 있습니다.