Clash 자주 묻는 질문

Clash Meta는 Clash에서 파생된 코어의 이전 이름이며, 이후 프로젝트명이 mihomo로 변경되었습니다. 코어는 프로토콜 연결, 규칙 매칭, DNS 처리를 담당하고 GUI 클라이언트는 구독 가져오기, 정책 그룹 선택, 시스템 프록시 전환 등의 화면을 제공합니다. 같은 mihomo를 사용하는 클라이언트라도 메뉴 위치와 설정 덮어쓰기 방식은 다를 수 있습니다. 문제를 점검할 때는 클라이언트 이름과 코어 버전을 함께 기록하고, 창에 Clash라고 표시된다는 이유만으로 지원 기능을 판단하지 마세요. 클라이언트를 바꾸기 전에는 설정을 내보내고 사용자 지정 항목을 기록한 뒤 새 클라이언트의 코어 안내를 확인하세요.

클라이언트는 설정을 실행하는 도구입니다. 설치를 마쳤다고 바로 사용할 수 있는 원격 프록시 서비스가 제공되는 것은 아닙니다. 일반적으로 사용 권한이 있는 구독 링크를 가져오거나, 아웃바운드와 정책 그룹, 규칙이 포함된 로컬 설정을 불러와야 합니다. 구독의 유효 기간과 사용량 제한, 서버 상태는 해당 서비스 제공업체가 관리하며 클라이언트를 다시 설치해도 초기화되지 않습니다. 처음 사용할 때는 설정 출처를 확인하고 정책 그룹이 정상적으로 생성됐는지 살펴보세요. 직접 연결 옵션만 보인다면 시스템 프록시를 반복해서 전환하기보다 설정 내용과 가져오기 로그를 확인하세요. 구독 주소에 접근 정보가 포함될 수 있으므로 공개하지 마세요.

구독 링크는 원격 설정을 가져오는 주소이고, Profile은 보통 클라이언트에 저장된 설정 항목을 뜻합니다. YAML은 널리 쓰이는 설정 파일 형식입니다. 구독 응답은 완전한 Clash 설정일 수도 있고 노드 목록만 포함할 수도 있습니다. 노드 목록만 있는 경우에는 클라이언트가 해당 가져오기 방식을 지원해야 하며, 그렇지 않다면 신뢰할 수 있는 도구로 변환해야 합니다. 가져온 뒤에는 정책 그룹과 규칙, DNS 설정이 모두 갖춰졌는지 확인하세요. 원격 업데이트는 구독으로 생성된 내용을 덮어쓰는 경우가 많으므로, 계속 유지할 사용자 지정 규칙은 클라이언트의 덮어쓰기 또는 병합 설정에 넣으세요. 업데이트 때 덮어써질 파일을 직접 수정하지 않는 것이 좋습니다.

규칙 모드는 설정에 정의된 규칙에 따라 연결별 아웃바운드를 선택하므로 평소 트래픽을 목적지별로 분기할 때 적합합니다. 전역 모드는 코어가 처리하는 연결을 모두 전역 정책으로 보내므로 임시 비교 테스트에 유용하지만, 기기의 모든 앱을 제어하는 것은 아닙니다. 직접 연결 모드는 코어가 처리하는 연결을 목적지에 바로 연결해 프록시 아웃바운드 문제를 확인할 때 사용할 수 있습니다. 세 모드 모두 트래픽이 실제로 코어에 들어와야 작동합니다. 앱이 시스템 프록시를 우회하면 모드를 바꿔도 달라지지 않을 수 있습니다. 설정을 바꾼 뒤 새 연결을 만들고 연결 기록을 확인하세요. 기존 장기 연결은 이전 아웃바운드를 계속 사용할 수 있습니다.

먼저 운영체제를 고른 다음 CPU 아키텍처와 설치 파일 형식을 확인하세요. Windows에서는 시스템의 정보 페이지에서 시스템 종류를 볼 수 있고, macOS에서는 이 Mac에 관하여에서 Apple 칩인지 Intel인지 확인할 수 있습니다. Linux는 uname -m으로 아키텍처를 확인한 뒤 배포판에 맞는 패키지를 선택하세요. Android에서는 기기와 클라이언트의 아키텍처 요구 사항을 먼저 확인해야 합니다. 데스크톱 설치 파일이나 코어 압축 파일을 모바일 앱으로 사용하면 안 됩니다. 설치에 실패하면 OS 버전과 오류 전문을 기록하고, 아키텍처 불일치와 낮은 OS 버전, 이전 설치와의 충돌부터 확인하세요. 출처를 알 수 없는 수정 패키지를 연달아 설치하지 마세요.

