BASICS · 기본 개념
먼저 알아둘 개념들
Clash는 어떤 소프트웨어인가요? mihomo 커널과는 어떤 관계인가요?
Clash는 규칙 기반 네트워크 프록시 도구를 통칭하는 명칭입니다. 원조 Clash 커널은 유지보수가 중단되었고, 현재 커뮤니티 주류 클라이언트는 대부분 mihomo(구 Clash Meta) 커널을 내장하고 있습니다. mihomo는 기존 설정 형식과 호환되면서 더 많은 프로토콜과 규칙 유형을 확장 지원합니다. 흔히 말하는 'Clash 다운로드'는 실제로 Clash Plus, Clash Verge Rev, FlClash 같은 그래픽 인터페이스 클라이언트를 내려받는 것으로, 커널은 클라이언트에 이미 포함되어 있어 별도로 설치할 필요가 없습니다.
Clash Plus, Clash Verge Rev, FlClash 클라이언트는 어떤 차이가 있고 어떻게 선택해야 하나요?
핵심 기능은 동일합니다: 구독 가져오기, 규칙 기반 트래픽 분배, 노드 전환. 차이는 주로 인터페이스와 지원 플랫폼에 있습니다. Clash Plus는 Windows, macOS, Android, iOS를 모두 지원해 각 플랫폼에서 가장 먼저 추천되는 선택이고, Clash Verge Rev는 데스크톱용으로 설정 항목이 풍부해 세밀한 제어가 필요한 상급 사용자에게 적합하며, FlClash는 인터페이스가 간결하고 플랫폼 간 일관성이 높습니다. 자신의 운영체제에 맞춰 다운로드 페이지의 해당 항목을 선택하면 되고, 같은 구독은 여러 클라이언트에서 공통으로 사용할 수 있습니다.
규칙 모드, 글로벌 모드, 다이렉트 모드는 각각 어떤 상황에서 사용하나요?
규칙 모드는 설정 파일의 rules 항목을 기준으로 트래픽을 하나씩 매칭해, 일반 웹사이트는 다이렉트로 연결하고 나머지는 정책 그룹에 따라 전달하는 방식으로 일상적으로 권장되는 모드입니다. 글로벌 모드는 모든 트래픽을 프록시를 통해 전달하며, 규칙 설정 문제를 임시로 점검하거나 전체 구간에서 프록시가 필요한 서비스에 적합합니다. 다이렉트 모드는 프록시를 전혀 사용하지 않아, 클라이언트를 종료하지 않고도 트래픽 분배를 임시로 끄는 것과 같은 효과를 냅니다. 전환 메뉴는 보통 클라이언트 메인 화면의 '프록시 모드' 또는 '아웃바운드 모드'에 있으며, 전환 즉시 적용됩니다.
Clash 사용에는 비용이 드나요? 구독이란 무엇이고 어디서 얻을 수 있나요?
클라이언트와 커널 모두 오픈소스 소프트웨어로 무료로 사용할 수 있습니다. 다만 클라이언트 자체는 노드를 제공하지 않으므로, 노드 서비스 제공업체에서 구독 링크를 받아야 합니다. 구독은 하나의 URL이며 클라이언트에 가져오면 노드 목록과 트래픽 분배 규칙이 자동으로 생성되는데, 이는 보통 유료 서비스입니다. 노드의 속도, 안정성, 만료 시점은 구독 제공업체가 결정하며 클라이언트 소프트웨어 자체와는 무관합니다. 클라이언트는 규칙에 따라 이 노드들을 조율하는 역할만 합니다.
INSTALL · 설치 설정
설치, 권한 승인, 구독 가져오기
Windows에서 설치 후 시스템 프록시를 켜는 방법은?
클라이언트를 설치하고 구독을 가져온 뒤 클라이언트 설정에서 「시스템 프록시」 스위치를 켜면, 클라이언트가 127.0.0.1:7890(기본 혼합 포트)을 Windows 시스템 프록시 설정에 기록하고, 시스템 프록시를 따르는 브라우저 등의 앱은 즉시 자동으로 적용됩니다. 일부 앱은 시스템 프록시를 읽지 않으므로(많은 명령줄 도구와 게임 등) 이들까지 포괄하려면 TUN 모드를 켜야 합니다. 전체 단계별 방법은 본 사이트 사용 가이드 페이지를 참고하세요.
macOS에서 「손상되어 열 수 없음」 또는 「개발자를 확인할 수 없음」 메시지가 뜨면 어떻게 하나요?
이는 macOS Gatekeeper가 공증되지 않은 앱을 기본적으로 차단하는 것으로, 설치 파일 자체에 문제가 있다는 의미는 아닙니다. 먼저 「시스템 설정 → 개인정보 보호 및 보안」 페이지 하단에서 차단된 앱을 찾아 「그래도 열기」를 클릭하세요. 손상되어 수리할 수 없다는 메시지가 뜨면 터미널에서 xattr -cr /Applications/클라이언트이름.app 명령을 실행해 격리 속성을 제거한 뒤 다시 열면 됩니다. 명령의 경로는 실제 설치 위치에 맞게 수정하세요. 이 작업 후에도 첫 실행 시 한 번 더 확인 요청이 뜨는 것은 정상적인 과정입니다.
구독 링크를 클라이언트에 가져오는 방법은? 가져오기 성공의 신호는 무엇인가요?
구독 제공업체가 준 전체 URL을 복사해, 클라이언트의 「설정」 또는 「구독」 페이지에서 「URL로 가져오기」를 선택하고 붙여넣은 뒤 확인하면 클라이언트가 설정을 내려받아 분석합니다. 가져오기 성공의 신호는 설정 목록에 새 항목이 나타나고 프록시 페이지에 노드 그룹과 노드 목록이 표시되는 것입니다. 목록이 비어 있거나 오류가 나면 먼저 링크가 메신저에서 잘렸는지, 불필요한 공백이 포함되었는지 확인하세요. 일부 클라이언트는 QR코드로 가져오기나 로컬 YAML 파일에서 가져오기도 지원합니다.
TUN 모드를 켤 때 관리자 권한이 필요하다거나 서비스 설치가 실패한다고 나오면 어떻게 하나요?
TUN 모드는 가상 네트워크 카드를 생성해야 하므로 시스템 수준의 권한이 반드시 필요합니다. Windows에서는 관리자 권한으로 클라이언트를 실행하거나 클라이언트 안내에 따라 시스템 서비스 구성 요소를 설치하세요. macOS에서는 처음 켤 때 인증 요청이 뜨며 로그인 비밀번호 입력으로 확인해야 합니다. Linux에서는 커널 파일에 CAP_NET_ADMIN 권한을 부여하거나 root로 실행해야 합니다. 인증을 완료한 뒤 클라이언트를 재시작하고 TUN 스위치를 다시 켜세요. 서비스 설치가 계속 실패하면 보안 소프트웨어가 드라이버 설치를 차단하고 있는지 확인하세요.
Android에서 처음 연결할 때 VPN 연결 요청 창이 뜨는데, 동의해야 하나요?
동의해야 합니다. Android 클라이언트는 시스템 VpnService 인터페이스를 통해 기기 트래픽을 관리하며, 처음 연결 버튼을 누르면 「VPN 연결을 설정하려고 합니다」라는 시스템 대화상자가 뜹니다. 「확인」을 선택해야 로컬 가상 터널이 생성됩니다. 이 터널은 오직 로컬 클라이언트에만 연결되며, 클라이언트가 설정한 규칙에 따라 각 트래픽을 다이렉트로 보낼지 전달할지 결정합니다. 원격 VPN 서버에 연결되는 것이 아닙니다. 잘못해서 거부를 누른 경우, 연결 버튼을 다시 누르면 인증 요청이 다시 표시됩니다.
USAGE · 사용 팁
일상에서 유용한 몇 가지 조작
정책 그룹의 url-test, fallback, 수동 선택은 각각 어떤 상황에 적합한가요?
url-test 유형은 그룹 내 노드의 속도를 주기적으로 측정해 지연이 가장 낮은 노드를 자동으로 선택하므로 일상적인 사용에 적합합니다. fallback은 목록 순서대로 가용성을 확인해, 우선 노드에 장애가 생기면 다음 노드로 자동 전환하므로 주 노드와 백업 노드가 명확한 상황에 적합합니다. 수동 선택은 사용자가 노드를 직접 지정하는 방식으로, 특정 지역 출구가 필요한 서비스(예: 특정 지역 제한 콘텐츠)에 적합합니다. 세 가지 유형의 동작 원리와 핵심 파라미터는 본 사이트 블로그의 전문 글에서 하나씩 다루고 있습니다.
특정 웹사이트나 앱이 프록시를 거치지 않게 하는 방법은?
규칙 모드에서는 설정 파일의 rules 항목이 트래픽 분배를 결정합니다. 대상 도메인에 DOMAIN-SUFFIX 규칙을, 대상 네트워크 대역에 IP-CIDR 규칙을 추가하고 아웃바운드를 DIRECT로 설정하면 다이렉트 연결이 됩니다. 일부 클라이언트는 그래픽 인터페이스로 규칙 오버라이드나 우회 목록을 제공해 YAML을 직접 수정할 필요가 없습니다. 시스템 프록시 차원에서도 운영체제의 프록시 예외 목록에 프록시를 거치지 않을 주소를 입력할 수 있습니다. 규칙을 변경한 뒤에는 반드시 설정을 다시 불러와 적용하세요.
구독은 자동으로 업데이트되나요? 얼마나 자주 업데이트하는 것이 적절한가요?
주요 클라이언트는 구독마다 자동 업데이트 주기를 설정할 수 있으며, 흔히 24시간마다 한 번 받아오는 방식을 사용합니다. 설정 목록에서 언제든 수동으로 업데이트 버튼을 눌러도 됩니다. 자동 업데이트를 켜두는 것을 권장하는데, 구독 제공업체가 노드 주소를 변경했는데도 로컬에 예전 목록이 남아 있으면 대량의 노드 타임아웃이 발생할 수 있기 때문입니다. 특정 업데이트가 실패하면 클라이언트는 보통 이전에 캐시된 설정을 계속 사용하므로 현재 연결에는 영향이 없습니다.
터미널과 명령줄 프로그램이 시스템 프록시를 거치지 않는데, 어떻게 설정하나요?
대부분의 명령줄 도구는 시스템 프록시를 읽지 않으므로 환경 변수를 직접 설정해야 합니다: export https_proxy=http://127.0.0.1:7890 http_proxy=http://127.0.0.1:7890, 포트는 클라이언트의 실제 혼합 포트에 맞게 입력하세요. 이 설정은 현재 터미널 세션에만 적용되며, shell 설정 파일에 작성하면 계속 유지됩니다. 하나씩 설정하고 싶지 않다면 TUN 모드를 켜서 네트워크 계층에서 모든 프로세스의 트래픽을 관리할 수 있고, 이 경우 명령줄 도구를 따로 수정할 필요가 없습니다.
TROUBLE · 문제 해결
연결 안 될 때, 오류 발생 시 순서대로 확인
구독 업데이트나 파싱이 실패하면 어떤 순서로 점검해야 하나요?
먼저 브라우저에서 구독 링크를 직접 열어 내용이 정상적으로 반환되고 만료 안내 페이지가 아닌지 확인하세요. 이어서 다음을 순서대로 확인합니다: 링크가 잘리지 않고 완전한지, 시스템 시간이 정확한지, 구독 주소에 접속하려면 프록시가 필요한지(필요하다면 임시로 다이렉트로 전환한 뒤 업데이트하거나 반대로 시도). 링크는 열리지만 클라이언트에서 파싱 오류가 나면 대부분 반환 형식이 호환되지 않는 경우이므로, 구독 제공업체에 Clash 형식 구독을 제공하는지 문의해야 합니다. 본 사이트 블로그에 항목별 자가진단 체크리스트가 있어 그대로 따라 확인할 수 있습니다.
노드가 전부 타임아웃되면 어떻게 점검하나요?
다음 다섯 가지를 순서대로 확인하세요: 로컬 네트워크가 정상인지(프록시를 끄면 정상적으로 인터넷이 되는지), 구독이 만료되지 않았고 트래픽이 남아 있는지, 클라이언트의 지연 시간 테스트 URL 자체가 사용 가능한지, 구독을 한 번 수동으로 업데이트해 최신 노드 주소를 받았는지, 임시로 글로벌 모드로 전환해 단일 노드를 직접 선택해 규칙 오설정 여부를 배제했는지. 일부 노드는 사용 가능하지만 대부분 타임아웃된다면 보통 서버 측 문제이므로 구독 제공업체에 문의해야 하며, 클라이언트 측에서는 해결할 수 없습니다.
시스템 프록시를 켰는데도 브라우저 트래픽이 프록시를 거치지 않나요?
먼저 브라우저에 프록시 관련 확장 프로그램이 설치되어 있는지 확인하세요. 확장 프로그램의 프록시 설정이 시스템 설정을 덮어쓸 수 있습니다. 그다음 시스템 프록시가 가리키는 포트와 클라이언트가 수신하는 포트(기본 7890)가 일치하는지 확인하세요. 클라이언트에서 포트를 바꿨는데 시스템 설정이 동기화되지 않은 경우가 흔한 원인입니다. 일부 브라우저는 재시작해야 새 프록시 설정을 읽어옵니다. 또한 Firefox는 기본적으로 자체 독립 프록시 설정을 사용하므로, 네트워크 설정에서 「시스템 프록시 설정 사용」으로 변경해야 합니다.
Windows 마이크로소프트 스토어 앱(UWP)이 프록시를 켜도 인터넷에 연결되지 않나요?
UWP 앱은 기본적으로 시스템에 의해 로컬 루프백 주소 연결이 차단되므로, 시스템 프록시가 127.0.0.1을 가리키더라도 앱의 요청은 격리되어 차단됩니다. 해결 방법은 두 가지입니다. 하나는 클라이언트에 내장된 「UWP 루프백 예외」 도구(일부 클라이언트에서 제공)를 사용해 대상 앱을 체크하고 허용하는 것이고, 다른 하나는 TUN 모드로 바꿔 네트워크 계층에서 직접 트래픽을 관리해 루프백 제한을 근본적으로 우회하는 것입니다. 변경 후 대상 앱을 재시작해 확인하세요.
클라이언트 실행 시 포트 사용 중(7890 또는 9090) 오류가 뜨면 어떻게 하나요?
다른 프로세스가 동일한 포트를 사용 중이라는 의미로, 두 개의 프록시 클라이언트를 동시에 켰거나 이전에 종료한 프로세스가 남아 있는 경우 흔히 발생합니다. Windows에서는 netstat -ano로 포트를 점유한 PID를 찾은 뒤 작업 관리자에서 해당 프로세스를 종료하고, macOS와 Linux에서는 lsof -i:7890으로 위치를 확인하세요. 점유 중인 프로세스를 종료한 뒤 클라이언트를 다시 시작하면 됩니다. 두 프로그램을 함께 사용해야 한다면 클라이언트 설정에서 다른 포트로 변경한 뒤 재시작해 적용하세요. 세 플랫폼의 전체 명령 절차는 본 사이트 블로그의 전문 글을 참고하세요.
프록시를 켠 뒤 브라우저에서 HTTPS 인증서 오류가 뜨는데, 감청당하고 있는 건가요?
반드시 그런 것은 아닙니다. 흔한 원인은 세 가지입니다: 시스템 시간이 크게 어긋나 인증서 유효기간 검증이 실패하는 경우, 현재 노드나 네트워크 경로에 문제가 있어 목적지 사이트가 아닌 하이재킹 페이지가 반환되는 경우, 로컬에 패킷 캡처 디버깅 도구의 루트 인증서가 설치되어 복호화 기능이 계속 실행 중인 경우입니다. 점검 순서는 먼저 시스템 시간을 맞추고, 다음으로 노드를 바꿔 재테스트하고, 마지막으로 백그라운드에서 MITM 류 도구가 실행 중인지 확인하는 것입니다. 원인이 밝혀지기 전에는 오류 페이지에서 계속 방문을 누르지 마세요.
NEXT · 답을 찾지 못했다면
주제별로 계속 찾아보기
개념이 낯설다면 먼저 용어집을 확인하세요. 플랫폼별 다운로드, 설치, 설정 세부 사항은 설치 가이드에서 Windows, macOS, Linux, Android, iOS별로 장을 나누어 모든 단계를 다루고 있습니다.