Clash 자주 묻는 질문

Clash는 프록시 도구 생태계에서 널리 쓰이는 이름입니다. mihomo는 Clash 설정 체계와 호환되면서 계속 발전하는 프록시 코어로, 연결 처리와 DNS, 규칙 매칭을 담당합니다. 그래픽 클라이언트는 구독 관리, 정책 선택, 로그 확인, 시스템 프록시 설정 기능을 제공합니다. 화면이 비슷해도 코어 버전이나 기능까지 같다는 뜻은 아닙니다. 문제를 진단할 때는 클라이언트 이름과 버전, 코어 버전을 함께 기록하세요. 설정의 프로토콜이나 필드가 지원되는지는 클라이언트 이름만으로 판단하지 말고 실제 실행 중인 코어의 지원 여부를 확인해야 합니다.

클라이언트는 설정을 실행하는 프로그램이지, 그 자체로 사용할 수 있는 프록시 서비스는 아닙니다. 구독에는 보통 프록시 노드와 정책 그룹, 규칙이 포함되지만 노드만 제공되는 경우도 있어 클라이언트 설정 템플릿과 함께 사용해야 합니다. 가져오기 전에 출처가 신뢰할 만한지, 서비스 이용 기간이 남아 있는지, 출력 형식이 현재 코어와 호환되는지 확인하세요. 가져온 뒤에는 해당 설정을 활성화하고 정책 그룹과 프록시 모드를 선택해야 합니다. 링크만 저장해 두어서는 네트워크 경로가 바뀌지 않습니다. 스크린샷이나 공개 문의, 채팅 기록에 구독 주소 전체를 노출하지 마세요. 주소에 포함된 인증 정보가 악용될 수 있습니다.

규칙 모드는 rules에 적힌 순서대로 연결을 매칭해 해당 정책으로 보내므로, 도메인이나 네트워크 범위에 따라 평소 트래픽을 나눌 때 적합합니다. 전역 모드는 코어에 들어온 연결을 전역 정책으로 보내므로 문제가 규칙에서 비롯됐는지 임시로 확인할 때 유용합니다. 직접 연결 모드는 코어에 들어온 연결을 대상에 바로 연결합니다. 전역 모드라고 해서 모든 앱의 트래픽이 클라이언트를 통과하는 것은 아닙니다. 시스템 프록시나 TUN을 거치지 않은 트래픽은 코어에 들어오지 않을 수 있습니다. 모드를 바꾼 뒤 새 연결을 만들어 확인하세요. 기존의 장시간 연결은 이전 경로를 계속 사용할 수 있습니다.

시스템 프록시는 운영체제에 프록시 주소를 등록하는 방식으로, 해당 설정을 사용하는 앱에 주로 적용됩니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 받아 시스템 프록시를 따르지 않는 프로그램을 처리할 때 주로 사용합니다. 두 기능을 반드시 함께 켤 필요는 없습니다. 처음에는 시스템 프록시가 작동하는지 확인한 뒤 앱 사용 환경에 따라 TUN을 켜세요. TUN은 권한과 라우팅, DNS, 다른 네트워크 프로그램과의 호환성에도 영향을 받습니다. 켠 뒤 인터넷이 끊기면 구독을 계속 바꾸기보다 먼저 TUN을 끄고 비교해 보세요. 구체적인 조합 방법은 클라이언트의 구현과 안내를 따르세요.

먼저 설정 페이지에 표시된 업데이트 오류를 확인한 뒤 링크 접속 실패와 콘텐츠 파싱 실패를 구분하세요. 401 또는 403 오류라면 구독 만료 여부, 인증 정보 변경 여부, 서버의 접근 제한을 확인합니다. 404 오류라면 구독 제공자에게 링크가 바뀌었는지 문의하세요. 로그인 페이지나 웹 인증 화면, 형식 오류가 반환되면 받은 내용이 설정 파일이 아닐 수 있습니다. 접속 시간이 초과되면 로컬 네트워크 상태와 클라이언트가 구독을 가져올 때 직접 연결과 프록시 중 어느 쪽을 사용하는지 확인하세요. 업데이트가 성공할 때까지 기존에 사용할 수 있는 설정을 보관하고, 구독 오류의 첫 해결책으로 클라이언트를 재설치하지 마세요.

먼저 원본 파일을 복사해 두고 로그에 표시된 줄 번호 주변을 확인하세요. YAML 계층은 공백으로 들여쓰기해야 하며 탭 문자가 섞이지 않도록 주의합니다. 목록 항목 앞의 하이픈, 콜론 뒤의 공백, 특수 문자가 포함된 문자열도 확인하세요. 문법 오류를 해결한 뒤에는 규칙 대상이 존재하는지, 정책 그룹에서 참조하는 노드 이름이 정확히 일치하는지, 현재 코어가 해당 필드를 지원하는지도 확인해야 합니다. 표시된 줄 번호는 파싱이 중단된 위치일 수 있어 실제 오류가 바로 앞 줄에 있을 수도 있습니다. 한 번에 일부만 수정한 뒤 다시 검사하고, 로드에 성공한 것을 확인한 다음 활성화하면 문제 발생 시 복구하기 쉽습니다.

