Windows 설치 및 설정

먼저 클라이언트, 시스템 아키텍처, 코어 확인하기

Windows에서 Clash를 사용하려면 보통 GUI 클라이언트를 설치한 뒤 클라이언트에서 프록시 코어를 실행합니다. Clash와 Clash Meta(현재 mihomo)는 서로 다른 버전 계열입니다. GUI가 열리더라도 코어가 구독에 포함된 모든 프로토콜을 지원한다고 볼 수는 없습니다. 설치 전에 운영체제 아키텍처, 클라이언트의 유지보수 상태, 구독 형식을 확인하면 설치 파일을 여러 번 바꾸는 일을 줄일 수 있습니다.

설치 전에 확인할 세 가지

1. 시스템 아키텍처: Windows에서 「설정」→「시스템」→「정보」로 이동해 「시스템 종류」를 확인하세요. 일반적인 Intel·AMD PC에는 x64 설치 파일을 선택합니다. ARM 기기는 클라이언트에서 정식 제공하는 ARM64 버전을 우선 선택하고, 설치 파일 크기만으로 판단하지 마세요.
2. 유지보수 상태: 업데이트가 계속 제공되고 현재 Windows를 지원하는 클라이언트를 선택하세요. Clash for Windows는 유지보수가 종료되었습니다. 이전 가이드의 메뉴 위치, 드라이버 방식, 문제 해결 방법을 새 클라이언트에 그대로 적용하면 안 됩니다.
3. 설정 형식: 구독 제공업체에 링크가 공유 링크만 포함한 노드 목록이 아니라 Clash 또는 mihomo 설정을 제공하는지 확인하세요. 일부 최신 프로토콜이나 필드는 mihomo가 필요하며, 구형 코어에서는 불러오는 단계에서 오류가 날 수 있습니다.

설치 파일은 사이트의 Clash 클라이언트 설치 파일 페이지에서 플랫폼에 맞게 선택할 수 있습니다. 설치 전에 실행 중인 다른 유사 클라이언트를 종료하세요. 여러 프로그램이 동시에 시스템 프록시를 변경하거나 포트를 점유하고 가상 네트워크 어댑터를 중복 생성하는 일을 막을 수 있습니다. 기존 설정을 유지해야 한다면 클라이언트의 설정 관리 기능으로 먼저 내보내 백업하세요. 설정에 구독 인증 정보가 포함될 수 있으므로 로컬의 안전한 폴더에 보관해야 합니다.

설치와 SmartScreen: 출처를 확인한 뒤 경고 처리하기

설치 프로그램을 실행하면 Windows SmartScreen에 「Windows에서 PC를 보호했습니다」라는 메시지가 표시될 수 있습니다. 이런 경고는 파일 평판이나 서명 등 여러 요인에 따라 나타납니다. 경고만으로 파일에 문제가 있다고 단정할 수도, 항상 무시해도 되는 절차로 여길 수도 없습니다. 먼저 선택한 프로젝트의 공식 배포 경로에서 받은 파일인지 확인하고, 설치 파일 이름과 아키텍처가 다운로드 대상과 일치하는지 확인하세요. 가능하다면 파일 속성에서 디지털 서명 정보도 확인합니다.

차단되었을 때 처리 순서

1. 출처가 불분명한 설치 프로그램은 닫고 다운로드 페이지와 실제 파일을 다시 확인하세요. 메신저 첨부 파일이나 임의의 파일 공유 사이트에 올라온 사본으로 설치를 계속하지 마세요.
2. 출처를 신뢰할 수 있고 기기 정책상 허용되는 경우에만 SmartScreen의 「추가 정보」→「실행」을 선택해 계속 진행하세요. 해당 버튼이 보이지 않더라도 시스템 보호 기능을 꺼서 조직의 정책을 우회하지 마세요.
3. 보안 소프트웨어가 파일을 격리했다면 「Windows 보안」→「바이러스 및 위협 방지」→「보호 기록」에서 탐지 결과를 확인한 뒤 소프트웨어 배포자에게 문의할지 결정하세요. 다운로드 폴더 전체를 예외로 추가하지 마세요.
4. 설치가 끝나면 먼저 일반 권한으로 실행해 보세요. 시스템 프록시를 사용하는 데 GUI를 항상 관리자 권한으로 실행할 필요는 없습니다. 서비스 모드와 TUN에 필요한 권한은 이후 별도로 설정하세요.

