Clash 자주 묻는 질문

클라이언트는 설정 관리, 정책 선택, 시스템 프록시 전환 기능을 제공합니다. 코어는 설정을 해석하고 규칙을 적용해 연결을 수립하며, 구독은 서비스 제공자가 노드나 전체 설정을 전달하는 방식입니다. 클라이언트를 설치해도 사용할 수 있는 프록시 서비스가 자동으로 제공되지는 않습니다. 문제를 해결할 때는 인터페이스 조작, 코어 오류, 구독 상태를 먼저 구분하고 서로 혼동하지 마세요. 같은 구독이라도 클라이언트마다 호환 여부가 다를 수 있으며, 실제 코어와 지원 필드에 따라 달라집니다. 클라이언트를 옮기기 전에 정보 또는 코어 설정에서 코어 이름을 확인하고 가져오기 로그를 살펴보세요.

일상적으로는 규칙 모드를 사용하는 것이 일반적입니다. 설정에 포함된 규칙에 따라 연결을 프록시로 보내거나 직접 연결합니다. 전역 모드는 코어에 전달된 연결을 모두 전역 정책으로 처리하고, 직접 연결 모드는 보통 해당 연결을 대상에 바로 연결합니다. 전역 모드를 사용해도 기기의 모든 앱이 자동으로 프록시를 거치는 것은 아닙니다. 트래픽이 먼저 코어로 전달되어야 합니다. 특정 웹사이트의 분류 문제인지 확인하려면 잠시 전역 모드로 전환하고 같은 노드를 선택해 비교한 뒤, 테스트가 끝나면 규칙 모드로 되돌리세요. 두 모드에서 모두 실패하면 노드, 이름 해석, 로컬 트래픽 전달 경로를 확인하세요.

시스템 프록시는 HTTP 또는 SOCKS 프록시 주소를 운영체제에 등록하며, 이를 사용할지는 앱이 결정합니다. 일부 게임, 명령줄 도구, 자체 네트워크 스택을 사용하는 프로그램은 시스템 프록시 설정을 읽지 않습니다. TUN 모드는 가상 네트워크 어댑터와 라우팅을 통해 트래픽을 전달하므로 대체로 더 많은 트래픽을 처리하지만, 관련 권한과 DNS 설정이 필요합니다. 브라우저는 연결되는데 특정 앱만 실패한다면 먼저 해당 앱이 시스템 프록시를 지원하는지 확인한 뒤 TUN 사용을 고려하세요. 라우팅을 가로채는 클라이언트를 여러 개 동시에 실행하면 기본 경로 충돌이나 중복 전달이 발생할 수 있습니다.

사용 가능 여부는 노드 프로토콜, 설정 형식, 서버 상태에 따라 달라지며 유료인지 무료인지만으로 판단할 수 없습니다. 이른바 구독 서비스는 보통 설정을 가져오는 비공개 주소를 제공하는 반면, 공개 노드는 언제든 사용할 수 없게 될 수 있고 운영 주체나 데이터 처리 방식도 확인하기 어렵습니다. 가져오기 전에 출처, 호환 코어, 이용 약관을 확인하고 여러 개의 전체 설정을 그대로 합치지 마세요. 설정을 통합해야 한다면 클라이언트가 지원하는 병합 기능이나 규칙 덮어쓰기 기능을 사용하고, 되돌릴 수 있도록 원본 설정을 보관하세요. 이 페이지는 노드를 제공하거나 구독 서비스를 관리하지 않습니다.

두 가지를 모두 확인해야 합니다. 먼저 Windows, macOS, Android, Linux에 맞는 클라이언트를 고른 다음 기기 아키텍처에 맞는 설치 파일을 선택하세요. x64와 AMD64는 일반적으로 같은 종류의 아키텍처를 가리키며, ARM64는 다른 프로세서 아키텍처입니다. macOS에서는 이 Mac에 관하여에서 칩을 확인할 수 있고, Windows에서는 시스템 정보에서 시스템 종류를 확인할 수 있습니다. Android 기기는 제품 사양을 확인하세요. 운영체제 버전만으로 아키텍처를 판단하지 마세요. 설치 후 실행되지 않으면 시스템에 표시된 메시지를 기록하고 클라이언트의 최소 시스템 요구 사항을 확인하세요. 호환되지 않는 설치 파일을 반복해서 설치하지 마세요.

