Clash 자주 묻는 질문

Clash는 연결 처리, 규칙 매칭, DNS 처리를 담당하는 프록시 코어로 시작했습니다. Clash Meta는 기능을 확장한 포크이며, 이후 mihomo라는 이름으로 개발을 이어가고 있습니다. Clash Verge Rev 같은 데스크톱 클라이언트는 코어에 그래픽 인터페이스와 설정 관리, 시스템 연동 기능을 제공합니다. 같은 구독을 사용할 수 있는지는 인터페이스가 비슷한지가 아니라 코어가 지원하는 프로토콜과 설정 항목에 달려 있습니다. 알 수 없는 항목이나 지원하지 않는 프로토콜 오류가 발생하면 먼저 클라이언트의 코어 정보를 확인하고 설정 요구 사항과 대조하세요. 인터페이스 테마만 바꿔서는 프로토콜 호환성이 달라지지 않습니다.

클라이언트는 설정을 읽고 트래픽을 전달하는 역할을 하므로, 설치만으로 사용할 수 있는 프록시 서비스가 생기지는 않습니다. 일반적으로 서비스 제공업체가 발급한 구독 주소나 서버 정보, 인증 매개변수, 규칙이 포함된 설정 파일이 필요합니다. 설정이 현재 코어와 호환되는지 확인한 뒤 가져와 활성 설정으로 지정하고, 정책 그룹과 트래픽 처리 방식을 선택하세요. 소프트웨어 라이선스와 프록시 서비스 요금은 별개이며, 선택한 프로젝트와 서비스 제공업체에 따라 달라집니다. 구독 주소에는 접근 자격 증명이 포함되는 경우가 많으므로 비밀번호처럼 안전하게 보관하세요. 문제를 확인할 때는 주소와 사용자 이름, 인증 정보를 가리고 전체 설정을 공개 게시판에 올리지 마세요.

시스템 프록시는 프록시 주소를 운영체제 설정에 등록해 해당 설정을 사용하는 앱에 적용합니다. 일부 게임이나 명령줄 프로그램, 자체적으로 네트워크를 관리하는 앱은 시스템 프록시를 따르지 않을 수 있습니다. TUN 모드는 가상 네트워크 인터페이스와 라우팅을 이용해 트래픽을 처리하므로 더 많은 앱에 적용할 수 있지만, 시스템 권한과 라우팅, DNS 설정의 영향을 더 크게 받습니다. 웹을 주로 이용한다면 먼저 시스템 프록시로 연결을 확인하고, 필요한 앱에 맞춰 TUN을 테스트하세요. TUN을 켜도 모든 연결이 반드시 프록시를 거치는 것은 아닙니다. 실제 연결 경로는 규칙과 제외 라우트, 클라이언트 구현에 따라 달라집니다. 클라이언트가 두 방식을 함께 조정할 수는 있지만, 여러 프록시 프로그램으로 네트워크 트래픽을 중복 처리하는 것은 피하세요.

먼저 운영체제와 프로세서 아키텍처에 맞는 앱을 고른 다음, 설정 호환성과 시스템 연동 기능을 비교하세요. 이 사이트에서는 Windows, macOS, Android, iOS용으로 Clash Plus를 우선 소개하며, Linux에서는 Clash Verge Rev와 FlClash를 비교해 볼 수 있습니다. 기존 mihomo 설정을 계속 사용하려면 이름만 보지 말고 클라이언트 코어와 가져오기 형식을 확인하세요. iOS용 Clash Plus는 App Store에서 받을 수 있으며 공식 사이트는 clashplus.io입니다. 이전하기 전에 기존 설정과 규칙을 백업하고, 새 클라이언트에서 구독과 DNS, 자주 쓰는 앱을 확인한 뒤 이전 클라이언트를 종료하세요. 두 클라이언트가 동시에 시스템 프록시를 설정하지 않도록 주의하세요.

