Clash 자주 묻는 질문

Clash는 처음에 프록시 코어와 설정 생태계를 가리켰으며, Clash Meta는 이를 바탕으로 발전한 코어 포크입니다. 이후 mihomo라는 이름으로 계속 관리되고 있습니다. 일반적으로 설치하는 GUI 클라이언트는 구독, 프록시 그룹, 설정을 표시하고, 코어는 실제 연결을 처리합니다. 클라이언트 이름이 비슷하다고 해서 코어와 지원 설정 항목까지 동일한 것은 아닙니다. 프로토콜이나 설정이 호환되지 않으면 먼저 정보 화면에서 클라이언트와 코어 정보를 확인한 다음 구독 요구사항과 대조하세요. 이름만 보고 설정을 선택하지 마세요.

클라이언트는 설정을 읽고 트래픽을 전달하는 프로그램이며, 설치 프로그램에 바로 사용할 수 있는 프록시 서비스가 포함되는 경우는 드뭅니다. 사용할 권한이 있는 구독 링크나 설정 파일을 준비해 가져온 뒤 프록시 그룹을 선택하고, 시스템 프록시를 켜거나 필요에 따라 TUN을 활성화해야 합니다. 설정 이름이 표시되는 것은 가져오기가 끝났다는 뜻일 뿐입니다. 프록시 그룹에 선택 가능한 노드가 있는지, 설정이 활성화되어 있는지, 대상 앱의 트래픽이 클라이언트로 전달되는지도 확인하세요. 구독 기간이 끝났거나 트래픽 한도를 초과했다면 구독 제공업체에 문의하세요.

먼저 운영체제에 맞는 항목을 고른 뒤 프로세서 아키텍처와 최소 시스템 요구사항을 확인하세요. Windows, macOS, Android, iOS에서는 Clash Plus를, Linux에서는 Clash Verge Rev를 우선 살펴볼 수 있습니다. 기존 설정을 옮길 때는 클라이언트 코어가 사용 중인 프로토콜, 규칙, DNS 항목을 지원하는지도 확인해야 합니다. Apple Silicon용과 Intel용 설치 파일은 서로 바꿔 사용할 수 없으며, Android에서는 ARM64 또는 ARM 아키텍처를 확인하세요. 선택 가능한 프로그램과 설치 링크, 보관 상태는 다운로드 센터의 플랫폼별 목록을 기준으로 확인하세요.

규칙 모드는 현재 설정의 규칙에 따라 연결을 프록시로 보낼지 직접 연결할지 결정하므로 일상적인 사용에 적합합니다. 전역 모드는 코어로 들어오는 일반 연결을 전역 프록시 그룹으로 보내므로 잠시 비교하거나 문제를 점검할 때 유용하지만, 사용 가능한 노드를 선택해야 합니다. 직접 연결 모드는 코어로 들어온 연결을 대상에 바로 연결하며, 시스템 프록시를 끄거나 클라이언트를 종료하는 기능은 아닙니다. 세 모드는 클라이언트가 이미 처리하는 트래픽에만 영향을 줍니다. 앱이 프록시로 전달되지 않는다면 모드를 바꿔도 연결 경로는 달라지지 않습니다.

구독 링크에는 계정을 식별하는 인증 정보가 포함되는 경우가 많으므로 포럼, 단체 채팅방, 공개 스크린샷에 그대로 올리지 마세요. 문제를 확인할 때는 오류 문구, 클라이언트와 코어 정보, 민감한 내용을 가린 설정 일부를 공유할 수 있습니다. 구독 주소뿐 아니라 노드 비밀번호, 인증 요청 헤더, 로그에 기록된 전체 URL도 가려야 합니다. 링크가 공개됐다면 제공업체 관리 페이지에서 재설정하거나 폐기한 다음 클라이언트의 주소를 업데이트하세요. 채팅 기록만 삭제해서는 기존 링크를 더 이상 사용할 수 없게 만들 수 없습니다.

