Clash 자주 묻는 질문과 문제 해결
구독 가져오기부터 프록시 적용까지, 문제가 발생한 단계별로 해결 방법을 찾아보세요. 각 항목은 재현 가능한 점검 순서를 우선 안내하며 Windows, macOS, Android, iOS와 Linux 클라이언트에 적용할 수 있습니다.
클라이언트, 코어와 설정부터 구분하기
Clash 관련 문제는 그래픽 클라이언트, Mihomo 코어, 구독 내용과 시스템 프록시가 함께 얽혀 발생하는 경우가 많습니다. 각 계층의 역할을 먼저 파악한 뒤 설치나 네트워크 문제를 점검하면 클라이언트 화면 문제를 노드 장애로 잘못 판단하는 일을 줄일 수 있습니다.
Clash, Clash Meta와 Mihomo 클라이언트는 어떤 관계인가요?
Clash는 프록시 클라이언트와 코어 생태계를 통칭하는 이름입니다. 현재 많이 사용하는 데스크톱 클라이언트는 대개 Mihomo 코어 또는 호환 코어를 사용합니다. 클라이언트는 화면, 설정 가져오기와 시스템 프록시를 담당하고, 코어는 설정을 해석해 규칙에 따라 연결을 구성합니다. 클라이언트를 선택할 때는 플랫폼 지원 여부, 코어 기능과 유지 관리 상태를 먼저 확인하세요.
구독 링크와 개별 노드는 어떻게 다른가요?
개별 노드는 하나의 연결 정보만 담지만, 구독 링크는 보통 여러 노드와 프록시 그룹, 규칙 설정을 반환합니다. 클라이언트는 구독 주소에서 주기적으로 업데이트를 가져오므로 구독 업데이트에 실패해도 기존 설정은 계속 사용할 수 있지만 새 노드와 정책 변경 사항은 동기화되지 않습니다.
전역, 규칙, 직접 연결 모드는 어떻게 선택하나요?
규칙 모드는 설정된 규칙에 따라 연결 경로를 결정하므로 일상적인 사용에 적합합니다. 전역 모드는 대부분의 요청을 선택한 프록시로 보내 프록시 경로를 임시로 확인할 때 유용합니다. 직접 연결 모드는 프록시를 우회하므로 접속 이상이 프록시 설정 때문인지 확인할 때 사용합니다. 일반적으로는 규칙 모드부터 선택하세요.
같은 구독인데 클라이언트마다 표시 결과가 다른 이유는 무엇인가요?
클라이언트마다 사용하는 코어 버전, 설정 호환 범위, 기본 DNS 설정과 규칙 처리 방식이 다를 수 있습니다. 먼저 구독 형식을 클라이언트가 인식하는지 확인한 다음 코어 종류, 오버라이드 설정과 규칙 모드를 점검하세요. 노드 수만으로 가져오기가 완전한지 판단하지 마세요.
권한 승인부터 첫 연결까지 단계별 확인
설치가 끝났다고 프록시가 바로 트래픽을 제어하는 것은 아닙니다. 클라이언트는 설정을 읽고 시스템 권한을 얻은 뒤 플랫폼에 따라 시스템 프록시 또는 VPN 인터페이스를 구성해야 합니다. 다음 항목은 처음 배포하거나 기기를 변경할 때 점검하기 좋습니다.
Windows에 클라이언트를 설치하기 전에 확인할 조건은 무엇인가요?
시스템 버전이 클라이언트 요구 사항을 충족하는지 확인하고, 클라이언트에 정상적인 파일 읽기·쓰기 권한을 부여하세요. 처음 실행한 뒤 설정 파일 폴더, 시스템 프록시 스위치와 방화벽 알림을 점검합니다. 컴퓨터에 다른 VPN, 프록시 도구 또는 네트워크 필터링 프로그램이 있다면 먼저 작동 상태를 기록해 여러 프로그램이 동시에 시스템 프록시를 제어하지 않도록 하세요.
Android 클라이언트에 VpnService 권한이 필요한 이유는 무엇인가요?
Android 클라이언트는 VpnService를 사용해 로컬 VPN 인터페이스를 만들고 앱 트래픽을 프록시 코어로 전달합니다. 이 권한은 원격 VPN 서비스 이용 권한이 아니라 클라이언트가 기기의 트래픽을 처리하도록 허용하는 데 필요한 시스템 권한입니다. 처음 활성화할 때 시스템 팝업에서 권한을 승인하고, 다른 VPN이 실행 중인지 확인하세요.
iOS 클라이언트에서 설정을 가져온 뒤 연결되지 않으면 무엇을 확인해야 하나요?
먼저 설정을 성공적으로 가져왔는지 확인한 다음 시스템 설정에서 클라이언트의 VPN 설정 추가를 허용하세요. 클라이언트로 돌아와 규칙 또는 전역 모드를 선택하고 사용 가능한 정책을 지정한 뒤 연결합니다. 시스템 상태 표시줄에 VPN 표시가 나타나지 않으면 권한 요청, 시스템 VPN 목록과 다른 VPN 설정의 충돌 여부를 다시 확인하세요.
구독 업데이트에 실패했을 때 어떤 순서로 점검해야 하나요?
먼저 브라우저나 클라이언트 로그에서 구독 주소에 접속할 수 있는지 확인한 뒤 시스템 시간, 네트워크 연결과 구독 주소가 완전한지 점검하세요. 이어서 현재 클라이언트에 사용 가능한 프록시가 있는지 확인하고, 필요하면 직접 연결로 업데이트하거나 네트워크를 임시로 바꿔 보세요. 주소가 설정 내용 대신 HTML, 로그인 페이지 또는 오류 메시지를 반환한다면 구독 제공업체에 주소 상태를 문의하세요.
구독, 노드와 프록시 모드를 통제 가능하게 관리하기
안정적인 사용을 위해서는 확인 가능한 설정 절차가 필요합니다. 업데이트 후 내용을 확인하고, 연결 전 정책을 점검하며, 접속 이상이 생기면 테스트 대상을 구분하세요. 한 번의 속도 측정 결과를 모든 네트워크 요청의 기준으로 삼지 마세요.
구독 업데이트는 성공했는데 노드 목록이 바뀌지 않는 이유는 무엇인가요?
클라이언트에 이전 설정이 저장되어 있거나 구독 서버의 내용이 아직 업데이트되지 않았을 수 있습니다. 업데이트 로그에서 응답 상태와 가져오기 결과를 확인하고 설정 업데이트 시간이 실제로 바뀌었는지 점검하세요. 그런 다음 설정을 한 번 다시 불러와 프록시 그룹이 새 노드를 참조하는지 확인합니다. 구독 내용 자체가 바뀌지 않았다면 클라이언트가 새 노드를 임의로 만들 수는 없습니다.
노드 테스트는 시간 초과인데 브라우저에서는 웹페이지가 열릴 때 어떻게 판단해야 하나요?
노드 테스트 주소와 실제 접속 대상은 같은 경로가 아니므로, 시간 초과는 테스트 대상에 접근할 수 없거나 노드 제한, DNS 확인 문제 또는 테스트 시간이 너무 짧아서 발생할 수 있습니다. 먼저 프록시 모드로 정상 작동이 확인된 대상에 접속한 뒤 클라이언트 로그를 확인하세요. 다른 노드와 여러 테스트 URL도 비교해야 합니다. 한 번의 지연 시간이나 시간 초과 결과만으로 노드를 완전히 사용할 수 없다고 판단하지 마세요.
TUN 모드를 활성화하기 전에 무엇을 준비해야 하나요?
TUN을 활성화하기 전에 클라이언트가 해당 시스템을 지원하는지 확인하고 관리자 권한 또는 시스템 승인을 준비하세요. 충돌할 수 있는 VPN, 가상 네트워크 어댑터와 다른 트래픽 제어 도구는 종료합니다. 활성화한 뒤 TUN 상태, DNS 설정과 규칙 모드를 확인하고 명령줄이나 브라우저로 실제 트래픽이 프록시로 들어가는지 검증하세요. 인터넷이 끊기면 먼저 TUN을 끄고 시스템 프록시 모드로 되돌려 비교하세요.
TUN 모드에서 권한 부족이 표시되거나 활성화 직후 꺼지면 어떻게 해야 하나요?
클라이언트가 필요한 권한으로 실행되고 있는지 확인하고, 시스템 보안 프로그램이 가상 네트워크 어댑터나 네트워크 서비스를 차단하지 않는지 점검하세요. Windows 사용자는 관련 드라이버 설치 알림과 기존 VPN 어댑터도 확인해야 합니다. Linux 사용자는 실행 권한, 라우팅 설정과 코어 기능을 점검하세요. 로그의 구체적인 오류를 확인한 뒤 다시 활성화하고, 인터페이스가 여러 개 남지 않도록 연속해서 반복 전환하지 마세요.
시스템 프록시, 루프백과 DNS를 단계별로 확인하기
일부 앱만 접속하지 못한다면 문제는 대개 노드가 온라인인지 여부에만 있지 않습니다. 앱이 시스템 프록시를 따르는지, 로컬 루프백이 필요한지, DNS가 예상한 주소를 반환하는지 순서대로 확인하면 문제 범위를 좁힐 수 있습니다.
시스템 프록시는 켜져 있는데 일부 프로그램이 계속 직접 연결되는 이유는 무엇인가요?
시스템 프록시는 주로 시스템 프록시 규격을 따르는 앱에 적용됩니다. 일부 프로그램은 독립적인 네트워크 스택이나 고정 프록시 설정을 사용하거나 특정 프로토콜만 지원하므로 시스템 프록시를 읽지 않습니다. 먼저 클라이언트의 수신 주소와 포트를 확인한 다음 대상 프로그램의 프록시 설정을 점검하세요. 이런 트래픽까지 처리해야 한다면 TUN 모드를 검토하되 권한, DNS와 네트워크 라우팅에 추가 요구 사항이 있다는 점을 유의하세요.
Windows UWP 앱이 프록시로 접속하지 못할 때 루프백은 어떻게 설정하나요?
일부 UWP 앱은 기본적으로 로컬 루프백 주소에 접근할 수 없어 기기에서 실행 중인 프록시 포트에 연결하지 못합니다. 시스템에서 제공하는 앱 루프백 면제 도구를 사용해 대상 UWP 앱에 루프백 권한을 선택하고 설정을 저장한 뒤 앱을 다시 시작하세요. 설정 전에는 로컬 프록시에 접근해야 하는 앱만 선택하고, 완료 후 시스템 프록시와 클라이언트 로그를 다시 확인하세요.
Fake-IP 모드에서 로컬 네트워크 기기나 특정 앱에 접근할 수 없으면 어떻게 해야 하나요?
Fake-IP는 도메인에 가상 주소를 할당하므로 도메인 확인과 규칙 매칭에 의존하는 앱에서 호환성 문제가 발생할 수 있습니다. 먼저 대상 도메인이 Fake-IP 제외 목록 또는 nameserver-policy 설정에 포함되어 있는지 확인한 뒤 클라이언트 DNS 캐시를 지우고 다시 연결하세요. 로컬 네트워크 기기, 프린터, 게임 콘솔과 실제 주소를 직접 가져와야 하는 앱은 상황에 맞게 직접 연결 또는 제외로 설정하는 것이 좋습니다.
DNS 설정에 이상이 있을 때 주소 확인 문제와 노드 문제를 어떻게 구분하나요?
먼저 직접 연결 모드에서 같은 도메인을 확인한 다음 규칙 모드로 전환해 결과를 비교하세요. 직접 연결에서만 확인에 실패하고 프록시에서는 정상이라면 로컬 네트워크나 DNS 문제일 수 있습니다. 모두 정상적으로 확인되지만 연결에 실패한다면 노드, 규칙과 대상 서비스를 계속 점검하세요. 로그의 DNS 요청, 반환 주소와 적용된 규칙을 확인하는 편이 노드를 반복해서 바꾸는 것보다 원인 파악에 효과적입니다.
규칙을 수정했는데 바로 적용되지 않는 이유는 무엇인가요?
규칙 파일을 수정해도 클라이언트가 메모리에 저장된 이전 설정이나 이전 DNS 캐시를 계속 사용할 수 있습니다. 먼저 설정을 저장하고 다시 불러온 뒤 규칙 파일 경로와 문법이 올바른지 확인하세요. 이후 관련 연결을 정리하거나 앱을 다시 엽니다. 규칙 적용 정보를 확인할 때는 규칙 순서도 함께 점검해야 합니다. MATCH 같은 기본 규칙이 너무 앞에 있으면 뒤의 규칙이 적용되지 않습니다.