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

코어는 설정을 읽고 프록시 연결을 수립하며 규칙 매칭과 DNS 처리를 담당합니다. 그래픽 클라이언트는 구독 관리, 정책 전환, 로그 확인 및 시스템 프록시 제어를 담당합니다. mihomo는 Clash 설정 체계를 이어 가는 활발한 코어 구현체로, 많은 최신 클라이언트가 이를 실행 코어로 사용합니다. 문제를 해결할 때는 클라이언트 이름, 코어 유형, 설정 출처를 함께 기록해야 합니다. 인터페이스 문제와 코어 오류는 해결 경로가 다르기 때문입니다.

규칙 모드는 설정의 rules 선언 순서에 따라 요청의 경로를 판단하므로 일상적인 사용에 적합합니다. 글로벌 모드는 대부분의 요청을 현재 선택한 프록시 정책으로 보내 노드를 임시로 확인할 때 유용합니다. 직접 연결 모드는 프록시 노드를 거치지 않고 대상에 직접 접속합니다. 웹사이트가 열리지 않으면 잠시 글로벌 모드로 전환해 비교해 보세요. 글로벌 모드에서는 정상인데 규칙 모드에서만 문제가 생긴다면 시스템 프록시를 반복해서 켜고 끄기보다 규칙 매칭 결과와 정책 그룹 선택을 확인해야 합니다.

구독 링크는 설정 제공자가 호스팅하며, 클라이언트가 주기적으로 다시 요청해 구독 내용을 교체할 수 있습니다. 로컬 YAML 파일은 기기에 저장되고 필드 수정은 사용자가 직접 관리합니다. 구독을 업데이트하면 해당 구독 설정에 직접 수정한 내용이 덮어써지는 경우가 많으므로, 장기적으로 사용할 사용자 규칙은 클라이언트가 지원하는 오버라이드, 병합 또는 스크립트 기능에 넣어야 합니다. 가져오기 전에는 링크가 YAML이나 클라이언트가 지원하는 설정 내용을 반환하는지, 로그인 페이지·오류 페이지·일반 웹페이지를 반환하는 것은 아닌지 확인하세요.

Fake-IP 모드에서는 코어가 먼저 애플리케이션에 예약 주소를 반환한 뒤 내부 매핑으로 원래 도메인을 복원하고 규칙을 적용합니다. 보통 중복 DNS 조회를 줄이면서 도메인 정보를 유지할 수 있습니다. 일부 LAN 기기, 게임, 기업용 프로그램 또는 실제 주소 검증에 의존하는 프로그램은 호환되지 않을 수 있습니다. LAN 접속에 문제가 생기면 먼저 관련 도메인을 fake-ip-filter에 추가하세요. 문제가 광범위할 때는 redir-host로 잠시 전환해 Fake-IP 매핑이 원인인지 비교할 수 있습니다.

먼저 클라이언트 로그에서 최초의 파싱 오류와 해당 줄 번호를 찾은 다음, 그 줄 주변의 들여쓰기·콜론·하이픈·따옴표를 확인하세요. YAML은 공백으로 들여써야 하며 목록 항목의 계층도 일관되어야 합니다. 특수 문자가 포함된 노드 이름이나 비밀번호는 따옴표로 감쌀 수 있습니다. proxies, proxy-groups, rules 등의 필드가 올바른 계층에 있는지도 확인하세요. 설정이 구독 링크에서 온 것이라면 먼저 응답 내용을 확인해 웹페이지 오류 메시지를 YAML로 잘못 가져오는 일을 피해야 합니다.

먼저 브라우저에 구독 주소를 붙여 넣어 내용을 가져올 수 있는지 테스트하고, 응답 상태·파일 내용·로그인 페이지로의 이동 여부를 확인하세요. 브라우저에서도 접속할 수 없다면 설정 제공자에게 링크 상태를 문의해야 합니다. 브라우저에서는 열리지만 클라이언트에서 실패한다면 클라이언트의 네트워크 권한, 프록시 경로, 업데이트 주기와 로컬 캐시를 확인하세요. 실패한 설정 사본을 삭제한 뒤 다시 가져올 수도 있지만, 먼저 오버라이드 규칙을 백업해야 합니다. 응답이 JSON, HTML 또는 빈 텍스트라면 클라이언트가 해당 구독 형식을 지원하는지도 확인하세요.

