Win11에서 Clash for Windows를 고르는 검색 의도

Windows 11에서 프록시 앱을 처음 쓸 때 많이 나오는 요구는 단순합니다. 트레이 아이콘 하나로 켜고 끄고, 주소 한 줄(구독 URL)만 넣으면 노드 목록이 채워지고, 브라우저 검색 결과가 바뀌는지 바로 확인하고 싶다는 것입니다. Clash for Windows는 그 전형을 만든 그래픽 클라이언트라는 점에서 여전히 검색량이 큽니다. 메뉴 이름은 버전·포크마다 조금씩 다르지만, 화면 곳곳에 남아 있는 Profiles, Proxies, General 같은 영문 탭 패턴 덕분에 예전 튜토리얼을 역으로 따라가기도 쉽습니다.

같은 사이트에는 이미 Clash Verge Rev나 Mihomo Party처럼 최신 코어를 전제로 한 Windows 11 설치 글이 있을 수 있습니다. 역할을 나누어 보면, Verge·Party 쪽이 mihomo·Meta 문법 최적화와 코어 교체 UX에 강하다면, CfW 길은 “옛 YAML을 그대로 열어보는 호환 루트”에 가깝습니다. 클라이언트 갈래 선택은 클라이언트 선택 가이드를 보고, Win11에서 TUN까지 확장하려면 Windows 11용 Verge Rev 글·Mihomo Party Win11 글과 교차하는 편이 빠릅니다.

유지보수 종료와 배포본·보안을 먼저 읽는 이유

커뮤니티에 널리 알려진 바와 같이 Clash for Windows의 원 저장소 기준 개발은 멈춘 지 오래입니다. 그렇다고 해서 설명 자체가 무의미해지는 것은 아니지만, 첫 실행 튜토리얼을 읽는 입장에서는 전제가 달라집니다. 공식 빌드가 끊긴 뒤에는 제3의 “재패키지”가 돌아다니기 쉬우므로, 실행 파일 해시·서명·다운로드 경로를 스스로 검증하지 않은 상태로 관리자 권한 설치를 진행하면 위험합니다. 회사 PC라면 보안팀 승인 경로 밖에서 설치 시도 자체가 규정 위반이 될 수 있습니다.

또 한 가지, 최신 공급자 구독이 Clash Meta 전용 문법에만 맞춰져 있으면 구형 코어를 쓰는 빌드에서는 YAML 파싱 단계에서 막히는 일이 잦습니다. 이때는 클라이언트 설명이 부족해서가 아니라 “도구 세대”가 맞지 않는 경우가 많으니, 아래 호환 절을 먼저 읽고 분기하는 편이 시간을 아낍니다.

⚠ 주의: 더 이상 보안 패치를 기대하기 어려운 앱을 일상 업무에 고정하는 것은 권장되지 않습니다. 이 글은 검색 의도에 맞춘 재현 순서이며, 장기 운용은 최신 포크·대체 클라이언트를 검토하세요.

설치 전: 권한·SmartScreen·다른 터널 정리

Windows 11에서도 설치 프로그램이 시스템 폴더에 쓰면 UAC 확인이 뜹니다. 다음으로 Microsoft Defender SmartScreen이나 백신이 실행 파일을 막으면, 출처를 확인한 뒤에만 예외를 허용해야 합니다. 상용 VPN, 기업 터널, 다른 로컬 프록시가 동시에 켜져 있으면 포트·라우팅표가 반만 적용되는 패턴이 흔하므로, 첫 검증 구간에서는 한 줄기만 남깁니다.

구독 URL은 유출 시 남용되기 쉽습니다. 복사 과정에서 앞뒤 공백·숨은 줄바꿈이 들어가 HTTP 403이 나는 경우도 있으니, 문자열 검증 순서는 구독 갱신 실패 안내와 같은 흐름으로 맞춰 두면 이후에 같은 패턴을 빠르게 찾습니다.

다운로드와 첫 실행, 방화벽 프롬프트

버전 문자열을 이 글에서 고정하지는 않습니다. 대신 패턴만 적습니다. .exe 설치 프로그램 실행 → 사용권 동의 → 설치 경로 선택 → 완료 후 트레이에서 아이콘 실행입니다. 사내에서 GitHub이 막혀 있으면 승인된 미러나 자체 아카이브만 따라야 하며, 그 경로의 무결성도 같이 적어두는 것이 좋습니다.

처음 띄웠을 때 Windows Defender 방화벽이 뜨면 사설·공용 프로필을 구분하고 불필요하게 광범위하게 “모든 네트워크 허용”만 누르지 않습니다. 설치 직후 대시보드에서 코어가 실제로 기동했는지, 오류 배너가 없는지부터 확인합니다. 회색 상태가 길면 바로 로그 탭으로 넘어가 UTF-8 인코딩이 깨진 경로나 차단된 DLL 같은 힌트가 없는지 봅니다.

