Clash 자주 묻는 질문
설치·설정·연결 문제 해결

클라이언트는 설정을 불러오고 프록시 트래픽을 전달하며 규칙을 적용하지만, 사용할 원격 서버를 직접 제공하지는 않습니다. 구독은 보통 서비스 제공업체가 제공하며 서버 주소, 인증 정보, 프록시 그룹과 트래픽 분리 규칙이 포함됩니다. Config 또는 Profiles 페이지에서 구독을 가져온 뒤 해당 설정을 선택하고, 프록시 페이지에서 사용할 출구 노드를 선택해야 합니다. 설치만 했거나 구독 주소만 저장한 경우, 또는 가져온 설정을 활성화하지 않은 경우에는 연결이 성립하지 않습니다. 구독 주소에는 민감한 정보가 포함될 수 있으므로 공개 댓글이나 스크린샷에 전체 주소를 올리지 마세요.

코어는 설정을 읽고 규칙을 적용해 프록시 연결을 설정합니다. GUI 클라이언트는 설정 목록, 시스템 프록시 스위치, 로그와 설치 옵션을 보여줍니다. mihomo는 계속 발전하고 있는 Clash 생태계의 코어지만, Clash라는 이름이 붙은 모든 클라이언트가 같은 코어를 사용하거나 같은 설정 항목을 지원하는 것은 아닙니다. 호환성 문제를 확인할 때는 정보 또는 코어 정보 페이지에서 클라이언트 이름, 코어 종류와 오류가 발생한 설정 항목을 기록하세요. 클라이언트마다 버튼 위치가 다를 수 있으니 실제 화면에서 설정 이름을 찾아야 하며, 튜토리얼 스크린샷의 위치만 보고 조작하지 마세요.

규칙 모드는 설정에 정의된 규칙을 차례로 적용해 대상별로 직접 연결, 프록시 그룹 또는 차단 정책을 선택하므로 일상적인 사용에 적합합니다. 글로벌 모드는 코어로 들어오는 트래픽에 글로벌 정책 그룹을 적용하지만, 해당 그룹에서 사용할 출구 노드를 직접 선택해야 합니다. 모든 앱의 트래픽을 자동으로 가로채는 모드는 아닙니다. 직접 연결 모드는 코어로 들어온 연결을 대상에 바로 연결하므로 비교 테스트에 유용합니다. 모드를 바꿔도 기존 장시간 연결은 이전 경로를 계속 사용할 수 있으니 페이지를 새로 열거나 관련 앱을 다시 시작하세요. 트래픽을 가로챌 범위를 바꾸려면 모드만 전환하지 말고 시스템 프록시 또는 TUN 설정을 확인하세요.

기존 클라이언트가 기존 설정을 계속 읽을 수는 있지만, 지원이 종료되면 향후 시스템 호환성, 프로토콜 확장과 오류 수정이 보장되지 않습니다. 이전하기 전에 로컬 규칙, 오버라이드 설정과 구독 출처를 내보낸 뒤 필요한 설정 문법을 지원하고 계속 관리되는 클라이언트를 선택하세요. 기존 프로그램 폴더 전체를 새 클라이언트 폴더에 덮어쓰지 마세요. 먼저 원본 구독을 가져와 설정을 불러오고 연결할 수 있는지 확인한 다음, 사용자 지정 DNS, 포트와 규칙을 하나씩 옮기세요. 알 수 없는 설정 항목이나 지원되지 않는 프로토콜이 나타나면 새 클라이언트 로그를 확인하고 구독 제공업체에 호환 형식을 문의하세요.

먼저 구독을 가져오는 단계에서 실패했는지, 설정을 해석하는 단계에서 실패했는지 구분하세요. 401 또는 403 오류가 발생하면 구독 만료 여부, 주소 재설정 여부와 서비스 제공업체의 접근 제한을 확인하세요. 시간 초과라면 현재 네트워크와 클라이언트의 구독 업데이트 프록시 설정을 점검하세요. YAML 파싱 오류가 표시되면 로그인 페이지나 오류 페이지가 반환됐거나 설정 형식이 호환되지 않을 수 있습니다. 구독 주소 전체를 다시 복사하고 불필요한 공백이 들어가지 않았는지 확인하세요. 업데이트 전에 정상 작동하는 설정을 보관하고, 실패했다고 반복해서 삭제하거나 다시 만들지 마세요. 인증 정보가 포함된 주소를 낯선 온라인 구독 변환 서비스에 입력하지 마세요.

