Clash 자주 묻는 질문

클라이언트는 구독 관리, 시스템 프록시 설정, 연결 화면을 담당하고 코어는 프로토콜 연결, DNS 처리, 규칙 매칭을 담당합니다. Clash Meta는 원래 Clash에서 파생된 코어로, 이후 mihomo로 이름이 바뀌었습니다. 클라이언트 이름에 Clash가 들어가더라도 같은 코어를 사용한다는 뜻은 아닙니다. 설정이 작동하는지 확인하려면 먼저 정보 화면이나 코어 설정에서 실제 코어를 확인한 뒤, 지원되는 필드와 프로토콜을 살펴보세요. 다른 클라이언트로 옮길 때는 기존 설정을 백업하고, 화면이 비슷하다는 이유만으로 호환된다고 판단하지 마세요.

클라이언트 설치는 기기에 프로그램을 설치한 것일 뿐, 보통 유효한 구독을 가져오거나 직접 관리하는 설정을 추가해야 합니다. 구독에는 노드 주소, 인증 정보, 정책 그룹 등이 포함되며 클라이언트가 연결 정보를 자동으로 만들어 주지는 않습니다. 가져온 뒤 설정이 활성화되어 있는지, 정책 그룹에서 선택할 항목이 있는지 확인하고 노드를 골라 연결을 테스트하세요. 목록이 비어 있다면 시스템 프록시를 반복해서 켜고 끄기보다 구독 응답 내용과 형식부터 확인하세요. 구독 유효 기간과 사용량은 제공 업체가 정합니다.

기존 설정은 계속 작동할 수 있지만 클라이언트 유지 관리가 종료되었으므로 이후 추가된 프로토콜과 필드까지 지원한다고 볼 수는 없습니다. Clash Verge Rev 같은 클라이언트로 옮기기 전 구독 주소, 정책 그룹 선택, 포트, 사용자 지정 규칙을 기록한 뒤 하나씩 가져와 확인하세요. 새 클라이언트가 파일을 읽을 수 있어도 기존 환경과 동작이 모두 같지는 않습니다. 특히 DNS, TUN, 오버라이드 설정을 확인하세요. 새 환경이 정상적으로 작동하는 것을 확인한 다음 기존 클라이언트를 종료해 두 프록시 프로세스가 시스템 설정을 동시에 바꾸지 않도록 하세요.

규칙 모드는 설정에 적힌 규칙 순서에 따라 연결 경로를 결정합니다. 전역 모드는 보통 코어로 들어온 연결을 전역 정책 그룹으로 보내고, 직접 연결 모드는 해당 연결을 목적지에 바로 연결합니다. 세 모드는 코어가 연결을 받은 뒤 처리하는 방식만 바꿀 뿐, 모든 앱의 트래픽을 코어로 보내지는 않습니다. 처음 사용할 때는 규칙 모드를 선택하고 연결 화면에서 적용된 규칙을 확인하세요. 문제를 비교할 때 잠시 전역 모드로 바꿔 테스트할 수 있지만, 다른 앱의 연결 경로가 바뀌지 않도록 테스트가 끝나면 원래 모드로 되돌리세요.

iOS에서는 다운로드 페이지에서 Clash Plus의 App Store 페이지로 이동할 수 있으며, 공식 웹사이트 clashplus.io에서 제품 안내를 확인할 수 있습니다. 구독을 여러 클라이언트에서 사용할 수 있는지는 지원 프로토콜과 설정 형식에 따라 다르므로 구독 이름만 보고 판단하지 마세요. 가져오기 전에 제공 업체가 안내한 링크 유형을 확인하고, 가져온 뒤 노드와 정책 그룹이 모두 표시되는지 살펴보세요. 데스크톱용 스크립트, 파일 경로, 일부 TUN 필드는 휴대폰에서 그대로 사용할 수 없습니다. 지원하지 않는 필드가 표시되면 반복해서 가져오지 말고 모바일 문서에 맞게 설정을 조정하세요.

