Clash 자주 묻는 질문

클라이언트는 설정을 가져오고, 정책을 전환하고, 로그를 확인하는 인터페이스입니다. Mihomo 같은 코어는 실제 연결, 규칙 매칭, DNS 처리를 담당하며, 구독에는 노드와 일부 설정이 포함됩니다. 클라이언트를 설치해도 사용할 수 있는 프록시 서비스가 자동으로 제공되는 것은 아닙니다. 설정하기 전에 구독 출처와 유효 기간, 제공 업체가 지원하는 형식을 확인한 다음 호환되는 클라이언트를 선택하세요. 문제를 해결할 때는 인터페이스 조작 실패, 코어 시작 실패, 구독 서비스 오류를 구분해야 합니다.

일상적인 사용에는 규칙 모드를 권장합니다. 트래픽은 현재 설정의 규칙에 따라 직접 연결하거나 프록시 정책을 따릅니다. 전역 모드에서는 코어로 들어온 요청이 모두 전역 정책을 따르지만, 사용 가능한 노드를 선택해야 합니다. 직접 연결 모드에서는 코어로 들어온 요청이 대상에 바로 연결됩니다. 전역 모드라고 해서 기기의 모든 트래픽을 가로채는 것은 아닙니다. 앱이 코어를 거치는지는 시스템 프록시, 앱 프록시 또는 TUN 설정에 따라 달라집니다. 모드를 비교하면 규칙 문제를 찾는 데 도움이 되며, 테스트 후에는 원래 설정으로 되돌리세요.

공개하지 않는 것이 좋습니다. 구독 주소에는 계정에 연결된 접근 정보가 포함되는 경우가 많아, 전체 링크를 가진 사람이 노드 정보를 확인하거나 서비스 사용량을 소진할 수 있습니다. 스크린샷을 공유할 때는 도메인만 가리지 말고 주소 경로, 쿼리 매개변수, 노드 비밀번호, 제어 인터페이스 키도 가리세요. 링크가 이미 공개됐다면 제공 업체의 관리 페이지에서 구독 주소를 재설정한 뒤 각 기기에서 기존 링크를 교체하세요. 채팅 기록을 삭제해도 이미 유출된 링크가 자동으로 무효화되지는 않습니다.

iOS에서는 App Store에서 Clash Plus를 설치할 수 있습니다. 클라이언트 공식 웹사이트는 clashplus.io이며, 이 사이트의 다운로드 페이지에서 App Store로 이동할 수 있습니다. 가져오기 전에 구독 제공 업체가 해당 클라이언트에 필요한 형식을 지원하는지 확인하세요. 클라이언트마다 스크립트, 규칙 세트, 확장 필드 지원 여부가 다를 수 있습니다. 컴퓨터에서 작동하는 설정이 휴대폰에서도 그대로 작동한다는 보장은 없습니다. 먼저 제공 업체가 안내하는 호환 구독을 가져와 기본 연결을 확인한 다음 사용자 지정 규칙을 하나씩 추가하세요.

그렇지는 않습니다. 일반적인 노드 속도 테스트는 지정된 테스트 주소에 접속했을 때의 응답 시간을 측정합니다. 연결을 맺고 응답을 받기까지 걸린 시간이지, 지속적인 다운로드 대역폭을 직접 나타내는 것은 아닙니다. 실제 속도는 대상 사이트, 회선 혼잡, 서비스 사용량 제한, 로컬 네트워크의 영향을 받습니다. 비교할 때는 같은 테스트 주소와 네트워크 환경을 유지하고, 실제로 이용하는 서비스에서도 확인하세요. 응답 시간은 짧은데 동영상이 끊긴다면 처리량, 패킷 손실, 규칙 매칭 여부를 추가로 점검해야 합니다.

