Clash 자주 묻는 질문

코어는 연결을 설정하고 도메인을 확인하며 트래픽 분기 규칙을 적용합니다. GUI 클라이언트는 설정 가져오기, 시스템 프록시 전환, 서비스 관리, 로그 표시를 담당합니다. 구독은 원격으로 제공되는 노드 또는 설정 데이터입니다. mihomo는 코어에 해당하며, 이를 사용하는 클라이언트라도 화면 구성과 오버라이드 방식은 서로 다를 수 있습니다. 클라이언트를 설치해도 사용할 수 있는 노드가 자동으로 제공되지는 않습니다. 문제를 해결할 때는 클라이언트 이름, 코어 정보, 설정 출처를 각각 기록해 화면 기능 차이를 프로토콜 오류로 오해하지 않도록 하세요.

Clash Home은 클라이언트와 설정 자료를 제공하는 사이트이며, 원본 Clash나 각 GUI 클라이언트 개발팀을 대표하지 않습니다. Clash 생태계는 여러 독립 프로젝트로 이루어져 있어 이름이 비슷하다는 이유만으로 관리 주체가 같다고 볼 수 없습니다. 다운로드할 때는 클라이언트, 대상 운영체제, 프로세서 아키텍처를 확인하세요. 프로젝트 동작을 확인하려면 해당 프로젝트의 문서, 릴리스 내역, 라이선스 파일을 참고해야 합니다. 이 사이트의 가이드는 일반적인 사용법을 설명하며, 구독 제공업체의 계정 지원이나 소프트웨어 개발자의 문제 제보 채널을 대신하지 않습니다.

일상적인 사용은 보통 규칙 모드로 시작합니다. 연결은 규칙 순서대로 검사되어 지정된 정책으로 처리됩니다. 전역 모드는 코어로 들어오는 연결을 전역 정책으로 보내므로, 분기 규칙이 원인인지 임시로 확인할 때 유용합니다. 단, 모든 기기의 트래픽이 이 모드에서 처리된다는 뜻은 아닙니다. 직접 연결 모드는 일반적으로 코어에 들어온 연결을 대상에 바로 연결하지만, 코어의 DNS 확인과 리스닝 과정은 계속 작동할 수 있습니다. 테스트가 끝나면 원래 모드로 되돌리고, 스위치 상태만 보지 말고 연결 화면에서 실제로 적용된 규칙과 출구를 확인하세요.

서로 다른 개념입니다. 클라이언트의 소프트웨어 라이선스와 노드 서비스를 이용하는 방식은 별개입니다. 소프트웨어를 무료로 쓸 수 있다고 해서 원격 서버까지 무료로 제공되는 것은 아닙니다. 공개 노드는 사용 가능 여부, 운영자 신원, 로그 정책을 확인하기 어려운 경우가 많으므로 민감한 정보를 전송하는 데 사용하지 않는 것이 좋습니다. 출처가 불분명한 설정을 가져오기 전에는 원격 규칙, DNS, 스크립트나 오버라이드 내용, 로컬 제어 인터페이스의 공개 여부를 확인하세요. 구독 주소가 유출됐다면 제공업체에 재발급을 요청해야 합니다. 클라이언트에서 삭제하는 것만으로는 기존 주소를 계속 안전하게 사용할 수 없습니다.

먼저 운영체제에 맞는 클라이언트를 고른 뒤 설정 호환성, 코어 지원, 서비스 설치 방식, 로컬 오버라이드 기능을 확인하세요. Windows 사용자는 Clash Plus를 먼저 살펴보고 Clash Verge Rev, FlClash, Clash Nyanpasu와 비교할 수 있습니다. Clash for Windows는 유지 관리가 중단됐으므로 새 설정의 기본 선택지보다는 기존 환경을 옮길 때 고려할 대상으로 보는 편이 좋습니다. 이전하기 전에 구독 출처, 규칙, 정책 그룹 선택을 백업하고 기존 프로그램 폴더를 그대로 덮어쓰지 마세요. 새 클라이언트와 기존 클라이언트는 따로 테스트해 시스템 프록시를 동시에 변경하거나 같은 포트를 점유하지 않도록 하세요.

