Clash 자주 묻는 질문

Clash는 보통 프록시 도구 생태계를 가리키며, 초기 코어 프로젝트를 뜻하기도 합니다. mihomo는 Clash Meta에서 발전한 코어로, 설정을 해석하고 DNS를 처리하며 규칙을 매칭해 아웃바운드 연결을 설정합니다. 클라이언트는 구독 관리, 정책 선택, 시스템 프록시 설정 등의 인터페이스를 제공합니다. 문제를 해결할 때는 Clash를 설치했다고만 하지 말고 클라이언트 이름과 코어 정보를 각각 기록하세요. 화면이 같더라도 사용하는 코어는 다를 수 있습니다. 설정 항목의 지원 여부는 실제 실행 중인 코어의 문서와 시작 로그를 기준으로 확인해야 합니다.

클라이언트는 연결을 관리하고 트래픽을 분기하는 도구입니다. 설치만으로 사용할 수 있는 프록시 아웃바운드가 준비되는 것은 아닙니다. 일반적으로 유효한 구독 링크를 준비하거나 사용 권한이 있는 노드 정보를 직접 입력해야 합니다. 구독에는 노드, 프록시 그룹, 규칙이 포함될 수도 있고 노드 목록만 제공될 수도 있으므로 가져오기 전에 서비스 제공자가 안내한 형식을 확인하세요. 구독 주소의 액세스 토큰은 비밀번호처럼 안전하게 관리해야 합니다. 스크린샷이나 로그를 공유하거나 온라인 변환 서비스를 이용할 때는 링크 전체를 가리세요. 이 사이트는 클라이언트 다운로드와 설정 안내를 제공하지만 구독을 발급하거나 서비스 제공자가 비활성화한 계정을 복구하지는 않습니다.

일상적으로는 규칙 모드부터 사용하는 것이 좋습니다. 연결은 rules 순서대로 매칭되며, 처음 일치하는 규칙이 아웃바운드 정책을 결정합니다. 전역 모드는 보통 코어에 들어온 연결을 하나의 전역 정책으로 보내므로 짧은 비교 테스트에 적합합니다. 직접 연결 모드에서는 해당 연결이 프록시를 거치지 않고 직접 접속을 시도합니다. 여기서 전역은 아웃바운드 결정 방식을 뜻하며, 모든 앱의 트래픽이 자동으로 클라이언트에 들어온다는 의미는 아닙니다. 앱 트래픽이 처리되는지는 시스템 프록시, 앱별 프록시 설정 또는 TUN에 따라 달라집니다. 모드를 바꾼 뒤에는 새 연결로 테스트하세요. 이미 연결된 장시간 세션은 기존 아웃바운드를 계속 사용할 수 있습니다.

새로 설치한다면 먼저 Clash Plus를 살펴보고 Clash Verge Rev, FlClash 등의 시스템 지원 범위와 사용 방법을 비교해 보세요. 특정 기능이 필요하다면 오래된 튜토리얼의 이름만 보고 선택하지 말고 최신 릴리스 노트를 확인해야 합니다. 이전하기 전에 구독 주소, 직접 추가한 규칙과 필요한 설정을 백업한 다음 새 클라이언트에서 구성을 다시 가져오세요. 이전 클라이언트의 데이터베이스, 서비스 구성 요소와 화면 설정은 그대로 복사되지 않을 수 있습니다. 이전하는 동안 시스템 프록시나 TUN을 제어하는 클라이언트는 한 번에 하나만 유지하세요. 새 설정이 정상 작동하는 것을 확인한 뒤 이전 서비스를 정리하면 됩니다.

먼저 시스템 정보에서 운영체제 버전과 프로세서 아키텍처를 확인한 뒤 다운로드 항목의 지원 안내를 살펴보세요. Windows의 x64와 ARM64, macOS의 Intel과 Apple Silicon, Android의 arm64와 arm은 기기 외관만으로 구분할 수 없습니다. Linux에서는 배포판의 패키지 형식과 실행에 필요한 종속성도 확인해야 합니다. 설치 프로그램에서 호환되지 않는다고 표시되면 먼저 이 조건을 점검하세요. 파일 확장자를 임의로 바꿔 설치를 시도하지 마세요. 최소 시스템 요구 사항은 해당 클라이언트의 최신 릴리스 노트를 기준으로 확인해야 합니다. 구형 시스템에서는 프로그램이 실행되더라도 시스템 프록시나 가상 네트워크 어댑터에 필요한 구성 요소가 없을 수 있습니다.

먼저 다운로드 실패와 콘텐츠 해석 실패를 구분하세요. 다운로드가 실패한다면 구독 만료 여부와 토큰 재설정 여부, 업데이트 요청이 직접 연결인지 프록시 연결인지 확인합니다. 프록시를 아직 사용할 수 없다면 클라이언트가 허용하는 경우 직접 연결로 업데이트해 보세요. 다운로드는 성공했지만 노드가 없다면 로그인 페이지나 오류 메시지가 반환됐는지, 형식이 호환되는지 확인하고 구독이 전체 설정을 제공하는지 또는 프록시 목록만 제공하는지도 살펴보세요. 비공개 구독 링크를 공개 변환 사이트에 입력하지 마세요. 주소가 올바른데도 접근 거부나 계정 오류가 발생한다면 구독 서비스 제공자에게 문의해야 합니다. 클라이언트를 반복해서 재설치해도 대개 해결되지 않습니다.