먼저 기기 시간이 정확한지, 구독 주소가 온전한지 확인하고 계정이 만료되었거나 사용량을 모두 소진하지 않았는지 살펴보세요. 클라이언트의 업데이트 오류도 확인하세요. 인증 실패라면 링크의 인증 정보를, 시간 초과라면 구독 서버까지의 네트워크 경로를 점검하세요. 형식 오류라면 응답이 로그인 페이지가 아닌 설정 파일인지 확인해야 합니다. 현재 프록시가 작동하지 않아 업데이트가 안 되는 경우, 클라이언트가 지원한다면 직접 연결로 업데이트해 보세요. 구독 주소에는 접속 인증 정보가 포함될 수 있으니 공개 변환 사이트에 입력하거나 스크린샷에 노출하지 마세요. 계속 실패하면 제공 업체에 서비스 상태를 문의하세요.

운영체제의 기기 정보에서 프로세서 아키텍처를 확인한 다음 알맞은 설치 파일을 선택하세요. 일반적인 Intel·AMD 데스크톱 프로세서는 대개 x64를 사용하고, ARM 기기에는 ARM64를 선택하는 것이 좋습니다. Apple Silicon Mac과 Intel Mac도 각각 맞는 파일을 선택해야 합니다. Linux는 프로세서 아키텍처뿐 아니라 배포판의 패키지 형식도 확인하세요. 설치 중 운영체제가 지원되지 않는다고 나오면 클라이언트 릴리스 안내에서 최소 시스템 요구 사항을 확인하세요. 파일 확장자만 바꾸거나 강제로 압축을 푸는 방식으로 정상 설치 절차를 대신하지 마세요.

TUN은 가상 네트워크 어댑터를 만들고 라우팅을 설정해야 하므로 데스크톱 클라이언트는 보통 서비스 모드나 관리자 권한으로 처리합니다. 먼저 TUN을 끄고 클라이언트 설정에서 서비스가 설치되어 실행 중인지 확인한 다음, 해당 클라이언트 안내에 따라 권한을 부여하세요. Linux 서비스와 권한 설정은 설치 방식에 맞춰야 합니다. 회사 기기에서는 드라이버 설치나 라우팅 변경이 제한될 수 있으므로 관리자에게 정책을 확인하세요. 오류를 피하려고 방화벽을 계속 끄거나 라우팅을 제어하는 도구를 여러 개 동시에 실행하지 마세요. 구체적인 오류를 기록한 뒤 서비스를 다시 설치할지 판단하세요.

시스템 프록시는 해당 설정을 따르는 앱에 프록시 주소를 제공할 뿐입니다. 일부 프로그램은 자체 프록시 설정을 사용하고, 기존 연결을 계속 재사용할 수도 있습니다. 먼저 시스템 설정의 주소와 포트가 클라이언트의 혼합 포트와 일치하는지 확인하고, 대상 앱을 다시 시작한 뒤 클라이언트 연결 화면에 새 요청이 표시되는지 살펴보세요. 브라우저 확장 프로그램, 명령줄 환경 변수, 다른 프록시 도구가 시스템 설정을 덮어쓸 수도 있습니다. 앱이 실제로 시스템 프록시를 따르지 않는다면 TUN 사용을 검토하세요. 트래픽이 어디로 들어가는지 확인하기 전에는 노드나 분할 규칙부터 바꾸지 마세요.

AppContainer로 격리된 일부 Windows 앱은 기본적으로 로컬 루프백 주소에 접근하지 못해 기기에서 수신 대기 중인 프록시 포트에 연결하지 못할 수 있습니다. 먼저 문제가 발생한 앱이 이 유형인지 확인하고, 클라이언트에 루프백 예외 관리 기능이 있는지 살펴보세요. 필요한 앱에만 예외를 적용하고 모든 앱을 일괄 허용하지 마세요. Microsoft Store에서 설치한 앱이라고 해서 모두 같은 격리 방식을 사용하는 것은 아니며, 일반 데스크톱 프로그램에는 이 설명을 적용할 수 없습니다. TUN으로 트래픽을 처리하기로 했다면 연결 기록을 다시 확인해 요청이 실제로 코어에 들어오는지 검증하세요.

