Clash 자주 묻는 질문

Clash는 프록시 코어와 그 설정 생태계를 가리키는 이름으로 널리 쓰이며, mihomo는 이 생태계에서 꾸준히 개발 중인 코어 프로젝트입니다. Clash Verge Rev, FlClash 같은 클라이언트는 그래픽 인터페이스를 제공하고 설정 가져오기, 시스템 프록시, 코어 프로세스 관리를 담당합니다. 규칙을 해석하고 연결을 만드는 것은 코어입니다. 문제를 확인할 때는 먼저 ‘정보’ 또는 ‘코어’ 화면에서 클라이언트 이름과 코어 버전을 각각 기록하세요. 화면이 비슷하다고 같은 설정을 지원하는 것은 아니며, 특히 TUN, DNS, 프로토콜 항목은 차이가 있을 수 있습니다. 다운로드할 때는 기기의 운영체제에 맞는 클라이언트를 선택하고, 설정을 수정하기 전에는 설치 파일 이름만 보지 말고 현재 실행 중인 코어를 확인하세요.

사용할 수 있는 프록시 설정이 필요합니다. 클라이언트는 설정을 읽고 요청을 전달할 뿐, 설치만으로 원격 프록시 서비스가 만들어지지는 않습니다. 보통 이용 중인 서비스의 계정 페이지에서 Clash 또는 mihomo 형식의 구독을 받은 뒤 ‘설정’ 화면에서 가져옵니다. 직접 관리하는 YAML 파일을 가져와도 됩니다. 가져온 다음에는 설정이 선택되어 있는지, 프록시 화면에 프록시 그룹이 표시되는지, 선택한 그룹에 사용 가능한 출구가 있는지 확인하세요. 구독 주소에는 계정 식별 정보가 포함될 수 있으므로 민감한 정보로 취급하고, 화면을 공유할 때는 주소 전체를 가리세요. 출처가 불분명한 설정은 중요한 계정에 사용하지 말고, 노드 링크 하나를 전체 설정 파일로 착각하지 마세요.

일상적인 사용에는 ‘규칙’ 모드를 권장합니다. 요청을 rules 순서대로 매칭해 해당 프록시 그룹으로 전달합니다. ‘전역’ 모드는 코어로 들어온 요청을 모두 전역 프록시 그룹으로 보내므로 규칙이 문제를 일으키는지 임시로 확인할 때 유용하지만, 해당 그룹에서 사용할 수 있는 출구를 선택해야 합니다. ‘직접 연결’은 코어로 들어온 요청을 프록시 없이 연결하므로 비교 테스트에 적합합니다. 모드는 코어가 요청을 받은 뒤 처리하는 방식만 정합니다. 시스템 프록시나 TUN을 대신하지 않으며 모든 앱의 트래픽을 자동으로 가져오지도 않습니다. 전역 모드로 바꿔도 웹페이지가 열리지 않으면 요청이 로그에 들어오는지 확인한 뒤 출구 연결을 점검하세요. 모드를 계속 바꾸면서 DNS까지 함께 수정하면 어떤 설정이 효과를 냈는지 판단하기 어렵습니다.

시스템 프록시는 운영체제의 프록시 설정을 통해 해당 설정을 따르는 앱이 로컬 수신 포트에 연결되도록 합니다. TUN은 가상 네트워크 인터페이스를 사용해 해당 인터페이스로 라우팅된 IP 트래픽을 받으므로 시스템 프록시를 따르지 않는 프로그램에 더 적합합니다. 어느 쪽도 모든 트래픽이 반드시 프록시를 거친다는 뜻은 아닙니다. 실제 동작은 라우팅, 앱 동작, 규칙의 영향을 받습니다. 처음 설정할 때는 시스템 프록시만 켜고 브라우저 연결을 확인한 다음, 필요한 경우 TUN을 활성화하고 클라이언트가 안내하는 조합 설정을 따르세요. 문제를 해결하려고 프록시 클라이언트, VPN, 가상 네트워크 어댑터의 트래픽 가로채기 기능을 한꺼번에 켜지 마세요. 여러 기능을 겹쳐 쓰기보다 명확한 경로 하나만 유지하는 편이 원인을 찾기 쉽습니다.

