Clash 자주 묻는 질문과 문제 해결

Clash 클라이언트는 일반적으로 그래픽 인터페이스, 설정 관리 모듈과 프록시 코어로 구성됩니다. 그래픽 인터페이스는 구독 가져오기, 정책 선택과 시스템 프록시 전환을 담당하고, 코어는 설정을 해석하고 규칙을 매칭한 뒤 연결을 전달합니다. Mihomo는 Clash 설정 체계를 이어 가는 활발한 코어입니다. 클라이언트마다 통합된 코어 버전이 다를 수 있으므로, 인터페이스가 비슷해도 지원 필드가 완전히 같다는 뜻은 아닙니다.

구독 링크는 설정 내용을 가져오는 네트워크 주소이며, 클라이언트는 이 주소를 통해 설정을 내려받고 업데이트합니다. YAML 설정 파일은 코어가 실제로 읽는 텍스트로, 프록시 노드, 정책 그룹, 규칙과 DNS 등의 필드를 포함합니다. 링크는 주기적으로 업데이트할 수 있지만, 수동으로 가져온 로컬 YAML은 일반적으로 서버 변경 사항을 자동으로 반영하지 않습니다.

일상적인 사용에는 보통 규칙 모드를 선택합니다. 설정에 정의된 규칙에 따라 연결을 프록시로 보낼지 직접 연결할지 결정하기 때문입니다. 글로벌 모드는 가로챌 수 있는 대부분의 연결을 현재 정책 그룹으로 보내므로, 노드가 작동하는지 임시로 테스트할 때 적합합니다. 직접 연결 모드는 프록시를 우회하므로 클라이언트가 네트워크에 미치는 영향을 배제할 때 유용합니다. 점검이 끝나면 실제 필요에 맞는 모드로 돌아가세요.

먼저 Windows, macOS, Android, iOS 또는 Linux 중 해당 플랫폼을 선택한 다음 프로세서 아키텍처와 운영체제 버전을 확인하세요. 데스크톱에서는 계속 유지 관리되고 최신 코어가 통합된 그래픽 클라이언트를 우선 선택하는 것이 좋습니다. 서버나 라우터 환경에서만 Mihomo 코어를 직접 실행하는 방식을 고려하세요. 구형 클라이언트는 기존 설정을 읽는 데 사용할 수 있지만, 새 필드를 인식하지 못할 수 있습니다.

Clash 클라이언트는 설정을 읽고 규칙을 실행하며 연결을 전달할 뿐, 구독 서비스를 제공하지 않습니다. 구독 주소, 노드 상태, 트래픽 한도와 만료일은 해당 서비스 제공업체가 관리합니다. 클라이언트에 구독 오류가 표시되면 로컬 가져오기 문제인지, 네트워크 접속 문제인지, 구독 서비스 자체가 만료된 것인지 구분해야 합니다.

저장 위치는 클라이언트와 운영체제에 따라 다르며, 보통 클라이언트의 설정, Profiles 또는 구독 관리 화면에서 확인할 수 있습니다. 직접 편집해야 한다면 클라이언트가 제공하는 설정 폴더 열기 기능을 우선 사용하세요. 다른 클라이언트의 경로를 기준으로 파일을 덮어쓰면 안 됩니다. 수정하기 전에 자동 업데이트를 중지하고, 작업이 끝나면 설정을 검사한 뒤 다시 불러오세요.

복사한 주소가 완전한지, 시작 부분에 불필요한 공백이 없는지, 끝의 매개변수가 메신저에서 잘리지 않았는지 먼저 확인하세요. 그런 다음 브라우저에서 해당 주소가 여전히 콘텐츠를 반환하는지 확인하고, 반환 내용이 Clash에서 읽을 수 있는 YAML인지 살펴보세요. 로그인 페이지, 오류 메시지 또는 다른 구독 형식이라면 가져올 수 없습니다. 이후 시스템 시간, 네트워크 접속, 클라이언트 코어 호환성과 서비스 제공업체 상태를 점검하세요.

