Clash 자주 묻는 질문

Clash는 일반적으로 프록시 코어와 그 설정 생태계를 가리키며, mihomo는 이 설정 생태계를 이어 가는 코어 프로젝트입니다. 그래픽 클라이언트에서는 구독 가져오기, 정책 선택, 시스템 프록시 설정 등을 처리하고, 실제 연결은 사용하는 코어가 담당합니다. 따라서 인터페이스가 같아도 지원하는 설정 항목은 다를 수 있고, 같은 코어를 사용해도 설정 메뉴가 동일하다는 보장은 없습니다. 안내서를 찾을 때는 먼저 클라이언트 이름을 확인한 뒤 정보 페이지나 실행 로그에서 코어를 확인하세요. 구버전 Clash의 제한 사항을 mihomo에 그대로 적용하지 않도록 주의해야 합니다.

클라이언트는 프록시 연결을 설정하고 사용하는 도구일 뿐, 설치한다고 사용할 수 있는 노드가 자동으로 생기지는 않습니다. 사용할 권한이 있는 구독 링크나 프록시 노드, 정책 그룹, 규칙이 포함된 설정 파일을 준비해야 합니다. 구독은 보통 서비스 제공업체나 직접 구축한 서비스에서 발급하며, 이 사이트의 다운로드 링크는 구독 서비스가 아닙니다. 가져오기 전에 구독이 해당 클라이언트 형식을 지원하는지 확인하고 링크에 포함된 계정 정보를 안전하게 보관하세요. 구독 주소 전체를 공개 게시판에 올리거나 출처가 불분명한 원격 설정을 가져오지 마세요.

규칙 모드는 설정에 지정된 규칙 순서에 따라 연결을 직접 연결, 프록시 연결, 차단 등의 방식으로 처리합니다. 전역 모드는 코어에 전달된 연결에 전역 정책을 적용하지만, 사용할 수 있는 노드도 선택해야 합니다. 직접 연결 모드에서는 코어에 전달된 연결이 대상에 바로 접속합니다. 세 모드는 코어가 연결을 받은 뒤 처리하는 방식을 바꾸며, 앱이 트래픽을 코어로 전달하는지는 결정하지 않습니다. 따라서 전역 모드로 바꿔도 시스템 프록시나 TUN 설정을 대신할 수 없고, 모든 앱의 트래픽이 프록시를 거친다는 보장도 없습니다.

Clash 생태계에는 각기 독립적으로 관리되는 여러 코어와 그래픽 클라이언트가 있습니다. 페이지에 ‘공식’이라고 적혀 있다는 이유만으로 생태계 전체를 대표한다고 볼 수는 없습니다. 사용하는 클라이언트의 프로젝트 이름, 관리 안내, 배포 경로를 확인하세요. 이 사이트는 다운로드 경로와 한국어 설정 안내를 모아 제공하며, 서로 다른 프로젝트를 하나의 관리 팀이 운영한다고 간주하지 않습니다. Clash for Windows 대체 클라이언트를 찾을 때는 인터페이스보다 유지 관리 상태, 플랫폼 지원, 설정 호환성을 먼저 확인하세요. 오래된 안내서에 나온 설치 파일이나 설정 메뉴 이름은 달라졌을 수 있습니다.

설정 공유 가능 여부는 운영체제뿐 아니라 코어와 설정 항목의 지원 여부에 따라 달라집니다. 기본 규칙과 일반적인 프록시 항목은 호환될 수 있지만, 데스크톱 시스템 프록시, TUN, 파일 경로, 스크립트 관련 설정을 모바일에 그대로 적용할 수는 없습니다. 모바일은 대개 시스템 VPN 인터페이스로 트래픽을 처리하며 권한 설정 경로도 데스크톱과 다릅니다. 기기 간 설정을 가져올 때는 먼저 서비스 제공업체가 해당 기기에 맞는다고 안내한 설정을 사용하고 가져오기 로그를 확인하세요. 지원되지 않는 항목이 있으면 설정 블록을 무작정 삭제하지 말고 사용 중인 클라이언트의 안내를 확인하세요.

