Clash 자주 묻는 질문과 문제 해결

Clash는 규칙 기반 트래픽 분배와 정책 그룹을 중심으로 하는 프록시 설정 체계입니다. 코어는 설정을 읽고 연결을 수립하며 DNS와 라우팅 규칙을 실행합니다. 그래픽 클라이언트는 구독 가져오기, 모드 전환, 로그 확인, 시스템 프록시 제어를 담당합니다. 클라이언트를 선택할 때는 사용하는 코어, 운영체제 지원 범위, 설정 필드 호환성을 함께 확인해야 합니다.

기본 Clash는 설정 구조와 규칙 모델의 기반을 마련했고, Clash Meta는 이를 바탕으로 프로토콜, DNS, 규칙, 투명 프록시 기능을 확장했습니다. 이후 프로젝트 이름은 mihomo로 변경되었습니다. 많은 최신 클라이언트가 mihomo 코어를 사용하지만, 인터페이스 이름에는 여전히 Clash가 남아 있습니다. 일반적인 기본 필드는 계속 사용할 수 있는 경우가 많지만, 확장 필드는 해당 코어의 지원 여부를 확인해야 합니다.

일상적인 사용에는 도메인, IP, 규칙 집합에 따라 직접 연결 또는 프록시를 결정하는 규칙 모드를 우선 사용하세요. 글로벌 모드는 대부분의 연결을 현재 선택한 정책으로 전달하므로 특정 노드의 작동 여부를 임시로 확인할 때 적합하지만, 장기간 문제 해결의 기준으로 삼기에는 적절하지 않습니다. 직접 연결 모드는 프록시를 우회하므로 문제가 프록시 경로 또는 설정 규칙에서 비롯되었는지 확인할 때 유용합니다.

클라이언트는 주로 설정 구문 분석, 규칙 기반 트래픽 분배, 연결 관리 기능을 제공하며 구독 서비스 자체는 아닙니다. 구독 주소, 노드 사용 가능 여부, 트래픽 용량, 만료일은 해당 서비스 제공자가 관리합니다. 출처가 불분명한 공개 설정을 가져오기 전에는 관리 상태, 데이터 처리 방식, 이용 조건을 확인하고 신뢰할 수 없는 경로로 민감한 정보를 전송하지 마세요.

구독은 일반적으로 업데이트 가능한 원격 주소이며, 전체 설정이나 노드 목록을 반환합니다. 설정 파일은 클라이언트가 실제로 불러오는 YAML 내용으로, DNS, 규칙, 정책 그룹이 포함될 수 있습니다. 노드는 설정 안에 있는 연결 항목일 뿐입니다. 구독을 업데이트하면 관련 내용이 다시 생성되거나 덮어써질 수 있으므로, 장기간 사용자 지정 규칙을 유지하려면 오버라이드 기능을 사용하거나 별도의 사본을 보관하세요.

먼저 가져오기 결과에 성공 메시지가 표시되었는지 확인한 다음, 설정 목록에 새 설정이 실제로 생성되었는지 확인하세요. 설정은 존재하지만 정책 그룹이 비어 있다면 구독이 빈 내용을 반환했거나, 링크가 만료되었거나, 설정이 아닌 웹페이지가 반환되었거나, 클라이언트가 해당 구독 형식을 지원하지 않거나, 특정 필드에서 설정 구문 분석이 중단된 경우가 흔합니다. 업데이트 기록과 코어 로그를 함께 확인해 정확한 오류 행을 찾아야 합니다.

먼저 브라우저나 서비스 제공자 콘솔에서 구독 주소가 유효하고 만료되지 않았는지 확인한 뒤, 시스템 시간, 네트워크 연결, 주소가 빠짐없이 복사되었는지 점검하세요. 이어서 클라이언트 업데이트 로그를 확인해 연결 시간 초과, 인증서 오류, 권한 거부, YAML 구문 분석 실패를 구분합니다. 기존 설정이 계속 작동한다면 먼저 이전 사본을 보관하고, 원인을 찾기 전에 모든 설정을 연속해서 삭제하지 마세요.

