Clash 자주 묻는 질문

클라이언트는 설정을 읽고 규칙에 따라 트래픽을 처리하지만, 설치만으로 사용할 수 있는 프록시 회선이 자동 생성되지는 않습니다. 구독 링크는 설정을 가져오는 주소로, 보통 노드와 정책 그룹, 규칙을 포함하며 노드만 포함할 수도 있습니다. 설정 제공업체에 구독이 Clash 또는 mihomo를 지원하는지 확인한 뒤 클라이언트에 가져오세요. 가져오기에 성공해도 설정을 읽을 수 있다는 뜻일 뿐입니다. 서비스가 유효한지, 정책 그룹에서 출구를 선택했는지, 시스템 트래픽이 클라이언트로 전달되는지도 확인해야 합니다. 이 사이트는 클라이언트 다운로드와 설정 안내를 제공하며 구독이나 노드를 제공하지 않습니다.

먼저 운영체제에 맞는 클라이언트를 고르고, 설정 호환성을 확인하세요. Clash Plus부터 살펴볼 수 있습니다. Android에서는 설치 패키지의 아키텍처와 시스템 요구 사항을 확인하고, iOS에서는 App Store를 통해 설치하세요. 데스크톱은 규칙 편집, 서비스 모드, TUN 설정 필요 여부를 고려해 선택하면 됩니다. 인터페이스가 비슷해도 코어 기능은 다를 수 있습니다. 특정 프로토콜이나 규칙 필드가 포함된 구독은 클라이언트가 사용하는 코어와 지원 범위를 확인하세요. 기존 설정이 있다면 먼저 백업하고, 이전 후 항목별로 검증하세요. 인터페이스 이름만 보고 그대로 사용할 수 있다고 판단하지 마세요.

규칙 모드는 설정의 규칙에 따라 연결별 출구를 선택하므로 일상적인 사용에 적합합니다. 전역 모드는 보통 코어에 들어온 연결을 전역 정책 그룹으로 보내고, 직접 연결 모드는 해당 연결을 대상에 바로 연결합니다. 전역 모드라고 해서 휴대폰이나 컴퓨터의 모든 트래픽이 자동으로 처리되는 것은 아닙니다. 실제 트래픽 처리 여부는 시스템 프록시, TUN 또는 모바일 VPN 채널에 달려 있습니다. 문제를 확인할 때는 잠시 전역 모드로 전환하고 사용 가능한 노드를 선택해 규칙 문제인지 살펴볼 수 있습니다. 확인을 마치면 규칙 모드로 되돌려 임시 테스트 설정을 계속 사용하지 않도록 하세요.

아닙니다. VpnService는 Android에서 제공하는 시스템 인터페이스입니다. 클라이언트는 이를 사용해 로컬 가상 네트워크 채널을 만들고, 설정에 따라 채널로 들어오는 트래픽을 처리합니다. 처음 실행할 때 표시되는 시스템 VPN 권한 요청은 트래픽을 처리하는 데 필요한 권한이며, 시스템이 원격 회선을 제공한다는 뜻은 아닙니다. 권한을 허용한 뒤에도 유효한 설정과 사용할 수 있는 출구가 필요합니다. 같은 사용자 또는 업무 프로필에서는 일반 VPN 채널을 보통 두 앱이 동시에 사용할 수 없습니다. 실행 직후 연결이 끊기면 다른 VPN, 가속 앱 또는 로컬 VPN을 사용하는 필터링 도구가 있는지 확인하세요.

구독 링크, 노드 비밀번호, 액세스 토큰, 제어 인터페이스 키는 반드시 숨기세요. 구독 주소가 평범한 URL처럼 보여도 경로나 매개변수에 액세스 자격 증명이 포함될 수 있습니다. 로그를 공유하기 전에는 전체 요청 주소, 계정 정보, 내부 네트워크 주소도 확인하세요. 스크린샷에서는 설정 세부 정보와 QR 코드를 가려야 합니다. 도움을 요청할 때는 보통 운영체제 버전, 클라이언트 이름, 코어 정보, 오류 발생 시각, 민감 정보를 제거한 오류 로그만 있으면 됩니다. 링크가 이미 공개됐다면 설정 제공업체에서 자격 증명을 재설정하세요. 게시물만 삭제해도 이미 복사된 링크를 무효화할 수는 없습니다.