‘설정’ 화면에서 ‘URL에서 가져오기’ 또는 ‘구독 추가’를 선택하고 서비스에서 받은 Clash 형식의 주소를 붙여넣어 저장하세요. 다운로드가 끝나면 해당 설정을 클릭해 현재 설정으로 지정합니다. 다음으로 ‘프록시’ 화면에서 프록시 그룹이 로드됐는지 확인하고, ‘로그’ 화면에서 파싱 오류가 있는지 살펴보세요. 목록에 파일이 표시되는 것은 설정이 저장됐다는 뜻일 뿐, 활성화됐다는 뜻은 아닙니다. yaml: unmarshal errors가 표시되면 낯선 항목을 바로 삭제하지 말고 구독 형식과 코어의 호환성을 먼저 확인하세요. 마지막으로 시스템 프록시를 켜고 대상 웹사이트에 접속하면서 연결 기록을 확인합니다. 실제 적용 여부는 기록에 표시된 규칙, 프록시 그룹, 출구를 기준으로 판단하세요.

먼저 시스템의 프로세서 아키텍처를 확인한 뒤 설치 파일을 선택하세요. Windows에서는 ‘설정 → 시스템 → 시스템 정보’에서 시스템 종류를 확인할 수 있습니다. macOS에서는 ‘이 Mac에 관하여’에서 칩을 확인하세요. Apple Silicon 기기는 보통 ARM64, Intel 기기는 x64를 선택합니다. 최근 Android 기기는 대부분 arm64-v8a를 사용하지만, 기기와 설치 파일의 지원 범위를 확인해야 합니다. Linux에서는 uname -m을 실행하면 됩니다. x86_64는 보통 AMD64, aarch64는 보통 ARM64에 해당합니다. 아키텍처를 확인한 뒤 최소 시스템 요구 사항도 확인하세요. 설치하거나 실행할 수 없다면 오류 문구를 그대로 보관하고, 먼저 아키텍처와 운영체제 버전이 맞는지 점검하세요. 설치 단계의 문제를 해결하려고 구독을 계속 바꾸지 마세요.

‘시작 시 실행’은 보통 클라이언트가 실행된다는 뜻일 뿐, 코어와 시스템 프록시, TUN까지 모두 복구된다는 보장은 없습니다. 로그아웃한 뒤 다시 로그인하고, 시스템 트레이에 아이콘이 표시되는지 확인한 다음 코어 상태, 현재 설정, 트래픽 가로채기 스위치를 살펴보세요. Windows에서는 ‘시작 앱’에서 프로그램이 비활성화되어 있지 않은지도 확인해야 합니다. TUN을 사용하는 경우 클라이언트에 필요한 서비스가 설치되어 실행되는지 확인하세요. 관리자 권한 시작 항목과 일반 사용자 시작 항목을 중복 설정하지 마세요. 로그인 직후 구독 업데이트만 실패한다면 네트워크가 연결될 때까지 기다린 뒤 수동으로 업데이트하거나, 클라이언트의 지연 시작 옵션을 사용하세요. 시작 과정을 하나씩 확인하고, 작업 관리자에 프로세스가 있다는 이유만으로 연결이 복구됐다고 판단하지 마세요.

먼저 안내 메시지가 서비스 설치, 가상 인터페이스 생성, 네트워크 확장 승인 중 어디에서 발생했는지 확인하세요. Windows 클라이언트에 ‘서비스 모드’ 또는 ‘서비스 설치’가 있다면 안내에 따라 설치를 승인한 뒤 TUN을 다시 켜세요. 서비스 오류를 가리기 위해 매번 관리자 권한으로 실행하는 방식은 피하세요. macOS에서는 실제로 표시된 안내에 따라 시스템 설정에서 해당 네트워크 확장 또는 VPN 구성을 허용하세요. 클라이언트마다 구현 방식이 다를 수 있습니다. Linux에서는 보통 /dev/net/tun에 접근할 수 있어야 하고 적절한 네트워크 관리 권한도 필요하므로 프로젝트에서 권장하는 서비스 설정을 사용하세요. 승인한 뒤 로그에서 인터페이스 생성이 성공했는지 확인합니다. 그래도 인터넷에 연결되지 않으면 네트워크와 무관한 디스크 권한을 반복해서 허용하지 말고 라우팅과 DNS를 점검하세요.

