Windows에 Clash 설치하기: 다운로드부터 시스템 프록시까지 자주 발생하는 문제

설치 전에 클라이언트, 아키텍처, 커널부터 확인하기

Windows에서 “Clash”는 보통 그래픽 클라이언트와 프록시 커널을 함께 가리킵니다. 그래픽 클라이언트는 구성 관리, 트레이 메뉴, 시스템 프록시 전환 및 로그 표시를 담당하고, 실제로 규칙을 해석하고 연결을 수립하는 것은 Clash 커널입니다. 2026년에도 업데이트되는 Windows 클라이언트는 대개 mihomo 커널을 사용합니다. 초기 Clash for Windows의 마지막으로 널리 알려진 버전은 0.20.39이며 유지 보수가 중단되어, 새로운 필드에 의존하는 mihomo 구성 파일을 직접 처리하기에는 적합하지 않습니다.

계속 유지 보수되는 mihomo 클라이언트 우선 선택

대표적인 선택지로 Clash Verge Rev 등 mihomo 기반 데스크톱 클라이언트가 있습니다. 다운로드하기 전에 Windows의 「설정」→「시스템」→「시스템 정보」→「시스템 종류」를 확인한 뒤 알맞은 설치 패키지를 선택하세요. 대부분의 Intel·AMD 컴퓨터는 x64를 사용하고, Snapdragon X 시리즈 같은 ARM 프로세서 탑재 기기는 arm64를 사용합니다. 파일명의 아키텍처가 반드시 일치해야 하며, Windows 10인지 Windows 11인지만 보고 판단해서는 안 됩니다.

설치 패키지 표기	대상 기기	일반적인 경우
`x64` / `amd64`	Intel 또는 AMD 64비트 프로세서	대부분의 Windows 10·Windows 11 컴퓨터
`arm64`	Windows on ARM 기기	Snapdragon X Elite, X Plus 등 플랫폼
`portable`	휴대용 실행 환경	구성 파일이 보통 프로그램 폴더 또는 지정된 데이터 폴더에 저장됨
`setup` / `installer`	표준 설치 방식	시작 메뉴 항목을 만들고 제거 정보를 등록할 수 있음

다운로드 후 보안 프로그램이 차단할 때 대처하기

프록시 클라이언트는 로컬 포트를 열고 시스템 프록시를 변경하며 TUN 서비스를 설치할 수 있어 보안 프로그램의 휴리스틱 규칙에 걸리기 쉽습니다. 차단되었다고 출처가 불분명한 설치 패키지를 계속 바꾸어 받지는 마세요. 먼저 파일명, 버전, 배포 출처를 확인한 다음 「Windows 보안」→「바이러스 및 위협 방지」→「보호 기록」에서 탐지 대상과 처리 시각을 확인하세요.

설치 프로그램이 실행 직후 사라진다면 Windows의 SmartScreen 알림도 확인해야 합니다. 「추가 정보」를 선택하면 게시자와 파일 정보를 볼 수 있습니다. 회사 컴퓨터가 그룹 정책으로 관리되는 경우에는 관리자가 소프트웨어 실행 정책을 확인해야 합니다. 클라이언트 설치가 끝난 뒤에는 프로그램 폴더와 구성 폴더가 보통 별도로 존재하므로, 제거 프로그램이 사용자 구성을 함께 삭제한다고 보장할 수 없습니다.

설치를 완료하고 최초 실행 문제 확인하기

표준 설치 절차

실행 중인 구형 Clash 클라이언트를 종료하여 7890, 7891 또는 9090 포트를 계속 점유하지 않도록 합니다.
프로세서 아키텍처에 맞는 설치 프로그램을 실행하고 설치 마법사의 안내에 따라 설치를 완료합니다.
시작 메뉴에서 클라이언트를 실행한 뒤 트레이 영역에 클라이언트 아이콘이 나타나는지 확인합니다.
「설정」→「시스템 설정」으로 이동하여 앱 데이터 폴더가 정상적으로 열리는지 확인합니다.
「설정」→「Clash 설정」 또는 이에 해당하는 커널 페이지로 이동하여 커널 상태와 버전 정보를 확인합니다.

