Clash 자주 묻는 질문
문제 해결

Clash는 규칙 기반 프록시 생태계에서 널리 쓰이는 프로젝트 이름입니다. Clash Meta는 관련 코어 브랜치의 이전 이름이며, 이후 이 브랜치는 mihomo라는 이름을 사용하게 됐습니다. 클라이언트는 구독 관리, 정책 선택, 시스템 네트워크 설정 등을 위한 그래픽 인터페이스를 제공합니다. 인터페이스에서 옵션을 지원하더라도 코어에서 해당 기능이 활성화된다는 뜻은 아닙니다. 설정 파일을 불러올 수 있는지는 코어 버전과 지원 필드에 따라 달라집니다. 설정 오류가 발생하면 클라이언트의 정보 또는 코어 화면에서 실제 사용 중인 코어를 확인한 뒤 해당 문서를 참고하세요. 설치 파일 이름만으로 호환 여부를 판단하지 마세요.

클라이언트는 설정을 읽고 연결을 전달하는 프로그램이며, 그 자체가 사용 가능한 프록시 서비스는 아닙니다. 원격 프록시를 이용하려면 보통 서비스 제공자가 발급한 구독을 가져오거나 유효한 서버 정보를 직접 입력해야 합니다. 직접 연결 규칙만 사용할 때는 원격 노드가 필요하지 않습니다. 구독에는 노드, 정책 그룹, 규칙, DNS 설정이 포함될 수도 있고 노드 목록만 들어 있을 수도 있습니다. 가져오기 전에 형식과 사용 기간을 확인하세요. 구독 주소에는 접근 인증 정보가 포함되는 경우가 많으므로 공개 댓글이나 스크린샷, 온라인 변환 서비스에 올리지 마세요. 도움을 요청할 때는 민감한 정보를 가린 오류 메시지만 공유하세요.

일반적으로는 규칙 모드를 사용해 rules에 지정된 순서대로 연결에 정책을 적용합니다. 전역 모드는 코어로 들어오는 일반 연결에 전역 정책을 적용하지만, 사용 가능한 노드를 선택해야 합니다. 모든 앱의 트래픽이 자동으로 코어를 거치는 것은 아닙니다. 직접 연결 모드는 네트워크 상태를 잠시 비교할 때 유용하지만, 설정된 DNS와 TUN 라우팅, 앱 자체 프록시가 테스트 결과에 영향을 줄 수 있습니다. 문제를 진단할 때는 기존 모드를 기록하고 한 번에 설정 하나만 바꾼 뒤 연결을 새로 만드세요. 전역 모드로 바꾸는 것을 구독, 권한 또는 시스템 프록시 문제의 만능 해결책으로 여기지 마세요.

시스템 프록시는 로컬 프록시 주소를 운영체제 설정에 등록해 해당 설정을 따르는 브라우저와 앱에서 사용합니다. 일부 프로그램은 시스템 프록시를 무시할 수 있습니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 설정 범위에 해당하는 IP 트래픽을 처리합니다. 더 많은 앱의 트래픽을 다루는 데 적합하지만 권한, 라우팅, DNS 설정이 필요합니다. 처음 설정할 때는 시스템 프록시로 구독과 노드가 정상인지 확인한 뒤 필요에 따라 TUN을 켜세요. 두 기능을 함께 사용할 수 있는지는 클라이언트 구현에 따라 다릅니다. 스위치를 더 많이 켠다고 적용 범위가 반드시 넓어지는 것은 아니며, 오히려 문제 진단이 복잡해질 수 있습니다.

오류가 다운로드 단계에서 발생했는지 파싱 단계에서 발생했는지 먼저 확인하세요. 다운로드 실패라면 전체 주소, 접근 권한, 현재 네트워크를 확인합니다. 파싱 실패라면 응답 내용이 YAML 설정인지 살펴보세요. 로그인 페이지나 오류 페이지, Base64로 인코딩된 노드 목록이 반환된 것일 수 있습니다. 알 수 없는 필드나 지원하지 않는 프로토콜이라는 메시지가 뜨면 mihomo 코어와 클라이언트의 지원 범위를 확인하세요. 이미 작동하는 설정을 반복해서 덮어쓰지 말고, 먼저 사본을 보관한 뒤 새 설정으로 테스트하세요. 형식이 호환되지 않으면 구독 제공자에게 호환 버전을 요청하세요. 인증 정보가 담긴 구독을 공개 변환 서비스에 직접 입력하지 마세요.