설정 또는 Profiles 페이지에 전체 구독 주소를 붙여 넣고 가져온 다음, 해당 항목이 현재 설정으로 선택됐는지 확인하세요. 일부 클라이언트는 설정 다운로드와 활성화를 별도 작업으로 처리하므로 목록에 항목이 있다고 해서 코어에 로드된 것은 아닙니다. 이어서 정책 그룹에 예상한 옵션이 표시되는지 확인하고, 로그에 YAML 구문 오류나 지원하지 않는 필드가 없는지 살펴보세요. 로컬 파일을 가져왔다면 원본을 따로 보관하고 외부 규칙 세트와 프록시 목록을 가져올 수 있는지도 확인하세요. 마지막으로 사용 가능한 아웃바운드를 선택해 새 연결을 만든 뒤 적용된 규칙과 정책을 확인하세요.

TUN 모드는 가상 네트워크 인터페이스를 만들고 라우팅을 조정하므로 보통 시스템 프록시보다 높은 권한이 필요합니다. Windows에서는 클라이언트 서비스 모드가 설치되어 실행 중인지 확인한 뒤 안내에 따라 권한을 허용하세요. macOS에서는 시스템 네트워크 확장 또는 보조 서비스의 권한을 확인하고, Linux에서는 클라이언트 문서에 따라 TUN 장치와 필요한 권한을 점검하세요. Android와 iOS에서는 일반적으로 VPN 설정을 승인해야 합니다. 문제 해결을 위해 시스템 보안 기능을 장기간 끄지는 마세요. 계속 실패한다면 다른 VPN이나 네트워크 가로채기 도구를 종료한 뒤 인터페이스, 라우팅, 권한 관련 오류를 확인하세요. 로그를 공유하기 전에는 구독 주소와 인증 정보를 삭제하세요.

iOS 클라이언트는 보통 시스템 네트워크 확장을 통해 트래픽을 처리하므로 처음 연결할 때 VPN 설정 추가를 요청합니다. 권한 요청이 방금 설치한 클라이언트에서 온 것인지 확인한 뒤 시스템 안내에 따라 승인하고, 앱으로 돌아와 설정을 가져온 다음 연결을 시작하세요. 시스템에 VPN 표시가 나타나도 터널이 켜졌다는 뜻일 뿐, 선택한 원격 아웃바운드가 작동한다는 보장은 없습니다. 클라이언트 연결 기록도 함께 확인하세요. 기기가 조직에서 관리된다면 정책에 따라 권한이 제한될 수 있으므로 기기 관리자에게 문의하세요. Clash Plus를 사용한다면 다운로드 페이지에서 App Store로 이동할 수 있으며, 제품 정보는 clashplus.io에서 확인할 수 있습니다.

수동 선택 그룹은 사용자가 아웃바운드 하나를 직접 고정합니다. 자동 테스트 그룹은 보통 지정된 테스트 주소의 응답을 바탕으로 아웃바운드를 선택하고, 장애 조치 그룹은 설정 순서와 사용 가능 여부에 따라 처리합니다. 테스트 결과는 해당 시점에 테스트 대상에 접속한 결과일 뿐, 모든 사이트에서의 실제 사용 경험이나 다운로드 속도를 뜻하지는 않습니다. 특정 사이트 문제를 확인할 때는 수동 선택 그룹으로 같은 노드를 고정해 자동 전환의 영향을 줄여 보세요. 정책 그룹 안에 다른 그룹이 중첩되어 있는지도 확인해야 합니다. 최종 아웃바운드는 현재 화면에 바로 표시된 그룹이 아닐 수 있습니다. 전환한 뒤 새 연결로 결과를 확인하세요.

규칙은 보통 위에서 아래로 평가되며, 처음 일치하는 규칙이 아웃바운드를 결정합니다. 사용자 지정 규칙은 먼저 일치할 수 있는 포괄적인 규칙보다 위에 두고, 대상 정책 이름이 실제 정책 그룹 이름과 일치하는지 확인하세요. 클라이언트에서 덮어쓰기나 병합 기능을 제공한다면 그 기능을 우선 사용하고 규칙이 삽입되는 위치도 확인하세요. 원격 설정을 직접 수정하면 구독 업데이트 때 변경 내용이 사라질 수 있습니다. 저장 후 설정을 다시 불러오고 연결 기록에서 적용된 규칙을 확인하세요. 도메인 규칙은 코어가 도메인을 인식할 수 있어야 합니다. 연결 재사용이나 기존 장기 연결도 확인에 영향을 줄 수 있으므로 테스트 전에 기존 연결을 종료한 뒤 다시 접속하는 것이 좋습니다.

Fake-IP는 도메인에 가상 주소를 할당하고, 코어가 매핑 정보를 이용해 대상을 식별하고 트래픽을 분기합니다. redir-host는 보통 앱에 실제로 해석된 주소를 반환합니다. 모드 이름만 볼 것이 아니라 클라이언트의 DNS 처리 방식과 앱 호환성을 함께 고려하세요. 특정 로컬 네트워크 서비스나 앱에서 문제가 발생하면 먼저 문제가 생긴 도메인을 확인하고, 필요한 경우 fake-ip-filter로 해당 도메인을 제외하세요. 범위를 지나치게 넓게 허용하지 마세요. 모드를 바꾼 뒤에는 시스템과 앱의 DNS 캐시를 비우고 연결을 다시 만들어야 할 수 있습니다. 앱이 자체적으로 암호화 DNS를 사용한다면 현재 설정을 우회해 DNS를 조회하는지도 확인하세요.