원격 구독을 업데이트하면 설정 파일 전체가 다시 생성될 수 있어 생성된 파일을 직접 편집한 내용은 덮어쓰기됩니다. 먼저 클라이언트가 실제로 불러오는 파일을 확인한 뒤, 해당 클라이언트가 지원하는 오버라이드·병합·설정 확장 기능으로 변경 사항을 저장하세요. 규칙 배열은 통째로 교체되거나 지정한 위치에 삽입될 수 있으며, 동작은 클라이언트 구현에 따라 다릅니다. 새 규칙은 존재하는 프록시 그룹을 참조해야 합니다. 수정한 뒤에는 편집기의 원본 일부만 보지 말고 최종 적용 설정과 코어 로그를 확인하세요. 원본 설정을 백업하고 한 번에 한 종류의 항목만 수정한 다음 구독을 업데이트해 변경 사항이 유지되는지 확인하는 것이 좋습니다.

TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 변경할 수 있어 보통 클라이언트 서비스 구성 요소나 시스템 권한이 필요합니다. 현재 클라이언트 안내에 따라 서비스를 설치하고 실행한 뒤 시스템에 표시되는 네트워크 확장 프로그램, VPN 또는 관리자 권한 요청을 승인했는지 확인하세요. Linux에서는 TUN 장치와 프로세스에 필요한 권한도 점검해야 합니다. 오류를 없애려고 방화벽을 계속 끄거나 모든 파일의 권한을 과도하게 넓히지 마세요. 권한을 부여한 뒤에도 실패한다면 로그에 처음 나타난 오류를 확인하고 다른 VPN이 라우팅을 제어하고 있지 않은지 살펴보세요. TUN은 트래픽이 코어에 들어가는 방식을 정할 뿐이므로, 켠 뒤에도 사용 가능한 노드와 올바른 규칙이 필요합니다.

프록시 그룹 선택은 최종적으로 해당 그룹을 가리키는 연결에만 적용되며 모든 규칙을 자동으로 덮어쓰지는 않습니다. 먼저 연결 패널에서 대상 연결이 코어에 들어왔는지 확인한 다음 매칭된 규칙과 최종 아웃바운드를 살펴보세요. 규칙이 DIRECT를 가리킨다면 다른 프록시 그룹을 바꿔도 결과는 달라지지 않습니다. 규칙은 보통 위에서 아래로 매칭되므로 앞쪽의 포괄적인 규칙이 뒤쪽의 구체적인 규칙보다 먼저 적용될 수 있습니다. 중첩된 프록시 그룹이 다른 그룹을 가리키는지, 앱이 시스템 프록시를 우회하는지도 확인하세요. 설정을 바꾼 뒤에는 기존 연결을 닫고 다시 시도하세요. 노드를 연이어 바꾸는 것보다 어느 설정이 영향을 주는지 파악하기 쉽습니다.

사용자 지정 규칙은 앞에서 먼저 매칭될 수 있는 포괄적인 규칙보다 앞에 두고, 클라이언트의 영구 오버라이드 기능을 통해 설정에 추가하는 것이 일반적입니다. DOMAIN은 특정 도메인을 매칭하고 DOMAIN-SUFFIX는 도메인 접미사를 기준으로 매칭합니다. 둘 다 전체 URL이 아닌 도메인을 입력해야 하며 프로토콜, 경로, 쿼리 매개변수는 포함하지 않습니다. 규칙 끝의 정책 이름은 기존 노드, 프록시 그룹 또는 내장 정책과 일치해야 합니다. MATCH는 다른 조건에 해당하지 않는 연결에 적용되는 최종 규칙이므로 보통 규칙 목록 맨 아래에 둡니다. 너무 앞에 배치하면 뒤에 있는 규칙은 매칭될 기회를 얻지 못합니다. 저장한 뒤 새 연결을 만들어 매칭 기록을 확인하고 규칙이 로드되어 실제로 적용됐는지 점검하세요.

Fake-IP 모드에서는 앱에 예약 주소 대역의 매핑 주소를 반환하고, 코어가 해당 주소와 도메인의 대응 관계를 저장한 뒤 도메인을 기준으로 실제 연결을 처리합니다. 웹사이트의 권한 DNS에 등록된 실제 레코드를 변경하는 것은 아닙니다. 일부 로컬 네트워크 기기 검색, 장치 제어 또는 실제 DNS 응답에 직접 의존하는 앱은 fake-ip-filter에 추가해야 할 수 있습니다. 필터 항목은 이름 해석 방식에만 영향을 주며 해당 도메인의 접속 정책을 직접 연결로 바꾸지는 않습니다. 호환성 문제가 생기면 먼저 특정 도메인으로 범위를 좁히고 필요한 항목만 필터링한 다음 관련 DNS 캐시를 지우고 연결을 다시 만드세요. 모든 도메인을 한꺼번에 필터링하면 실제 원인을 찾기 어려워질 수 있습니다.

