Clash 자주 묻는 질문

Clash는 일반적으로 프록시 코어와 그 설정 생태계를 가리킵니다. Mihomo는 이 생태계에서 계속 개발 중인 코어로, 초기에는 Clash Meta라는 이름으로 알려졌습니다. Clash Verge Rev, Clash Meta for Android 같은 그래픽 클라이언트는 구독 관리, 정책 선택, 시스템 연결을 담당합니다. 실제로 지원되는 프로토콜과 설정 항목은 사용하는 코어에 따라 달라집니다. 튜토리얼을 참고할 때는 먼저 클라이언트의 정보 또는 코어 설정에서 코어 이름을 확인하고 해당 문서를 찾아보세요. 화면에 Clash라는 이름이 표시된다는 이유만으로 서로 다른 클라이언트의 설정을 모두 호환해 사용할 수 있다고 단정해서는 안 됩니다.

클라이언트는 주로 설정을 읽고 트래픽을 전달합니다. 설치를 마쳤다고 바로 사용할 수 있는 프록시 출구가 생기는 것은 아닙니다. 구독은 보통 이용 중인 서비스 제공업체에서 제공하며, 노드, 정책 그룹, 규칙, DNS 설정 등이 포함될 수 있습니다. 단일 노드 링크에는 대개 하나의 연결 정보만 들어 있습니다. 먼저 현재 코어와 호환되는 설정 구독인지 확인한 다음 가져와 현재 설정으로 선택하세요. 구독 주소에는 계정 인증 정보가 포함될 수 있으므로 공개 게시판이나 스크린샷, 출처가 불분명한 온라인 변환 페이지에 올리지 마세요. 문제를 문의할 때는 민감한 정보를 가린 오류 내용만 공유하세요.

규칙 모드는 설정에 정의된 규칙에 따라 트래픽을 보낼 정책을 결정하므로, 도메인·주소·앱별로 평소 트래픽을 나눠 처리할 때 적합합니다. 전역 모드는 코어에 들어온 연결을 전역 정책으로 보내지만, 사용할 수 있는 출구를 선택해야 합니다. 클라이언트에 들어오지 않은 앱 트래픽까지 자동으로 처리하지는 않습니다. 직접 연결 모드는 일반적으로 코어에 들어온 연결을 프록시 없이 바로 접속시킵니다. 특정 웹사이트 문제를 확인할 때는 잠시 전역 모드로 전환하고 사용 가능한 노드를 선택해 규칙 모드와 결과를 비교해 보세요. 확인이 끝나면 원래 모드로 되돌려 임시 설정이 계속 남지 않도록 하세요.

반드시 그럴 필요는 없습니다. 시스템 프록시는 운영체제 설정에 로컬 프록시 주소를 등록하며, 주로 해당 설정을 따르는 앱에서 사용합니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 연결하며, 적용 범위는 플랫폼, 권한, 라우팅 설정에 따라 달라집니다. 브라우저가 정상적으로 작동한다면 우선 시스템 프록시를 유지하고, 기능을 더 켜기 위해 TUN까지 추가할 필요는 없습니다. 시스템 프록시를 따르지 않는 앱이 있다면 클라이언트 문서에 따라 TUN을 켜고 DNS 설정을 확인하세요. 일부 클라이언트에서는 두 기능을 함께 사용할 수 있지만, 그렇다고 모든 트래픽이 처리되는 것은 아닙니다. 다른 VPN의 라우팅과 충돌하지 않도록 주의하세요.

클라이언트에서 설정, 구독 또는 Profiles 페이지를 열고 링크로 가져오기를 선택한 다음 전체 주소를 붙여 넣어 저장하세요. 다운로드가 끝나면 해당 설정을 현재 사용 항목으로 지정하고, 프록시 또는 정책 그룹 페이지에서 출구를 선택합니다. YAML 파싱 오류가 발생하면 링크가 로그인 페이지나 일반 웹페이지, 다른 형식의 구독이 아니라 Clash 호환 설정을 반환하는지 먼저 확인하세요. 마지막으로 필요한 시스템 프록시나 TUN을 켜고 브라우저에서 대상 사이트에 접속하면서 연결 기록을 살펴보세요. 설정 이름이 목록에 보이는 것만으로는 설정이 활성화됐거나 트래픽이 코어에 들어갔다고 볼 수 없습니다.

Windows에서는 설정의 시스템 정보에서 시스템 종류를 확인해 x64와 ARM 프로세서를 구분할 수 있습니다. macOS에서는 이 Mac에 관하여에서 Apple 칩인지 Intel 프로세서인지 확인하세요. Android는 기기의 프로세서 아키텍처와 클라이언트 배포 안내를 기준으로 선택하는 것이 좋습니다. 최신 기기는 ARM64인 경우가 많지만, 운영체제 버전만으로 판단해서는 안 됩니다. 범용 패키지는 해당 클라이언트가 실제로 제공하는 경우에만 사용하세요. Linux는 프로세서 아키텍처뿐 아니라 배포판에 맞는 deb, rpm 등 패키지 형식도 확인해야 합니다. 설치에 실패하면 이 조건부터 점검하고 운영체제 버전 요구 사항을 확인하세요. 출처가 불분명한 설치 파일을 반복해서 바꾸어 설치하지 마세요.

