Clash 자주 묻는 질문

Clash는 일반적으로 프록시 코어와 그 설정 생태계를 가리킵니다. mihomo는 관련 설정 기능을 이어받아 확장한 코어 프로젝트로, 초기에는 Clash Meta라고도 불렸습니다. GUI 클라이언트는 구독 관리, 모드 전환, 시스템 연동을 담당하며, 실제 기능은 사용하는 코어와 버전에 따라 달라집니다. 문제를 확인하기 전에 정보 또는 코어 정보 화면에서 클라이언트 이름과 코어 버전을 기록한 뒤 해당 문서를 찾아보세요. 클라이언트마다 버튼 위치가 다르므로 화면에 표시된 이름만으로 기능 지원 여부를 판단하면 안 됩니다.

클라이언트는 프록시 연결과 규칙 처리 기능을 제공하지만, 사용할 수 있는 프록시 서버가 자동으로 포함되지는 않습니다. 구독을 통해 서비스 제공자가 배포하는 설정을 가져오며, 설정 파일에는 프록시, 정책 그룹, 규칙, DNS 등의 정보가 담깁니다. 구독 출처와 지원 형식을 확인한 뒤 클라이언트에 가져오세요. 계정 권한과 직접 연결될 수 있는 접근 정보가 포함되어 있으니 구독 URL을 공개 채팅방에 올리거나 화면을 캡처해 공유하지 마세요. 자체 서버를 사용하는 경우에도 실제 프로토콜에 맞게 연결 정보를 입력해야 합니다.

평소에는 규칙 모드를 사용해 설정에 따라 연결을 직접 연결하거나 프록시로 보내세요. 전역 모드는 코어에 들어온 연결에 전역 정책을 적용하므로 규칙이 접속에 영향을 주는지 잠깐 비교할 때 유용합니다. 기기의 모든 트래픽을 가로채는 기능은 아닙니다. 직접 연결 모드는 코어에 들어온 연결을 대상에 바로 연결하며, 클라이언트를 종료하는 것과는 다릅니다. 모드를 바꾼 뒤에는 새 연결로 테스트하세요. 기존 연결은 이전 정책을 계속 적용할 수 있으므로 필요한 경우 연결 화면에서 해당 연결을 종료하세요.

먼저 운영체제, 프로세서 아키텍처, 필요한 트래픽 처리 방식으로 후보를 좁힌 뒤 구독 관리와 규칙 편집 메뉴를 비교하세요. Windows 사용자는 Clash Plus를 먼저 살펴보고 Clash Verge Rev, FlClash 등의 클라이언트도 확인할 수 있습니다. Clash for Windows는 유지 관리가 중단됐으므로 예전 가이드의 화면 위치를 최신 버전의 기준으로 삼지 마세요. 이전할 때 구독과 사용자 규칙은 보존하되 기존 클라이언트의 데이터 폴더 전체를 그대로 복사하지 마세요. 가져온 뒤 포트, 정책 그룹, DNS 설정을 하나씩 확인하세요.

시스템 프록시는 HTTP 등의 프록시 주소를 운영체제에 등록하며, 이 설정을 따르는 앱만 사용합니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 더 많은 연결을 처리하므로 시스템 프록시를 읽지 않는 프로그램에 유용하지만, 추가 권한이 필요하고 다른 VPN과 충돌할 수 있습니다. 두 방식 모두 규칙과 설정의 영향을 받으며, TUN을 켠다고 모든 연결이 프록시를 거치는 것은 아닙니다. 먼저 시스템 프록시로 기본 동작을 확인하고, 실제로 더 많은 앱을 처리해야 할 때 TUN을 켜세요. 여러 네트워크 계층을 동시에 변경하지 않는 것이 좋습니다.