AppContainer 격리 환경에서 실행되는 일부 Windows 앱은 로컬 루프백 주소에 직접 접근할 수 없습니다. 로컬 프록시는 보통 루프백 주소에서 연결을 수신하므로 브라우저는 작동해도 해당 앱의 연결은 실패할 수 있습니다. 먼저 대상 앱이 실제로 이 제한을 받는지 확인한 다음 클라이언트의 UWP 루프백 도구나 Windows의 CheckNetIsolation 도구를 사용해 필요한 앱에만 루프백 예외를 추가하세요. 관리자 권한이 필요할 수 있으며 설정을 마친 뒤 대상 앱을 다시 시작해야 합니다. 스토어 앱이 모두 UWP인 것은 아니며 모든 연결 오류가 루프백 제한 때문인 것도 아닙니다. 로그에 연결 기록이 있다면 예외를 반복해서 추가하지 말고 규칙과 노드를 계속 점검하세요.

먼저 이 기기의 기본 네트워크가 정상적으로 작동하는지 확인한 다음 로그에서 실패한 부분이 노드 서버 이름 확인인지, 서버 연결인지, 속도 측정 대상 요청인지 살펴보세요. 속도 측정 시간이 초과됐다는 것은 해당 요청이 제한 시간 안에 완료되지 않았다는 뜻일 뿐, 노드가 영구적으로 사용할 수 없다고 단정할 수는 없습니다. 사용 가능한 다른 아웃바운드와 같은 측정 대상을 비교하고 기기 시간, 구독 유효기간, 서버 포트와 프로토콜 매개변수도 확인하세요. 모든 노드가 동시에 실패하면 로컬 네트워크와 공통 설정을 먼저 점검합니다. 일부 노드만 실패한다면 서비스 제공자에게 상태를 문의하세요. 명확한 이름 확인 오류가 로그에 있을 때만 DNS를 조정하세요.

먼저 실패한 도메인, 오류 발생 시각, 사용한 리졸버를 기록하고 노드 서버 도메인과 대상 웹사이트 도메인 중 어느 쪽의 이름 확인이 실패했는지 구분하세요. 설정에 입력한 DNS 업스트림에 연결할 수 있는지, 암호화 DNS 업스트림의 도메인을 확인할 부트스트랩 경로가 작동하는지도 점검합니다. TUN을 사용한다면 시스템 DNS 요청이 예상대로 코어에 들어오는지 확인해 다른 DNS 도구와 제어가 충돌하지 않도록 하세요. 한 번에 업스트림 하나 또는 라우팅 설정 하나만 바꾸고 캐시를 지운 뒤 다시 시도하면서 비교 로그를 보관하세요. 여러 DNS 가로채기 기능을 동시에 켜면 잠시 복구되더라도 어느 설정이 문제를 해결했는지 판단하기 어렵습니다.

시스템 프록시는 앱이 참고하는 프록시 설정일 뿐 모든 프로그램에 사용을 강제하지 않습니다. 일부 명령줄 도구, 게임 또는 자체 네트워크 스택을 사용하는 앱은 이 설정을 무시할 수 있습니다. 먼저 시스템 프록시 주소와 포트가 클라이언트의 수신 주소 및 포트와 일치하는지 확인한 뒤 연결 패널에 대상 앱의 요청이 있는지 살펴보세요. 기록이 없다면 앱 자체의 프록시 설정, 프록시 환경 변수와 우회 목록을 확인하고, 필요한 권한을 확인한 뒤 TUN을 사용해 볼 수 있습니다. 연결 기록이 있다면 규칙과 아웃바운드 경로를 따라 점검하세요. 테스트할 때는 시스템 설정을 덮어쓸 수 있는 다른 프록시 클라이언트를 끄세요. TUN과 전역 아웃바운드 모드는 같은 설정이 아닙니다.

포트 사용 중 오류는 필요한 수신 주소를 다른 프로세스가 이미 사용하고 있다는 뜻입니다. 클라이언트를 중복 실행했는지, 이전 백그라운드 코어나 서비스가 계속 실행 중인지 먼저 확인하세요. 프로세스의 용도를 확인한 뒤 정상적으로 종료해야 하며, 정체를 모르는 시스템 프로세스를 바로 강제 종료해서는 안 됩니다. 로컬 수신 포트를 바꿀 수도 있지만 시스템 프록시와 앱에 직접 입력한 포트도 함께 업데이트해야 합니다. 종료 후 네트워크에 문제가 생기면 먼저 시스템에 종료된 클라이언트를 가리키는 프록시 설정이 남아 있는지 확인한 뒤 다른 VPN, 라우팅과 DNS 상태를 점검하세요. 클라이언트에서 트래픽 제어 기능을 정상적으로 끄고 종료하는 방법을 우선 사용하세요. 일반적인 복구 방법으로 해결되지 않을 때만 시스템 네트워크 초기화를 고려하고, 그 전에 기존 네트워크 설정을 기록해 두세요.