Clash 자주 묻는 질문

클라이언트는 설정 가져오기, 시스템 프록시 전환, 연결 기록 확인 등 화면에서 하는 작업을 담당합니다. mihomo 커널은 프로토콜 연결, DNS 조회, 규칙 실행을 처리하고, 구독은 서비스 제공자가 전달하는 설정 또는 노드 데이터입니다. 클라이언트를 설치해도 사용할 수 있는 노드가 자동으로 생기거나 서비스 계정이 만들어지지는 않습니다. 문제를 점검할 때는 화면, 커널 실행, 서비스 문제를 먼저 구분하세요. 커널이 시작되지 않으면 로그를 확인하고, 설정을 가져올 수 없으면 형식을 확인하세요. 계정이 만료되었거나 노드가 비활성화된 경우에는 구독 제공자에게 문의해야 합니다.

Clash for Windows는 지원이 종료되었습니다. 이전할 때는 현재 운영체제와 호환되고 계속 관리되는 클라이언트를 선택하세요. 먼저 구독 주소, 포트, 규칙 모드, 로컬 오버라이드 설정을 기록한 뒤 기존 클라이언트의 시스템 프록시를 끄고 종료합니다. 그런 다음 새 클라이언트를 실행해 구독을 가져오세요. 두 클라이언트가 동시에 네트워크를 제어하지 않도록 하고, 기존 프로그램 폴더를 새 프로그램에 그대로 덮어쓰지 마세요. 이전 후에는 노드 하나와 자주 사용하는 앱부터 확인한 다음 사용자 지정 규칙을 하나씩 복원하세요. 이전 설정의 실험용 필드는 새 커널 문서를 참고해 다시 확인해야 합니다.

일상적인 사용에는 규칙 모드가 적합합니다. 커널에 들어온 연결을 규칙 순서에 따라 해당 정책으로 보냅니다. 전역 모드는 연결을 전역 정책으로 보내므로 잠깐 비교하거나 문제를 점검할 때 유용합니다. 직접 연결 모드는 연결이 대상에 바로 접속하도록 합니다. 모드는 트래픽을 가로채는 방식과 다릅니다. 전역 모드로 바꿔도 모든 앱의 트래픽이 자동으로 가로채지는 않습니다. 먼저 시스템 프록시나 TUN이 대상 앱을 처리하는지 확인한 다음 모드별 차이를 비교하세요. 전역 모드에서는 되지만 규칙 모드에서 실패한다면 클라이언트를 바로 다시 설치하기보다 적용된 규칙과 정책 그룹을 확인하세요.

시스템 프록시는 시스템 프록시 설정을 따르는 앱에만 적용됩니다. 게임, 일부 명령줄 도구, 자체적으로 연결을 만드는 소프트웨어까지 모두 처리한다고 보장할 수는 없습니다. 브라우저 확장 프로그램이 시스템 프록시 설정을 덮어쓰는 경우도 있습니다. 먼저 클라이언트의 연결 기록에서 대상 앱의 새 요청을 찾아보세요. 기록이 없다면 노드를 바꾸기보다 앱 자체의 프록시 설정, 확장 프로그램 설정, 트래픽 처리 방식을 확인하세요. 더 많은 트래픽을 처리해야 한다면 TUN 사용을 고려하되, 라우팅과 제외 항목, 플랫폼 제한도 함께 확인해야 합니다. 연결이 커널에 들어온 뒤 규칙에 따라 직접 연결될 수도 있습니다.

클라이언트의 설정 또는 구독 페이지에서 URL 가져오기를 선택하고 서비스 제공자가 알려 준 전체 주소를 붙여 넣으세요. 저장한 뒤 다운로드와 파싱이 끝날 때까지 기다립니다. 가져오기에 성공해도 해당 설정이 실제로 사용 중이라는 뜻은 아닙니다. 가져온 설정을 현재 설정으로 지정하고 정책 그룹이 표시되는지 확인한 다음 사용할 정책을 선택하세요. 이어서 트래픽 처리 방식을 하나 켜고 대상 웹사이트에 접속하면서 연결 기록을 확인합니다. 구독 주소에는 계정 정보가 포함될 수 있으므로 스크린샷, 공개 로그, 단체 채팅방에 올리지 마세요. 주소가 유출됐다면 제공자 페이지에서 재설정한 뒤 다시 가져와야 합니다.

전체 Clash YAML 설정, 노드 모음, Base64로 인코딩된 공유 링크 목록은 서로 다른 형식입니다. 전체 설정에는 보통 프록시, 정책 그룹, 규칙이 포함됩니다. 노드 목록만 있는 경우 프록시 모음으로 참조해야 할 수 있으며, 기본 설정처럼 바로 불러올 수는 없습니다. Base64는 인코딩 방식일 뿐, 내용이 현재 클라이언트와 호환된다는 뜻은 아닙니다. 구독 제공자에게 Clash 또는 mihomo에 맞는 설정 주소를 요청하고 프로토콜 지원 여부도 확인하세요. 계정 정보가 포함된 구독을 출처가 불분명한 변환 사이트에 입력하지 마세요. 형식 오류를 해결하려고 포트를 계속 바꾸는 것도 도움이 되지 않습니다.

