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

Clash는 일반적으로 규칙 기반 프록시 프로젝트와 그 생태계를 가리킵니다. Mihomo는 Clash 설정 형식과 호환되면서 기능을 계속 확장하는 핵심 엔진입니다. Clash Verge Rev, Clash Plus, FlClash 등은 그래픽 클라이언트에 해당합니다. 그래픽 클라이언트는 설정 가져오기, 정책 전환, 시스템 프록시 제어를 담당하며, 실제 연결과 규칙 매칭은 대개 내장된 핵심 엔진이 처리합니다. 클라이언트를 선택할 때는 유지 관리 상태, 운영체제 지원 여부, 사용 중인 핵심 엔진을 함께 확인해야 합니다.

규칙 모드는 설정 파일의 규칙 순서에 따라 연결을 직접 연결, 프록시 또는 차단으로 처리하므로 일상적인 사용에 적합합니다. 전역 모드는 대부분의 트래픽을 현재 선택한 프록시 정책으로 보내며, 노드 사용 가능 여부를 임시로 테스트할 때 유용합니다. 직접 연결 모드는 프록시를 우회하며, 문제가 프록시 경로에서 발생했는지 확인할 때 주로 사용합니다. 문제를 해결할 때는 먼저 전역 모드로 노드를 확인한 뒤 규칙 모드로 돌아가 규칙 매칭 결과를 점검할 수 있습니다.

시스템 프록시는 운영체제의 프록시 설정을 따르는 앱에만 영향을 줍니다. 대부분의 브라우저와 일부 데스크톱 프로그램이 여기에 해당하지만, 명령줄 도구나 게임, 자체 네트워크 스택을 사용하는 프로그램은 설정을 읽지 않을 수 있습니다. TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 트래픽을 처리합니다. 적용 범위가 넓은 대신 관리자 권한이 필요하며, 보안 프로그램·가상 머신·다른 네트워크 필터링 프로그램과 충돌할 수 있습니다.

프록시 노드는 서버 연결 정보를 저장하고, 정책 그룹은 여러 노드나 다른 정책을 묶습니다. 규칙은 도메인, IP 또는 네트워크 유형에 따라 지정된 정책 그룹으로 트래픽을 전달합니다. 일반적으로 연결은 규칙을 위에서 아래로 매칭하고, 일치하는 규칙을 찾으면 해당 정책 그룹으로 이동한 뒤 수동 선택, 자동 속도 측정 또는 장애 조치 로직으로 최종 노드를 결정합니다. 이름을 변경할 때는 정책 그룹의 참조와 규칙 대상도 함께 확인해야 합니다.

구독 설정은 서비스 제공자가 노드와 기본 규칙을 일괄 관리하므로 업데이트가 편리하지만, 다시 업데이트할 때 구독 파일에 직접 입력한 수정 사항이 덮어써질 수 있습니다. 로컬 설정은 사용자 지정 DNS, 규칙, 정책 그룹을 장기간 유지할 때 적합합니다. 함께 사용해야 한다면 클라이언트가 지원하는 오버라이드, 확장 스크립트 또는 설정 병합 기능을 우선 사용하고, 구독 새로 고침으로 교체될 원본 파일은 직접 수정하지 않는 것이 좋습니다.

가져온 뒤 먼저 설정 상태가 활성화됨으로 표시되는지 확인하고, 프록시 노드와 정책 그룹이 정상적으로 보이는지 점검합니다. 그런 다음 사용할 수 있는 노드를 선택하고 시스템 프록시를 켠 뒤 브라우저로 자주 방문하는 사이트에 접속해 연결을 확인합니다. 명령줄 도구, 게임 또는 더 많은 앱의 트래픽을 처리해야 할 때는 플랫폼 권한에 따라 TUN을 활성화합니다. 기본 프록시를 확인하기 전에 DNS, 규칙, 포트를 동시에 변경하면 원인을 찾기 어려워집니다.

먼저 브라우저에서 구독 주소가 로그인 페이지나 오류 페이지, 빈 파일이 아닌 실제 콘텐츠를 반환하는지 확인합니다. 이어서 시스템 시간, 네트워크 연결, 클라이언트 로그의 HTTP 상태를 점검합니다. 기존 설정으로 계속 연결할 수 있다면 사용 가능한 노드로 전환한 뒤 다시 업데이트합니다. 서비스 제공자가 주소를 초기화했다면 새 구독 주소를 받아야 합니다. 구독 주소에는 접근 자격 증명이 포함될 수 있으므로 스크린샷, 로그 또는 공개 문서에 올리지 마세요.