TUN 모드는 가상 네트워크 인터페이스를 만들고 시스템 라우팅을 수정하므로 일반 시스템 프록시보다 높은 권한이 필요합니다. Windows에서는 서비스 모드가 설치되어 정상적으로 실행 중인지 확인하고, 필요하면 관리자 권한으로 최초 설정을 완료하세요. macOS에서는 네트워크 확장 또는 보조 서비스의 승인이 필요합니다. Linux에서는 일반적으로 CAP_NET_ADMIN, 관리자 권한과 사용 가능한 TUN 장치가 필요합니다. 권한을 수정한 뒤에는 클라이언트를 완전히 종료했다가 다시 실행하고, 방화벽이 새 가상 인터페이스를 차단하지 않는지 확인하세요.

먼저 클라이언트가 실행되지 않은 것인지, 실행은 되었지만 시스템 프록시가 켜지지 않은 것인지 구분하세요. Windows에서는 작업 관리자의 시작 앱 목록에서 항목 상태를 확인하고, 설치 폴더를 옮겨 클라이언트 경로가 무효화되지 않았는지 살펴보세요. macOS에서는 로그인 항목과 백그라운드 항목 권한을 확인하고, Linux에서는 데스크톱 자동 시작 파일이나 사용자 서비스 설정을 확인해야 합니다. 클라이언트는 실행되지만 트래픽을 가로채지 못한다면 시작 후 시스템 프록시 자동 설정 또는 TUN 자동 활성화 옵션이 별도로 켜져 있는지도 확인하세요.

먼저 클라이언트에 표시된 HTTP 또는 mixed 포트가 시스템 프록시 설정의 주소와 포트와 일치하는지 확인하세요. 일반적인 로컬 주소는 127.0.0.1입니다. 그런 다음 브라우저나 애플리케이션이 별도 프록시·확장 프로그램 프록시를 사용하거나 시스템 설정을 무시하는지 확인하세요. 기업 정책, 보안 프로그램 및 다른 프록시 도구가 시스템 프록시를 덮어쓸 수도 있습니다. 다른 네트워크 도구를 종료한 뒤 시스템 프록시를 한 번 껐다가 다시 켜고, 시스템 프록시를 확실히 따르는 브라우저로 테스트하세요. 일부 애플리케이션에서만 문제가 생긴다면 해당 앱의 프록시 동작을 따로 확인해야 합니다.

일부 UWP 앱은 제한된 컨테이너에서 실행되므로 기본적으로 로컬 루프백 프록시에 접근할 수 없습니다. 따라서 데스크톱 브라우저가 정상이어도 스토어 앱의 연결까지 보장되지는 않습니다. 클라이언트에서 제공하는 UWP 루프백 도구를 사용해 인터넷 연결이 필요한 앱만 선택하고 예외를 저장하세요. 영향 범위를 통제할 수 있도록 모든 항목을 한 번에 선택하지 않는 것이 좋습니다. 설정 후 대상 앱을 다시 시작하세요. 그래도 실패한다면 시스템 프록시 포트를 사용할 수 있는지 확인하고, 대상 앱이 QUIC, 별도 DNS 또는 시스템 프록시를 따르지 않는 다른 연결 방식을 사용하는지도 살펴보세요.

지연 시간 테스트 실패가 노드를 완전히 사용할 수 없다는 뜻은 아닙니다. 테스트 주소, 네트워크 출구와 프로토콜 핸드셰이크가 모두 결과에 영향을 줄 수 있습니다. 먼저 기기의 기본 네트워크가 정상인지 확인한 뒤 구독을 업데이트하고, 다른 지역이나 프로토콜의 노드를 선택해 비교하세요. 이어 로그에서 DNS 실패인지, 연결 시간 초과인지, TLS 오류인지, 인증 실패인지 확인합니다. 많은 노드가 동시에 시간 초과되면 로컬 네트워크, 구독 상태 또는 테스트 주소 문제일 가능성이 큽니다. 한 노드만 실패한다면 해당 노드에 연결할 수 없거나 매개변수가 변경되었을 가능성이 더 높습니다.

먼저 문제가 도메인에만 영향을 주는지, IP 주소에도 접속할 수 없는지 구분하세요. IP에는 연결되지만 도메인만 실패한다면 dns.enable, nameserver, fallback, enhanced-mode와 수신 주소를 확인하고, 설정에 지정된 DNS 서버에 현재 네트워크에서 접근할 수 있는지 확인해야 합니다. 시스템에 남아 있는 암호화 DNS, 브라우저 보안 DNS 또는 다른 로컬 DNS 서비스가 Clash DNS를 우회하거나 포트를 점유할 수 있습니다. 수정 후 시스템 DNS 캐시를 삭제하고 대상 앱을 다시 시작한 다음, 로그를 통해 요청이 코어에 들어오는지 확인하세요.