TUN 모드는 가상 네트워크 인터페이스를 만들고 시스템 라우팅을 변경하므로 일반적으로 관리자 권한이나 관련 서비스 설치가 필요합니다. Windows에서는 서비스 모드가 올바르게 설치되었는지 확인하고, macOS에서는 시스템 확장 프로그램 또는 네트워크 권한을 확인하세요. Linux에서는 실행 사용자 권한, TUN 장치, 관련 capability 설정을 점검해야 합니다. 권한을 수정한 뒤에는 클라이언트를 완전히 종료하고 다시 시작하세요.

먼저 브라우저가 별도의 프록시 설정을 사용하거나 확장 프로그램 또는 보안 소프트웨어가 네트워크를 제어하고 있는지 확인하세요. 다음으로 시스템 프록시 주소와 포트가 클라이언트의 수신 대기 포트와 일치하는지 확인하고, 코어가 실행 중인지 점검합니다. 일부 앱은 시스템 프록시를 읽지 않으므로 앱 내 프록시, TUN 모드 또는 다른 시스템 수준의 연결 방식이 필요할 수 있습니다. 화면의 스위치를 켜는 것만으로 모든 프로그램이 프록시를 사용하는 것은 아닙니다.

일부 UWP 앱은 로컬 루프백 격리 제한으로 인해 같은 기기의 주소에서 실행 중인 프록시 포트에 직접 연결하지 못합니다. 이 기능을 지원하는 클라이언트에서 UWP 루프백 도구를 열고 인터넷 연결이 필요한 앱을 선택한 뒤 저장하세요. 설정 후 대상 앱을 다시 시작합니다. 앱 업데이트로 ID가 바뀌었다면 선택 상태를 다시 확인해야 할 수 있습니다. 관련 없는 모든 시스템 구성 요소를 한꺼번에 선택하지 마세요.

글로벌 모드는 보통 GLOBAL이라는 정책 그룹을 사용하지만, 실제 이름은 설정에 따라 다를 수 있습니다. 프록시 또는 정책 화면에서 해당 그룹이 사용할 수 없는 자동 선택 그룹이 아니라 특정 노드를 가리키는지 확인하세요. 선택할 때 한 번의 지연 시간 결과만 보지 말고 대상 웹사이트, 연결 안정성, 지속적인 전송 성능도 테스트해야 합니다. 확인이 끝나면 규칙 모드로 돌아가도 됩니다.

지연 시간 테스트는 대개 지정된 테스트 주소까지의 짧은 연결만 확인하므로 DNS, TLS, 대상 웹사이트까지의 경로가 모두 정상이라는 뜻은 아닙니다. 정책 그룹에서 해당 노드를 선택했는지, DNS가 사용 가능한 주소를 반환하는지, 규칙이 대상 도메인을 예상한 정책으로 분류하는지, 노드가 특정 프로토콜을 제한하는지 순서대로 확인하세요. 로그의 규칙 일치 결과, 연결 오류, DNS 기록이 한 번의 지연 시간 수치보다 더 유용합니다.

클라이언트의 연결 기록이나 실시간 로그를 연 다음 대상 웹사이트에 접속해 도메인, 대상 주소, 적용된 규칙, 최종 정책을 확인하세요. 최신 웹페이지는 보통 기본 도메인뿐 아니라 정적 리소스 도메인과 서드파티 API도 함께 요청하므로 여러 연결을 확인해야 합니다. 결과가 예상과 다르면 정책 그룹 이름만 바꾸지 말고 규칙 순서나 오버라이드 내용을 조정하세요.

원격 구독을 업데이트하면 구독 설정이 다시 기록되는 경우가 많아, 그 안의 규칙, DNS, 정책 그룹을 직접 수정하면 덮어써질 수 있습니다. 먼저 클라이언트가 제공하는 오버라이드, 확장 스크립트, 설정 병합, 로컬 규칙 집합 기능을 사용하세요. 이러한 기능이 없다면 별도의 로컬 설정으로 복사하고 출처를 기록해야 합니다. 수정 전에는 정상 작동하는 버전을 보관해 구문 분석 실패 시 되돌릴 수 있도록 하세요.