Windows는 설정의 시스템 정보에서 시스템 종류를 확인할 수 있습니다. macOS는 이 Mac에 관하여에서 칩 또는 프로세서를 확인하고, Android는 기기 정보나 제조사 사양을 살펴보세요. x64와 AMD64는 일반적으로 같은 계열의 아키텍처를 가리키며, ARM64 설치 파일은 해당 기기용입니다. macOS에서는 Apple Silicon용과 Intel용 패키지를 구분해야 합니다. 파일 크기만으로 설치 파일을 선택하지 마세요. 설치에 실패하면 오류 메시지를 빠짐없이 기록하고, 운영체제 최소 요구 사항과 남은 저장 공간, 이전 프로세스가 실행 중인지 확인하세요. 보안 경고가 표시되면 다운로드 출처와 프로젝트 안내를 함께 살펴보세요. 설치 파일을 실행하려고 시스템 보호를 계속 끄거나 보안 정책을 함부로 바꾸지 마세요.

먼저 구독 주소가 완전한지 확인하고, 복사할 때 들어간 공백과 줄바꿈, 끝의 문장 부호를 제거한 다음 업데이트 로그의 오류 내용을 살펴보세요. 401이나 403은 인증, 권한 또는 접근 제한과 관련된 경우가 많고, 404는 주소가 변경되었을 수 있습니다. 설정 대신 웹페이지가 반환된다면 제공업체에 전용 구독 주소를 확인하세요. 연결 시간 초과가 발생하면 기본 네트워크와 업데이트 요청의 아웃바운드 경로부터 확인합니다. 로그에 설정 파싱 오류가 표시되면 구독 형식이 현재 클라이언트와 코어에 맞는지 점검하세요. 작동하지 않는 주소를 반복해서 가져오거나 개인 구독을 출처가 불분명한 변환 사이트에 입력하지 마세요. 자격 증명이 유출됐다면 서비스 측에서 구독 주소를 재발급받으세요.

먼저 TUN을 끄고 일반 프록시 연결이 되는지 확인한 뒤, 서비스나 가상 네트워크 어댑터, 라우트 생성과 관련된 로그 오류를 살펴보세요. Windows 데스크톱 클라이언트는 서비스 모드를 설치하거나 복구해야 할 수 있으므로 해당 클라이언트의 안내를 따르세요. macOS에서는 시스템이 요청하는 네트워크 확장 또는 VPN 권한을 승인해야 합니다. Linux에서는 TUN 인터페이스를 만들고 라우트를 수정할 권한이 필요합니다. Android는 보통 VPN 연결 권한을 요청하므로 현재 사용 중인 클라이언트에서 나온 요청인지 확인하세요. 기존 VPN이나 오래된 가상 네트워크 어댑터, 보안 소프트웨어와 충돌할 수도 있습니다. 한 번에 하나씩 설정을 바꿔 다시 시도하고, 권한 문제를 파악하는 대신 계속 관리자 권한으로 실행하지 마세요.

앱 컨테이너로 격리된 일부 Windows 앱은 로컬 루프백 프록시에 직접 접근하지 못해 브라우저는 정상인데 스토어 앱만 작동하지 않을 수 있습니다. 모든 스토어 앱에 해당하는 것은 아닙니다. 먼저 해당 앱이 시스템 프록시를 사용하는지 확인하고, 클라이언트 연결 목록에 앱의 연결이 표시되는지 살펴보세요. 실제로 루프백 제한이 원인이라면 클라이언트에서 제공하는 UWP 루프백 면제 도구를 사용해 필요한 앱에만 권한을 부여하세요. 이 작업에는 관리자 권한이 필요할 수 있습니다. 설정을 바꾼 뒤 대상 앱을 다시 시작해 테스트하세요. 그래도 문제가 계속되면 앱의 네트워크 설정과 DNS, 규칙을 확인하고, 호환되는 경우 TUN도 테스트해 보세요. 모든 앱에 일괄적으로 권한을 허용하지 마세요.