클라이언트의 설정 또는 구독 페이지를 열고 URL 가져오기를 선택한 다음 전체 링크를 붙여 넣어 저장하세요. 다운로드와 파싱이 끝나면 해당 설정을 선택해 현재 설정으로 지정하세요. 목록에 보인다고 해서 활성화된 것은 아닙니다. 이어서 프록시 또는 정책 그룹 페이지에서 노드가 표시되는지 확인하고, 수동 선택 그룹에서 출구를 지정하세요. 마지막으로 연결을 시작하고 시스템 안내에 따라 권한을 허용한 뒤 테스트 페이지에 접속하세요. 노드만 포함된 구독을 가져왔다면 클라이언트가 지원하는 방식으로 정책 그룹과 규칙을 보완해야 합니다. 노드 목록만으로 완전한 설정이 되는 것은 아닙니다.

먼저 링크가 완전한지, 불필요한 공백이나 줄바꿈이 들어갔는지, 웹페이지 공유 주소를 복사한 것은 아닌지 확인하세요. 401은 보통 인증 문제와 관련 있고, 403은 권한이나 접근 제한이 원인일 수 있지만 정확한 사유는 제공업체 안내를 확인해야 합니다. 서비스 계정에 로그인해 만료일과 트래픽 상태를 확인하고 구독 주소가 재설정됐는지 살펴본 뒤, 새 링크를 복사해 기존 설정 항목을 업데이트하세요. 응답이 로그인 페이지, 인증 페이지 또는 오류 페이지라면 클라이언트가 YAML 설정으로 파싱할 수 없습니다. 모르는 온라인 변환 서비스에 링크를 반복해서 제출하지 마세요. 꼭 변환해야 한다면 링크가 누구에게 전달되는지 먼저 확인하세요.

플랫폼별로 다릅니다. Android 클라이언트는 보통 VpnService로 트래픽을 처리하므로 데스크톱의 관리자 권한 절차를 그대로 적용할 필요가 없으며, root가 필요하지 않은 경우가 많습니다. Windows의 TUN은 클라이언트 서비스 또는 권한 상승이 필요한 경우가 많고, macOS에서는 보조 구성요소를 설치하고 권한을 허용해야 할 수 있습니다. 먼저 연결을 끄고 클라이언트 안내에 따라 서비스를 설치한 뒤 다시 켜서 시작 로그를 확인하세요. 그래도 실패하면 가상 네트워크 어댑터, 다른 VPN, 보안 소프트웨어와의 충돌을 살펴보세요. 오류를 없애려고 시스템 보호 기능을 모두 끄지 말고 권한, 드라이버 또는 라우팅과 관련된 구체적인 오류부터 확인하세요.

네트워크 확장 기능을 사용하는 클라이언트는 처음 연결할 때 iOS에서 VPN 구성 추가를 요청할 수 있으며, 기기 인증이 필요할 수도 있습니다. 방금 설치한 클라이언트가 띄운 안내인지 확인하고 시스템 절차에 따라 권한을 허용하세요. 앱이 생성하는 VPN 구성은 별도로 다운로드하는 기기 관리 프로파일과 다릅니다. 출처를 알 수 없는 관리 프로파일을 설치하는 것을 일반적인 연결 절차로 여기지 마세요. 권한을 허용한 뒤에도 연결되지 않으면 클라이언트에서 구독, 정책 그룹, 로그를 확인하세요. 기기가 조직에서 관리되는 경우 관리 정책으로 권한이 제한될 수 있으니 기기 관리자에게 먼저 문의하세요.

시스템 프록시는 앱에 프록시 주소를 제공할 뿐, 모든 프로그램이 이를 따르도록 보장하지는 않습니다. 먼저 클라이언트 코어가 실행 중인지, 시스템 프록시가 로컬의 올바른 수신 포트를 가리키는지 확인한 다음 브라우저나 앱에 별도 프록시가 설정되어 있는지 살펴보세요. 일부 프로그램은 자체 네트워크 스택을 사용하거나 직접 연결하므로 앱 내부에서 프록시를 설정하거나, 라우팅에 미치는 영향을 파악한 뒤 TUN을 사용해야 할 수 있습니다. 클라이언트를 종료하기 전에 시스템 프록시를 정상적으로 끄세요. 클라이언트가 중지됐는데도 시스템이 해당 클라이언트를 가리키면 프록시를 따르는 앱이 오히려 인터넷에 연결되지 않을 수 있습니다. 회사 기기에서는 관리되는 프록시 설정도 확인하세요.