클라이언트마다 메뉴 이름은 버전에 따라 달라집니다. Clash Verge Rev는 데스크톱 동작을 「설정」→「시스템 설정」에, 포트·커널·실행 모드를 「설정」→「Clash 설정」에 배치하는 경우가 많습니다. 반면 Clash for Windows 0.20.39는 주로 General 페이지에서 포트, 시스템 프록시, 시작 시 실행 옵션을 표시합니다.

두 번 클릭해도 창이 뜨지 않는다고 실행되지 않은 것은 아닙니다

Windows 클라이언트는 기본 창을 닫은 뒤에도 트레이에서 계속 실행되도록 설정할 수 있습니다. 처음 문제를 확인할 때는 여러 프로세스를 반복해서 실행하기보다 작업 표시줄 오른쪽의 숨겨진 아이콘 화살표를 먼저 클릭하세요. 「작업 관리자」→「세부 정보」를 열어 클라이언트 프로세스와 mihomo.exe를 검색할 수도 있습니다. 그래픽 화면은 살아 있지만 커널 프로세스가 반복해서 종료된다면 앱 내 「로그」 페이지를 바로 확인하세요.

로그의 첫 번째 오류가 뒤이어 발생한 연쇄 오류보다 대개 더 중요합니다. 구성 문법 문제는 parse config error, 포트 충돌은 bind: Only one usage of each socket address, 서비스 권한 문제는 Access is denied를 포함하는 경우가 많습니다. 오류 발생 시각을 기록한 뒤 Windows 이벤트 뷰어의 애플리케이션 로그와 대조하면 화면 충돌인지 커널 시작 실패인지 구분할 수 있습니다.

구독을 가져오고 구성이 실제로 실행되는지 확인하기

구독 주소로 가져오기

구독 주소를 복사한 뒤 클라이언트의 「구독」 또는 「구성」 페이지에서 「새로 만들기」→「URL에서 가져오기」를 선택하고 주소를 붙여 넣습니다. 식별하기 쉬운 이름도 설정하세요(예: “서비스 A－주 구성”). 구독 주소에는 보통 접근 자격 증명이 포함되므로 공개 변환 웹페이지, 스크린샷 또는 문의 내용에 붙여 넣지 않는 것이 좋습니다.

가져오기에 성공했다는 것은 클라이언트가 콘텐츠를 내려받았다는 뜻일 뿐, 구성이 활성화되었다는 의미는 아닙니다. 구성 목록에서 해당 구성을 선택하고 커널이 다시 로드될 때까지 기다린 다음 「프록시」 페이지에서 최소 하나의 정책 그룹과 선택 가능한 노드가 표시되는지 확인하세요. 빈 그룹만 보인다면 구독 응답이 로그인 페이지, 오류 메시지 또는 HTML 콘텐츠로 바뀌지 않았는지 먼저 확인합니다.

로컬 YAML 구성에서 최소한 확인할 항목

YAML을 직접 가져올 때 들여쓰기는 공백만 사용해야 합니다. 다음은 포트와 제어 인터페이스를 이해하기 위한 기본 필드 예시이며, 전체 노드 구성은 아닙니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip

mixed-port: 7890은 HTTP와 SOCKS 요청이 하나의 로컬 포트로 들어올 수 있음을 뜻합니다. allow-lan: false는 기본적으로 다른 LAN 기기의 연결을 허용하지 않는다는 의미입니다. external-controller는 제어 인터페이스이며 브라우저에 입력할 프록시 포트가 아닙니다. 9090을 프록시 포트로 잘못 입력하면 연결이 거부되거나 제어 인터페이스 응답이 반환될 수 있습니다.

먼저 노드를 테스트한 뒤 시스템 프록시를 켜기

「프록시」 페이지에서 노드를 하나 선택하고 지연 시간 테스트를 실행하세요. 지연 시간 결과는 테스트 URL에 대한 한 번의 HTTP 왕복을 나타낼 뿐, 노드의 대역폭 안정성을 단독으로 증명하지는 않습니다. 처음에는 정책 그룹에서 노드가 선택되었는지 확인하고, 로그에 아웃바운드 연결이 나타나는지 본 다음 브라우저로 일반 HTTP 및 HTTPS 페이지에 접속하는 순서가 더 정확합니다.