포터블 패키지는 압축 프로그램 안에서 바로 실행하지 말고, 현재 사용자가 쓸 수 있는 고정 폴더에 완전히 압축을 풀어 사용하세요. 클라이언트에서 설정 저장이나 코어 업데이트가 안 된다고 나오면 권한을 반복해서 높이기보다 폴더 권한, 보안 소프트웨어의 제어된 폴더 액세스 기록, 다른 프로세스의 파일 점유 여부를 확인하세요.

구독 가져오기: 업데이트 성공 후 설정 활성화하기

클라이언트의 「설정」 또는 「Profiles」 페이지를 열고 URL 가져오기를 선택한 다음 구독 제공업체가 안내한 전체 주소를 붙여넣어 다운로드하세요. 토큰이 포함된 구독 주소는 계정 인증 정보와 같습니다. 공개 로그나 스크린샷, 온라인 변환 사이트에 올리지 마세요. 링크가 공개되었다면 로컬 기록을 지우는 데 그치지 말고 제공업체의 관리 페이지에서 재발급하세요.

1. 다운로드 결과 확인: 설정 목록에 새 항목이 표시되어야 합니다. 웹 로그인 화면이나 세션 만료 안내, 오류 페이지가 반환된 경우 파일 이름을 YAML로 바꿔도 정상적으로 불러올 수 없습니다.
2. 설정 활성화: 방금 가져온 항목을 선택하고 코어가 다시 로드될 때까지 기다리세요. 구독 갱신 성공은 파일을 가져왔다는 뜻일 뿐, 해당 설정이 현재 실행 중이라는 뜻은 아닙니다.
3. 로그 확인: YAML 파싱 오류, 알 수 없는 프록시 유형, 프록시 그룹 누락 등의 메시지를 먼저 확인하세요. 표시된 줄 번호는 오류를 발견한 위치일 수 있으므로 앞줄의 들여쓰기와 필드도 함께 살펴보세요.
4. 출구 노드 선택: 규칙 모드로 전환한 뒤 실제 규칙에서 참조하는 정책 그룹에서 노드를 선택하세요. 현재 규칙에서 사용하지 않는 예비 그룹만 변경하지 마세요.

구독을 처음 가져오는 데 실패했다면 시스템 프록시를 끄고 현재 네트워크에서 구독 주소를 다시 요청해 보세요. 사용 가능한 노드가 아직 없을 수 있으므로 구독 요청이 프록시를 통과했다고 가정하면 안 됩니다. 제공업체가 허용하고 클라이언트가 지원하는 경우에만 구독 갱신 전용 프록시를 설정하세요. 출처가 불분명한 변환 서비스를 임의로 추가하지 마세요.

시스템 프록시와 포트: 먼저 브라우저 연결 확인하기

첫 번째 확인 단계에서는 시스템 프록시만 켜고 TUN은 꺼 두세요. 시스템 프록시는 Windows 프록시 설정을 따르는 앱에 주로 적용되며 모든 프로그램의 트래픽을 처리하지는 않습니다. 게임, 명령줄 도구, 자체 네트워크 스택을 사용하는 앱은 시스템 프록시를 사용하지 않을 수 있습니다. 먼저 이 경로를 정상화해야 노드 문제와 가상 네트워크 어댑터 문제를 구분할 수 있습니다.

수신 포트와 Windows 설정 확인

