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

GUI 클라이언트는 구독 가져오기, 메뉴 조작, 시스템 프록시, 로그 표시를 담당하고, 커널은 프로토콜 연결, DNS 처리, 규칙 매칭을 담당합니다. ClashX는 macOS 클라이언트 이름이며, 이름이 같거나 파생된 모든 버전이 mihomo 커널을 사용한다고 볼 수는 없습니다. 호환성 문제를 점검할 때는 먼저 정보 화면이나 시작 로그에서 실제 커널을 확인한 뒤 설정 지원 범위를 살펴보세요. 인터페이스를 바꿔도 커널이 바뀌는 것은 아니며, 커널을 교체해도 기존 클라이언트가 새 기능을 관리할 수 있다고 보장할 수 없습니다.

클라이언트는 연결과 트래픽 분배 기능을 제공하고, 설정 파일에는 노드, 정책 그룹, DNS, 규칙 등의 실제 값이 담깁니다. 설치 파일만 있고 사용할 설정이 없으면 대개 프록시 연결을 만들 수 없습니다. 신뢰할 수 있는 서비스에서 받은 구독 URL을 준비하거나 직접 관리하는 YAML 파일을 가져오세요. 가져온 다음에는 해당 설정을 선택하고 정책 그룹을 확인해야 합니다. 구독 링크에는 계정 접근 정보가 포함될 수 있으므로 공개 게시판이나 스크린샷, 온라인 변환 사이트에 올리지 마세요. 이 사이트의 클라이언트 설치 안내는 노드 서비스가 아닙니다.

일상적인 사용에는 규칙 모드를 선택해 요청이 규칙 목록에 따라 차례로 매칭되도록 하세요. 전역 모드는 보통 커널로 들어온 요청을 전역 정책 그룹으로 보내며, 이 그룹에서 사용할 노드도 선택해야 합니다. 직접 연결 모드에서는 해당 요청이 프록시를 거치지 않고 직접 연결됩니다. 모드는 커널이 이미 받은 요청을 처리하는 방식만 결정하며, 모든 앱이 프록시에 연결된다는 뜻은 아닙니다. 특정 앱의 요청이 연결 목록에 전혀 나타나지 않는다면 모드를 계속 바꾸기보다 시스템 프록시, 앱 자체의 프록시 설정, TUN 연결 여부를 확인하세요.

mixed-port는 클라이언트가 로컬에서 수신 대기하는 HTTP·SOCKS 혼합 포트입니다. 7890은 흔히 쓰이는 예시일 뿐, 모든 설치 환경에서 고정된 값은 아닙니다. 노드 포트는 원격 서버의 포트로, 노드 설정에 따라 정해지므로 두 포트는 서로 바꿔 쓸 수 없습니다. 브라우저나 명령줄 도구에 로컬 프록시를 설정할 때는 클라이언트가 현재 수신 대기 중인 주소와 포트를 사용하세요. 예를 들면 127.0.0.1과 7890입니다. UI 설정이나 오버라이드가 값을 덮어썼다면 실행 중인 포트 화면과 시작 로그를 기준으로 확인하세요.

형식이 호환되고 서버가 계속 작동하는 노드만 연결할 수 있습니다. 무료라고 해서 신뢰할 수 있거나 계속 사용할 수 있는 것은 아닙니다. 공개 구독은 여러 사람이 공유하거나 속도 제한이 걸릴 수 있고, 언제든 폐지될 수 있으며, 현재 커널에서 지원하지 않는 설정이 포함될 수도 있습니다. 가져오기 전에 출처를 확인하고, 계정 구독 정보를 낯선 변환 서비스에 입력하지 마세요. 연결 후에도 웹사이트의 HTTPS 인증서 검증을 유지해야 합니다. 특정 노드를 쓰려고 출처가 불분명한 루트 인증서를 설치하지 말고, 클라이언트 설치 성공을 노드 품질의 증거로 여기지 마세요.