구독 가져오기와 프로필 갱신 루프

대부분의 흐름은 동일합니다. 공급자가 준 구독 URL을 복사해 클라이언트의 “다운로드·가져오기·URL” 입력란에 붙이고 갱신 버튼을 누릅니다. 레이블이 언어별로 달라도 결과는 하나입니다. 원격 서버가 내려 주는 YAML이 로컬 프로필로 저장되고, 노드·그룹 이름이 채워집니다. 자동 업데이트 주기가 너무 짧으면 429나 캐시 문제로 막히기도 하니 제공자 안내 간격에 맞추는 편이 낫습니다.

실패가 반복될 때 순서를 지키면 빨리 좁혀집니다. 브라우저에서 같은 URL이 열리는지, 프록시 끈 상태에서 열리는지, 회사 DNS가 NXDOMAIN을 내는지입니다. 상태 코드별로는 404·403 정리 글, 운영 습관은 구독 유지 보수 가이드를 같이 두면 좋습니다.

프로필이 들어오면 규칙과 정책 그룹이 따라옵니다. 우선순위 해석에는 규칙 라우팅 모범이 도움이 됩니다. 그룹 표시 이름이 화려해도 실제로는 “자동 지연”, “수동 고정”, “규칙에 따름” 정도로 읽어도 충분합니다.

프로필 문법과 코어 호환·Meta-only 구독

CfW라는 이름이 오래 됐다고 해서 모든 구독이 같은 해석기를 쓰는 것은 아닙니다. 공급자가 최신 Clash Meta 기능만 쓰는 YAML을 내려 주면 구형 clash 프리미엄 계열 해석기에서는 필드 하나가 발목을 잡습니다. 오류 대화 상자에 줄 번호가 찍히면 그 한 줄을 통 문자열로 검색해 릴리스 노트·FAQ와 맞춰 보세요.

같은 URL을 Mihomo Party나 Verge Rev에서 열었을 때만 정상이라면, 문제는 노드 품질이 아니라 문법 세대입니다. 이때는 그래픽 스킨을 고집하기보다 코어 세대를 맞추는 쪽이 비용 대비 효과가 큽니다.

ℹ 메모: “업데이트만 눌렀는데 갑자기 안 열린다”는 문의는 대부분 공급자 쪽 프로필 변경과 클라이언트 해석기 차이가 동시에 온 경우입니다. 롤백 대신 다른 세대 클라이언트로 열어보는 실험이 더 빠를 때가 많습니다.

규칙·글로벌·직연결과 정책 그룹

처음에는 규칙 모드를 기본으로 두는 경우가 많습니다. 국내 트래픽은 직행·해외만 터널로 보내는 구조가 체감 속도와 비용에 유리하기 때문입니다. 장애 분석을 위해 한시적으로 글로벌 모드와 직연결을 오가며 “규칙이 놓친 도메인인지, 노드 자체가 불안한지”를 분리하면 로그 읽기가 쉬워집니다.

Proxies 화면에서 지연 숫자가 보이더라도 한 번의 핑만 보지 말고, 실제로 쓰는 사이트를 짧게 여러 번 새로 고침하며 TLS 완료까지 안정적인지 봅니다.

대용량 동기화나 긴 영상 테스트는 별도 시간대에 잡아두면 “평소엔 되는데 특정 패턴만 끊긴다”는 보고를 줄일 수 있습니다.

mixed-port 번호 확인과 시스템 프록시

많은 사용자에게 첫 실행 성공의 기준은 시스템 프록시를 켠 뒤 브라우저 결과가 바뀌는 순간입니다. 설정 화면 어딘가에 System Proxy 토글이 있고, 켠 직후 Windows의 설정 → 네트워크 및 인터넷 → 프록시에 표시된 주소·포트 숫자가 앱에 적힌 값과 같은지 비교해 보세요. 숫자가 어긋나면 “앱에서는 켰는데 OS는 아니다” 패턴을 바로 분리할 수 있습니다.

터미널·일부 개발 도구는 OS 프록시를 무시합니다. 이때는 설정에 표시된 mixed-port(또는 별도 HTTP·SOCKS 표시)를 환경 변수나 앱별 설정으로 직접 넣습니다. 포트가 이미 다른 프로세스에 잡혀 있으면 포트 충돌 실측 글 순서로 점유 프로세스를 찾습니다.

예: PowerShell 세션에만 HTTP 프록시를 지정합니다(포트는 화면 표시값으로 바꿉니다). 
$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
⚠ 주의: 사용자 환경 변수에 영구 저장해 두면 프록시를 꺼도 일부 도구가 옛 번호를 붙잡습니다. 테스트 후에는 세션을 닫거나 변수를 지웁니다.

