Clash 자주 묻는 질문

클라이언트는 구독 관리, 정책 선택, 로그 확인, 시스템 네트워크 설정을 담당하고, 코어는 설정을 해석하고 규칙을 적용해 연결을 수립합니다. Clash Meta는 Clash에서 파생된 코어로, 이후 mihomo라는 이름으로 개발이 이어지고 있습니다. 클라이언트마다 내장 코어가 다를 수 있고 코어를 바꿀 수 있는 경우도 있으므로, 화면이 비슷하다고 지원 프로토콜이나 설정 항목까지 같지는 않습니다. 설정이 호환되지 않으면 클라이언트 이름만 보지 말고 정보 또는 코어 정보 화면에서 실제 실행 중인 코어를 확인한 뒤 해당 문서를 참고하세요.

클라이언트는 설정과 연결을 실행하는 도구일 뿐, 설치만으로 사용할 수 있는 원격 프록시 서비스가 생기지는 않습니다. 구독이나 로컬 설정에는 프록시 노드, 정책 그룹, 규칙 등 필요한 정보가 포함되어야 하며 원격 서비스도 정상적으로 작동해야 합니다. 가져오기 전에 설정 출처가 신뢰할 만한지, 현재 코어가 프로토콜을 지원하는지, 서비스 이용 범위가 어디까지인지 확인하세요. 노드 목록만 들어 있는 구독은 완전한 Clash 설정이 아닐 수 있습니다. 클라이언트가 지원하는 가져오기 형식에 따라 설정 템플릿에 병합해야 할 수도 있습니다.

규칙 모드는 설정에 적힌 순서대로 규칙을 적용하고 정책을 선택하므로 일상적인 트래픽 분산에 적합합니다. 전역 모드는 코어가 처리하는 연결을 전역 정책으로 보내므로 임시 비교 테스트에 유용하고, 직접 연결 모드는 해당 연결을 목적지에 바로 연결해 원격 노드의 영향을 확인할 때 적합합니다. 이 모드는 코어에 들어온 연결을 어떻게 처리할지만 정하며, 어떤 앱의 트래픽이 코어로 들어오는지는 결정하지 않습니다. 전역 모드에서도 특정 앱의 트래픽이 처리되지 않으면 규칙을 계속 바꾸기보다 시스템 프록시나 TUN 설정을 확인하세요.

두 방식은 트래픽을 처리하는 지점이 다릅니다. 시스템 프록시는 운영체제의 프록시 설정을 따라가는 앱의 연결을 유도하지만, 일부 명령줄 프로그램이나 게임, 독자적인 네트워크 스택을 사용하는 앱은 이를 따르지 않을 수 있습니다. TUN은 가상 네트워크 어댑터와 라우팅을 통해 대상 트래픽을 처리하며 권한, DNS, 다른 VPN과의 공존도 고려해야 합니다. 브라우저는 되는데 다른 앱이 연결되지 않는다면 먼저 해당 앱이 명시적 프록시를 지원하는지 확인한 뒤 TUN을 검토하세요. 모든 문제에서 두 방식을 동시에 켤 필요는 없습니다.

프로토콜 이름이 같은 것은 기본 조건일 뿐입니다. 전송 방식, TLS, 인증, 추가 매개변수도 확인해야 합니다. 예를 들어 VLESS의 전송 방식 조합이나 Hysteria2의 대역폭 설정은 코어 기능이나 클라이언트의 가져오기 방식에 따라 지원 여부가 달라질 수 있습니다. 공유 링크, Clash YAML, 다른 클라이언트의 설정 형식도 서로 다릅니다. 서비스 제공자가 지원한다고 명시한 형식을 우선 사용하고, 가져온 뒤 노드 유형과 주요 매개변수를 확인하세요. 오류를 없애려고 인증이나 보안 관련 항목을 임의로 삭제하지 마세요.

