Clash 자주 묻는 질문

클라이언트는 설정 가져오기, 정책 선택, 시스템 프록시 설정 등 사용자 인터페이스 작업을 담당하고, 코어는 실제 연결과 DNS 조회, 규칙 매칭을 처리합니다. Clash Meta는 관련 코어 프로젝트에서 사용하던 이름이며, 이후 mihomo로 이름이 바뀌었습니다. 오래된 가이드에 나오는 Meta가 독립형 클라이언트를 뜻하는 것은 아닙니다. 클라이언트마다 포함된 코어 버전과 설정 관리 방식이 다를 수 있으므로 문제를 점검할 때는 클라이언트 이름과 코어 버전을 함께 확인하세요. 화면이 비슷하다는 이유만으로 특정 설정 항목을 지원한다고 판단해서는 안 됩니다.

클라이언트를 설치하면 트래픽 처리 도구를 준비한 것일 뿐입니다. 실제로 연결하려면 사용할 수 있는 프록시 설정이나 구독과 해당 서버에 접속할 수 있는 네트워크 환경이 필요합니다. 설정을 가져온 뒤 프록시 노드와 정책 그룹이 있는지 확인하고, 노드를 선택해 테스트한 다음 시스템 프록시를 켜거나 필요에 따라 TUN을 활성화하세요. 클라이언트에 실행 중이라고 표시되어도 코어가 시작된 것일 뿐, 구독이 유효하거나 노드에 연결할 수 있거나 웹사이트가 열린다는 뜻은 아닙니다. 각 항목을 따로 확인해야 합니다.

일상적인 사용은 규칙 모드로 시작하는 것이 좋습니다. 설정에 정의된 규칙에 따라 연결이 해당 정책으로 전달됩니다. 전역 모드는 코어가 받은 연결을 전역 정책으로 보내므로 잠깐 비교하며 문제를 확인할 때 유용하지만, 모든 앱의 트래픽을 자동으로 처리하지는 않습니다. 직접 연결 모드는 주로 로컬 네트워크가 정상인지 확인할 때 사용합니다. 모드를 바꾼 뒤에는 새 연결을 만들어 테스트하세요. 기존 연결은 이전 정책을 계속 사용할 수 있습니다. 전역 모드에서 정상적으로 작동하더라도 규칙이나 그룹을 확인해야 한다는 의미일 뿐, 구체적인 원인이 밝혀진 것은 아닙니다.

이미 설치된 버전은 계속 작동할 수 있지만, 보관된 클라이언트에는 호환성 수정과 보안 업데이트가 제공되지 않습니다. 새 설정 항목이나 프로토콜을 인식하지 못할 수도 있습니다. 다른 클라이언트로 옮기려면 먼저 구독 출처, 정책 선택, 로컬 규칙을 백업한 뒤 유지 관리 중인 클라이언트에 하나씩 가져오세요. 기존 프로그램 폴더 전체를 덮어쓰거나 두 클라이언트를 동시에 실행해 네트워크를 처리하지 마세요. 처음 옮긴 뒤에는 시스템 프록시와 기본 연결을 확인하고, TUN과 오버라이드 등 사용자 설정을 복원하세요.

구독 주소에는 접속 자격 증명이 포함되는 경우가 많아, 전체 링크를 얻은 사람이 노드 정보를 확인하거나 서비스 리소스를 사용할 수 있습니다. 스크린샷이나 로그를 공유하기 전에는 구독 경로, 쿼리 매개변수, 노드 비밀번호, 컨트롤 인터페이스 키를 가리세요. 계정 이름만 숨겨서는 충분하지 않습니다. 구독 변환이 필요하면 서비스 제공업체가 제공하는 호환 형식을 우선 사용하거나 신뢰할 수 있는 로컬 환경에서 처리하세요. 낯선 변환 사이트에 링크를 제출하는 것은 설정에 접근할 권한을 넘기는 것과 같습니다. 링크가 유출되었다면 공개 게시물을 삭제하는 데 그치지 말고 서비스 제공업체 계정에서 재설정하세요.