먼저 코어가 정상적으로 시작되는지 확인한 뒤 클라이언트에서 요구하는 서비스 모드, 보조 프로그램 또는 관리자 권한 승인이 완료됐는지 점검하세요. Windows 클라이언트는 서비스를 설치하고 시작해야 할 수 있고, macOS에서는 보조 프로그램 권한을 확인해야 할 수 있습니다. Linux에서는 가상 인터페이스 접근 권한이나 네트워크 관리 권한이 필요할 수 있습니다. 출처를 알 수 없는 프로그램에 무턱대고 권한을 부여하지 말고 설치 경로와 클라이언트 안내부터 확인하세요. 권한을 승인한 뒤 클라이언트를 다시 시작하고 로그에서 인터페이스 생성과 라우팅 설정이 성공했는지 확인합니다. 조직 정책으로 관리되는 기기라면 관리자가 권한 범위를 확인해야 하며 관리 제한을 우회해서는 안 됩니다.

일부 Windows 패키지 앱은 AppContainer 네트워크 격리의 영향을 받아 로컬 프록시 주소에 접근할 때 루프백 예외가 필요할 수 있습니다. 다만 스토어 앱의 연결 문제를 모두 루프백 탓으로 볼 수는 없습니다. 먼저 같은 시스템 프록시를 사용하는 브라우저에서 접속이 되는지 확인한 뒤 대상 앱의 연결 기록이 생성되는지 살펴보세요. 클라이언트에 루프백 예외 도구가 있다면 실제로 필요한 신뢰할 수 있는 앱에만 적용하세요. 관리자는 시스템 도구로 해당 앱 패키지의 예외 상태를 확인할 수도 있습니다. 설정을 바꾼 뒤 앱을 완전히 종료했다가 다시 실행하세요. 루프백 권한은 로컬 접근 제한만 해결하며 구독, DNS, 원격 연결 문제를 해결해 주지는 않습니다.

시스템 프록시 주소와 포트가 클라이언트의 실제 수신 값과 일치하는지 확인하고 코어가 실행 중인지 살펴보세요. 예시의 기본 포트 7890이 현재 설정에도 사용된다는 보장은 없습니다. 다음으로 앱에 별도의 프록시 설정이 있는지, 시스템 프록시를 무시하는지, 시스템 우회 목록에 대상 주소가 포함되어 있는지 확인하세요. 앱에서 새 요청을 보내면서 클라이언트의 연결 화면이나 로그를 함께 살펴보세요. 기록이 전혀 없다면 분기 규칙을 조정하기 전에 트래픽이 클라이언트로 들어오는 경로부터 확인해야 합니다. 다른 프록시 프로그램이나 네트워크 관리 도구가 시스템 설정을 덮어쓰는지도 확인하고, 필요하면 하나만 남겨 비교하세요.

많은 명령줄 도구는 데스크톱의 시스템 프록시 설정을 자동으로 읽지 않으므로 도구 안내에 따라 HTTP, HTTPS 또는 SOCKS 프록시를 설정해야 합니다. mixed-port를 사용한다면 HTTP 프록시를 지원하는 도구에 로컬 주소와 해당 포트를 입력하세요. external-controller는 트래픽 수신 포트가 아니라 제어 인터페이스이므로 잘못 입력하지 않도록 주의하세요. 터미널 환경 변수는 해당 변수를 읽는 프로그램에만 적용되며 변수 이름과 적용 방식은 도구마다 다릅니다. 변경한 뒤에는 같은 터미널에서 새 프로세스를 실행해 테스트하세요. 먼저 현재 세션에서 임시로 설정해 작동을 확인한 다음 영구 적용하고, 클라이언트를 종료할 때 프록시 설정도 함께 해제해 연결 오류를 방지하세요.

클라이언트의 속도 측정은 보통 지정된 주소로 탐색 요청을 보내며, 결과는 측정 당시 해당 연결 상태만 나타냅니다. 모든 웹사이트에 접속할 수 있다는 뜻도, 실제 다운로드 속도를 그대로 보여 준다는 뜻도 아닙니다. 먼저 현재 정책 그룹에서 실제 선택된 노드가 측정 대상과 같은지 확인하고, 웹 연결이 어떤 정책에 매칭됐는지 살펴보세요. 특정 유형의 사이트만 실패한다면 도메인 조회, 규칙 분류, 대상 서비스의 접근 제한을 확인합니다. 모든 대상이 실패한다면 노드 상태와 로컬 네트워크를 점검하세요. 측정 주소 자체에 접속할 수 없어 결과가 잘못 나올 수도 있으므로 로그와 실제 접속 결과를 함께 확인하고, 지연 시간만 보고 노드를 자주 바꾸지 마세요.