클라이언트의 설정 또는 구독 화면에서 URL 가져오기를 선택하고 전체 구독 주소를 붙여넣으세요. 다운로드가 끝나면 해당 설정을 선택합니다. 로컬 파일이 있다면 파일 가져오기를 통해 YAML을 선택한 뒤 로드 로그를 확인하세요. Base64 노드 목록만 제공하는 링크는 바로 사용할 수 있는 Clash 설정이 아닐 수 있으므로, 서비스 제공자에게 호환되는 형식으로 내보내 달라고 요청해야 합니다. 계정 정보가 포함된 링크를 신뢰할 수 없는 변환 서비스에 입력하지 마세요. 가져온 뒤에는 정책 그룹에 선택 가능한 프록시가 있는지 확인하고 시스템 프록시를 켜세요.

먼저 시스템 설정의 정보 화면에서 프로세서 아키텍처를 확인하세요. 일반적인 Intel·AMD 데스크톱 기기는 x64를 사용하고, Apple Silicon Mac은 해당 ARM 아키텍처용 설치 파일을 사용합니다. Windows ARM 기기는 클라이언트가 네이티브 지원을 제공하는지 확인해야 합니다. Android는 기기 아키텍처에 맞춰 선택하고, 확인이 어렵다면 범용 패키지와 시스템 요구 사항을 살펴보세요. Linux의 deb와 rpm처럼 설치 파일 형식도 배포판에 맞아야 하며 서로 바로 바꿔 사용할 수 없습니다. 기기 브랜드나 외관만 보고 아키텍처를 추측하지 마세요.

먼저 TUN을 끄고 클라이언트에 서비스 설치, 서비스 모드 또는 서비스 복구 메뉴가 있는지 확인하세요. 안내에 따라 시스템 권한을 허용한 뒤 클라이언트를 다시 시작합니다. Windows는 일반적으로 관리자 권한이 있는 서비스가 가상 인터페이스를 관리해야 합니다. macOS에서는 관련 네트워크 권한을 승인해야 하며, Linux는 클라이언트의 권한 상승 방식에 따라 다릅니다. 모든 프로그램을 항상 높은 권한으로 실행하는 방식으로 해결하지 마세요. 서비스를 설치했는데도 실패한다면 로그의 첫 오류를 확인하고 다른 VPN, 가상 네트워크 어댑터 또는 보안 정책이 인터페이스 생성을 차단하는지 살펴보세요.

mixed-port는 HTTP와 SOCKS 프록시 연결을 함께 받는 포트입니다. 7890은 흔히 쓰이는 예시일 뿐 모든 클라이언트가 현재 이 포트를 사용하는 것은 아닙니다. 설정 화면이나 적용된 설정에 표시된 수신 포트를 기준으로 브라우저, 터미널, 시스템 프록시가 같은 포트를 가리키도록 하세요. 로컬 기기에서 접속할 때는 보통 127.0.0.1을 사용합니다. 포트를 바꾼 뒤에는 시스템 프록시를 다시 적용하세요. 로그에 주소가 이미 사용 중이라고 나오면 어떤 프로그램이 점유 중인지 먼저 확인하고, 시스템 프로세스를 함부로 종료하지 마세요.

같은 로컬 네트워크의 다른 기기에서 프록시를 사용해야 할 때만 켜세요. 로컬 네트워크 연결 허용 외에도 수신 주소, 호스트 방화벽, 기기 간 네트워크 연결을 확인해야 합니다. 다른 기기에는 클라이언트가 실행 중인 호스트의 로컬 IP와 실제 포트를 입력하세요. 127.0.0.1은 해당 기기 자신을 가리키므로 입력하면 안 됩니다. 클라이언트가 지원하는 경우 접근 인증과 허용 출처를 설정하세요. 프록시 포트나 외부 제어 인터페이스를 공용 인터넷에 노출하지 말고, 공용 Wi-Fi에서도 계속 열어 두지 마세요.

