Windows용 Clash 설치 및 인터넷 연결 문제 해결: 방화벽, UAC, 시스템 프록시

설치 전: 시스템 아키텍처와 클라이언트 종류 확인

Windows용 Clash 클라이언트는 일반적으로 그래픽 인터페이스와 프록시 코어로 구성됩니다. 인터페이스에서는 구독, 프록시 그룹, 시스템 프록시, 서비스 관리를 담당하고, 코어는 로컬 포트에서 연결을 수신해 규칙을 적용하고 연결을 설정합니다. Clash Meta는 이후 mihomo라는 이름으로 발전했으며, mihomo를 사용하는 클라이언트라고 해서 메뉴 구성이 모두 같은 것은 아닙니다. 문제를 해결할 때는 클라이언트 이름과 버전, 코어 버전을 함께 기록하세요. ‘Clash’만 적어 두면 정보가 부족합니다.

이 문서에서는 Windows 11의 설정 경로를 기준으로 설명합니다. Windows 10은 일부 메뉴 이름이 다르지만 로컬 수신, 시스템 프록시, 권한 확인 방법은 같습니다. 먼저 일반 시스템 프록시 연결부터 확인하고, 앱에서 필요한 경우에만 TUN을 켜세요. 네트워크 경로를 여러 개 동시에 바꾸지 않는 것이 좋습니다.

설치 패키지 선택 방법

‘설정’ → ‘시스템’ → ‘정보’를 열고 ‘장치 사양’에서 ‘시스템 종류’를 확인하세요. x64 기반 프로세서를 사용하는 기기는 보통 x64 설치 패키지를 선택합니다. ARM 기반 기기라면 클라이언트에서 제공하는 ARM64 패키지를 우선 선택하세요.
클라이언트 다운로드 페이지에서 플랫폼과 아키텍처를 확인하세요. 설치 프로그램과 별도의 mihomo 코어는 서로 다른 배포 파일이며, 코어 압축 파일에는 구독 관리 인터페이스가 포함되지 않는 경우가 많습니다.
클라이언트의 릴리스 정보를 확인해 Windows 최소 지원 버전, 런타임 의존성, 유지 관리 상태를 살펴보세요. 이전 Clash for Windows 인터페이스 안내를 모든 최신 클라이언트에 그대로 적용하지 마세요.
설치 전에 다른 프록시 클라이언트를 종료하고 현재 프록시 및 VPN 설정을 기록해 두세요. 포터블 버전은 고정된 폴더에 압축을 푸세요. 서비스를 등록한 뒤에는 코어 파일을 임의로 옮기지 마세요.

첫 연결: 설정을 가져와 최소한의 연결 경로 만들기

설치가 끝나면 먼저 유효한 구독이나 로컬 YAML 설정 파일을 가져오세요. 구독 주소에는 인증 정보가 포함될 수 있으므로 공개 그룹이나 스크린샷에 공유하지 마세요. 가져온 뒤 해당 설정이 현재 설정으로 선택되었는지, 프록시 그룹에 선택 가능한 노드가 표시되는지 확인하세요. ‘구독 업데이트 완료’라는 메시지만으로 코어가 설정을 정상적으로 불러왔다고 볼 수는 없습니다.

클라이언트의 구독 또는 설정 화면에서 가져오기를 실행하고 해당 설정을 활성화하세요. 로그에서 YAML 구문 오류, 알 수 없는 필드, 규칙 제공자 다운로드 실패가 있는지 확인하세요.
프록시 화면에서 규칙 모드를 선택한 다음, 실제 규칙에서 참조하는 프록시 그룹의 노드를 선택하세요. 규칙에서 사용하지 않는 그룹을 선택해도 해당 요청의 출구는 바뀌지 않습니다.
코어가 실행 중인지 확인하고 실제 HTTP 또는 혼합 프록시 포트를 기록하세요. 아래에서는 127.0.0.1:7890을 예시로 사용합니다. 모든 클라이언트의 기본 포트가 이 값인 것은 아닙니다.
클라이언트에서 시스템 프록시를 켜고 브라우저로 테스트할 사이트에 접속하세요. 그런 다음 연결 목록에서 규칙, 정책 그룹, 출구를 확인합니다.