클라이언트의 연결 화면을 열고 대상 앱에서 새 요청을 보낸 다음, 도메인이나 프로세스로 연결을 찾아 적용된 규칙, 정책 그룹, 실제 출구를 확인하세요. 기존 장기 연결은 이전 정책을 유지할 수 있으므로 규칙을 바꾼 뒤에는 연결을 새로 만들어 확인해야 합니다. 규칙은 대개 순서대로 적용되므로 앞쪽의 포괄적인 규칙이 뒤쪽의 세부 규칙보다 먼저 적용될 수 있습니다. 현재 규칙 모드인지도 확인하세요. 로그에 도메인 조회 기록만 있다고 해서 실제 트래픽이 프록시를 통과했다고 볼 수는 없습니다. 연결 상세 정보와 앱의 접속 결과를 함께 확인하세요.

구독을 업데이트하면 설정을 다시 내려받아 기존 파일을 덮어쓰는 경우가 많으므로 다운로드한 파일을 직접 수정해도 변경 사항이 유지되지 않을 수 있습니다. 계속 사용할 규칙, DNS 설정, 정책 그룹 변경 사항은 클라이언트가 지원하는 오버라이드나 설정 병합 기능에 넣고 병합 순서를 확인하세요. 배열 추가, 필드 덮어쓰기, 스크립트 실행 방식은 클라이언트마다 다를 수 있으므로 다른 프로그램의 설정을 그대로 가져오지 마세요. 규칙 몇 개로 먼저 시험한 뒤 병합된 최종 설정을 확인하세요. 클라이언트를 옮길 때는 구독 링크뿐 아니라 오버라이드 내용도 백업하세요.

Fake-IP는 먼저 앱에 가상 주소를 반환한 뒤, 코어가 주소 매핑을 이용해 도메인을 복원하고 연결을 만듭니다. 덕분에 도메인 정보를 분할 규칙에 활용할 수 있습니다. 일부 로컬 네트워크 서비스나 실제 주소에 의존하는 앱은 이런 응답과 맞지 않을 수 있습니다. 문제가 확인된 도메인만 적절한 필터 설정에 추가하고 모든 도메인을 제외하지 마세요. 변경한 뒤에는 앱이 도메인을 다시 조회하고 연결을 새로 만들도록 해야 합니다. 필터 동작은 코어 버전과 필터 모드에 따라 다르므로 설정을 복사하기 전에 해당 버전의 안내를 읽고 매칭 결과를 반대로 해석하지 않도록 주의하세요.

지연 시간 테스트는 보통 특정 테스트 주소에 요청 한 번을 보내는 데 걸린 시간만 보여 줍니다. 대용량 파일 전송 속도와 같지 않으며 모든 웹사이트의 성능을 나타내지도 않습니다. 같은 기기와 대상, 비슷한 시간대를 기준으로 노드를 비교한 뒤 특정 회선이나 앱에서만 느린지 확인하세요. 이어서 패킷 손실, 서버 부하, 정책 그룹의 출구, 기기의 네트워크 사용량을 살펴보세요. 속도를 측정하는 동안 다른 대용량 작업은 중지해 테스트 간섭을 줄이세요. 직접 연결도 느리다면 클라이언트 설정만 바꾸기보다 로컬 Wi-Fi나 인터넷 회선을 먼저 점검하세요.

먼저 화면 잠금이나 네트워크 전환 뒤에 연결이 일정하게 끊기는지 확인하세요. Android에서는 클라이언트의 백그라운드 실행 권한, 배터리 최적화, 시스템 VPN 설정을 점검하세요. 제조사에 따라 추가 백그라운드 제한이 있을 수 있습니다. iOS에서는 클라이언트의 VPN 상태와 로그를 확인하고, 모든 끊김을 백그라운드 프로세스 탓으로 돌리지 마세요. 화면이 켜져 있을 때도 연결이 안 된다면 구독 유효 기간과 노드 연결을 확인하세요. 프로토콜의 연결 유지 방식, 재연결 빈도, 네트워크 품질이 모두 배터리 사용량에 영향을 줍니다. 프로토콜 이름만으로 특정 설정이 반드시 배터리를 덜 쓴다고 판단할 수는 없습니다.