먼저 계정 요금제, 만료일, 남은 데이터 용량을 확인한 다음 서비스 제공업체의 계정 페이지에서 전체 링크를 다시 복사하세요. 공백이나 줄바꿈이 들어갔거나 링크가 잘리지 않았는지도 확인합니다. 오류가 요청 시간 초과, 접근 거부, 설정 파싱 실패 중 무엇인지 살펴보세요. 접근이 거부되면 인증 정보를 확인하고, 웹페이지가 반환되면 로그인 페이지나 오류 페이지인지 확인해야 합니다. 링크에 접속하려면 프록시가 필요한 경우, 이미 연결 가능한 상태에서 업데이트하거나 서비스 제공업체가 허용하는 다른 주소를 사용하세요. 요청을 짧은 시간에 반복하면 속도 제한에 걸릴 수 있습니다.

먼저 시스템 정보에서 프로세서 아키텍처와 운영체제 버전을 확인한 뒤 해당 파일을 선택하세요. 일반적인 Intel 및 AMD 데스크톱 프로세서는 x64 또는 AMD64를, 해당 ARM 기기는 ARM64를 사용합니다. macOS에서는 Apple Silicon과 Intel용 파일을 구분해야 합니다. 설치 중 형식이 지원되지 않는다는 메시지가 나오면 파일 확장자를 바꾸기보다 운영체제와 아키텍처가 맞는지 확인하세요. 최소 운영체제 버전, 필수 구성 요소, 서비스 설치 요건은 클라이언트마다 다르므로 다운로드 페이지의 안내와 설치 메시지를 따르세요.

먼저 TUN을 끄고 시스템 프록시를 통한 기본 연결이 되는지 확인하세요. 그런 다음 클라이언트 안내에 따라 서비스 모드를 설치하거나 가상 네트워크 어댑터 생성에 필요한 권한을 부여합니다. Windows에서는 관리자 권한이 필요할 수 있고, Linux에서는 서비스 권한이나 네트워크 기능을 설정해야 할 수 있습니다. 모바일 기기에서는 시스템 VPN 연결 요청을 승인해야 합니다. 권한을 부여한 뒤 서비스가 실제로 실행 중인지 확인하고 코어 로그에서 구체적인 오류를 살펴보세요. 조직에서 관리하는 기기라면 제한을 우회하지 마세요. 올바른 서비스 설정 대신 관계없는 모든 프로그램을 계속 높은 권한으로 실행해서도 안 됩니다.

mixed-port는 HTTP 및 SOCKS 프록시 연결을 받는 포트이고, external-controller는 관리 인터페이스가 호출하는 포트입니다. 두 포트의 용도는 다릅니다. 브라우저나 터미널에 프록시를 설정할 때는 실제로 활성화된 혼합 포트를 사용해야 하며 컨트롤 포트를 입력하면 안 됩니다. 클라이언트에서 리슨 주소와 포트를 확인한 뒤 앱에도 같은 값을 입력하세요. 로컬 기기에서만 사용할 경우 루프백 주소로 리슨하는 것이 좋습니다. 값을 변경한 뒤에는 코어 설정을 다시 불러오고, 프록시를 수동으로 설정한 앱도 함께 업데이트해 이전 포트에 계속 연결되지 않도록 하세요.

구독 파일은 보통 원격 콘텐츠로 전체 갱신되므로, 다운로드한 설정을 직접 수정하면 업데이트할 때 덮어써질 수 있습니다. 개인 설정은 구독 본문과 분리해 관리할 수 있도록 클라이언트의 오버라이드, 병합 또는 로컬 규칙 기능을 사용하세요. 지원하는 항목과 병합 순서는 클라이언트마다 다릅니다. 저장한 뒤에는 편집기 내용만 보지 말고 현재 적용된 최종 설정을 확인하세요. 먼저 쉽게 확인할 수 있는 규칙 하나를 추가해 위치와 대상 정책이 맞는지 테스트한 다음 나머지 설정을 옮기고, 복구할 수 있도록 백업도 보관하세요.