클라이언트의 설정 또는 구독 페이지에서 URL 가져오기를 선택하고 전체 주소를 붙여 넣은 뒤 저장하세요. 로컬 파일은 파일 가져오기 메뉴를 사용하면 됩니다. 메뉴 이름은 클라이언트마다 다르며, ClashX에서는 메뉴 막대의 설정 메뉴에서 설정을 관리할 수 있습니다. 다운로드가 끝나면 해당 설정을 선택하고 정책 그룹에 노드가 포함되어 있는지 확인한 뒤 시스템 프록시를 켜고 잘 알려진 사이트에 접속해 보세요. 다운로드 기록만 있고 노드가 없다면 실제로 선택된 설정과 응답 형식을 먼저 확인하세요. 바로 포트를 바꾸거나 TUN을 켤 필요는 없습니다.

먼저 로그에서 오류가 난 줄 번호와 오류 유형을 확인하고, 해당 줄과 앞뒤 몇 줄의 들여쓰기, 콜론, 목록 기호를 살펴보세요. YAML 들여쓰기에는 공백을 사용하고 탭은 넣지 마세요. 특수 문자가 포함된 문자열은 적절히 따옴표로 감싸야 합니다. 응답 첫 부분에 웹페이지 태그, 로그인 안내, 접근 거부 메시지가 보인다면 설정 파일이 아닌 내용을 받은 것이므로 들여쓰기를 고쳐도 해결되지 않습니다. 수정 전 원본을 보관하고 한 번에 한 곳만 바꾼 뒤 다시 불러오세요. 구독에서 출력된 설정 형식이 현재 커널에서 지원되는지도 확인해야 합니다.

먼저 현재 클라이언트가 TUN을 지원하는지 확인한 뒤 설정 화면의 안내에 따라 서비스 구성 요소를 설치하거나 복구하세요. Windows 클라이언트는 보통 관리자 권한으로 서비스를 설치해야 하며, macOS에서는 보조 구성 요소를 승인해야 할 수 있습니다. Linux에서는 네트워크 관리 권한이 필요할 수 있습니다. 모든 파일의 권한을 무작정 완화하지 마세요. 권한을 승인한 다음 로그에서 가상 네트워크 어댑터 생성과 라우팅 설정이 성공했는지 확인하세요. 그래도 실패하면 다른 VPN이나 TUN 클라이언트를 먼저 종료하고, 로그에 기록된 구체적인 오류를 바탕으로 계속 점검하세요.

시작 프로그램 등록은 대개 클라이언트를 실행한다는 뜻일 뿐, 시스템 프록시나 TUN을 자동으로 켠다는 의미는 아닙니다. 로그인 시 실행, 실행 후 프록시 활성화, 서비스 모드, 설정 선택 상태를 각각 확인하세요. Windows에서는 작업 관리자의 시작 앱을, macOS에서는 시스템 설정의 로그인 항목과 확장 프로그램을 확인할 수 있습니다. 처음 실행할 때 네트워크가 준비되지 않아 구독 업데이트에 실패할 수 있으므로 로컬에서 사용할 수 있는 설정을 보관해 두고, 네트워크가 복구된 뒤 직접 업데이트하세요. 실행할 때마다 설정을 새로 내려받는 방식에 의존하지 마세요.

구독 URL, 직접 만든 노드, 호환성을 확인한 규칙을 우선 옮기고, 앱 데이터 디렉터리 전체를 그대로 복사하지 마세요. 시스템 프록시 상태, 서비스 구성 요소, TUN 네트워크 어댑터, UI 오버라이드는 클라이언트에 종속되는 경우가 많아 YAML 복사만으로 이전할 수 없습니다. 기존 클라이언트와 시스템 프록시를 먼저 끈 다음 새 클라이언트에서 설정을 가져오고, 포트와 정책 그룹 이름을 확인한 뒤 연결을 테스트하세요. 새 환경이 안정적으로 작동하는 것을 확인한 뒤 기존 데이터를 정리하세요. 두 클라이언트가 동시에 라우팅을 변경하거나 같은 포트를 놓고 충돌하지 않도록 주의해야 합니다.