클라이언트 설정에서 HTTP 포트 또는 혼합 포트를 확인하세요. 혼합 포트가 7890으로 표시된다면 시스템 프록시를 켠 뒤 「설정」→「네트워크 및 인터넷」→「프록시」에서 「프록시 서버 사용」 항목의 주소와 포트를 확인할 수 있습니다. 로컬 주소는 보통 127.0.0.1입니다. PAC 모드에서는 자동 구성 스크립트를 사용할 수 있으므로 수동 프록시 스위치만 보고 작동 여부를 판단하지 마세요.

PowerShell에서 아래 명령을 실행하면 예시 포트가 수신 대기 중인지 확인할 수 있습니다. 결과가 나오지 않으면 코어 실행 실패, 포트 설정 불일치, 설정 파일 불러오기 오류부터 확인하세요.

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

포트를 다른 프로세스가 사용 중이라면 출력된 프로세스 ID로 프로그램을 확인한 뒤 충돌하는 클라이언트를 종료하거나 현재 클라이언트의 포트를 변경하세요. 정체를 알 수 없는 시스템 프로세스를 바로 종료하지 마세요. 포트를 바꾼 후에는 시스템 프록시를 다시 켜고 앱에 직접 입력한 프록시 주소도 함께 변경해야 합니다.

curl.exe --proxy http://127.0.0.1:7890 --head --connect-timeout 10 https://example.com/

이 명령은 로컬 HTTP 프록시를 명시적으로 사용합니다. HTTP 포트나 혼합 포트에 적합하며 SOCKS만 제공하는 포트에는 사용할 수 없습니다. HTTP 응답이 돌아오면 이번 요청에서 프록시 연결이 완료된 것이지만, 모든 사이트에 접속할 수 있다는 뜻은 아닙니다. 이어서 대상 웹페이지를 열고 클라이언트의 「연결」 또는 로그 페이지에서 대상 도메인, 적용된 규칙, 정책 그룹, 실제 출구 노드를 확인하세요. 지연 시간 테스트 성공만으로는 이 확인을 대신할 수 없습니다.

방화벽 허용: 로컬 프록시와 LAN 서비스는 다릅니다

Windows 방화벽은 프로그램, 네트워크 프로필, 규칙 방향 등을 기준으로 통신을 제어합니다. 로컬 앱이 127.0.0.1에 연결하기만 한다면 보통 LAN에 프록시 포트를 공개할 필요가 없습니다. 시스템 권한 허용 창이 표시되어도 개인 네트워크와 공용 네트워크를 모두 선택할 이유는 없으며, PC 전체의 방화벽을 끌 필요도 없습니다.

LAN 공유가 꼭 필요하다면 클라이언트가 지원하는지 확인하고 「LAN 허용」을 켠 다음 수신 주소가 LAN 인터페이스를 포함하는지 확인하세요. 「Windows 보안」→「방화벽 및 네트워크 보호」→「고급 설정」에서 실제 프록시 포트에 필요한 인바운드 규칙만 만들고, 신뢰할 수 있는 기기 주소나 로컬 서브넷으로 범위를 제한하세요. HTTP 프록시는 보통 TCP를 사용합니다. 프록시 노드 프로토콜에 UDP가 포함되어 있다는 이유로 로컬의 모든 UDP 포트를 열지 마세요.

GUI와 코어는 서로 다른 실행 파일일 수 있습니다. GUI에서 온라인 업데이트가 되더라도 조직의 아웃바운드 규칙이 코어를 차단하지 않는다는 뜻은 아닙니다. 로그에서 실제로 차단된 프로세스를 찾은 뒤 해당 프로그램의 경로와 규칙을 확인하세요. 클라이언트 업데이트 후 실행 파일 경로가 바뀌면 기존 규칙이 더 이상 적용되지 않을 수도 있습니다.

UWP 루프백: 브라우저는 되지만 일부 앱이 연결되지 않을 때

