Clash 자주 묻는 질문

세 가지는 서로 다른 계층에 속합니다. Clash는 가장 초기의 오픈소스 프록시 코어 프로젝트이며, 원 저장소가 아카이브된 이후 커뮤니티 포크인 mihomo가 유지보수를 이어가고 있습니다. Clash Verge Rev, FlClash 등은 코어를 감싸는 GUI 클라이언트로, 화면, 구독 관리, 시스템 통합을 담당합니다. 흔히 말하는 「Clash 사용」은 대개 특정 GUI 클라이언트와 mihomo 코어의 조합을 가리킵니다.

각 프로젝트의 계승 관계와 플랫폼별 선택 가이드는 본 사이트 아티클 《Clash, mihomo, Verge Rev의 관계》를 참고하세요.

실행은 가능하지만 장기간 사용은 권장하지 않습니다. Clash for Windows는 업데이트가 중단되어 mihomo가 새로 추가한 프로토콜과 설정 필드를 반영하지 않으며, 새 형식의 구독을 파싱하지 못할 수 있고 보안 문제도 더 이상 수정되지 않습니다.

Windows 사용자는 Clash Plus나 Clash Verge Rev로 이전하는 것이 좋으며, 기존 구독 링크는 새 클라이언트에 다시 가져오기만 하면 되고 수정할 필요는 없습니다. 다운로드 페이지 Windows 영역에서 설치 파일을 받을 수 있습니다.

본 사이트에 소개된 모든 클라이언트와 mihomo 코어는 무료 오픈소스 소프트웨어이며, 다운로드와 사용에 어떠한 비용도 들지 않습니다.

다만 클라이언트는 도구일 뿐이며, 프록시 노드는 구독 서비스 제공업체가 제공하는 것이므로 노드 서비스의 유료 여부는 제공업체에 따라 다르고 클라이언트 자체와는 무관합니다.

규칙 모드(rule)는 설정 파일의 규칙을 순서대로 매칭해 다이렉트로 보낼 것은 다이렉트로, 프록시로 보낼 것은 프록시로 처리하는 일상 권장 모드입니다. 전역 모드(global)는 모든 트래픽을 선택한 노드로 보내며 규칙 문제 진단이나 임시 사용에 적합합니다. 다이렉트 모드(direct)는 모든 트래픽이 프록시를 거치지 않도록 합니다.

대부분의 경우 규칙 모드를 유지하면 되며, mode 필드의 구체적인 작성법은 설정 필드 레퍼런스를 참고하세요.

서비스 제공업체에서 https://로 시작하는 구독 주소를 복사한 뒤, 클라이언트의 설정(Profiles) 페이지를 열고 새 프로필의 주소란에 붙여넣고 확인하면 클라이언트가 자동으로 설정 파일을 다운로드하고 파싱합니다. 가져오기가 성공하면 프록시 페이지에서 노드 목록을 확인할 수 있습니다.

플랫폼별 상세 이미지 가이드는 사용 가이드에서 확인하세요.

이는 macOS가 App Store 외부 앱을 차단하는 Gatekeeper 메커니즘이며, 설치 파일에 문제가 있다는 의미는 아닙니다. Finder에서 앱 아이콘을 마우스 오른쪽 버튼(또는 Control 키를 누른 채)으로 클릭해 「열기」를 선택하면 처음 확인 후 정상적으로 실행됩니다. 또는 「시스템 설정 → 개인정보 보호 및 보안」 페이지 하단에서 「그래도 열기」를 클릭할 수도 있습니다.

TUN 모드는 가상 네트워크 카드를 생성해야 하므로 반드시 관리자 권한으로 실행해야 합니다. Clash Verge Rev는 설정에서 시스템 서비스(Service Mode)를 설치할 수 있어 이후에는 매번 수동으로 권한을 올릴 필요가 없습니다. 다른 클라이언트는 마우스 오른쪽 버튼으로 「관리자 권한으로 실행」을 선택하면 됩니다.

켠 후에는 DNS 하이재킹 관련 옵션도 함께 켜는 것을 권장합니다. 그렇지 않으면 일부 트래픽이 가상 네트워크 카드를 우회할 수 있습니다.

정상입니다. Android용 프록시 클라이언트는 시스템의 VpnService 인터페이스를 통해 트래픽을 처리하므로, 첫 실행 시 반드시 「VPN 연결 생성」 권한을 부여해야 합니다. 이는 시스템의 표준 메커니즘이며, 권한을 부여하면 상태 표시줄에 키 아이콘이 나타납니다.

만약 잘못 거부했다면 클라이언트 내에서 연결을 다시 시도하면 권한 요청 창이 다시 표시됩니다.

iOS 플랫폼에서는 Clash Plus를 추천합니다. App Store에서 바로 검색해 설치하거나, 공식 사이트 clashplus.io에서 스토어 링크를 확인할 수 있습니다. 설치 후 첫 실행 시에도 VPN 설정 권한을 부여해야 하며, 안내에 따라 시스템 설정에서 확인하면 됩니다.

스토어 링크는 본 사이트 다운로드 페이지의 iOS 영역에서도 찾을 수 있습니다.