먼저 서비스 제공자의 관리 페이지에서 구독 유효 기간, 계정 상태, 링크가 재설정되었는지 확인하세요. 복사한 주소에 공백이나 줄바꿈, 웹페이지 안내 문구가 섞이지 않았는지도 살펴보세요. 클라이언트에 HTTP 상태 코드가 표시된다면 401 또는 403은 인증을 확인하고, 404는 주소가 변경되었을 가능성이 있으며, 429가 표시되면 반복 요청을 멈추고 기다리세요. 다운로드는 되지만 해석에 실패한다면 로그인 페이지나 노드 공유 텍스트가 아니라 클라이언트와 호환되는 설정을 가져왔는지 확인하세요. 로그와 스크린샷에 표시된 구독 주소 전체를 가리고, 주소가 유출되었다면 서비스 제공자 페이지에서 새로 발급받으세요.

먼저 권한 문제인지 설정 오류인지 구분하세요. 데스크톱 클라이언트는 서비스 구성 요소 설치, 보조 프로그램 승인 또는 최초 설정 시 관리자 권한을 요구할 수 있습니다. Android에서는 일반적으로 시스템 팝업에서 VPN 연결을 허용해야 합니다. 권한을 부여한 뒤에도 권한, 장치 생성, 라우팅 설정 오류가 남아 있는지 로그를 확인하세요. 구성 요소 설치에 실패하면 해당 클라이언트의 안내에 따라 서비스를 다시 설치하세요. 시스템 드라이버를 임의로 변경하거나 보안 기능을 끄지 마세요. 다른 VPN이나 가상 네트워크 어댑터 관리 프로그램도 종료하세요. 설정 해석 오류는 권한을 높여도 필드나 들여쓰기 문제를 해결하지 못합니다.

먼저 원본 파일을 보관하고 로그에 표시된 줄 번호와 필드 이름을 확인하세요. YAML 계층에는 공백을 사용해야 하며, 목록 항목·콜론·들여쓰기가 서로 맞아야 합니다. 정책 그룹과 규칙에서 참조하는 이름도 대소문자와 공백까지 완전히 일치해야 합니다. 특정 프로토콜이나 필드를 지원하지 않는다는 메시지가 표시되면 오류 줄을 바로 삭제하지 말고 코어 호환성을 확인하세요. 한 번에 한 곳만 수정하고 다시 불러와야 원인을 찾기 쉽습니다. 구독 업데이트 후 문제가 발생했다면 마지막으로 정상 작동한 설정으로 되돌린 다음, 민감 정보를 가린 오류 내용과 클라이언트 코어 이름을 서비스 제공자에게 전달하세요.

정책 그룹에서 선택한 노드는 해당 그룹을 참조하는 연결에만 적용됩니다. 먼저 클라이언트가 규칙 모드인지 확인한 다음 연결 기록에서 대상 요청을 찾아 실제로 적용된 규칙과 최종 정책을 살펴보세요. DIRECT가 적용되었다면 다른 정책 그룹을 바꿔도 결과는 달라지지 않습니다. 사용자 지정 규칙은 보통 위에서 아래 순서로 적용되므로, 범위가 넓은 직접 연결 규칙이 앞에 있으면 뒤의 규칙을 덮어쓸 수 있습니다. 현재 사용 중인 설정이 수정한 설정인지, 구독 업데이트가 로컬 변경 사항을 덮어쓰지 않았는지도 확인하세요. 변경 후에는 연결을 새로 만들어야 합니다. 기존 연결에는 규칙이 다시 적용되지 않을 수 있습니다.

클라이언트에서 제공하는 덮어쓰기, 병합, 확장 스크립트, 영구 규칙 기능을 우선 사용하세요. 업데이트 때마다 새로 내려받는 원격 설정 파일을 직접 수정하지 마세요. 먼저 해당 기능이 규칙을 삽입하는 위치를 확인한 뒤, 특정 도메인 규칙을 적절한 범위의 포괄 규칙보다 앞에 배치하고 마지막에는 기본 처리용 MATCH를 유지하세요. 저장한 뒤 구독을 직접 업데이트해 규칙이 남아 있고 실제로 적용되는지 확인하세요. 덮어쓰기 문법은 클라이언트마다 다르므로 다른 클라이언트로 옮길 때 다시 확인해야 합니다. 규칙 제공자는 규칙 세트를 구성할 뿐이며, 규칙이 유지되는지는 클라이언트의 불러오기 방식에 달려 있습니다.

먼저 클라이언트에서 로컬 수신 주소, 포트, 지원하는 프록시 프로토콜을 확인한 뒤 각 도구의 안내에 따라 프록시 옵션이나 환경 변수를 설정하세요. 많은 도구가 HTTP_PROXY와 HTTPS_PROXY를 지원하지만, 소문자 변수만 읽거나 자체 설정 파일을 사용하는 도구도 있습니다. 한 번 설정하면 모든 프로그램에 적용된다고 가정하지 마세요. HTTPS_PROXY 값은 프록시 주소를 지정하며, 일반 HTTP 프록시를 사용할 때도 http://로 시작할 수 있습니다. 설정 후 새 터미널을 열어 테스트하고, 사용이 끝나면 임시 변수를 삭제하세요. 단일 기기에서 사용하는 도구의 프록시 문제를 해결하려고 로컬 수신 주소를 외부에 공개하지 마세요.

