Clash 자주 묻는 질문
설정 및 연결 문제 해결

클라이언트는 구독 관리, UI 조작, 시스템 연동을 담당하고 코어는 프로토콜 연결, DNS 처리, 규칙 매칭을 담당합니다. Clash.Meta는 Clash 생태계에서 발전한 코어 포크로, 이후 mihomo라는 이름으로 유지 관리되고 있습니다. 원본 Clash와 mihomo를 같은 기능 집합으로 보면 안 됩니다. 프로토콜 지원 여부는 앱 이름만 볼 것이 아니라 클라이언트가 실제로 사용하는 코어와 지원 목록을 확인해야 합니다. 같은 YAML도 코어에 따라 결과가 다를 수 있으므로 전환 전에 설정을 백업하고, 로그에 알 수 없는 필드나 미지원 프로토콜 안내가 있는지 살펴보세요.

새로 설치할 클라이언트는 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu의 운영체제 지원 범위, 코어 업데이트 방식, 서비스 모드를 비교한 뒤 사용 습관에 맞춰 선택하세요. Clash for Windows는 지원이 종료됐으므로 구버전이 실행되더라도 새 프로토콜을 인식하거나 향후 시스템 변경에 대응한다는 보장은 없습니다. 이전할 때는 구독 주소와 직접 추가한 규칙을 내보낸 뒤 새 클라이언트에서 다시 가져오세요. 포트, TUN, 시작 프로그램 설정도 다시 확인하고 프로그램 폴더 전체를 그대로 덮어쓰지 않는 것이 좋습니다. 새 클라이언트의 연결을 확인한 후 기존 클라이언트의 자동 실행과 백그라운드 서비스를 꺼서 프록시 두 개가 동시에 네트워크를 제어하지 않도록 하세요.

규칙 모드는 설정의 규칙 순서에 따라 연결 경로를 정하므로 일상적인 사용에 적합합니다. 전역 모드는 코어에 들어온 연결에 전역 정책을 적용해, 문제가 라우팅 규칙 때문인지 임시로 확인할 때 유용합니다. 직접 연결 모드는 코어에 들어온 연결을 바로 외부로 내보내므로 비교 테스트에 적합합니다. 전역 모드라고 해서 기기의 모든 트래픽을 제어하는 것은 아닙니다. 시스템 프록시나 TUN을 거치지 않는 앱은 여전히 코어를 우회할 수 있습니다. 문제를 확인할 때 규칙 모드와 전역 모드의 결과를 비교하고 연결 기록에서 적용된 규칙을 살펴보세요. 규칙 모드로 돌아온 뒤에는 대상 정책 그룹에서 사용 가능한 노드를 선택했는지도 확인해야 합니다.

시스템 프록시는 운영체제에 로컬 프록시 주소를 등록하며, 일반적으로 이 설정을 따르는 브라우저와 앱이 사용합니다. TUN은 가상 네트워크 어댑터와 라우팅을 통해 조건에 맞는 트래픽을 가져와 시스템 프록시를 사용하지 않는 일부 프로그램도 처리할 수 있습니다. 두 기능을 반드시 함께 켤 필요는 없으며, 적절한 조합은 클라이언트 구현과 앱의 요구 사항에 따라 달라집니다. 처음 설정할 때는 시스템 프록시로 구독과 노드를 확인한 뒤 필요에 따라 TUN을 켜세요. 전환 후 트래픽이 중복으로 처리되거나 연결 문제가 생기면 한 번에 하나의 진입 방식만 사용해 비교하고, 다른 VPN·가상 어댑터·보안 프로그램이 같은 라우팅을 변경하는지도 확인하세요.

