Windows UWP 앱이 프록시에 연결되지 않을 때: 루프백 제한 해제 및 확인 방법

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

“스토어가 열리지 않는다”는 이유만으로 곧바로 루프백 예외를 수정하지 마세요. Microsoft Store, 메일, 일부 미디어 앱과 기타 스토어 앱의 연결 실패는 시스템 프록시가 꺼져 있거나 Clash 코어가 실행되지 않은 경우, 잘못된 규칙, DNS 오류, 계정 서비스 장애 또는 Windows 서비스 상태 이상 때문에 발생할 수도 있습니다. 루프백 제한은 특정 현상만 설명합니다. 앱이 로컬 프록시를 통해 연결해야 하지만 AppContainer가 해당 로컬 수신 주소에 대한 접근을 차단하는 경우입니다.

가장 대표적인 증상 조합은 다음과 같습니다. 일반 데스크톱 브라우저는 Clash를 통해 정상적으로 접속하고, Clash의 시스템 프록시가 켜져 있으며, 대상 UWP 앱은 인터넷 연결 없음, 로딩 지속 또는 연결 실패를 표시합니다. 시스템 프록시를 끄면 앱이 직접 연결로 복구될 수도 있지만 네트워크 환경에 따라 계속 실패할 수도 있습니다. 이때는 현재 모드, 프록시 포트와 앱 이름을 먼저 기록한 뒤 대상에 맞게 조치하세요.

다음 순서로 기본 상태를 확인하세요

1. Clash 클라이언트에서 코어가 실행 중인지 확인하세요. 화면 프로세스만 열려 있는 상태와 구분해야 합니다.
2. 일반 데스크톱 브라우저로 접속 가능한 사이트를 열어 시스템 프록시 경로가 적어도 Win32 앱에서는 작동하는지 확인하세요.
3. Clash 연결 기록에서 대상 도메인을 검색하고 UWP 앱을 실행할 때 새 연결이 생성되는지 확인하세요.
4. 클라이언트 설정에서 HTTP 포트 또는 혼합 포트를 기록하고 시스템 프록시가 실제로 같은 포트를 가리키는지 확인하세요.
5. 대상 앱을 완전히 종료한 뒤 다시 열어 백그라운드 프로세스가 변경 전 연결을 계속 사용하는 일을 방지하세요.

대상 앱을 실행했을 때 Clash 연결 목록에 관련 요청이 전혀 나타나지 않는데 브라우저 요청은 정상적으로 표시된다면 루프백 제한을 우선 확인해야 합니다. 반대로 요청이 이미 Clash에 들어왔고 규칙 적용, DNS 오류 또는 노드 연결 실패가 명확히 표시된다면 트래픽은 AppContainer를 통과해 로컬 프록시에 도달한 것입니다. 이 경우 문제는 규칙, DNS 또는 상위 노드로 범위를 좁혀야 합니다.

시스템 프록시는 정상인데 UWP 앱이 계속 실패하는 이유

Clash 또는 mihomo가 Windows에서 실행되면 일반적으로 로컬 포트를 수신 대기합니다. 예를 들어 혼합 포트가 127.0.0.1:7890에서 HTTP와 SOCKS 프로토콜을 동시에 받을 수 있으며, 일부 클라이언트는 HTTP와 SOCKS 포트를 별도로 설정합니다. 시스템 프록시를 켜면 Windows는 현재 사용자 네트워크 설정에 프록시 주소를 기록하고, 이 설정을 사용하는 앱은 이후 요청을 로컬 Clash 포트로 보냅니다.

일반 데스크톱 프로그램에서 127.0.0.1에 접근하는 것은 표준적인 로컬 통신입니다. 반면 UWP 앱과 일부 패키지 앱은 AppContainer 샌드박스에서 실행될 수 있습니다. AppContainer는 격리된 앱이 같은 장치의 다른 서비스에 임의로 연결하지 못하도록 네트워크 기능과 로컬 루프백 접근에 제한을 둡니다. 그 결과 앱이 시스템 프록시 주소를 읽더라도 해당 주소에 연결하지 못하며, 네트워크 요청이 Clash 코어에 도달하기 전에 실패합니다.

루프백 예외는 앱 자체를 “강제 프록시”로 바꾸는 기능이 아닙니다. 지정한 AppContainer가 로컬 루프백 인터페이스에 접근하도록 허용할 뿐입니다. 앱이 시스템 프록시를 읽는지, 프록시를 우회하는지, UDP 또는 QUIC를 사용하는지는 앱 구현과 Windows 네트워크 스택에 따라 달라집니다. 따라서 예외를 추가한 뒤에도 연결 기록으로 트래픽 경로를 확인해야 하며, 앱 화면이 잠시 정상으로 돌아온 것만으로는 충분하지 않습니다.