설정 화면에서 구독 주소를 추가하고 업데이트가 완료되면 해당 설정을 선택해 현재 실행 설정으로 지정하세요. 그런 다음 프록시 화면에서 실제 사용할 정책 그룹의 노드를 선택하고, 시스템 프록시를 켜거나 필요에 따라 TUN을 활성화합니다. 마지막으로 연결 화면과 로그 화면을 열고 테스트 대상을 방문해 연결이 코어로 들어와 예상한 정책을 적용받는지 확인하세요. 설정 목록에 항목이 표시되는 것은 데이터가 저장됐다는 뜻일 뿐, 설정이 활성화됐다는 뜻은 아닙니다. 노드 속도 테스트에 성공해도 브라우저 트래픽이 클라이언트로 전달되고 있다는 보장은 없습니다.

먼저 업데이트 오류를 확인하세요. 인증 실패나 접근 거부가 표시되면 구독이 만료됐거나 재설정됐는지, 주소를 빠짐없이 복사했는지 확인합니다. 웹페이지나 빈 내용이 반환되면 계정 관리 페이지가 아닌 구독 주소를 복사했는지 확인하세요. 시간 초과라면 먼저 로컬 네트워크를 점검하고, 업데이트 요청이 이미 작동하지 않는 프록시에 의존하는지도 살펴보세요. 전체 구독 주소를 공개 변환 서비스나 공개 포럼에 올리지 마세요. 기존 설정을 계속 사용할 수 있다면 우선 보관한 뒤 제공업체에 형식과 계정 상태를 문의하세요. 삭제했다가 사용할 수 있는 설정까지 잃지 않도록 주의해야 합니다.

로그에 표시된 줄 번호와 그 앞뒤 몇 줄부터 확인하세요. 들여쓰기에 탭과 공백이 섞이지 않았는지, 목록 항목 앞의 하이픈이 빠지지 않았는지, 콜론 뒤에 공백이 있는지 살펴봅니다. 다음으로 파일이 Clash 또는 mihomo에서 인식하는 YAML인지 확인하세요. 웹페이지 내용, Base64 노드 목록, 다른 코어의 JSON이 아닌지도 점검해야 합니다. 구문 분석에 성공한 뒤에는 정책 그룹이 참조하는 노드 이름과 규칙이 참조하는 정책 이름이 실제로 존재하는지 확인하세요. 수정하기 전에 원본 파일을 보관하고 한 번에 한 곳만 고친 뒤 다시 불러오면 구문 오류와 필드 호환성 문제를 구분하기 쉽습니다.

TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 조정하므로 일반 시스템 프록시보다 높은 권한이 필요합니다. 먼저 클라이언트 안내에 따라 서비스나 보조 구성 요소를 설치하고 서비스가 실행 중인지 확인하세요. 데스크톱 운영체제에서는 관리자 권한이 필요할 수 있고, Android에서는 시스템 VPN 연결 요청을 승인해야 합니다. 승인 후에도 실패한다면 다른 VPN, 가상 네트워크 어댑터 도구, 보안 소프트웨어가 차단하는지 확인하세요. 드라이버를 반복해서 설치하지 마세요. 충돌하는 프로그램을 종료하고 관련 서비스를 다시 시작한 다음 로그를 살펴 권한, 인터페이스 생성, 라우팅 기록 중 어느 단계에서 실패했는지 확인하세요.

먼저 시스템 VPN 권한이 유효한지 확인한 다음 클라이언트의 앱별 분기 설정을 살펴보세요. 허용 목록은 선택한 앱만 연결하고, 제외 목록은 지정한 앱을 프록시에서 우회시킵니다. 정책 규칙에서 해당 앱이 접속하는 도메인을 직접 연결로 처리하는지도 확인하세요. Android에서는 일반 VPN 서비스를 보통 한 번에 하나만 사용할 수 있어 다른 VPN이나 로컬 필터링 도구가 현재 연결을 대체할 수 있습니다. 화면을 잠근 뒤 연결이 끊긴다면 배터리 최적화, 백그라운드 실행, 자동 시작 권한도 확인하세요. 설정을 바꿀 때마다 다시 연결하고 로그에서 요청이 코어에 들어오는지 확인하세요.