먼저 클라이언트 설정에서 서비스 모드, 보조 프로그램 또는 가상 네트워크 어댑터 구성요소가 제대로 설치됐는지 확인한 뒤 클라이언트 안내에 따라 권한을 허용하세요. Windows에서는 보통 필요한 권한을 가진 서비스를 설치해야 합니다. macOS에서는 네트워크 관련 권한을 승인해야 할 수 있으며, Linux의 권한 설정은 패키지와 서비스 구성에 따라 다릅니다. 서비스 설치 오류를 가리기 위해 프로그램 전체의 권한을 계속 높이지 마세요. 처음 테스트할 때는 다른 VPN이나 가상 네트워크 어댑터 도구를 끄고, TUN을 켠 뒤 로그에서 어댑터와 라우팅 오류를 확인하세요. 인터넷이 끊기면 먼저 TUN을 꺼서 연결을 복구한 다음 구체적인 오류를 점검하세요.

먼저 중복 실행된 클라이언트를 종료한 뒤 해당 포트를 사용 중인 프로세스를 찾아 용도를 확인하세요. 정체를 알 수 없는 시스템 서비스를 무작정 종료하지 마세요. 클라이언트의 포트 설정에서 mixed-port를 변경할 수도 있습니다. 설정을 적용한 뒤 로그에서 새 포트가 수신 대기 중인지 확인하세요. 그런 다음 시스템 프록시를 껐다가 다시 켜고, 브라우저의 수동 프록시, 터미널 환경 변수와 앱 내부 프록시 주소도 함께 수정하세요. external-controller는 제어 인터페이스이며 브라우저가 사용할 프록시 포트가 아니므로 혼동하지 마세요. 구독 오버라이드가 포트 값을 덮어쓸 수 있으니 업데이트 후에도 변경 사항이 유지되는 위치인지 확인하세요.

앱 컨테이너 제한이 적용되는 일부 Windows 앱은 로컬 루프백 프록시에 직접 연결할 수 없습니다. 먼저 일반 브라우저가 같은 클라이언트를 통해 인터넷에 연결되는지 확인하세요. 그런 다음 클라이언트에서 제공하는 UWP 루프백 도구를 사용해 로컬 프록시가 필요한 앱에만 예외를 허용하세요. 관리자 권한이 필요할 수 있습니다. 내장 도구가 없다면 Windows의 CheckNetIsolation 도구에서 앱 패키지 ID를 기준으로 관리할 수 있습니다. 모든 앱에 무조건 예외를 허용하지 마세요. 클라이언트가 TUN으로 트래픽을 처리한다면 라우팅이나 DNS가 원인일 수도 있으므로 로그를 확인해 구분해야 합니다. 모든 스토어 앱 오류를 루프백 문제로 단정하지 마세요.

시스템 프록시는 해당 설정을 읽는 앱에만 영향을 줍니다. 브라우저 확장 프로그램, 브라우저 자체 프록시 설정과 터미널 환경 변수가 실제 연결 경로를 바꿀 수 있습니다. 먼저 프록시 확장 프로그램을 잠시 끄고, 시스템 설정의 프록시 주소가 클라이언트에서 수신 대기 중인 포트를 가리키는지 확인한 뒤 브라우저를 따로 테스트하세요. 터미널에서는 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY와 각 변수의 소문자 형태를 확인하고, 값을 변경한 뒤 터미널을 다시 여세요. 프록시 설정에 제어 인터페이스 포트를 입력하지 마세요. 시스템 프록시를 읽지 않는 앱은 앱 자체 프록시 옵션을 사용하거나, 라우팅과 권한을 확인한 뒤 TUN을 사용할 수 있습니다.

속도 테스트는 클라이언트에서 지정된 테스트 주소로 보낸 한 번의 요청만 보여줍니다. 모든 웹사이트, 프로토콜과 연결 방식이 정상이라는 뜻은 아닙니다. 먼저 현재 규칙이 어떤 프록시 그룹에 적용됐는지, 그 그룹에서 실제로 어떤 출구 노드를 선택했는지 확인한 뒤 실패한 요청의 로그를 살펴보세요. 테스트 주소에는 연결되지만 대상 사이트에 접속할 수 없다면 사이트 제한, DNS, 서버 출구 또는 프로토콜 호환성 문제일 수 있습니다. 지연 시간만 보고 노드를 반복해서 바꾸지 마세요. 같은 대상과 모드에서 출구를 하나씩 비교하고, 노드를 바꾼 뒤 기존 연결을 종료해야 선택한 노드가 달라진 영향을 확인할 수 있습니다.

클라이언트에서 제공하는 오버라이드, 설정 병합 또는 규칙 확장 기능을 우선 사용하세요. 다음 업데이트 때 교체될 구독 캐시 파일을 직접 수정하지 마세요. 먼저 적용할 도메인과 원하는 정책을 정한 뒤, 먼저 일치할 수 있는 포괄적인 규칙보다 앞에 새 규칙을 배치하세요. MATCH는 보통 마지막 기본 규칙으로 사용합니다. 정책 이름은 설정의 프록시 그룹 이름과 정확히 일치해야 합니다. 적용 후 연결 정보나 로그에서 실제로 어떤 규칙이 적용됐는지 확인하고, 구독을 다시 업데이트해 규칙이 유지되는지도 점검하세요. GEOSITE 등의 규칙은 관련 데이터 파일과 코어 지원이 필요할 수 있으므로 실행 조건을 확인하지 않고 규칙 문장만 복사하지 마세요.