먼저 클라이언트 코어가 실행 중인지 확인하고, 시스템 프록시 스위치가 운영체제 설정에 실제로 적용되었는지 점검하세요. 이어서 HTTP 또는 Mixed 포트가 시스템 프록시 포트와 일치하는지 확인하고, 브라우저에서 별도로 설정한 프록시 확장 기능을 끈 뒤 브라우저를 완전히 다시 시작하세요. 일부 앱은 시스템 프록시를 읽지 않으므로 TUN 모드로 전환하거나 앱 내부에서 프록시를 직접 설정해야 합니다.

TUN 모드는 가상 네트워크 인터페이스를 만들고 라우팅을 설정하며 DNS를 조정해야 하므로 일반적으로 관리자 또는 시스템 수준 권한이 필요합니다. Windows에서는 클라이언트 안내에 따라 서비스를 설치하거나 관리자 권한으로 최초 설정을 완료하세요. macOS에서는 네트워크 확장을 승인해야 하며, Linux에서는 일반적으로 네트워크 관리 권한을 부여해야 합니다. 권한을 승인한 뒤 코어를 다시 시작하고 가상 인터페이스가 생성되었는지 확인하세요.

Microsoft Store 앱이나 구형 UWP 앱만 로컬 프록시에 연결하지 못하고 일반 데스크톱 프로그램은 정상적으로 작동할 때 루프백 제한을 확인하세요. 클라이언트에 내장된 UWP 루프백 도구에서 로컬 프록시에 접근해야 하는 앱을 선택해 저장한 다음 해당 앱을 다시 시작하면 됩니다. 불필요한 네트워크 접근 범위가 넓어질 수 있으므로 모든 항목을 한꺼번에 선택하지 마세요.

자동 업데이트되는 구독 파일에서 규칙을 직접 장기간 수정하지 마세요. 다음 업데이트에서 해당 내용이 덮어써지는 경우가 많습니다. 클라이언트가 제공하는 오버라이드, 병합, 스크립트 또는 로컬 규칙 세트 기능을 사용해 사용자 지정 내용을 원격 구독과 분리해 저장하세요. 업데이트 후에는 정책 그룹 이름이 바뀌었는지 먼저 확인하고, 사용자 지정 규칙이 참조하는 대상 정책이 여전히 존재하는지 점검하세요.

규칙은 위에서 아래 순서로 매칭되며, 일치하면 보통 이후 검사를 중단합니다. 따라서 범위가 더 구체적인 규칙을 일반 규칙보다 앞에 배치해야 합니다. 사용자 지정 도메인, 프로세스 또는 네트워크 대역 규칙은 MATCH 같은 최종 규칙보다 앞에 두고, 설정에 실제로 존재하는 정책 그룹을 가리켜야 합니다. 저장한 뒤 구문 검사를 실행하고, 연결 로그에서 실제로 어떤 규칙이 적용되었는지 확인하세요.

지연 시간 테스트는 보통 테스트 대상까지의 왕복 시간만 보여 주며, 노드의 대역폭, 패킷 손실, 혼잡도와 대상 사이트까지의 라우팅을 완전히 반영하지 못합니다. 같은 네트워크에서 여러 노드를 반복 테스트하고, 웹페이지 로딩, 파일 전송과 실행 로그를 함께 확인하세요. 노드 배율, 프로토콜 호환성, 현재 지역의 라우팅과 서버의 동시 연결 제한 여부도 점검해야 합니다.