클라이언트의 설정 또는 구독 화면에서 원격 설정을 추가하고 전체 링크를 붙여 넣어 저장하세요. 다운로드와 파싱이 끝나면 해당 설정을 현재 설정으로 지정합니다. 다음으로 정책 그룹에서 정상 노드를 선택하고 시스템 프록시를 켜거나 필요에 따라 TUN을 활성화한 뒤 연결 기록을 확인하세요. 클라이언트마다 버튼 이름은 다르지만 다운로드 성공, 설정 활성화, 트래픽 처리는 서로 별개의 단계입니다. 구독 링크에는 접근 인증 정보가 포함될 수 있으므로 공개 스크린샷이나 온라인 변환 사이트, 공개 게시판에 올리지 마세요.

먼저 업데이트 로그를 확인해 도메인 해석 실패, 연결 시간 초과, HTTP 상태 코드 오류, 설정 파싱 실패를 구분하세요. 401 또는 403 응답이면 계정 상태와 링크 권한을 확인하고, 404라면 주소가 바뀌었는지 확인합니다. 요청은 성공했지만 파싱에 실패한다면 로그인 페이지나 오류 안내 페이지, 호환되지 않는 형식을 내려받았을 수 있습니다. 현재 사용할 수 없는 노드가 다운로드에 영향을 주지 않도록 클라이언트가 제공하는 옵션에 따라 직접 연결하거나 기존 프록시를 통해 업데이트해 보세요. 짧은 간격으로 계속 재시도하거나 전체 구독 주소를 공개하지 마세요.

먼저 원본 설정을 보존하고 로그에서 처음 발생한 오류 위치를 확인하세요. 지원되지 않는 항목은 코어 기능과 설정 형식을 점검해야 합니다. 정책 그룹을 찾지 못한다면 규칙 대상, 그룹 이름, 노드 이름이 대소문자와 공백까지 정확히 일치하는지 확인하세요. YAML은 공백으로 들여쓰기하고 목록의 계층도 올바르게 맞춰야 합니다. 구독으로 생성된 설정이라면 업데이트 후 수동 수정이 덮어써지지 않도록 구독 템플릿이나 클라이언트의 오버라이드 설정을 먼저 수정하세요. 한 번에 한 항목씩 바꾼 뒤 클라이언트의 설정 검사를 실행하세요.

TUN은 가상 네트워크 어댑터와 시스템 라우팅을 사용하므로 관련 권한이 필요할 수 있습니다. 데스크톱 클라이언트에 서비스 모드나 권한 보조 프로그램이 있다면 설치 절차에 따라 먼저 권한을 설정하고, 권한이 필요한 작업은 서비스에서 실행하도록 하세요. 화면을 항상 관리자 권한으로 실행하는 것을 기본 해결책으로 삼을 필요는 없습니다. 서비스를 설치한 뒤에도 실패하면 서비스가 시작됐는지, 가상 어댑터가 생성됐는지, 보안 프로그램이 차단하는지 확인하세요. 모바일에서는 시스템 VPN 설정을 허용해야 하며, 권한을 거부하면 관련 트래픽 처리 기능을 사용할 수 없습니다.

mixed-port는 HTTP와 SOCKS 프록시 연결을 모두 받는 수신 포트입니다. 앱의 프록시 주소에는 실제 수신 주소와 포트를 입력해야 하며, 제어 인터페이스 포트를 입력하면 안 됩니다. 이 기기에서만 사용할 때는 루프백 주소에서 수신하도록 설정하면 됩니다. LAN 기기에서 사용하려면 allow-lan, 바인딩 주소, 시스템 방화벽, 인증 설정도 확인하고 신뢰할 수 있는 네트워크로 접근 범위를 제한하세요. 프록시 수신 포트나 제어 인터페이스를 공용 인터넷에 직접 노출하지 마세요. 포트를 바꾼 경우 앱의 명시적 프록시 설정도 함께 수정해야 합니다.

