Clash 자주 묻는 질문

클라이언트는 설정 가져오기, 노드 선택, 시스템 프록시 같은 기능을 제공하는 인터페이스입니다. mihomo 같은 코어는 연결 처리, 규칙 적용, DNS 해석을 담당하며, 구독은 서비스 제공자가 노드나 전체 설정을 제공하는 방식입니다. 클라이언트를 설치했다고 바로 사용할 수 있는 노드가 생기는 것은 아닙니다. 문제를 해결할 때는 먼저 어느 단계에서 발생했는지 구분하세요. 화면이 실행되지 않으면 클라이언트와 시스템을 확인하고, 설정을 불러오지 못하면 구독 형식을 확인하세요. 설정은 정상인데 연결이 안 되면 노드, 프록시 그룹, 네트워크를 점검하면 됩니다. 코어마다 지원하는 프로토콜과 설정 항목이 다를 수 있으므로 파일 확장자만으로 호환 여부를 판단할 수는 없습니다.

일상적인 사용에는 규칙 모드를 권장합니다. 설정에 지정된 규칙 순서에 따라 연결이 해당 프록시 그룹으로 전달됩니다. 전역 모드는 일반적으로 코어에 들어온 연결을 전역 정책으로 처리하지만, 모든 앱의 트래픽을 가로채는 것은 아닙니다. 직접 연결 모드에서는 코어에 들어온 연결이 프록시를 거치지 않고 나갑니다. 특정 웹사이트에 문제가 있으면 잠시 전역 모드로 바꾸고 정상 작동을 확인한 노드를 선택해 분기 규칙이 원인인지 확인한 뒤, 테스트가 끝나면 규칙 모드로 되돌리세요. 모드 변경은 시스템 프록시나 TUN을 대신하지 않으며, 만료된 구독이나 사용할 수 없는 노드, 서버 측 제한을 해결해 주지도 않습니다.

시스템 프록시는 운영체제에 프록시 주소를 등록하는 방식으로, 해당 설정을 따르는 브라우저와 앱에서 주로 작동합니다. 자체 연결을 사용하거나 시스템 프록시를 무시하는 프로그램에는 적용되지 않을 수 있습니다. TUN은 가상 네트워크 인터페이스와 라우팅을 이용해 트래픽을 처리합니다. 적용 범위는 클라이언트, 플랫폼 권한, 라우팅 설정에 따라 달라지며 DNS 처리도 관련될 수 있습니다. 먼저 시스템 프록시로 기본 연결을 확인하고, 특정 앱의 트래픽이 처리되지 않을 때 TUN을 고려하세요. 사용 전에 다른 VPN을 끄고 기존 네트워크 설정을 기록해 두세요. 인터넷 연결이 끊기면 먼저 TUN을 끄고 일반 네트워크가 복구되는지 확인한 뒤 설정을 하나씩 조정하세요.

구독 링크가 열리는지만 확인해서는 안 됩니다. 구독 내용의 형식이 현재 코어와 맞는지도 확인해야 합니다. 전체 Clash YAML 설정, 노드만 포함된 목록, 다른 클라이언트용 구독 형식은 서로 다릅니다. 먼저 서비스 제공자 페이지에서 Clash 또는 mihomo용 구독 링크를 선택한 다음 클라이언트의 원격 설정 기능으로 가져오세요. 지원하지 않는 프로토콜이나 알 수 없는 항목이 표시되면 코어의 요구 사항을 확인하고 설정을 임의로 삭제하지 마세요. 구독 주소에는 접근 자격 정보가 포함되는 경우가 많으므로 출처가 불분명한 변환 사이트에 입력하거나 공개된 문의 글에 그대로 붙여 넣지 마세요.

먼저 계정 서비스가 유효한지 확인한 뒤, 제공자 페이지에서 구독 주소 전체를 다시 복사하세요. 매개변수가 빠지거나 공백이 들어가지 않도록 주의해야 합니다. 업데이트 로그도 확인하세요. 401 또는 403은 인증 만료나 접근 제한, 404는 주소 변경과 관련이 있을 수 있고, 시간 초과가 발생하면 로컬 네트워크와 업데이트 요청의 연결 경로를 점검해야 합니다. 정확한 의미는 제공자의 안내를 확인하세요. 현재 사용할 수 있는 설정은 보관하고, 전체 데이터를 지우지 말고 업데이트만 따로 테스트하세요. 로그인 페이지나 오류 페이지가 반환되면 올바른 구독 링크를 다시 확인하세요. 계속 실패하면 상태 코드와 발생 시각을 제공자에게 전달하되, 주소에 포함된 인증 정보는 가리세요.

가져오기에 성공했다는 것은 클라이언트가 설정을 저장했다는 뜻일 뿐, 설정이 활성화되었다는 의미는 아닙니다. 설정 목록에서 대상 설정을 선택하고 코어에 로드 오류가 없는지 확인한 다음 프록시 화면에서 프록시 그룹을 확인하세요. proxy-providers를 사용한다면 해당 제공자가 노드를 정상적으로 가져왔는지, 프록시 그룹에서 use로 해당 제공자를 참조하는지도 확인해야 합니다. 일부 인터페이스에서는 프록시 그룹을 펼쳐야 노드가 표시되며, 전체 서버 목록을 별도로 보여 주지 않을 수 있습니다. 노드만 있는 파일을 전체 설정처럼 덮어쓰지 마세요. 업데이트 후에도 목록이 비어 있다면 로그에서 설정 항목 오류, 제공자 요청 실패, 구독 서비스 상태를 확인하세요.