먼저 TUN을 끄고 클라이언트에 서비스 모드, 보조 서비스 또는 권한 설치 메뉴가 있는지 확인하세요. Windows에서는 보통 클라이언트 안내에 따라 서비스를 설치하거나 권한을 높여야 합니다. macOS에서는 보조 구성요소를 허용해야 할 수 있으며, Linux의 권한 요구 사항은 설치 방식과 배포판에 따라 다릅니다. 권한 설정을 마친 뒤 관련 서비스를 다시 시작하고 TUN을 켜세요. 로그에서 가상 네트워크 인터페이스와 라우팅이 정상적으로 생성됐는지 확인합니다. 오류를 없애려고 시스템 보안 기능을 계속 꺼 두지 마세요. 문제가 계속되면 다른 VPN이나 가상 네트워크 도구를 종료하고, 임시 연결 수단으로 시스템 프록시를 사용하세요.

Android 클라이언트는 보통 VpnService로 로컬 VPN 인터페이스를 만들고, 선택한 앱의 연결을 프록시 코어에 전달합니다. 따라서 처음 실행할 때 시스템 권한이 필요합니다. 권한을 허용해도 구독이 자동으로 유효해지는 것은 아닙니다. 설정을 가져오고 사용 가능한 정책을 선택해야 합니다. 다른 VPN에 연결되어 있다면 먼저 연결을 해제하세요. 일반적으로 같은 사용자 프로필에서는 이러한 VPN 두 개를 동시에 실행할 수 없습니다. 권한 요청이 반복되면 업무 프로필, 상시 VPN, VPN 미사용 시 연결 차단 등의 설정을 확인하고 현재 클라이언트가 실제로 적용 중인지 확인한 다음 다시 연결하세요.

부팅 시 자동 실행, 코어 시작, 시스템 프록시 복원은 서로 다른 설정입니다. 먼저 클라이언트에서 로그인 후 실행을 켠 다음, 마지막 설정을 자동으로 불러올지, 정책을 복원할지, 필요한 네트워크 모드를 활성화할지 각각 확인하세요. TUN은 백그라운드 서비스가 먼저 시작되어야 할 수 있으므로 시작 바로가기만 추가해서는 충분하지 않습니다. 설정을 마친 뒤 기기를 완전히 재부팅하고 설정 이름, 실행 상태, 프록시 스위치를 확인하세요. 여러 사람이 사용하는 기기에서는 사용자별로 설정해 다른 계정이 부적절한 프록시를 이어서 사용하지 않도록 하세요. 종료 후 네트워크에 문제가 생기면 시스템 프록시를 먼저 끄고 백그라운드 코어가 계속 실행 중인지 확인하세요.

구독으로 생성된 설정 파일을 직접 수정하면 다음 업데이트 때 원격 내용으로 덮어써지는 경우가 많습니다. 규칙을 계속 유지하려면 클라이언트가 지원하는 오버라이드, 병합 또는 스크립트 기능을 사용하세요. 클라이언트마다 규칙을 추가하거나 교체하는 방식이 다르므로 설정 전에 설명서를 확인해야 합니다. 수정 후에는 최종 적용 설정을 확인해 사용자 지정 규칙이 MATCH 앞에 있는지, 참조하는 정책 그룹이 실제로 존재하는지 확인하세요. 도메인 규칙 하나로 먼저 검증한 뒤 점차 늘리세요. 업데이트 후 설정 전체를 불러오지 못하면 오버라이드를 비활성화해 연결을 복구한 다음 로그에서 충돌 필드를 찾으세요.

규칙은 위에서 아래로 확인하며 먼저 일치하는 규칙이 정책을 결정합니다. 뒤에 있는 규칙은 같은 연결의 선택에 더 이상 참여하지 않습니다. 먼저 연결 기록을 열어 대상 도메인, 일치한 규칙, 최종 정책 그룹을 확인하고 정책 그룹에서 현재 어떤 노드를 선택했는지 살펴보세요. 연결에 IP 주소만 표시되면 도메인 규칙을 적용하는 데 필요한 정보가 없을 수 있으므로 DNS와 도메인 스니핑 설정을 함께 확인하세요. 규칙을 수정한 뒤에는 해당 앱의 기존 연결을 끊고 다시 시도하세요. 이미 연결된 트래픽은 이전 경로를 계속 사용할 수 있습니다. 규칙 파일에 도메인이 적혀 있는지만 보지 말고 해당 파일이 실제로 불러와졌는지도 확인하세요.

기기를 같은 신뢰할 수 있는 LAN에 연결하고, 컴퓨터의 클라이언트에서 LAN 연결 허용을 켜세요. 수신 주소가 컴퓨터에서만 접근할 수 있는 루프백 주소로 설정되어 있지 않은지도 확인합니다. 그런 다음 휴대폰이나 TV의 네트워크 프록시 설정에 컴퓨터의 LAN IP와 혼합 포트를 입력하세요. 포트 번호는 현재 설정을 기준으로 합니다. 컴퓨터 방화벽은 필요한 LAN 범위에만 접근을 허용해야 합니다. 수동 HTTP 프록시는 보통 해당 설정을 따르는 앱만 처리하며 기기 전체 트래픽을 의미하지는 않습니다. 사용이 끝나면 공유를 끄고, 혼합 포트나 외부 제어 포트를 공용 인터넷에 직접 노출하지 마세요.

