Windows용 Clash 설치 및 설정 가이드: 시스템 프록시, TUN 모드, 방화벽 설정

먼저 시스템 프록시로 연결을 확인한 뒤 TUN 설정

Windows에서 Clash를 설정할 때는 ‘클라이언트 설치 → 구독 가져오기 → 정책 선택 → 시스템 프록시 켜기 → 연결 확인’ 순서로 진행하세요. 브라우저 연결이 정상인 것을 확인한 다음 필요에 따라 TUN을 활성화하면 됩니다. 한 번에 한 항목씩 변경해야 구독 오류, 노드 연결 실패, 로컬 트래픽 처리 문제를 구분하기 쉽습니다.

이 문서에서는 Windows 11의 시스템 메뉴를 기준으로 설명합니다. Clash Verge Rev, FlClash 등 GUI 클라이언트는 메뉴 이름이 다를 수 있으므로 시스템 프록시, 서비스 모드, TUN 설정은 사용 중인 클라이언트에 표시된 항목을 기준으로 확인하세요. GUI 클라이언트는 설정을 관리하고, mihomo 같은 코어는 설정을 해석해 규칙에 따라 연결을 처리합니다. 두 프로그램의 버전은 각각 확인해야 합니다.

설치 파일 선택: 아키텍처와 설치형·포터블형

Windows 시스템 아키텍처 확인

‘설정’ → ‘시스템’ → ‘정보’를 열고 ‘시스템 종류’를 확인하세요. 일반적인 Intel·AMD PC에는 x64 패키지를 선택하고, ARM 기기는 프로젝트에서 제공하는 ARM64 패키지를 우선 사용하세요. Windows가 64비트라는 이유만으로 x64와 ARM64 패키지를 같은 것으로 보면 안 됩니다.

패키지 유형	용도	주의 사항
EXE / MSI 설치 파일	일반적인 데스크톱 사용	설치 마법사의 안내에 따라 진행하세요. 서비스 구성 요소 설치 여부는 클라이언트 구현에 따라 다릅니다.
ZIP 포터블 패키지	직접 압축을 풀어 실행	먼저 고정된 폴더에 압축을 완전히 푸세요. 압축 파일 안에서 바로 실행하지 마세요.
코어 실행 파일	명령줄 실행 또는 서비스 배포	GUI 클라이언트와는 별개이며, 설정과 실행 인수를 직접 준비해야 합니다.

새 클라이언트 실행 전 기존 클라이언트 정리

기존 클라이언트의 시스템 트레이 메뉴에서 시스템 프록시를 끈 다음 클라이언트를 종료하세요.
라우팅과 DNS 설정을 동시에 변경하지 않도록 다른 VPN이나 투명 프록시 프로그램은 잠시 중지하세요.
새 클라이언트를 설치하고 실행한 뒤 코어가 정상적으로 시작됐는지 확인하고 설정을 가져오세요.
포터블 버전에서 서비스를 설치해야 한다면 먼저 고정된 폴더에 배치하세요. 폴더를 옮긴 뒤에는 서비스를 다시 설치해야 할 수 있습니다.

Clash for Windows 구버전은 더 이상 유지 관리되지 않으므로 새로 설치할 때 기본 선택으로 권장하지 않습니다. 기존 설정을 계속 사용해야 한다면 먼저 클라이언트 선택 가이드에서 대상 클라이언트와 코어의 호환성을 확인한 뒤 구독 및 오버라이드 설정을 옮기세요. 기존 클라이언트의 프로그램 폴더 전체를 새 클라이언트에 그대로 덮어쓰지 마세요.

구독 가져오기: 형식, 활성 설정, 업데이트 결과 확인

구독 링크는 일반적으로 서비스 제공업체에서 발급합니다. 클라이언트 다운로드 링크는 구독 링크가 아니며, 웹사이트 로그인 페이지나 결제 페이지도 설정으로 가져올 수 없습니다. 링크에 계정 정보가 포함될 수 있으므로 문제를 진단할 때 전체 URL, QR 코드, 설정 파일을 공개 게시판에 올리지 마세요.

클라이언트의 ‘구독’ 또는 ‘프로필’ 페이지에서 원격 설정 추가를 선택하세요.
Clash 또는 mihomo용 구독 링크를 붙여 넣어 다운로드한 뒤 파싱 오류가 있는지 확인하세요.
방금 가져온 설정을 선택해 현재 사용 중인 설정으로 지정하세요. 목록에 추가하는 것만으로는 적용되지 않습니다.
‘프록시’ 페이지에서 정책 그룹을 펼치고 사용 가능한 노드나 자동 선택 그룹을 선택하세요.
아웃바운드 모드를 ‘규칙’으로 설정한 다음 로그와 연결 페이지를 확인하세요.