먼저 특정 노드를 선택한 뒤 새 연결을 시도하고, 클라이언트 연결 목록에서 대상 도메인, 매칭된 규칙, 정책 그룹, 실제 노드를 확인하세요. 이미 맺어진 연결은 기존 경로를 계속 사용할 수 있으므로 필요한 경우 대상 앱을 완전히 종료한 후 다시 실행합니다. 외부 IP 확인은 참고가 될 수 있지만 브라우저 아이콘, 시스템 프록시 스위치, 노드 테스트 성공만으로는 충분하지 않습니다. 앱에서 별도의 프록시나 VPN을 사용 중이라면 연결 경로가 겹치지 않도록 먼저 확인하세요. 그렇지 않으면 테스트 결과가 다른 연결을 가리킬 수 있습니다.

규칙은 보통 위에서 아래 순서로 평가되며 처음 일치한 규칙의 정책이 적용됩니다. 구체적인 사용자 지정 규칙은 먼저 적용될 수 있는 포괄적인 규칙보다 위에 배치하고, 대상 정책 그룹이 존재하는지도 확인하세요. 구독 설정에는 클라이언트의 오버라이드나 규칙 병합 기능을 사용하면 생성된 파일을 직접 수정했다가 업데이트로 덮어쓰는 일을 피할 수 있습니다. 현재 설정을 다시 불러왔는지 확인하고 새 연결의 규칙 기록을 살펴보세요. 앱이 IP 주소로 연결하고 코어에 도메인 정보가 없으면 도메인 규칙이 적용되지 않을 수 있으므로 DNS와 트래픽 식별 방식을 함께 점검하세요.

Fake-IP는 도메인과 연결의 관계를 유지하기 위해 코어가 할당하는 가상 주소이며, 대상 서버의 실제 공인 IP 주소가 아닙니다. 앱이 이 주소를 받은 뒤 이어지는 연결은 코어가 처리해야 합니다. 일부 LAN 기기 검색, 기기 관리 기능, 실제 DNS 응답을 요구하는 앱에는 예외 설정이 필요할 수 있습니다. 모든 도메인을 한꺼번에 제외하기보다 해당 도메인에 맞춰 필터를 설정하거나 DNS 경로를 조정하세요. DNS 모드를 바꾼 뒤에는 대상 앱을 다시 시작하고 관련 캐시를 지워 이전 매핑이 진단에 영향을 주지 않도록 하세요.

자동 업데이트는 보통 원격 설정이나 프록시 제공자 데이터를 새로 가져옵니다. 정책 선택이 유지되는지는 클라이언트의 저장 방식과 정책 그룹 이름이 안정적으로 유지되는지에 따라 다릅니다. 원격 설정 파일에 직접 입력한 수정 내용은 다음 다운로드 때 덮어써질 수 있습니다. 고정 규칙이나 DNS 변경은 클라이언트가 지원하는 오버라이드 계층에 넣고 업데이트 후 최종 적용 설정을 확인하세요. 전체 설정 업데이트와 proxy-providers 업데이트는 서로 다른 작업입니다. 예약 업데이트를 설정하기 전에 클라이언트가 제공하는 업데이트 방식이 무엇인지 확인하세요.

명령줄 도구가 데스크톱 시스템 프록시를 읽는다고 단정할 수 없습니다. 먼저 도구 문서를 확인하고 지원되는 프록시 옵션, 전용 설정 또는 환경 변수를 사용해 클라이언트가 실제로 수신 중인 로컬 주소와 포트를 지정하세요. HTTP_PROXY, HTTPS_PROXY, ALL_PROXY와 대소문자 변수 이름의 지원 방식은 도구마다 다르므로 변수 하나가 모든 프로그램에 적용된다고 가정하면 안 됩니다. 테스트 후 필요하지 않다면 해당 터미널 세션이나 설정 파일에서 값을 삭제하세요. 클라이언트를 종료한 뒤에도 프록시 설정을 남겨 두면 도구가 존재하지 않는 로컬 주소에 계속 연결을 시도합니다.