반드시 그렇지는 않습니다. 테스트 주소에 연결할 수 없거나 DNS에 문제가 있거나 기기 시간이 틀렸거나 코어가 제대로 실행되지 않아도 모든 노드가 시간 초과로 표시될 수 있습니다. 먼저 일반 인터넷 연결이 되는지 확인한 뒤 로그의 오류 유형을 살펴보고, 노드 하나를 선택해 실제 접속을 비교해 보세요. 지연 시간 테스트만 실패하고 웹페이지는 정상적으로 열린다면 테스트 주소와 방식을 확인하세요. 실제 연결도 실패한다면 인증 정보, 계정 상태, 서버 주소를 점검하세요. DNS, TUN, 규칙을 한꺼번에 바꾸면 원인을 찾기 어렵습니다. 한 번에 하나씩 변경하고 기존 값을 기록해 두세요.

먼저 이전 클라이언트나 중복 실행 인스턴스가 백그라운드에 남아 있지 않은지 확인한 다음 앱 로그, 서비스 로그, 시스템 이벤트 기록을 살펴보세요. 포트가 사용 중이라면 해당 포트를 수신 대기하는 프로세스를 찾아 중복 프록시를 종료하거나 비어 있는 포트를 사용하고, 시스템 프록시와 관련 앱 설정도 함께 업데이트하세요. 설정 손상이 의심되면 설정 디렉터리를 백업한 뒤 클라이언트 안내에 따라 새 설정으로 임시 테스트하세요. 자료를 전부 바로 삭제하지 마세요. 런타임이나 시스템 호환성 오류는 릴리스 안내에 따라 처리하세요. 일반 오류 화면을 공유할 때는 구독 주소와 인증 정보를 가리세요.

먼저 TUN을 끄고 비교해 라우팅 제어가 원인인지 확인하세요. 로컬 네트워크 대역, 회사 VPN 경로, 가상 네트워크 어댑터 주소가 충돌하는지 살펴본 다음 코어와 클라이언트가 지원하는 방식으로 라우팅 제외를 설정하세요. 직접 연결 규칙만 추가해서는 트래픽이 잘못된 어댑터로 들어가는 문제를 해결하지 못할 수 있습니다. 회사 네트워크에는 내부 DNS가 필요할 수도 있으므로 이름 조회 경로도 확인하세요. 다른 사람이 공유한 네트워크 대역 제외 목록을 그대로 복사하거나 자동 라우팅 도구를 여러 개 동시에 켜지 마세요. 변경 후에는 공용 인터넷, 로컬 네트워크, 회사 리소스를 각각 테스트하세요.

먼저 어떤 도메인을 어느 DNS 리졸버가 처리해야 하는지, 요청이 직접 연결되어야 하는지 프록시를 거쳐야 하는지 기준을 정하세요. 그런 다음 코어 로그와 검사 결과를 함께 확인해 실제 경로를 파악하세요. 검사 페이지에 표시된 리졸버의 지역이나 이름은 참고 정보일 뿐, 그것만으로 유출을 입증할 수는 없습니다. 브라우저 보안 DNS, 시스템 암호화 DNS, 다른 VPN이 클라이언트의 DNS 설정을 우회할 수도 있습니다. TUN의 DNS 가로채기가 모든 암호화 DNS 트래픽까지 자동으로 처리한다는 뜻은 아닙니다. 앱 설정, DNS 라우팅, 프록시 출구를 각각 확인하고 설정을 바꾼 뒤 연결을 새로 만들어 다시 테스트하세요.

먼저 시스템에 로컬 기기를 가리키는 프록시 주소가 남아 있는지 확인하세요. 프록시 프로세스가 종료된 상태라면 해당 주소로는 연결할 수 없으므로 남은 시스템 프록시를 꺼야 합니다. 이어서 TUN이나 VPN이 여전히 연결되어 있는지, 다른 앱에 수동 프록시나 환경 변수가 남아 있는지 확인하세요. 가능하면 원래 클라이언트를 다시 열어 시스템 프록시와 TUN을 끈 다음 정상적으로 종료하세요. 프로세스를 강제 종료하지 마세요. 문제가 계속되면 라우팅과 DNS 상태를 확인하세요. 회사 네트워크 설정이나 고정 IP 구성을 잃을 수 있으므로 모든 네트워크 설정 초기화를 첫 단계로 삼지 마세요.