구독 상세 정보에서 자동 업데이트를 켜고 입력란의 단위를 먼저 확인하세요. 일부 클라이언트는 분 단위로 입력하므로 1440분은 하루입니다. provider 설정의 interval은 보통 초 단위이므로 숫자를 그대로 옮겨 입력하면 안 됩니다. 업데이트 주기는 서비스 제공자의 권장 값을 따르세요. 너무 자주 업데이트하면 요청 제한이 걸릴 수 있습니다. 현재 네트워크에서 구독 주소에 직접 접속할 수 없고 이미 켜 둔 프록시가 작동할 때만 프록시를 통한 업데이트를 시도하세요. 값을 바꾼 뒤에는 수동으로 새로 고쳐 로그에서 성공 여부를 확인하고, 되돌릴 수 있도록 기존 설정도 보관하세요.

클라이언트의 오버라이드, 병합 또는 확장 규칙 메뉴를 우선 사용하세요. 원격 구독으로 덮어써질 수 있는 원본 파일을 직접 수정하지 않는 것이 좋습니다. Clash 규칙은 일반적으로 위에서 아래 순서로 매칭되므로 구체적인 도메인 규칙을 더 포괄적인 규칙보다 앞에 두고 MATCH는 보통 마지막에 둡니다. 규칙을 추가할 때 대상 정책 이름이 실제로 존재하는지, 대소문자와 문자가 정확한지 확인하세요. 저장 후 설정 검사 결과를 살펴보고 새 연결에서 적용된 규칙을 확인하세요. 병합 순서는 클라이언트마다 다르므로 최종 적용 설정을 기준으로 판단해야 합니다.

클라이언트의 연결 화면을 열고 도메인이나 앱으로 필터링해 해당 연결에 적용된 규칙, 정책 그룹, 최종 출구를 확인하세요. 연결 재사용으로 판단이 빗나가지 않도록 기존 연결을 닫고 사이트를 새로 여세요. 클라이언트 홈 화면의 스위치나 브라우저에 표시된 IP만으로는 모든 요청의 경로를 알 수 없습니다. 웹페이지가 여러 도메인에 동시에 요청을 보낼 수 있기 때문입니다. 연결 목록에 해당 요청이 전혀 없다면 먼저 앱이 현재 프록시 주소를 사용하고 있는지 확인한 뒤 TUN, 브라우저 자체 프록시, 앱의 네트워크 설정을 살펴보세요.

먼저 정상 작동이 확인된 구독 설정이나 클라이언트 권장 설정을 그대로 사용하세요. fake-ip는 도메인에 가상 주소를 할당해 코어가 연결을 처리할 때 도메인 정보를 유지할 수 있게 합니다. redir-host는 일반적으로 실제로 해석된 주소를 반환합니다. 일부 게임, 로컬 네트워크 서비스, 실제 주소에 의존하는 앱은 별도 호환 설정이 필요할 수 있으므로 문제가 생겼다고 전체 모드를 바로 바꾸지는 마세요. 먼저 fake-ip-filter와 관련 DNS 규칙을 확인하세요. 모드를 바꾼 뒤에는 해당 앱의 DNS 캐시를 비우고 새 연결을 만들어 이전 해석 결과가 테스트에 영향을 주지 않도록 하세요.

먼저 시스템 배터리 사용량을 확인해 클라이언트의 상시 실행과 다른 앱의 프록시 트래픽을 구분하세요. 불필요한 속도 측정과 구독 새로 고침을 줄이고 상세 로그를 계속 기록하지 않도록 설정하세요. Android에서 연결이 자주 끊긴다면 필요에 따라 배터리 최적화나 백그라운드 제한을 조정할 수 있지만, 제한을 완화하면 배터리 소모가 늘 수 있습니다. iOS는 주로 시스템 네트워크 확장의 실행 정책에 따라 달라집니다. 한 번에 한 가지씩 변경하고 실제 사용 상태를 관찰하세요. 백그라운드 유지를 위해 여러 상주 도구를 동시에 켜지 마세요. 연결을 계속 처리하려면 네트워크 서비스가 실행 상태를 유지하는 비용도 감안해야 합니다.

