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

Clash는 규칙에 따라 트래픽을 분기하는 프록시 도구를 가리키는 말로 흔히 쓰입니다. mihomo는 관련 생태계에서 계속 발전 중인 코어로, 설정을 해석하고 규칙을 적용해 연결을 수립합니다. 클라이언트는 인터페이스와 구독 관리, 시스템 연동 기능을 제공합니다. 같은 이름의 설정 항목이라도 실제 지원 여부는 사용 중인 코어와 버전에 따라 다릅니다. 문제를 살펴보기 전에 정보 또는 코어 정보 화면에서 클라이언트 이름과 코어 버전을 확인하세요. 다른 클라이언트의 화면 안내를 그대로 따라 해서는 안 됩니다.

클라이언트는 설정을 실행하는 프로그램이며, 사용할 수 있는 원격 프록시 서비스를 자동으로 제공하지는 않습니다. 구독으로 노드와 프록시 그룹, 규칙을 가져올 수 있고, 로컬 YAML 파일로 직접 설정할 수도 있습니다. 가져온 뒤에는 해당 설정을 활성화하고 프록시 그룹에서 사용할 출구를 선택해야 합니다. 규칙과 비어 있는 프록시 그룹만으로는 원격 프록시 연결을 만들 수 없습니다. 구독 출처와 만료일, 서비스 이용량은 제공업체에 확인하세요. 설치가 완료됐다고 서비스까지 사용할 수 있는 것은 아닙니다.

일반적으로는 mode: rule을 사용해 rules를 위에서 아래 순서로 적용합니다. 전역 모드는 코어에 들어온 연결을 전역 정책으로 보내고, 직접 연결 모드는 해당 연결을 프록시 없이 내보냅니다. 이 모드들은 트래픽을 가져오는 방식과는 별개입니다. 앱이 시스템 프록시나 명시적 프록시, TUN을 사용하지 않으면 모드를 바꿔도 영향을 받지 않을 수 있습니다. 문제를 확인할 때는 먼저 로그에 해당 앱의 연결이 나타나는지 살펴본 뒤 규칙 모드와 전역 모드의 결과를 비교하세요.

시스템 프록시는 시스템 설정을 따르는 앱에 프록시 주소를 제공하지만, 이를 무시하는 앱도 있습니다. TUN은 가상 네트워크 인터페이스와 라우팅을 이용해 트래픽을 가져오며 DNS, 권한, 경로 제외 설정도 관련됩니다. 처음 설정할 때는 시스템 프록시로 구독과 노드가 작동하는지 확인한 다음, 앱의 필요에 따라 TUN을 켜는 편이 좋습니다. 처음부터 모든 트래픽 처리 방식을 동시에 활성화할 필요는 없습니다. TUN이 특정 트래픽을 처리할 수 있는지는 플랫폼 제한과 설정에 따라 달라지므로, 스위치가 켜졌다는 이유만으로 트래픽이 제대로 전달된다고 판단해서는 안 됩니다.

Profile은 일반적으로 클라이언트에 저장된 설정 항목을 뜻하며, 원격 구독이나 로컬 YAML에서 가져올 수 있습니다. 구독을 새로 고치면 제공업체의 내용을 다시 가져오고, 오버라이드는 설정을 불러올 때 로컬 필드나 규칙, 프록시 그룹 변경 사항을 추가합니다. 클라이언트마다 설정을 병합하는 순서는 다릅니다. 구독으로 생성된 파일을 직접 수정하면 업데이트 후 변경 사항이 사라질 수 있습니다. 계속 사용할 설정을 바꾸기 전에는 백업하고, 클라이언트의 오버라이드 안내를 확인한 뒤 편집기의 원본이 아니라 최종 적용된 설정을 점검하세요.

설정 또는 구독 화면에서 가져오기가 완료됐는지 확인하고, 해당 설정을 현재 사용 항목으로 지정하세요. 다음으로 업데이트 결과를 확인합니다. 웹페이지나 로그인 안내, 오류 메시지가 반환됐다면 사용할 수 있는 설정이 아닙니다. 구독이 아직 유효한지, 내용이 현재 코어와 호환되는지도 살펴보세요. 파싱은 성공했는데 노드가 보이지 않는다면 proxy-groups가 proxies 또는 proxy-providers를 참조하는지 확인하세요. 구독 주소 전체를 공개하지 말고, 스크린샷을 공유할 때도 쿼리 매개변수에 포함된 인증 정보를 가리세요.

로그에 표시된 줄 번호 주변에서 들여쓰기와 콜론, 목록의 하이픈을 확인하세요. 특히 최근에 수정한 부분을 살펴보는 것이 좋습니다. YAML 들여쓰기에는 공백을 사용하고 탭은 넣지 마세요. 같은 단계의 필드는 줄을 맞추고, 특수 문자가 포함된 문자열은 필요에 따라 따옴표로 감싸세요. 오류가 발생한 줄보다 다음 줄을 가리키는 경우도 있으므로 앞부분도 확인해야 합니다. 마지막으로 정상 작동했던 설정을 복원한 뒤 한 번에 한 항목씩 수정하세요. 설정이 파싱된다고 해서 모든 참조가 유효한 것은 아니므로 프록시 그룹 이름과 규칙 대상이 실제로 존재하는지도 확인하세요.