구독 파일은 업데이트할 때 다시 내려받는 경우가 많아 직접 수정한 내용이 덮어써질 수 있습니다. 설정을 계속 유지하려면 클라이언트가 지원하는 오버라이드, 병합 또는 스크립트 기능을 사용하고 목록을 뒤에 추가하는지, 앞에 삽입하는지, 전체 교체하는지 먼저 확인하세요. 사용자 지정 rules의 위치도 중요합니다. 구체적인 규칙은 먼저 매칭될 수 있는 포괄적인 규칙보다 앞에 두고, MATCH는 보통 마지막 기본 규칙으로 둡니다. 수정한 뒤 최종 적용 설정을 확인해 정책 이름 참조가 여전히 유효한지 점검하세요. 오버라이드 형식은 클라이언트마다 다를 수 있으므로 다른 클라이언트로 옮길 때 파일을 그대로 복사하지 말고 다시 확인해야 합니다.

먼저 클라이언트 프록시를 끄고 로컬 네트워크에서 정상적인 직접 연결 대상에 접속할 수 있는지 확인하세요. 그런 다음 구독 유효 기간, 노드가 올바르게 로드됐는지, 기기의 시간이 정확한지 점검합니다. 노드 하나를 골라 실제로 접속해 보고 로그를 통해 도메인 조회 실패, 연결 시간 초과, 인증 실패, 인증서 오류를 구분하세요. 모든 노드가 실패한다면 공통 네트워크 경로나 구독 문제일 수 있으므로 각 노드가 모두 만료됐다고 단정하지 마세요. 가능하다면 신뢰할 수 있는 다른 네트워크에서도 비교하고, 속도 측정만 실패한다면 측정 주소도 확인하세요. 문의할 때는 민감 정보를 가린 오류 내용과 재현 절차를 제공하고 노드 비밀번호나 구독 인증 정보를 공개하지 마세요.

먼저 로그에서 문제가 발생한 도메인이 정상적으로 조회됐는지 확인하고 연결이 올바른 정책으로 들어갔는지 살펴보세요. Fake-IP는 매핑 주소를 사용해 트래픽 분기를 돕지만 일부 앱이나 네트워크 환경과 호환되지 않을 수 있습니다. 다만 페이지가 열리지 않는다는 이유만으로 Fake-IP 문제라고 단정할 수는 없습니다. 원래 설정을 보관한 뒤 클라이언트가 지원하는 방식으로 해석 모드를 임시 전환해 비교하세요. 소수 도메인만 호환되지 않는 것으로 확인되면 모든 도메인을 제외하기보다 코어 문서를 참고해 fake-ip-filter 적용을 검토하세요. 설정을 바꾼 뒤에는 새 연결을 만들어야 하며, 필요한 경우 시스템이나 앱의 DNS 캐시를 비우고 브라우저의 보안 DNS가 예상한 조회 경로를 우회하지 않는지도 확인하세요.

먼저 클라이언트를 중복 실행했거나 다른 프록시 도구를 함께 실행 중인지 확인하세요. Windows에서는 netstat로 수신 대기 포트와 해당 프로세스를 찾을 수 있고, macOS와 Linux에서는 lsof 또는 ss로 확인할 수 있습니다. 프로세스의 용도를 확인한 뒤 종료할 프로그램을 정하세요. 정체를 모르는 시스템 프로세스를 바로 종료하지 마세요. 기존 프로세스를 유지해야 한다면 mixed-port를 사용 가능한 포트로 바꾸고 시스템 프록시, 브라우저 개별 프록시, 터미널 설정도 함께 수정하세요. 오류가 프록시 포트인지 제어 포트인지 구분해야 하며 둘은 서로 대체할 수 없습니다. 변경한 뒤 코어가 정상적으로 포트를 열었는지 확인하고 새 연결로 테스트하세요.

먼저 시스템 프록시가 더 이상 수신하지 않는 로컬 포트를 가리키는지 확인하고 브라우저나 터미널에 별도로 설정한 프록시를 해제하세요. TUN을 사용했다면 클라이언트를 다시 열어 정상 종료 절차로 TUN과 시스템 프록시를 끈 뒤 종료하고, 가상 인터페이스와 라우팅이 복구됐는지 확인하는 것이 좋습니다. 문제가 계속되면 시스템 DNS를 현재 접근할 수 없는 주소로 수동 설정했는지 확인하고 네트워크에 다시 연결하세요. 조치를 시작하기 전에 기존 네트워크 설정을 기록하세요. 회사 네트워크나 고정 IP 환경에서는 특히 중요합니다. 처음부터 모든 네트워크 설정을 초기화하면 필요한 설정까지 함께 사라질 수 있습니다.