먼저 계정 로그인 페이지나 결제 페이지가 아니라 구독 주소 전체를 복사했는지 확인하세요. 특히 메신저가 주소 끝부분을 잘라내지 않았는지 살펴보세요. 다음으로 제공 업체의 관리 페이지에서 서비스가 유효하고 링크가 재설정되지 않았는지 확인한 뒤, 구독 형식이 코어 요구 사항에 맞는지 점검하세요. 로그에 인증 실패가 표시되면 주소와 계정을 먼저 확인하고, 설정 파싱 오류가 표시되면 응답 내용이 웹페이지이거나 호환되지 않는 설정인지 살펴보세요. 전체 구독 주소를 공개 진단 사이트에 제출하지 마세요.

구독 형식이 현재 클라이언트와 호환되지 않고 제공 업체가 호환 링크를 직접 제공하지 않을 때만 변환을 고려하세요. 제공 업체가 제공하는 형식 옵션을 우선 사용하고, 그다음에는 직접 제어할 수 있는 로컬 변환 도구를 이용하세요. 타사 온라인 변환 서비스는 구독 전체와 노드 인증 정보를 볼 수 있으므로 사용 전에 신뢰할 수 있는지 판단해야 합니다. 변환 후에는 프록시 프로토콜, 정책 그룹 참조, 규칙 세트 주소를 확인하세요. 변환은 형식을 바꿀 뿐, 만료된 계정을 되살리거나 이미 사용할 수 없는 노드를 복구하지는 못합니다.

먼저 클라이언트에 서비스 모드나 보조 서비스 설치 기능이 있는지 확인하고, 현재 버전 안내에 따라 설치한 뒤 클라이언트를 다시 시작하세요. Windows에서는 관련 서비스를 설치할 때 관리자 권한이 필요한 경우가 많습니다. macOS에서는 보조 도구나 네트워크 확장 프로그램을 승인해야 할 수 있습니다. Linux에서는 가상 네트워크 인터페이스 생성과 라우팅 설정 권한이 필요합니다. 그래도 실패하면 로그에서 권한, 인터페이스 생성, 라우팅 충돌 관련 내용을 확인하세요. 출처가 불분명한 권한 상승 명령을 그대로 실행하거나 시스템 보안을 장기간 해제하지 마세요.

먼저 코어가 실행 중인지, 시스템 프록시가 이전 클라이언트의 포트가 아니라 현재 기기에서 실제로 수신 대기 중인 주소와 포트를 가리키는지 확인하세요. 브라우저 확장 프로그램이 별도의 프록시를 지정했는지, 대상 도메인이 시스템 프록시 우회 목록에 포함됐는지도 살펴보세요. 새 요청을 보내 연결 기록에 표시되는지 확인하세요. 기록은 있지만 직접 연결된다면 규칙이나 모드를 점검하고, 기록이 없다면 앱의 트래픽 연결 방식을 확인하세요. 일부 앱은 시스템 프록시를 따르지 않으므로 앱에서 프록시를 별도로 설정하거나 TUN을 사용해야 합니다.

예시 포트를 고정값으로 간주하지 말고 클라이언트의 현재 설정에 표시된 수신 대기 값을 기준으로 하세요. 혼합 포트는 일반적으로 HTTP와 SOCKS 프록시 요청을 모두 받을 수 있습니다. 앱에서 HTTP 프록시를 요구하면 해당 HTTP 포트나 혼합 포트를, SOCKS5를 요구하면 SOCKS 포트나 혼합 포트를 입력하세요. 로컬 앱에는 보통 127.0.0.1을 사용하고, 다른 기기에서는 프록시 호스트의 로컬 네트워크 주소를 입력해야 합니다. 포트가 같아도 프로토콜 표기까지 같은 것은 아니므로 앱의 입력 항목에 맞는 유형을 선택하세요.

