Clash 자주 묻는 질문

클라이언트는 직접 조작하는 화면이고, 코어는 연결을 처리하고 규칙을 적용하는 프로그램입니다. 예를 들어 mihomo가 코어에 해당합니다. 구독은 설정을 가져올 때 사용하는 업데이트 주소입니다. 이 셋은 서로 다른 요소입니다. 클라이언트를 설치한 뒤에는 보통 사용할 권한이 있는 구독이나 로컬 설정을 가져와 실행할 항목으로 선택해야 합니다. 클라이언트가 열려도 구독을 사용할 수 있다는 뜻은 아니며, 구독이 업데이트되어도 모든 노드에 연결할 수 있다는 뜻은 아닙니다. 문제를 점검할 때는 화면, 설정 가져오기, 실제 연결 중 어느 단계에서 문제가 생겼는지 먼저 확인하세요.

일상적인 사용에는 설정에 정의된 규칙에 따라 요청을 지정된 정책으로 보내는 규칙 모드를 권장합니다. 전역 모드는 코어로 들어온 요청을 전역 정책으로 보내므로 짧게 비교·점검할 때 유용합니다. 직접 연결 모드에서는 코어로 들어온 요청이 대상에 바로 연결됩니다. 모드를 바꾼다고 코어로 들어오는 앱이 달라지는 것은 아닙니다. 어떤 트래픽이 코어로 들어오는지는 시스템 프록시, 앱 자체 설정, TUN의 트래픽 처리 여부에 따라 달라집니다. 전역 모드에서도 웹페이지가 열리지 않는다고 해서 규칙 오류라고 단정할 수는 없습니다. 전역 정책, 노드 연결, 도메인 이름 확인도 점검하세요. 테스트가 끝나면 원래 모드로 되돌리세요.

노드는 개별 프록시 연결 설정이고, 정책 그룹은 노드나 직접 연결, 다른 그룹 등을 묶어 선택하는 항목입니다. 규칙은 보통 노드가 아니라 정책 그룹 이름을 참조합니다. 수정한 그룹이 현재 요청에 적용되지 않으면 연결 경로도 바뀌지 않습니다. 연결 목록에서 대상 도메인을 찾아 적용된 규칙과 정책 경로를 확인한 다음 해당 그룹을 수정하세요. 자동 선택 그룹은 상태 점검 결과에 따라 출구 노드가 다시 선택될 수 있습니다. 출구를 고정하려면 설정에서 제공하는 수동 선택 그룹을 사용하세요.

처음부터 두 기능을 함께 켤 필요는 없습니다. 시스템 프록시는 시스템 설정을 따르는 앱에 프록시 주소를 알려주는 방식입니다. TUN은 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 트래픽을 처리하며, 적용 범위는 클라이언트와 설정에 따라 다릅니다. 초보자라면 먼저 시스템 프록시로 브라우저 연결을 확인한 뒤 게임, 명령줄 프로그램 또는 다른 앱에 필요한 경우 TUN을 켜세요. 문제를 점검할 때는 한 번에 설정 하나만 바꿔 두 가지 트래픽 처리 방식이 서로 간섭하지 않도록 하세요. TUN을 켜도 모든 트래픽이 반드시 프록시를 거치는 것은 아닙니다. 실제 경로는 라우팅, 규칙, 앱의 네트워크 동작에 따라 결정됩니다.

먼저 구독 제공업체의 계정 페이지에서 서비스 상태, 만료일, 남은 트래픽을 확인하세요. 그런 다음 클라이언트용 구독 주소를 다시 복사하고 앞뒤 공백이나 줄바꿈이 없는지 살펴보세요. 웹사이트 로그인 주소가 구독 주소와 같지는 않습니다. 응답이 웹페이지, 로그인 안내 또는 오류 페이지라면 클라이언트가 설정으로 읽을 수 없습니다. 업데이트 로그의 상태 코드도 확인하세요. 401, 403은 대개 접근 권한 문제이고, 404는 주소가 변경되었을 가능성이 있으며, 429는 잠시 기다렸다가 다시 시도해야 한다는 뜻입니다. 접근 정보가 포함된 전체 구독 링크를 공개 게시판에 올리지 마세요.

가져온 설정이 설정 목록에만 있는 것이 아니라 현재 설정으로 선택되었는지 먼저 확인하세요. 그런 다음 가져온 결과에 프록시 노드나 프록시 그룹이 포함되어 있는지, 프록시 그룹 자체의 업데이트 오류는 없는지 살펴보세요. 일부 구독은 노드 목록만 제공하므로 완전한 실행 설정으로 바로 사용할 수 없습니다. 추가 리소스를 온라인에서 가져와야 하는 설정도 있습니다. 기존 파일을 서둘러 덮어쓰지 말고, 실행 가능한 설정을 보존한 뒤 제공업체가 요구하는 클라이언트 형식과 코어 호환성을 확인하세요. 업데이트에 성공하면 정책 그룹으로 돌아가 선택 항목이 나타났는지 확인하세요.