클라이언트의 구독 또는 설정 화면에서 링크 가져오기를 선택하고 서비스 제공업체가 안내한 전체 주소를 붙여 넣으세요. 다운로드가 끝나면 해당 설정을 현재 설정으로 지정합니다. 구독 목록에 항목이 표시되는 것은 링크가 저장됐다는 뜻일 뿐, 코어에 설정이 로드됐다는 뜻은 아닙니다. 프록시 그룹에 노드가 있는지, 코어 로그에 파싱 오류가 있는지 확인한 다음 노드를 선택하고 필요한 프록시 진입 방식을 켜세요. 버튼 이름은 클라이언트마다 조금씩 다르므로 현재 화면을 기준으로 진행하면 됩니다. 구독 주소에는 보통 접근 인증 정보가 포함되므로 공개 스크린샷이나 질문 게시판에 올리거나 신뢰할 수 없는 온라인 변환 서비스에 입력하지 마세요.

먼저 업데이트 로그에서 HTTP 상태 코드와 오류 유형을 확인하세요. 401 또는 403은 인증, 링크 유효 기간, 서버의 접근 정책과 관련이 있을 수 있고, 404라면 주소가 바뀌었는지 확인해야 합니다. 시간 초과가 발생하면 먼저 기기에서 구독 서버에 접속할 수 있는지 확인하세요. 일부 클라이언트는 구독 업데이트를 직접 연결로 받을지 프록시로 받을지 선택할 수 있으므로, 사용할 수 있는 연결이 있다면 두 방식을 비교해 보세요. 다운로드는 됐지만 파싱할 수 없다면 로그인 페이지나 오류 메시지, 호환되지 않는 형식이 반환됐을 수 있습니다. 제공업체에 Clash 또는 mihomo에서 사용할 수 있는 구독인지 문의하세요. 사용 중인 설정은 백업으로 보관하고, 업데이트 실패 직후 기존 설정을 삭제하거나 짧은 간격으로 계속 새로 고치지 마세요.

먼저 현재 클라이언트와 운영체제가 해당 TUN 구현을 지원하는지 확인한 뒤, 클라이언트 안내에 따라 서비스 구성 요소를 설치하거나 필요한 권한을 부여하세요. Windows에서는 클라이언트가 제공하는 서비스 모드를 켜는 경우가 많습니다. macOS는 관리자 승인이나 관련 네트워크 구성 요소 허용이 필요할 수 있습니다. Android에서는 처음 켤 때 VPN 연결 요청을 승인해야 하는 경우가 많고, Linux에서는 서비스 권한과 가상 네트워크 어댑터 장치 사용 가능 여부에 따라 달라집니다. 권한을 부여한 뒤 코어를 다시 시작하고 로그를 확인하세요. 스위치만 반복해서 누르지 마세요. 다른 VPN이 이미 실행 중이면 충돌하는 연결을 먼저 중지하고, 관리 대상 기기에서는 관리자의 권한 정책을 따라야 합니다.

시작 시 앱 실행, 코어 시작, 시스템 프록시 활성화는 서로 다른 설정이므로 앱이 시작돼도 프록시 진입 방식이 자동으로 켜지지 않을 수 있습니다. 먼저 시스템의 시작 앱 관리에서 클라이언트 자동 실행이 비활성화되지 않았는지 확인한 다음, 현재 설정이 유지되는지와 프록시 그룹이 여전히 유효한 노드를 가리키는지 살펴보세요. 서비스 모드에 의존하는 TUN은 백그라운드 서비스가 정상적으로 시작됐는지도 확인해야 합니다. 로그인 직후에만 문제가 생긴다면 네트워크가 아직 준비되지 않았거나 다른 VPN이 나중에 라우팅을 변경했을 수 있습니다. 네트워크가 안정된 후 수동으로 다시 시도하고 로그를 비교하세요. 클라이언트를 바꾼 뒤에는 기존 프로그램의 자동 실행 작업을 정리해 이전 포트나 프록시 설정이 다시 적용되지 않도록 하세요.

