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

Clash는 프록시 코어와 관련 설정 생태계를 통칭하는 이름으로 흔히 사용됩니다. mihomo는 이 생태계에서 계속 개발되고 있는 코어이며, 초기에는 Clash Meta라고도 불렸습니다. Clash Verge Rev는 설정 관리, 프록시 전환, 시스템 설정 기능을 제공하는 데스크톱 클라이언트입니다. 클라이언트 인터페이스와 실제 코어는 서로 다른 계층입니다. 특정 YAML 필드를 사용할 수 있는지는 클라이언트에 포함된 코어와 버전에 따라 달라집니다. 문제를 해결할 때는 먼저 정보 페이지에서 클라이언트 이름을 확인하고, 코어 정보나 시작 로그에서 코어를 확인하세요. 다른 클라이언트의 메뉴 위치를 그대로 적용하지 않도록 주의해야 합니다.

클라이언트는 설정을 읽고 트래픽을 전달하지만, 설치만으로 사용할 수 있는 프록시 서비스가 생기지는 않습니다. 구독 링크는 보통 서비스 제공자가 제공하며, 노드와 정책 그룹, 규칙 등의 설정을 가져오는 데 사용됩니다. 서비스 제공자의 구독 페이지에서 Clash 또는 mihomo와 호환되는 설정 링크를 선택한 다음, 클라이언트 설정 페이지에서 원격 설정을 추가하세요. 계정 로그인 페이지 주소를 구독 주소로 사용하지 말고, 구독 링크를 공개 게시판에 올리지 마세요. 링크에 포함된 인증 정보로 다른 사람이 설정을 읽을 수 있습니다. 로컬 설정 파일만 있다면 파일 가져오기를 이용할 수도 있습니다.

평소에는 규칙 모드를 선택해 불러온 설정의 규칙에 따라 트래픽이 처리되도록 하세요. 전역 모드는 일반적으로 코어에 들어온 연결을 전역 정책으로 처리하지만, 모든 앱의 트래픽을 가로챈다는 뜻은 아닙니다. 시스템 프록시나 TUN이 제대로 작동하는지도 확인해야 합니다. 직접 연결 모드는 코어에 들어온 트래픽을 대상에 바로 연결하므로 연결 상태를 잠시 비교할 때 유용합니다. 테스트할 때는 모드만 하나씩 바꾸고 DNS나 노드는 동시에 변경하지 마세요. 특정 사이트만 전역 모드에서 열린다면 전역 모드를 계속 사용해 설정 문제를 덮기보다 규칙 매칭과 정책 그룹 선택을 먼저 확인하세요.

시스템 프록시는 운영체제 설정에 프록시 주소를 등록해 해당 설정을 따르는 앱에 적용합니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 조건에 맞는 트래픽을 처리하며, 보통 추가 권한이 필요합니다. 연결을 위해 두 기능을 모두 켤 필요는 없습니다. 먼저 시스템 프록시만으로 브라우저 연결을 확인한 다음, 게임이나 명령줄 도구 등 다른 앱의 필요에 따라 TUN을 테스트하세요. 일부 클라이언트에서는 두 기능을 함께 사용할 수 있지만, 적용 범위는 라우팅과 제외 설정에도 영향을 받습니다. TUN을 켠 뒤 문제가 생기면 먼저 TUN을 끄고 비교해 라우팅 처리와 프록시 서비스 중 어느 쪽이 원인인지 확인하세요.

먼저 설정 페이지에서 방금 가져온 설정이 목록에 저장만 된 것이 아니라 현재 설정으로 지정되어 있는지 확인하세요. 그런 다음 업데이트 기록과 코어 로그를 살펴 다운로드 성공 여부와 YAML 파싱 상태를 확인합니다. 일부 설정은 proxy-providers를 이용해 노드를 별도로 가져옵니다. 기본 설정이 정상적으로 로드되어도 노드 제공자까지 업데이트된 것은 아니므로 제공자 페이지에서 다시 확인해야 합니다. 서비스 제공자가 로그인 페이지나 오류 메시지, 클라이언트가 지원하지 않는 형식으로 응답한다면 호환되는 링크를 다시 받아오세요. 같은 이름의 설정을 반복해서 새로 만들기보다 비교할 설정 하나를 남겨 두세요.

먼저 서비스 제공자 계정 페이지에서 구독 만료 여부, 데이터 사용량 초과 여부, 링크 초기화 여부를 확인하세요. 401은 보통 인증 문제를, 403은 접근 거부를 뜻하지만 정확한 원인은 서비스 제공자의 안내를 확인해야 합니다. 구독 주소 전체를 다시 복사하고 실수로 들어간 공백이나 줄바꿈을 제거한 뒤, 기존 설정에서 링크를 바꾸고 수동으로 업데이트하세요. 다른 네트워크에서는 링크가 작동한다면 현재 네트워크가 요청을 차단하는지 확인합니다. 문의할 때는 오류 코드와 민감 정보를 가린 로그만 첨부하고 구독 주소 전체는 공유하지 마세요. 업데이트 버튼을 반복해서 눌러도 서버의 접근 제한이 풀리지는 않습니다.