지연 시간 테스트는 보통 지정된 테스트 주소로 한 번 요청했을 때 걸린 시간을 보여줄 뿐, 지속적인 대역폭을 나타내지는 않습니다. 실제 속도는 회선 혼잡, 서버 부하, 대상 사이트의 제한, 로컬 무선 네트워크의 영향을 받습니다. 노드를 비교할 때는 비슷한 시간대에 같은 대상에 접속해 웹페이지 응답과 지속 전송 속도를 각각 확인하세요. 여러 속도 측정 작업을 동시에 실행하지 않는 것이 좋습니다. 특정 사이트만 느리다면 해당 사이트에 적용된 규칙과 연결 경로부터 확인하세요. 지연 시간이 가장 짧다는 이유만으로 모든 용도에 적합한 노드라고 판단하지 마세요.

클라이언트의 연결 목록이나 로그를 열고 대상 웹사이트에 다시 접속하세요. 도메인으로 새 연결을 필터링한 뒤 적용된 규칙, 정책 그룹, 최종 아웃바운드를 확인합니다. 규칙은 일반적으로 위에서 아래 순서로 적용되므로 앞에 있는 포괄적인 규칙이 뒤의 세부 규칙보다 먼저 적용될 수 있습니다. 설정을 변경한 뒤에는 해당 연결을 종료하거나 테스트 앱을 다시 실행해 기존 연결이 재사용되면서 잘못 판단하는 일을 피하세요. 한 웹페이지가 여러 도메인에 요청을 보낼 수 있습니다. 메인 사이트는 열리지만 이미지가 표시되지 않는다면 정적 리소스와 로그인 API에 적용된 규칙도 확인해야 합니다.

일부 클라이언트는 두 기능을 동시에 지원하지만, 처음 설정할 때는 한 가지 트래픽 처리 방식만 먼저 테스트하는 것이 좋습니다. 시스템 프록시는 시스템 프록시 설정을 따르는 앱에 주로 영향을 주고, TUN은 가상 네트워크 어댑터와 라우팅을 통해 조건에 맞는 트래픽을 처리합니다. 두 기능은 같은 방식이 아닙니다. 함께 사용할 때는 라우팅, DNS 하이재킹, 다른 VPN과의 충돌을 확인해 트래픽이 반복해서 전달되지 않도록 하세요. 전환하기 전에 기존 설정을 기록하고 각 기능을 단독으로 켰을 때의 동작부터 확인합니다. 문제가 생기면 여러 옵션을 동시에 바꾸기보다 검증된 한 가지 방식으로 되돌리는 편이 원인을 찾기 쉽습니다.

업데이트 전에 현재 설정 이름, 정책 그룹 선택, 로컬 오버라이드를 기록하고 보관할 파일을 백업하세요. 구독 업데이트와 규칙 목록 업데이트는 서로 다른 작업입니다. 구독 업데이트는 노드나 정책 그룹을 바꿀 수 있고, 규칙 목록 업데이트는 주로 규칙 매칭 데이터를 변경합니다. 업데이트 후에는 설정이 정상적으로 로드되었는지 확인한 다음 자주 사용하는 사이트와 로컬 서비스를 점검하세요. 노드 이름이 바뀌었다면 이전 정책 선택이 복원되지 않을 수 있습니다. 자동 업데이트 간격은 서비스 제공업체의 안내에 맞추되 지나치게 짧게 설정할 필요는 없습니다. 문제가 생기면 오류와 업데이트 시간을 기록한 뒤 백업 복원 여부를 결정하세요.

출구 IP는 특정 연결이 어느 위치를 통해 나갔는지만 보여주며, DNS 조회도 같은 경로를 사용했다는 뜻은 아닙니다. 먼저 현재 설정의 DNS 서비스, 상위 DNS 서버, 라우팅을 확인한 다음 브라우저의 보안 DNS, 시스템의 암호화 DNS, 다른 VPN이 별도의 DNS 경로를 만들고 있지 않은지 살펴보세요. 테스트 사이트에 표시되는 DNS 서버 위치도 실제 조회 경로와 다를 수 있으므로 로그와 필요에 따라 패킷 캡처를 함께 확인해야 합니다. 설정을 변경한 뒤에는 관련 캐시를 지우고 새 연결을 만들어, 이전 조회 결과를 현재 설정의 문제로 오해하지 않도록 하세요.