대상 앱의 루프백 제한 해제

일부 Clash Windows 클라이언트는 “UWP 루프백”, “Loopback” 또는 “루프백 제한 해제” 메뉴를 제공합니다. 이 메뉴는 일반적으로 Windows의 루프백 예외 기능을 호출하고 설치된 AppContainer 앱 목록을 표시합니다. 로컬 프록시를 통해 인터넷에 연결해야 하는 앱만 선택하세요. 예를 들어 문제가 발생한 Microsoft Store 또는 특정 스토어 앱을 대상으로 하며, 범위를 확인하지 않은 상태에서 모든 항목을 한꺼번에 선택하는 것은 권장하지 않습니다.

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

1. Clash 클라이언트를 정상적으로 실행하고 코어가 설정을 성공적으로 로드했는지 확인하세요.
2. 설정, 일반 설정 또는 서비스 도구 영역을 열고 UWP, Loopback 또는 “루프백”이 포함된 메뉴를 찾으세요.
3. 앱 목록에서 대상 프로그램을 찾으세요. 목록에는 앱 이름, 패키지 이름 또는 패키지 제품군 이름이 표시될 수 있으므로 이름이 비슷한 항목과 혼동하지 않도록 주의하세요.
4. 대상 프로그램을 선택하고 저장하면 Windows가 해당 패키지에 루프백 예외를 추가합니다.
5. 대상 앱의 모든 창을 닫고 작업 관리자에서 백그라운드 프로세스가 종료되었는지 확인한 다음 앱을 다시 시작하세요.

클라이언트마다 메뉴 위치가 다르고, 최신 클라이언트 중에는 그래픽 루프백 도구를 통합하지 않은 제품도 있습니다. 메뉴가 없다고 해서 mihomo 코어에 프록시 기능이 없는 것은 아닙니다. 루프백 제한은 Clash 규칙 엔진의 옵션이 아니라 Windows AppContainer 정책에 해당합니다. 이 경우 Windows 기본 명령으로 확인하고 수정할 수 있습니다.

방법 2: PowerShell로 패키지 제품군 이름 찾기

먼저 PowerShell을 열고 앱 표시 이름이나 패키지 이름으로 해당 PackageFamilyName을 찾으세요. 다음 명령은 현재 사용자에게 설치된 앱 패키지와 패키지 제품군 이름을 표시합니다.

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

목록이 길다면 키워드로 필터링할 수 있습니다. 예를 들어 이름에 Store가 포함된 앱을 찾으려면 다음 명령을 사용하세요.

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

정확한 패키지 제품군 이름을 찾았다면 터미널에서 루프백 예외 추가 명령을 실행하세요. 예시 값을 조회한 실제 PackageFamilyName으로 바꿔야 합니다.

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

명령에서 -a는 추가를 의미하며, -n 뒤에는 시작 메뉴에 표시되는 이름이나 설치 폴더 이름이 아닌 패키지 제품군 이름을 입력해야 합니다. 이름이 틀리면 명령이 실패하거나 의도하지 않은 패키지가 수정될 수 있습니다. 실행하기 전에 PowerShell 출력에서 전체 값을 복사하세요.

기존 예외 확인 및 취소

현재 루프백 예외 목록을 확인하려면 다음 명령을 실행하세요.

CheckNetIsolation.exe LoopbackExempt -s

테스트가 끝난 뒤 특정 예외가 더 이상 필요하지 않다면 삭제 명령으로 앱을 기본 제한 상태로 되돌릴 수 있습니다.

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

로컬 포트부터 규칙 적용까지 단계별 확인

예외 추가는 권한만 변경하므로 확인 과정에서 각 계층을 순서대로 점검해야 합니다. 규칙 모드에서는 연결 기록에 도메인, 대상 주소, 적용 규칙과 정책 그룹이 표시되므로 요청이 예상대로 분기되는지 판단하기에 글로벌 모드보다 적합합니다. 따라서 Clash는 일시적으로 규칙 모드로 유지하는 것이 좋습니다.

1단계: 수신 포트 확인

Clash 클라이언트에서 현재 혼합 포트 또는 HTTP 포트를 확인한 다음 Windows 시스템 프록시를 점검하세요. 두 포트는 반드시 같아야 합니다. 예를 들어 클라이언트가 127.0.0.1:7890에서 수신 대기하는데 시스템 프록시에 127.0.0.1:7897이 남아 있다면 시스템 프록시를 읽는 모든 앱이 잘못된 주소로 연결합니다. 여러 Clash 클라이언트를 바꿔 사용한 경우 이런 포트 잔류가 특히 흔합니다.