클라이언트의 설정 또는 구독 페이지에서 원격 설정을 추가하고 전체 주소를 붙여 넣어 저장한 다음 업데이트하세요. 목록에 새 설정이 나타나면 현재 설정으로 지정해야 합니다. 다운로드 성공만으로는 충분하지 않습니다. 프록시 페이지에서 예상한 정책 그룹이 표시되는지 확인하고, 사용 가능한 노드를 선택한 뒤 시스템 프록시나 모바일 VPN을 켜세요. 마지막으로 실제 사용할 사이트에 접속하고 연결 기록에서 적용된 정책을 확인하세요. 화면에 구독이 저장되었다고 표시되는 것은 주소가 저장되었다는 뜻일 뿐, 설정이 불러와졌거나 연결이 프록시로 전달된다는 뜻은 아닙니다.

먼저 업데이트 오류가 네트워크 시간 초과, HTTP 상태 오류, 설정 파싱 실패 중 무엇인지 확인하세요. 주소가 온전한지, 구독이 만료되었는지, 서비스 제공업체가 접속 주소를 바꾸었는지 점검하세요. 401이나 403은 인증 또는 접근 제한과 관련될 수 있고, 404는 주소가 변경되었음을 뜻할 수 있습니다. 현재 프록시를 사용할 수 없다면 다른 사용 가능한 노드로 바꾸거나, 클라이언트가 지원하는 경우 직접 연결로 업데이트해 보세요. 로그인 페이지나 인증 페이지 같은 HTML을 내려받아도 파싱에 실패할 수 있습니다. 클라이언트를 반복해서 재설치하기보다 구독 서버가 유효한 설정을 반환하는지 먼저 확인하세요.

로그에 나온 줄 번호의 앞뒤를 확인하고 들여쓰기, 콜론 뒤 공백, 목록 항목 앞의 하이픈을 중점적으로 살펴보세요. YAML 들여쓰기에는 공백을 사용해야 합니다. 복사할 때 탭이나 전각 문장 부호가 섞이면 구조가 깨질 수 있습니다. 구독에서 받은 파일이라면 먼저 원본 설정을 다시 다운로드하세요. 설명 없이 구독 주소 끝에 매개변수를 임의로 추가하지 마세요. 문법이 올바른데도 오류가 난다면 현재 코어가 해당 항목을 지원하지 않을 수 있습니다. 수정 전에 사본을 남기고 한 번에 한 곳씩 바꿔야 형식 오류와 항목 호환성 문제를 구분하기 쉽습니다.

먼저 TUN을 중지한 다음 클라이언트가 요구하는 서비스 구성 요소, 관리자 권한, 시스템 네트워크 확장 기능이 설치되어 있고 실행이 허용되었는지 확인하세요. Windows에서는 클라이언트의 서비스 모드를 설치하고 시작해야 하는 경우가 많습니다. macOS에서는 시스템 설정에서 네트워크 확장 기능을 허용해야 할 수 있으니 클라이언트 안내를 따르세요. 모바일에서는 VPN 연결 생성을 허용해야 합니다. 클라이언트 전체를 항상 높은 권한으로 실행하는 방법만 고집하지 마세요. 권한을 허용한 뒤 코어를 다시 시작하세요. 그래도 실패하면 다른 VPN이 네트워크 인터페이스를 사용 중인지 확인하고 로그에 나온 구체적인 오류를 보관하세요.

mixed-port는 HTTP와 SOCKS 프록시 연결을 모두 받는 로컬 수신 포트입니다. 실제 포트 번호는 현재 적용된 설정을 따르며 항상 7890이라고 가정하면 안 됩니다. 시작할 때 주소가 이미 사용 중이라는 메시지가 나오면 다른 클라이언트나 코어 프로세스가 중복 실행 중인지 확인하세요. 중복 프로세스를 종료하거나 사용되지 않는 포트로 바꿀 수 있습니다. 변경한 뒤에는 브라우저, 터미널, 프록시를 수동 설정한 앱의 주소와 포트도 함께 바꾸고 코어를 다시 시작하세요. 설정 파일만 수정하고 다시 불러오지 않으면 이전 포트가 계속 사용될 수 있습니다.