select는 사용자가 구성원 하나를 직접 선택합니다. url-test는 설정된 테스트 주소와 측정 결과를 바탕으로 구성원을 선택하고, fallback은 보통 구성원 순서에 따라 사용 가능한 항목을 선택합니다. 자동 선택 결과는 테스트 대상, 간격, 허용 오차, 노드 상태에 따라 달라지며 모든 서비스의 접속 속도가 빨라진다는 뜻은 아닙니다. 그룹 안에서 다른 프록시 그룹을 참조할 수도 있으므로 문제를 확인할 때 참조 관계를 따라 최종 출구 노드를 확인하세요. 로그인이나 세션처럼 출구를 고정해야 하는 경우에는 정책 변경으로 출구가 바뀌지 않도록 수동 선택을 우선 고려하세요. 그룹 유형이나 구성원을 변경하기 전에 설정을 저장하고, 구독 업데이트가 직접 수정한 내용을 덮어쓰는지도 확인하세요.

지연 시간 테스트는 보통 지정된 주소에 요청을 한 번 보내는 데 걸리는 시간만 측정합니다. 연결 설정이나 TLS 협상 시간이 포함되는지는 구현에 따라 다르며, 이 값만으로 대역폭이나 지속적인 전송 속도, 대상 웹사이트의 응답 속도를 알 수는 없습니다. 노드에서 테스트 주소까지의 경로와 실제 서비스 사이트까지의 경로도 다를 수 있습니다. 먼저 브라우저 연결이 실제로 해당 노드를 사용하는지 확인한 뒤, 같은 대상과 네트워크에서 비슷한 시간대에 여러 노드를 비교하세요. 다운로드 속도는 서버 제한, 패킷 손실, 혼잡, 로컬 네트워크의 영향을 받을 수도 있습니다. 한 번의 측정만으로 노드를 제외하거나 시간 초과를 영구적인 노드 장애로 판단하지 말고, 연결 로그와 반복 테스트를 함께 확인하세요.

규칙은 일반적으로 위에서 아래 순서로 매칭됩니다. 앞쪽의 포괄적인 규칙이 적용되면 뒤쪽의 구체적인 규칙은 해당 연결을 처리하지 않습니다. 연결 기록에서 도메인, 대상 IP, 적용된 규칙, 최종 정책을 확인하고 앱이 IP에 직접 연결했거나 기존 연결을 재사용했을 가능성도 고려하세요. no-resolve는 GEOIP,CN,DIRECT,no-resolve처럼 해당 매개변수를 지원하는 IP 규칙에서 사용할 수 있습니다. 이 규칙을 매칭하기 위해 도메인을 별도로 조회하지 않도록 하는 옵션이지 DNS 전체를 끄는 기능은 아닙니다. 구체적인 도메인 규칙은 포괄적인 규칙보다 앞에 두고, MATCH 기본 규칙은 마지막에 배치하세요. 설정을 바꾼 뒤에는 새 연결을 만들어 결과를 확인해야 합니다.

AppContainer에서 실행되는 일부 Windows 앱은 기본적으로 로컬 루프백 주소에 접근하지 못해 127.0.0.1에서 수신 대기하는 프록시 포트에 연결할 수 없습니다. 다만 스토어 앱이 모두 이 제한을 받는 것은 아닙니다. 먼저 앱이 시스템 프록시를 따르는지, 코어 연결 기록에 해당 앱의 연결이 나타나는지 확인하세요. 루프백 제한이 원인이라면 클라이언트의 루프백 예외 기능을 사용해 필요한 앱에만 권한을 부여하고, 안내에 따라 관리자 권한으로 작업하세요. 모든 앱의 제한을 한꺼번에 해제하지 마세요. TUN으로 전환했다면 해당 앱의 트래픽이 라우팅에 포함되는지 다시 확인해야 합니다. 루프백 예외를 모든 연결 문제의 해결책으로 간주해서는 안 됩니다.