먼저 TUN을 끄고 일반 프록시 연결이 정상인지 확인한 다음, 클라이언트 안내에 따라 서비스 구성 요소를 설치하거나 복구하세요. Windows에서는 서비스 상태와 관리자 권한을, macOS에서는 안내에 따라 필요한 네트워크 권한을 확인합니다. Linux에서는 클라이언트가 지원하는 권한 상승 방식과 /dev/net/tun을 사용할 수 있는지 확인하세요. 필요한 권한은 클라이언트마다 다르므로 시스템 권한을 모두 허용하지 마세요. 그래도 실패하면 다른 VPN이나 가상 네트워크 어댑터 도구를 끈 뒤 다시 시도하고, 인터페이스 생성 실패가 기록된 원본 로그를 확인하세요.

시작 시 클라이언트 실행, 코어 실행, 프록시를 통한 트래픽 처리를 각각 확인하세요. 일부 클라이언트는 사용자가 로그인한 뒤에만 화면을 띄우며, 서비스 구성 요소나 시스템 프록시, TUN은 함께 활성화되지 않을 수 있습니다. 재부팅 후 클라이언트 프로세스가 실행 중인지, 현재 설정이 로드됐는지, 선택한 정책을 계속 사용할 수 있는지 확인한 다음 시스템 시작 항목 권한을 점검하세요. 부팅 시 네트워크가 아직 준비되지 않아 구독을 가져오지 못했을 가능성도 있습니다. 시작 항목을 계속 추가해 해결하려고 하지 마세요. 여러 인스턴스가 실행되면 같은 수신 포트를 두고 충돌할 수 있습니다.

먼저 시스템 정보 화면에서 프로세서 아키텍처를 확인한 다음 다운로드 항목을 선택하세요. Windows는 주로 x64와 ARM64, macOS는 Apple Silicon과 Intel로 구분합니다. Android는 arm64-v8a와 armeabi-v7a가 흔하며, Linux는 배포판에서 사용하는 패키지 형식도 확인해야 합니다. 아키텍처가 맞지 않으면 설치나 실행이 안 되거나 호환 계층이 필요할 수 있습니다. 기기 브랜드만 보고 아키텍처를 짐작하지 마세요. 업데이트 전에 설정을 백업하고, 클라이언트 설치 패키지와 별도로 배포되는 mihomo 코어 파일을 혼용하지 마세요.

현재 모드가 mode: rule인지, 실제 사용 중인 설정을 수정했는지 확인하세요. rules는 위에서부터 차례로 적용되므로 범위가 넓은 규칙이나 MATCH를 앞에 두면 뒤에 있는 규칙이 적용되지 않을 수 있습니다. 규칙 대상이 프록시 그룹 이름과 정확히 일치하는지 확인한 뒤 연결 로그에서 실제 도메인과 대상 주소, 적용된 규칙을 살펴보세요. 구독 업데이트 후 사라지는 변경 사항은 클라이언트가 지원하는 오버라이드 위치로 옮기세요. 로드되지 않는 로컬 백업 파일에만 규칙을 써 두어서는 안 됩니다.

select는 출구를 직접 선택하는 방식으로, 특정 지역을 고정하거나 출구를 계속 동일하게 유지해야 할 때 적합합니다. url-test는 지정한 테스트 주소의 결과에 따라 출구를 자동 선택하지만, 테스트 주소에 연결된다고 모든 서비스가 정상이라는 뜻은 아닙니다. fallback은 보통 후보 순서에 따라 사용 가능한 출구를 선택하므로 우선순위가 정해진 백업 구성에 알맞습니다. 먼저 후보 목록의 노드가 사용 가능한지 확인하고, 필요에 따라 url, interval, tolerance 등의 필드를 조정하세요. 어떤 그룹 유형을 사용해도 노드 자체의 대역폭이 늘어나지는 않습니다.

전체 Profile 업데이트와 proxy-providers 업데이트를 구분해야 합니다. 전자는 보통 클라이언트의 구독 설정에서 관리하며 단위는 화면에 표시된 값을 따릅니다. 후자는 설정의 interval로 제어하고, mihomo에서는 초 단위를 사용합니다. health-check.interval은 상태 확인 간격이지 구독을 다시 다운로드하는 간격이 아닙니다. 제공업체의 제한에 맞춰 업데이트 빈도를 정하세요. 실패했다면 먼저 수동으로 새로 고치고 오류를 확인하세요. 지나치게 짧은 간격으로 반복 요청하면 서버에서 요청을 제한할 수 있습니다.

원본 형식을 현재 클라이언트에서 지원하지 않고 제공업체에서도 적절한 구독 형식을 제공하지 않을 때만 변환을 고려하세요. 먼저 제공업체의 호환 링크를 사용하거나 신뢰할 수 있는 도구를 로컬에서 실행하는 방법을 선택하세요. 온라인 변환 서비스에 링크를 제출하면 해당 서비스가 구독에 접근할 수 있게 됩니다. 변환으로 구독 만료나 이용량 초과, 서버 장애를 해결할 수는 없습니다. 변환한 뒤 노드 유형과 프록시 그룹, 규칙이 유지됐는지 확인하세요. 링크가 실수로 공개됐다면 제공업체에서 구독 주소를 재발급받으세요.