AppContainer에서 실행되는 일부 앱은 네트워크 격리 때문에 로컬 루프백 프록시에 직접 연결하지 못할 수 있습니다. 브라우저에서는 접속되지만 특정 앱에 오프라인 메시지가 표시되는 식으로 나타납니다. Microsoft Store 앱이라고 모두 이런 제한을 받는 것은 아니며, 패키지 형태로 배포되는 데스크톱 프로그램도 반드시 같은 제한을 받는 것은 아닙니다. 먼저 해당 앱이 실제로 시스템 프록시를 사용하려는지 확인하세요.

필요한 앱에만 예외 적용하기

1. 클라이언트에 「UWP 루프백」 또는 「Loopback」 도구가 있다면 실행한 뒤 로컬 프록시를 통해 접속해야 하는 앱만 선택하고 저장하세요. 그런 다음 해당 앱을 다시 시작합니다.
2. GUI 도구가 없다면 터미널에서 CheckNetIsolation.exe LoopbackExempt -s를 실행해 현재 예외 목록을 확인할 수 있습니다.
3. 예외를 추가해야 한다면 관리자 권한으로 터미널을 실행하고 조회한 정확한 패키지 패밀리 이름을 -n= 매개변수에 전달하세요. 앱 표시 이름이나 설치 폴더, 전체 패키지 이름으로 대신하면 안 됩니다.

Get-AppxPackage |
  Select-Object Name, PackageFamilyName

CheckNetIsolation.exe LoopbackExempt -s

추가 명령은 CheckNetIsolation.exe LoopbackExempt -a -n= 뒤에 실제 패키지 패밀리 이름을 붙입니다. 예외를 취소하려면 -a를 -d로 바꾸고 같은 이름을 사용하세요. 앱과 배포 채널에 따라 패키지 식별자가 다르므로 그대로 복사해 쓸 수 있는 패키지 이름은 제공하지 않습니다. 설정을 마친 뒤 대상 앱을 다시 시작하고 클라이언트의 연결 기록을 확인하세요. 요청이 여전히 들어오지 않는다면 앱의 자체 프록시 지원과 네트워크 정책을 추가로 살펴보세요.

TUN 모드: 서비스 권한, 가상 어댑터, DNS

시스템 프록시를 따르지 않는 프로그램도 처리해야 할 때 TUN을 고려하세요. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 코어로 전달합니다. 실제로 특정 연결을 처리하는지는 라우팅, 제외 설정, 구성에 따라 달라집니다. mihomo의 TUN 스택 옵션, DNS 처리 방식, 클라이언트 서비스 설치 절차는 버전에 따라 다를 수 있으므로 현재 클라이언트의 안내를 기준으로 설정하세요.

한 번에 하나씩 설정하기

1. 먼저 시스템 프록시 경로가 정상인지 확인하고, 현재 노드와 작업 포트, 정상적으로 열리는 테스트 페이지를 기록하세요.
2. 클라이언트의 「설정」에서 「서비스 모드」 또는 서비스 설치 항목을 통해 권한을 부여하세요. 서비스 설치에는 관리자 권한이 필요합니다. 설치에 실패하면 오류 내용을 먼저 확인하고 같은 버튼을 계속 누르지 마세요.
3. 트래픽 처리 여부를 쉽게 확인하려면 시스템 프록시를 먼저 끈 다음 TUN을 켜세요. 로그에서 가상 인터페이스와 라우팅이 정상적으로 설정되었는지 확인합니다.
4. 구독, 덮어쓰기 설정, 클라이언트 관리 설정이 DNS 구성을 변경했는지 확인하세요. TUN이 켜져 있어도 DNS 처리와 도메인 확인이 정상이라는 뜻은 아닙니다.

PowerShell에서 Get-NetAdapter -IncludeHidden을 실행해 가상 인터페이스를 확인하고, route print로 라우팅을 살펴볼 수 있습니다. 인터페이스 이름에 반드시 「Clash」가 포함되는 것은 아니며, 기존 형태의 단일 기본 경로가 나타나지 않을 수도 있습니다. 일부 자동 라우팅 방식은 더 구체적인 경로 항목을 사용합니다. 판단할 때는 시작 전후의 변화와 코어 로그를 함께 확인하고 네트워크 어댑터 아이콘 하나만 보지 마세요.

