설치 전 확인: Windows 버전, 클라이언트 유형, 설정 출처
Windows에서 흔히 사용하는 Clash 클라이언트는 그래픽 인터페이스, Clash 또는 mihomo 코어, 설정 관리자, 시스템 프록시 제어 모듈로 구성됩니다. 그래픽 인터페이스는 구독 가져오기, 노드 전환, 로그 확인을 담당하고, 코어는 로컬 포트 수신, 규칙 매칭, DNS 및 연결 전달을 처리합니다. 설치가 완료되어도 프로그램이 실행되는 것에 불과하며, 실제로 사용하려면 설정 가져오기, 코어 실행, 시스템 프록시 활성화, 연결 상태 확인까지 마쳐야 합니다.
지원이 계속되는 Windows 10 22H2, Windows 11 23H2 또는 Windows 11 24H2 사용을 권장합니다. Windows 7, Windows 8.1 및 이전 Windows 10 버전에서는 최신 WebView2, 런타임, 드라이버 인터페이스 또는 시스템 구성 요소가 없을 수 있습니다. 설치 프로그램이 실행되더라도 코어 시작, 인터페이스 렌더링 또는 TUN 활성화에 실패할 수 있습니다.
설치 파일과 포터블 압축 파일 구분하기
- EXE 설치 파일: 일반적으로 설치 마법사, 시작 메뉴 항목, 제거 정보가 포함되어 장기간 사용하기에 적합합니다.
- MSI 설치 파일: Windows Installer로 관리하기 편하며 대량 배포에도 자주 사용됩니다.
- ZIP 압축 파일: 압축 해제 후 바로 실행할 수 있지만 업데이트할 때 파일을 수동으로 교체해야 합니다. 설정 폴더가 프로그램과 함께 이동하는지는 클라이언트 구현에 따라 다릅니다.
- x64 및 ARM64: 대부분의 Intel 및 AMD PC는 x64를 선택하고, Snapdragon 등 ARM 프로세서가 탑재된 Windows 장치는 ARM64를 우선 선택합니다.
「설정」→「시스템」→「시스템 정보」에서 “시스템 종류”를 확인할 수 있습니다. “x64 기반 프로세서”로 표시되면 x64를, “ARM 기반 프로세서”로 표시되면 ARM64를 선택하세요. Windows 11이라는 제품명만으로 아키텍처를 판단하지 마세요.
Clash 클라이언트 설치 및 Windows 보안 경고 처리
현재 프로세서 아키텍처에 맞는 설치 파일을 다운로드한 뒤, 먼저 실행 중인 이전 버전 클라이언트를 종료하세요. 작업 표시줄 알림 영역에 이전 클라이언트 아이콘이 남아 있다면 메뉴에서 “종료”를 선택한 다음 작업 관리자를 열어 관련 인터페이스 프로세스와 코어 프로세스가 모두 끝났는지 확인합니다. 이전 프로세스가 7890, 7891 또는 9090 포트를 계속 사용하면 새 버전이 시작된 직후 포트 충돌을 보고할 수 있습니다.
표준 설치 순서
- EXE 또는 MSI 설치 파일을 두 번 클릭하고, 설치 마법사에 표시되는 버전과 대상 폴더를 확인합니다.
- 일반적인 개인용 장치는 기본 폴더를 그대로 사용해도 됩니다. 기업 정책으로 관리되는 장치는 관리자가 지정한 폴더에 설치하세요.
- 설치가 끝나면 시작 메뉴에서 클라이언트를 실행합니다. 처음 실행할 때부터 관리자 권한으로 실행할 필요는 없습니다.
- Windows 방화벽에서 네트워크 액세스를 허용할지 묻는 경우, 가정 또는 신뢰할 수 있는 회사 네트워크라면 “개인 네트워크”를 선택할 수 있습니다. 공용 네트워크에서 허용할지는 실제 사용 목적에 따라 결정하세요.
- 인터페이스가 완전히 로드될 때까지 기다린 뒤, 상태 페이지에 “Core failed”, “코어 시작 실패” 또는 계속 재시작된다는 안내가 표시되지 않는지 확인합니다.
Clash는 기본적으로 로컬 루프백 주소에서만 프록시 포트를 수신하면 됩니다. 설정의 allow-lan: false는 LAN 장치에 프록시를 제공하지 않는다는 의미이며, 현재 컴퓨터에서만 사용하는 환경에 적합합니다. 휴대전화나 다른 컴퓨터를 연결해야 한다면 LAN 액세스를 직접 활성화하고 방화벽 인바운드 범위, 인증, 신뢰할 수 있는 네트워크 대역도 함께 설정하세요. 포트를 모든 네트워크 인터페이스에 그대로 노출해서는 안 됩니다.
첫 실행 후 확인할 폴더
클라이언트마다 폴더 이름은 다르지만, 일반적인 데이터 위치는 %APPDATA%, %LOCALAPPDATA% 또는 사용자 폴더 아래의 전용 폴더입니다. Win+R을 누르고 %APPDATA%와 %LOCALAPPDATA%를 각각 입력해 확인할 수 있습니다. 설정 파일, 로그, 코어, 캐시는 대개 설치 폴더에 저장되지 않으므로 인터페이스 프로그램을 제거한 뒤에도 사용자 설정이 남을 수 있습니다.
구독 가져오기 및 Clash 설정 로드 확인
클라이언트를 실행한 뒤 먼저 “설정”, “Profiles” 또는 “구독 관리” 페이지로 이동합니다. 프로젝트마다 메뉴 이름은 조금씩 다르며, 일반적인 경로는 「설정」→「새 구독」 또는 「Profiles」→「Download from URL」입니다. 구독 URL을 주소 입력란에 붙여넣고 식별하기 쉬운 이름을 지정한 다음 다운로드 또는 가져오기를 실행하세요.
구독을 가져온 후 확인할 네 가지
- 업데이트 시간: 페이지에 방금 업데이트가 완료된 시간이 표시되는지 확인하고, 오래된 캐시 시간이 그대로 남아 있지 않은지 확인합니다.
- 설정 상태: 현재 설정이 선택되어 있고 YAML 구문 오류가 없는지 확인합니다.
- 프록시 그룹: “프록시”, “Proxy” 또는 이와 유사한 정책 그룹에 선택 가능한 노드가 있는지 확인합니다.
- 로그: 코어 시작 단계에서 포트 바인딩, DNS 초기화 또는 규칙 로드 오류가 나타나는지 확인합니다.
로컬 시스템 프록시에 사용하는 기본 설정에는 보통 프록시 포트, 프록시 그룹, 규칙이 정의됩니다. 아래 조각은 구조 관계만 보여 주며 완전한 구독을 대신할 수 없습니다:
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxy-groups:
- name: Proxy
type: select
proxies:
- Node-A
- DIRECT
rules:
- GEOIP,CN,DIRECT
- MATCH,Proxymixed-port: 7890은 HTTP와 SOCKS 요청이 하나의 혼합 포트로 들어올 수 있다는 뜻입니다. 일부 이전 설정은 port: 7890과 socks-port: 7891을 각각 사용합니다. 실제 포트는 현재 설정과 클라이언트 상태 페이지를 기준으로 확인해야 하며, 흔히 쓰이는 기본값만 보고 입력해서는 안 됩니다.
YAML 구문 분석에 실패할 때
YAML은 들여쓰기에 민감합니다. 목록 항목 앞의 공백 수를 일관되게 유지해야 하며, Tab 문자가 구문 분석 실패를 일으킬 수도 있습니다. 구독을 서버에서 생성하는 경우 클라이언트에서 원본 파일을 크게 수정하지 마세요. 먼저 구독을 다시 업데이트해 다운로드 중단이나 캐시 이상 여부를 확인합니다. 수동 설정에서는 콜론 뒤 공백, 목록의 하이픈, 따옴표의 짝, 프록시 그룹이 참조하는 노드 이름의 실제 존재 여부를 중점적으로 확인하세요.
노드와 규칙 모드를 선택하고 Windows 시스템 프록시 활성화
설정 로드가 끝나면 “프록시”, “Proxies” 또는 정책 그룹 페이지로 이동합니다. 먼저 주요 프록시 그룹에서 노드를 하나 선택한 다음 지연 시간 테스트를 실행하세요. 지연 시간은 테스트 URL 연결에 걸린 시간이며 지속적인 다운로드 속도를 의미하지 않습니다. 특정 노드가 85ms로 표시되면 테스트 당시 응답이 빨랐다는 뜻일 뿐이고, Timeout은 클라이언트에 설정된 제한 시간 안에 테스트가 완료되지 않았다는 의미입니다.
Rule, Global, Direct의 차이
- Rule: 설정의 rules를 위에서 아래 순서로 매칭하여 직접 연결, 프록시 또는 차단 여부를 결정합니다. 일상적인 사용에 적합한 모드입니다.
- Global: Clash로 들어오는 대부분의 연결을 지정한 전역 정책으로 전달합니다. 규칙이 트래픽을 잘못 분류하는지 일시적으로 확인할 때 유용합니다.
- Direct: Clash로 들어온 연결이 프록시 노드를 거치지 않고 대상에 직접 접속합니다. 비교 테스트에 자주 사용됩니다.
모드를 전환해도 Windows의 프록시 스위치가 자동으로 바뀌지는 않습니다. 노드와 모드를 선택한 후 클라이언트 홈 화면이나 설정 페이지에서 “시스템 프록시”, “System Proxy”를 활성화해야 합니다. 일반적인 메뉴 경로는 「설정」→「시스템 프록시」→“활성화”이며, 일부 클라이언트는 메인 화면 상단에 스위치를 배치합니다.
활성화한 뒤 Windows 11의 「설정」→「네트워크 및 인터넷」→「프록시」에서 확인할 수 있습니다. 클라이언트는 보통 수동 프록시 주소 127.0.0.1과 HTTP 또는 mixed 포트(예: 7890)를 기록합니다. 이 값이 클라이언트에서 관리되는 동안에는 Windows 설정에서 다른 포트로 수동 변경하지 않는 것이 좋습니다. 클라이언트 상태와 시스템의 실제 값이 달라질 수 있습니다.
시스템 프록시가 실제로 적용되었는지 확인
- 클라이언트 로그를 열고 로그 수준을
info로 유지합니다. - 브라우저를 완전히 종료한 뒤 다시 열어 기존 연결이 계속 재사용되지 않도록 합니다.
- 일반 HTTPS 페이지에 접속하고 로그에 해당 도메인과 매칭된 정책이 표시되는지 확인합니다.
- 규칙 모드와 직접 연결 모드를 각각 테스트하여 접속 경로와 페이지 연결 상태를 비교합니다.
- 시스템 프록시를 끈 뒤 다시 테스트하여 결과가 스위치 상태에 따라 실제로 바뀌는지 확인합니다.
브라우저가 접속된다고 해서 모든 Windows 프로그램이 자동으로 프록시를 사용하는 것은 아닙니다. WinINET 또는 시스템 프록시 설정을 따르는 프로그램은 대개 적용되지만, 자체 네트워크 스택을 구현했거나 항상 직접 연결을 사용하거나 환경 변수만 읽거나 특수 프로토콜을 사용하는 프로그램은 시스템 프록시를 우회할 수 있습니다. 이 경우 소프트웨어 자체의 프록시 옵션을 확인하거나, 영향 범위를 충분히 이해한 뒤 TUN 모드를 사용해야 합니다.
포트 충돌, 코어 실행 실패, 로컬 연결 거부
로그에 bind: Only one usage of each socket address, address already in use 또는 “포트가 사용 중”이라는 메시지가 나타나면 다른 프로세스가 같은 주소와 포트를 이미 사용 중이라는 뜻입니다. 흔한 원인으로는 이전 Clash 코어, 다른 프록시 소프트웨어, 개발 및 디버깅 도구, 인터페이스를 종료한 뒤에도 백그라운드에 남은 서비스 프로세스가 있습니다.
명령으로 7890 포트 사용 프로세스 확인
netstat -ano | findstr :7890
tasklist /FI "PID eq 프로세스 번호"첫 번째 명령의 마지막 열에 PID가 표시됩니다. 실제 숫자를 두 번째 명령에 넣으면 해당 프로세스를 확인할 수 있습니다. PowerShell에서도 다음 명령으로 로컬 수신이 설정되었는지 확인할 수 있습니다:
Test-NetConnection 127.0.0.1 -Port 7890
Get-NetTCPConnection -LocalPort 7890 -ErrorAction SilentlyContinueTcpTestSucceeded가 False라면 먼저 설정에서 실제로 수신 중인 포트를 확인하세요. 포트가 정말 7890이라면 코어가 실행되었는지, 설정이 정상적으로 로드되었는지, 보안 소프트웨어가 프로세스를 종료하지 않았는지 확인합니다. 설정 포트와 Windows 프록시 포트를 동시에 바꾼 뒤 바로 반복 테스트하지 마세요. 먼저 7890 또는 7892처럼 사용 가능한 포트 하나를 정한 다음 클라이언트가 시스템 프록시를 다시 기록하도록 해야 합니다.
코어 실행 실패 점검 순서
- 로그의 첫 번째 오류를 확인하고 이후에 반복되는 재시도 메시지만 보지 마세요.
- 클라이언트에 포함된 기본 설정으로 전환하여 문제가 코어에서 발생했는지 구독 파일에서 발생했는지 구분합니다.
- 코어 파일이 이동되지 않았는지, 클라이언트 설정에 지정된 코어 경로가 유효한지 확인합니다.
- 유사한 프록시 프로그램을 종료하여 포트 및 서비스 이름 충돌을 배제합니다.
- Windows를 다시 시작하여 남은 프로세스와 아직 해제되지 않은 드라이버 상태를 정리합니다.
- 그래도 실패하면 필요한 로그를 내보내되, 구독 주소, 노드 자격 증명, 공개 IP 주소는 삭제하세요.
UWP 루프백 제한: 스토어 앱이 프록시에 연결되지 않을 때
일부 Microsoft Store 앱과 AppContainer 격리를 사용하는 프로그램은 기본적으로 로컬 루프백 주소에 액세스할 수 없습니다. 이 경우 브라우저는 127.0.0.1:7890으로 정상 연결되지만 특정 스토어 앱은 계속 오프라인으로 표시될 수 있습니다. 이는 대개 노드 문제가 아니라 UWP 루프백 액세스 제한 때문입니다.
먼저 클라이언트에서 제공하는 루프백 도구 사용
일부 Windows Clash 클라이언트는 「설정」→「UWP 루프백」 또는 「Settings」→「UWP Loopback」에 관리 메뉴를 제공합니다. 목록을 연 뒤 로컬 프록시를 통해 연결해야 하는 앱만 선택하고 설정을 저장한 다음 해당 앱을 완전히 종료했다가 다시 실행하세요. 모든 패키지를 한꺼번에 선택하지 마세요. 시스템 구성 요소와 백그라운드 앱의 트래픽까지 바뀔 수 있습니다.
클라이언트에 그래픽 도구가 없다면 PowerShell에서 앱의 Package Family Name을 조회할 수 있습니다:
Get-AppxPackage | Select-Object Name, PackageFamilyName대상 앱의 패키지 패밀리 이름을 확인한 뒤 관리자 권한 명령 프롬프트에서 루프백 예외를 추가할 수 있습니다:
CheckNetIsolation LoopbackExempt -a -n=실제 PackageFamilyName
CheckNetIsolation LoopbackExempt -s첫 번째 명령은 지정한 앱을 추가하고, 두 번째 명령은 현재 예외 목록을 표시합니다. 앱을 제거 후 다시 설치하면 패키지 식별자가 바뀔 수 있으므로 다시 확인해야 합니다. 앱 자체가 Windows 시스템 프록시를 읽지 않는다면 루프백 예외를 추가해도 연결되지 않을 수 있습니다. 이때는 앱 내부에서 프록시를 설정하거나 더 넓은 범위를 처리하는 네트워크 방식으로 전환해야 합니다.
서비스 모드 실패, 시작 시 실행, 권한 처리
일부 클라이언트는 “서비스 모드”, “Service Mode” 또는 “시스템 서비스”를 제공합니다. 이는 특정 네트워크 기능을 Windows 서비스로 실행하여 TUN, 시스템 프록시 상주 기능 또는 코어 시작이 전면 인터페이스에 의존하지 않도록 합니다. 서비스 모드는 일반적인 시스템 프록시에 필수는 아닙니다. 브라우저와 시스템 프록시를 따르는 소프트웨어만 사용한다면 클라이언트를 실행한 상태에서 시스템 프록시를 켜는 것만으로 충분한 경우가 많습니다.
서비스 설치 실패의 일반적인 원인
- 클라이언트 폴더가 이동했지만 서비스 등록은 이전 경로를 가리키고 있습니다.
- 이전 버전의 서비스가 제거되지 않아 서비스 이름이 충돌합니다.
- 서비스를 설치할 때 Windows 사용자 계정 컨트롤 확인을 완료하지 않았습니다.
- 기업 그룹 정책이 일반 사용자의 시스템 서비스 생성 또는 시작을 제한합니다.
- 보안 정책이 드라이버, 서비스 프로그램 또는 코어 파일의 실행을 차단합니다.
먼저 클라이언트의 「설정」→「서비스 모드」에서 제거를 실행한 뒤 클라이언트를 종료하고 Windows를 다시 시작하세요. 클라이언트를 다시 연 다음 서비스를 설치하고 권한 확인을 완료합니다. 버튼에 계속 실패가 표시되면 services.msc를 열어 이전 서비스와 상태를 확인할 수 있지만, 용도를 확인할 수 없는 서비스 항목을 함부로 삭제하지 마세요.
시작 시 실행은 하나의 진입점만 활성화하는 것이 좋습니다. 클라이언트가 이미 「설정」→「일반」→“시작 시 실행”에서 시작 작업을 만들었다면 바로 가기를 shell:startup에 다시 넣지 마세요. 중복 실행으로 인터페이스 프로세스가 두 개 동시에 시작되어 포트 충돌, 시스템 프록시 반복 전환 또는 트레이 아이콘 중복이 발생할 수 있습니다.
TUN 모드의 적용 범위와 DNS 점검
시스템 프록시는 Windows 프록시 설정을 능동적으로 읽는 프로그램에만 영향을 줍니다. 게임 런처, 명령줄 도구, 일부 메신저, 자체 네트워크 스택을 사용하는 앱은 이를 거치지 않을 수 있습니다. TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 IP 트래픽을 처리하므로 개별 프록시 설정을 지원하지 않는 프로그램에 적합하지만, 설정 복잡도와 권한 요구 사항, 장애 발생 시 영향 범위도 더 커집니다.
TUN 활성화 전에 세 가지 기본 테스트 완료
- 시스템 프록시 모드에서 브라우저가 대상 페이지에 안정적으로 접속됩니다.
- 규칙 모드의 프록시 그룹에서 사용 가능한 노드를 선택했습니다.
- 로그에 DNS 시간 초과, 포트 충돌 또는 설정 구문 오류가 계속 나타나지 않습니다.
기본 테스트를 마친 뒤 「설정」→「네트워크」→「TUN 모드」로 이동하여 관련 스위치를 켭니다. 처음 활성화할 때 관리자 권한이 필요하거나 가상 네트워크 어댑터 및 서비스를 설치해야 할 수 있습니다. 활성화 후에는 로컬 네트워크, 프린터, 회사 VPN, 가상 머신 네트워크, 게임 플랫폼이 정상인지 확인하세요. 여러 가상 네트워크 어댑터, VPN, 트래픽 필터 드라이버 사이에서 라우팅 우선순위 충돌이 발생할 수 있습니다.
로그에서 대상 도메인 연결 시 DNS timeout, no such host 또는 비정상적인 조회 결과가 반복되면 먼저 시스템 DNS와 Clash DNS를 구분해야 합니다. TUN과 시스템 프록시를 끈 상태에서 nslookup example.com을 실행하여 기본 네트워크가 도메인을 조회할 수 있는지 확인한 다음 Clash를 시작하고 코어의 DNS 모듈이 설정된 주소에서 수신 중인지 확인하세요. mihomo 설정은 fake-ip 또는 redir-host 강화 모드를 사용할 수 있으며, 두 방식은 캐시와 앱 호환성이 다릅니다. 기존 규칙을 이해하지 못한 상태에서 바로 서로 바꾸지 마세요.
ipconfig /flushdns
nslookup example.com
route printipconfig /flushdns는 Windows DNS 클라이언트 캐시만 지우며 모든 브라우저 캐시나 Clash 코어 캐시를 삭제하지는 않습니다. route print로 TUN, 기업 VPN, 물리 네트워크 어댑터의 라우팅 우선순위를 확인할 수 있습니다. 점검할 때는 한 번에 하나의 변수만 바꾸세요. 먼저 노드, 다음 규칙 모드, 그다음 DNS를 확인하고 마지막에 TUN과 드라이버를 점검합니다.
설치 후 확인 목록
완전한 Windows Clash 배포가 이루어지려면 프로그램, 설정, 포트, 시스템 프록시, 규칙의 다섯 가지 조건을 모두 충족해야 합니다. 트레이 아이콘이나 지연 시간 숫자만으로 최종 정상 여부를 판단할 수 없습니다.
- 클라이언트 버전과 Windows 아키텍처가 일치하고 인터페이스와 코어가 모두 안정적으로 실행됩니다.
- 구독에 최신 업데이트 시간이 표시되고 현재 설정이 정상적으로 로드됩니다.
- 주요 프록시 그룹에서 노드를 선택했으며 지연 시간 테스트 결과가 명확합니다.
- 로컬 HTTP, SOCKS 또는 mixed 포트가 수신 상태입니다.
- Windows 시스템 프록시 주소와 클라이언트 수신 포트가 일치합니다.
- 페이지에 접속할 때 로그에 도메인, 규칙, 최종 정책이 표시됩니다.
- 시스템 프록시를 끄면 테스트 결과가 예상대로 바뀝니다.
- 프록시가 필요한 UWP 앱에 루프백 예외가 설정되어 있습니다.
- 필요한 경우에만 서비스 모드와 TUN을 활성화합니다.
- 구독 주소, 설정 파일, 로그에 포함된 자격 증명이 안전하게 보관됩니다.
문제가 발생하면 먼저 첫 번째 로그 오류를 확인하고, 다음으로 설정과 포트를 점검한 뒤 Windows 시스템 프록시를 확인하고, 마지막으로 UWP, 서비스 모드, TUN, DNS를 처리하는 순서가 가장 효과적입니다. 계층별로 점검하면 여러 스위치를 동시에 바꾸는 일을 피할 수 있고, 문제가 클라이언트 인터페이스, Clash 코어, Windows 네트워크 설정, 원격 노드 중 어디에서 발생했는지도 쉽게 확인할 수 있습니다.