설정을 클라이언트가 생성하는 경우에는 클라이언트 설정이나 지원되는 오버라이드 기능을 통해 수신 매개변수를 변경하세요. 구독 캐시 파일을 직접 수정하면 다음 업데이트 때 변경 내용이 덮어써질 수 있습니다. 아래는 mihomo 로컬 수신 설정의 예시일 뿐이며 노드와 분기 규칙은 포함하지 않습니다. 이 설정만으로는 완전한 인터넷 연결 구성이 되지 않습니다.

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

혼합 포트는 HTTP 프록시와 SOCKS 프록시를 모두 지원합니다. 로컬 기기에서만 사용할 경우 루프백 주소로 수신하고 LAN 접근은 꺼 두세요. 브라우저 연결 문제를 해결하려고 모든 네트워크 인터페이스에서 수신하도록 바꾸거나 프록시 포트를 공용 인터넷에 노출하지 마세요.

명시적 프록시로 문제 범위 좁히기

PowerShell에서 다음 명령을 실행하세요. Windows PowerShell에서 같은 이름의 별칭으로 인해 매개변수가 달라지는 일을 피하기 위해 curl.exe를 지정합니다. 예시 주소는 연결 테스트용일 뿐, 모든 사이트의 접속 품질을 나타내지는 않습니다.

Test-NetConnection 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

TcpTestSucceeded : True는 로컬 TCP 연결을 설정할 수 있다는 뜻일 뿐, 원격 노드가 작동한다는 의미는 아닙니다.
명시적 프록시에서는 HTTP 응답을 받는데 브라우저에서 실패한다면 시스템 프록시, 브라우저 확장 프로그램, 앱 자체 설정부터 확인하세요.
127.0.0.1:7890에 연결할 수 없다는 메시지가 표시되면 원격 노드를 바로 바꾸지 말고 먼저 포트와 코어 상태를 확인하세요.
로컬 포트에 연결된 뒤 TLS 오류나 원격 시간 초과가 발생한다면 노드, 규칙, 시스템 시간, 클라이언트 로그를 확인하세요. 일반적인 해결책으로 인증서 검증을 건너뛰지는 마세요.

UAC와 서비스 모드: 필요한 기능에 맞게 권한 부여

일반적인 로컬 프록시 수신에는 보통 관리자 권한이 필요하지 않습니다. 보호된 폴더에 설치하거나 시스템 서비스를 등록하거나 가상 네트워크 어댑터를 설정하고 라우팅을 변경할 때 UAC가 표시될 수 있습니다. UAC는 권한 상승을 확인하는 절차이지 네트워크 연결을 허용하는 절차가 아닙니다. ‘예’를 눌러도 방화벽이 자동으로 설정되거나 노드가 선택되지는 않습니다.

서비스 설치 및 상태 확인

클라이언트 설정에서 서비스 모드 또는 백그라운드 서비스 메뉴를 찾으세요. 메뉴 이름은 클라이언트마다 다르므로 현재 사용 중인 클라이언트의 기능인지 먼저 확인하세요.
서비스 설치를 누른 뒤 UAC 창에 표시된 프로그램 경로와 게시자 정보를 확인하세요. 경로가 이상하거나 출처가 불분명하면 권한 부여를 취소하세요.
Win + R을 누르고 services.msc를 입력하세요. 클라이언트가 실제로 등록한 서비스를 찾아 상태와 실행 파일 경로를 확인합니다. 클라이언트마다 서비스 이름은 다릅니다.
클라이언트로 돌아가 서비스 상태를 확인하세요. TUN을 켤 계획이라면 서비스 설치 완료 메시지만 보지 말고 가상 인터페이스와 코어 로그도 확인하세요.

‘액세스가 거부되었습니다’라는 메시지가 나오면 서비스 설치 작업에서 권한 상승이 제대로 이루어졌는지 확인하세요. ‘서비스 파일을 찾을 수 없음’ 또는 시작 직후 중지되는 문제가 있다면 포터블 폴더를 옮겼는지, 보안 소프트웨어가 파일을 격리했는지, 기존 서비스가 이전 경로를 가리키는지 살펴보세요. 클라이언트의 서비스 관리 메뉴에서 기존 서비스를 제거한 뒤 다시 설치하는 것이 좋습니다. 서비스 이름을 추측해 삭제 명령을 실행하지 마세요.

시스템 프록시: Windows, 브라우저, 명령줄 설정 비교

Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’로 이동하세요. ‘수동 프록시 설정’의 주소와 포트가 클라이언트 설정과 일치하는지 확인합니다. 이 문서의 예시에서는 주소가 127.0.0.1, 포트가 7890이어야 합니다. 클라이언트가 PAC 자동 구성을 사용한다면 수동 프록시를 억지로 추가하지 말고 ‘설정 스크립트 사용’과 스크립트 주소를 확인하세요.