지연 시간 테스트는 노드가 지정된 테스트 주소에 접속한 결과만 보여 줍니다. 모든 웹사이트와 프로토콜, 다운로드가 정상이라는 뜻은 아닙니다. 먼저 대상 요청에 실제로 어떤 정책 그룹이 적용됐는지 확인하고, 해당 그룹에서 현재 어떤 노드가 선택됐는지 살펴보세요. 테스트한 노드와 실제 사용 중인 노드가 다를 수 있습니다. 그런 다음 대상 도메인의 DNS 응답, 연결 로그, 규칙 적용 기록을 확인하세요. 테스트 주소 자체에 접속할 수 없어 잘못 판단할 수도 있으므로 실제 대상 서비스에서도 확인해야 합니다. 지연 시간이 가장 짧은 노드만 고르지 마세요. 연결 안정성, 대상 서비스 접속 가능 여부, 서비스에 남은 트래픽도 사용에 영향을 줍니다.

특정 출구를 고정해 사용하려면 select 수동 정책 그룹을 선택하세요. 테스트 결과에 따라 지연 시간이 짧은 출구를 고르려면 url-test를, 목록 앞쪽의 사용 가능한 출구를 우선 사용하고 장애 시 전환하려면 fallback을 사용하면 됩니다. 이 기능들은 테스트 주소와 검사 간격에 따라 동작하므로 전환이 실시간으로 이뤄지지는 않습니다. 먼저 구독에 해당 정책 그룹이 정의돼 있는지 확인한 뒤 클라이언트에서 선택하세요. 그룹 이름만 바꾼다고 동작이 달라지는 것은 아닙니다. 설정을 수정하기 전에 사본을 보관하고, 구독을 업데이트한 뒤 로컬 변경 사항이 덮어쓰이지 않았는지 확인하세요. 세션 안정성이 중요한 서비스에서는 자동 전환을 특히 신중하게 사용해야 합니다.

규칙은 보통 위에서 아래 순서로 적용되므로 구체적인 도메인 규칙을 포괄적인 규칙과 마지막 기본 규칙보다 앞에 두세요. 먼저 규칙에서 참조하는 정책 이름이 실제로 존재하는지 확인한 뒤 클라이언트의 오버라이드, 병합 또는 규칙 유지 기능으로 변경 사항을 저장하세요. 구독에서 다운로드한 파일을 직접 편집하면 다음 업데이트 때 덮어써질 수 있습니다. 규칙을 추가한 뒤 설정을 다시 불러오고 로그에서 적용 결과를 확인하세요. 앱은 여러 도메인에 연결하는 경우가 많으므로 홈페이지 도메인 하나만 추가해서는 충분하지 않을 수 있습니다. 실제 연결을 확인하며 조금씩 조정하고, 이유를 설명할 수 없는 항목을 한꺼번에 많이 추가하지 마세요.

두 기기를 서로 통신할 수 있는 같은 로컬 네트워크에 연결한 뒤, 프록시를 제공하는 클라이언트에서 로컬 네트워크 연결 허용을 켜고 수신 주소와 프록시 포트를 확인하세요. 다른 기기의 프록시 서버 주소에는 해당 호스트의 로컬 네트워크 IP를 입력해야 합니다. 다른 기기 자신의 루프백 주소를 입력하면 안 됩니다. 연결되지 않으면 호스트 방화벽, 게스트 네트워크 격리, 무선 액세스 포인트 격리 여부를 확인하세요. 신뢰할 수 있는 네트워크에서만 켜고, 클라이언트가 지원한다면 접근 제어나 인증을 설정하세요. 수신 포트를 인터넷에 직접 노출하지 마세요. 모바일 핫스팟이나 일부 학교 네트워크는 기기 간 통신을 제한할 수 있으므로 별도로 확인해야 합니다.

일부 UWP 또는 AppContainer 앱이 시스템 프록시를 통해 로컬 프록시 포트에 접속할 때 루프백 격리 제한이 발생할 수 있습니다. 모든 스토어 앱에 해당하는 문제는 아닙니다. 먼저 일반 브라우저가 같은 프록시를 통해 인터넷에 접속되는지 확인한 다음 영향을 받는 앱을 특정하세요. 클라이언트에 루프백 예외 도구가 있다면 필요한 권한으로 실행해 대상 앱에만 예외를 추가한 뒤 앱을 완전히 종료하고 다시 여세요. TUN으로 트래픽을 처리하는 방법도 검토할 수 있지만 실제로 작동하는지 확인해야 합니다. 모든 앱을 일괄적으로 예외에 추가하지 말고 원격 노드 장애를 로컬 루프백 문제로 오인하지 마세요.