설정의 수신 주소가 특정 인터페이스에서만 사용할 수 있는 값으로 변경되지 않았는지도 확인하세요. 로컬 앱만 사용할 경우에는 일반적으로 루프백 주소에서 수신 대기하면 충분합니다. LAN 공유에는 allow-lan, 수신 주소와 방화벽 설정이 별도로 필요하므로 단일 PC의 UWP 앱 문제를 해결하려고 LAN 접근을 바로 개방해서는 안 됩니다.

2단계: 대상 앱 다시 시작

많은 UWP 앱은 창을 닫은 뒤에도 백그라운드 작업을 유지합니다. 루프백 예외를 변경한 후에는 작업 관리자에서 해당 프로세스를 종료하거나 현재 Windows 사용자 계정에서 로그아웃한 뒤 다시 로그인하세요. 앱이 이전 연결을 계속 재사용하면 “설정은 추가했지만 적용되지 않았다”는 오판이 생길 수 있습니다.

3단계: Clash 연결 및 로그 확인

앱을 다시 열고 페이지 새로 고침, 업데이트 확인 또는 계정 정보 로드처럼 명확한 네트워크 작업을 한 번 실행하세요. 그런 다음 Clash 연결 목록을 확인합니다.

• 대상 도메인이 나타나고 데이터 전송이 완료되면 루프백, 로컬 포트와 프록시 진입점이 모두 연결된 것입니다.
• 도메인은 나타나지만 규칙이 잘못 적용된다면 규칙 순서, 규칙 세트 참조 또는 정책 그룹 선택을 조정하세요.
• 연결은 표시되지만 노드 핸드셰이크가 실패한다면 정책 그룹의 다른 사용 가능한 노드를 테스트하세요.
• 요청이 전혀 없다면 앱이 시스템 프록시를 사용하는지, 예외 대상이 올바른지, 앱이 해당 프록시 진입점에서 처리하지 않는 프로토콜을 사용하는지 계속 확인해야 합니다.

4단계: 설정 켜기/끄기 비교 테스트

다른 조건은 그대로 둔 채 “시스템 프록시 켜기”와 “시스템 프록시 끄기”를 각각 테스트하세요. 켰을 때 앱이 실패하고 끄면 직접 연결이 정상이며 Clash에 해당 앱 요청이 계속 나타나지 않는다면 로컬 프록시 진입점 또는 루프백 권한 문제일 가능성이 큽니다. 두 상태 모두 실패한다면 예외 추가를 반복하지 말고 앱 서비스, Windows 네트워크, 계정 상태와 DNS를 확인하세요.

루프백 해제 후에도 연결되지 않을 때의 점검 순서

대상 앱이 이미 예외 목록에 있는데도 인터넷에 정상적으로 연결되지 않는다면 프록시 진입점부터 다음 계층으로 점검하세요. 다음 문제는 루프백 제한과 증상이 비슷하지만 처리 방법이 다릅니다.

시스템 프록시 주소 또는 포트 잔류

Windows 시스템 프록시에 이전 클라이언트의 포트가 남아 있을 수 있습니다. 특히 클라이언트가 비정상적으로 종료되었거나 포터블 버전과 설치 버전을 바꿔 사용했거나 여러 프록시 도구를 번갈아 사용한 뒤에 자주 발생합니다. 먼저 다른 프록시 소프트웨어를 종료한 다음 현재 Clash 클라이언트에서 시스템 프록시를 다시 설정하세요. 클라이언트 버튼 상태만 보지 말고 Windows에 실제로 저장된 프록시 주소를 확인해야 합니다.

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

모든 앱이 현재 사용자의 시스템 프록시 설정을 따르는 것은 아닙니다. 일부 프로그램은 자체 네트워크 스택을 구현하고, 일부 연결은 UDP 또는 QUIC를 사용하며, 일부 백그라운드 구성 요소는 다른 서비스 프로세스에서 요청을 보냅니다. 이 경우 루프백 예외가 올바르더라도 HTTP 시스템 프록시가 모든 트래픽을 가로채지 못할 수 있습니다. mihomo의 TUN 모드를 테스트할 수 있지만, 사용 전에 클라이언트에 필요한 권한이 있는지, 가상 네트워크 어댑터 구성 요소를 사용할 수 있는지, DNS 가로채기와 라우팅 변경 사항을 이해하고 있는지 확인하세요.

TUN 모드는 네트워크 계층에서 트래픽을 가로채며, 앱이 127.0.0.1 시스템 프록시에 직접 연결하도록 하는 방식과는 다릅니다. 시스템 프록시를 읽지 않는 앱에 유용하지만 모든 UWP 문제의 해결을 보장하지는 않습니다. TUN을 켠 뒤에도 요청이 나타나지 않는다면 라우팅 제외 설정, 인터페이스 충돌, 보안 소프트웨어 정책과 앱 자체 서비스 상태를 확인하세요.

