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

Clash는 일반적으로 프록시 설정 문법과 규칙 기반 라우팅 체계를 가리킵니다. Mihomo는 이 설정 생태계를 이어 가는 코어로서 프록시 연결, 규칙 매칭, DNS 처리 및 TUN 인터페이스 생성을 담당합니다. Clash Verge Rev, Clash Plus 같은 그래픽 클라이언트는 구독 가져오기, 노드 선택, 시스템 프록시 전환 및 로그 확인을 담당합니다. 문제를 해결할 때는 먼저 원인이 클라이언트 화면, 코어 프로세스, 설정 파일 또는 상위 노드 중 어디에 있는지 구분해야 합니다.

규칙 모드는 설정 파일의 rules를 위에서 아래로 매칭하고 트래픽을 지정된 정책 그룹으로 전달합니다. 전역 모드는 일반적으로 Clash가 가로챈 모든 연결을 하나의 프록시 정책으로 보냅니다. 직접 연결 모드에서는 가로챈 연결이 대상에 직접 접속합니다. 일상적인 사용에는 규칙 모드를 우선 사용하세요. 규칙이 잘못 라우팅되는지 확인할 때만 잠시 전역 모드로 전환해 비교 테스트하는 것이 좋습니다.

전역 모드는 이미 Clash에 들어온 트래픽에만 영향을 주며, 기기의 모든 연결을 강제로 가로챈다는 뜻은 아닙니다. 시스템 프록시를 따르지 않는 프로그램, 독립 네트워크 스택을 사용하는 게임, 일부 명령줄 도구와 로컬 네트워크 통신은 시스템 프록시를 우회할 수 있습니다. 먼저 시스템 프록시가 켜져 있는지 확인한 뒤 프로그램 자체의 프록시 설정을 점검하세요. 더 많은 TCP·UDP 트래픽을 가로채야 한다면 권한과 라우팅 설정을 확인한 후 TUN 모드를 사용할 수 있습니다.

Clash for Windows는 유지 보수가 중단되었습니다. 기존 설치본은 계속 실행될 수 있지만 호환성 수정과 코어 업데이트가 지속적으로 제공되지는 않습니다. 기존 설정을 이전하기 전 구독 주소, 오버라이드 규칙 및 정책 선택 기록을 보관하고, 현재 유지 관리되는 클라이언트로 전환하세요. 오래된 프로그램 폴더 전체를 새 클라이언트에 그대로 덮어쓰면 안 됩니다. 클라이언트마다 설정 저장 위치, 코어 필드 및 오버라이드 방식이 다를 수 있습니다.

먼저 구독 업데이트 기록을 열어 서버가 로그인 페이지, 안내 페이지 또는 빈 내용이 아니라 Clash 설정을 반환했는지 확인하세요. 그런 다음 파싱 오류가 발생한 줄을 확인하고 proxies, proxy-groups 및 rules의 들여쓰기와 필드 형식을 중점적으로 점검합니다. 구독은 정상적으로 다운로드되지만 노드 목록이 비어 있다면 해당 구독의 로컬 캐시를 삭제한 뒤 다시 가져오고, 클라이언트에서 방금 업데이트된 설정 파일을 선택했는지 확인하세요.

먼저 브라우저에서 구독 주소를 열어 정상적인 응답 상태이며 만료 안내가 아닌지 확인하세요. 주소에 임시 토큰이 포함되어 있다면 구독 제공업체에서 완전한 링크를 다시 발급받아야 합니다. 응답 내용은 존재하지만 클라이언트에서 파싱 실패가 발생한다면 별도의 새 설정을 만들어 가져와 기존 오버라이드가 계속 적용되지 않도록 한 뒤 로그로 문제가 된 필드를 찾으세요. 업데이트 전에는 정상 작동했지만 업데이트 직후 실패했다면 원격 설정에 들여쓰기 오류, 중복 키 또는 클라이언트가 아직 지원하지 않는 필드가 있는지도 확인해야 합니다.

먼저 Clash 코어가 실행 중인지 확인하고 시스템 프록시 주소가 현재 수신 포트를 가리키는지 점검하세요. 브라우저에 프록시 확장 프로그램이 설치되어 있다면 확장 프로그램 설정이 운영체제 설정을 덮어쓸 수 있으므로 잠시 비활성화한 뒤 다시 테스트합니다. Windows에서는 프록시 설정에 이전 주소가 남아 있지 않은지도 확인하세요. macOS에서는 현재 네트워크 서비스의 프록시 설정에서 HTTP와 HTTPS 항목을 확인할 수 있습니다. 마지막으로 클라이언트 로그에서 브라우저 요청이 코어로 들어오는지 확인하세요. 로그가 전혀 없다면 해당 트래픽이 아직 가로채지지 않은 경우가 많습니다.

UWP 네트워크 격리 기능을 사용하는 일부 앱은 로컬 루프백 프록시에 직접 접근할 수 있어 브라우저는 작동하지만 스토어 앱은 연결에 실패할 수 있습니다. 클라이언트에서 제공하는 UWP 루프백 도구를 열고 대상 앱을 선택해 저장한 다음 앱을 다시 시작하세요. 로컬 프록시가 꼭 필요한 프로그램만 선택해야 합니다. 클라이언트에 루프백 도구가 없다면 Windows에서 제공하는 CheckNetIsolation 기능으로 설정한 뒤 다시 테스트하세요.