지연 시간 테스트는 주로 테스트 주소에 연결되는지와 응답 시간을 보여 줍니다. 지속적인 대역폭을 나타내지는 않으며 대상 웹사이트까지 같은 경로를 사용한다고 보장하지도 않습니다. 먼저 출구 하나와 다운로드 주소 하나를 고정하고 연결 기록을 확인해 실제 요청이 규칙에 따라 다른 프록시 그룹으로 전달되지 않았는지 살펴보세요. 그런 다음 직접 연결과 프록시, 출구별 속도, 시간대별 속도를 비교해 로컬 네트워크, 원격 회선, 대상 사이트의 속도 제한을 구분합니다. 테스트 중에는 다른 기기의 대용량 전송을 멈춰 속도 측정과 다운로드가 서로 영향을 주지 않도록 하세요. 특정 앱에서만 느리다면 해당 앱의 프록시 설정과 동시 연결 제한을 확인하세요. 지연 시간이 가장 짧다는 이유만으로 노드를 고르거나 한 번의 속도 테스트를 장기적인 속도 보장으로 받아들이지 마세요.

먼저 ‘연결’ 화면에서 해당 요청에 매칭된 규칙과 프록시 그룹을 확인하세요. 이름만 비슷한 다른 그룹이 아니라 실제로 사용되는 그룹을 수정했는지 살펴봐야 합니다. select 그룹은 직접 선택할 수 있지만 url-test 같은 자동 그룹은 테스트 결과에 따라 노드를 다시 선택할 수 있습니다. 중첩 그룹은 선택 경로를 따라 단계별로 확인하세요. 이미 연결된 장시간 연결은 노드를 바꿔도 바로 이전되지 않는 경우가 많습니다. 해당 연결을 닫거나 요청을 보낸 앱을 재시작한 뒤 새 연결을 만들어 확인하세요. 구독을 업데이트하면 그룹 구조가 바뀌거나 선택이 초기화될 수도 있으며, 동작은 클라이언트가 선택 상태를 저장하는지에 따라 달라집니다. 문제를 확인할 때는 그룹 하나만 수정하고 새 연결의 출구를 기록하세요. 기존 페이지에서 재사용 중인 연결로 전환 성공 여부를 판단하지 마세요.

mixed-port는 HTTP와 SOCKS 프록시 요청을 모두 받는 혼합 수신 포트입니다. 앱에서 수동 프록시를 설정할 때 이 포트를 지정하세요. external-controller는 코어를 관리하는 API 주소로, 인터넷 연결용 프록시 포트가 아닙니다. 7890과 127.0.0.1:9090은 흔히 쓰이는 예시이며 실제 값은 현재 클라이언트 설정을 따라야 합니다. 로그에 bind: address already in use가 표시되면 다른 프록시 프로그램을 종료한 뒤 포트 점유 여부를 확인하세요. mixed-port를 바꿨다면 앱의 수동 프록시 설정도 함께 변경해야 합니다. 관리 인터페이스는 우선 루프백 주소에 바인딩하고, 꼭 외부에 열어야 한다면 접근 제어를 설정하세요. 로컬 앱을 연결하려고 관리 인터페이스를 LAN이나 인터넷에 그대로 공개하지 마세요.

먼저 문제가 모든 Windows 프로그램이 아니라 앱 컨테이너로 격리되는 UWP 앱에 한정되는지 확인하세요. 일부 앱은 기본적으로 로컬 루프백 프록시에 접근할 수 없어 브라우저는 정상인데 스토어 앱은 실패할 수 있습니다. 클라이언트에 ‘UWP 루프백 예외’ 기능이 있다면 필요한 권한으로 도구를 열고, 필요한 앱에만 예외를 적용한 뒤 앱을 재시작해 테스트하세요. 예외는 루프백 주소 접근을 허용할 뿐 프록시를 자동으로 설정하거나 작동하지 않는 노드를 고쳐 주지는 않습니다. 관련 도구가 없다면 Microsoft 문서를 참고해 CheckNetIsolation으로 지정한 앱의 루프백 예외를 관리할 수 있습니다. 모든 앱에 일괄 적용하지 마세요. 그래도 문제가 계속되면 앱이 시스템 프록시를 따르는지, 연결 로그에 요청이 들어오는지 확인하세요.