먼저 프록시를 끄고 기본 네트워크가 정상적으로 연결되는지 확인하세요. Wi-Fi 로그인 인증을 마치고 기기 시간이 정확한지도 살펴보세요. 이어서 구독이 유효한지, 노드 목록이 오래된 캐시가 아닌지 확인하고 다른 VPN이 채널을 사용 중인지 살펴보세요. 클라이언트 코어를 재시작하고 노드 하나를 선택해 실제 대상에 접속하면서 관련 오류 중 첫 번째 항목을 확인하세요. 속도 테스트만 시간 초과라면 신뢰할 수 있고 접속 가능한 테스트 주소로 다시 확인하세요. 로그에 서버 연결 실패가 표시되면 모바일 데이터나 다른 네트워크로 바꿔 비교하세요. 처음부터 재설치하거나 설정을 삭제하면 문제를 찾는 데 도움이 될 상태가 사라질 수 있습니다.

시스템 앱 설정에서 클라이언트를 찾아 배터리 사용을 백그라운드 실행 허용 또는 제한 없음으로 변경하고, 휴대폰 제조사의 설정에서 필요한 자동 시작 권한도 켜세요. 일부 시스템에서는 최근 앱 화면에서 앱을 잠가야 할 수도 있지만, 배터리 설정을 대신하지는 않습니다. 화면을 몇 분간 잠근 뒤 잠금을 해제하고 VPN 아이콘, 알림, 로그가 계속 표시되는지 확인하세요. 필요하다면 상시 VPN을 켤 수 있습니다. VPN을 사용하지 않을 때의 연결을 차단하는 기능은 클라이언트가 끊기면 네트워크도 차단하므로 작동 방식을 이해한 뒤 켜세요. 프로세스가 계속 종료된다면 시스템 절전 모드와 제조사의 백그라운드 관리 규칙도 확인하세요.

DNS는 도메인 이름을 IP 주소로 변환합니다. 먼저 구독에 원래 설정된 DNS를 확인하고, 현재 네트워크에서 상위 DNS 서버에 접속할 수 있는지, 자체 도메인을 먼저 확인해야 하는 순환 의존성이 있는지 살펴보세요. fake-ip는 가상 주소와 코어의 매핑을 이용해 도메인을 처리하는 방식입니다. 주소가 낯설다는 이유만으로 오류라고 판단하지 마세요. 로컬 네트워크 서비스나 앱이 호환되지 않는다면 코어 안내에 따라 제외 항목을 조정하고, 수정 후에는 클라이언트 기능을 사용해 관련 캐시를 지우세요. 시스템 비공개 DNS, 브라우저 보안 DNS, 클라이언트 설정이 서로 다른 DNS 경로를 만들고 있지는 않은지도 확인해야 합니다.

그럴 가능성은 있지만 바로 단정할 수는 없습니다. 두 네트워크는 IPv6, DNS, UDP 지원, 라우팅 제한이 다를 수 있습니다. 같은 노드와 대상, 모드를 유지한 채 네트워크만 바꿔 비교한 다음 로그에서 DNS 응답 주소와 연결 오류를 확인하세요. IPv6가 의심된다면 클라이언트에서 지원하는 설정으로 관련 옵션을 일시적으로 끄고 다시 연결해 확인하세요. DNS의 IPv6 설정과 시스템 트래픽 처리 범위도 함께 살펴보세요. 검증한 뒤 변경 사항을 유지할지 결정하세요. IPv6 비활성화를 모든 문제의 해결책으로 여기거나 여러 설정을 한꺼번에 바꾸지 마세요.

먼저 구독 출처, 현재 활성화된 설정, 수동 규칙, 오버라이드 내용, 정책 그룹 선택, DNS 설정을 기록하고 필요하면 클라이언트가 지원하는 백업 파일을 내보내세요. 백업에는 자격 증명이 포함될 수 있으므로 안전한 곳에 보관해야 합니다. 이전할 때는 기존 클라이언트의 연결과 시스템 프록시를 먼저 끈 다음 새 클라이언트로 가져와 두 프로그램이 포트나 VPN 채널을 함께 사용하지 않도록 하세요. 기존 클라이언트의 비공개 필드를 모두 그대로 복사하지 말고 새 코어가 지원하는지 먼저 확인하세요. 연결이 복구되면 웹페이지, 자주 쓰는 앱, 로컬 네트워크 접속, 화면 잠금 후 상태를 차례로 확인한 뒤 기존 설정을 정리하세요.