Clash 자주 묻는 질문.

Clash는 프록시 코어와 설정 생태계를 가리키는 이름이며, 원본 코어는 더 이상 유지 관리되지 않습니다. Clash Meta는 원본을 바탕으로 프로토콜과 트래픽 분기 기능을 확장했으며, 이후 mihomo로 이름이 바뀌었습니다. Clash Verge Rev 같은 GUI 클라이언트는 구독 관리, 트레이 아이콘, 시스템 설정 화면을 제공하고 실제 연결은 보통 코어가 처리합니다. 호환성 문제를 확인할 때는 창 제목에 Clash가 있는지만 보지 말고 클라이언트 이름과 코어 버전을 함께 기록하세요. 기존 설정은 대체로 이전할 수 있지만, 새 프로토콜과 DNS 필드, TUN 설정은 사용할 코어의 문서를 확인해야 합니다.

평소에는 규칙 모드를 사용해 설정에 따라 연결을 직접 연결하거나 프록시로 보내세요. 전역 모드는 코어가 받은 연결을 전역 정책 그룹으로 보내므로 규칙이 원인인지 잠시 확인할 때 유용합니다. 다만 시스템의 모든 앱이 프록시를 거친다는 뜻은 아닙니다. 직접 연결 모드에서는 코어가 처리하는 연결이 목적지에 바로 접속하므로 비교 테스트에 활용할 수 있습니다. 모드를 바꾼 뒤에는 해당 정책 그룹의 선택 항목도 확인하세요. 전역 그룹에서 DIRECT를 선택했을 수도 있습니다. 기존 연결은 이전 경로를 계속 사용할 수 있으므로 테스트할 때는 연결을 새로 만드세요.

시스템 프록시는 데스크톱 환경이나 운영체제 설정에 로컬 프록시 주소를 등록합니다. 해당 설정을 참조하는 앱에 주로 적용되며, 보통 가상 네트워크 인터페이스를 만들 필요가 없습니다. TUN은 가상 인터페이스와 라우팅을 이용해 더 많은 연결을 처리하므로 시스템 프록시를 따르지 않는 프로그램에 적합하지만, 서비스 구성 요소나 별도 권한이 필요한 경우가 많습니다. 두 방식 모두 모든 트래픽이 반드시 프록시를 통과한다고 보장하지는 않습니다. 라우팅, 제외 항목, 앱 동작에 따라 달라질 수 있습니다. 먼저 시스템 프록시로 구독과 노드가 작동하는지 확인한 뒤, 필요에 따라 TUN을 켜세요. 여러 설정을 한꺼번에 바꾸면 원인을 찾기 어려워집니다.

구독 링크에는 계정 식별 정보나 접근 자격 증명이 포함되는 경우가 많습니다. 링크를 가진 사람이 노드 정보를 확인할 수 있으므로 포럼, 단체 채팅방, 공개 스크린샷에 그대로 올리지 마세요. 도움을 요청할 때는 클라이언트 이름, 코어 버전, 오류 발생 시각, 민감 정보를 가린 로그만 제공하면 됩니다. 노드 비밀번호, 구독 주소, 제어 인터페이스 키도 숨기세요. 클라이언트가 노드 계정을 제공하는 것은 아닙니다. 구독 만료일, 트래픽 한도, 서비스 상태는 구독 제공업체에 문의하세요. 링크가 이미 공개됐다면 제공업체 계정에서 주소를 재설정한 다음 클라이언트의 구독 정보도 업데이트하세요.

클라이언트의 설정 또는 구독 화면에서 링크로 새 설정을 만든 뒤, 제공업체가 안내한 전체 주소를 붙여 넣으세요. 다운로드가 완료되면 해당 설정을 현재 설정으로 지정합니다. 클라이언트마다 버튼 이름은 다를 수 있지만, 설정 다운로드와 설정 적용은 서로 다른 작업입니다. 필드 누락이나 파싱 오류가 표시되면 제공된 형식이 Clash 또는 mihomo 호환 형식인지 먼저 확인하세요. 웹 로그인 주소나 다른 클라이언트 전용 형식은 사용할 수 없습니다. 호환 형식으로 다시 요청하는 것이 좋습니다. 변환이 꼭 필요하다면 변환 서비스가 구독 전체를 읽을 수 있는지 확인하고, 출처가 불분명한 온라인 서비스에 비공개 링크를 입력하지 마세요.

먼저 클라이언트 안내에 따라 서비스 구성 요소를 설치하고 실행했는지 확인한 다음, 로그에서 가상 인터페이스 생성 실패나 권한 거부 오류를 살펴보세요. Linux에서는 사용 가능한 TUN 장치도 필요하므로 /dev/net/tun이 있는지 확인할 수 있습니다. 컨테이너나 제한된 가상 환경에서는 장치 또는 네트워크 권한이 제공되지 않을 수 있습니다. GUI 클라이언트 전체를 장기간 관리자 권한으로 실행하거나 장치 권한을 무분별하게 완화하지 마세요. 서비스가 정상적으로 실행되는지 확인한 뒤 TUN을 켜세요. 그래도 실패한다면 배포판, 설치 형식, 오류 원문을 기록하고 클라이언트의 권한 설정 절차를 하나씩 확인하세요.