규칙은 위에서 아래 순서로 매칭됩니다. 사용자 지정 규칙은 먼저 적용될 수 있는 포괄적인 규칙이나 MATCH보다 위에 배치해야 합니다. 예를 들어 DOMAIN-SUFFIX,example.com,DIRECT는 해당 도메인과 하위 도메인을 직접 연결한다는 뜻입니다. 대상 정책은 내장 정책이거나 이미 존재하는 정책 그룹이어야 하며, 대소문자도 확인하세요. 클라이언트의 오버라이드 또는 영구 규칙 기능을 우선 사용하세요. 원격 구독에서 생성된 파일을 직접 수정하면 다음 업데이트 때 변경 내용이 사라질 수 있습니다. 저장한 뒤 다시 불러오고, 연결 세부 정보에서 어떤 규칙이 적용됐는지 확인하세요.

먼저 기기들이 서로 통신할 수 있는 신뢰할 만한 로컬 네트워크에 연결되어 있어야 합니다. 컴퓨터 클라이언트에서 로컬 네트워크 연결 허용을 켜고, 다른 기기에서 접속할 수 있도록 수신 주소가 설정되어 있는지 확인하세요. 그런 다음 휴대폰이나 TV의 프록시 설정에 컴퓨터의 로컬 네트워크 IP와 실제 혼합 포트를 입력하세요. 127.0.0.1을 입력하면 안 됩니다. 컴퓨터 방화벽에서는 필요한 로컬 네트워크 대역에만 해당 포트를 허용하고, 공용 네트워크에는 열지 마세요. 기기가 프록시를 사용할지는 앱의 구현에 따라 다르며, 수동 HTTP 프록시로 모든 UDP 요청을 처리할 수 있는 것은 아닙니다.

많은 명령줄 도구는 데스크톱의 시스템 프록시 설정을 읽지 않으므로 프록시 옵션이나 환경 변수를 별도로 설정해야 합니다. 예를 들어 curl에서 curl -x http://127.0.0.1:7890 https://example.com을 실행해 프록시를 명시적으로 테스트할 수 있습니다. 포트는 클라이언트의 실제 값으로 바꾸세요. 테스트가 성공하면 해당 도구가 HTTP_PROXY, HTTPS_PROXY 또는 ALL_PROXY를 지원하는지 확인하세요. 환경 변수는 이를 읽는 프로세스에만 적용되므로 이미 실행 중인 터미널이나 백그라운드 서비스는 재시작해야 할 수 있습니다. 테스트 설정을 정리할 때는 해당 변수도 함께 제거하세요.

AppContainer 격리 환경에서 실행되는 일부 앱은 로컬 루프백 프록시에 직접 접근하지 못합니다. 먼저 브라우저가 같은 포트로 연결되는지 확인한 뒤, 클라이언트에서 제공하는 UWP 루프백 도구를 사용해 필요한 앱에만 루프백 예외를 설정하세요. 도구 실행에 관리자 권한이 필요할 수 있습니다. 클라이언트에 해당 기능이 없다면 Windows의 CheckNetIsolation 도구로 앱 패키지의 예외 상태를 확인할 수 있습니다. 모든 앱에 일괄적으로 허용하지 마세요. 실제 원인이 DNS, 앱 로그인, 방화벽이라면 루프백 예외로는 해결되지 않습니다.

서비스 제공자가 관리하는 노드와 로컬에서 계속 사용할 설정을 분리해 관리하세요. 클라이언트가 오버라이드, 설정 병합 또는 스크립트 처리를 지원한다면 mixed-port, DNS, 사용자 지정 규칙을 해당 영구 설정 기능에 넣고 최종 실행 설정을 확인하세요. 클라이언트마다 병합 순서와 배열 처리 방식이 다르므로 규칙이 자동으로 추가된다고 가정하면 안 됩니다. 처음 설정한 뒤 구독을 직접 업데이트해 노드는 갱신되고 로컬 변경 사항은 유지되는지 확인하세요. 클라이언트에서 설정을 보존할 수 없다면 별도 설정을 백업하고 관리 방법을 정해 두세요.