‘다운로드 성공’이 ‘설정 적용 완료’를 뜻하지는 않습니다

설정 다운로드 성공은 응답을 받았다는 뜻일 뿐입니다. 응답 내용이 로그인 안내나 오류 페이지일 수도 있습니다. YAML 파싱 실패, 알 수 없는 프록시 유형, 존재하지 않는 정책 그룹 참조 등의 오류가 발생하면 먼저 설정 자체를 바로잡으세요. 시스템 프록시를 껐다 켜도 이런 오류는 해결되지 않습니다.

인증 실패: 구독이 만료됐는지, 링크가 재설정됐는지, 복사할 때 공백이 포함됐는지 확인하세요.
다운로드 시간 초과: 구독 도메인이 정상적으로 확인되는지 점검하세요. 작동하지 않는 시스템 프록시를 사용 중이라면 먼저 끄고 다시 시도하세요.
프로토콜 미지원: 클라이언트 이름만 보지 말고 현재 실행 중인 코어를 확인하세요. 서비스 제공업체가 호환되는 설정 형식을 제공하는지도 확인해야 합니다.
업데이트 후 설정이 사라짐: 원격 설정을 다시 다운로드하면서 변경 사항이 덮어써졌을 수 있습니다. 로컬 변경은 클라이언트에서 지원하는 오버라이드 또는 병합 기능으로 저장하세요.

노드 연결 테스트에 성공해도 테스트 대상에 해당 시점에 접속할 수 있었다는 뜻일 뿐입니다. 실제 앱이 프록시를 사용하는지는 규칙 매칭과 연결 세부 정보로 확인해야 합니다. 테스트 지연 시간을 다운로드 속도로 오해하지 마세요.

시스템 프록시: 주소, 포트, 앱 지원 여부 확인

시스템 프록시는 Windows 프록시 설정을 따르는 앱에 주로 적용됩니다. PC 전체 트래픽을 처리하는 기능이 아니며 UDP 트래픽이 모두 프록시를 통과한다고 보장하지도 않습니다. 먼저 TUN을 끈 상태로 두고 클라이언트에서 ‘시스템 프록시’를 켜세요. 그런 다음 브라우저로 대상 사이트에 접속하고 클라이언트의 연결 페이지에서 해당 연결이 표시되는지 확인하세요.

Windows에서 프록시 주소 확인

Windows 11에서 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’ → ‘수동 프록시 설정’ → ‘편집’을 여세요. 클라이언트가 로컬 HTTP 또는 혼합 프록시 포트를 사용하는 경우 주소는 보통 127.0.0.1이며, 포트에는 클라이언트에 표시된 값을 입력합니다. 외부 컨트롤러 포트를 여기에 입력하지 마세요. 예를 들어 9090은 제어 인터페이스에 사용되는 경우가 많으며 프록시 포트가 아닙니다.

아래는 필드의 의미를 설명하기 위한 mihomo 설정 예시입니다. 전체 구독 설정이 아니므로 기존 설정을 그대로 대체할 수 없습니다. GUI 클라이언트가 포트를 덮어쓸 수 있으니 실행 중인 설정과 실제 수신 대기 결과를 기준으로 확인하세요.

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

mixed-port는 하나의 포트에서 HTTP와 SOCKS 프록시 요청을 모두 받습니다. allow-lan: false는 LAN 접근을 제한합니다. 로컬 PC에서만 사용할 경우 브라우저 연결을 위해 LAN 공유를 켤 필요가 없습니다.

명령줄에서 프록시 주소만 별도로 확인

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

이 명령은 로컬 프록시를 명시적으로 지정하므로 ‘프록시 포트에 연결할 수 없음’과 ‘앱이 시스템 프록시를 사용하지 않음’을 구분하는 데 유용합니다. HTTP 응답을 받으면 해당 요청에서 대상 서버와 기본 통신이 이루어진 것입니다. 다른 노드나 사이트도 사용할 수 있다는 뜻은 아닙니다. 연결이 거부되면 코어 실행 여부와 포트가 올바른지 먼저 확인하세요.

TUN 모드: 서비스 권한, DNS, 가상 네트워크 인터페이스

TUN은 가상 네트워크 인터페이스와 라우팅 설정으로 트래픽을 처리하므로 시스템 프록시를 사용하지 않는 앱에 적합합니다. 시스템 프록시와는 작동 계층이 다릅니다. TUN을 켜도 연결이 끊긴 노드가 복구되지는 않으며, 규칙 모드에서는 규칙에 따라 직접 연결·프록시·차단 여부가 결정됩니다. 실제 지원 범위는 코어, 클라이언트, 설정에 따라 달라집니다.

순서대로 활성화하고 복구 경로 확보