먼저 코어가 실행 중인지 확인한 다음 시스템 프록시의 주소와 포트가 클라이언트의 수신 대기 설정과 일치하는지 비교하세요. 다른 프록시 도구, 브라우저 확장 프로그램, 기업 네트워크 정책이 시스템 설정을 덮어쓸 수 있으며 브라우저 자체에 별도의 프록시 설정이 있을 수도 있습니다. 대상 페이지를 열고 클라이언트 연결 기록을 확인하세요. 기록이 전혀 없다면 트래픽 진입 방식, 프록시 우회 목록, 포트 사용 여부부터 살펴보세요. 기록은 있지만 DIRECT로 연결된다면 시스템 프록시 스위치를 계속 바꾸기보다 송신 모드와 적용된 규칙을 확인해야 합니다. 브라우저를 다시 시작해 기존 연결을 끊은 뒤 충돌하는 설정을 하나씩 비활성화하세요. 시스템 프록시를 제어하는 클라이언트를 여러 개 동시에 실행하지 마세요.

모든 노드가 시간 초과되면 먼저 기기의 인터넷 연결, 시스템 시간, 구독 인증 상태를 확인한 다음 방화벽이 클라이언트를 차단하는지와 테스트 대상에 접근할 수 있는지 살펴보세요. 노드 하나만 실패한다면 다른 노드와 비교하고 해당 노드의 서버 상태, 주소, 포트, 프로토콜 지원 여부를 중점적으로 확인하세요. QUIC을 사용하는 프로토콜이라면 현재 네트워크에서 필요한 UDP 통신을 허용하는지도 확인해야 합니다. 테스트 주소 자체에 문제가 있어 여러 노드가 모두 실패할 수도 있으므로 실제 접속 여부와 로그의 연결 단계를 함께 살펴보세요. 처음부터 클라이언트를 재설치하지 말고 이름 확인 실패, 연결 거부, 연결 대기 시간 초과를 구분해야 원인을 좁힐 수 있습니다.

먼저 로그에서 도메인 확인 실패, 상위 DNS 시간 초과, 연결 대상 오류를 찾은 다음 요청이 코어에 들어왔는지와 DNS 조회를 시스템과 클라이언트 중 어디서 처리하는지 확인하세요. 노드만 바꿨는데 문제가 해결됐다면 노드에서 대상까지의 경로와 관련이 있을 수 있습니다. 여러 노드로 바꿔도 조회 단계에서 실패한다면 상위 DNS 주소, 접속 경로, 설정 호환성을 확인하세요. fake-ip를 사용할 때 일부 로컬 네트워크 서비스나 앱은 문서에 따라 필터 규칙을 설정해야 할 수 있습니다. DNS 가로채기 설정을 여러 개 겹쳐 사용하거나 도메인 대신 IP로만 장기간 테스트하지 마세요. HTTPS 인증서나 가상 호스트 때문에 새로운 오류가 생길 수 있습니다.

먼저 시스템이 여전히 클라이언트의 로컬 프록시 포트를 가리키는지 확인하세요. 프로그램이 비정상적으로 종료되면 수신 대기는 중단됐지만 시스템 프록시 설정은 남아 있을 수 있습니다. 클라이언트를 다시 열어 시스템 프록시와 TUN을 끈 뒤 정상적으로 종료하거나, 시스템 네트워크 설정에서 더 이상 사용하지 않는 수동 프록시를 끄세요. 그래도 문제가 계속되면 백그라운드 서비스, VPN 연결, 다른 도구가 DNS를 제어하는지 확인하세요. 수동 DNS를 사용하는 기기는 이전에 기록한 설정으로 되돌리세요. 정체를 모르는 가상 네트워크 어댑터나 라우팅을 바로 삭제하지 마세요. 복구한 뒤 네트워크에 다시 연결해 일반 웹사이트를 테스트하고, 기본적인 복구 방법으로 해결되지 않을 때만 시스템 안내에 따라 네트워크 초기화를 고려하세요.