Clash 자주 묻는 질문: 카테고리별로 증상부터 찾기
구독 가져오기, 노드 타임아웃, TUN 권한, 시스템 프록시처럼 반복적으로 질문받는 실제 상황에서 나온 18가지 고빈도 문답입니다. 각 항목마다 먼저 확인 방법을 제시하고 이어서 해결 절차를 안내합니다. 읽어도 해결되지 않는다면 본문에 표시된 튜토리얼과 문제 해결 심층 글 링크로 이동하세요.
기초 개념
용어부터 맞춰야 합니다. 설정, 구독, 코어 같은 단어가 헷갈리면 이후 단계마다 길을 잃기 쉽습니다.
Clash란 무엇인가요? 설정 파일, 구독, 노드는 각각 무엇을 의미하나요?
Clash는 규칙 기반 프록시 클라이언트를 통칭하는 이름으로, 핵심은 하나의 YAML 설정 파일입니다. 설정에서 가장 중요한 세 가지는 proxies(노드, 즉 사용 가능한 프록시 서버), proxy-groups(정책 그룹, 어떤 노드를 쓸지 결정), rules(규칙, 어떤 트래픽이 프록시를 거칠지 결정)입니다.
구독은 서비스 제공업체가 제공하는 URL로, 클라이언트가 주기적으로 가져와 위 설정을 자동으로 생성합니다. 한 가지만 기억하세요: 클라이언트는 껍데기일 뿐이며 동작은 전부 설정에 의해 결정됩니다. 각 필드의 자세한 의미는 개념 사전에서 확인하세요.
Clash for Windows 업데이트가 중단됐는데, 지금은 어떤 클라이언트를 써야 하나요?
원작자가 유지보수를 중단하고 저장소를 보관 처리해 신규 시스템과 신규 프로토콜에 더 이상 대응하지 않습니다. Windows에서 현재 주류 대안은 Clash Verge Rev와 FlClash로, 코어를 모두 mihomo로 교체해 지원 프로토콜이 더 폭넓고 기존 구독 대부분을 그대로 옮길 수 있습니다.
이미 Clash for Windows를 설치했다면 당분간 계속 써도 되지만, 프로토콜 인식 오류나 시스템 호환성 문제가 생기면 옛 클라이언트를 굳이 붙잡고 있을 필요 없이 바로 새 클라이언트로 바꾸면 됩니다. 다운로드 페이지에 플랫폼별로 현재 사용 가능한 클라이언트를 정리해 두었습니다.
오리지널 코어, Clash.Meta, mihomo는 서로 어떤 관계인가요?
세 이름은 하나의 발전 흐름입니다. 오리지널 Clash 코어가 출발점이며 개발이 중단됐고, Clash.Meta는 커뮤니티가 이를 기반으로 강화한 브랜치로 VLESS, Hysteria2 등 신규 프로토콜을 보완했습니다. 이후 Meta가 mihomo로 이름을 바꾸었고 현재 유일하게 활발히 유지보수되는 메인 라인입니다.
지금 다운로드하는 Clash Verge Rev, FlClash 등 클라이언트가 내장한 코어는 모두 mihomo입니다. 설정 필드는 하위 호환되므로 기존 설정은 대체로 그대로 실행됩니다. 코어 계열별 기능 차이 비교는 프로토콜 참고 자료에서 확인하세요.
규칙 모드, 글로벌 모드, 다이렉트 모드는 각각 언제 사용하나요?
규칙 모드(rule)는 일상적인 기본값입니다. 트래픽을 rules와 하나씩 대조해 일치하는 항목대로 처리하며, 직접 연결과 프록시가 서로 간섭하지 않습니다. 글로벌 모드(global)는 모든 트래픽을 하나의 출구로 몰아넣는 방식으로, 노드를 임시로 테스트하거나 규칙 오판이 뚜렷할 때만 짧게 사용합니다. 다이렉트 모드(direct)는 프록시를 잠시 끄되 클라이언트는 계속 실행 중인 상태와 같습니다.
글로벌 모드를 장기간 쓰면 트래픽이 낭비되고 국내 사이트 접속도 느려집니다. 평소에는 rule 모드로 고정하면 되며, 이 내용은 튜토리얼 2단계에서 더 자세히 다룹니다.
설치 설정
설치부터 구독 연결까지, 이 구간에서 문제가 가장 자주 몰립니다: 형식 불일치, 시스템 차단, 의존성 누락.
구독 링크를 가져왔는데 노드 목록이 비어 있어요. 어떻게 해야 하나요?
순서대로 세 가지를 확인하세요. 첫째, 구독이 만료됐거나 트래픽을 다 썼는지 — 서비스 제공업체 관리 페이지에서 상태를 확인합니다. 만료된 구독은 빈 내용을 반환하는 경우가 흔합니다. 둘째, 구독 형식이 클라이언트와 맞는지 — 일부 구독은 기본적으로 V2Ray 형식을 출력해 Clash 클라이언트가 인식하지 못하므로, 서비스 제공업체 안내에 따라 구독 링크 뒤에 Clash 파라미터를 추가하거나 구독 변환을 거쳐야 합니다. 셋째, 가져오기 방식 — 구독 페이지를 열어 복사한 웹 내용이 아니라 구독 URL 자체를 붙여넣었는지 확인하세요.
수정 후 클라이언트에서 구독을 한 번 수동으로 업데이트하고 결과를 확인합니다. 가져오기의 전체 절차는 튜토리얼 1단계에서 확인하세요.
Windows에서 Clash Verge Rev 설치 후 백화면이 뜨거나 WebView2 오류가 발생하나요?
Clash Verge Rev의 UI는 Microsoft WebView2 런타임에 의존합니다. Windows 11에는 기본 포함되어 있지만 일부 Windows 10과 경량 시스템에는 없어 실행 시 백화면이나 오류가 나타납니다. Microsoft 공식 사이트에서 WebView2 Evergreen 런타임을 다운로드해 설치한 뒤 다시 실행하면 됩니다.
또 다른 흔한 원인은 설치 경로에 특수 문자가 포함된 경우이니 기본 경로에 설치하는 것을 권장합니다. 설치 파일 선택부터 분기 검증까지 전체 흐름은 블로그 Windows에 Clash Verge Rev 설치하는 전체 과정에서 확인하세요.
macOS에서 클라이언트 실행 시 '확인되지 않은 개발자' 또는 '손상됨' 알림이 뜨나요?
이는 App Store를 거치지 않고 배포된 앱에 대한 Gatekeeper의 기본 차단이며, 설치 파일에 문제가 있다는 뜻은 아닙니다. 해결 방법: 시스템 설정 → 개인정보 보호 및 보안에서 차단 알림 아래 '그래도 열기'를 클릭합니다. '손상되어 휴지통으로 이동' 메시지가 뜨면 터미널에서 xattr -cr /Applications/앱이름.app을 실행해 격리 속성을 제거한 뒤 다시 엽니다.
또한 칩 아키텍처에 주의하세요. Apple Silicon과 Intel은 각각 맞는 버전의 설치 파일을 다운로드해야 하며, 다운로드 페이지 macOS 섹션에 각각 정리되어 있습니다.
클라이언트가 제 구독을 인식하지 못해요. '구독 변환'은 무엇인가요?
클라이언트마다 지원하는 형식이 다릅니다. Clash 계열은 YAML을, V2Ray 계열은 Base64 링크 목록을 사용합니다. 구독 변환은 서비스 제공업체가 준 링크를 목표 클라이언트가 인식하는 형식으로 바꿔주는 변환기 역할을 하며, 흔히 분기 규칙 템플릿도 함께 적용됩니다.
우선 서비스 제공업체에 Clash 전용 구독 주소를 요청하는 것이 가장 좋습니다. 대부분 제공업체가 지원합니다. 정말 없을 때만 변환 서비스를 사용하세요. 구독 링크에는 계정 정보가 포함되어 있으니 출처가 불분명한 온라인 변환 사이트에 제출하지 않도록 주의하세요. 클라이언트별 구독 형식 호환 여부는 프로토콜 참고 자료에서 확인하세요.
사용 팁
연결에 성공한 뒤에는 분기, 속도 측정, 공유 이 세 가지만 잘 정리해도 사용 경험이 크게 달라집니다.
사이트별로 다른 노드를 사용하게 하려면 어떻게 하나요?
'규칙 + 정책 그룹' 조합으로 처리합니다. rules의 각 규칙 출구는 정책 그룹을 지정할 수 있습니다. 스트리밍 도메인은 '스트리밍' 그룹으로, 일반 해외 트래픽은 '자동 선택' 그룹으로 지정하고, 클라이언트 화면에서 각 그룹에 노드를 선택해두면 규칙이 일치할 때 해당 그룹의 현재 선택으로 나가게 됩니다.
대부분의 구독에는 이런 그룹 구성이 이미 포함되어 있어 프록시 페이지에서 바로 전환할 수 있습니다. 직접 커스텀하려면 설정이나 클라이언트 규칙 설정에 DOMAIN-SUFFIX 규칙을 추가해 목표 그룹을 지정하세요. 규칙은 위에서 아래로 매칭되며 일치하면 즉시 중단되므로, 새 규칙은 MATCH 기본 규칙 앞에 추가해야 합니다.
url-test와 select 정책 그룹은 어떻게 다른가요?
select는 수동 그룹으로, 선택한 노드를 바꾸기 전까지 계속 사용합니다. url-test는 자동 그룹으로, 백그라운드에서 주기적으로 테스트 URL에 요청을 보내 지연이 가장 낮은 노드를 선택하고 끊기면 자동으로 전환합니다. 평소에는 두 계층을 조합하는 방식을 추천합니다 — 상위 select 그룹 안에 url-test 그룹을 '자동'이라는 옵션으로 넣어두고, 보통은 자동에 맡기다가 특정 상황에서만 수동으로 노드를 지정하세요.
자동으로 선택된 노드가 만족스럽지 않다면 테스트 간격(interval)과 허용 오차(tolerance)를 확인하세요. 허용 오차를 늘리면 지연이 비슷한 노드끼리 빈번하게 전환되는 것을 막을 수 있습니다.
노드 지연은 어떻게 측정하나요? 숫자는 무엇을 의미하나요?
클라이언트의 프록시 화면에는 모두 지연 테스트 버튼이 있습니다. 원리는 해당 노드를 통해 테스트 주소로 HTTP 요청을 보내 걸린 시간을 밀리초 단위로 기록하는 것입니다. 이 숫자는 '연결 수립 + 왕복 1회'를 반영할 뿐 다운로드 속도와는 다릅니다. 지연이 80ms인 노드도 대역폭이 작을 수 있고, 300ms인 노드가 영상 재생에서는 더 매끄러울 수 있습니다.
지연 값은 타임아웃이나 명백히 저하된 노드를 걸러내는 데 적합합니다. 노드를 고를 때는 지연이 안정적으로 유지되는지, 실제 사용 시 끊김이 없는지 두 가지를 확인하세요. 전체가 타임아웃으로 표시된다면 먼저 노드를 의심하지 말고, 아래 문제 해결 카테고리의 순서대로 확인하세요.
TV, 게임기가 컴퓨터의 프록시를 함께 사용하게 하려면 어떻게 하나요?
클라이언트에서 'LAN 연결 허용'(allow-lan)을 켜고, 컴퓨터의 LAN IP와 믹스 포트(보통 7890)를 확인합니다. TV나 게임기의 네트워크 설정에서 프록시 서버에는 컴퓨터 IP, 포트에는 7890을 입력하고 프로토콜은 HTTP로 선택합니다.
전제 조건: 두 기기가 같은 라우터에 연결돼 있어야 하고, 컴퓨터 방화벽이 해당 포트를 허용해야 합니다 — Windows에서는 처음 설정 시 방화벽 권한 창이 뜨는데 개인 네트워크에 체크하세요. 컴퓨터가 절전 모드에 들어가면 프록시도 끊기므로 장기간 사용 시 절전 모드를 꺼두는 것이 좋습니다.
구독은 수동으로 업데이트해야 하나요? 얼마나 자주 업데이트하는 게 적절한가요?
업데이트가 필요하지만 자주 할 필요는 없습니다. 서비스 제공업체가 노드 주소와 포트를 조정하는데, 로컬 구독을 업데이트하지 않으면 옛 노드 정보가 그대로 남아 노드가 하나씩 타임아웃되는 현상이 나타납니다. 주요 클라이언트는 대부분 구독 자동 업데이트를 지원하며 12~24시간 간격이면 충분합니다. 노드가 대량으로 이상 동작할 때는 구독을 수동으로 한 번 업데이트하는 것이 첫 번째 확인 절차입니다.
자동 업데이트 실패는 조용히 일어나는 경우가 많습니다. 클라이언트에서 구독의 '마지막 업데이트 시각'을 확인할 수 있으니, 문제 진단 시 먼저 이 시각을 확인하세요.
문제 해결
연결이 안 되거나, 적용되지 않거나, 켜지지 않는 문제는 모두 정해진 확인 순서가 있습니다. 순서를 건너뛰지 마세요.
문제 해결의 원칙: 한 번에 하나씩만 수정하고, 수정 즉시 확인하세요. 세 가지 설정을 동시에 바꾸면 해결돼도 무엇이 원인이었는지 알 수 없고, 오히려 나빠지면 되돌리기도 어렵습니다.
시스템 프록시를 켰는데 브라우저가 프록시를 거치지 않나요?
먼저 클라이언트의 '시스템 프록시' 스위치가 정말로 켜져 있는지 확인한 뒤 세 가지를 점검하세요. 첫째, 운영체제의 프록시 설정이 원래대로 되돌려졌는지 — Windows 설정 → 네트워크 및 인터넷 → 프록시에는 127.0.0.1과 클라이언트 포트가 표시돼야 하며, 일부 소프트웨어는 종료 시 이 값을 지워버립니다. 둘째, PAC 잔여 설정 — 이전에 다른 프록시 소프트웨어를 썼다면 '자동 구성 스크립트'가 이미 무효화된 주소를 가리키고 있을 수 있으니 비워두세요. 셋째, 브라우저 프록시 확장 프로그램이 시스템 설정보다 우선순위가 높으므로 확장 프로그램을 '시스템 프록시' 모드로 전환하세요.
항목별로 수정한 뒤 브라우저를 재시작해 확인합니다. 브라우저와 터미널 두 경로의 전체 진단은 블로그 시스템 프록시를 켰는데도 적용되지 않을 때에서 확인하세요.
노드가 전부 타임아웃될 때는 어떤 순서로 확인해야 하나요?
전체 타임아웃은 대부분 노드 자체 문제가 아닙니다. 순서대로 확인하세요: ①구독이 만료됐거나 트래픽을 다 썼는지(서비스 제공업체 관리 페이지에서 확인); ②로컬 시스템 시간이 정확한지 — 일부 프로토콜은 시간에 민감해 몇 분만 차이 나도 핸드셰이크에 실패하므로 자동 동기화를 켜세요; ③포트가 이미 사용 중인지 — 다른 프록시 소프트웨어가 7890을 점유하면 클라이언트 로그에 bind 실패 기록이 남습니다; ④코어와 프로토콜이 맞는지 — 구독에 Hysteria2, VLESS 같은 신규 프로토콜이 포함돼 있는데 클라이언트가 여전히 옛 코어라면 mihomo 코어 기반 클라이언트로 바꾸세요; ⑤휴대폰 테더링 등 다른 네트워크 환경으로 바꿔 재테스트해 로컬 네트워크 간섭을 배제하세요.
각 단계별 확인 방법과 처리법은 블로그 Clash 노드 전체 타임아웃 진단 순서에서 확인하세요.
TUN 모드가 켜지지 않고 권한 부족이라고 나와요?
TUN은 시스템에 가상 네트워크 카드를 생성해야 하므로 관리자/root 수준 권한이 반드시 필요합니다. Windows: Clash Verge Rev는 먼저 설정에서 '서비스 모드'를 설치하고 활성화한 뒤 시스템 서비스 권한을 부여받아야 TUN을 켤 수 있으며, 바로 켜면 실패합니다. macOS: 처음 켤 때 시스템 확장 프로그램이나 권한 확인 창이 뜨므로 시스템 설정에서 허용해야 합니다. Android: VpnService 권한 요청 창에서 반드시 허용을 눌러야 합니다.
켠 후에도 네트워크가 되지 않는다면 클라이언트가 권장하는 DNS 하이재킹 설정을 켰는지 확인하세요 — TUN 모드에서 DNS 설정이 잘못되면 인터넷이 끊기는 주된 원인이 됩니다. TUN과 시스템 프록시의 동작 방식 차이는 블로그 TUN 모드와 시스템 프록시의 차이점에서 확인하세요.
UWP 앱(Microsoft Store 앱)이 프록시를 거치지 않나요?
Windows는 UWP 앱에 네트워크 격리 메커니즘을 적용해 기본적으로 127.0.0.1 로컬 루프백 주소 접근을 차단하므로, 시스템 프록시가 스토어 버전 앱에는 적용되지 않습니다. 두 가지 해결책이 있습니다. 첫째, 클라이언트에 내장된 'UWP 루프백 해제' 도구를 사용합니다(Clash Verge Rev 설정에 진입점이 있음). 대상 앱에 체크해 제한을 해제할 수 있습니다. 둘째, TUN 모드를 직접 켜서 네트워크 계층에서 트래픽을 처리해 루프백 제한을 우회합니다.
같은 소프트웨어에 데스크톱 버전(win32)이 있다면 데스크톱 버전으로 바꿔 설치해도 이 제한을 피할 수 있습니다.
브라우저는 정상인데 터미널과 명령줄이 프록시를 거치지 않나요?
정상적인 현상입니다. 터미널의 명령은 시스템 프록시 설정을 읽지 않고 환경 변수만 인식합니다. 임시 해결책으로 현재 세션에서 export https_proxy=http://127.0.0.1:7890 http_proxy=http://127.0.0.1:7890 all_proxy=socks5://127.0.0.1:7890을 실행하세요(포트는 클라이언트의 실제 믹스 포트에 맞춰 수정). 장기적으로 적용하려면 셸 설정 파일에 작성해두면 됩니다. Windows PowerShell에서는 $env:https_proxy 문법을 사용합니다.
git, docker 같은 도구는 별도의 프록시 설정 항목이 있어 환경 변수를 인식하지 않는 경우 개별적으로 설정해야 한다는 점도 주의하세요. 두 경로에 대한 전체 비교는 블로그 시스템 프록시 진단 글에서 확인하세요.
다른 경로로 계속 찾아보기
자주 묻는 질문에서 다루지 않는 상황은 문제 성격에 따라 아래 페이지를 선택하세요: 설치는 튜토리얼, 선택 기준은 프로토콜 참고 자료, 용어는 개념 사전에서 확인하세요.