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

Clash는 규칙 설정 도구와 그 구성 형식을 가리키는 일반적인 명칭입니다. Clash Meta는 기존 기능에 프로토콜, 규칙 및 DNS 기능을 확장했으며, 이후 핵심 프로젝트의 이름이 mihomo로 변경되었습니다. 여전히 Clash라는 이름을 사용하는 많은 신규 클라이언트는 실제로 mihomo 코어를 사용하므로 인터페이스 명칭은 달라도 구독 가져오기, 정책 그룹 및 규칙 매칭 방식은 대체로 호환됩니다.

일상적인 사용에는 규칙 모드를 우선 선택하세요. 연결은 구성의 rules를 위에서 아래로 매칭한 뒤 DIRECT, REJECT 또는 지정한 정책 그룹으로 전달됩니다. 전체 모드는 대부분의 연결을 하나의 정책 그룹으로 보내므로 규칙 문제를 임시로 확인할 때 적합합니다. 직접 연결 모드는 프록시를 우회하므로 규칙 설정을 잠시 중단할 때 사용할 수 있습니다. 모드를 바꿔도 구독 파일은 수정되지 않지만 현재 연결 처리 방식은 달라집니다.

시스템 프록시는 운영체제의 프록시 설정을 따르는 앱만 제어하며, 대부분의 브라우저와 데스크톱 프로그램이 여기에 해당합니다. TUN 모드는 가상 네트워크 인터페이스를 만들어 시스템 프록시를 읽지 않는 앱, 일부 명령줄 프로그램과 게임도 처리할 수 있습니다. 먼저 시스템 프록시를 사용하는 편이 간단하며, 제어되지 않는 앱이 있을 때 TUN을 활성화하고 시스템 안내에 따라 네트워크 확장 또는 관리자 권한을 허용하세요.

구독 링크는 서버에서 구성을 제공하며, 클라이언트가 설정한 업데이트 주기에 따라 다시 가져올 수 있어 정책과 연결 정보를 지속적으로 동기화해야 할 때 적합합니다. 로컬 config.yaml은 기기에 저장되므로 규칙, DNS 또는 포트를 직접 수정하기 쉽지만 구독 변경 사항이 자동으로 반영되지는 않습니다. 장기간 사용자 설정을 유지하려면 기존 구독을 보존하고 클라이언트의 오버라이드 기능을 사용해 업데이트로 수동 수정 사항이 덮어쓰이지 않도록 하세요.

먼저 구독 링크를 브라우저에 완전히 붙여 넣어 YAML 텍스트가 반환되거나 구성 파일 다운로드가 시작되는지 확인하세요. 로그인 페이지, 오류 페이지 또는 빈 화면이 나타나면 안 됩니다. 이어서 링크 앞뒤에 공백이 섞이지 않았는지, 메신저에서 링크가 잘리지 않았는지, 기기 시간이 정확한지 확인하세요. 그래도 가져오지 못하면 파일로 먼저 다운로드한 뒤 가져오세요. 파일도 해석되지 않는다면 YAML 들여쓰기를 확인하거나 구독 제공업체에 새 링크를 요청해야 할 수 있습니다.

먼저 시스템 프록시와 TUN을 잠시 끈 다음 구독 업데이트를 다시 실행해, 기존 규칙이 구독 도메인을 사용할 수 없는 정책 그룹으로 전달하는지 확인하세요. 구독 주소가 변경되지 않았는지, 현재 네트워크에서 해당 주소에 직접 접속할 수 있는지, 클라이언트에 구성 디렉터리 쓰기 권한이 있는지 확인합니다. 업데이트가 완료되면 구성 파일을 다시 선택하고, 화면에 표시된 현재 구성이 방금 업데이트한 파일인지 확인하세요.

Windows에서는 클라이언트가 관리자 권한으로 서비스를 설치하거나 시작하도록 허용해야 합니다. macOS에서는 시스템 설정에서 네트워크 확장을 승인하고 VPN 구성 추가를 허용해야 합니다. Linux에서는 일반적으로 코어에 TUN 인터페이스 생성 및 라우팅 변경 권한을 부여해야 합니다. 권한을 승인한 뒤 클라이언트를 완전히 종료하고 다시 시작하세요. 시스템에 이전 서비스가 남아 있다면 클라이언트에서 TUN을 끄고 기존 서비스를 제거한 다음 서비스를 다시 설치하세요.

모바일 운영체제에서는 일반적으로 하나의 앱만 VPN 채널을 사용할 수 있습니다. 다른 프록시, 기업용 VPN, 광고 차단기 또는 비공개 DNS 앱이 만든 VPN을 먼저 끊은 뒤 Clash 호환 클라이언트에서 다시 연결하세요. Android에서는 항상 켜짐으로 설정된 VPN이 다른 앱에 연결되어 있는지도 확인해야 하며, iOS에서는 시스템 VPN 목록에서 현재 활성화된 구성을 확인할 수 있습니다. 클라이언트를 바꾸기 전에는 기존 연결을 직접 끊으세요.