구독을 업데이트하면 원격 설정을 다시 가져오는 경우가 많아, 구독에서 생성된 파일을 직접 수정하면 내용이 덮어써질 수 있습니다. 먼저 기존 규칙을 백업한 다음 클라이언트가 덮어쓰기, 병합 또는 별도 규칙 파일을 지원하는지 확인하고, 개인 설정은 지속적으로 유지되는 경로에 저장하세요. 병합한 뒤에는 규칙 순서와 정책 그룹 이름이 여전히 유효한지 확인하세요. 특히 사용자 지정 규칙은 기본 처리 규칙보다 앞에 두어야 합니다. 구독 링크만 내보내서는 보통 로컬 덮어쓰기를 보존할 수 없으므로 여러 기기로 옮길 때 관련 파일도 별도로 백업하세요.

클라이언트의 연결 페이지를 열고 불필요한 기록을 지운 뒤 대상 사이트에 다시 접속하세요. 대상 도메인, 적용된 규칙, 정책 경로, 최종 출구를 확인하면 됩니다. 규칙은 보통 순서대로 매칭되므로 먼저 적용된 규칙이 이후 판단에 영향을 줍니다. 설정을 변경한 뒤에는 기존 연결을 종료하고 다시 테스트하세요. 웹페이지는 여러 도메인에 동시에 요청할 수 있으므로 주소창의 도메인만 보면 이미지나 로그인 API 요청을 놓칠 수 있습니다. 연결 기록에 관련 요청이 전혀 없다면 분기 규칙을 더 수정하기 전에 트래픽 연결 방식을 점검하세요.

가능합니다. 두 기기가 서로 통신할 수 있는 로컬 네트워크에 연결되어 있어야 하며, 컴퓨터 클라이언트에서 로컬 네트워크 연결을 허용하고 수신 주소가 로컬 네트워크 요청을 받도록 설정해야 합니다. 방화벽에서는 신뢰할 수 있는 네트워크에 한해 필요한 포트만 허용하세요. 휴대폰의 네트워크 프록시에는 컴퓨터의 로컬 네트워크 주소와 HTTP 또는 혼합 포트를 입력하고, 127.0.0.1은 입력하지 마세요. 일부 앱은 Wi-Fi의 HTTP 프록시 설정을 따르지 않습니다. 사용을 마치면 공유 기능을 끄고 프록시 포트나 외부 제어 인터페이스를 인터넷에 직접 노출하지 마세요.

기본적으로 둘 다 켤 필요는 없습니다. 브라우저처럼 시스템 설정을 따르는 앱은 먼저 시스템 프록시를 사용할 수 있습니다. 시스템 프록시를 따르지 않는 프로그램의 트래픽까지 연결해야 할 때 TUN을 검토하세요. TUN은 트래픽이 들어오는 경로와 일부 라우팅 동작을 바꾸므로 다른 VPN, 가상 네트워크 어댑터, 보안 소프트웨어와 함께 사용하면 충돌할 수 있습니다. 문제를 해결할 때는 연결 방식을 하나만 남기고 연결과 DNS가 정상인지 확인한 뒤 조합 사용을 고려하세요. 모드를 바꾸기 전에 원래 설정을 기록해 두면 여러 항목을 동시에 변경해 원인을 찾기 어려워지는 일을 막을 수 있습니다.

호환되는 클라이언트에서는 구독 주소를 다시 가져올 수 있지만, 로컬 덮어쓰기, 규칙 파일, 정책 선택, 앱 기본 설정은 구독과 함께 동기화되지 않을 수 있습니다. 옮기기 전에 구독 출처와 로컬 변경 사항을 따로 기록하고 클라이언트의 내보내기 기능으로 백업하세요. 기기마다 수신 주소, 파일 경로, TUN 설정이 다를 수 있으므로 설정 파일 전체를 그대로 덮어쓰지 않는 것이 좋습니다. 클라우드 드라이브나 WebDAV를 사용할 때는 접근 권한을 제한하세요. 백업에 구독 인증 정보나 노드 비밀번호가 포함되어 있다면 보호된 저장 방식을 사용해야 합니다.