먼저 현재 연결이 실제로 Clash에 의해 처리되고 있는지 확인한 다음, 시스템·브라우저·클라이언트가 각각 어떤 DNS를 사용하는지 점검하세요. 브라우저의 보안 DNS가 시스템 설정을 우회할 수 있으며, TUN 모드와 시스템 프록시 모드의 DNS 경로도 다릅니다. 설정을 조정한 뒤 시스템 DNS 캐시를 삭제하고 브라우저를 다시 시작하세요. DNS 해석 로그에서 요청이 Clash의 DNS 모듈로 들어가는지 확인하면 됩니다.

클라이언트에서 로컬 네트워크 연결 허용을 켜고, 수신 주소가 로컬 루프백 주소에만 바인딩되어 있지 않은지 확인하세요. 그런 다음 시스템 방화벽에서 해당 프록시 포트를 허용합니다. 다른 기기의 프록시 서버에는 127.0.0.1이 아니라 Clash를 실행 중인 컴퓨터의 로컬 네트워크 주소를 입력해야 합니다. 신뢰할 수 있는 네트워크에서만 포트를 열고, 제어 인터페이스를 외부 네트워크에 직접 노출하지 마세요.

먼저 구독 업데이트 시간, 만료 상태와 반환 내용을 확인하고, 주소가 로그인 페이지나 오류 페이지로 리디렉션되지 않았는지 살펴보세요. 기존 설정은 작동하지만 업데이트 후 노드가 비어 있다면 기존 파일을 보존한 뒤 구독 서비스 제공업체에 계정과 형식 상태를 문의하세요. 로컬 설정을 계속 덮어쓰지 말고, 현재 사용할 수 있는 설정을 먼저 내보낸 다음 구독이 복구되면 다시 가져오세요.

먼저 직접 연결 모드로 전환해 기본 네트워크가 정상인지 확인하고, 시스템 프록시를 일시 중지한 뒤 코어를 다시 시작하세요. 이후 시스템 시간, 구독 만료 여부, 현재 코어가 노드 프로토콜을 지원하는지, 로컬 방화벽이 클라이언트의 네트워크 접속을 차단하는지 점검합니다. 지연 시간 테스트만 시간 초과되고 웹페이지는 열리는 경우에는 테스트 주소를 바꿔 보세요. 테스트 대상에 접근할 수 없는 것을 모든 노드의 장애로 오해하지 않도록 주의해야 합니다.

먼저 다른 프록시 클라이언트를 종료하고, 작업 관리자나 시스템 프로세스 목록에서 남아 있는 코어가 없는지 확인하세요. 설정의 port, mixed-port, socks-port와 제어 포트가 서로 중복되지 않는지, 다른 프로그램이 해당 포트를 사용하고 있지 않은지도 점검합니다. 포트를 변경했다면 시스템 프록시 설정도 함께 업데이트한 뒤 코어를 다시 시작하고 첫 번째 수신 대기 로그를 확인하세요.

먼저 TUN과 시스템 프록시를 끄고 기본 네트워크가 복구되는지 확인한 다음, 클라이언트를 종료하고 가상 네트워크 어댑터와 라우팅이 남아 있는지 점검하세요. 다시 시작한 뒤 TUN만 켜고, 일단 간소화한 DNS 설정으로 테스트합니다. 문제가 계속되면 관리자 권한, 인터페이스 자동 선택, 기본 라우팅 충돌, 다른 VPN 소프트웨어와 보안 프로그램의 차단 여부를 확인하고, 로그에서 인터페이스 생성 또는 라우팅 설정 실패 기록을 찾으세요.

먼저 남아 있는 클라이언트와 코어 프로세스를 종료한 다음, 정상적으로 해석되는 것으로 확인된 기본 설정으로 시작해 보세요. 업데이트 후 문제가 발생했다면 기존 설정의 폐기된 필드, 손상된 인터페이스 데이터와 시스템 런타임을 확인하세요. 창이 보이지 않을 때는 트레이 영역과 다중 모니터 위치 기록도 점검해야 합니다. 계속 충돌한다면 앱 로그에서 마지막으로 기록된 설정 해석 오류나 권한 오류를 확인하세요.