일상적인 사용은 보통 규칙 모드로 시작해 설정된 규칙에 따라 연결을 분류하면 됩니다. 전역 모드는 전역 정책에 따라 연결을 처리하며, 실제 연결 경로는 해당 정책에서 선택한 항목에 따라 달라집니다. 트래픽 분류가 문제의 원인인지 잠깐 비교할 때 유용하지만, 특정 프록시 서버를 반드시 선택하는 모드는 아닙니다. 직접 연결 모드는 일반적으로 프록시를 거치지 않고 대상에 직접 연결합니다. 모드를 바꾸면 새 연결부터 새 정책이 적용되지만, 기존 연결이 즉시 다시 만들어지지는 않을 수 있습니다. 테스트할 때는 대상 앱을 다시 열거나 영향 범위를 확인한 뒤 관련 연결을 종료하세요. 클라이언트마다 같은 이름의 모드라도 메뉴 위치는 다를 수 있으므로 모드와 정책 그룹의 실제 선택 항목을 함께 확인하세요.

구독에서 생성된 파일을 직접 수정하면 다음 업데이트 때 변경 내용이 덮어써질 수 있으므로, 클라이언트에서 제공하는 덮어쓰기·병합·규칙 유지 기능을 우선 사용하세요. 규칙은 보통 위에서 아래로 매칭되므로, 더 구체적인 도메인 규칙을 먼저 일치할 수 있는 광범위한 규칙보다 위에 배치하세요. 기본값으로 처리하는 MATCH 규칙은 일반적으로 맨 아래에 둡니다. 규칙을 추가한 뒤 YAML 들여쓰기와 규칙 유형, 정책 그룹 이름과 대소문자를 확인하고 현재 활성 설정을 다시 불러왔는지도 점검하세요. 도메인 규칙은 클라이언트가 연결 도메인을 식별할 수 있어야 적용됩니다. 대상 IP만 표시된다면 매칭 결과가 달라질 수 있습니다. 웹페이지를 반복해서 새로고침하기보다 연결 기록에서 매칭된 규칙과 실제 연결 경로를 확인하는 편이 적용 여부를 판단하기 쉽습니다.

클라이언트 실행, 프록시 코어 실행, 시스템 프록시 활성화를 각각 별도의 단계로 보고 클라이언트가 어떤 옵션을 지원하는지 확인하세요. 먼저 직접 실행했을 때 정상 작동하는 설정을 저장하고, 로그인 시 실행을 켠 뒤 중복 등록된 시작 항목이 없는지 살펴보세요. 로그인 직후 네트워크를 사용할 수 없다면 코어가 준비되기 전에 시스템 프록시가 설정됐거나 네트워크 연결 전에 구독 업데이트가 시작됐을 수 있습니다. 클라이언트가 지원한다면 시작 지연을 설정하고 여러 네트워크 도구가 동시에 실행되지 않도록 조정한 뒤 시작 로그를 확인하세요. 개인 구독 주소를 공개 스크립트에 넣지 마세요. 자동 실행을 끄거나 클라이언트를 제거하기 전에 정상 종료하고 시스템 프록시를 비활성화해, 로컬의 작동하지 않는 포트를 가리키는 설정이 남지 않도록 하세요.

지연 시간 테스트는 보통 특정 테스트 주소에 요청을 한 번 보내는 데 걸린 시간만 보여 줍니다. 지속적인 다운로드 속도나 모든 웹사이트의 이용 경험을 나타내지는 않습니다. 대상 서버의 위치와 부하, 회선 혼잡, 패킷 손실, 정책 그룹 선택에 따라 실제 속도가 달라집니다. 먼저 웹 연결이 테스트한 출구를 실제로 사용하는지 확인하세요. 여러 속도 테스트를 동시에 실행하지 말고 같은 대상과 네트워크에서 비슷한 시간대에 비교하세요. 특정 웹사이트만 느리다면 해당 도메인에 적용된 규칙과 DNS 결과, 대상 서비스 상태를 확인합니다. 모든 연결이 느리다면 출구를 바꾸거나 기본 네트워크를 변경해 비교하세요. 한 번 측정한 지연 시간만으로 DNS와 TUN 설정을 여러 개 바꾸지 마세요.