먼저 패키지가 배포판과 프로세서 아키텍처에 맞는지 확인하세요. DEB는 주로 Debian·Ubuntu 계열, RPM은 Fedora 등의 배포판에서 사용합니다. 파일명에 Linux가 들어 있다고 해서 설치할 수 있는 것은 아닙니다. uname -m 결과를 확인해 x86_64와 aarch64를 구분하세요. 실행되지 않으면 터미널에서 클라이언트를 실행하고 누락된 의존성이나 샌드박스 관련 오류를 확인하세요. 포터블 형식도 시스템 실행 구성 요소가 필요할 수 있으므로 프로젝트 안내를 확인해야 합니다. 먼저 시스템 보안 기능을 끄지 말고, 배포판에 맞는 패키지를 사용하세요. 다운로드 페이지에서 현재 제공되는 설치 형식도 확인하세요.

AppContainer에서 실행되는 일부 Windows 앱은 루프백 접근이 제한됩니다. 시스템 프록시가 로컬 포트를 가리키더라도 로컬 프록시 서비스에 연결하지 못할 수 있습니다. 이 경우 클라이언트에서 제공하는 루프백 예외 도구를 사용해 필요한 앱에만 권한을 추가하세요. 실행 중 관리자 확인이 필요할 수 있습니다. 모든 스토어 앱이 같은 실행 모델을 사용하는 것은 아니며, 모든 연결 실패가 루프백 제한 때문인 것도 아닙니다. 먼저 일반 브라우저에서 프록시를 사용할 수 있는지, 대상 앱이 시스템 프록시를 읽는지 확인하세요. TUN으로 트래픽을 처리한다면 다시 테스트하고, 모든 앱의 접근을 일괄 허용하지 마세요.

지연 시간 테스트는 보통 지정된 테스트 주소에 요청을 보내 특정 시점의 응답을 확인합니다. 지속적인 다운로드 속도나 모든 웹사이트의 성능을 나타내지는 않습니다. 먼저 테스트 주소와 실제 접속 대상이 비슷한지 확인한 뒤, 노드를 하나로 고정하고 같은 웹사이트와 네트워크에서 비교하세요. 웹페이지 로딩 속도는 DNS, 대상 서버, 패킷 손실, 연결 재사용에도 영향을 받습니다. 여러 노드를 자주 한꺼번에 측정하면 연결 부하가 커질 수 있습니다. 노드를 선택할 때는 지연 시간이 안정적인지 먼저 보고, 실제 페이지 로딩과 파일 전송도 확인하세요. 목록에서 가장 낮은 수치만 고집할 필요는 없습니다.

규칙은 보통 위에서 아래 순서로 적용됩니다. 먼저 클라이언트가 규칙 모드인지 확인한 다음, 연결 기록에서 실제로 적용된 규칙과 정책 그룹을 살펴보세요. 사용자 지정 규칙은 먼저 일치할 수 있는 넓은 범위의 규칙보다 위에 두어야 합니다. 특히 MATCH 뒤에 두지 마세요. 이어서 도메인 규칙과 IP 규칙 중 무엇을 사용했는지, 코어가 도메인 정보를 가져왔는지 확인하세요. 설정을 수정한 뒤 다시 불러오고 대상 연결을 새로 만드세요. 기존 연결은 경로가 바뀌지 않을 수 있습니다. 구독을 업데이트할 때 수정 내용이 덮어써진다면 원본 파일을 계속 편집하지 말고 클라이언트의 오버라이드 또는 병합 기능으로 로컬 규칙을 저장하세요.

원격 구독 파일과 클라이언트의 로컬 오버라이드 계층을 구분하세요. 원격 파일은 업데이트 시 전체가 교체될 수 있지만, 포트·규칙·개인 정책 설정은 오버라이드 계층에 저장하는 것이 적합합니다. 자동 업데이트를 설정하기 전에 클라이언트가 오버라이드 병합을 지원하는지, 목록 항목을 추가하는지 교체하는지 확인하세요. 노트북이 절전 상태이거나 클라이언트가 실행되지 않으면 예약 작업이 제시간에 실행되지 않을 수 있으며, 복귀 후 업데이트 여부는 구현에 따라 다릅니다. 업데이트 후 현재 설정, 정책 그룹 선택, 로그를 확인해 정상적으로 적용됐는지 살펴보세요. 백업에는 오버라이드 파일과 설정 간의 관계를 유지하고, 비공개 구독 주소가 포함된 백업은 안전하게 보관하세요.