먼저 프록시를 끄고 기본 네트워크가 정상인지 확인한 뒤, 시스템 시간과 구독 유효 기간을 점검하고 설정을 한 번 업데이트하세요. 속도 테스트 주소에 접속할 수 있는지 확인한 다음 서로 다른 회선을 수동으로 테스트하고, 로그에서 도메인 조회 실패, 연결 거부, 핸드셰이크 오류가 발생하는지 살펴보세요. 같은 구독이 다른 네트워크에서는 작동한다면 현재 네트워크 제한, 로컬 방화벽, DNS를 우선 확인하세요. 기기와 네트워크를 바꿔도 모두 실패한다면 제공 업체에 서비스 상태를 문의하세요. 테스트 주소 하나만으로 모든 노드를 사용할 수 없다고 판단하지 마세요.

먼저 클라이언트를 다시 열고 시스템 프록시와 TUN을 끈 다음 정상적으로 종료해 프록시와 라우팅 설정이 해제되도록 하세요. 클라이언트를 시작할 수 없다면 운영체제의 네트워크 설정에서 로컬 포트를 가리키는 수동 프록시가 남아 있는지 확인하세요. 해당 클라이언트의 설정이라고 확실한 항목만 제거하고, 업무 네트워크에 필요한 설정은 유지하세요. 문제가 계속되면 가상 네트워크 어댑터, 다른 VPN, DNS 설정을 확인하세요. 복구하기 전에 기존 값을 기록하고 네트워크 설정을 한꺼번에 초기화하지 마세요. 기업 네트워크나 고정 IP 설정에 영향을 줄 수 있습니다.

AppContainer로 격리된 일부 앱은 로컬 프록시에 접근할 때 루프백 제한을 받을 수 있지만, 모든 스토어 앱이 같은 문제를 겪는 것은 아닙니다. 먼저 브라우저에서 시스템 프록시를 통해 정상적으로 접속되는지 확인한 다음, 클라이언트에 UWP 루프백 도구가 있는지 살펴보세요. 필요한 대상 앱에만 예외를 허용하며, 이 작업에는 관리자 권한이 필요할 수 있습니다. 루프백 예외는 로컬 프록시에 접근하지 못하는 문제만 해결할 뿐, 모든 앱이 시스템 프록시를 따르게 하지는 않습니다. 작업을 마친 뒤 대상 앱을 다시 시작하고 연결 페이지에서 요청이 코어에 들어오는지 확인하세요.

먼저 로그에 조회 실패가 명확히 표시되는지 확인한 다음, 노드 서버 도메인을 조회할 수 없는 문제인지 대상 웹사이트 도메인 조회 문제인지 구분하세요. 전자라면 프록시 연결 전에 사용할 수 있는 DNS 조회 경로를 점검해야 하고, 후자라면 설정의 DNS 분기와 규칙도 확인해야 합니다. TUN이나 클라이언트 DNS 기능과 중복되지 않도록 다른 DNS 연결 도구를 일시적으로 끄세요. 한 번에 설정 하나만 바꾸고 기존 연결을 종료한 뒤 운영체제 방식으로 캐시를 비우고 다시 테스트하세요. 흔히 쓰이는 DNS 주소라는 이유만으로 전체 설정을 바로 교체하지 마세요.

먼저 설정과 로컬 덮어쓰기를 백업하고 운영체제, 기기 아키텍처, 클라이언트 이름, 문제가 발생하기 전에 수행한 작업을 기록하세요. 클라이언트에서 지원하는 로그 폴더나 시스템 충돌 기록을 확인하고, 시작 실패 전후의 오류를 중점적으로 보존하세요. 설정 문제로 의심되면 백업한 뒤 최소 설정으로 테스트하고 모든 데이터를 바로 삭제하지 마세요. 로그를 공유하기 전에 구독 주소, 비밀번호, 제어 인터페이스 키를 가리세요. 이전에 작동하던 버전으로 임시 되돌린다면 설정 형식이 해당 버전과 호환되는지도 확인해야 합니다.