먼저 일반 시스템 프록시로 연결되는지 확인한 다음 TUN 권한 문제를 점검하세요. 데스크톱 클라이언트는 서비스 모드를 설치하거나 시작해야 하는 경우가 많습니다. Windows에서는 클라이언트 설정에서 서비스 상태를 확인하고 안내에 따라 권한을 허용하세요. macOS에서는 해당 시스템 권한을 승인해야 합니다. Linux에서는 클라이언트 문서에 따라 서비스나 필요한 권한을 설정하고, 디렉터리 전체에 함부로 쓰기 권한을 부여하지 마세요. 권한을 허용한 뒤 클라이언트를 다시 시작하고, 로그에 장치 생성, 라우팅 설정, 인터페이스 접근 실패가 남는지 확인합니다. 관리 대상 업무용 기기라면 시스템 제한을 우회하려 하지 말고 관리자에게 권한 정책을 문의하세요.

AppContainer 격리를 사용하는 일부 Windows 앱은 기본적으로 로컬 루프백 주소에 접근할 수 없습니다. 브라우저에서는 연결되지만 스토어 앱에서는 실패한다면 루프백 제한을 확인해 보세요. 클라이언트에 UWP 루프백 도구가 있다면 관리자 권한으로 실행하고, 로컬 프록시에 접근해야 하는 앱만 선택하세요. 저장한 뒤 해당 앱을 완전히 종료하고 다시 실행합니다. 클라이언트마다 메뉴 이름이 다를 수 있으며, 도구가 없다면 Windows 루프백 제외 설정 안내를 확인하세요. 필요한 앱에만 권한을 부여하고 모두 선택하지 마세요. 루프백 제외 설정으로 구독 만료, 원격 노드 장애, 앱 자체의 네트워크 제한을 해결할 수는 없습니다.

먼저 서비스 제공자가 권장하는 업데이트 간격을 따르세요. 별도 안내가 없다면 하루 한 번부터 시작해 구독 요청을 지나치게 자주 보내지 않는 것이 좋습니다. 원격 설정을 업데이트하면 원격 YAML에서 직접 수정한 내용이 덮어써질 수 있으므로, 사용자 지정 규칙과 DNS, 정책 설정은 클라이언트에서 지원하는 오버라이드나 병합 설정에 넣는 편이 좋습니다. 설정한 뒤 한 번 수동으로 업데이트하고 최종 적용 설정에서 변경 사항이 유지되는지 확인하세요. 클라이언트마다 병합 순서와 배열 처리 방식이 다르므로 클라이언트를 바꿀 때 다시 점검해야 합니다. 오버라이드 파일만 복사하면 결과가 같을 것이라고 단정하지 마세요.

각 설정에 용도나 서비스 제공자에 따라 구분하기 쉬운 이름을 지정하고 기본 이름을 그대로 두지 마세요. 전환할 때는 설정 페이지에서 원하는 설정을 현재 설정으로 지정한 뒤, 프록시 페이지에서 정책 그룹과 선택 가능한 노드도 바뀌었는지 확인합니다. 전환 직후에는 기존 연결이 이전 경로를 계속 사용할 수 있습니다. 테스트 전에 대상 앱을 닫았다가 다시 열거나 클라이언트의 연결 관리 기능으로 관련 연결을 종료하세요. 새 설정이 작동하는 것을 확인한 뒤 이전 설정을 삭제하고, 삭제 전에는 필요한 로컬 규칙을 저장하세요. 원격 구독과 로컬 오버라이드가 별도로 저장되는지도 확인해야 합니다.

클라이언트에서 연결 페이지를 열고 대상 사이트에 다시 접속한 다음, 도메인이나 대상 주소로 새 연결을 찾아 적용된 규칙과 정책 그룹, 최종 아웃바운드를 확인하세요. 기존 연결은 규칙이 다시 적용되지 않을 수 있으므로 테스트 전에 이전 페이지를 닫거나 해당 연결을 종료해야 합니다. 화면에 IP 주소만 표시된다면 로그에서 DNS 조회가 이뤄졌는지, 규칙이 도메인 정보에 의존하는지 확인하세요. 트래픽이 기본 규칙에 매칭된다면 대상 규칙이 기본 규칙보다 앞에 있는지, 규칙 세트가 정상적으로 로드됐는지 점검합니다. 프록시 페이지에서 특정 노드를 선택했다는 이유만으로 모든 사이트가 그 노드를 사용한다고 판단하지 마세요.