클라이언트의 연결 화면을 열고 대상에 새로 접속한 뒤 해당 연결의 도메인, 일치한 규칙, 프록시 체인을 확인하세요. 규칙은 보통 위에서부터 순서대로 적용되므로 앞쪽의 포괄적인 규칙이 뒤쪽의 구체적인 규칙보다 먼저 적용될 수 있습니다. MATCH는 마지막에 두어야 하는 기본 규칙입니다. 규칙이나 정책 선택을 바꾼 뒤에도 기존 연결은 이전 출구를 계속 사용할 수 있으므로 관련 연결을 끊거나 대상 앱을 다시 시작한 후 테스트하세요. 연결 화면에 대상 IP만 표시된다면 도메인 확인과 스니핑 조건을 추가로 점검하세요. 웹사이트에 표시된 출구 주소만으로 특정 규칙이 적용됐다고 판단하지 마세요.

구독 업데이트 때 덮어써지는 캐시 파일을 직접 편집하지 말고, 클라이언트의 별도 오버라이드, 설정 병합, 확장 설정 기능을 우선 사용하세요. 병합 순서와 목록 필드가 추가, 앞에 삽입, 전체 교체 중 어떤 방식으로 처리되는지 먼저 확인해야 합니다. 동작 방식은 클라이언트마다 다르므로 모든 소프트웨어가 같다고 가정하지 마세요. 저장한 뒤 최종 실행 설정을 확인해 사용자 지정 규칙의 위치, 정책 그룹 참조, DNS 필드가 유지됐는지 점검하세요. 클라이언트를 바꾸면 오버라이드 방식도 다시 확인해야 합니다. 기존 클라이언트의 스크립트와 확장 파일을 그대로 옮길 수 있는 것은 아닙니다.

공유 사용 가능 여부는 구독 제공업체의 기기 수 제한, 동시 연결 제한, 이용 약관에 따라 달라지며 클라이언트가 이를 바꿀 수는 없습니다. 같은 주소를 쓰더라도 플랫폼마다 지원하는 프로토콜, TUN 매개변수, 오버라이드 방식이 다를 수 있습니다. 노드 출처만 공유하고 운영체제별 필드는 각 기기의 로컬 오버라이드에 두는 편이 안전합니다. 동기화할 때는 필요한 설정만 전달하고, 접속 정보가 포함된 구독 주소를 공개 저장소에 올리지 마세요. 한 기기에서는 작동하지만 다른 기기에서는 실패한다면 먼저 코어 기능과 최종 설정을 비교한 뒤 기기 제한 여부를 확인하세요.

먼저 호스트와 대상 기기가 서로 통신할 수 있는 LAN에 연결돼 있는지 확인하세요. 호스트 클라이언트에서 LAN 연결 허용을 켜고 리스닝 주소와 실제 HTTP 또는 혼합 프록시 포트를 확인합니다. 다른 기기에는 호스트의 LAN IP를 입력해야 하며 127.0.0.1을 입력하면 안 됩니다. 127.0.0.1은 각 기기에서 자기 자신을 가리킵니다. 호스트 방화벽은 필요한 경우에만 신뢰할 수 있는 LAN 접근을 허용하고, 필요하면 프록시 인증을 켜세요. 프록시 포트나 제어 인터페이스를 공용 인터넷에 노출하지 마세요. 호스트가 절전 모드에 들어가거나 IP 주소가 바뀌거나 클라이언트가 종료되면 다른 기기에서도 해당 프록시를 사용할 수 없습니다.

먼저 예상 동작을 정하세요. 어떤 도메인을 어떤 리졸버가 처리해야 하는지, 어떤 연결이 프록시를 통해 나가야 하는지 확인합니다. 테스트 사이트에 표시되는 리졸버는 재귀 DNS 서비스의 출구일 수 있으므로 위치만으로 누출 여부를 판단할 수는 없습니다. 클라이언트의 DNS 로그, 시스템 DNS 설정, 브라우저 보안 DNS, TUN의 DNS 처리 설정을 하나씩 대조하세요. 브라우저에 내장된 암호화 DNS는 미리 지정한 코어 DNS 경로를 우회할 수도 있고, 프록시를 통해 연결될 수도 있으므로 각각 확인해야 합니다. 한 번에 설정 하나만 바꾸면서 DNS 요청과 대상 연결의 실제 경로를 함께 살펴보세요.