PowerShell에서 로컬 프록시를 명시해 시스템 프록시 설정을 우회하여 테스트할 수도 있습니다.

curl.exe -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204 -I

정상이라면 몇 초 안에 HTTP 상태 줄이 반환됩니다. 명령은 성공하지만 브라우저가 실패한다면 Windows 시스템 프록시나 브라우저 확장 프로그램이 원인일 가능성이 큽니다. 명령도 실패한다면 노드, 규칙, DNS, 로컬 수신 포트를 계속 확인해야 합니다.

시스템 프록시를 켜고 포트 충돌 해결하기

시스템 프록시가 실제로 영향을 주는 프로그램

클라이언트에서 「시스템 프록시」를 켜면 Windows의 프록시 설정은 보통 127.0.0.1:7890을 가리킵니다. 「설정」→「네트워크 및 인터넷」→「프록시」에서 현재 상태를 확인할 수 있습니다. Chrome과 Edge처럼 시스템 프록시를 따르는 앱은 Clash를 통해 연결되지만, 일부 게임·명령줄 도구·백그라운드 서비스와 자체 네트워크 스택을 사용하는 소프트웨어는 이 설정을 무시할 수 있습니다.

시스템 프록시를 켠 뒤에도 웹페이지가 직접 연결된다면 브라우저를 완전히 종료한 후 다시 실행해 보세요. 브라우저에 프록시 확장 프로그램이 설치되어 있다면 PAC, 고정 프록시, Windows 설정이 서로 덮어쓰지 않도록 잠시 비활성화합니다. 명령줄 프로그램도 각자 규칙이 있습니다. 예를 들어 Git은 http.proxy를 읽을 수 있고 일부 시스템 구성 요소는 WinHTTP 설정을 사용하므로 모든 프로그램이 데스크톱 프록시를 자동으로 따른다고 가정해서는 안 됩니다.

7890 포트 점유 여부 확인

여러 프록시 클라이언트를 동시에 실행하는 것은 포트 충돌의 대표적인 원인입니다. 관리자 권한 또는 일반 PowerShell에서 다음 명령을 실행하면 7890을 수신 중인 프로세스를 확인할 수 있습니다.

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

Get-Process -Id 프로세스 번호

Windows 기본 명령을 사용할 수도 있습니다.

netstat -ano | findstr :7890
tasklist /fi "PID eq 프로세스 번호"

해당 포트가 구형 Clash, 다른 프록시 도구 또는 남아 있는 커널에 속한다면 먼저 해당 프로그램을 정상적으로 종료하세요. 두 클라이언트를 동시에 실행해야 한다면 한쪽의 혼합 포트를 7892로 변경하고 시스템 프록시 대상도 함께 수정합니다. YAML만 수정하고 구성을 다시 로드하지 않으면 포트는 즉시 바뀌지 않습니다.

일반적인 포트	용도	중점 확인 사항
`7890`	Mixed 또는 HTTP 프록시	시스템 프록시가 같은 포트를 가리키는지 확인
`7891`	일부 구형 구성의 SOCKS 프록시	앱에서 잘못된 프록시 프로토콜을 선택했는지 확인
`9090`	외부 제어 인터페이스	웹 프록시 포트로 입력하지 않기
`1053`	예시 DNS 수신 포트	로컬 DNS 도구와 충돌하는지 확인

클라이언트를 종료해도 시스템 프록시가 남아 있는 경우

클라이언트가 비정상적으로 종료되면 Windows 프록시 설정이 제때 복원되지 않을 수 있습니다. 먼저 클라이언트를 다시 열고 「시스템 프록시」를 끈 다음 정상적으로 종료하세요. 클라이언트를 더 이상 시작할 수 없다면 「설정」→「네트워크 및 인터넷」→「프록시」로 이동하여 수동 프록시 서버를 끄고 주소와 포트가 여전히 127.0.0.1:7890인지 확인합니다.

TUN 모드 설치, 권한 및 DNS 문제 확인

TUN이 필요한 경우