먼저 클라이언트 안내에 따라 서비스 모드를 설치하거나 복구한 다음 TUN을 다시 켜세요. 화면의 스위치만 켠다고 가상 네트워크 인터페이스가 생성되거나 라우팅이 변경되는 것은 아닙니다. Windows에서는 일반적으로 관리자 권한으로 서비스를 설치해야 하며, macOS에서는 보조 도구나 네트워크 확장 권한이 필요할 수 있습니다. Android에서는 시스템 VPN 연결 요청을 승인해야 합니다. 세부 절차는 클라이언트에 따라 다릅니다. 현재 설치된 클라이언트에서 요청한 권한인지 확인하고, 출처를 알 수 없는 권한 상승 명령은 실행하지 마세요. 서비스 설치에 실패하면 시스템 보안 알림과 클라이언트 로그를 확인하고, 다른 VPN이 관련 기능을 사용 중인지 점검하세요. 조치 후 클라이언트를 다시 시작해 확인하세요.

가능합니다. 다만 먼저 포트를 사용 중인 프로그램이 다른 프록시 클라이언트인지 확인하세요. 중복 실행 중인 인스턴스를 종료한 뒤 다시 시도하는 편이 설정을 일관되게 유지하기 쉽습니다. 포트를 바꿔야 한다면 현재 적용 중인 설정이나 클라이언트의 포트 설정에서 사용 중이지 않은 포트를 선택하고 저장한 다음 다시 불러오세요. 7890은 흔히 쓰이는 값일 뿐 필수 포트는 아닙니다. 이후 시스템 프록시, 브라우저 확장 프로그램, 터미널 환경 변수, 프록시를 수동 설정한 앱이 새 포트를 사용하도록 변경하세요. 로컬에서 접속하려고 LAN 연결 허용을 켜거나 프록시 수신 주소를 인터넷에서 접근할 수 있도록 변경하지 마세요.

지연 시간 테스트는 보통 특정 테스트 주소의 응답 시간을 측정하며, 다운로드 대역폭이나 동영상 재생 성능, 모든 웹사이트의 접속 속도를 의미하지는 않습니다. 같은 네트워크에서 비슷한 시간대에 동일한 웹사이트를 대상으로 노드를 비교하고, 백그라운드 다운로드가 결과에 영향을 주지 않는지 확인하세요. 연결 로그에서 선택한 프록시 그룹을 실제로 통과했는지도 확인해야 합니다. 특정 웹사이트만 느리다면 출구 경로, 대상 서비스의 제한, DNS 결과가 원인일 수 있습니다. 모든 노드가 느리다면 먼저 로컬 네트워크를 점검하세요. 여러 노드를 자주 동시에 테스트하면 서버 측 제한이 발생할 수 있으므로 적은 수만 시험하고 실제 접속 결과와 함께 판단하세요. 지연 시간 숫자 하나만으로 노드를 평가해서는 안 됩니다.

먼저 해당 연결에 실제로 적용된 프록시 그룹을 수정했는지 확인하세요. 설정에서 동영상, 다운로드, 일반 웹 트래픽을 서로 다른 그룹으로 나눴다면 기본 선택 그룹을 바꿔도 다른 그룹에는 영향을 주지 않을 수 있습니다. 자동 테스트 그룹도 자체 기준에 따라 노드를 선택할 수 있습니다. 연결 패널에서 대상 도메인으로 새 요청을 찾아 적용된 규칙, 프록시 그룹 경로, 최종 출구를 확인하세요. 기존 장시간 연결은 이전 출구를 계속 사용할 수 있으므로 노드를 바꾼 뒤 새 요청을 보내고, 필요한 경우 해당 연결만 끊으세요. 클라이언트에서 로컬 덮어쓰기를 지원한다면 직접 설정을 수정하기보다 덮어쓰기 기능으로 규칙이나 그룹 참조를 변경하세요. 구독 업데이트로 직접 수정한 내용이 덮어써지는 일을 방지할 수 있습니다.

다운로드한 구독 파일을 직접 수정하기보다 클라이언트의 규칙 덮어쓰기, 확장 설정, 영구 병합 기능을 사용하세요. 예를 들어 example.com과 하위 도메인을 직접 연결하려면 DOMAIN-SUFFIX,example.com,DIRECT를 추가하고, 해당 트래픽과 먼저 일치할 수 있는 포괄적인 규칙보다 앞에 배치하세요. Clash 규칙은 일반적으로 위에서 아래로 확인하며, 처음 일치하는 규칙의 정책을 적용합니다. 수정 전에 백업하고 저장 후 설정 로드 로그를 확인한 다음 연결 패널에서 결과를 검증하세요. 대상 콘텐츠가 여러 도메인에서 제공된다면 실제 연결을 확인해 규칙을 추가하세요. 편의를 위해 관계없는 도메인까지 대량으로 직접 연결하도록 설정하지 마세요.