첫 실행 검증: 브라우저·포트 충돌·로그

크롬·엣지에서 기대한 지역의 검색·뉴스가 안정적으로 뜨면 1차 성공입니다. 가능하면 IP 정보 페이지를 열어 ASN이 기대 범위인지 확인합니다. 이어서 앱의 연결 로그에서 TLS 핸드셰이크 실패나 반복 타임아웃 문구가 없는지 봅니다. 패턴 매칭 순서는 타임아웃·TLS 로그 가이드가 정리해 줍니다.

PowerShell의 Invoke-WebRequest는 에디션마다 시스템 프록시를 다루다 달라서 브라우저와 결과가 어긋나도 당황하지 말고 $env: 직지정 여부를 먼저 확인합니다. 이름만 깨지면 터널은 살아 있어도 페이지가 열리지 않을 수 있으니 DNS 관련 항목은 FAQ와 대조합니다. 브라우저 한정 증상이면 WebRTC 누출이나 확장 프로그램 개입도 의심합니다.

Win11에서 자주 걸리는 증상

TUN·가상 어댑터 경로로 확장할 때는 드라이버 허용 UI 순서가 중요합니다. 개념 정리는 TUN 심화를 먼저 읽어 두면 “왜 브라우저만 된다고 느꼈는지”가 분명해집니다. 회사 장비에서는 시작부터 막히는 경우가 많으니 정책 확인이 선행입니다.

종료 후에도 인터넷이 돌아오지 않으면 시스템 프록시 잔류 가능성을 봅니다. 순서 안내는 종료 후 인터넷 복구 글과 함께 검토하세요.

자주 묻는 질문

Clash for Windows에서 구독을 받았는데 프로필 오류가 날 때는요?

먼저 오류 줄이 가리키는 필드가 현재 바이너리가 이해하는 키인지 확인합니다. 공급자가 Meta 전용 키만 남겼다면 구세대 클라이언트는 그대로 열리지 않습니다. 같은 URL을 최신 mihomo 계열 앱에서 열어 비교하면 원인 분리가 빨라집니다.

시스템 프록시를 켰는데 브라우저만 되고 다른 앱은 왜 그대로인가요?

WinHTTP 우회·자체 TLS 스택 때문에 생깁니다. 해당 앱에 표시 포트를 직접 넣거나, 게임 런처처럼 규칙 밖으로 새는 경우 TUN·프로세스 규칙 쪽을 다음 단계로 넘깁니다.

Clash for Windows는 더 이상 업데이트되지 않는다고 들었습니다. 그래도 써도 되나요?

교육·재현·짧은 테스트에는 의미가 있지만, 일상의 주력 클라이언트로는 보안과 호환성 리스크가 큽니다. 장기적으로는 Verge·Party·다른 활발한 포크로 옮기는 계획을 권합니다.

맺음말

그래픽 클라이언트 이름은 바뀌어도 실제 작업은 같은 질문으로 돌아옵니다. 구독 URL이 정상 갱신되는지, 선택한 노드와 규칙 모드 매치가 의도한 결과인지, mixed-port와 시스템 프록시 숫자가 서로 맞는지, 마지막으로 프로필 문법이 실행 중인 코어 세대와 맞는지. 이 네 가지가 흔들리면 화면이 비슷해도 문서 검색 시간만 길어집니다.

다만 Clash for Windows는 더 이상 최전선에서 따라올 수 있는 제품이라기보다 과거 생태계를 열었던 고전형 UI에 가깝습니다. 새 구독이 Meta·mihomo 중심으로만 제공되는 시대에는 설치 튜토리얼만 무한히 붙잡고 있기보다, 같은 검증 순서를 유지한 채 Clash Verge Rev·Mihomo Party처럼 코어를 교체하기 쉬운 쪽으로 옮기는 편이 운영 비용이 낮습니다. 이름이 달라도 구독 새로 고침·모드 전환·로그 패턴은 상당 부분 재사용됩니다.

이런 맥락에서 Clash V.CORE는 배포·문서·버전 확인을 한 도메인 안에 묶어 “재현 가능한 설치 경로와 로그 줄 읽기”를 잃지 않게 하려는 쪽에 가깝습니다. 클래식 CfW로 Win11 첫 실행만 확인했다 해도, 다음 단계의 TUN·분할 라우팅·구독 장애 대응 글까지 같은 사이트에서 이어 읽을 수 있으면 전환 비용이 줄어듭니다. 지금 패키지를 받아 같은 순서로 확인하려면 Clash V.CORE 다운로드 페이지를 기준으로 두는 편이 낫습니다.