TUN 모드는 가상 네트워크 인터페이스를 만들어 시스템 프록시를 따르지 않는 앱도 mihomo로 전달합니다. 게임 플랫폼, 일부 명령줄 프로그램, UDP를 사용하는 앱에서 TUN이 필요할 가능성이 높습니다. 일반적인 브라우저 이용이라면 먼저 시스템 프록시를 사용하고, 구독·노드·규칙이 모두 정상임을 확인한 뒤 TUN을 별도로 켜는 편이 문제를 찾기 쉽습니다.

Windows에서 TUN을 활성화하려면 보통 관리자 권한이나 클라이언트가 설치하는 서비스 구성 요소가 필요합니다. Clash Verge Rev를 예로 들면 「설정」→「시스템 설정」에서 서비스 모드를 설치한 다음 「설정」→「Clash 설정」에서 TUN을 활성화할 수 있습니다. 메뉴 위치는 클라이언트 버전에 따라 달라지지만, “서비스 설치 성공”과 “TUN 스위치 켜짐”은 서로 다른 상태입니다.

TUN을 켠 뒤 인터넷이 끊길 때 확인할 네 가지

서비스 상태 확인: 「서비스」 앱을 열고 클라이언트에 해당하는 서비스가 실행 중인지 확인합니다. 서비스가 시작 직후 중지된다면 클라이언트 로그와 Windows 시스템 로그를 확인하세요.
가상 네트워크 어댑터 확인: 「설정」→「네트워크 및 인터넷」→「고급 네트워크 설정」으로 이동하여 TUN 인터페이스가 생성되었고 수동으로 비활성화되지 않았는지 확인합니다.
DNS 확인: 로그에 DNS 조회 시간 초과가 계속 나타난다면 먼저 구성에 지정된 DNS 서버에 연결할 수 있는지 확인하고, 다른 DNS 필터링 소프트웨어가 53 포트를 점유하고 있지 않은지 확인합니다.
라우팅 충돌 확인: 기업용 VPN, 게임 가속기, Hyper-V, WSL 및 다른 가상 네트워크 어댑터가 라우팅을 변경할 수 있습니다. 유사한 소프트웨어를 잠시 종료한 뒤 다시 테스트하면 충돌 원인을 빠르게 판단할 수 있습니다.

mihomo의 TUN 구성에는 stack, auto-route, auto-detect-interface 등의 필드가 포함될 수 있습니다. 일반적인 구성은 mixed 스택과 자동 라우팅을 사용하지만, 실제로 사용할 수 있는 값은 커널 버전에 따라 달라집니다. 오래된 튜토리얼의 TUN 구성 전체를 복사하여 구독에서 제공한 설정을 바로 덮어쓰지 마세요.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns-hijack는 지정한 DNS 요청을 커널이 처리하도록 전달합니다. 그렇다고 모든 DNS 문제가 자동으로 사라지는 것은 아닙니다. 상위 DNS 서버에 연결할 수 없거나, 규칙이 DNS 요청을 잘못된 출구로 보내거나, 로컬 보안 정책이 가상 인터페이스를 차단하면 여전히 DNS 조회가 실패할 수 있습니다.

자동 시작 실패와 업그레이드 후 복구 절차

앱 자동 시작, 커널 시작, 프록시 적용을 구분하기

“자동 시작”에는 적어도 세 단계가 포함됩니다. Windows 로그인 후 그래픽 클라이언트 시작, 클라이언트의 mihomo 커널 실행, 클라이언트의 시스템 프록시 또는 TUN 상태 복원입니다. 트레이 아이콘만 보인다고 프록시가 적용되었다는 뜻은 아닙니다. 마찬가지로 백그라운드 서비스가 실행 중이어도 현재 구성이 성공적으로 로드되었다고 볼 수 없습니다.

먼저 클라이언트의 「설정」→「시스템 설정」에서 시작 시 실행을 켠 다음 「작업 관리자」→「시작 앱」을 열어 해당 항목이 활성화되어 있는지 확인하세요. 일부 버전은 레지스트리 시작 항목을 사용하고, 다른 버전은 작업 스케줄러나 시작 폴더를 사용합니다. 업그레이드로 설치 경로가 바뀌면 기존 시작 항목이 더 이상 존재하지 않는 실행 파일을 가리킬 수 있습니다.