LAN 연결 허용을 사용하면 같은 신뢰할 수 있는 네트워크의 다른 기기에서 이 기기의 프록시 포트에 접속할 수 있습니다. 스위치를 켜는 것뿐 아니라 수신 주소와 실제 포트, 시스템 방화벽 규칙도 확인해야 합니다. 다른 기기에는 클라이언트가 실행 중인 기기의 LAN 주소를 입력해야 하며, 자기 기기의 루프백 주소를 입력하면 안 됩니다. 필요한 네트워크와 기기에만 허용하고 공용 네트워크에서는 끄세요. 클라이언트가 지원한다면 접속 인증도 설정하세요. 라우터에서 프록시 포트나 제어 인터페이스를 공용 인터넷에 노출하지 마세요. 연결되지 않으면 네트워크 격리, 방화벽, 포트 수신 상태, 인증 정보를 차례로 확인해야 합니다. 스위치가 켜져 있다는 이유만으로 접속이 가능하다고 판단할 수는 없습니다.

먼저 업데이트 로그의 구체적인 오류를 확인한 뒤 다음 단계를 정하세요. HTTP 401 또는 403이면 인증 정보와 서비스 상태를 확인하고, 404라면 주소가 만료됐거나 경로가 바뀌었을 수 있습니다. 429는 잠시 기다렸다가 다시 시도하세요. 시간 초과, 도메인 해석 실패, TLS 오류는 네트워크와 시스템 시간, 인증서 환경을 먼저 확인해야 합니다. 다운로드는 성공했지만 파싱에 실패했다면 응답이 로그인 페이지나 오류 페이지이거나 호환되지 않는 구독 형식일 수 있습니다. 현재 사용할 수 있는 설정은 보관하고, 클라이언트가 구독을 업데이트할 때 직접 연결과 프록시 중 무엇을 사용하는지 확인한 뒤 다른 경로로도 가져와 보세요. 인증 정보가 포함된 전체 링크를 공개 진단 사이트에 붙여 넣지 마세요.

보통은 재설치보다 문제가 있는 아웃바운드부터 확인하는 것이 좋습니다. 해당 노드를 수동으로 선택하고 로그에서 도메인 해석 실패, 연결 거부, 핸드셰이크 실패, 테스트 시간 초과 중 어떤 오류인지 확인하세요. 구독이 만료됐는지, 서버 매개변수가 변경됐는지도 살펴보세요. 일부 테스트 대상에 접근할 수 없어 시간 초과가 발생해도 실제 접속이 모두 실패한다는 뜻은 아닙니다. 실제 요청으로 함께 판단하세요. 신뢰할 수 있는 다른 네트워크에서도 테스트하면 현재 네트워크 경로와 서버 문제를 구분하는 데 도움이 됩니다. UDP를 사용하는 프로토콜만 문제가 있다면 네트워크가 해당 트래픽을 지원하는지도 확인하세요. 오류를 없애려고 인증서 검증을 함부로 끄지 마세요.

시스템 프록시는 해당 시스템 설정을 따르는 앱에만 영향을 줍니다. 명령줄 도구, 일부 브라우저 설정, 앱 내장 네트워크 스택은 별도의 프록시 설정을 사용할 수 있습니다. 먼저 시스템의 프록시 주소와 포트가 현재 클라이언트와 일치하는지 확인하고, 다른 프로그램이 설정을 반복해서 변경하는지도 살펴보세요. 새 페이지를 열고 클라이언트 연결 기록을 확인하세요. 기록이 전혀 없다면 먼저 트래픽 진입 경로를 확인하고, 기록은 있지만 직접 연결로 처리된다면 모드와 규칙을 점검하세요. 프록시가 적용됐는데 접속이 실패한다면 아웃바운드를 확인해야 합니다. 더 많은 앱의 트래픽을 처리해야 한다면 TUN 모드를 고려할 수 있지만, 먼저 권한과 라우팅 환경을 확인하고 여러 트래픽 가로채기 도구를 동시에 실행하지 마세요.

일부 UWP 앱은 AppContainer의 루프백 접속 제한 때문에 클라이언트가 수신 중인 로컬 프록시 포트에 연결하지 못할 수 있습니다. 먼저 일반 데스크톱 앱에서 같은 프록시를 사용할 수 있는지 확인하고, 대상 앱이 실제로 이 제한의 영향을 받는지 점검하세요. Microsoft Store에서 설치한 앱이 모두 UWP인 것은 아닙니다. 클라이언트에서 제공하는 루프백 예외 도구를 사용하거나 Windows의 CheckNetIsolation 도구 안내에 따라 대상 패키지에 예외를 추가할 수 있습니다. 이 작업에는 보통 관리자 권한이 필요합니다. 예외를 추가한 뒤 앱을 완전히 종료하고 다시 실행한 다음 연결 기록을 확인하세요. 필요한 앱에만 적용하고 더 이상 사용하지 않을 때는 해당 예외를 제거하세요.