클라이언트 설정에서 시작 시 자동 실행을 켠 뒤 시스템의 시작 프로그램 또는 로그인 항목에서도 실행이 허용됐는지 확인하세요. 시작 시 자동 실행, 시스템 프록시 자동 활성화와 TUN 자동 시작은 별도 설정인 경우가 많으므로 하나의 스위치만으로 전체 설정이 완료됐다고 생각하지 마세요. 재부팅 후 프로세스, 활성화된 설정과 포트 수신 상태를 확인하고 웹페이지를 열어 테스트하세요. 종료 전에 클라이언트를 정상적으로 닫지 않으면 시스템에 로컬 주소를 가리키는 프록시 설정이 남을 수 있습니다. 클라이언트가 실행되지 않은 상태에서 이 설정이 남아 있으면 인터넷에 연결되지 않습니다. 먼저 시스템 프록시를 꺼서 연결을 복구한 뒤 자동 실행 권한과 서비스 상태를 확인하세요.

먼저 프록시를 끄고 평소 직접 연결하는 사이트에 로컬 네트워크로 접속할 수 있는지 확인한 다음, 시스템 시간, 구독 상태와 현재 설정의 로드 여부를 점검하세요. 프록시를 다시 켠 뒤 출구 노드 하나만 선택해 같은 대상을 테스트하고, 로그에서 서버 연결 시간 초과, 인증 실패 또는 대상 연결 실패 중 어떤 오류인지 확인하세요. 다른 네트워크를 사용하면 현재 네트워크가 연결을 제한하는지 알아볼 수 있습니다. 이때 나머지 설정은 그대로 유지하세요. 서로 다른 네트워크에서 여러 출구 노드가 모두 실패하면 서비스 제공업체에 상태를 문의하세요. 시간 초과 값을 늘려도 대기 시간만 길어질 뿐, 잘못된 주소나 인증 정보 또는 원격 서버 연결 불가 문제는 해결되지 않습니다.

먼저 도메인 이름 확인 자체가 실패하는지, 아니면 예상과 다른 경로로 DNS 요청이 처리되는지 구분하세요. 현재 적용 중인 설정의 dns 항목과 클라이언트 오버라이드에서 nameserver, fallback 또는 향상 모드가 바뀌었는지 확인하세요. 이러한 항목의 작동 방식은 코어 지원 여부에 따라 달라질 수 있습니다. 브라우저의 보안 DNS, 시스템의 암호화 DNS와 다른 VPN은 별도의 DNS 경로를 사용할 수 있으므로 각각 기록하고 비교 테스트하세요. TUN을 사용한다면 DNS 하이재킹과 라우팅이 실제로 적용되는지도 확인해야 합니다. 테스트 사이트에 표시되는 DNS 서버 위치는 참고 정보일 뿐, 모든 앱의 DNS 경로를 증명하지는 않습니다. 설정을 바꾼 뒤 로그와 실제 요청을 함께 확인하세요.

인증서 검증을 끄거나 출처가 불분명한 루트 인증서를 설치해 오류를 우회하지 마세요. 먼저 시스템 날짜, 시간과 시간대가 올바른지 확인한 뒤 프록시를 끈 경우, 출구 노드를 바꾼 경우와 네트워크를 변경한 경우를 비교하세요. 특정 출구에서만 인증서 오류가 발생하면 해당 출구 사용을 중단하고 서비스 제공업체에 알리세요. 기업 네트워크, 공용 네트워크의 로그인 페이지와 보안 소프트웨어의 HTTPS 검사도 인증서 체인에 영향을 줄 수 있으므로 해당 네트워크의 관리 지침에 따라 처리하세요. 문의할 때는 오류 코드와 대상 도메인만 기록하고, 계정 정보나 구독 주소 또는 전체 요청 매개변수가 포함된 스크린샷과 로그는 보내지 마세요.

먼저 시스템 네트워크 설정에서 남아 있는 수동 프록시를 끄고 기본 네트워크가 복구됐는지 확인하세요. 이전에 TUN을 사용했다면 클라이언트를 다시 실행한 뒤 해당 기능을 정상적으로 끄고, 필요한 경우 시스템을 재시작해 임시 라우팅을 정리하세요. 재설치하기 전에 설정 폴더, 오버라이드 규칙과 오류 발생 시간대의 로그를 백업하고, 공유하기 전 구독 주소와 인증 정보를 삭제하세요. 그런 다음 최소 설정으로 실행해 기능을 하나씩 복구하면서 특정 설정이나 권한 작업이 충돌을 일으키는지 확인하세요. 모바일 기기에서는 VPN 권한, 배터리 백그라운드 제한과 다른 VPN의 점유 상태도 확인하세요. 문제를 파악할 단서를 잃지 않도록 앱 데이터를 바로 삭제하지 마세요.