자동 시작 후 프록시가 작동하지 않을 때 확인 순서

Windows에 로그인한 뒤 15~30초 기다리면서 클라이언트가 트레이에 나타나는지 확인합니다.
클라이언트 로그를 열어 커널이 시작을 완료하고 현재 구성을 로드했는지 확인합니다.
구독 구성이 계속 선택되어 있는지, 빈 구성이나 기본 구성으로 되돌아가지 않았는지 확인합니다.
「시스템 프록시」 또는 TUN 스위치가 클라이언트 설정대로 복원되었는지 확인합니다.
Windows 프록시 주소가 현재 포트인지 확인합니다(예: 127.0.0.1:7890).

클라이언트가 네트워크 연결보다 먼저 시작되면 로그인 단계에서 구독 자동 업데이트가 실패할 수 있습니다. 이때 구독 실패를 노드 장애로 오해하지 말고, 네트워크가 안정된 뒤 수동으로 한 번 업데이트하면서 HTTP 상태와 로그 시각을 확인하세요. 노트북이 절전 모드에서 복귀한 뒤 Wi-Fi를 전환한 경우에도 기본 네트워크 어댑터를 다시 검색해야 할 수 있으며, TUN 사용 시 특히 두드러집니다.

클라이언트 업그레이드 시 보존해야 할 항목

업그레이드 전에 현재 클라이언트 버전, 커널 버전, 포트, 실행 모드, 구성 이름을 기록해 두세요. 구독 주소와 로컬 오버라이드 규칙은 별도로 저장하여 클라이언트 내부 데이터베이스에만 의존하지 않는 것이 좋습니다. 업그레이드가 끝나면 먼저 TUN을 끈 상태에서 시스템 프록시로 연결을 한 번 테스트한 뒤 서비스 모드와 TUN을 다시 활성화하세요.

Clash for Windows 0.20.39에서 mihomo 클라이언트로 이전할 때는 기존 데이터 폴더 전체를 그대로 복사하지 않는 것이 좋습니다. 구형 클라이언트의 화면 설정, 데이터베이스, 오버라이드 스크립트는 새 클라이언트에서 인식되지 않을 수 있습니다. 더 안정적인 방법은 구독을 다시 가져온 뒤 규칙, DNS, 포트 설정을 항목별로 옮기는 것입니다.

Windows 최초 설치 후 점검 목록

설치가 끝나면 다음 순서로 전체 점검을 진행할 수 있습니다. 각 단계가 명확한 상태에 대응하므로, 이후 문제가 생겨도 어느 계층에서 발생했는지 빠르게 판단할 수 있습니다.

클라이언트 아키텍처가 시스템과 일치하고 그래픽 인터페이스와 mihomo 커널이 모두 안정적으로 실행됩니다.
구독이 다운로드되어 선택된 상태이며, 프록시 페이지에서 정책 그룹과 노드를 확인할 수 있습니다.
로컬 7890 포트가 수신 대기 중이고 다른 프로그램이 점유하지 않았습니다.
127.0.0.1:7890을 지정한 curl.exe 테스트에서 HTTP 응답을 받을 수 있습니다.
Windows 시스템 프록시의 주소와 포트가 클라이언트의 실제 수신 값과 일치합니다.
규칙 모드에서 서로 다른 사이트에 접속할 때 로그에 해당 규칙과 아웃바운드 정책이 표시됩니다.
TUN이 필요한 경우 서비스, 가상 인터페이스, 자동 라우팅, DNS가 모두 정상적으로 작동합니다.
Windows를 다시 시작한 뒤 클라이언트, 커널, 프록시 적용 상태가 모두 예상대로 복원됩니다.

Windows에서 Clash 설치의 핵심 난관은 설치 프로그램 자체보다 그래픽 클라이언트, mihomo 커널, 구독 구성, 시스템 프록시, TUN 라우팅 사이의 상태 연결에 있습니다. “커널 실행 → 구성 로드 → 로컬 포트 → 지정 프록시 테스트 → 시스템 프록시 → TUN” 순서로 확인하면 여러 스위치를 동시에 바꾸는 것보다 문제를 구체적으로 찾기 쉽습니다.