먼저 프록시를 끄고 기본 네트워크가 작동하는지 확인한 다음 구독 만료 여부, 노드 로드 상태, 시스템 시간의 정확성을 점검하세요. 이어서 노드를 몇 개만 골라 수동으로 테스트하고 로그에서 DNS 조회 실패, 연결 거부, 핸드셰이크 시간 초과 중 어떤 오류가 발생하는지 확인합니다. 공통 테스트 주소에만 연결할 수 없다면 테스트 시간 초과가 모든 대상에 접속할 수 없다는 뜻은 아닙니다. 실제 웹사이트로 교차 확인하세요. 다른 네트워크에서도 모두 실패한다면 DNS, 규칙, 포트를 동시에 바꾸지 말고 서비스 제공업체에 노드 상태를 문의하세요.

먼저 시스템 프록시 주소가 클라이언트의 실제 리슨 포트와 일치하는지, 코어가 실행 중인지 확인하세요. 이어서 브라우저에 별도 프록시 확장 프로그램이나 수동 설정, 조직 정책이 적용되어 있는지 살펴봅니다. 웹사이트에 접속할 때 새 연결이 기록되는지도 확인하세요. 기록이 없다면 트래픽이 클라이언트에 들어오는지부터 확인하고, 기록이 있다면 적용된 정책과 노드를 점검합니다. 터미널이나 게임 등은 시스템 프록시 설정을 따르지 않을 수 있으므로 앱에서 별도로 설정하거나 TUN을 사용해야 합니다. 점검할 때는 프록시 도구를 하나만 남겨 다른 프로그램이 시스템 설정을 계속 덮어쓰지 않도록 하세요.

일부 UWP 앱은 앱 컨테이너의 루프백 제한 때문에 로컬 루프백 주소에서 리슨하는 프록시에 연결하지 못할 수 있습니다. 먼저 일반 브라우저에서 프록시가 작동하는지 확인하고, 해당 앱이 실제로 이 프록시 경로를 사용하는지도 확인하세요. 그런 다음 클라이언트 문서에 따라 해당 앱에만 루프백 예외를 추가합니다. 이 작업에는 관리자 권한이 필요할 수 있습니다. 모든 앱에 일괄적으로 예외를 허용하거나 앱이 스토어에서 설치되었다는 이유만으로 같은 문제가 있다고 단정하지 마세요. 앱이 시스템 프록시를 사용하지 않는다면 네트워크 동작 방식을 확인하고, 권한이 허용되는 경우 TUN으로 비교 테스트하세요.

먼저 충돌한 포트가 혼합 프록시 포트인지 컨트롤 인터페이스 포트인지 확인하세요. Windows에서는 netstat -ano로 리슨 상태와 프로세스 ID를 확인할 수 있고, Linux에서는 ss -lntp를 사용합니다. 구체적인 프로세스 정보를 확인하려면 추가 권한이 필요할 수 있습니다. 포트를 사용 중인 프로그램을 확인한 뒤 중복 실행 중인 클라이언트를 종료할지, 현재 설정에서 사용 가능한 포트를 선택할지 결정하세요. 정체를 모르는 시스템 프로세스를 바로 종료하지 마세요. 포트를 바꾼 다음 설정을 다시 불러오고 앱의 프록시 주소도 함께 업데이트합니다. 실행할 때마다 충돌한다면 이전 서비스나 시작 프로그램이 백그라운드에서 계속 실행되는지 확인하세요.

연결 중에는 구독, 노드, 모드, 트래픽 처리, DNS 순서로 확인하고 연결 기록을 통해 요청이 코어에 도달하지 않았는지, 도달한 뒤 실패했는지 구분하세요. 종료 후 인터넷이 끊겼다면 시스템 프록시가 중지된 로컬 포트를 계속 가리키는지, TUN이나 다른 VPN이 라우팅에 영향을 남겼는지 먼저 확인합니다. 클라이언트에서 프록시와 TUN을 정상적으로 끈 다음 시스템 네트워크 설정을 점검하고 필요한 경우 관련 앱을 다시 시작하세요. 전체 설정을 처음부터 초기화하면 원래 찾을 수 있었던 문제의 단서가 사라질 수 있으므로 로그를 보관한 뒤 재설정하세요.