일상적인 사용에는 설정이 대상 주소에 따라 연결 경로를 결정하는 규칙 모드를 먼저 사용하세요. 특정 사이트에 접속 문제가 있으면 잠시 전역 모드로 바꿔 비교하고, 전역 정책에서 사용 가능한 노드를 선택했는지 확인하세요. 전역 모드에서는 정상인데 규칙 모드에서 문제가 생긴다면 해당 연결에 어떤 규칙이 적용됐는지 확인한 뒤 정책이나 규칙 순서를 조정하세요. 점검이 끝나면 다른 연결까지 같은 경로를 사용하지 않도록 원래 모드로 되돌리세요. 전역 모드 테스트는 문제 범위를 좁히는 데 도움이 될 뿐, 원인이 반드시 규칙에 있다는 증거는 아닙니다. 두 모드에서 실제로 선택한 노드가 같은지도 비교해야 합니다.

대상 도메인에 정확한 도메인 규칙이나 도메인 접미사 규칙을 추가하고, 먼저 적용될 수 있는 포괄적인 규칙과 MATCH 기본 규칙보다 앞에 배치하세요. 기본 도메인과 하위 도메인을 모두 포함하려면 DOMAIN-SUFFIX를, 단일 호스트 이름만 대상으로 하려면 DOMAIN을 사용할 수 있습니다. 구독 설정을 수정하기 전에는 다음 업데이트에서 변경 사항이 덮어써지지 않도록 클라이언트의 오버라이드 또는 사용자 지정 규칙 메뉴를 먼저 확인하세요. 저장하고 다시 불러온 뒤 새 연결을 만들어 적용 기록을 확인하세요. 기존 연결은 이전 경로를 계속 사용할 수 있습니다. 사이트가 여러 도메인에 의존한다면 리소스 요청도 각각 어떻게 처리되는지 확인해야 합니다.

시스템 프록시는 시스템 프록시 설정을 읽는 앱에 주로 적용됩니다. 일부 명령줄 도구는 자체 옵션이나 프록시 환경 변수만 읽습니다. 먼저 해당 도구가 지원하는 프록시 설정 방법을 확인한 뒤, 현재 수신 주소와 포트에 맞춰 HTTP_PROXY, HTTPS_PROXY 또는 ALL_PROXY를 설정하세요. 변수 이름과 우선순위는 도구 문서를 따르세요. 이미 열려 있는 터미널은 다시 열어야 할 수 있으며, 도구 자체 설정이 환경 변수를 덮어쓸 수도 있습니다. 점검할 때는 실제 연결 기록을 확인하세요. 테스트가 끝나면 임시 환경 변수를 지워 클라이언트를 종료한 뒤에도 터미널이 작동하지 않는 로컬 포트를 가리키지 않도록 하세요.

Fake-IP는 도메인에 가상 IP를 반환하고 코어가 연결을 원래 도메인과 연결하는 방식입니다. 도메인별로 트래픽을 분기하는 데 유용하지만, 앱의 DNS 조회가 코어가 관리하는 DNS를 거쳐야 합니다. 단순히 옵션 하나만 바꾸기보다 클라이언트 기본 설정과 현재 네트워크의 호환성을 기준으로 사용 여부를 결정하세요. LAN 기기, 일부 게임, 실제 DNS 응답 주소에 의존하는 앱에는 예외 처리가 필요할 수 있습니다. 특정 도메인에서 문제가 생기면 먼저 로그를 확인한 다음 현재 코어가 지원하는 fake-ip-filter 문법으로 예외를 설정하세요. 변경 후 관련 캐시를 지우고 다시 연결하세요.

기존 TCP 연결은 정책 선택이 바뀌어도 보통 새 출구로 자동 이전되지 않습니다. 앱이 연결 풀을 재사용할 수도 있어 전환 직후에도 잠시 이전 노드를 사용하는 것처럼 보일 수 있습니다. 대상 앱의 관련 연결을 종료하거나 클라이언트의 연결 페이지에서 해당 연결을 끊은 뒤 요청을 다시 보내세요. 규칙이나 DNS 설정을 업데이트한 뒤에는 앱 재시작, DNS 캐시 삭제, 코어 다시 불러오기가 필요할 수 있습니다. 이미 열려 있는 웹페이지의 상태만 보고 변경이 적용되지 않았다고 판단하지 말고, 새 연결의 정책 기록을 확인하세요. 진행 중인 작업이 중단되지 않도록 모든 연결을 한꺼번에 끊는 것은 피하세요.