먼저 커널이 정상적으로 실행되는지 확인하세요. 그다음 클라이언트 안내에 따라 서비스 모드를 설치하거나 시작하고 시스템 권한을 승인합니다. Windows에서는 보통 관리자 권한이 필요하거나 백그라운드 서비스가 올바르게 설치되어 있어야 합니다. macOS에서는 안내에 따라 네트워크 구성 요소의 권한을 승인해야 합니다. Linux에서는 TUN 장치에 접근할 수 있고 네트워크 관리 권한이 있어야 하는 경우가 많습니다. 보안 소프트웨어가 차단하는지, 다른 VPN이 라우팅을 제어하고 있는지도 확인하세요. 출처가 불분명한 프로그램에 관리자 권한을 주거나 시스템 보호 기능을 장기간 끄지 마세요. 권한을 승인한 뒤 관련 서비스를 다시 시작하고, 여전히 실패하면 네트워크 어댑터 생성 단계의 로그를 확인하세요.

AppContainer 샌드박스에서 실행되는 일부 앱은 로컬 루프백 제한 때문에 클라이언트가 수신 대기 중인 로컬 프록시 포트에 직접 연결하지 못할 수 있습니다. 먼저 같은 프록시를 통해 브라우저가 접속되는지 확인한 뒤 특정 앱에서만 문제가 발생하는지 살펴보세요. 클라이언트에 루프백 예외 도구가 있다면 용도를 확인하고 대상 앱에만 예외를 적용한 다음 안내에 따라 관리자 권한을 승인하세요. 해당 도구가 없다면 Windows의 CheckNetIsolation 사용법을 참고할 수 있습니다. 모든 스토어 앱에 같은 제한이 적용되는 것은 아닙니다. TUN을 켰다면 연결 기록과 라우팅을 먼저 확인하고, 관련 없는 예외를 중복으로 추가하지 마세요.

먼저 현재 설정이 정상적으로 불러와졌고 커널이 실행 중인지 확인한 다음, 시스템 프록시가 올바른 로컬 주소와 수신 포트를 가리키는지 살펴보세요. 포트는 클라이언트에서 실제로 적용된 mixed-port 또는 HTTP 포트와 일치해야 합니다. HTTP 프록시로 설정할 때 SOCKS 전용 포트를 입력하면 안 됩니다. 브라우저 확장 프로그램, 앱 자체의 프록시 설정, 시스템의 프록시 제외 목록을 확인한 뒤 요청을 다시 보내 연결 기록을 살펴보세요. 기록에 DIRECT가 표시되면 요청이 커널에 들어왔지만 규칙에 따라 직접 연결됐을 수 있으므로 적용된 규칙을 확인해야 합니다. 기록이 전혀 없다면 트래픽 처리 설정을 추가로 점검하세요.

규칙은 위에서 아래 순서로 적용됩니다. 구체적인 규칙은 기본값인 MATCH 규칙보다 위에 두고, 현재 설정에 실제로 존재하는 정책 그룹이나 내장 정책을 지정해야 합니다. 클라이언트에서 제공하는 오버라이드, 병합 또는 규칙 유지 기능을 우선 사용하세요. 구독으로 생성된 파일을 직접 수정하면 업데이트 후 변경 사항이 사라질 수 있습니다. 저장한 뒤 설정을 다시 불러오고 연결 기록에서 실제로 적용된 규칙을 확인하세요. 이미 연결된 항목은 이전 정책을 계속 사용할 수 있으므로 필요한 경우 대상 연결만 종료한 뒤 다시 시도합니다. 도메인 규칙을 사용한다면 커널이 해당 연결의 대상 도메인을 인식하는지도 확인하세요.

클라이언트의 지연 시간 테스트는 지정된 테스트 주소에 한 번 연결되는지를 주로 확인합니다. 다운로드 속도와는 다르며 모든 웹사이트에 접속할 수 있다는 보장도 아닙니다. 먼저 테스트 주소에 직접 접속할 수 있는지 확인한 다음, 같은 노드들을 동일한 조건으로 테스트하세요. 한꺼번에 너무 많은 속도 테스트를 실행하면 결과에 영향을 줄 수 있습니다. 평소 사용할 노드는 대상 웹사이트 접속 여부, 연결 안정성, 서비스 제공자의 트래픽 제한을 함께 고려해 선택하세요. 지연 시간은 낮지만 서비스가 제대로 작동하지 않는다면 대상 웹사이트의 제한과 프로토콜 호환성을 확인하세요. 테스트 시간 초과가 발생해도 실제 접속은 정상이라면 테스트 주소와 시간 초과 설정부터 살펴보세요.