모바일에서 VPN이나 TUN 인터페이스를 계속 실행하면 배터리가 일부 소모됩니다. 상태 확인 간격을 지나치게 짧게 설정하지 말고, 자주 업데이트되는 규칙과 로그를 대량으로 동시에 사용하지 않으며, 실제 필요에 맞는 프로토콜과 모드를 선택하세요. Android에서는 배터리 최적화, 백그라운드 실행, 상시 알림 권한도 확인해야 합니다. iOS의 백그라운드 동작은 시스템이 관리하므로 네트워크가 전환된 뒤 연결 상태를 다시 확인할 수 있습니다.

먼저 직접 연결 모드로 전환해 기본 네트워크가 정상인지 확인한 다음, 규칙 모드로 돌아가 현재 설정이 정상적으로 로드되었는지 확인하세요. 이어서 정책 그룹이 만료된 노드를 선택하지 않았는지, 시스템 프록시 또는 TUN 상태가 예상과 일치하는지 확인하고, 접속 중 연결 로그가 생성되는지 관찰합니다. 로그에 새 기록이 전혀 없다면 트래픽이 클라이언트로 들어오지 않는 것이 원인일 가능성이 큽니다. 오류 기록이 있다면 DNS, 규칙, 노드 경로를 순서대로 점검하세요.

먼저 동일한 설정에 포함된 여러 노드를 테스트하세요. 모두 시간 초과가 발생하면 로컬 네트워크, DNS, 시스템 시간, 방화벽, 클라이언트 수신 대기 상태를 우선 확인해야 합니다. 일부 노드에서만 시간 초과가 발생한다면 노드 주소, 포트 또는 회선 이상일 가능성이 높습니다. 네트워크 환경을 바꿔 다시 테스트하는 방법도 있습니다. 지연 시간 테스트를 연속으로 빠르게 클릭하면 불필요한 동시 연결이 발생하므로 한 차례가 끝난 뒤 결과를 비교하세요.

먼저 클라이언트 로그 디렉터리를 찾아 인터페이스 프로세스가 충돌한 것인지 코어 시작에 실패한 것인지 확인하세요. 흔한 원인으로는 마지막에 가져온 설정의 문법 오류, 설정 디렉터리 권한 문제, 코어 파일 누락, 이전 버전의 잔류 프로세스가 포트를 점유한 경우, 시스템 구성 요소 부족 등이 있습니다. 최근 설정을 잠시 다른 곳으로 옮긴 뒤 다시 시작해 볼 수 있지만, 데이터를 전부 삭제하지는 마세요. 로그와 이전 설정이 복구에 도움이 됩니다.

로그에 표시된 행 번호와 필드 이름을 기록하고 들여쓰기, 콜론, 따옴표, 중복 키, 목록 형식을 먼저 확인하세요. 문법은 올바른데 알 수 없는 필드라는 메시지가 나온다면 현재 코어 버전이 해당 확장 설정을 지원하지 않는 경우가 많습니다. 호환되는 코어로 업데이트하거나 구독 제공자에게 형식 수정을 요청하고, 호환되지 않는 필드를 제거할 수 있습니다. 하나의 오류를 우회하려고 DNS나 규칙 블록 전체를 무작정 삭제하지 마세요.

먼저 로컬 네트워크 대역이 규칙에서 직접 연결로 지정되었는지 확인하고, TUN 라우팅이 로컬 네트워크 주소까지 포함하는지 점검하세요. 일반적인 사설 네트워크 대역과 localhost는 보통 직접 연결로 유지해야 하지만, 실제 네트워크에서는 사용자 지정 주소 범위를 사용할 수도 있습니다. 다른 장치에서 이 기기의 프록시나 개발 서버에 접근해야 한다면 LAN 연결 허용 여부, 수신 대기 주소, 시스템 방화벽도 확인하세요. 포트를 열기 전에는 접근 범위를 명확히 정해야 합니다.