먼저 들여쓰기에 공백을 일관되게 사용했는지, 콜론 뒤에 공백이 있는지, 목록 항목 앞 하이픈의 단계가 올바른지 확인합니다. proxies, proxy-groups, rules 같은 필드가 올바른 계층에 있는지, 참조된 정책 그룹 이름이 완전히 일치하는지도 점검해야 합니다. 마지막으로 정상적으로 불러온 설정으로 되돌린 뒤 수정 내용을 구간별로 추가하고, 저장할 때마다 다시 불러와 오류가 발생한 부분을 찾을 수 있습니다.

Windows에서는 먼저 클라이언트를 종료한 뒤 관리자 권한으로 실행하고 서비스 모드를 다시 설치하거나 활성화합니다. macOS에서는 시스템 안내에 따라 네트워크 확장을 허용하고 관리자 인증을 완료해야 합니다. 권한을 이미 부여했는데도 실패한다면 이전 버전 서비스가 남아 있는지, 가상 네트워크 어댑터가 비활성화되어 있는지, 보안 프로그램이 드라이버 로드를 차단하는지 확인합니다. 처리 후 클라이언트를 다시 시작하고, 필요하면 시스템을 재부팅해 이전 네트워크 구성 요소를 정리합니다.

일부 UWP 앱은 기본적으로 로컬 프록시 수신 포트에 접근할 수 없기 때문에 브라우저가 정상이어도 스토어 앱은 네트워크에 연결되지 않을 수 있습니다. 클라이언트에서 제공하는 UWP 루프백 도구로 대상 앱을 선택하고 저장하세요. 내장 메뉴가 없다면 Windows의 루프백 면제 관리 기능을 사용할 수 있습니다. 완료 후 대상 앱을 다시 시작하고 Clash의 로컬 수신 주소와 포트가 변경되지 않았는지 확인합니다.

일상적인 사용에는 보통 규칙 모드를 선택해 도메인과 IP에 따라 연결을 분류하는 것이 좋습니다. 불필요한 프록시 트래픽을 줄일 수 있기 때문입니다. 전역 모드는 특정 노드를 짧게 확인하거나 규칙 오판을 배제할 때, 또는 아직 규칙에 등록되지 않은 임시 상황에 적합합니다. 전역 모드는 되는데 규칙 모드가 실패한다면 전역 모드를 계속 유지하기보다 연결 로그의 매칭 규칙과 정책 그룹을 확인해야 합니다.

먼저 같은 구독의 다른 노드로 전환해 특정 노드만 고장인지 모든 노드를 사용할 수 없는지 판단합니다. 그런 다음 구독을 업데이트하고 시스템 시간을 확인합니다. 인증서 연결은 정확한 시간에 의존하기 때문입니다. 모든 노드에서 시간 초과가 발생한다면 TUN을 잠시 끄고 기본 DNS를 복원한 뒤 로컬 방화벽이 클라이언트를 차단하는지 점검합니다. 속도 측정 주소에 연결되지 않는다고 해서 모든 웹사이트에 접속할 수 없는 것은 아니므로 실제 연결 로그를 함께 확인해야 합니다.

먼저 현재 설정에서 실제로 참조하는 프록시 제공자를 업데이트했는지 확인합니다. 활성화되지 않은 다른 설정의 동명 항목을 업데이트한 것은 아닌지 주의하세요. 제공자의 업데이트 시간과 로그의 다운로드 결과를 확인한 뒤 설정을 다시 불러옵니다. 캐시가 갱신되지 않았다면 해당 제공자의 로컬 캐시를 삭제하고 다시 가져옵니다. 구독 변환으로 생성한 설정이라면 변환 서버가 새 콘텐츠를 반환하는지, 이전 캐시를 계속 제공하는지도 확인해야 합니다.