최소한 현재 활성화된 설정, 수동으로 선택한 프록시 그룹, 포트, 시스템 프록시 및 TUN 상태를 기록하고 로컬 규칙 덮어쓰기와 DNS 변경 사항을 백업하세요. 구독을 업데이트하기 전에 원격 설정 내용이 교체되는지 확인하세요. 클라이언트를 업그레이드하기 전에는 마이그레이션 안내를 읽고 코어, 서비스 모드, 설정 폴더가 변경되는지 특히 주의하세요. 한 번에 핵심 설정 하나만 변경하고, 완료 후 자주 사용하는 웹사이트와 앱을 확인하세요. 그래야 문제가 생겼을 때 원인을 찾기 쉽습니다. 백업에는 구독 인증 정보나 노드 인증 정보가 포함될 수 있으니 안전한 곳에 보관하세요. 설정 폴더 전체를 압축해 공개 포럼에 올리지 말고, 문의할 때는 필요한 부분만 민감 정보를 가려서 공유하세요.

먼저 현재 설정이 활성화되어 있고 노드를 사용할 수 있는지 확인한 다음, 운영체제에 등록된 프록시 주소와 클라이언트의 수신 주소 및 포트가 일치하는지 확인하세요. 일반 브라우저에서 새 요청을 보내고 연결 패널에 기록이 나타나는지 살펴보세요. 기록은 있지만 직접 연결된다면 모드와 규칙을 확인하고, 기록이 없다면 앱이 시스템 프록시를 무시하거나 별도의 프록시 설정을 사용하거나 다른 도구가 설정을 덮어썼는지 확인하세요. 브라우저 프록시 확장 프로그램, 기업 정책, 다른 프록시 클라이언트도 결과에 영향을 줄 수 있습니다. 터미널 프로그램은 시스템 프록시를 따르지 않을 수 있으므로 프로그램 안내에 따라 환경 변수를 설정하세요. 더 넓은 범위의 트래픽을 처리해야 한다면 TUN 사용을 검토하세요.

먼저 프록시를 끄고 기본 네트워크가 정상인지 확인하세요. 구독이 만료되지 않았는지, 시스템 시간이 올바른지 확인한 다음 정상 작동이 확인된 다른 노드나 테스트 대상으로 비교해 보세요. 시간 초과는 도메인 해석, 서버 연결, 대상 웹사이트 접속 단계에서 발생할 수 있으므로 로그에 표시된 주소를 함께 살펴보세요. 연결 거부는 해당 포트에서 서비스가 실행 중이지 않을 때 흔히 발생하지만 원격 서버에서 거부했을 수도 있으므로 노드가 만료됐다고 단정할 수는 없습니다. 한 경로만 실패하면 서비스 제공자에게 문의하세요. 모두 실패하면 로컬 방화벽, 다른 VPN, 네트워크 제한을 확인하세요. DNS, 규칙, TUN을 한꺼번에 변경하면 어느 조치가 효과가 있었는지 알기 어렵습니다.

AppContainer로 격리된 일부 Windows 앱은 로컬 루프백 주소에 직접 접근하지 못할 수 있습니다. 브라우저는 정상인데 이런 앱만 실패한다면 루프백 제한을 확인해 보세요. 클라이언트에서 UWP 루프백 도구를 제공한다면 안내에 따라 관리자 권한으로 실행하고, 로컬 프록시에 접근해야 하는 앱에만 예외를 추가한 뒤 앱을 다시 시작하세요. 모든 스토어 앱에 같은 방식이 적용되는 것은 아니며, 모든 연결 문제가 루프백 때문인 것도 아닙니다. 먼저 앱이 어떤 프록시 경로를 사용하는지와 구체적인 오류 상황을 확인하세요. TUN이 대체 트래픽 처리 방식이 될 수도 있지만 라우팅 결과를 검증해야 하며, 모든 문제를 해결하는 만능 기능으로 여겨서는 안 됩니다.

먼저 TUN과 시스템 프록시를 끄고 다른 VPN도 종료한 다음 일반 네트워크가 복구되는지 확인하세요. 클라이언트를 종료한 뒤에도 시스템 프록시가 로컬 포트를 가리킨다면 시스템 네트워크 설정에서 프록시를 먼저 끄세요. 클라이언트를 다시 실행할 때는 트래픽 처리 방식을 하나만 켜고, DNS 요청 시간 초과, 라우팅 충돌, 가상 인터페이스 생성 실패가 로그에 있는지 확인하세요. DNS 설정을 통째로 따라 하지 말고 현재 코어와 네트워크 환경에 맞춰 항목별로 복구하세요. 관련 기능을 끈 뒤에도 문제가 계속되면 네트워크를 다시 연결하거나 시스템을 재시작해 임시 상태를 정리할 수 있습니다. 회사 장비의 라우팅 및 보안 설정은 관리자에게 확인하세요.