복사한 주소가 계정 로그인 페이지나 구독 관리 페이지가 아니라 실제 구독 URL인지 확인하세요. 주소 앞뒤의 공백이나 줄바꿈, 누락된 매개변수를 확인한 다음 가져오기 결과와 로그를 살펴보세요. 로그인 페이지, 접근 거부 또는 빈 응답이 반환되면 계정 권한과 네트워크 접근 문제부터 해결해야 합니다. 지원하지 않는 형식이라는 메시지가 나오면 현재 코어와 호환되는 Clash 설정을 제공하는지 업체에 문의하세요. 가져오기가 끝난 뒤에는 설정을 활성화하고 프록시 그룹이 올바른 노드 또는 프록시 제공자를 참조하는지도 확인하세요.

TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 조정하므로 일반적으로 시스템 프록시보다 더 많은 권한이 필요합니다. Windows에서는 클라이언트 안내에 따라 서비스 구성 요소를 설치하고 서비스가 실행 중인지 확인하세요. 필요한 경우 한 번 관리자 권한으로 실행해 확인할 수 있습니다. macOS에서는 시스템에 표시되는 네트워크 확장 또는 보조 구성 요소의 권한을 확인하고, Linux에서는 서비스 권한과 TUN 장치 사용 가능 여부를 점검하세요. 권한을 부여하는 대신 스위치를 반복해서 누르지 마세요. 권한 설정을 마친 뒤 클라이언트를 다시 시작하고 로그에서 인터페이스 생성과 라우팅 설정이 성공했는지 확인하세요.

먼저 시스템 네트워크 설정에서 프록시 주소가 로컬 기기를 가리키는지, 포트가 클라이언트의 현재 수신 포트와 일치하는지 확인하세요. 모든 클라이언트가 같은 포트를 사용한다고 가정하지 마세요. 다른 프록시 프로그램을 종료하고 브라우저에서 프록시를 제어하는 확장 기능도 잠시 비활성화하세요. Firefox 같은 브라우저는 별도의 프록시 설정을 사용할 수 있으므로 시스템 설정을 따르도록 되어 있는지 확인해야 합니다. 새 페이지를 열고 클라이언트 연결 기록을 살펴보세요. 기록이 전혀 없다면 트래픽이 클라이언트로 들어오는 경로를 확인하고, 기록은 있지만 연결에 실패한다면 규칙, 노드, DNS를 점검하세요.

Android에서는 일반적으로 한 번에 하나의 앱만 시스템 VPN 연결을 사용할 수 있습니다. 먼저 다른 VPN 앱과 로컬 VPN 방식으로 동작하는 방화벽 또는 네트워크 필터링 도구를 끈 다음 Clash에 연결 권한을 다시 부여하세요. 시스템에서 상시 VPN 또는 VPN을 통하지 않는 연결 차단을 설정했다면 해당 설정에 연결된 앱도 확인해야 합니다. 연결에 성공하면 클라이언트의 앱별 목록에서 대상 앱이 제외되지 않았는지 점검하세요. 충돌을 해결하려고 모든 설정을 바로 초기화하지 말고 구독과 필요한 설정을 먼저 보존하세요.

먼저 설정을 백업한 다음 오류 메시지에 표시된 줄과 주변 내용을 확인하세요. YAML의 계층 구조는 공백 들여쓰기로 표현하므로 Tab을 사용하지 마세요. 목록 항목, 콜론 뒤 공백, 여는 따옴표와 닫는 따옴표도 올바른지 확인해야 합니다. 오류가 발견된 줄이 표시되더라도 실제로 따옴표가 빠진 위치는 바로 윗줄일 수 있습니다. 형식 오류를 해결한 뒤에도 알 수 없는 항목이라는 메시지가 나오면 코어가 해당 항목을 지원하는지 확인하세요. 구독으로 생성된 설정은 업데이트할 때 덮어쓰이는 경우가 많으므로 장기적으로 유지할 변경 사항은 클라이언트의 오버라이드 또는 병합 기능을 사용하세요.