YAML은 들여쓰기로 계층 구조를 나타내는 텍스트 형식입니다. 먼저 원본 파일을 복사한 뒤 로그에 나온 줄 번호 주변을 확인하세요. 특히 콜론, 목록을 나타내는 하이픈, 공백 들여쓰기를 살펴보세요. 탭과 공백을 섞어 쓰지 말고, 특수 문자가 포함된 텍스트는 YAML 문법에 맞게 따옴표로 감쌀 수 있습니다. 문법 오류를 해결한 뒤에는 정책 그룹이 참조하는 노드 이름과 규칙이 참조하는 그룹 이름이 실제로 있는지 확인하세요. 이름은 정확히 일치해야 합니다. 한 번에 작은 부분만 수정하고 다시 불러오세요. 계속 실패하면 백업으로 되돌린 뒤 여러 항목을 연달아 수정하지 말고 설명서를 참고해 한 부분씩 확인하세요.

TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 수정하므로 보통 추가 권한이 필요합니다. 먼저 클라이언트에 표시된 안내를 확인하세요. Windows 클라이언트는 서비스를 설치하고 실행해야 할 수 있고, macOS는 보조 프로그램을 승인해야 할 수 있습니다. Linux에서는 설치 방식에 맞는 권한이나 서비스 관리가 필요합니다. 권한을 부여한 뒤 TUN을 다시 켜고 로그에 인터페이스 생성 오류가 남는지 확인하세요. 출처를 알 수 없는 스크립트로 시스템 권한을 일괄 변경하지 마세요. 조직에서 관리하는 기기라면 관리 정책에서 허용하는지 먼저 확인하세요. 필요한 권한이 있는데도 실패한다면 다른 VPN, 가상 네트워크 어댑터, 보안 프로그램과의 충돌을 점검하세요.

정책 그룹 버튼만 보지 말고 연결 목록에 표시된 실제 요청을 확인하세요. 클라이언트의 연결 화면을 열고 대상 웹사이트를 새로고침한 뒤 도메인이나 앱 이름으로 요청을 찾아 적용된 규칙, 사용된 정책, 최종 연결 노드를 확인하세요. 웹페이지는 여러 도메인에 동시에 요청을 보낼 수 있으므로 본문과 이미지, 동영상의 연결 경로가 다를 수 있습니다. 규칙은 대체로 위에서 아래 순서로 확인하며, 먼저 일치한 규칙이 처리 방식을 결정합니다. 마지막의 MATCH는 앞선 규칙에 일치하지 않은 요청에 적용되는 기본 규칙입니다. 기존 연결이 보이면 해당 사이트 탭을 닫았다가 다시 열고 새로 만들어진 연결을 확인하세요.

구독을 업데이트하면 보통 원격 설정을 다시 가져오므로 구독 파일에 직접 추가한 내용은 덮어써질 수 있습니다. 사용자 지정 내용과 원격 설정을 분리해 저장할 수 있도록 클라이언트의 덮어쓰기, 병합 또는 확장 기능을 우선 사용하세요. 기능 이름과 병합 순서는 클라이언트마다 다르므로 다른 클라이언트의 설정 방식을 그대로 따라 하면 안 됩니다. 수정 후 최종 적용 설정을 확인해 사용자 지정 규칙이 앞쪽에 있는지, 참조한 정책 그룹이 존재하는지 살펴보고 수동 업데이트도 테스트하세요. 클라이언트가 지속적인 덮어쓰기를 지원하지 않으면 별도의 로컬 설정을 보관할 수 있지만, 이후 노드와 규칙은 직접 관리해야 합니다.

먼저 해당 요청이 실제로 사용하는 정책 그룹을 수정했는지 확인하고 기존 연결이 남아 있는지도 살펴보세요. 일부 앱은 기존 연결을 계속 재사용하므로 정책을 바꿔도 이미 만들어진 세션은 끊기지 않을 수 있습니다. 관련 웹페이지를 닫거나 앱을 종료한 뒤 요청을 다시 보내세요. 필요한 경우 다른 작업에 영향을 주지 않도록 클라이언트 연결 목록에서 해당 연결만 종료할 수 있습니다. 출구 확인 페이지에 캐시가 남아 있을 수도 있으므로 연결 목록과 새 테스트 요청을 함께 확인하세요. 정책 경로에 자동 선택 그룹이나 중첩 그룹이 있다면 바깥 그룹 이름만 보지 말고 펼쳐서 최종 선택된 노드를 확인하세요.

