문제 해결 센터 / FAQ
Clash 자주 묻는 질문
설정 및 연결 문제 해결
설정이 불러와지지 않은 것인지, 트래픽이 연결되지 않은 것인지, 출구에 도달할 수 없는 것인지 먼저 구분하세요. 증상에 맞는 항목을 확인하고 한 번에 설정 하나만 바꾸세요. 반복해서 재설치하는 것보다 로그를 확인하는 편이 효과적입니다.
문제 범위 / 개념 및 호환성
입문 가이드
클라이언트는 조작 화면, 커널은 연결 처리, 구독은 설정 제공을 담당합니다. 먼저 이 세 가지 역할을 구분하면 어느 부분을 확인할지 알 수 있습니다.
Clash 클라이언트, mihomo 커널, 구독은 각각 어떤 역할을 하나요?
클라이언트는 설정 가져오기, 프록시 그룹 전환, 로그 확인을 위한 인터페이스를 제공합니다. 커널은 설정을 읽고 연결을 처리하며 트래픽을 분기합니다. mihomo는 계속 발전 중인 Clash 생태계의 커널 중 하나입니다. 구독은 설정이나 노드 정보를 제공하는 주소입니다. 클라이언트를 설치했다고 바로 연결할 수 있는 것은 아니며, 유효한 설정과 해당 서비스도 필요합니다. 문제를 확인할 때는 먼저 설정이 활성화되어 있고 커널이 실행 중인지 확인한 다음 프록시 그룹을 살펴보세요. 구독 문제를 설치 문제로 오해하지 않도록 주의해야 합니다.
규칙·전역·직접 연결 모드, 어떻게 선택하나요?
일상적으로는 규칙 모드를 선택해 설정에 지정된 규칙에 따라 연결 경로를 결정하는 것이 일반적입니다. 전역 모드는 커널이 처리하는 연결에 전역 정책을 적용하므로, 규칙 때문에 문제가 생겼는지 잠시 확인할 때 유용합니다. 직접 연결 모드는 해당 연결을 대상에 바로 연결합니다. 전역 모드라고 해서 시스템의 모든 앱이 프록시를 거치는 것은 아니며, 실제 적용 범위는 시스템 프록시나 TUN 설정에 따라 달라집니다. 테스트한 뒤에는 규칙 모드로 돌아오고, 모드 버튼의 표시만 보지 말고 실제 연결 기록을 확인하세요.
Clash 설정 파일과 Base64 노드 구독은 서로 바로 바꿔 쓸 수 있나요?
링크 모양만으로 호환 여부를 판단할 수는 없습니다. Clash YAML에는 보통 프록시, 프록시 그룹, 규칙 등이 포함되지만, Base64 콘텐츠는 다른 클라이언트용 노드 목록일 뿐 전체 트래픽 분기 설정이 없을 수 있습니다. 구독 제공업체에서 Clash 또는 mihomo 형식이라고 명시된 형식을 선택하세요. 클라이언트에서 형식 변환을 지원한다면 안내에 따라 진행하면 됩니다. 구독 주소에 접근 인증 정보가 포함될 수 있으므로, 잘 모르는 온라인 변환 사이트에 입력하거나 전체 링크를 공개하지 마세요.
이전 버전 Clash 설정을 mihomo에서 바로 사용할 수 있나요?
기본 필드 중 상당수는 그대로 사용할 수 있지만, 모든 설정이 서로 호환된다고 볼 수는 없습니다. mihomo에서 지원하는 일부 프로토콜, DNS 옵션, 확장 규칙은 구형 커널에서 인식되지 않을 수 있고, 서드파티 클라이언트가 설정을 병합하거나 덮어쓸 수도 있습니다. 이전하기 전에 기존 파일을 백업하고, 클라이언트의 설정 검사 기능을 실행한 다음 시작 로그에서 필드나 프로토콜 오류를 확인하세요. 알 수 없는 유형이 표시되면 커널의 지원 범위를 확인해야 합니다. 오류가 난 필드를 무작정 삭제한 뒤 계속 사용하지 마세요.
이 사이트와 클라이언트 프로젝트, 구독 서비스는 어떤 관계인가요?
Clash 튜토리얼은 클라이언트 다운로드 경로와 중국어 설정 자료를 정리한 사이트로, 각 클라이언트 프로젝트 자체가 아니며 구독 계정이나 노드 서비스도 제공하지 않습니다. 클라이언트 다운로드, 커널 기능, 구독 서비스는 서로 다른 영역입니다. 설치 문제는 플랫폼과 권한을, 설정 문제는 형식과 로그를 확인하세요. 계정 만료나 사용량 문제는 실제 서비스 제공업체에 문의해야 합니다. 클라이언트 출처를 확인할 때는 프로젝트 이름과 배포 경로를 대조하세요. 페이지 제목에 ‘Clash 공식 사이트’ 같은 검색어가 있다고 해서 공식 사이트인 것은 아닙니다.
문제 범위 / 가져오기 및 권한
설치 및 설정
설정을 활성화하는 단계부터 시스템 권한 승인까지, 최소한의 연결 경로부터 확인하세요. 클라이언트마다 메뉴 이름은 달라도 점검할 내용은 같습니다.
처음 설치한 뒤 구독이 실제로 활성화됐는지 어떻게 확인하나요?
클라이언트의 설정 또는 구독 페이지에서 주소를 추가하고 다운로드가 끝나면 해당 설정을 직접 선택해 현재 설정으로 지정하세요. 목록에 항목이 보인다고 해서 활성화된 것은 아닙니다. 이어서 커널 실행 상태를 확인하고, 프록시 그룹에 선택 가능한 정책이 있는지 살펴본 다음 시스템 프록시를 켜서 브라우저 접속을 테스트하세요. 화면에 기본 직접 연결 정책만 보인다면 구독 다운로드 결과와 설정 파싱 로그부터 확인하세요. 처음 설정할 때는 먼저 시스템 프록시가 작동하는지 확인한 뒤 필요에 따라 TUN을 켜면 어느 단계에서 문제가 생겼는지 파악하기 쉽습니다.
가져오는 중 YAML 파싱 오류가 나거나 HTML 내용이 표시되면 어떻게 하나요?
먼저 다운로드한 내용이 설정 파일인지 웹페이지인지 확인하세요. 로그에 HTML 태그가 나타난다면 로그인 페이지, 오류 페이지 또는 인증이 필요한 공유 페이지로 연결됐을 가능성이 큽니다. 서비스 제공업체가 안내한 구독 주소를 다시 복사하세요. YAML이 반환됐다면 들여쓰기, 콜론 뒤 공백, 탭 문자 혼입 여부를 확인하고 오류 줄 바로 앞부분도 살펴보세요. 가능하면 원본 설정을 다시 받아오고, 직접 수정하기 전에 사본을 저장하세요. 수정한 뒤에는 클라이언트의 설정 검사 기능을 실행하고 다시 불러오면 됩니다.
mixed-port가 사용 중이라면 포트를 바꿔야 하나요, 클라이언트를 다시 설치해야 하나요?
먼저 다른 프록시 클라이언트와 남아 있는 커널을 종료하고, 같은 수신 포트를 사용 중인 프로세스가 있는지 확인하세요. 보통 재설치할 필요는 없습니다. 충돌하는 프로세스를 종료하거나 mixed-port를 사용하지 않는 포트로 바꾼 뒤 설정을 다시 불러오면 됩니다. 포트를 변경했다면 프록시를 수동 설정한 브라우저, 터미널, 기타 앱의 포트도 함께 수정하세요. 클라이언트가 자동으로 관리하는 시스템 프록시는 껐다가 다시 켜야 합니다. 설정 파일만 바꾸고 앱에 이전 포트가 남아 있으면 커널이 정상 실행돼도 연결되지 않을 수 있습니다.
TUN 권한 부족 또는 가상 네트워크 어댑터 생성 실패는 어떻게 해결하나요?
먼저 TUN을 끄고 일반 시스템 프록시가 작동하는지 확인한 뒤, 클라이언트 안내에 따라 서비스 구성 요소를 설치하거나 복구하세요. Windows에서는 보통 관리자 권한이 필요하고, macOS에서는 보조 프로그램을 승인해야 할 수 있습니다. Linux는 실행 방식과 네트워크 관리 권한에 따라 달라집니다. 권한을 부여한 다음 관련 서비스를 재시작하고 TUN을 켜서 라우팅 및 네트워크 어댑터 로그를 확인하세요. 라우팅 충돌을 피하려면 다른 VPN이나 유사한 트래픽 가로채기 도구도 종료하세요. 안내를 없애려고 시스템 보안 기능을 장기간 끄지는 마세요.
Android와 iOS에 설치한 뒤 필요한 시스템 권한은 무엇인가요?
모바일 기기에서 처음 터널을 만들 때 VPN 구성 권한을 요청하는 경우가 많습니다. 시스템 확인 창에서 허용해야 합니다. Android에서 화면을 잠근 뒤 연결이 끊긴다면 배터리 최적화, 백그라운드 실행, 자동 시작 제한을 확인하세요. 먼저 실제로 백그라운드에서 앱이 종료되는지 살펴본 다음 해당 앱 설정을 조정하세요. iOS에서는 VPN 구성이 활성화되어 있는지, 다른 VPN이 연결을 전환 중인지 확인해야 합니다. 시스템의 VPN 표시는 터널 상태만 나타내며 구독이 유효하거나 모든 대상에 접속할 수 있다는 뜻은 아닙니다. 클라이언트 로그도 함께 확인하세요.
문제 범위 / 테스트 및 트래픽 분기
사용 팁
속도 테스트, 그룹 선택, 규칙 적용은 서로 다른 문제를 확인합니다. 실제 연결로 결과를 검증하고, 한 가지 테스트 결과만으로 전체 연결 경로를 판단하지 마세요.
노드 속도 테스트가 시간 초과로 표시되면 노드를 전혀 사용할 수 없다는 뜻인가요?
꼭 그렇지는 않습니다. 클라이언트 속도 테스트는 보통 지정된 테스트 주소에 접속합니다. 테스트 서버에 연결할 수 없거나 DNS 오류, 핸드셰이크 실패, 노드 자체의 문제 때문에 시간 초과가 발생할 수 있습니다. 먼저 해당 노드로 실제 접속하려는 서비스를 선택하고 연결 로그를 확인하세요. 필요하면 접속 가능 여부가 확인된 다른 테스트 주소를 사용하되, 모든 노드를 같은 조건으로 테스트하세요. 속도 테스트 결과가 다운로드 속도나 모든 웹사이트의 체감 성능과 같지는 않습니다. 여러 노드에서 동시에 실패한다면 테스트를 반복하기보다 로컬 네트워크, 시스템 시간, 구독 상태부터 확인하세요.
수동 선택·자동 선택·장애 조치 프록시 그룹은 어떻게 다른가요?
select는 사용자가 직접 출구를 지정하므로 같은 노드를 계속 사용해야 할 때 적합합니다. url-test는 테스트 결과에 따라 후보를 자동 선택하며, 테스트 주소와 간격이 판단에 영향을 줍니다. fallback은 후보 순서에 따라 사용 가능한 항목을 선택하므로 미리 정한 우선순위를 더 중시합니다. 세 방식 모두 설정에 나열된 후보 안에서만 작동하며 새 노드를 자동으로 추가하지 않습니다. 정책을 바꾸면 보통 새 연결부터 적용됩니다. 기존에 오래 유지 중인 연결은 이전 출구를 계속 사용할 수 있으니, 확인할 때는 테스트 연결을 새로 만드세요.
구독 업데이트 후 덮어쓰이지 않도록 사용자 지정 규칙을 추가하려면 어떻게 하나요?
구독 업데이트 때 교체되는 원격 파일을 직접 수정하지 말고, 클라이언트의 덮어쓰기, 확장 규칙 또는 설정 병합 기능을 우선 사용하세요. 규칙은 위에서 아래 순서로 적용되므로 구체적인 도메인 규칙을 넓은 범위의 규칙과 MATCH 앞에 배치해야 합니다. 대상 프록시 그룹 이름은 실제 설정과 정확히 일치해야 합니다. 규칙을 추가한 뒤 설정을 다시 불러오고, 연결 세부 정보에서 적용된 규칙과 출구를 확인하세요. 클라이언트마다 병합 순서가 다를 수 있습니다. 저장에 성공한 것만으로 끝내지 말고 최종 적용 설정에 규칙이 포함됐는지도 확인하세요.
Fake-IP가 198.18로 시작하는 주소를 반환하면 즉시 꺼야 하나요?
Fake-IP 모드에서 예약된 주소 대역의 매핑 주소가 보이는 것은 일반적으로 정상입니다. 커널은 매핑을 통해 도메인과 연결을 연결하므로 실제 서버가 해당 주소에 있다는 뜻은 아닙니다. 로컬 네트워크 기기, 특정 게임 또는 실제 DNS 응답에 의존하는 앱에 문제가 생기면 필요한 도메인을 fake-ip-filter에 추가하세요. 그런 다음 클라이언트가 지원하는 방식으로 관련 DNS 캐시를 비우고 다시 시도하면 됩니다. 주소가 낯설다는 이유만으로 DNS 설정 전체를 바꾸지 말고, 문제가 발생한 앱과 요청이 커널을 거치는지 먼저 확인하세요.
문제 범위 / 오류 및 복구
문제 해결
먼저 문제가 발생하는 범위를 좁히세요. 모든 앱인지 특정 앱인지, 직접 연결인지 프록시 연결인지, TCP인지 UDP인지 확인한 뒤 설정을 변경하세요.
어제까지 업데이트되던 구독이 오늘 만료되었거나 다운로드에 실패하면 어떻게 하나요?
먼저 서버에서 요청을 거부한 것인지, 로컬 연결이 실패한 것인지 구분하세요. 401, 403 오류는 인증 정보, 권한 또는 서비스 제공업체의 정책과 관련될 수 있고, 404는 주소가 변경됐을 때 흔히 나타납니다. 연결 시간 초과라면 현재 네트워크, DNS, 업데이트 요청에 사용된 출구도 확인해야 합니다. 서비스 제공업체 페이지에 로그인해 유효 기간, 사용량, 최신 주소를 확인하고, 복사할 때 쿼리 매개변수를 빠뜨리거나 공백이 들어가지 않도록 하세요. 현재 사용할 수 없는 노드를 거쳐야만 업데이트할 수 있다면 직접 연결이나 다른 사용 가능한 네트워크로 전환한 뒤 시도하세요. 제한이 추가로 걸리지 않도록 짧은 간격으로 반복 요청하지 마세요.
시스템 프록시를 켰는데 브라우저나 일부 앱에서 적용되지 않으면 어떻게 하나요?
먼저 커널이 예상한 로컬 주소와 포트에서 수신 대기 중인지 확인한 다음, 다른 프로그램이 시스템 프록시 설정을 바꾸지 않았는지 살펴보세요. 브라우저 확장 프로그램, 앱 내부 프록시, 터미널 환경 변수가 시스템 설정을 덮어쓸 수 있습니다. 일부 앱은 시스템 프록시를 아예 사용하지 않습니다. 브라우저에서 새 요청을 보내고 클라이언트의 연결 목록에 해당 기록이 나타나는지 확인하세요. 기록이 없다면 트래픽이 클라이언트로 들어오는 단계부터 살펴보고, 기록이 있다면 규칙과 노드를 확인하세요. 시스템 프록시를 따르지 않는 앱까지 처리해야 할 때 TUN 설정을 고려하면 됩니다.
Windows UWP 앱이 로컬 프록시를 사용하지 못할 때 루프백 제한을 어떻게 확인하나요?
일부 UWP 앱은 네트워크 격리 때문에 로컬 루프백 프록시에 접근하지 못할 수 있습니다. 먼저 일반 데스크톱 브라우저에서 같은 프록시로 접속되는지 확인한 뒤, 클라이언트에 UWP 루프백 예외 도구가 있는지 살펴보세요. 도구가 있다면 필요한 앱에만 예외를 추가하세요. Windows의 CheckNetIsolation 도구로 규칙을 확인하고 관리할 수도 있습니다. 실행 전에 앱 패키지 식별자를 확인하세요. 모든 Microsoft Store 앱에 예외를 적용하지 말고, 모든 스토어 앱 연결 문제를 루프백 제한 탓으로 돌리지 마세요.
웹페이지는 열리는데 게임·동영상·음성 앱 연결에 문제가 생기면 어떻게 하나요?
먼저 대상 앱이 클라이언트의 연결 목록에 표시되는지 확인한 다음, 앱에서 사용하는 TCP 또는 UDP 트래픽이 처리 대상인지, 선택한 노드가 필요한 전송 방식을 지원하는지 살펴보세요. 브라우저가 정상이라는 사실만으로는 일부 연결 경로만 확인된 것이며, 게임이나 음성 앱의 UDP 경로까지 정상이라는 뜻은 아닙니다. TUN을 켠 뒤에만 문제가 생긴다면 잠시 꺼서 비교하고 라우팅, DNS, 다른 VPN과의 충돌을 확인하세요. 한 번에 설정 하나만 바꾸고 결과를 기록하세요. 필요하다면 허가된 다른 네트워크에서도 다시 테스트하세요.
클라이언트를 종료한 뒤 기기 전체에서 인터넷이 안 되면 어떻게 복구하나요?
먼저 시스템 네트워크 설정을 열어 로컬 주소를 가리키는 수동 프록시가 남아 있는지 확인하세요. 커널이 종료되면 해당 수신 포트를 사용할 수 없을 수 있습니다. 남아 있는 프록시를 끄고 TUN 또는 VPN 연결이 정상적으로 끊겼는지 확인하세요. 필요하면 클라이언트를 다시 시작하고, 트래픽 가로채기를 먼저 끈 뒤 종료하는 순서로 진행하세요. 그래도 해결되지 않으면 클라이언트 실행 중에만 사용할 수 있는 DNS 주소가 남아 있는지 확인하고 원래 네트워크 설정으로 복원하세요. 처음부터 네트워크 전체를 초기화하지 말고 원인 파악을 위해 로그와 기존 설정을 보존하세요.
용어의 의미를 확인하려면 개념 빠른 참조를 살펴보세요. 클라이언트 지원 범위를 확인하려면 선택 가이드와 클라이언트 페이지를 참고하세요.