먼저 이름 해석 모드가 원인인지 확인하세요. 노드와 규칙은 그대로 두고 문제가 있는 도메인과 앱을 비교 테스트합니다. 앱이 실제 IP 주소, 로컬 네트워크 기기 검색, 특수 도메인 해석에 의존한다면 코어에서 지원하는 형식으로 필요한 도메인을 fake-ip-filter에 추가한 뒤 관련 앱을 다시 시작하고 DNS 캐시를 비우세요. 도메인 제외는 이름 해석 방식만 바꾸며 해당 연결이 반드시 직접 연결되는 것은 아닙니다. 트래픽 분류는 여전히 규칙에 따라 결정됩니다. 모든 도메인을 필터 목록에 넣지 마세요. redir-host로 전환해야 한다면 DNS 상위 서버, 라우팅, 기존 규칙의 적용 가능성도 함께 확인하세요.

먼저 프록시를 잠시 중단하고 기본 네트워크 연결을 확인한 다음 구독 상태, 시스템 시간, 노드가 여전히 서비스 중인지 점검하세요. 이어서 다른 노드와 다른 네트워크를 각각 테스트해 특정 노드 장애인지, 로컬 네트워크 제한인지, 설정 전체의 문제인지 구분합니다. 내장 테스트는 지정된 테스트 주소에 연결합니다. 테스트가 시간 초과되었다고 모든 대상에 연결할 수 없는 것은 아니며, 테스트 결과를 다운로드 속도로 볼 수도 없습니다. 로그에서 실패한 단계가 도메인 해석, 연결 수립, TLS 핸드셰이크 중 무엇인지 확인하세요. 여러 노드를 연속으로 반복 테스트하지 마세요. 같은 노드가 다른 네트워크에서도 계속 실패한다면 민감 정보를 가린 로그를 서비스 제공자에게 전달하세요.

먼저 코어가 실행 중인지, 로컬 프록시 포트와 시스템에 등록된 포트가 일치하는지 확인한 다음 브라우저 확장 프로그램이나 별도 프록시 설정이 이를 덮어쓰지 않는지 살펴보세요. 다른 프록시 도구를 종료하고 시스템 프록시를 껐다가 다시 켠 뒤 새 연결을 테스트하세요. 시스템 우회 목록에 대상 도메인이 포함되어 있는지도 확인해야 합니다. 시스템 프록시는 보통 해당 설정을 따르는 앱에만 적용됩니다. 클라이언트를 종료해도 연결되지 않는다면 시스템에 로컬 포트를 가리키는 프록시 설정이 남아 있는지 확인하세요. 로컬 프록시 진입점을 확인하지 않은 채 노드만 바꾸지 마세요. 포트가 이미 사용 중이거나 코어가 시작되지 않으면 모든 노드에서 문제가 생길 수 있습니다.

AppContainer 네트워크 격리를 사용하는 일부 앱은 로컬 프록시 포트에 직접 연결할 수 없습니다. 따라서 브라우저는 정상인데 특정 앱만 실패할 수 있습니다. 먼저 문제가 발생한 앱이 실제로 이런 유형인지 확인한 뒤 클라이언트에서 루프백 예외를 관리하는 기능을 제공하는지 살펴보세요. 기능이 있다면 로컬 프록시에 연결해야 하는 앱만 허용하세요. Windows 관리 도구에 익숙한 사용자는 CheckNetIsolation으로 예외를 확인하고 관리할 수도 있습니다. 모든 앱에 일괄 허용하지 마세요. 루프백 예외는 서버나 DNS 문제를 해결하지 않습니다. 권한을 부여한 뒤에도 실패한다면 연결 기록을 계속 확인하세요.

도메인이 열리지 않으면 먼저 DNS 해석 실패인지 프록시 연결 실패인지 구분하세요. 코어 로그에서 해석 오류를 확인하고 dns-hijack, 상위 DNS, 라우팅 설정이 현재 코어와 호환되는지 살펴보세요. Android에서는 비공개 DNS와 클라이언트의 DNS 처리 기능이 충돌하지 않는지도 확인하세요. 여러 옵션을 한꺼번에 바꾸지 마세요. 화면을 잠근 뒤에만 연결이 끊긴다면 배터리 최적화, 백그라운드 실행 권한, 시스템 VPN 상태를 확인하고 다른 VPN 앱이 연결을 차지하고 있지 않은지 살펴보세요. 설정을 한 번에 하나씩 바꾸며 테스트하고 원래 설정을 보관해 백그라운드 제한을 노드 장애로 오해하지 않도록 하세요.