먼저 현재 정상적으로 작동하는 설정을 저장한 뒤, 클라이언트 로그에서 권한 요청, 가상 인터페이스 생성, 라우팅 설정 중 어느 단계에서 실패했는지 확인하세요. Windows 클라이언트는 서비스 모드를 설치하거나 문서에 따라 관리자 권한을 부여해야 할 수 있습니다. macOS에서는 권한이 필요한 보조 프로그램이나 네트워크 구성 요소를 승인해야 할 수 있습니다. Android에서는 시스템 VPN 연결 요청을 승인하고 다른 VPN이 이미 사용 중인지 확인하세요. Linux는 권한과 실행 방식이 환경마다 다르므로 클라이언트 안내를 따르세요. TUN이라는 문구만 보고 시스템 보안 설정을 바꾸지 마세요. 권한을 갖췄는데도 실패한다면 다른 VPN, 가상 네트워크 어댑터, 라우팅 간 충돌을 확인하세요.

먼저 일반 브라우저에서 동일한 프록시로 접속되는지 확인한 다음, 앱 컨테이너 제한이 있는 UWP 앱에서만 문제가 발생하는지 살펴보세요. 이런 앱은 루프백 제한 때문에 로컬 프록시 주소에 접속하지 못할 수 있습니다. 클라이언트에서 제공하는 루프백 예외 도구를 사용하거나 Windows 문서에 따라 CheckNetIsolation으로 해당 앱 패키지에 예외를 설정할 수 있습니다. 보통 관리자 권한이 필요합니다. 필요한 앱에만 적용하고, 나중에 되돌릴 수 있도록 변경 내용을 기록하세요. 모든 스토어 앱이 UWP인 것은 아니며, 모든 연결 실패가 루프백 제한 때문인 것도 아닙니다. 예외를 설정한 뒤에도 문제가 계속되면 앱이 시스템 프록시를 사용하는지와 앱 자체 네트워크 설정을 확인하세요.

먼저 클라이언트 코어가 실행 중인지, 시스템 프록시 주소와 포트가 현재 설정의 수신 포트와 일치하는지 확인하세요. 그런 다음 브라우저의 프록시 확장 프로그램, 조직 정책 또는 별도 프록시 설정이 시스템 설정을 덮어쓰는지 살펴보고, 대상 주소가 시스템 우회 목록에 포함되어 있지 않은지도 확인하세요. 대상 웹페이지에 접속하면서 클라이언트 연결 기록을 확인합니다. 기록이 전혀 없다면 트래픽 유입 경로를 먼저 점검하고, 기록은 있지만 직접 연결된다면 규칙과 정책 그룹 선택을 확인하세요. 설정에서 포트를 바꾼 뒤에는 시스템 프록시 설정을 다시 적용해야 합니다. 프록시 클라이언트를 여러 개 실행 중이라면 다른 클라이언트를 종료해 같은 시스템 설정을 반복해서 변경하지 않도록 하세요.

그렇지 않습니다. 클라이언트의 지연 시간 테스트는 보통 노드를 통해 지정된 테스트 주소에 요청을 보내며, 결과는 해당 시점의 연결 상태와 응답 시간을 보여줍니다. 지속적인 전송 대역폭과 같지 않으며 대상 웹사이트에 접속할 수 있다는 보장도 없습니다. 테스트 주소에 연결할 수 없으면 노드는 사용할 수 있어도 속도 테스트가 시간 초과될 수 있습니다. 노드를 선택할 때는 실제 접속 결과, 연결 로그, 서비스 제공업체의 상태를 함께 확인하고 테스트를 연속해서 대량으로 실행하지 마세요. 다운로드 환경을 비교하려면 동일한 대상과 네트워크 조건에서 비슷한 시간대에 테스트하고, 구독 트래픽이 소모될 수 있다는 점에 유의하세요. 한 번 측정한 지연 시간이 가장 낮다고 모든 상황에서 최선인 것은 아닙니다.

Fake-IP는 일부 코어에서 지원하는 DNS 보강 방식입니다. 도메인에 매핑된 주소를 반환한 뒤 코어가 원래 도메인을 연결에 연결해 처리하며, 프록시 출구의 실제 주소를 뜻하지는 않습니다. LAN 기기, 실제 DNS 응답에 의존하는 앱, 특정 기기 검색 프로토콜은 별도 설정이 필요할 수 있습니다. 먼저 이 모드를 켠 뒤에만 문제가 발생하는지 확인하고, 로컬 도메인 해석, DNS 처리, LAN 라우팅을 점검하세요. 필요하면 코어 문서에 따라 해당 도메인을 fake-ip-filter에 추가하거나 관련 DNS 정책을 조정하세요. 범위가 넓은 제외 규칙을 무턱대고 추가하지 말고, 변경 후에는 앱이나 시스템의 기존 DNS 캐시를 비운 다음 다시 테스트하세요.