먼저 프록시를 잠시 끄고 로컬 네트워크, 시스템 시간, 기본 도메인 확인이 정상인지 점검하세요. 그런 다음 클라이언트를 다시 켜고 설정이 제대로 불러와졌는지 확인합니다. 노드 주소, 포트, 인증 정보, 프로토콜 지원 여부를 점검한 뒤 정상 작동이 확인된 다른 노드와 테스트 대상으로 교차 확인하세요. 속도 테스트 시간 초과는 테스트 주소에 접근할 수 없거나 제한 시간이 너무 짧아서 발생할 수도 있으므로 노드가 완전히 오프라인이라고 단정할 수 없습니다. 모든 노드가 동시에 실패하면 로컬 서비스와 네트워크를 먼저 확인하고, 특정 노드만 실패하면 제공업체에 문의하세요. 반복해서 속도 테스트를 누르는 것보다 오류 유형과 발생 시각을 기록하는 편이 문제를 파악하는 데 도움이 됩니다.

먼저 코어가 실행 중인지, 시스템 프록시에 기록된 주소와 포트가 클라이언트의 리스닝 값과 일치하는지 확인하세요. 이어서 대상 앱이 시스템 프록시를 따르는지 살펴봅니다. 일부 브라우저 확장 프로그램은 프록시 설정을 덮어쓰며, 터미널 도구는 프록시 매개변수나 환경 변수를 별도로 설정해야 하는 경우가 많습니다. 접속해도 연결 화면에 새 기록이 전혀 없다면 대개 트래픽이 코어에 도달하기 전에 문제가 발생한 것입니다. 연결 기록은 있지만 출구가 예상과 다르면 규칙과 정책 그룹을 확인하세요. 문제를 해결하는 동안에는 시스템 프록시를 관리하는 프로그램을 하나만 남겨 다른 클라이언트, 확장 프로그램, VPN이 백그라운드에서 설정을 반복해서 바꾸지 않도록 하세요.

일부 Windows 패키지 앱은 네트워크 격리 때문에 루프백 주소의 프록시에 직접 접근하지 못하지만 일반 데스크톱 브라우저는 정상적으로 작동할 수 있습니다. 먼저 문제가 생긴 앱이 실제로 이 제한을 받는지 확인한 뒤 클라이언트에서 제공하는 UWP 루프백 도구를 사용해 필요한 앱에만 예외를 추가하고 앱을 다시 시작해 테스트하세요. 모든 앱에 권한을 허용하지 마세요. Windows에 포함된 CheckNetIsolation 도구로 예외를 확인하고 관리할 수도 있지만, 먼저 정확한 앱 패키지 식별자를 확인해야 합니다. 루프백 예외는 로컬 접근 제한만 해결하며 노드, DNS, 원격 서비스 문제는 해결하지 못합니다.

포트가 사용 중이면 다른 프록시 클라이언트나 남아 있는 코어 프로세스를 종료한 뒤 어떤 프로세스가 해당 포트를 리스닝하는지 확인하세요. 정체를 모르는 시스템 프로세스를 바로 종료하지 마세요. 현재 클라이언트에서 사용 가능한 다른 포트로 바꿀 수도 있지만, 시스템 프록시와 수동으로 설정한 앱도 함께 업데이트해야 합니다. 클라이언트를 종료한 뒤 인터넷이 되지 않으면 시스템 네트워크 설정에 로컬 포트를 가리키는 수동 프록시가 남아 있는지 먼저 확인하세요. TUN을 사용했다면 관련 서비스와 라우팅이 정상적으로 복구됐는지도 점검합니다. 네트워크를 복구한 뒤 클라이언트 하나만 실행해 여러 인스턴스로 인한 문제가 반복되지 않도록 하세요.

운영체제, 프로세서 아키텍처, 클라이언트 이름, 코어 정보, 현재 모드, 재현 단계와 오류 전후의 짧은 로그를 제공하는 것이 좋습니다. 모든 연결에 영향을 주는지 특정 앱에만 발생하는지, TUN이나 특정 네트워크 또는 규칙에서만 나타나는지도 설명하세요. 제출 전에 전체 구독 주소, 인증 비밀번호, 액세스 토큰, 노드 계정, 불필요한 개인 도메인을 삭제하세요. 스크린샷에도 주소 표시줄과 설정 사이드바에 민감한 정보가 없는지 확인해야 합니다. 민감한 내용을 제거한 최소 설정을 우선 제공하고 설정 폴더 전체를 올리지 마세요. 로그에 신원을 알아볼 수 있는 정보가 남아 있다면 추가로 삭제한 뒤 공개하세요.