DNS 항목을 수정한 뒤 설정을 다시 불러오고, 클라이언트의 화면 설정이나 오버라이드 내용이 해당 항목을 덮어쓰지 않는지 확인하세요. 로그에 상위 DNS 서버 조회 오류가 있는지 살펴본 다음, 클라이언트가 지원하는 방식으로 DNS 캐시를 지우고 대상 연결을 새로 만듭니다. GeoIP 등 위치 데이터를 업데이트할 때는 현재 커널에서 지원하는 데이터 형식과 설정 경로를 사용하고, 업데이트 후 정상적으로 불러와졌는지 확인하세요. GeoIP는 관련 IP 규칙에 영향을 줄 뿐 도메인 조회 문제를 자동으로 해결하지는 않습니다. 특정 도메인에서만 문제가 생긴다면 DNS 조회 결과, 적용된 규칙, 정책 선택을 모두 확인하세요.

점검에 필요한 단서를 잃지 않도록 현재 사용할 수 있는 설정을 먼저 보존하세요. 401 또는 403은 보통 인증, 주소에 포함된 계정 정보, 접근 제한과 관련이 있습니다. 404는 주소가 변경됐을 가능성이 있지만 제공자의 안내를 기준으로 판단해야 합니다. HTML이 반환되는 경우에는 로그인 페이지 주소를 복사했거나 웹페이지 인증 절차에 걸렸을 수 있습니다. 제공자 페이지에서 전용 구독 주소를 다시 복사하고 계정 유효 기간과 남은 트래픽을 확인한 뒤 수동 업데이트를 시도하세요. 전체 응답 내용과 구독 주소를 공개하지 마세요. 단순한 네트워크 시간 초과라면 업데이트 요청이 어떤 네트워크 경로를 이용하는지 먼저 확인하세요.

먼저 트래픽 처리를 끈 상태에서 기본 네트워크가 정상적으로 작동하는지 확인한 다음 기기 시간, 계정 상태, 구독 업데이트 결과를 살펴보세요. 이어서 노드 하나만 선택해 대상에 요청을 한 번 보내고 같은 시간대의 로그를 확인합니다. 도메인 조회 실패, 연결 거부, 핸드셰이크 실패, 테스트 주소 시간 초과를 구분하세요. 모든 노드가 같은 서비스에서 제공됐다면 제공자에게 서비스 상태를 문의할 수 있습니다. 특정 프로토콜만 실패한다면 커널이 해당 프로토콜을 지원하는지, 필요한 설정값이 모두 있는지 확인하세요. 원인을 찾기 어려워지지 않도록 DNS, 포트, 규칙을 한꺼번에 바꾸지 마세요. 로그를 공유하기 전 구독 인증 정보, 노드 비밀번호, 기타 계정 정보는 삭제해야 합니다.

먼저 로그에서 수신 대기 실패인지 확인한 다음 Windows의 netstat 또는 macOS와 Linux의 lsof로 7890 포트를 사용 중인 프로세스를 찾으세요. 정체를 알 수 없는 시스템 프로세스를 바로 종료하지 마세요. 이전 클라이언트가 실행 중이라면 정상적으로 종료합니다. 포트를 계속 사용할 수 없다면 현재 클라이언트의 포트 설정이나 유효한 설정 파일에서 mixed-port를 사용되지 않는 포트로 변경하고 설정을 다시 불러오세요. 구독 파일의 값은 오버라이드 설정으로 덮어써질 수 있으므로 실제 실행 중인 값을 기준으로 확인해야 합니다. 변경 후 시스템 프록시, 브라우저, 명령줄 도구의 포트도 함께 수정하고 로그에 수신 대기 오류가 더 이상 나타나지 않는지 확인하세요.

흔한 원인은 시스템이 더 이상 수신 대기하지 않는 로컬 프록시를 계속 가리키는 것입니다. 먼저 클라이언트를 다시 열고 시스템 프록시와 TUN을 끈 다음 정상적으로 종료하세요. 그 후 시스템 네트워크 설정에 수동 프록시가 남아 있는지 확인합니다. 앱에 별도의 프록시를 설정했거나 명령줄에 프록시 환경 변수를 지정했다면 각각 원래대로 되돌려야 합니다. TUN, 수동 DNS 또는 다른 VPN을 사용했다면 라우팅과 DNS가 복구됐는지 확인하고 필요하면 네트워크에 다시 연결하세요. 처음부터 네트워크 초기화를 실행하거나 모든 네트워크 어댑터를 삭제하지 마세요. 현재 설정을 기록해 두고 프록시, DNS, 라우팅 순서로 하나씩 점검하세요.