먼저 HTTP 오류와 네트워크 오류를 구분하세요. 401, 403은 주소 만료, 접근 제한, 계정 상태와 관련된 경우가 많으므로 계정 페이지에서 서비스 상태를 확인하고 Clash 구독 주소 전체를 다시 복사하세요. 404라면 경로가 빠짐없이 복사됐는지 먼저 확인합니다. YAML 설정 대신 HTML 로그인 페이지가 반환되어도 가져오기 과정에서 파싱에 실패할 수 있습니다. i/o timeout이 표시되면 현재 네트워크와 구독 도메인에 연결할 수 있는지 확인하세요. 클라이언트에서 업데이트 시 프록시 사용 여부를 선택할 수 있다면 직접 연결과 정상 작동이 확인된 프록시 출구를 각각 테스트하세요. 업데이트되지 않은 설정에 구독 업데이트가 의존하는 상황을 피할 수 있습니다. 오류를 공유할 때는 상태 코드와 도메인만 남기고 주소의 계정 식별 정보와 쿼리 매개변수는 삭제하세요.

오류 전체를 확인하세요. dial tcp 자체가 원인은 아니며 TCP 연결을 시도하는 상황을 나타내는 문구입니다. 뒤에 i/o timeout이 이어지면 보통 제한 시간 안에 연결이 완료되지 않았다는 뜻입니다. connection refused는 대상 포트에서 연결을 받지 않거나 명시적으로 거부한 경우에 가깝고, no such host라면 도메인 조회부터 확인해야 합니다. 구독이 유효한지, 노드 주소와 포트가 최신인지 확인한 다음 다른 출구와 비교하고 라우팅 충돌을 피하도록 다른 VPN을 잠시 끄세요. 모든 노드가 동시에 실패한다면 로컬 네트워크, DNS, 클라이언트의 트래픽 가로채기 상태를 먼저 살펴보세요. 노드 하나만 실패한다면 해당 서비스 제공자에게 문의하세요. 시간 제한을 무작정 늘리거나 방화벽 보호 기능을 통째로 끄는 것으로 원인 파악을 대신하지 마세요.

먼저 ‘연결’ 화면을 열고 대상 웹사이트를 새로고침하세요. 새 요청이 전혀 없다면 분기 규칙보다 트래픽 가로채기 설정에 문제가 있을 가능성이 큽니다. 운영체제에 설정된 프록시 주소와 포트가 현재 mixed-port와 일치하는지 확인한 다음, 브라우저가 자체 프록시 확장 프로그램이나 별도 네트워크 설정을 사용하는지 살펴보세요. Firefox 같은 앱은 시스템 설정을 그대로 따르지 않을 수 있습니다. 다른 프록시 클라이언트를 종료해 시스템 프록시 설정을 덮어쓰지 않도록 하세요. 요청이 코어에 들어왔는데 DIRECT로 표시되면 시스템 프록시를 다시 켜기보다 매칭된 규칙과 모드를 확인하세요. 클라이언트를 종료하기 전에 시스템 프록시를 끄세요. 프로그램을 닫은 뒤 인터넷이 끊긴다면 시스템 프록시 설정에서 로컬 포트를 가리키는 수동 프록시를 삭제하세요.

먼저 노드 도메인 조회 실패와 대상 웹사이트 도메인 조회 실패를 구분하세요. 로그에 표시된 도메인을 보면 원인을 찾는 데 도움이 됩니다. 현재 dns 설정을 기록하고 한 번에 한 항목만 조정하세요. 사용 중인 DNS 확인 서버에 연결할 수 있는지, 확인 서버의 도메인도 초기 조회가 가능한지, 다른 VPN이나 보안 프로그램이 DNS 요청을 가로채는지 점검합니다. fake-ip를 사용하는 경우 가상 주소 트래픽이 제대로 가로채지는지도 확인하세요. 캐시만 비워서는 잘못된 라우팅을 해결할 수 없습니다. 브라우저에서 별도의 보안 DNS를 사용한다면 잠시 시스템 설정을 따르도록 바꿔 비교 테스트할 수 있습니다. 설정을 수정한 뒤 시스템과 앱 캐시를 지우고 새 연결을 만드세요. 여러 안내서의 DNS 설정을 이어 붙이지 말고, 특히 현재 코어가 지원하지 않는 항목을 섞어 쓰지 마세요.