먼저 코어가 실행 중이고 현재 설정이 유효한지 확인한 다음 시스템 프록시 주소가 실제로 수신 중인 로컬 포트를 가리키는지 확인하세요. 브라우저 확장 프로그램, 브라우저 자체 프록시 설정, 다른 프록시 소프트웨어가 시스템 설정을 덮어쓰는지도 살펴보세요. 그런 다음 연결 페이지에서 새 요청을 보내세요. 기록이 없으면 트래픽 유입 경로를 먼저 확인하고, 기록이 있으면 적용된 정책과 오류를 살펴보세요. 다른 브라우저로 잠시 비교하면 브라우저 설정 문제와 네트워크 문제를 구분할 수 있습니다. DNS, 규칙, 노드를 한꺼번에 바꾸지 말고 유입 경로, 정책, 출구 순으로 하나씩 확인해야 원인을 찾기 쉽습니다.

먼저 다른 노드로 바꿔 같은 대상에 접속해 문제가 특정 노드에만 발생하는지 확인하세요. 테스트 시간 초과는 노드 연결 불가, 테스트 주소 문제, 프로토콜 비호환, 현재 네트워크 제한 등 여러 원인으로 발생할 수 있습니다. 한 번의 테스트만으로 구독 전체가 만료됐다고 판단해서는 안 됩니다. 구독이 업데이트되었는지, 기기 시간이 정확한지 확인하고 해당 노드에 연결할 때의 로그를 살펴보세요. 테스트만 실패하고 실제 접속은 정상이라면 테스트 URL을 확인하세요. 실제 접속도 실패하면 사용 가능한 노드를 먼저 이용한 뒤, 발생 시각과 네트워크 유형, 민감 정보를 제거한 오류 요약을 서비스 제공업체에 전달하세요.

앱 컨테이너 격리 때문에 일부 UWP 앱은 로컬 루프백 프록시 주소에 직접 접근할 수 없습니다. 브라우저는 정상인데 특정 UWP 앱만 실패한다면 먼저 해당 앱이 실제로 이 제한을 받는지 확인하세요. 그런 다음 클라이언트에서 제공하는 루프백 예외 도구를 사용해 필요한 앱에만 접근을 허용하세요. 도구가 없다면 Windows CheckNetIsolation 문서를 참고해 해당 패키지의 예외 상태를 확인할 수 있습니다. 이 작업에는 관리자 권한이 필요할 수 있으며 모든 스토어 앱에 적용되는 것도 아닙니다. 권한을 허용한 뒤 대상 앱을 다시 시작하세요. 앱 자체가 시스템 프록시를 읽지 않는다면 별도로 트래픽 처리 방법을 확인해야 합니다.

먼저 앱의 DNS 조회를 누가 처리하는지 확인하고, 코어 DNS 설정과 시스템 DNS, 브라우저 보안 DNS 설정을 비교하세요. 브라우저에 내장된 암호화 DNS는 별도의 경로로 조회할 수 있어 코어의 DNS 정책을 따르지 않을 수 있습니다. 유출 테스트에 표시되는 DNS 서버 위치는 참고 정보일 뿐, 위치만으로 유출 여부를 판단할 수는 없습니다. DNS 로그와 트래픽 경로를 함께 살펴 조회가 예상한 방식으로 전송되는지 확인하세요. TUN이나 DNS 설정을 바꾼 뒤에는 새로 조회하고 필요하면 캐시를 지우세요. IPv6 조회와 LAN 기기의 DNS 경로도 설정에 포함되어 있는지 확인해야 합니다.

클라이언트를 종료한 뒤 인터넷이 끊기면 먼저 시스템에 로컬 포트를 가리키는 수동 프록시 설정이 남아 있는지 확인한 다음 DNS와 VPN 연결 상태를 살펴보세요. 시스템 프록시와 TUN은 가능하면 클라이언트에서 정상적으로 끄세요. TUN을 켠 뒤 프린터, 라우터, LAN 서비스만 작동하지 않는다면 방화벽을 전부 끄기보다 사설 네트워크 대역에 대한 라우팅 제외와 직접 연결 규칙을 확인하세요. 자동 라우팅 방식은 클라이언트마다 다르므로 변경 전에 기존 설정을 기록하세요. 네트워크를 복구한 뒤 기능을 하나씩 다시 켜세요. 문제가 계속되면 경로와 로그 정보를 보관하고 모든 네트워크 설정을 무작정 초기화하지 마세요.