먼저 프록시를 끄고 기본 네트워크로 정상적인 서비스에 접속할 수 있는지 확인하세요. 구독이 제대로 업데이트됐는지, 인증이 유효한지, 시스템 시간이 정확한지도 점검합니다. 그런 다음 실제 웹 요청과 연결 로그를 함께 확인하세요. 웹페이지는 열리는데 지연 시간 테스트만 시간 초과라면 테스트 주소에 접속할 수 없거나 현재 회선에 맞지 않는 것일 수 있으므로 모든 노드가 작동하지 않는다고 단정하지 마세요. 실제 요청도 실패하면 시간 초과, 인증 오류, TLS 오류 등 구체적인 내용을 기록하고 다른 출구와 기본 네트워크에서도 시도하세요. 모든 출구에서 동시에 실패한다면 구독 상태와 로컬 방화벽, 네트워크 환경을 먼저 확인합니다. 한 번에 하나의 조건만 바꾸고 오류 내용을 보관해 서비스 제공업체에 문제를 설명할 때 활용하세요.

먼저 클라이언트에서 코어가 실행 중인지 확인하고, 시스템 프록시의 주소와 포트가 실제 수신 대기 값과 일치하는지 점검하세요. 다른 안내서에 나온 포트를 그대로 사용하지 마세요. 다음으로 연결 목록에서 대상 앱의 요청이 클라이언트에 도달하는지 확인합니다. 브라우저 확장 프로그램이나 별도 프록시 설정, 일부 명령줄 도구의 환경 변수가 시스템 프록시보다 우선할 수 있으며, 시스템 설정 자체를 사용하지 않는 앱도 있습니다. 먼저 명시적 프록시를 지원하는 도구로 한 번 테스트한 뒤 앱별 프록시를 설정할지 TUN을 사용할지 결정하세요. 클라이언트를 종료한 후에도 네트워크에 문제가 있으면 시스템에 로컬 프록시 주소가 남아 있는지 확인하고, 오래된 프록시 환경 변수를 정리한 뒤 터미널을 다시 시작하세요.

먼저 어떤 도메인을 어떤 경로로 조회할지 정한 다음 클라이언트 DNS와 시스템 DNS, 브라우저 보안 DNS, 다른 VPN이 각각 DNS 요청을 처리하고 있는지 확인하세요. 테스트 사이트에 표시되는 DNS 리졸버 위치는 단서일 뿐, 그것만으로 유출을 입증할 수는 없습니다. 설정과 로그, 필요한 경우 네트워크 캡처를 함께 확인해 DNS 요청의 실제 경로를 판단하세요. Fake-IP는 매핑된 IP를 반환해 코어가 도메인과 연결을 연관 짓도록 돕는 기능입니다. 암호화 DNS와 같은 뜻이 아니며 모든 상황에서 반드시 켜야 하는 것도 아닙니다. 로컬 네트워크 기기 검색이나 특정 앱 호환성에 문제가 있으면 문서에 따라 예외를 설정하세요. DNS 모드를 바꾼 뒤 관련 캐시를 비우고 앱을 다시 시작해 같은 요청으로 재테스트하면 이전 캐시를 새 결과로 착각하는 일을 막을 수 있습니다.

먼저 클라이언트에서 TUN과 시스템 프록시를 끄고 정상적으로 종료한 다음 기본 네트워크가 복구됐는지 확인하세요. 클라이언트가 비정상 종료됐다면 시스템에 프록시 설정이 남아 있는지, 서비스 프로세스가 계속 실행 중인지 살펴보세요. VPN이나 트래픽 처리 도구를 하나만 남기고 DNS와 라우팅, 가상 네트워크 어댑터 충돌 여부를 확인하세요. 클라이언트를 다시 실행할 때는 먼저 시스템 프록시를 테스트하고 정상 작동하면 TUN만 따로 켜서 인터페이스 생성과 라우트 및 DNS 설정 로그를 확인합니다. 기본 네트워크를 계속 사용할 수 없다면 네트워크에 다시 연결하거나 기기를 재시작한 뒤 테스트하세요. 처음부터 모든 네트워크 어댑터를 삭제하거나 라우팅 정보를 초기화하거나 출처가 불분명한 네트워크 초기화 명령을 실행하지 마세요. 원격 연결이나 다른 업무용 네트워크에 영향을 줄 수 있습니다.