Edge와 Chrome은 보통 시스템 프록시를 따르지만 확장 프로그램, 시작 매개변수, 조직 정책에 따라 동작이 달라질 수 있습니다. Firefox는 ‘설정’ → ‘일반’ → ‘네트워크 설정’에서 프록시 사용 방식을 별도로 지정할 수 있습니다. 특정 브라우저에서만 문제가 발생한다면 코어, DNS, 방화벽을 동시에 바꾸지 말고 해당 브라우저의 프록시 설정부터 확인하세요.

WinHTTP와 환경 변수는 별도로 확인

netsh winhttp show proxy
Get-ChildItem Env: | Where-Object Name -Match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$'

netsh winhttp show proxy는 WinHTTP 설정을 조회합니다. 브라우저가 사용하는 현재 사용자 계정의 시스템 프록시와는 다릅니다. 직접 연결로 표시되더라도 클라이언트의 시스템 프록시 기능이 작동하지 않는다는 뜻은 아닙니다. 일부 개발 도구는 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 환경 변수를 읽고, 자체 설정 파일을 사용하는 도구도 있습니다.

앱이 어떤 프록시 설정을 사용하는지 확인하지 않은 상태에서 현재 사용자 프록시를 WinHTTP에 바로 가져오지 마세요. 백그라운드 서비스는 다른 계정을 사용할 수 있으며, 시스템 전체 설정을 바꾸면 다른 소프트웨어에도 영향을 줍니다. 먼저 문제가 발생한 프로세스를 확인한 다음 해당 앱의 프록시 안내와 실행 계정을 살펴보세요.

클라이언트를 종료한 뒤 브라우저에서 인터넷이 모두 끊김

먼저 남아 있는 프록시 설정을 확인하세요. 코어는 중지됐는데 Windows가 여전히 로컬 프록시 포트를 가리키는 경우가 흔합니다. 클라이언트를 다시 열어 시스템 프록시를 정상적으로 끄거나 Windows 프록시 설정에서 이번에 설정한 수동 프록시 또는 스크립트를 비활성화하세요. 회사에서 설정한 PAC는 함부로 삭제하지 마세요. 연결을 복구한 뒤 직접 연결을 테스트하고 클라이언트를 다시 시작하세요.

포트 충돌: 수신 프로세스를 찾아 설정 충돌 해결

로그의 address already in use는 보통 수신 포트가 충돌했다는 뜻입니다. 원격 노드의 지연과는 관계가 없습니다. 클라이언트를 연달아 재설치하지 말고 먼저 로컬 포트를 조회한 뒤 프로세스 ID를 확인하세요.

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

netstat -ano | findstr ":7890"

첫 번째 명령은 지정한 포트의 TCP 수신 목록만 표시합니다. 두 번째 명령은 다른 연결도 표시할 수 있으므로 로컬 주소 열과 수신 상태를 확인해야 합니다. 프로세스 ID를 확인한 다음 ‘작업 관리자’ → ‘세부 정보’에서 PID로 찾으세요. PID 열이 없다면 열 제목을 마우스 오른쪽 버튼으로 클릭해 해당 열을 선택하면 됩니다.

다른 프록시 클라이언트가 사용 중이라면 알림 영역 메뉴에서 정상적으로 종료하고 자동 시작되는 백그라운드 서비스도 끄세요.
현재 클라이언트의 코어가 중복 실행 중이라면 포터블 버전과 설치 버전을 동시에 실행했는지, 서비스 모드와 수동 코어가 함께 실행되고 있는지 확인하세요.
다른 필수 프로그램이 포트를 사용 중이라면 로컬 프록시 포트를 7891처럼 사용하지 않는 값으로 바꾸고 시스템 프록시와 앱 내부 프록시 설정도 함께 업데이트하세요.

YAML의 포트만 바꾸고 Windows에 이전 값이 남아 있지 않은지 확인하세요. 수신 프로세스가 조회되지 않는데 access denied가 발생한다면 보안 정책이나 시스템 예약 포트가 원인일 수 있습니다. 모두 프로세스 점유 문제라고 단정하지 마세요. 알 수 없는 프로세스를 반복해서 종료하는 대신 오류 원문과 시스템 정책을 함께 확인하세요.