먼저 클라이언트 설정에서 시작 시 실행을 활성화하고, 시스템의 시작 프로그램 관리에서 해당 클라이언트가 비활성화되지 않았는지 확인합니다. 네트워크를 자동으로 처리하려면 시스템 프록시 또는 TUN의 활성화 상태도 각각 저장해야 합니다. Windows 서비스 모드와 macOS 네트워크 확장은 별도의 권한 승인이 필요할 수 있습니다. 설정을 마친 뒤 시스템을 재부팅해 테스트하고, 클라이언트가 시작된 후 빈 설정 화면이 아니라 예상한 설정을 정상적으로 불러오는지 확인합니다.

브라우저는 대개 시스템 프록시를 읽지만 터미널 프로그램은 해당 설정을 무시할 수 있습니다. 현재 터미널 세션에 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 환경 변수를 설정하고, 포트가 Clash의 HTTP·혼합·SOCKS 수신 포트와 일치하는지 확인하세요. TUN으로 트래픽을 처리하는 방법도 있습니다. 설정 후 새 터미널을 열어 다시 테스트하고, 도구 자체에 별도 프록시가 설정되어 여러 프록시 설정이 서로 덮어쓰지 않는지도 확인합니다.

먼저 클라이언트가 실행 중인지, 설정이 활성화되어 있는지, 로컬 수신 포트가 시스템 프록시의 주소와 일치하는지 확인합니다. 그런 다음 다른 프록시 프로그램과 브라우저 확장 기능을 종료해 시스템 설정이 반복해서 변경되지 않도록 합니다. 클라이언트의 연결 로그에서 요청이 Clash로 들어오는지 확인할 수 있습니다. 기록이 전혀 없다면 앱이 시스템 프록시를 사용하지 않는 경우가 많고, 기록은 있지만 실패한다면 규칙·정책 그룹·노드를 계속 점검해야 합니다.

먼저 클라이언트의 기본 DNS 설정을 복원하고 운영체제의 DNS 캐시를 삭제해 이전 기록의 영향을 배제합니다. fake-ip을 사용한다면 대상 프로그램의 호환성을 확인하고, 로컬 네트워크 장치·프린터·특수 도메인을 필터링 대상에서 제외합니다. nameserver와 fallback에 현재 네트워크에서 접근할 수 있는지도 확인해야 합니다. 특정 도메인에서만 문제가 발생한다면 DNS 로그와 규칙 매칭 결과를 확인하고, 여러 DNS 서버를 한꺼번에 변경하지 마세요.

먼저 TUN을 끄고 클라이언트를 종료한 뒤 직접 연결 네트워크가 복구되는지 확인합니다. 이어서 TUN 스택, 자동 라우팅, DNS 가로채기 설정을 점검하고 다른 가상 네트워크 어댑터·VPN·트래픽 필터링 프로그램·가상 머신 네트워크를 잠시 비활성화합니다. 클라이언트가 비정상 종료된 뒤 라우팅이 복구되지 않았다면 시스템을 재부팅해 남은 라우팅을 정리할 수 있습니다. 다시 활성화할 때는 먼저 기본 설정으로 테스트한 뒤 사용자 지정 옵션을 하나씩 복원합니다.

포트 충돌은 대개 실행 중인 다른 프록시 클라이언트, 이전 프로세스 또는 중복 실행된 Clash 인스턴스에서 발생합니다. 먼저 관련 프로그램을 완전히 종료한 뒤 시스템 네트워크 도구로 mixed-port, port 또는 socks-port를 사용 중인 프로세스를 찾습니다. 충돌하는 프로세스를 종료하거나 Clash를 사용하지 않는 포트로 변경할 수 있습니다. 변경 후에는 시스템 프록시, 브라우저, 터미널 환경 변수의 포트도 함께 업데이트해야 합니다.

먼저 현재 정책 그룹이 자동 속도 측정이나 장애 조치를 사용하는지, 검사 간격이 너무 짧지는 않은지 확인합니다. 네트워크가 불안정하면 여러 노드의 순서가 계속 바뀌어 연결이 재설정될 수 있습니다. 안정적인 노드 하나를 수동으로 선택해 문제가 사라지는지 잠시 관찰하고, 상태 확인 주소·시간 초과 임계값·클라이언트 로그도 점검합니다. 고정한 노드에서도 연결이 끊긴다면 로컬 네트워크, 시스템 절전, 서버 상태를 추가로 확인합니다.