먼저 업데이트 로그에서 구체적인 오류를 확인하세요. 시간 초과는 구독 도메인에 접속할 수 있는지 확인하고 직접 연결과 프록시 연결을 비교해야 합니다. 인증서 오류가 나면 시스템 날짜를 바로잡고 로그인 페이지나 네트워크 장비가 연결을 가로채는지 확인하세요. 인증서 검증을 바로 끄면 안 됩니다. 401이나 403은 접근 정보, 권한 또는 서비스 제공자의 제한과 관련된 경우가 많으므로 서비스 계정 페이지에서 확인하세요. YAML 대신 HTML이 반환됐다면 로그인 페이지나 오류 페이지를 받은 것일 수 있습니다. 기존 설정을 보관하고 구독 주소를 다시 복사해 시도하세요. 로그를 공유하기 전에는 계정 정보를 숨기세요.

속도 측정 시간 초과는 지정된 테스트 주소와 제한 시간 안에 기대한 결과를 얻지 못했다는 뜻일 뿐, 구독이 무효라는 증거는 아닙니다. 먼저 프록시 하나를 선택해 실제 대상 사이트에 접속한 뒤 테스트 URL에 연결할 수 있는지, 시스템 시간이 맞는지, 현재 네트워크에서 웹 로그인이 필요한지 확인하세요. 다른 네트워크나 같은 구독의 다른 프록시와 비교해 보세요. 모두 실패하면 설정 로드 상태와 코어 로그를 확인하고, 일부 프록시만 실패하면 서비스 제공자에게 문의하세요. 시간 초과 기준을 반복해서 낮추면 정상 연결을 실패로 잘못 판단하기 쉽습니다.

수신 포트, 시스템 설정, 앱 설정 순으로 확인하세요. 먼저 코어가 실행 중이고 포트가 시스템 프록시와 일치하는지 확인합니다. 다음으로 운영체제의 프록시 주소가 로컬 기기를 가리키는지 살펴보고, 설정을 덮어쓸 수 있는 브라우저 프록시 확장 프로그램은 끄세요. 연결이 클라이언트에 표시되면 적용된 규칙과 선택된 프록시를 확인하고, 기록이 없다면 연결 경로를 계속 점검하세요. 다른 VPN을 끈 뒤 새 연결로 테스트합니다. 클라이언트를 종료한 뒤에도 접속할 수 없다면 중지된 서비스 주소가 시스템 프록시에 남아 있는지 확인하고 이전 네트워크 설정을 복원하세요.

AppContainer 격리를 사용하는 일부 Windows 앱은 로컬 루프백 접근이 제한되어 127.0.0.1의 프록시에 직접 연결할 수 없습니다. 먼저 대상 앱이 실제로 이 문제에 해당하는지 확인한 뒤 클라이언트가 제공하는 UWP 루프백 도구를 사용해 필요한 앱만 예외로 추가하고 안내에 따라 권한을 허용하세요. Windows 관리에 익숙한 사용자는 CheckNetIsolation으로 설정을 확인할 수도 있습니다. 모든 앱을 한꺼번에 허용하는 것은 기본 해결책으로 삼지 마세요. 그래도 실패하면 앱이 시스템 프록시를 읽는지, 보안 정책이 설정 변경을 차단하는지 확인하세요.

먼저 TUN을 끄고 기본 네트워크가 복구되는지 확인한 다음, 같은 설정을 시스템 프록시로 테스트하세요. TUN에서만 실패한다면 로그에서 라우팅, DNS 가로채기, 가상 인터페이스 오류를 확인하고 다른 VPN을 끈 상태와 비교하세요. 인터넷에서 찾은 전체 DNS 설정을 구독에 그대로 덮어쓰지 마세요. 상위 DNS 주소에 접속할 수 있는지, DNS 요청이 순환하는지 확인해야 합니다. 변경 전 원래 설정을 저장하고 한 번에 매개변수 하나만 조정하세요. 클라이언트를 종료한 뒤에도 문제가 남으면 프록시와 라우팅 설정이 남아 있는지 확인하고 클라이언트 문서에 따라 서비스를 복구하거나 네트워크 연결을 다시 시작하세요.