Fake-IP 모드에서는 코어가 DNS 조회에 합성 주소를 반환하고, 내부 매핑을 통해 이후 연결을 도메인과 연결합니다. 원격 노드 주소도 실제 웹 서버 주소도 아닙니다. 일부 LAN 기기 검색이나 기기 제어 기능, 실제 IP에 의존하는 앱은 별도로 처리해야 할 수 있습니다. 이 경우 해당 도메인에 맞게 fake-ip-filter를 설정하고 현재 코어의 필터 모드를 확인하세요. 모든 도메인을 필터 목록에 넣으면 DNS 전체 동작 방식이 달라지므로 피해야 합니다. 설정을 조정한 뒤 앱 연결을 새로 만들고 DNS 로그와 로컬 기기 접근이 복구됐는지 확인하세요.

401 또는 403은 보통 접근 인증 정보, 권한 또는 서버 측 접근 정책에 문제가 있음을 나타냅니다. 서비스 제공자의 관리 페이지에 로그인해 구독 상태를 확인하고 주소가 재설정됐는지도 살펴보세요. 이 상태 코드만으로 계정이 만료됐다고 단정할 수는 없습니다. 시간 초과가 발생하면 로컬 네트워크와 도메인 조회를 확인하고 업데이트 요청이 이미 작동하지 않는 프록시에 의존하는지 살펴보세요. 우선 이전 설정을 보관하고 모든 노드를 삭제하지 마세요. 클라이언트에서 구독 업데이트 방식을 선택할 수 있다면 직접 연결과 이미 사용 가능한 프록시를 각각 테스트하세요. 오류 발생 시각을 기록해 제공자에게 전달하고, 문의할 때는 구독 주소를 가리세요.

먼저 프록시를 일시 중지하고 평소 직접 접속하는 웹사이트를 열어 기본 네트워크가 작동하는지 확인하세요. 시스템 시간과 구독 유효 여부도 살펴봅니다. 클라이언트의 연결 테스트 결과는 테스트 주소와 방식에 따라 달라지므로, 전부 시간 초과가 발생해도 모든 노드가 오프라인이라는 뜻은 아닙니다. 노드 하나를 선택해 대상 웹사이트에 직접 접속하면서 로그를 확인하세요. 도메인 조회 실패라면 DNS를 먼저 점검하고, 연결 거부나 핸드셰이크 실패라면 서버, 포트, 프로토콜, 인증 정보를 확인합니다. 특정 웹사이트만 문제가 있다면 일치한 규칙과 대상 사이트도 살펴보세요. 바로 클라이언트를 다시 설치하거나 설정 전체를 지우지는 마세요.

먼저 코어가 혼합 포트에서 정상적으로 연결을 수신하는지 확인한 다음 운영체제의 프록시 주소와 포트가 클라이언트 설정과 일치하는지 살펴보세요. 7890은 흔히 사용하는 값일 뿐 고정 필수 포트는 아닙니다. 로그에 address already in use가 표시되면 해당 포트를 사용하는 프로세스를 찾아 다른 프록시 인스턴스인지 확인하세요. 중복 인스턴스를 종료하거나 사용 가능한 포트로 변경하면 됩니다. 변경 후에는 수동 프록시, 브라우저 확장 프로그램, 환경 변수 설정도 함께 업데이트하세요. 코어가 정상 작동한다면 브라우저가 별도의 프록시를 사용하거나 조직 정책으로 관리되는지 확인합니다. 정체를 모르는 시스템 프로세스를 함부로 종료하거나 외부 제어 포트를 프록시 포트로 입력하지 마세요.

앱이 네트워크 격리 제한이 적용되는 AppContainer에 속하고 로컬 루프백 프록시에 연결해야 한다면 별도로 루프백 예외를 설정해야 할 수 있습니다. 모든 스토어 앱에 해당하는 것은 아닙니다. 먼저 앱이 시스템 프록시를 사용하는지 확인하세요. 구독 노드나 앱 자체 서비스에 문제가 있는 것은 아닌지 살펴봅니다. 관리자 터미널에서 CheckNetIsolation LoopbackExempt -s를 실행해 기존 예외를 확인한 뒤 클라이언트에서 제공하는 도구로 필요한 앱에만 권한을 부여할 수 있습니다. TUN도 트래픽을 처리하는 다른 방법이지만 라우팅과 DNS를 올바르게 설정해야 합니다. 모든 앱에 일괄적으로 예외를 적용하지 말고 문제 해결 후 불필요한 권한은 해제하세요.