방화벽과 보안 소프트웨어: 차단된 대상 확인

Windows 방화벽 알림은 주로 앱이 네트워크 프로필별 통신 권한을 요청할 때 표시됩니다. 클라이언트 인터페이스, 프록시 코어, 백그라운드 서비스는 서로 다른 실행 파일일 수 있습니다. 그래픽 인터페이스만 허용해도 코어에 대한 규칙이 올바르다는 보장은 없습니다. 반대로 로컬에서만 사용하는 루프백 프록시라면 공용 네트워크에 인바운드 포트를 열 필요도 없습니다.

확인된 기록을 바탕으로 차단 문제 해결

‘Windows 보안’ → ‘바이러스 및 위협 방지’ → ‘보호 기록’을 열고 이벤트 시간, 처리된 파일 경로, 탐지 이름을 확인하세요.
파일 출처와 현재 클라이언트 설치 폴더의 파일인지 확인하세요. 판단하기 어렵다면 기록을 보관하고 클라이언트 유지 관리자나 보안 소프트웨어 업체에 분석을 요청하세요.
Win + R을 누르고 wf.msc를 입력하세요. 고급 보안이 포함된 Windows Defender 방화벽에서 현재 코어 경로를 대상으로 하는 아웃바운드 규칙과 명시적 차단 규칙이 있는지 확인합니다.
권한을 조정해야 한다면 대상 프로그램, 방향, 적용할 네트워크를 제한하세요. 코어 업데이트 후 경로가 바뀌었다면 규칙의 대상 경로도 다시 확인해야 합니다.

명시적 차단 규칙은 허용 규칙보다 우선할 수 있어 허용 규칙을 하나 추가하는 것만으로 해결되지 않을 수 있습니다. 타사 보안 소프트웨어에도 별도의 네트워크 필터링 기능이 있을 수 있으니 해당 프로그램의 이벤트 기록을 확인하세요. 모든 보호 기능을 끄거나 다운로드 폴더 전체를 예외로 지정하거나 모든 포트를 여는 방법을 기본 문제 해결책으로 삼지 마세요.

UWP 루프백: 실제로 제한된 앱만 대상으로 조치

AppContainer에서 실행되는 일부 앱은 일반 데스크톱 프로그램과 같은 방식으로 로컬 루프백 프록시에 연결하지 못할 수 있습니다. 이 경우 브라우저는 정상인데 특정 스토어 앱만 실패할 수 있습니다. Microsoft Store에서 설치한 프로그램이 모두 이 유형에 해당하는 것은 아니며, 모든 앱이 시스템 프록시를 따르는 것도 아닙니다. 먼저 앱 유형과 실패 로그를 확인하세요.

관리자 권한으로 PowerShell을 열고 기존 루프백 예외와 로컬 설치 패키지 정보를 먼저 확인하세요. 아래 예시는 Microsoft Store 패키지를 확인하는 방법입니다. 조회 결과가 없으면 패키지 이름을 임의로 적용하지 마세요.

CheckNetIsolation.exe LoopbackExempt -s
Get-AppxPackage -Name Microsoft.WindowsStore |
  Select-Object Name, PackageFamilyName

해당 패키지가 처리할 대상인지 확인한 다음 변수를 사용해 현재 사용자에게 실제로 설치된 패키지 패밀리 이름을 가져오세요. 패키지 전체 이름이나 설치 폴더를 패키지 패밀리 이름으로 잘못 사용하지 않도록 합니다.

$app = Get-AppxPackage -Name Microsoft.WindowsStore
if ($app) {
    CheckNetIsolation.exe LoopbackExempt -a "-n=$($app.PackageFamilyName)"
}

작업을 마치면 대상 앱을 완전히 종료한 뒤 다시 열고 요청이 클라이언트에 표시되는지 확인하세요. 되돌려야 할 때는 같은 패키지 패밀리 이름을 지정해 제거 작업을 실행합니다.

$app = Get-AppxPackage -Name Microsoft.WindowsStore
if ($app) {
    CheckNetIsolation.exe LoopbackExempt -d "-n=$($app.PackageFamilyName)"
}

루프백 예외는 대상 앱의 로컬 루프백 접근 제한만 변경합니다. 프록시 설정이나 구독을 고치거나 규칙을 바꾸지는 않습니다. 클라이언트에 루프백 관리 도구가 있더라도 필요한 앱만 선택하고 모든 패키지의 제한을 일괄 해제하지 마세요. TUN을 켜면 앱의 트래픽 경로가 달라질 수 있지만, 모든 스토어 앱 문제에 통용되는 해결책은 아닙니다.

