Clash 자주 묻는 질문과 문제 해결
증상에서 네트워크 계층까지 단계적으로 원인을 좁혀 보세요. 기본 연결을 먼저 확인한 뒤 설정, 프록시 진입점, 규칙, DNS를 점검합니다. 한 번에 한 가지 변수만 바꿔야 로그를 정확히 판단할 수 있습니다.
기본 개념
먼저 코어, 클라이언트, 프록시 진입점, 정책 모드를 구분해 잘못된 대상을 점검하지 않도록 하세요.
Clash, Mihomo 코어, GUI 클라이언트는 어떤 관계인가요?
코어는 설정 읽기, 연결 수립, 규칙 매칭, DNS 처리를 담당하고, GUI 클라이언트는 구독 관리, 정책 선택, 시스템 프록시 전환, 로그 표시를 담당합니다. Mihomo는 현재 널리 쓰이는 호환 코어 중 하나입니다. 문제를 해결할 때는 Clash만 버전 정보로 제시하지 말고 클라이언트 이름, 코어 종류, 운영체제를 함께 기록해야 합니다.
규칙 모드, 전역 모드, 직접 연결 모드는 어떻게 다른가요?
규칙 모드는 설정의 규칙을 위에서 아래로 확인해 처음 일치한 정책으로 연결을 보냅니다. 전역 모드는 일반적으로 처리 가능한 트래픽을 지정한 정책 그룹으로 일괄 전달하며, 직접 연결 모드는 가능한 한 프록시를 우회합니다. 평소에는 규칙 모드를 우선 사용하고, 노드 연결을 테스트할 때만 전역 모드로 잠시 전환한 뒤 점검이 끝나면 원래 설정으로 되돌리세요.
시스템 프록시와 TUN 모드 중 무엇을 선택해야 하나요?
브라우저와 시스템 프록시 설정을 따르는 데스크톱 프로그램은 대개 시스템 프록시만으로 충분하며, 설정과 해제가 간단합니다. 게임, 명령줄 도구, 일부 스토어 앱처럼 시스템 프록시를 읽지 않는 프로그램은 TUN 처리가 필요할 수 있습니다. 먼저 시스템 프록시를 확인한 뒤 앱의 필요에 따라 TUN을 활성화하세요. 여러 네트워크 계층을 동시에 변경하면 점검 범위가 불필요하게 넓어집니다.
지연 시간 측정값이 실제 접속 속도와 다른 이유는 무엇인가요?
클라이언트의 지연 시간 테스트는 대개 지정된 주소에 짧은 연결이나 요청을 한 번 수행하므로, 측정 대상과 당시 경로, 핸드셰이크 상태를 주로 반영합니다. 웹페이지 로딩과 동영상 전송은 대역폭, 패킷 손실, 대상 서버와의 거리, 회선 혼잡, 프로토콜에도 영향을 받습니다. 숫자가 가장 작은 노드만 고르지 말고 여러 차례 측정한 뒤 실제 서비스를 열어 보고 로그 결과까지 함께 판단하세요.
설치 및 설정
구독 가져오기, 시스템 권한, 네트워크 인터페이스는 최초 설정 단계에서 가장 먼저 확인해야 할 세 가지 항목입니다.
구독을 가져왔는데 노드가 표시되지 않는 이유는 무엇인가요?
먼저 구독 URL에 계속 접속할 수 있는지 확인하고, 클라이언트의 설정 목록에 새 설정이 추가되었는지 살펴보세요. 설정은 있지만 노드가 비어 있다면 업데이트 로그에서 형식 오류, 인증 실패, 비정상 응답 여부를 확인하세요. 현재 활성화된 항목이 이전 설정이 아니라 방금 가져온 설정인지도 점검해야 합니다. 구독 URL은 민감한 정보이므로 문제 해결용 스크린샷에서는 전체 링크와 매개변수를 가리세요.
구독 업데이트가 실패하거나 만료되었다고 표시되면 어떻게 하나요?
먼저 서비스 제공업체 페이지에서 구독 상태, 유효기간, 트래픽 잔여량을 확인하고, URL을 불완전하게 복사해 매개변수가 누락되지 않았는지 점검하세요. 기존 설정은 작동하지만 업데이트만 실패한다면 시스템 시간, DNS 조회, 업데이트 요청 로그를 확인하세요. 일부 서비스는 요청 횟수를 제한하므로 구독을 짧은 간격으로 계속 새로고침하지 마세요. 잠시 기다렸다가 업데이트하면 일시적인 제한인지 URL 만료인지 구분하기 쉽습니다.
Windows에서 TUN을 켤 때 권한 부족 오류가 발생하는 이유는 무엇인가요?
TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 변경하므로 일반적으로 관리자 권한이 필요합니다. 클라이언트를 종료한 뒤 관리자 권한으로 실행하고, 보안 프로그램이 드라이버나 서비스 등록을 차단하는지 확인하세요. 클라이언트가 서비스 모드를 제공한다면 설정 페이지의 안내에 따라 설치한 뒤 다시 시작하세요. 계속 실패하면 로그에서 구체적인 장치명이나 서비스명을 확인하고, 같은 유형의 가상 네트워크 어댑터를 여러 개 반복 설치하지 마세요.
macOS에서 시스템 프록시를 켰는데 적용되지 않으면 어떻게 하나요?
먼저 클라이언트에 네트워크 관련 권한이 부여되었는지 확인하고, 현재 활성 네트워크 인터페이스가 실제 사용 중인 Wi-Fi 또는 유선 연결인지 살펴보세요. 네트워크를 전환하면 이전 인터페이스의 프록시 설정이 새 인터페이스에 자동 적용되지 않을 수 있습니다. 시스템 프록시를 끄고 클라이언트를 완전히 종료한 뒤 다시 실행한 다음, 시스템 네트워크 설정의 HTTP, HTTPS 또는 SOCKS 항목이 갱신되었는지 확인하세요.
Microsoft Store 또는 UWP 앱에서 프록시를 사용할 수 없으면 어떻게 하나요?
일부 UWP 앱은 로컬 루프백 제한 때문에 로컬 주소에서 실행 중인 프록시 포트에 직접 접속할 수 없습니다. 클라이언트가 제공하는 UWP 루프백 도구로 인터넷 연결이 필요한 앱에 루프백 권한을 부여한 뒤 해당 앱을 다시 실행하세요. TUN을 이미 켰다면 문제가 여전히 발생하는지 먼저 확인하세요. 어떤 설정이 효과를 냈는지 판단하기 어려워지므로 루프백, 시스템 프록시, 방화벽을 동시에 반복해서 변경하지 마세요.
Android에서 설정을 가져온 뒤 VPN 연결 안내가 표시되지 않는 이유는 무엇인가요?
Android 클라이언트가 처음 로컬 VPN을 만들 때는 시스템 승인이 필요합니다. 승인 창이 나타나지 않으면 시스템 설정에서 다른 VPN, 항상 연결 VPN 또는 업무 프로필 정책이 연결을 점유하고 있는지 확인하세요. 충돌하는 VPN을 끈 뒤 클라이언트로 돌아가 다시 시작하세요. 일부 기기는 백그라운드 실행도 제한하므로 연결을 수립하는 동안 클라이언트 실행을 허용하고, 상태 표시줄에 VPN 아이콘이 나타나는지 확인하세요.
활용 방법
연결 기록, 상태 확인, 오버라이드 기능을 활용하면 일상적인 설정 변경 내역을 확인하고 필요할 때 되돌릴 수 있습니다.
특정 도메인에 어떤 규칙이 적용되었는지 어떻게 확인하나요?
클라이언트의 연결 기록이나 실시간 로그를 연 뒤 대상 도메인에 다시 접속하세요. 기록에는 일반적으로 대상 호스트, 일치한 규칙, 최종 정책 그룹이 표시됩니다. IP 주소만 보인다면 DNS를 코어가 처리하고 있는지 확인하세요. 규칙을 변경한 뒤에는 설정을 다시 불러오고 새 연결로 테스트해야 합니다. 기존 장기 연결은 이전 경로를 계속 사용할 수 있으므로 새 규칙의 적용 여부를 판단하는 근거로 삼을 수 없습니다.
자동 선택 정책 그룹이 노드를 자주 바꾸는 이유는 무엇인가요?
자동 정책 그룹은 상태 확인 결과에 따라 순서를 다시 정하거나 장애 발생 시 다른 노드로 전환합니다. 검사 간격이 지나치게 짧거나 테스트 URL이 불안정한 경우, 노드 간 차이가 작거나 네트워크에 일시적인 패킷 손실이 있는 경우에는 전환이 잦아질 수 있습니다. 검사 간격을 적절히 늘리고, 안정적이면서 전송량이 적은 테스트 URL을 사용하며, 전환 허용 오차를 합리적으로 설정하세요. 접속 출구를 고정해야 하는 로그인 환경에서는 수동 정책이 더 적합합니다.
설정 파일 수정 내용이 구독 업데이트로 덮어쓰이지 않게 하려면 어떻게 하나요?
구독으로 생성된 설정을 직접 편집하면 다음 업데이트 때 전체 내용이 교체되는 경우가 많습니다. 클라이언트가 지원하는 오버라이드, 병합, 스크립트 또는 설정 전처리 기능을 우선 사용해 사용자 규칙과 구독 내용을 따로 보관하세요. 수정 전에는 정상적으로 실행되는 설정을 백업하고, 소수의 규칙으로 문법부터 검증하세요. 클라이언트마다 오버라이드 형식이 다르므로 이전할 때는 필드를 다시 확인해야 합니다.
모든 노드 테스트가 시간 초과되면 무엇부터 확인해야 하나요?
먼저 프록시를 끄고 기본 인터넷 연결로 일반 웹사이트에 접속할 수 있는지 확인한 뒤 시스템 시간, 구독 상태, 노드 주소의 DNS 조회를 점검하세요. 이후 정상 작동이 확인된 다른 네트워크로 전환해 현재 Wi-Fi, 공유기 또는 통신망의 제한을 배제하세요. 일부 노드만 시간 초과된다면 대개 노드 상태나 회선 문제입니다. 모든 노드가 시간 초과되면 코어 시작 로그, 방화벽 차단, 설정 파싱 오류를 중점적으로 확인하세요.
문제 해결
프록시를 끈 상태의 기본 네트워크를 기준으로 삼고, 노드, 트래픽 진입점, 규칙, DNS를 한 단계씩 다시 활성화하세요.
Clash를 켠 뒤 모든 웹사이트에 접속할 수 없으면 어떻게 하나요?
먼저 시스템 프록시나 TUN을 끄고 인터넷 연결이 복구되는지 확인하세요. 복구된다면 클라이언트, 설정 또는 노드 경로에 문제가 있는 것입니다. 다시 실행한 뒤 작동이 확실한 노드를 선택하고 전역 모드로 잠시 테스트하세요. 전역 모드는 되지만 규칙 모드는 안 된다면 규칙과 DNS를 확인하세요. 두 모드 모두 실패하면 로그에서 연결 거부, 시간 초과, 포트 충돌 정보를 살펴보세요.
노드에는 연결되지만 웹페이지에 DNS 오류가 표시되면 어떻게 점검하나요?
먼저 모든 도메인에서 실패하는지, 일부 도메인에서만 실패하는지 구분하세요. 설정에서 DNS 모듈이 활성화되어 있는지, 수신 포트가 충돌하지 않는지, 다른 도구가 시스템 DNS를 변경했는지 확인하세요. fake-ip와 redir-host를 전환하기 전에는 클라이언트와 코어의 지원 여부를 점검해야 합니다. 시스템 DNS 캐시를 비운 뒤 연결을 다시 만들고, 로그에서 DNS 요청이 코어로 들어가는지와 어떤 결과가 반환되는지 확인하세요.
Clash를 종료한 뒤에도 인터넷에 연결되지 않으면 어떻게 하나요?
비정상 종료 시 로컬 포트를 가리키는 시스템 프록시 설정이나 정리되지 않은 TUN 경로가 남을 수 있습니다. 먼저 시스템 네트워크 설정에서 수동 프록시를 끄고, 클라이언트를 다시 열어 정상 종료 절차로 프록시 기능을 해제하세요. TUN을 사용했다면 시스템을 재부팅해 네트워크 인터페이스와 라우팅 상태를 복원할 수 있습니다. 그래도 복구되지 않으면 현재 네트워크에서 IP, 게이트웨이, DNS를 자동으로 받아오는지 확인하세요.
시스템 프록시를 켰는데도 일부 앱이 직접 연결되면 어떻게 하나요?
시스템 프록시는 해당 설정을 읽도록 구현된 앱에만 적용됩니다. 일부 명령줄 프로그램, 게임, 자체 네트워크 스택을 사용하는 소프트웨어는 이를 우회할 수 있습니다. 먼저 연결 기록에 앱의 요청이 나타나는지 확인하고, 앱 자체에 프록시가 설정되어 있는지도 점검하세요. 트래픽을 일괄 처리해야 한다면 TUN 모드를 검토할 수 있지만, 요청이 여러 단계로 전달되어 루프나 포트 충돌이 발생하지 않도록 중복된 앱 프록시는 먼저 끄세요.