클라이언트의 연결 목록이나 로그를 열고 필터를 지운 다음, 대상 앱에서 새 요청을 보내세요. 해당 도메인과 프로세스, 적용된 규칙, 최종 출구를 확인합니다. 기존 장기 연결은 이전 정책을 계속 사용할 수 있으므로 필요하면 대상 앱을 완전히 종료한 뒤 다시 시도하세요. 웹페이지가 열린다는 사실은 해당 요청이 성공했다는 뜻일 뿐 모든 앱의 트래픽이 처리된다는 뜻은 아닙니다. 출구 확인 페이지 하나로는 그 페이지에 접속한 연결만 확인할 수 있습니다. 경로를 확인한 뒤에는 불필요한 접속 기록이 장기간 남지 않도록 상세 로그를 끄세요.

노드 테스트 결과만 보지 말고 먼저 구독 업데이트 로그를 확인하세요. HTTP 401 또는 403은 대개 접근 권한과 관련이 있고, 404는 주소 변경, 429는 요청 과다를 의미할 수 있습니다. 정확한 원인은 제공업체의 안내도 함께 확인해야 합니다. 시간 초과가 발생하면 구독 도메인이 DNS에서 해석되는지, 현재 네트워크와 업데이트 요청 경로가 정상인지 확인하세요. 파싱 오류가 발생했다면 반환된 내용이 웹페이지인지, 호환되지 않는 형식인지 점검하세요. 인증서 오류는 우선 시스템 시간을 확인하고, 문제를 감추기 위해 인증서 검증을 끄지 마세요.

구독 서버와 프록시 노드는 서로 다른 연결 대상입니다. 구독 업데이트에 성공해도 노드를 사용할 수 있다는 뜻은 아닙니다. 먼저 다른 노드와 테스트 주소를 바꿔 가며 비교한 다음, 서비스 이용량과 노드 매개변수, 시스템 시간을 확인하세요. 특정 노드만 실패하면 발생 시간과 오류 내용을 제공업체에 전달하세요. 모든 노드가 실패한다면 로컬 방화벽과 다른 VPN, 현재 네트워크의 제한을 점검하세요. 테스트 주소 자체에 연결되지 않아도 시간 초과가 발생할 수 있으므로 실제 서비스 연결 결과와 함께 판단하세요. 한 번의 테스트 결과만으로 설정 전체를 삭제하지 마세요.

먼저 코어가 실행 중인지, 시스템 프록시 주소와 포트가 mixed-port 또는 실제 HTTP 수신 포트와 일치하는지 확인하세요. 브라우저에 별도 프록시 설정이나 확장 프로그램, 기업 정책이 적용됐는지도 확인하고 프록시 우회 목록에 대상 주소가 포함됐는지 살펴보세요. 브라우저를 완전히 종료한 뒤 다시 열어 연결 로그를 확인합니다. 로그에 요청이 없다면 트래픽 처리 경로에 문제가 있을 가능성이 큽니다. 요청이 보인다면 적용된 규칙과 출구를 추가로 확인하세요. 로컬 연결을 위해 allow-lan을 무작정 활성화하지 마세요.

AppContainer 격리를 사용하는 일부 Windows 앱은 기본적으로 로컬 루프백 주소에 접근할 수 없어 127.0.0.1에서 수신 대기하는 프록시에 연결하지 못할 수 있습니다. 먼저 해당 앱이 실제로 로컬 프록시를 사용하는지 확인한 뒤, 클라이언트에서 제공하는 루프백 예외 도구로 필요한 앱만 허용하세요. 도구를 사용하려면 관리자 권한이 필요할 수 있습니다. 모든 Windows 앱에 이 제한이 적용되는 것은 아니므로 프로그램을 일괄적으로 허용하지 마세요. 허용한 뒤에도 실패한다면 같은 예외를 반복해서 추가하는 대신 앱 자체의 프록시 동작과 DNS, 방화벽을 점검하세요.

먼저 TUN을 끄고 기본 네트워크가 복구되는지 확인한 다음, 로그에서 DNS 시간 초과와 라우팅 충돌, 인터페이스 오류를 살펴보세요. 설정에서 auto-route를 사용한다면 다른 VPN과 컨테이너 네트워크, LAN 라우트가 충돌하지 않는지 확인하세요. dns-hijack을 사용한다면 DNS 서비스가 실행 중인지, 상위 DNS 서버에 연결할 수 있는지 확인합니다. LAN 기기에 문제가 생겼다면 라우트 제외 설정과 규칙을 함께 점검해야 합니다. DIRECT만 추가해도 트래픽 처리 단계의 충돌이 해결되는 것은 아닙니다. 한 번에 하나씩 변경하고 언제든 복구할 수 있도록 원래 설정을 보관하세요.