지연 시간 테스트는 현재 네트워크에서 테스트 대상까지의 응답 상태만 보여 주며 다운로드 속도, 피크 시간대 안정성 또는 특정 웹사이트의 이용 가능 여부를 단독으로 나타내지는 않습니다. 같은 테스트 주소와 네트워크 환경에서 노드를 비교하고, 여러 차례 연속 측정해 시간 초과가 반복되는지 확인하세요. 노드를 선택한 뒤 실제 웹페이지 접속과 지속적인 다운로드도 테스트해야 합니다. 속도 측정은 정상인데 특정 사이트만 실패한다면 반복 측정보다 규칙, DNS 또는 대상 사이트의 제한을 점검하세요.

노드 변경은 일반적으로 새로 생성되는 연결에만 적용되며, 이미 연결된 장시간 연결은 기존 노드를 계속 사용할 수 있습니다. 대상 앱을 종료했다가 다시 열거나 클라이언트의 연결 목록에서 해당 연결을 종료한 뒤 테스트하세요. 현재 규칙이 매칭하는 정책 그룹이 방금 수정한 그룹인지도 확인해야 합니다. 규칙이 다른 그룹을 가리킨다면 관련 없는 그룹을 수정해도 효과가 없습니다. 정책 그룹이 자동 선택 또는 장애 조치를 사용하는 경우 최종 노드는 그룹 내부의 검사 결과에 따라 결정될 수도 있습니다.

Clash 규칙은 일반적으로 위에서 아래로 매칭되며 연결이 처음으로 적용 가능한 규칙에 걸리면 이후 규칙은 확인하지 않습니다. 범위가 지나치게 넓은 DOMAIN-SUFFIX, IP-CIDR 또는 규칙 세트를 앞쪽에 배치하면 뒤의 정밀한 규칙이 가려질 수 있습니다. MATCH는 최종 대체 규칙이므로 목록 마지막에 두어야 합니다. 수정 후 연결 상세 정보에서 실제로 매칭된 규칙과 정책을 확인하고, 먼저 단일 도메인으로 검증한 다음 규칙 범위를 점진적으로 넓히세요. 여러 조건을 한 번에 바꾸면 원인을 찾기 어려워집니다.

원격 구독을 업데이트하면 해당 설정의 본문이 대체되는 경우가 많으므로 다운로드된 설정 파일에 로컬 변경 사항을 직접 장기간 저장해서는 안 됩니다. 클라이언트에서 제공하는 오버라이드, 병합 또는 스크립트 기능을 우선 사용하고 로컬 DNS, 규칙 및 정책 그룹 변경은 별도 계층에 저장하세요. 정책 선택을 유지할 수 있는지는 클라이언트가 정책 그룹 이름을 기준으로 상태를 저장하는지에 달려 있으며, 그룹 이름을 바꾸면 다시 선택해야 하는 경우가 많습니다. 작업 전 로컬 오버라이드를 내보내고 복사본으로 병합 결과를 먼저 검증하세요.

먼저 프록시를 끄고 로컬 네트워크에서 자주 사용하는 웹사이트에 직접 접속할 수 있는지 확인한 뒤 구독을 업데이트해 노드 정보가 만료되지 않았는지 점검하세요. 이어서 두 개 이상의 노드로 교차 테스트해 단일 노드 문제인지 전체 네트워크 진입점 문제인지 구분합니다. 모든 노드가 시간 초과되면 시스템 시간, 방화벽, 다른 프록시 프로그램 및 코어 로그를 확인하세요. 특정 프로토콜만 실패한다면 해당 프로토콜에 필요한 필드를 다시 확인합니다. 마지막으로 휴대폰 핫스팟으로 재시험하면 현재 인터넷 회선이나 로컬 네트워크가 원인인지 빠르게 판단할 수 있습니다.

TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 수정하므로 일반 시스템 프록시보다 높은 권한이 필요합니다. Windows에서는 클라이언트를 관리자 권한으로 다시 실행하고 서비스 모드가 올바르게 설치되었는지 확인하세요. macOS에서는 클라이언트가 네트워크 보조 구성요소를 설치하거나 활성화하도록 허용해야 합니다. Linux에서는 프로세스에 TUN 장치 생성과 라우팅 관리에 필요한 권한이 있는지 확인하세요. 권한을 복구한 뒤에는 다른 VPN과 가상 네트워크 카드 도구를 먼저 종료하고 TUN을 다시 활성화해 여러 프로그램이 라우팅과 DNS를 동시에 변경하지 않도록 하세요.

이 현상은 대개 DNS 경로 문제를 가리킵니다. 먼저 로그에 쿼리 시간 초과가 나타나는지 확인한 다음 설정의 nameserver, fallback 또는 proxy-server-nameserver가 현재 네트워크에서 접근 가능한지 점검하세요. Fake-IP를 사용하는 경우 강화 모드, 제외 목록 및 TUN DNS 하이재킹 설정이 서로 맞물려 있는지도 확인해야 합니다. 잠시 일반 DNS 설정으로 전환해 비교할 수 있지만 노드와 규칙을 동시에 변경하지는 마세요. Clash를 꺼도 여전히 해석되지 않는다면 먼저 시스템 네트워크 카드의 DNS 설정을 복구하세요.

시스템 프록시는 복구되었지만 Clash 코어가 아직 시작되지 않아 시스템 트래픽이 수신 대기 중이 아닌 로컬 포트로 향하는 것이 흔한 원인입니다. 먼저 시스템 프록시를 끄고 직접 연결을 복구한 뒤 클라이언트가 중복 실행되었는지, 설정이 정상적으로 로드되는지, 코어 포트를 다른 프로그램이 사용 중인지 확인하세요. 시작 시 시스템 프록시 자동 활성화를 취소하고 코어가 시작된 후 수동으로 켜는 방법도 있습니다. 클라이언트가 시작 지연이나 서비스 모드를 지원한다면 이를 활용해 시작 순서를 조정하세요.