클라이언트의 프록시 페이지에서 지연 테스트(번개 아이콘)를 클릭하면 클라이언트가 각 노드에 HTTP 프로브를 보내 밀리초 단위 수치를 표시합니다. 수치가 낮을수록 좋고, 타임아웃된 노드는 빨간색으로 표시됩니다.

자주 쓰는 노드를 url-test 유형의 정책 그룹에 넣으면 클라이언트가 지연이 가장 낮은 노드를 자동으로 선택해 수동 전환이 필요 없습니다.

설정 파일의 rules 섹션 맨 앞에 사용자 지정 규칙을 추가합니다. 예를 들어 DOMAIN-SUFFIX,example.com,노드 또는 정책 그룹명 형식입니다. 규칙은 위에서 아래로 순서대로 매칭되며 먼저 매칭된 것이 먼저 적용되므로, 사용자 지정 항목은 구독에 포함된 규칙보다 앞에 배치해야 하며, 그렇지 않으면 앞쪽의 와일드카드 규칙에 가로채일 수 있습니다.

문법과 우선순위는 설정 필드 레퍼런스와 아티클 《Clash 사용자 지정 규칙 작성법》에서 확인하세요.

서비스 제공업체는 부정기적으로 노드를 조정하므로 정기적으로 구독을 업데이트해 최신 노드 목록을 받는 것이 좋습니다. 주요 클라이언트는 대부분 자동 업데이트 간격 설정(예: 24시간마다)을 지원하며, 설정 페이지에서 수동으로 새로고침 버튼을 클릭할 수도 있습니다.

업데이트 후 노드가 대폭 변경되면 사용자 지정 규칙에서 참조하는 정책 그룹 이름이 여전히 존재하는지 확인하세요. 존재하지 않는 그룹을 참조하면 코어 시작이 실패할 수 있습니다.

가능합니다. 규칙 모드 자체가 도메인과 IP 기준으로 트래픽을 분산합니다. 앱 단위로 제어하려면 Android 클라이언트는 대체로 앱별 프록시를 지원하므로 설정에서 특정 앱을 선택하거나 제외하면 됩니다.

데스크톱에서는 PROCESS-NAME 규칙으로 프로세스명 기준 분산이 가능하며, 이 규칙은 TUN 모드에서 가장 완전하게 매칭됩니다.

순서대로 확인하세요: 클라이언트의 「시스템 프록시」 스위치가 실제로 켜져 있는지, 시스템 프록시 포트와 클라이언트의 믹스드 포트가 일치하는지(기본값 7890), 브라우저에 SwitchyOmega 같은 프록시 확장이 설치되어 시스템 설정을 덮어쓰고 있는지 확인합니다.

일부 소프트웨어는 시스템 프록시를 읽지 않으므로 해당 설정에서 직접 127.0.0.1:7890을 입력하거나 TUN 모드로 전체 트래픽을 처리하도록 전환해야 합니다.

UWP 앱은 기본적으로 시스템에 의해 로컬 루프백 주소 127.0.0.1 접근이 차단되어 있어 시스템 프록시가 적용되지 않습니다. 해결 방법: CheckNetIsolation 명령으로 해당 앱에 루프백 예외를 추가하거나, 클라이언트에 내장된 UWP 루프백 해제 도구를 사용해 대상 앱을 체크한 뒤 저장하면 됩니다.

메커니즘 설명과 단계별 조작은 아티클 《Windows 스토어 앱이 프록시를 거치지 않는 이유》에서 확인하세요.

리스닝 포트(보통 7890)가 다른 프로세스에 점유되어 있다는 뜻이며, 프록시 클라이언트를 동시에 두 개 실행했거나 이전 프로세스가 종료되지 않고 남아 있을 때 흔히 발생합니다. Windows는 netstat -ano와 작업 관리자를 함께 사용해 점유 프로세스를 찾고, macOS와 Linux는 lsof -i:7890을 사용합니다. 점유 프로세스를 종료하거나 설정에서 mixed-port를 다른 비어 있는 포트로 변경하세요.

전체 진단 과정은 아티클 《Clash 포트 점유 오류 해결법》에서 확인하세요.

순서대로 확인하세요: 구독이 만료되었거나 트래픽이 소진되었는지 서비스 제공업체 백엔드에서 확인, 로컬 시스템 시간이 정확한지(편차가 크면 핸드셰이크 실패 발생), 전역 모드로 전환해 개별 노드를 테스트해 규칙 설정의 간섭을 배제합니다.

일부 노드만 정상이고 대다수가 타임아웃되면 대개 제공업체 측 노드 장애이므로 복구를 기다리거나 구독을 업데이트하세요.

인증서 오류가 반드시 웹사이트 문제인 것은 아닙니다. 먼저 시스템 시간이 정확한지 확인하고, Fiddler나 Charles 같은 패킷 캡처 도구의 루트 인증서가 남아 있는지 확인하세요. 다른 노드로 바꿔 시도해보고, 특정 노드에서만 오류가 발생한다면 해당 경로에 중간자 공격 위험이 있음을 의미하므로 즉시 해당 노드 사용을 중단하고 제공업체에 신고해야 합니다.

각 원인별 판단 방법은 아티클 《프록시 사용 후 HTTPS 인증서 오류의 여러 원인》에서 확인하세요.