먼저 동일한 설정에서 시스템 프록시를 사용해 대상 사이트에 접속할 수 있는지 확인하세요.
클라이언트 설정에서 ‘서비스 모드’ 또는 서비스 설치 항목을 찾으세요. 클라이언트가 백그라운드 서비스로 권한을 처리한다면 먼저 설치하고 서비스가 실행 중인지 확인하세요.
각 기능을 따로 확인할 수 있도록 시스템 프록시를 잠시 끈 다음 ‘TUN 모드’를 켜세요. 일부 클라이언트는 두 설정을 자동으로 조정하므로 실제 상태를 확인해야 합니다.
로그에서 가상 인터페이스가 정상적으로 생성됐는지, 권한 부족이나 라우트 추가 실패, DNS 포트 충돌이 없는지 확인하세요.
대상 앱을 실행하고 연결 페이지에서 프로세스, 대상 주소, 매칭된 규칙, 최종 아웃바운드를 확인하세요.

가상 인터페이스 설치나 라우팅 변경에는 보통 높은 권한이 필요합니다. 일부 클라이언트는 서비스를 통해 처리하고, 일부는 관리자 권한으로 실행해야 합니다. 모든 클라이언트에서 매번 관리자 권한으로 실행해야 하는 것은 아닙니다. 서비스를 사용해도 실패한다면 드라이버를 반복 설치하지 말고 서비스 상태와 코어 로그를 확인하세요.

웹페이지가 열리지 않으면 DNS 문제부터 분리해 확인

로그에 도메인 확인 실패가 표시되면 현재 설정에서 DNS가 활성화되어 있는지, 업스트림 리졸버에 연결할 수 있는지, 다른 VPN의 DNS 처리와 충돌하는지 먼저 확인하세요. mihomo의 Fake-IP와 redir-host는 서로 다른 DNS 처리 방식입니다. 모드를 전환하면 동작이 달라지므로 로그에 근거가 없을 때 반복해서 바꾸지 마세요.

ipconfig /all로 어댑터와 DNS 정보를, route print로 라우팅 정보를 확인할 수 있습니다. 이 명령은 시스템 상태를 살펴보는 용도이며 모든 요청이 TUN으로 전달된다는 증거는 아닙니다. 브라우저의 보안 DNS는 별도의 암호화된 경로를 사용할 수 있으므로 클라이언트 연결 기록도 함께 확인하세요.

TUN을 켠 뒤 PC 전체의 인터넷 연결이 끊기면 먼저 TUN을 끄고 기존 네트워크가 복구되는지 확인하세요. 기본 연결이 복구되면 서비스 권한, DNS, 다른 가상 네트워크 어댑터를 차례로 점검하세요. 기업 기기에서 관리되는 네트워크 정책을 사용하는 경우 관리자가 허용된 연결 방식을 확인해야 합니다.

Windows 방화벽: 아웃바운드 연결과 LAN 인바운드 구분

이 PC의 브라우저에서 로컬 프록시에 연결할 때 LAN 전체에 공개되는 인바운드 포트를 열 필요는 보통 없습니다. Windows 방화벽은 기본적으로 아웃바운드를 허용하는 경우가 많지만, 기업 정책이나 보안 소프트웨어에서 별도로 제한할 수 있습니다. 코어의 아웃바운드 연결, 서비스 프로그램, LAN 기기의 로컬 프록시 접근 중 무엇이 차단됐는지 먼저 확인하세요.

실제 프로그램과 네트워크 범위에 맞춰 허용

이 PC의 아웃바운드 연결이 차단됨: 보안 소프트웨어 기록을 확인하고 실제 연결을 시작한 코어 실행 파일의 경로를 확인하세요. GUI 프로그램만 허용하면 별도로 실행되는 코어는 허용되지 않을 수 있습니다.
클라이언트 업데이트 후 작동하지 않음: 프로그램 폴더나 실행 파일 경로가 바뀌었다면 기존 경로 기반 규칙을 갱신해야 할 수 있습니다.
LAN 공유가 필요함: 클라이언트의 LAN 허용 설정, 수신 주소, 인바운드 규칙을 모두 확인하세요. 방화벽 포트만 여는 것으로는 충분하지 않습니다.
공용 Wi-Fi 사용: 신뢰할 수 없는 네트워크에 프록시 수신 포트를 공개하지 마세요. 특히 ‘공용’ 네트워크 프로필의 연결을 함부로 허용하지 마세요.

세부 규칙을 확인하려면 Win + R을 누르고 wf.msc를 실행해 ‘고급 보안이 포함된 Windows Defender 방화벽’을 여세요. LAN 공유용 인바운드 규칙은 프로그램 또는 실제 포트, 개인 네트워크 프로필, 신뢰할 수 있는 원본 주소로 범위를 제한해야 합니다. 공유가 필요 없다면 allow-lan: false를 유지하세요.

UWP 앱과 포트 충돌: 서로 다른 문제