Clash 규칙은 위에서 아래로 매칭되며, 처음 일치한 규칙에서 중단됩니다. 사용자 지정 규칙이 더 포괄적인 규칙 세트와 MATCH보다 앞에 있는지 먼저 확인한 다음 DOMAIN, DOMAIN-SUFFIX, IP-CIDR 등의 유형이 대상과 일치하는지 점검하세요. 수정 후에는 구성을 다시 불러와야 합니다. 연결 세부 정보나 로그에서 실제로 일치한 규칙을 확인하면 문제 원인이 규칙 순서인지, 도메인 해석인지, 프로세스가 제어되지 않은 것인지 판단할 수 있습니다.

먼저 시스템 프록시 주소가 클라이언트의 현재 mixed-port 또는 HTTP 포트를 가리키는지 확인하고, 해당 포트를 다른 프로그램이 사용 중인지 점검하세요. 일부 앱은 별도의 프록시 설정을 사용하거나 시스템 프록시를 무시하며, UDP 연결을 직접 시작하는 경우도 있어 시스템 프록시만으로는 제어할 수 없습니다. 앱에서 프록시 주소를 직접 입력하거나 TUN 모드로 전환하세요. 변경 후에는 대상 앱을 다시 시작해 기존 연결이 계속 재사용되지 않도록 합니다.

UWP 앱은 기본적으로 로컬 루프백 제한을 적용받아 127.0.0.1에서 실행 중인 프록시 포트에 접근하지 못할 수 있습니다. 클라이언트에서 제공하는 UWP 루프백 도구를 사용해 인터넷 연결이 필요한 스토어 앱에 루프백 예외를 적용한 뒤 저장하고 앱을 다시 시작하세요. 모든 시스템 구성 요소를 한꺼번에 선택하지 마세요. 클라이언트에 해당 메뉴가 없다면 TUN 모드를 활성화해 가상 인터페이스로 트래픽을 처리할 수 있습니다.

Fake-IP는 먼저 예약 주소를 반환한 뒤 코어가 도메인을 복원하고 규칙을 적용합니다. 로컬 네트워크 기기, 프린터, 화면 공유 장치 또는 실제 DNS 결과에 의존하는 앱에서 문제가 발생하면 해당 도메인을 fake-ip-filter에 추가하고 사설 주소에는 DIRECT 규칙을 유지하세요. DNS 구성을 수정한 뒤 시스템 DNS 캐시를 삭제하고 대상 앱을 다시 시작합니다. 문제가 광범위하면 redir-host로 잠시 전환해 비교 테스트하세요.

먼저 다른 네트워크로 전환해 현재 Wi-Fi, 모바일 네트워크 또는 방화벽이 차단 원인이 아닌지 확인하세요. 그런 다음 클라이언트 시간, 구독 업데이트 시간 및 노드 프로토콜에 필요한 시스템 구성 요소를 점검합니다. 단일 노드만 시간 초과라면 대개 노드 상태 문제입니다. 모든 노드가 동시에 시간 초과라면 DNS, 코어 시작, 포트 충돌 또는 구독 만료일 가능성이 더 큽니다. 로그의 timeout, refused 또는 DNS error를 확인하면 연결 단계별로 원인을 구분할 수 있습니다.

먼저 아직 사용할 수 있는 로컬 구성을 삭제하지 마세요. 복구할 수 있는 경로가 사라질 수 있습니다. 브라우저에서 구독 주소에 직접 접속해 링크가 만료되지 않았는지, 계정 상태가 정상인지, 반환된 내용이 여전히 Clash 구성인지 확인하세요. 서버가 로그인 페이지, 안내 문구 또는 빈 파일을 반환하면 클라이언트가 이를 프록시 목록으로 해석할 수 없습니다. 새 링크를 받은 뒤 별도의 구성으로 추가하고, 작동을 확인한 다음 기존 구성을 제거하세요.

대개 시스템 프록시 또는 TUN 라우팅이 원래대로 복원되지 않은 경우입니다. 클라이언트를 다시 시작하고 시스템 프록시와 TUN을 먼저 끈 다음 메뉴에서 정상적으로 종료하세요. 클라이언트를 시작할 수 없다면 운영체제 네트워크 설정에서 수동 프록시를 끄고 남아 있는 프록시 주소를 삭제하세요. 그다음 네트워크 연결을 끊었다가 다시 연결합니다. 그래도 복구되지 않으면 기기를 재시작해 가상 인터페이스, 라우팅 테이블 및 DNS 설정을 다시 초기화하세요.

먼저 직접 연결 모드로 전환해 기본 네트워크가 정상인지 확인한 뒤 규칙 모드로 돌아와 정책 그룹을 바꿔 보세요. 이어서 로그에 DNS 해석 실패, 연결 거부 또는 시간 초과가 나타나는지 확인하고 현재 구성, 시스템 프록시 포트 및 실행 중인 코어가 서로 일치하는지 점검합니다. 브라우저에서만 문제가 발생하면 브라우저의 독립 프록시 또는 보안 DNS를 끄고 다시 시도하세요. 모든 앱에서 문제가 발생하면 구독, DNS, TUN 라우팅 및 로컬 방화벽을 우선 확인합니다.