클라이언트에서 연결 기록을 열고 대상 앱에서 새 네트워크 요청을 보내 도메인, 일치한 규칙, 선택된 프록시 경로를 확인하세요. 기존의 장시간 연결은 이전 경로를 계속 사용할 수 있으므로 설정을 바꾼 뒤에는 연결을 새로 맺어야 합니다. 웹페이지에 표시되는 외부 IP만으로는 모든 라우팅 결과를 알 수 없습니다. 규칙 모드에서는 사이트마다 경로가 다를 수 있습니다. 연결 기록이 없다면 앱이 시스템 프록시를 따르는지 또는 TUN의 앱별 설정에서 제외됐는지 확인하세요. 스위치 색상만으로 트래픽이 정상적으로 전달된다고 판단하지 마세요.

항상 둘 다 켤 필요는 없습니다. 시스템 프록시는 시스템 프록시 설정을 따르는 브라우저와 일반 앱에 적합합니다. TUN은 프록시를 직접 사용하지 않는 더 많은 프로그램의 트래픽을 처리할 수 있지만 라우팅, DNS, 권한 설정이 필요합니다. 처음 문제를 점검할 때는 트래픽을 처리하는 방식을 하나만 사용해 정상 작동하는지 확인한 뒤 클라이언트 안내에 따라 조합하세요. 두 스위치를 모두 켠다고 속도가 빨라지는 것도 아니고, 사용할 수 없는 노드가 자동으로 복구되는 것도 아닙니다. TUN을 켠 뒤 문제가 발생하면 다른 프록시 도구를 더 추가하지 말고 인터페이스, 라우팅, DNS 로그를 확인하세요.

구독 또는 설정 관리 화면에서 자동 업데이트 간격을 찾아 필요에 맞게 설정하고, 업데이트가 클라이언트 실행 중에만 진행되는지 백그라운드 서비스가 처리하는지 확인하세요. 구독 주소를 바꾼 뒤에는 먼저 수동으로 새로 고침하고 업데이트 시간과 오류 메시지를 살펴보세요. 개인 규칙, 프록시 그룹 변경, DNS 설정은 내려받은 구독 내용을 직접 수정하는 대신 클라이언트에서 지원하는 오버라이드 또는 병합 기능으로 저장하는 것이 좋습니다. 업데이트 후 현재 활성화된 설정을 확인하고 기존 노드가 제거됐다면 프록시 그룹에서 사용할 노드를 다시 선택하세요.

컴퓨터와 휴대폰을 서로 통신할 수 있는 신뢰할 수 있는 LAN에 연결하고, 클라이언트에서 LAN 연결 허용을 켠 다음 수신 주소가 LAN 요청을 받도록 설정됐는지 확인하세요. 휴대폰 Wi-Fi의 수동 프록시 서버에는 컴퓨터의 LAN 주소를 입력하고, 포트에는 휴대폰의 루프백 주소가 아닌 클라이언트의 실제 HTTP 또는 혼합 포트를 입력해야 합니다. 컴퓨터 방화벽에서는 필요한 로컬 네트워크 대역만 허용하세요. 프록시 포트를 공용 인터넷에 노출하지 마세요. 수동 HTTP 프록시가 휴대폰의 모든 앱에 적용되는 것은 아니므로 각 앱이 해당 설정을 사용하는지 별도로 확인해야 합니다.

GeoIP 데이터는 IP 주소의 지역을 기준으로 규칙을 적용할 때 사용됩니다. 업데이트에 실패하면 지역 기반 판정이 부정확해질 수 있지만, 모든 도메인 규칙이 바로 작동하지 않게 되는 것은 아닙니다. 먼저 로그에 표시된 데이터 파일 경로와 업데이트 주소에 접근할 수 있는지 확인한 다음 설정에서 MMDB 또는 다른 지리 데이터 형식 중 무엇을 사용하는지, 해당 파일이 있는지 점검하세요. 형식이 다른 파일의 이름만 바꿔 서로 대체하지 마세요. 업데이트 후에는 클라이언트 안내에 따라 설정을 다시 불러오거나 코어를 재시작하고, 연결 기록에서 관련 규칙이 실제로 적용됐는지 확인하세요.

