설치 전: Windows 클라이언트, 코어, 구독 구분하기
Windows에서 Clash를 사용하려면 세 가지 구성 요소를 알아야 합니다. 클라이언트는 화면과 설정 관리, 시스템 연동을 담당하고, 코어는 프록시 프로토콜과 규칙 매칭, 연결 처리를 맡습니다. 구독에는 노드와 정책 그룹, 규칙 등이 포함될 수 있습니다. 설치에 성공해 클라이언트가 실행되더라도 사용할 수 있는 노드가 있거나 시스템 트래픽이 프록시를 통과한다는 뜻은 아닙니다.
Clash Meta는 이후 mihomo라는 이름으로 개발이 이어지고 있습니다. mihomo를 사용하는 클라이언트는 구형 Clash 클라이언트와 지원하는 설정 항목이 다를 수 있습니다. 지원하지 않는 프로토콜이나 설정 항목 파싱 오류가 발생하면 시스템 프록시를 반복해서 껐다 켜기보다 실제 실행 중인 코어와 버전을 먼저 확인하세요. 구형 Clash for Windows는 더 이상 유지보수되지 않으므로, 새로 설치할 때는 클라이언트 프로젝트의 유지보수 상태와 현재 Windows 지원 범위를 먼저 확인해야 합니다.
- 클라이언트: 설정 메뉴와 업데이트 방법을 쉽게 찾을 수 있도록 앱 이름, 버전, 설치 경로를 기록해 두세요.
- 코어: 클라이언트의 코어 정보나 로그 첫 부분에서 이름과 버전을 확인하세요. 앱 버전과 코어 버전은 서로 다릅니다.
- 설정: 구독이 Clash 또는 mihomo 호환 형식인지 확인하세요. 노드 URI만 있는 목록은 완전한 YAML 설정 파일로 바로 불러오지 못할 수 있습니다.
설치 패키지 선택: 시스템 아키텍처와 설치 방식 확인
먼저 x64 또는 ARM64를 확인한 뒤 다운로드
Windows 11에서는 ‘설정’ → ‘시스템’ → ‘정보’에서 ‘시스템 종류’를 확인하세요. Windows 10에서는 보통 ‘설정’ → ‘시스템’ → ‘정보’에서 확인할 수 있습니다. Intel 또는 AMD 데스크톱 프로세서는 대부분 x64 패키지를 사용합니다. ARM 기반 기기라면 프로젝트에서 제공하는 ARM64 패키지를 우선 선택하세요. Windows가 ‘64비트’라는 이유만으로 두 아키텍처를 같은 설치 패키지로 취급하면 안 됩니다.
| 확인 항목 | 선택 기준 | 흔히 하는 실수 |
|---|---|---|
| 프로세서 아키텍처 | x64 또는 ARM64, 배포 패키지 표기와 일치하는지 확인 | ARM64와 x64 패키지를 혼용 |
| 설치 프로그램 | 프로젝트에서 제공하는 EXE 또는 MSI 설치 안내에 따라 진행 | 패키징 방식이 다르다는 이유로 프록시 프로토콜도 다르다고 오해 |
| 포터블 패키지 | 데이터 폴더, 업데이트 방법, 서비스 설치 안내 확인 | 압축 해제 폴더를 옮긴 뒤에도 이전 시작 경로를 사용 |
| 시스템 지원 | 현재 버전에서 요구하는 Windows 버전과 런타임 구성 요소 확인 | 오래된 Windows에서도 모든 최신 클라이언트가 실행된다고 생각 |
설치 및 첫 실행
- 다운로드 센터에서 Windows 클라이언트를 선택한 다음, 해당 프로젝트의 릴리스 안내와 게시자 정보, 시스템 요구 사항을 확인하세요.
- 실행 중인 다른 프록시 클라이언트는 종료하세요. 처음 문제를 점검할 때는 코어 하나만 실행해 포트와 라우팅 충돌을 줄이세요.
- 프로그램은 안정적인 경로에 설치하세요. 포터블 패키지를 임시 압축 해제 폴더에 오래 두지 말고, 설정을 마친 뒤 폴더 이름을 바꾸거나 통째로 옮기지 마세요.
- 실행 후 로그를 열어 코어가 반복해서 종료되거나 재시작하지 않는지, 설정 파싱 오류가 없는지 확인하세요. 런타임 구성 요소가 부족하다면 해당 버전의 프로젝트 문서에 따라 설치하세요.
Windows 보안 경고가 표시되면 다운로드 출처와 게시자, 파일 속성을 먼저 확인한 뒤 계속 진행할지 결정하세요. 설치 문제를 해결하려고 시스템 보호 기능을 장기간 끄지 마세요. 회사 기기에서는 설치 및 네트워크 권한이 조직 정책에 제한될 수 있으므로 관리자에게 확인해야 합니다.
구독 가져오기: 다운로드한 뒤 설정 활성화하기
클라이언트마다 설정 메뉴 이름은 조금씩 다르며, ‘구독’, ‘설정’ 또는 ‘Profiles’로 표시되는 경우가 많습니다. 아래 단계는 기능을 기준으로 설명하므로 특정 버전의 버튼 이름을 모든 클라이언트에 그대로 적용하지 마세요. 가져오기 전에 링크가 구독 제공업체에서 받은 것인지, 클라이언트가 인식할 수 있는 형식으로 응답하는지 확인하세요.
- 설정 관리 화면을 열고 URL 가져오기를 선택한 다음 구독 링크를 주소 입력란에 붙여 넣으세요.
- 다운로드 또는 가져오기를 실행하고 결과를 확인하세요. HTTP 401 또는 403 오류가 발생하면 인증 정보, 유효 기간, 접근 제한을 확인해야 합니다. 웹페이지 내용이 반환됐다면 이를 YAML 설정으로 사용하면 안 됩니다.
- 방금 가져온 설정을 선택해 현재 설정으로 지정하세요. 목록에 구독 항목이 표시되어도 코어가 해당 설정으로 전환됐다는 뜻은 아닙니다.
- 정책 그룹이 있는지, 노드 이름이 모두 표시되는지 확인하세요. 실행 모드는 규칙 모드로 설정하고, 직접 선택할 수 있는 정책 그룹에는 사용할 노드를 지정하세요.
- 지연 시간 테스트를 실행하세요. 실패하면 로그에 표시된 구체적인 오류를 확인하고, 한 번의 시간 초과만으로 Windows 설치 문제라고 단정하지 마세요.
로컬 설정 편집과 구독 업데이트는 따로 관리
다운로드된 설정 파일을 직접 수정하면 다음 구독 업데이트 때 변경 내용이 덮어써질 수 있습니다. 규칙이나 DNS 설정을 계속 유지해야 한다면 클라이언트에서 공식 지원하는 재정의, 병합 또는 로컬 설정 기능을 사용하고 업데이트 후 적용된 설정을 확인하세요. 모든 클라이언트가 같은 재정의 문법을 지원한다고 가정하면 안 됩니다.
구독 링크에는 보통 접근 자격 증명이 포함됩니다. 문제를 공유하는 스크린샷에서는 전체 링크와 토큰, 관리 키를 가리세요. 서드파티 구독 변환 서비스를 사용하면 해당 서비스가 구독 내용을 볼 수 있으므로 신뢰 범위를 먼저 검토하세요. 가능하면 제공업체가 직접 제공하는 호환 설정을 사용하세요.
시스템 프록시: 127.0.0.1과 실제 수신 포트부터 확인
시스템 프록시는 Windows 프록시 설정을 따르는 앱에 주로 적용됩니다. 모든 프로세스의 트래픽을 가로채는 전역 스위치는 아닙니다. 일부 명령줄 도구와 게임, 자체 네트워크 연결을 구현한 프로그램은 이 설정을 자동으로 사용하지 않습니다. 따라서 ‘브라우저는 되는데 터미널은 연결되지 않는’ 상황이 반드시 오류인 것은 아닙니다.
이 문서에서는 혼합 프록시 포트 7890을 예로 듭니다. 클라이언트에 따라 7897이나 다른 포트를 사용할 수 있으므로 현재 코어의 유효 설정과 수신 로그를 기준으로 확인하세요. HTTP와 SOCKS 포트가 별도로 설정될 수도 있습니다. 컨트롤 인터페이스 포트를 시스템 프록시에 입력하지 마세요.
# 로컬 연결 매개변수 예시이며, 구독을 대체할 수 있는 완전한 설정이 아닙니다
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info- 클라이언트에서 시스템 프록시 기능을 켜세요.
- Windows ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’를 열어 수동 프록시 주소와 포트가 현재 클라이언트를 가리키는지 확인하세요. 일부 환경에서는 설정 스크립트를 사용하므로 다른 프로그램이 입력한 스크립트 주소가 있는지도 확인해야 합니다.
- PowerShell에서 로컬 포트에 TCP 연결을 설정할 수 있는지 확인하세요.
Test-NetConnection -ComputerName 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --head --connect-timeout 10 https://example.com/TcpTestSucceeded : True는 로컬 포트에 연결할 수 있다는 뜻일 뿐, 원격 노드가 사용 가능하다는 뜻은 아닙니다. 두 번째 명령은 로컬 HTTP 프록시를 명시적으로 사용하므로 ‘프로그램이 시스템 프록시를 사용하지 않는 문제’와 ‘프록시 연결 자체의 문제’를 구분하는 데 도움이 됩니다. 일부 PowerShell 환경에서는 curl 별칭으로 인해 매개변수가 달라질 수 있으므로 curl.exe를 사용하면 이를 피할 수 있습니다. 테스트 도메인은 예시이므로 점검하려는 실제 대상으로 바꿔도 됩니다.
서비스 모드, TUN, 방화벽: 권한과 트래픽 처리 범위를 따로 확인
서비스 모드는 권한을 보완할 뿐, 설정 검증을 대신하지 않습니다
일부 Windows 클라이언트는 서비스 모드로 코어를 실행하거나 높은 권한이 필요한 작업을 수행합니다. 서비스를 설치할 때 UAC 권한 요청이 표시되는 것은 권한 상승 절차입니다. 설치하려는 클라이언트에서 보낸 요청인지 확인하세요. 클라이언트마다 구현 방식이 다르므로 서비스를 설치했다고 TUN이 활성화되거나 라우팅과 DNS 설정이 올바르다는 뜻은 아닙니다.
서비스 설치 후 클라이언트에서 서비스 상태를 확인하세요. 추가 확인이 필요하면 Win + R을 누르고 services.msc를 입력해 서비스 관리자를 연 다음, 프로젝트 문서에서 실제 서비스 이름과 실행 상태를 확인하세요. 다른 클라이언트의 서비스 이름을 그대로 따라 하거나 알 수 없는 시스템 서비스를 삭제하지 마세요.
기본 연결을 확인한 뒤 TUN 활성화
TUN은 가상 네트워크 인터페이스와 라우팅을 통해 지정된 IP 트래픽을 처리하며, 시스템 프록시를 따르지 않는 일부 앱에도 적용할 수 있습니다. 보통 관리자 권한과 라우팅, DNS 처리가 필요합니다. 먼저 일반 로컬 프록시가 정상 작동하는지 확인한 뒤 TUN을 켜고, 로그에 가상 인터페이스 생성 실패, 라우트 추가 실패, 권한 부족이 표시되는지 살펴보세요.
- 다른 VPN과 함께 사용할 때는 라우팅 우선순위와 DNS 설정, 가상 네트워크 어댑터를 확인하세요. 처음 문제를 점검하는 동안은 트래픽을 처리하는 방식을 하나만 남겨 두는 것이 좋습니다.
- LAN 기기, 회사 내부망, 원격 데스크톱에 문제가 생기면 내부망 대역이 잘못 프록시로 전달되는지 확인하세요. 규칙 문제를 전역 모드로 장기간 덮어두지 마세요.
- TUN의 DNS 하이재킹은 해당 경로를 실제로 통과하는 요청에만 적용됩니다. 브라우저 자체의 암호화 DNS와 다른 VPN의 DNS 정책도 따로 확인해야 합니다.
프로그램과 사용 목적에 맞춰 방화벽 권한 설정
Windows Defender 방화벽 경고가 표시되면 코어 프로그램의 경로를 확인하고 실제 사용 환경에 맞는 네트워크 프로필을 선택하세요. 로컬에서 루프백 프록시만 사용할 경우 LAN에 인바운드 프록시 포트를 개방할 필요가 없는 경우가 많습니다. 다른 기기와 공유할 때는 수신 주소와 allow-lan, 해당 인바운드 규칙을 추가로 확인하세요.
테스트를 위해 방화벽 전체를 끄지 마세요. 서드파티 보안 프로그램이나 조직 정책이 아웃바운드 연결을 제한할 수도 있으므로 차단 기록을 확인하세요. 코어 업데이트 후 실행 파일 경로가 바뀌면 기존 프로그램 규칙이 적용되지 않을 수 있습니다. 이때는 프로그램 경로에 맞춰 권한을 갱신하고, 프로그램을 제한하지 않는 광범위한 규칙을 추가하지 마세요.
자주 발생하는 문제: 포트 충돌, 프록시 설정 잔류, 설정 오류
포트 충돌: 먼저 점유 프로세스를 확인한 뒤 종료하거나 포트를 변경
로그에 address already in use 또는 바인딩 실패가 표시되면 해당 포트를 수신 중인 프로세스를 확인하세요. 아래 두 명령은 수신 주소와 프로세스 ID를 찾는 데 사용하며 프로세스를 자동으로 종료하지 않습니다.
netstat -ano | findstr LISTENING | findstr :7890
Get-NetTCPConnection -LocalPort 7890 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess출력된 PID로 작업 관리자의 ‘세부 정보’ 탭에서 해당 프로세스를 찾으세요. 구형 클라이언트나 중복 실행된 코어라면 먼저 해당 화면에서 정상 종료하세요. 다른 프로그램이 꼭 해당 포트를 사용해야 한다면 현재 클라이언트의 혼합 포트를 예를 들어 7891로 변경한 뒤 시스템 프록시와 터미널 프록시 환경 변수, 명시적 프록시 테스트 명령도 함께 수정하세요.
시스템 프록시 오류: 앱 설정과 Windows 설정 구분하기
| 증상 | 우선 확인할 항목 | 다음 단계 |
|---|---|---|
| 명시적 프록시 테스트는 성공하지만 특정 앱은 실패 | 앱이 시스템 프록시를 따르는지, 자체 프록시 설정이 있는지 | 앱의 프록시를 설정하거나 TUN 사용 검토 |
| 로컬 포트에 연결할 수 없음 | 코어 상태, 실제 포트, 설정 파싱 로그 | 수신 상태를 복구한 뒤 원격 연결 테스트 |
| 브라우저는 연결되지만 명령줄은 실패 | 도구에 별도의 프록시 매개변수나 환경 변수가 필요한지 | 해당 도구 문서에 따라 프록시를 설정한 뒤 프로세스 재시작 |
| 연결 기록에 직접 연결로 표시됨 | 매칭된 규칙, 정책 그룹 선택, 현재 실행 모드 | 규칙의 대상이나 그룹 내 선택 수정 |
| TUN 사용 후 내부망에 문제가 발생 | 라우팅, DNS, 다른 VPN, 내부망 규칙 | TUN을 끄고 비교 테스트한 뒤 항목별로 조정 |
WinHTTP와 사용자 수준 시스템 프록시는 서로 다른 설정입니다. netsh winhttp show proxy로 WinHTTP 설정을 확인할 수 있지만, 결과가 모든 브라우저와 데스크톱 앱의 프록시 상태를 나타내지는 않습니다. 특정 프로그램 하나를 고치려고 컴퓨터 전체의 프록시 설정을 무작정 변경하지 마세요.
종료 후 인터넷이 안 될 때: 프록시가 종료된 포트를 가리키는지 확인
클라이언트가 비정상 종료됐는데 Windows 프록시가 여전히 127.0.0.1:7890을 가리킨다면 시스템 프록시를 따르는 앱의 연결이 실패할 수 있습니다. 클라이언트를 다시 실행해 수신을 복구하거나 Windows 프록시 설정에서 기존에 켰던 수동 프록시를 끄세요. 회사에서 설정한 프록시 스크립트는 함부로 삭제하지 마세요. 기존 값을 기록한 뒤 관리 지침에 따라 처리하세요.
설정 파싱 오류가 발생하면 로그를 확인해 문제가 있는 항목을 찾아야 합니다. YAML 들여쓰기에는 공백을 사용하고, 정책 그룹 참조는 실제 존재하는 이름과 일치해야 하며, 프로토콜 유형은 현재 코어에서 지원되어야 합니다. ‘연결 안 됨’만 기록하는 것보다 오류 전문과 줄 번호, 코어 버전을 함께 보관하는 편이 문제를 찾는 데 효과적입니다.
시작 프로그램 등록: 로그인 시 실행, 서비스 실행, 프록시 복구를 각각 확인
클라이언트의 ‘시작 프로그램’ 설정은 보통 사용자가 Windows에 로그인한 뒤 화면을 실행하는 기능입니다. 백그라운드 서비스는 로그인 전부터 실행될 수 있어 두 기능은 같지 않습니다. 시작 프로그램을 켠 뒤에는 현재 설정이 자동으로 불러와지는지, 시스템 프록시가 예상대로 복구되는지, TUN에 필요한 권한이 있는지도 확인하세요.
- 클라이언트 설정에서 제공하는 Windows 시작 옵션을 켜세요. 시작 바로 가기를 여러 개 수동으로 추가하지 마세요.
- Windows 11의 ‘설정’ → ‘앱’ → ‘시작 프로그램’ 또는 작업 관리자의 ‘시작 앱’에서 해당 항목이 비활성화되어 있는지 확인하세요. 서비스나 작업 스케줄러로 실행되는 항목은 클라이언트 문서를 참고해 별도로 점검해야 합니다.
- 클라이언트를 정상 종료한 뒤 다시 실행해 선택한 설정과 정책 그룹, 포트가 유지되는지 확인하세요.
- 절전 모드에서 깨어나는 것만 테스트하지 말고 Windows를 실제로 재시작한 뒤 로그인하세요. 네트워크 연결이 완료될 때까지 기다린 다음 로컬 포트와 대상 연결을 확인하세요.
- 코어 인스턴스가 하나만 실행 중인지 확인하고, 트레이 화면과 백그라운드 서비스, 현재 설정 상태가 서로 일치하는지 살펴보세요.
재시작 후 구독 업데이트는 실패하지만 수동 업데이트는 성공한다면, 시작 시 Wi-Fi 연결이 아직 완료되지 않았거나 시스템 시간이 동기화되지 않았거나 구독 접속 경로에 문제가 있을 수 있습니다. 먼저 시간 순서와 오류 로그를 확인한 뒤 클라이언트에서 제공하는 지연 시작 또는 업데이트 재시도 옵션을 검토하세요. 바로 재설치할 필요는 없습니다.
설정 완료 후 확인 목록
- 로컬 수신 포트에 연결할 수 있고, 바인딩 실패나 코어 반복 재시작이 없습니다.
- 현재 설정이 구독 기록과 일치하고 정책 그룹에서 사용 가능한 노드를 선택했습니다.
- 연결 로그에서 대상 요청에 적용된 규칙과 최종 아웃바운드를 확인할 수 있습니다.
- 정상 종료 후 네트워크가 예상대로 복구되고 시스템 프록시가 수신 중인 프로세스가 없는 포트를 가리키지 않습니다.
- 재시작 후 로그인하면 설정이 복구됩니다. TUN이 필요하다면 가상 인터페이스와 라우팅, DNS 상태를 별도로 확인하세요.
이 순서대로 설치하면 이후 발생하는 문제를 앱 프록시, 코어 수신, 구독 설정, 노드 연결, 시스템 트래픽 처리 중 어느 단계에서 생겼는지 구분하기 쉽습니다. 규칙과 구독 관리 방법은 입문 가이드에서 확인하세요. 권한과 네트워크 문제에 대한 추가 안내는 문제 해결에서 볼 수 있습니다.