많은 명령줄 도구는 데스크톱 시스템 프록시를 자동으로 읽지 않으므로 프록시 환경 변수나 도구 자체의 프록시 옵션을 별도로 설정해야 합니다. 먼저 클라이언트에서 로컬 수신 주소와 실제 포트를 확인한 뒤, 현재 터미널에서 HTTP_PROXY, HTTPS_PROXY 또는 도구가 지원하는 ALL_PROXY를 임시로 설정하세요. 다른 사람의 포트 번호를 그대로 사용하지 마세요. 변수의 대소문자, SOCKS 지원 여부, 도메인 이름을 해석하는 위치는 도구마다 다르므로 해당 도구의 문서를 따르세요. 테스트에 성공한 뒤 영구 설정을 고려하세요. 프록시를 해제할 때는 이전 변수와 Git 전용 설정도 지워야 클라이언트 종료 후 터미널이 작동하지 않는 로컬 포트에 계속 연결하지 않습니다.

오류 유형을 기록한 뒤 시스템 시간, 현재 네트워크, 구독 제공업체 계정 상태를 확인하세요. 401이나 403은 접근 권한, 링크 상태, 제공업체의 제한과 관련된 경우가 많고, 404는 경로가 바뀌었을 수 있습니다. 상태 코드만으로 원인을 단정할 수는 없습니다. 시간 초과나 TLS 오류가 발생하면 네트워크, 인증서, 기기 시간을 추가로 확인하세요. 응답이 로그인 페이지로 바뀌었다면 설정 파일을 받은 것이 아닙니다. 클라이언트에서 프록시를 통해 구독을 업데이트하도록 설정했는지 확인하고, 이미 사용할 수 없는 노드에 업데이트가 의존하지 않는지도 살펴보세요. 마지막으로 사용할 수 있는 설정을 바로 삭제하지 말고 백업한 뒤, 제공업체에 주소 재설정이 필요한지 문의하세요.

먼저 프록시를 끄고 기본 네트워크가 정상인지 확인한 다음 구독 유효성, 기기 시간, 현재 설정의 적용 여부를 점검하세요. 노드 하나를 선택해 연결 로그를 보고 도메인 이름 해석 실패, 연결 시간 초과, 핸드셰이크 실패, 인증 실패를 구분하세요. 오류 유형에 따라 해결 방법이 다릅니다. 속도 테스트만 시간 초과되고 실제 웹사이트는 열린다면 테스트 주소를 바꿔 다시 확인하세요. 여러 노드에 연결할 수 없다면 다른 네트워크에서도 비교하고, 라우팅 충돌을 피하려고 다른 VPN이나 네트워크 필터링 도구를 잠시 종료해 보세요. 반복해서 재설치하는 것보다 구체적인 오류 한 건을 보관하는 편이 도움이 됩니다. DNS, TUN 스택, 노드 프로토콜을 한꺼번에 바꾸지 마세요.

먼저 코어가 실행 중인지, 로컬 프록시 포트와 시스템 설정이 일치하는지 확인하세요. 그런 다음 클라이언트의 연결 기록에 대상 앱이 표시되는지 살펴봅니다. 기록이 없다면 앱이 시스템 프록시를 읽지 않거나 자체 프록시 설정을 유지하고 있을 수 있습니다. 기록은 있지만 직접 연결된다면 적용된 규칙과 정책 선택을 확인하세요. Linux에서는 데스크톱 환경, 브라우저, 터미널마다 프록시 설정을 읽는 방식이 다릅니다. 클라이언트가 비정상 종료되면 닫힌 포트를 가리키는 시스템 프록시 설정이 남을 수도 있습니다. 이때는 먼저 시스템 프록시를 꺼서 네트워크를 복구한 뒤 클라이언트를 다시 시작하세요. 앱을 처리하는 범위가 부족한 것을 확인한 경우에만 TUN을 고려하고, 여러 프록시 도구를 동시에 사용하지 마세요.

이 경우 DNS 해석 경로를 확인할 필요가 있지만, IP 주소와 도메인으로 접속할 때 서로 다른 인증서와 가상 호스트가 사용될 수 있으므로 한 번의 테스트만으로 결론 내리면 안 됩니다. 먼저 시스템의 DNS 조회 도구로 대상 도메인이 해석되는지 확인하고, 코어 로그의 DNS 요청과 오류를 비교하세요. 브라우저의 보안 DNS, 시스템 암호화 DNS, 클라이언트의 DNS 처리 기능을 동시에 사용하고 있는지 확인한 뒤 각 단계에서 실제로 어떤 경로를 사용하는지 살펴보세요. 설정을 변경한 후 관련 캐시를 지우고 다시 연결하세요. fake-ip를 사용할 때는 출처가 불분명한 설정을 섞지 마세요. 먼저 클라이언트의 기본 DNS 설정으로 되돌려 비교하고 사용자 지정 항목을 하나씩 추가하세요.