먼저 다운로드 실패와 내용 파싱 실패를 구분하세요. 다운로드에 실패했다면 구독 기간이 끝났는지, 주소가 재설정됐는지, 시스템 시간이 올바른지, 현재 네트워크에서 구독 서비스에 접속할 수 있는지 확인하세요. 파싱에 실패했다면 응답이 실제 설정이 아니라 웹페이지나 오류 메시지인지 확인하고 설정 형식과 코어 지원 여부를 점검하세요. 짧은 간격으로 계속 새로 고침하지 마세요. 일부 서비스는 요청 빈도를 제한합니다. 기존 설정을 계속 사용할 수 있다면 먼저 보존하고 덮어쓰기를 중단하세요. 업체에 문의할 때는 상태 코드와 민감한 정보를 가린 오류를 전달하고 전체 구독 주소는 공개하지 마세요.

모든 노드가 시간 초과됐다고 해서 반드시 구독이 잘못된 것은 아닙니다. 테스트 주소에 접속할 수 없거나 로컬 DNS에 문제가 있거나 방화벽이 연결을 차단했거나 노드 서비스가 중단됐을 수도 있습니다. 먼저 프록시를 사용하지 않는 상태에서 기기가 인터넷에 연결되는지 확인한 뒤 노드를 하나 선택해 실제 대상에 접속하고 연결 로그와 대조하세요. 테스트 결과는 특정 테스트 주소에 대한 확인일 뿐 실제 요청을 대신하지 않습니다. 신뢰할 수 있는 다른 네트워크에서 정상 작동한다면 원래 네트워크의 제한을 확인하세요. 특정 노드만 실패한다면 다른 노드로 확인한 뒤 해당 노드와 발생 시각을 업체에 전달하세요.

먼저 클라이언트에서 시스템 프록시와 TUN을 끄고 프로그램을 종료한 다음 시스템 네트워크 설정에 로컬 기기를 가리키는 프록시가 남아 있지 않은지 확인하세요. 기본 네트워크 연결이 복구되면 클라이언트를 다시 실행하고 트래픽 처리 방식 하나만 켠 뒤 정상 작동이 확인된 노드를 선택하세요. 도메인 확인, 노드 연결, 규칙 적용 중 어느 단계에서 실패하는지 살펴보고 필요한 경우 잠시 전역 모드로 바꿔 비교하세요. 클라이언트를 종료해도 인터넷이 연결되지 않으면 시스템 DNS, 라우팅, 다른 VPN 설정을 확인하세요. 원인을 파악하기 전 여러 네트워크 설정을 한꺼번에 바꾸지 마세요.

AppContainer 샌드박스를 사용하는 일부 Windows 앱은 기본적으로 로컬 루프백 프록시에 접속할 수 없어 브라우저는 정상인데 앱 연결은 실패할 수 있습니다. 먼저 해당 앱이 실제로 로컬 프록시를 사용하는지 확인하고, 클라이언트에서 제공하는 UWP 루프백 도구를 사용해 필요한 앱에만 루프백 예외를 추가하세요. 이 작업에는 관리자 권한이 필요할 수 있습니다. 모든 스토어 앱이 같은 제한을 받는 것은 아니므로 앱 목록에 없다고 다른 패키지 이름을 임의로 적용하지 마세요. 클라이언트 문서를 참고해 TUN 사용을 검토하고 연결 기록으로 효과를 확인할 수도 있습니다.

먼저 로그에 DNS 요청 시간 초과, 확인 실패, 리졸버 연결 오류가 있는지 살펴본 다음 설정에 지정된 DNS 업스트림에 예상한 경로로 접근할 수 있는지 확인하세요. 암호화 DNS 주소가 정확해도 현재 네트워크에서 접속할 수 있다는 뜻은 아닙니다. 서버 도메인을 먼저 확인할 DNS가 필요할 수도 있습니다. fake-ip를 사용한다면 관련 트래픽이 클라이언트에서 처리되는지 확인하고 다른 DNS 도구와 충돌하지 않는지도 살펴보세요. DNS를 변경한 뒤에는 연결을 새로 맺고 필요하면 시스템 캐시를 비우세요. DNS 설정을 한꺼번에 모두 바꾸지 말고 되돌릴 수 있는 설정을 보존한 채 확인 주소와 실제 접속을 하나씩 검증하세요.