GeoIP는 IP 주소를 지역별로 분류해 관련 규칙에서 사용하는 데이터입니다. 구독에 포함된 노드 정보와는 별개의 리소스입니다. 설정에서 실제로 이 데이터를 사용하는 경우에만 업데이트가 해당 규칙의 판단에 영향을 줍니다. 현재 코어가 사용하는 데이터 형식을 확인한 뒤 클라이언트에서 지원하는 리소스 업데이트 기능을 이용하세요. 형식이 다른 파일을 그대로 바꿔 쓰지 마세요. 업데이트가 끝나면 클라이언트 안내에 따라 설정을 다시 불러오거나 코어를 재시작한 뒤 테스트 연결에 적용된 규칙을 확인하세요. 지역 데이터만으로 모든 서비스의 라우팅이 예상대로 된다고 보장할 수는 없습니다. 특정 웹사이트를 대상으로 한다면 도메인을 명시한 규칙이 더 확인하기 쉽습니다.

시간 초과는 이번 테스트가 제한 시간 안에 결과를 얻지 못했다는 뜻일 뿐, 구독이 만료되었다는 증거는 아닙니다. 먼저 기기의 직접 연결 인터넷을 확인하고 다른 노드도 각각 테스트해 특정 테스트 주소에서만 실패하는지 살펴보세요. 일부 노드가 작동한다면 노드나 경로 문제일 가능성이 높습니다. 모두 실패한다면 기기 시간, 설정 로드 결과, 네트워크 제한, 다른 VPN의 영향도 확인하세요. 지연 시간 테스트와 실제 웹페이지 접속 결과는 완전히 같지 않으므로 대상 서비스에도 직접 접속해 보세요. 문제를 점검할 때 구체적인 오류와 발생 조건을 기록하세요. 제공업체에 문의할 때는 구독 링크와 비밀번호 등 민감한 정보를 가리세요.

시스템 프록시 주소가 기기 자체를 가리키는지 확인하고, 포트가 현재 코어의 HTTP 또는 혼합 프록시 포트와 일치하는지 살펴보세요. 흔히 쓰이는 포트 번호만 보고 추측하면 안 됩니다. 브라우저 확장 프로그램, 별도 프록시 설정, 우회 목록도 확인하세요. 일부 앱은 시스템 설정을 따르지 않습니다. 새 웹페이지를 열면서 클라이언트 연결 목록을 확인하세요. 새 기록이 없다면 트래픽이 코어에 들어오는지 중점적으로 점검하고, 기록이 있다면 규칙과 출구를 확인하세요. 다른 프록시 프로그램이 시스템 설정을 반복해서 바꾸고 있지는 않은지도 살펴보세요. 테스트가 끝나면 트래픽을 처리하는 방식을 하나로 정리해 사용하세요.

먼저 일반 브라우저가 같은 프록시를 통해 연결되는지 확인한 다음, 대상 앱이 네트워크 격리의 영향을 받는 UWP 앱인지 살펴보세요. 스토어 앱이 모두 UWP 앱인 것은 아닙니다. 루프백은 앱이 기기 자체 주소에 접속하는 것을 뜻하며 일부 UWP 앱은 기본적으로 제한됩니다. 클라이언트에 루프백 예외 도구가 있다면 안내에 따라 관리자 권한으로 실행하고, 필요한 앱에만 예외를 설정해 저장한 뒤 앱을 다시 시작해 테스트하세요. 시스템 문서의 CheckNetIsolation 명령으로 예외를 관리할 수도 있습니다. 모든 앱의 제한을 일괄 해제하지 마세요. 문제가 해결되지 않으면 앱 자체의 네트워크 권한, 프록시 지원 여부, 로그를 확인하세요.

먼저 TUN과 시스템 프록시를 끄고 클라이언트를 정상 종료한 뒤 일반 인터넷 연결이 복구되는지 확인하세요. 여전히 연결되지 않으면 시스템 프록시에 기기 자체 주소가 남아 있는지, 다른 VPN이 라우팅을 처리하고 있는지 살펴보세요. 처음부터 모든 네트워크 설정을 초기화하지 마세요. 직접 연결이 복구되면 트래픽 처리 방식 하나만 켜고 다시 시도한 뒤 오류가 DNS, 라우팅, 가상 인터페이스 중 무엇을 가리키는지 확인하세요. DNS는 도메인 이름을 IP 주소로 바꾸는 과정이므로 이름 확인에 실패해도 웹페이지가 열리지 않을 수 있습니다. 로그와 기존 설정을 보존하고 최근 변경 사항을 하나씩 되돌리세요. 필요하면 기기를 재시작한 뒤 직접 연결을 다시 확인하세요.