원격 구독을 업데이트하면 설정 전체가 교체될 수 있어 구독 파일에서 직접 수정한 내용이 덮어써질 수 있습니다. 노드나 정책 그룹의 이름이 바뀌면 기존 선택 항목이 더 이상 일치하지 않을 수도 있습니다. 먼저 편집 중인 항목이 원격 설정 캐시인지, 별도의 로컬 설정인지, 클라이언트에서 제공하는 오버라이드 계층인지 확인하세요. 규칙을 계속 유지하려면 해당 클라이언트가 지원하는 오버라이드, 병합 또는 스크립트 기능을 사용하고 최종 생성된 설정의 규칙 순서를 확인해야 합니다. 자동 업데이트와 정책 선택 기억은 별개의 기능이므로 업데이트를 켠다고 모든 선택이 유지되는 것은 아닙니다. 변경 전에 복원할 수 있는 사본을 저장하세요.

먼저 업데이트 시 HTTP 상태 코드나 로그 오류를 기록하세요. 401, 403은 인증, 접근 정책 또는 자격 증명 문제일 수 있고, 404는 주소가 만료됐을 가능성이 있습니다. 시간 초과나 DNS 해석 실패라면 네트워크와 DNS부터 확인하세요. 상태 코드만으로는 서비스 제공업체의 확인을 대신할 수 없습니다. 제공업체 계정 페이지에서 이용 기간, 데이터 사용량, 구독 주소 변경 여부를 확인한 다음 전체 링크를 다시 복사하세요. 로그인 또는 인증 페이지가 반환된다면 클라이언트에 맞는 구독 주소를 제공업체에 문의하세요. 브라우저에서 링크가 열린다고 클라이언트도 같은 네트워크 경로를 사용하는 것은 아닙니다. 필요하면 클라이언트 옵션에 따라 직접 연결과 프록시를 통한 업데이트를 각각 테스트하되, 제한을 유발할 수 있으므로 연속해서 재시도하지 마세요.

대부분은 재설치보다 공통 조건을 먼저 확인하는 편이 효과적입니다. 기기에서 직접 인터넷에 접속할 수 있는지, 구독 기간이 남아 있고 데이터 사용량을 다 쓰지 않았는지 확인한 다음 시스템 날짜, 시간, 시간대가 정확한지 살펴보세요. 이어서 현재 코어가 구독의 프로토콜과 관련 설정을 지원하는지 확인하고, 로그에서 핸드셰이크, 인증서, DNS 해석 오류를 확인합니다. 모든 노드가 동시에 시간 초과되더라도 테스트 주소에 연결할 수 없는 문제일 수 있으므로 실제 앱 접속은 별도로 확인하세요. 현재 네트워크에서만 실패한다면 이용 조건에 맞는 다른 네트워크에서도 테스트해 기기 문제와 네트워크 경로 문제를 구분할 수 있습니다. 인증서 오류를 피하려고 인증서 검증을 함부로 끄지 마세요.

트래픽 유입, DNS, 규칙, 출구 순서로 확인하세요. 먼저 연결 기록에 브라우저 요청이 나타나는지 살펴봅니다. 기록이 없다면 시스템 프록시나 TUN이 실제로 적용됐는지 확인하세요. 요청은 있지만 도메인 해석에 실패한다면 DNS 설정과 현재 네트워크에서 DNS 응답을 받을 수 있는지 점검합니다. 이어서 해당 연결에 적용된 규칙과 정책 그룹을 확인해 사용할 수 없는 출구나 의도치 않은 직접 연결이 선택되지 않았는지 살펴보세요. 마지막으로 정상 작동이 확인된 다른 노드와 비교하고 대상 웹사이트 자체의 장애 여부도 확인하세요. 화면에 연결됨으로 표시되는 것은 코어나 가상 인터페이스가 시작됐다는 뜻일 수 있을 뿐, 실제 접속이 완료됐다는 의미는 아닙니다. 한 번에 한 항목씩 변경하고 변경 전후 결과를 기록하세요.

먼저 오류가 mixed-port 같은 프록시 수신 포트에 관한 것인지, 외부 제어 포트에 관한 것인지 확인하세요. 두 포트는 서로 다른 용도입니다. Windows에서는 netstat -ano로 수신 항목과 PID를 확인한 뒤 작업 관리자에서 프로세스를 찾을 수 있습니다. macOS나 Linux에서는 lsof -i :7890으로 포트 사용 상태를 확인할 수 있으며, 환경에 따라 권한이 필요합니다. 이전 클라이언트가 원인이라면 정상적으로 종료하고, 정체를 알 수 없는 시스템 프로세스를 강제로 끝내지 마세요. 여러 클라이언트를 함께 사용해야 한다면 새 클라이언트에 비어 있는 포트를 지정하고 실제 적용되는 설정이나 클라이언트의 포트 설정을 수정하세요. 시스템 프록시와 앱별 프록시 포트도 함께 변경한 뒤 다시 시작해 확인하세요.