TUN과 DNS: 기본 연결 확인 후 트래픽 처리 범위 확장

명시적 프록시와 브라우저 시스템 프록시가 모두 정상인데 게임, 명령줄 도구, 프록시 설정을 지원하지 않는 앱이 계속 직접 연결된다면 TUN 사용을 검토하세요. mihomo의 TUN 처리 범위는 가상 인터페이스, 라우팅, 제외 설정, DNS 설정의 영향을 모두 받습니다. 스위치를 켠다고 모든 트래픽이 처리되는 것은 아닙니다.

TUN을 켜기 전에 클라이언트에서 요구하는 서비스와 권한이 준비됐는지 확인하세요. 로그에서 가상 인터페이스 생성 및 라우팅 오류를 살펴보세요.
기업용 VPN, 다른 가상 네트워크 어댑터, 프록시 도구가 함께 실행 중인지 확인하세요. 자동 라우팅이 여러 개면 기본 경로를 두고 충돌할 수 있으므로 한 번에 한 가지 변경 사항만 테스트하세요.
연결 목록에서 대상 앱이 표시되는지, 어떤 규칙과 출구가 적용되는지 확인하세요. 앱의 연결 기록이 없다면 프록시 그룹을 바꾸기보다 트래픽 처리 경로부터 확인하세요.
도메인 연결은 실패하지만 IP 주소로는 접속할 수 있다면 DNS를 확인하세요. Resolve-DnsName example.com으로 시스템 DNS 조회를 살펴볼 수 있지만, 이 결과만으로 코어 내부 DNS도 정상이라고 판단할 수는 없습니다.

모든 설정에 공용 DNS 주소를 입력하는 방식으로 일괄 해결하려 하지 마세요. 시스템 DNS, 코어 DNS, 프록시 노드의 도메인 조회, 브라우저 보안 DNS는 서로 다른 경로를 사용할 수 있습니다. 변경 전에 기존 값을 기록하고 한 번에 하나씩 조정한 뒤 코어 로그에서 DNS 시간 초과나 상위 DNS 서버 연결 실패가 발생하는지 확인하세요. TUN 및 라우팅 설정은 전 플랫폼 설치 가이드에서 해당 플랫폼의 설정 범위를 함께 확인할 수 있습니다.

증상에 따라 문제 해결 순서 좁히기

Windows용 Clash 자주 발생하는 문제와 우선 확인 항목
문제 증상	우선 확인	다음 단계
클라이언트는 시작되지만 프록시 포트에서 수신하지 않음	코어 상태와 설정 파싱 로그	설정 오류를 수정하고 실제 포트 확인
명시적 프록시는 되지만 브라우저는 실패	시스템 프록시, PAC, 브라우저 확장 프로그램	브라우저가 사용하는 프록시 경로 통일
포트가 이미 사용 중이라는 오류	수신 PID와 중복 실행된 코어	충돌 프로그램 종료 또는 포트 설정 함께 변경
서비스 설치 실패 또는 시작 직후 중지	UAC, 서비스 경로, 격리 기록	경로를 수정한 뒤 서비스 재설치
특정 스토어 앱에서만 실패	AppContainer 제한과 앱의 프록시 동작	필요한 패키지 하나의 루프백 예외 확인
TUN을 켠 뒤 기존 네트워크에 문제 발생	가상 인터페이스, 라우팅, DNS, VPN 충돌	TUN을 끄고 기본 상태를 복구한 뒤 하나씩 확인
클라이언트 종료 후에도 인터넷에 연결되지 않음	시스템 프록시 또는 스크립트가 남아 있는지 확인	기존 프록시 설정을 복구한 뒤 직접 연결 테스트

문제 해결 기록에는 Windows 버전과 아키텍처, 클라이언트 및 코어 버전, 발생 시각, 수신 포트, 명시적 프록시 테스트 결과, 전후 시각의 오류 로그를 포함하세요. 공유하기 전에 구독 주소, 인증 토큰, 노드 비밀번호, 개인 도메인 정보를 삭제하세요. 매번 한 가지 조건만 바꿔야 권한, 수신, 규칙, 네트워크 출구 문제를 구분해 찾을 수 있습니다.