구독 다운로드 주소와 노드 서버는 서로 다른 대상입니다. 구독이 업데이트된다고 노드도 정상이라는 뜻은 아닙니다. 먼저 계정, 트래픽 한도, 서비스 상태를 확인한 뒤 같은 그룹의 다른 노드와 비교하세요. 일부 노드만 실패한다면 해당 노드 서비스를 우선 점검하고, 모든 노드가 실패한다면 로컬 네트워크, 도메인 해석, 시스템 시간, 코어의 프로토콜 지원을 확인합니다. Hysteria2와 TUIC 등은 UDP 경로에도 영향을 받습니다. 테스트 URL 자체에 접속할 수 없어 시간 초과가 발생할 수도 있으므로 실제 접속과 연결 로그를 함께 살펴보세요. 단일 테스트 결과만 보고 클라이언트를 반복해서 재설치하지 마세요.

먼저 코어가 정상적으로 실행 중인지, 로컬 프록시 포트가 실제로 수신 중인지 확인한 뒤 시스템 설정에 입력된 주소와 포트를 대조하세요. 브라우저 확장 프로그램, 기업 정책, 별도 프록시 설정이 시스템 설정을 덮어쓰는지와 대상 주소가 프록시 우회 목록에 포함되는지도 확인합니다. 다음으로 클라이언트에 새 요청이 기록되는지 살펴보세요. 연결 기록이 없다면 트래픽 처리 진입 경로를, 기록이 있다면 규칙과 정책, 노드를 점검하면 됩니다. 프록시 설정을 변경하는 다른 프로그램을 종료한 뒤 다시 테스트해 스위치 상태와 실제 시스템 설정이 일치하는지 확인하세요.

앱 컨테이너로 격리된 일부 Windows 앱은 로컬 루프백 프록시에 직접 접근하지 못해 해당 앱에 루프백 예외를 설정해야 할 수 있습니다. 먼저 일반 데스크톱 브라우저가 같은 프록시를 사용할 수 있는지 확인한 뒤 클라이언트가 제공하는 UWP 루프백 도구나 시스템 관리 도구를 사용하세요. 실제로 필요한 앱만 선택하고 안내에 따라 권한을 부여합니다. 모든 스토어 앱이 같은 네트워크 구조를 사용하는 것은 아니므로 모든 연결 문제를 루프백 제한 탓으로 돌리면 안 됩니다. TUN으로 전환하더라도 라우팅, DNS, 앱의 실제 연결 기록을 확인해야 합니다.

먼저 TUN을 끄고 다른 VPN이나 유사한 트래픽 처리 도구도 일시 중지해 기본 네트워크가 복구되는지 확인하세요. 이후 트래픽 처리 방식은 하나만 활성화하고 기본 경로, DNS 설정, 가상 네트워크 어댑터 상태를 점검합니다. 클라이언트를 종료한 뒤에도 문제가 계속되면 클라이언트의 서비스 중지 또는 네트워크 설정 복구 기능을 사용하고, 수동으로 설정한 프록시나 DNS가 남아 있는지도 확인하세요. 역할을 모르는 상태에서 시스템 경로나 네트워크 어댑터를 한꺼번에 삭제하지 마세요. 기본 연결을 복구한 뒤 로그를 보며 기능을 하나씩 활성화해 문제를 일으키는 최소 설정을 찾으세요.

포트가 사용 중이라면 다른 클라이언트, 이전 코어 프로세스, 백그라운드 서비스가 같은 주소에서 수신 중인지 먼저 확인하세요. 정체를 모르는 시스템 프로세스를 바로 종료하지 마세요. 중복 실행을 중지하거나 수신 포트를 변경한 뒤 앱의 프록시 설정도 함께 수정할 수 있습니다. 클라이언트 종료 후에만 인터넷이 안 된다면 시스템 프록시가 꺼졌는지, 브라우저 확장 프로그램과 터미널 환경 변수가 여전히 로컬 포트를 가리키는지 확인하세요. TUN을 사용한다면 서비스와 라우팅도 정상적으로 종료됐는지 살펴보세요. 자동 시작 환경에서는 창을 닫아도 백그라운드 코어가 계속 실행될 수 있으므로 각각 확인해야 합니다.