먼저 설정 페이지에서 어느 구독이 실패했는지 확인하고 로그의 상태 코드를 살펴보세요. 401 또는 403은 인증, 만료, 접근 정책과 관련될 수 있고, 404는 주소가 변경됐을 가능성이 있지만 상태 코드만으로 원인을 단정할 수는 없습니다. 링크가 온전한지, 계정이 유효한지, 응답이 호환되는 설정 형식인지 확인하세요. 업데이트 경로가 현재 프록시에 의존할 수도 있으니 클라이언트에서 제공하는 직접 연결 업데이트를 시도해 보세요. 특정 구독만 실패한다면 제공자에게 문의하고, 모든 구독이 실패한다면 로컬 네트워크, DNS, 시스템 시간을 먼저 확인하세요.

시간 초과는 현재 테스트가 제한 시간 안에 끝나지 않았다는 뜻일 뿐입니다. 로컬 네트워크, DNS, 테스트 주소, 프로토콜 설정, 서버 상태가 원인일 수 있습니다. 먼저 같은 구독의 다른 노드로 바꿔 보고, 네트워크도 바꿔 테스트하세요. 테스트 URL에 해당 노드로 접속할 수 있는지도 확인해야 합니다. 지연 시간 테스트는 실패해도 실제 웹페이지가 열린다면 테스트 주소 설정을 확인하세요. 모든 노드와 직접 연결이 모두 실패한다면 기본 네트워크부터 복구하세요. 로그에 인증 실패가 표시되면 구독과 인증 정보를 확인하고, 연결 시간 초과가 표시될 때는 서버 접근성을 확인하세요. 두 오류를 같은 문제로 취급하지 마세요.

먼저 클라이언트 연결 목록에 해당 브라우저의 요청이 나타나는지 확인하세요. 요청이 없다면 시스템 프록시 주소와 실제 수신 포트가 일치하는지 살펴보고, 시스템 설정을 덮어쓰는 브라우저 프록시 확장 프로그램을 끄세요. 요청이 나타나는데도 직접 연결된다면 적용된 규칙과 대상 정책을 확인해 DIRECT로 설정되어 있지 않은지 살펴보세요. 브라우저가 사용하는 HTTP 프록시와 프록시에 연결되지 않은 다른 트래픽도 구분해야 합니다. 프록시를 명시하는 명령으로 로컬 포트가 작동하는지 테스트할 수 있습니다. 포트에 연결할 수 없다면 커널 시작 실패나 포트 충돌부터 해결하세요.

먼저 TUN을 끄고 기본 네트워크가 복구되는지 확인한 뒤 하나씩 점검하세요. 라우팅 설정을 계속 추가로 변경하지 마세요. 오류 로그를 보관하고, 다른 VPN이나 가상 네트워크 어댑터, 보안 소프트웨어가 동시에 네트워크를 제어하는지 확인한 다음 DNS와 자동 라우팅 설정을 살펴보세요. IP 주소에는 연결되지만 도메인 이름이 해석되지 않는다면 DNS 수신 설정, 상위 DNS 서버 접근성, 라우팅 루프를 집중적으로 확인하세요. 필요하면 클라이언트를 정상 종료한 뒤 네트워크에 다시 연결하세요. 그래도 복구되지 않으면 기기를 재시작하세요. 기업에서 관리하는 기기라면 시스템 네트워크 어댑터를 임의로 삭제하지 말고 관리자 정책을 따르세요.

종료 후 인터넷이 끊겼다면 시스템에 로컬 주소를 가리키는 프록시 설정이 남아 있는지 확인하고, 남은 프록시를 끈 뒤 터미널 환경 변수와 브라우저 확장 프로그램도 점검하세요. 인증서 경고는 별개의 문제입니다. 시스템 날짜와 시간을 맞춘 다음 인증서 발급자와 접속 도메인을 확인하고, HTTPS 검사나 MITM 설정이 있는지 살펴보세요. 경고를 무시하거나 출처가 불분명한 루트 인증서를 설치하지 마세요. 특정 노드에서만 경고가 발생하면 해당 노드 사용을 중단하고 서비스 제공자에게 알리세요. 직접 연결에서도 같은 오류가 난다면 기기나 웹사이트 자체를 추가로 확인해야 합니다.