운영체제와 클라이언트 이름, 클라이언트 및 코어 버전, 문제 발생 당시의 모드와 시스템 프록시·TUN 상태를 알려주세요. 어떤 유형의 앱을 열었을 때 어떤 오류가 발생하는지 재현 가능한 단계로 설명하고, 같은 네트워크에서 다른 앱은 정상인지도 덧붙이세요. 실패한 작업 전후의 로그만 발췌해 오류 코드와 필요한 맥락을 남기면 됩니다. 공개하기 전에 구독 주소 전체, 인증 정보, 노드 비밀번호, 개인 계정 정보, 불필요한 공인 IP 주소를 가리세요. 설정 파일 전체를 공개 업로드하지 말고 관련 필드만 추려 민감한 값을 바꾸세요. 문제를 파악하는 데 필요한 정보는 제공하면서 노출은 줄일 수 있습니다.

먼저 프록시를 끄고 기본 네트워크가 연결되는지 확인한 뒤, 기기의 날짜와 시간이 올바른지 점검하세요. 이어 구독 상태와 설정 업데이트 결과를 확인합니다. 정상 작동을 확인한 노드 하나를 골라 테스트하고, 로그에서 도메인 조회 실패인지, 연결 거부인지, 핸드셰이크 실패인지 살펴보세요. 테스트 주소에 접속할 수 없어도 속도 측정이 시간 초과될 수 있으므로 실제 접속 결과와 함께 판단해야 합니다. 모든 노드가 동시에 실패하면 DNS와 네트워크 제한, 로컬 설정을 우선 점검하세요. 노드 하나만 실패한다면 다른 노드로 전환하고 서비스 제공자에게 문의합니다. 한 번에 설정 하나만 바꾸고 변경 사항을 기록해 포트, DNS, 라우팅을 동시에 바꾸다가 원인을 놓치지 않도록 하세요.

먼저 클라이언트 코어가 실행 중인지 확인한 다음, 시스템 프록시의 호스트와 포트가 클라이언트의 현재 수신 주소 및 혼합 포트와 일치하는지 점검하세요. 스위치가 켜져 있다는 것만으로 설정이 올바르다고 볼 수 없습니다. 다른 프록시 클라이언트와 프록시 설정을 바꿀 수 있는 브라우저 확장 프로그램을 끈 뒤 브라우저를 다시 시작해 테스트하세요. Firefox 같은 앱은 자체 네트워크 설정을 사용할 수 있으므로 시스템 프록시를 선택하거나 올바른 로컬 프록시를 입력해야 합니다. 연결 페이지에 새 기록이 전혀 없다면 앱과 클라이언트 사이에서 문제가 발생했을 가능성이 큽니다. 연결 기록이 있다면 규칙 매칭과 정책 선택, 노드 상태를 이어서 확인하세요.

먼저 TUN을 끄고 비교해 기본 네트워크와 시스템 프록시가 정상인지 확인한 다음, 로그에서 DNS 시간 초과와 조회 실패, 라우팅 오류를 살펴보세요. 설정의 DNS 서비스가 켜져 있는지, 업스트림 주소에 의도한 경로로 접근할 수 있는지, TUN의 DNS 하이재킹 설정이 현재 코어와 호환되는지 확인합니다. fake-ip가 합성 주소를 반환하는 것은 정상적인 동작이며 설정이 손상됐다는 뜻이 아닙니다. 조회 모드나 필터 규칙을 바꾼 뒤에는 클라이언트와 시스템의 DNS 캐시를 비우고 연결을 새로 만드세요. 일부 앱에서만 문제가 생긴다면 먼저 해당 도메인에 fake-ip 필터를 설정해 보세요. 출처를 알 수 없는 DNS 설정 전체를 그대로 복사하지 마세요.

포트 충돌이 발생하면 다른 프록시 클라이언트를 종료하고 이전 코어 프로세스가 백그라운드에 남아 있는지 확인하세요. 운영체제의 네트워크 연결 또는 프로세스 도구로 포트를 점유한 항목을 확인하고, 정체를 모르는 시스템 프로세스를 바로 종료하지 마세요. 혼합 포트를 바꿔야 한다면 해당 포트를 직접 입력한 앱의 설정도 함께 변경합니다. 클라이언트 종료 후 인터넷이 끊긴다면 시스템 네트워크 설정에 로컬 주소를 가리키는 수동 프록시가 남아 있는지 확인하고, 해당 설정을 끈 뒤 다시 테스트하세요. 문제가 계속되면 TUN 서비스와 라우팅이 복구됐는지 확인하고 필요하다면 정상 절차에 따라 기기를 다시 시작합니다. 다음에는 종료 전에 트래픽 가로채기 기능을 먼저 끄면 프로세스를 강제 종료한 뒤 네트워크 설정이 남는 일을 줄일 수 있습니다.