드라이버 로드에 실패하면 먼저 다른 VPN, 네트워크 가속기, 가상 어댑터 도구를 종료한 뒤 클라이언트에서 지원하는 방식으로 서비스나 드라이버를 복구하세요. 출처가 불분명한 사이트에서 DLL 파일만 내려받아 설치 폴더에 덮어쓰지 말고, 구형 드라이버를 사용하려고 메모리 무결성 같은 시스템 보호 기능을 끄지도 마세요. 호환되지 않는 드라이버 방식이라면 지원되는 클라이언트 버전으로 업데이트하는 것이 좋습니다.

TUN을 켠 뒤 LAN 프린터, NAS, 회사 내부망에 접속할 수 없다면 사설 IP 대역의 라우팅 제외와 직접 연결 규칙을 확인하세요. 규칙의 DIRECT와 시스템 라우팅 제외는 서로 다른 계층의 설정입니다. DNS 조회에 실패한 경우 직접 연결 규칙만 추가해도 해결되지 않을 수 있습니다. 회사 VPN을 함께 사용한다면 조직에서 허용하는 네트워크 구성을 먼저 확인하세요. 두 프로그램이 동시에 라우팅과 DNS를 제어하지 않도록 해야 합니다.

설치 후 점검 및 종료 후 복구

설정을 마친 뒤 아래 항목을 하나씩 확인하세요. 설정을 한 번에 하나만 바꾸고 테스트 시각과 로그 오류를 기록하면 노드 변경, 드라이버 재설치, DNS 수정 등을 동시에 진행하는 것보다 원인을 찾기 쉽습니다.

• 설정: 방금 가져온 구독이 활성화되어 있고, 코어 로그에 파싱 오류가 없으며, 정책 그룹에서 실제로 사용할 수 있는 출구 노드를 선택했는지 확인합니다.
• 브라우저: 대상 페이지가 열리고 클라이언트에 해당 연결이 표시되는지, 적용된 규칙이 예상과 일치하는지 확인합니다.
• 특정 앱: 시스템 프록시, UWP 루프백 제한, 앱 자체 프록시 설정을 구분하세요. 모든 연결 실패를 방화벽 탓으로 돌리지 마세요.
• TUN: 필요한 경우에만 활성화하고 가상 인터페이스, 라우팅, DNS가 정상 작동하는지 확인한 뒤 로컬 네트워크 리소스도 테스트하세요.
• 종료 후 복구: 먼저 TUN과 시스템 프록시를 끈 다음 클라이언트를 종료하고 일반 네트워크에 계속 접속할 수 있는지 확인합니다.

클라이언트가 비정상 종료된 뒤 웹페이지가 모두 열리지 않는다면 Windows 「설정」→「네트워크 및 인터넷」→「프록시」에서 이미 수신 대기를 멈춘 로컬 프록시나 자동 구성 스크립트가 남아 있는지 확인하세요. 조직에서 관리하는 기기라면 기존 정책을 덮어쓰지 마세요. TUN을 사용한 뒤에만 문제가 생겼다면 클라이언트를 다시 실행해 TUN을 정상적으로 끄고 라우팅을 정리하세요. 그래도 복구되지 않을 때 시스템을 재시작하고, 네트워크 어댑터를 모두 삭제하거나 네트워크 전체를 초기화하지 마세요.

이후 규칙 조정, 구독 업데이트, 자동 실행 설정은 사용 가이드에서 확인할 수 있습니다. Windows 플랫폼 설정은 전체 플랫폼 가이드의 Windows 섹션을 참고하세요. 검증된 기본 설정을 하나 보관하고 기능을 하나씩 추가하면 이후 문제를 비교할 기준을 마련할 수 있습니다.