규칙이 필요한 요청을 잘못된 정책으로 보냄

Microsoft Store와 같은 앱은 콘텐츠 전송, 계정, 인증서와 업데이트 서비스에 동시에 접근할 수 있습니다. 기본 도메인 하나가 성공했다고 해서 모든 의존 요청이 정상이라는 뜻은 아닙니다. 연결 기록에서 실패하거나 반복 재시도하는 도메인을 확인하고 규칙이 위에서 아래로 어떤 순서로 매칭되는지 점검하세요. Clash는 규칙 하나가 적용되면 뒤의 규칙을 계속 확인하지 않으므로, 앞에 있는 지나치게 포괄적인 규칙이 뒤의 정밀한 규칙을 덮어쓸 수 있습니다.

점검 중에는 이미 정상 작동이 확인된 정책 그룹으로 임시 전환해 비교할 수 있지만, 규칙 문제를 가리기 위해 글로벌 프록시를 장기간 사용하는 것은 권장하지 않습니다. 구체적인 도메인과 실패 원인을 확인한 뒤 수정 사항을 규칙 설정에 반영하고 최종 기본 규칙도 유지하세요.

DNS 확인과 프록시 연결은 서로 다른 단계입니다

로그에 도메인 확인 실패, 비정상 주소 반환 또는 지속적인 시간 초과가 표시된다면 현재 설정의 dns 섹션, DNS 서버 연결 가능 여부와 Clash DNS 수신 상태를 확인하세요. fake-ip를 사용하는 경우 가상 주소 또는 특정 도메인에 대한 앱 호환성 요구 사항도 확인해야 합니다. UWP 앱에서 증상이 발생했다는 이유로 DNS 계층 점검을 건너뛰지 마세요.

포트 충돌 및 코어 로드 실패

클라이언트 화면이 열린다고 해서 프록시 포트가 수신 대기 중이라는 뜻은 아닙니다. 설정 구문 오류, 포트 사용 중 또는 코어 시작 실패가 발생하면 시스템 프록시는 서비스가 없는 주소를 계속 가리킬 수 있습니다. 클라이언트 로그에서 설정 로드 결과와 수신 오류를 확인하고, 필요하면 사용되지 않는 포트로 변경한 뒤 시스템 프록시도 함께 업데이트하세요.

기업 정책 또는 관리되는 장치의 제한

회사나 학교에서 사용하는 장치, 중앙 관리 정책이 적용된 Windows 환경에서는 그룹 정책, 방화벽 또는 엔드포인트 보안이 AppContainer, 로컬 프록시와 네트워크 인터페이스를 제한할 수 있습니다. 명령이 성공적으로 반환되더라도 정책이 나중에 설정을 덮어쓸 수 있습니다. 이러한 환경에서는 먼저 장치 관리 요구 사항을 확인하고 중앙에서 제어하는 설정을 계속 변경하지 마세요.

복구 테스트 체크리스트

변경을 완료한 뒤 다음 체크리스트로 최종 확인을 진행하세요. 각 항목이 명확한 계층에 대응하므로 나중에 재현하거나 되돌리기 쉽습니다.

• Clash 또는 mihomo 코어가 정상적으로 시작되었고 현재 설정에 구문 분석 오류가 없습니다.
• 로컬 HTTP 또는 혼합 포트가 수신 대기 중이며 다른 프로그램이 해당 포트를 사용하지 않습니다.
• Windows 시스템 프록시 주소가 현재 클라이언트 포트와 일치합니다.
• 대상 UWP 앱의 패키지 제품군 이름이 루프백 예외 목록에 추가되었습니다.
• 변경 후 대상 앱을 완전히 종료하고 다시 시작했습니다.
• Clash 연결 기록에서 앱이 생성한 도메인 또는 대상 주소를 확인할 수 있습니다.
• 요청이 예상한 규칙과 정책 그룹에 적용되었고 상위 노드가 정상적으로 연결됩니다.
• DNS 조회가 지속적으로 시간 초과되지 않으며 확인 결과가 현재 설정 모드와 일치합니다.
• 테스트가 끝나면 더 이상 필요하지 않은 임시 변경을 취소하고 최종적으로 유효한 설정을 기록하세요.

수정 성공 여부는 단순히 “페이지가 열리는가”만으로 판단하지 말고, 대상 요청이 안정적으로 Clash에 들어와 예상한 규칙에 적용되고 전송을 완료하는지로 확인해야 합니다. 이런 계층별 검증을 통해 AppContainer 권한, 로컬 프록시 포트, 규칙, DNS와 노드 문제를 구분하고 같은 설정을 반복해서 조작하는 일을 피할 수 있습니다.