앱 컨테이너의 로컬 루프백 제한

일부 UWP 앱이나 앱 컨테이너 제한을 받는 프로그램은 로컬 루프백 프록시 사용에 제약이 있을 수 있습니다. 브라우저는 연결되지만 특정 앱만 인터넷에 연결되지 않는 증상이 나타날 수 있습니다. 하지만 Microsoft Store에서 설치한 프로그램이 모두 해당하는 것은 아니며, 스토어 앱의 연결 오류가 모두 루프백 제한 때문인 것도 아닙니다.

관리자 터미널에서 다음 명령을 실행해 현재 루프백 예외 목록을 확인할 수 있습니다. 상태만 표시하며 앱 설정을 변경하지 않습니다:

CheckNetIsolation.exe LoopbackExempt -s

예외를 추가해야 한다면 대상 앱의 패키지 패밀리 이름을 먼저 확인하고 앱별로 처리하세요. 모든 패키지에 일괄 예외를 적용하지 마세요. 클라이언트에 UWP 루프백 관리 기능이 있다면 로컬 프록시를 사용할 앱만 선택하세요. TUN으로 트래픽을 처리할 때는 경로가 다르므로 시스템 프록시 기준의 진단 결과를 그대로 적용할 수 없습니다.

7890 포트 충돌: 수신 프로세스부터 확인

로그에 address already in use 또는 바인딩 실패가 표시되면 터미널에서 아래 두 명령을 실행하세요. 두 번째 명령은 PID 4321을 예시로 사용합니다. 실제로 실행할 때는 첫 번째 명령의 출력에 표시된 PID로 바꾸세요.

netstat -ano -p tcp | findstr ":7890"
tasklist /FI "PID eq 4321"

로컬 주소의 포트가 7890이고 상태가 LISTENING인 항목을 확인하세요. 출력에는 원격 포트나 비슷한 숫자도 표시될 수 있으므로 한 줄만 보고 포트 충돌이라고 판단하지 마세요. 기존 클라이언트가 시스템 트레이에서 계속 실행 중이거나 백그라운드 서비스가 남아 있거나 새 클라이언트가 중복 실행 중일 수 있습니다.

해당 프로그램의 종료 기능이나 서비스 중지 기능으로 포트를 해제하세요. 이름을 알 수 없는 시스템 프로세스를 강제 종료하지 마세요. 사용 중이 아닌 포트(예: 7891)로 프록시 포트를 바꿀 수도 있지만 시스템 프록시와 프록시를 수동 설정한 앱도 함께 변경해야 합니다. YAML만 바꾸고 앱의 포트를 변경하지 않으면 연결이 거부됩니다.

설치 후 점검 및 시작 시 실행 설정

웹페이지 하나가 열리는 것만으로 설정이 완전하다고 볼 수 없습니다. 아래 순서로 점검하면 일반적인 재부팅 및 비정상 종료에서 자주 발생하는 문제를 확인할 수 있습니다.

규칙 점검: 규칙 모드를 유지하고 직접 연결해야 하는 대상과 프록시를 사용해야 하는 대상에 각각 접속한 뒤 연결 페이지에서 매칭된 규칙과 최종 정책을 확인하세요.
앱 점검: 브라우저만 테스트하지 말고 실제로 인터넷 연결이 필요한 앱도 개별적으로 실행하세요. 필요하다면 UDP 등 다른 연결도 확인하세요.
종료 점검: 시스템 프록시와 TUN을 끈 다음 클라이언트를 종료하고 기본 네트워크가 정상인지 확인하세요.
재부팅 점검: 시작 시 실행을 설정한 뒤 PC를 재부팅하고 클라이언트, 설정, 백그라운드 서비스가 예상대로 실행되는지 확인하세요.
업데이트 점검: 구독이나 코어를 업데이트한 뒤 설정 파싱, 포트, TUN 상태, 주요 규칙을 다시 확인하세요.

클라이언트의 시작 시 실행, 백그라운드 서비스의 자동 시작, 시스템 프록시 자동 활성화는 각각 별개의 설정입니다. Windows 11의 ‘설정’ → ‘앱’ → ‘시작 프로그램’에서는 일부 시작 항목만 확인할 수 있습니다. 백그라운드 서비스는 services.msc에서도 확인하세요. 시작 작업을 여러 개 만들면 프로세스가 중복 실행되고 포트 충돌이 생길 수 있으니 주의하세요.

문제 해결에 필요한 정보는 발생 시각, 클라이언트와 코어 버전, 오류 로그, 시스템 프록시와 TUN 상태입니다. 로그를 공개하기 전에 구독 토큰, 인증 정보, 노드 접속 정보를 삭제하세요. 기본 사용법은 사용 가이드에서 확인하고, 연결 문제는 자주 묻는 질문에서 더 살펴보세요.