Clash 자주 묻는 질문

Clash는 프록시 코어와 그 설정 생태계를 통칭하는 이름으로 쓰입니다. mihomo는 Clash.Meta를 이어 발전한 코어로, 연결 처리와 규칙 매칭, DNS 처리를 담당합니다. Clash Plus, Clash Verge Rev 등의 클라이언트는 그래픽 인터페이스를 제공해 설정, 시스템 프록시, 코어 프로세스를 관리합니다. 같은 설정을 사용할 수 있는지는 클라이언트에 실제로 탑재된 코어와 버전에 따라 달라지므로, 소프트웨어 이름에 Clash가 포함됐는지만으로 판단하면 안 됩니다.

클라이언트는 설정을 실행하는 프로그램이며, 설치만으로 원격 프록시 서비스가 제공되지는 않습니다. 구독에는 보통 서버 정보와 프록시 그룹, 분기 규칙이 포함됩니다. 직접 관리하는 YAML 설정을 사용할 수도 있습니다. 가져오기 전에 출처를 신뢰할 수 있는지, 서비스가 유효한지, 구독 형식이 맞는지 확인하세요. 구독 주소에 인증 정보가 포함될 수 있으므로 화면 캡처나 문의용 로그를 공유할 때는 전체 주소를 가리고, 일반 웹 주소처럼 공개하지 마세요.

일상적인 사용에는 보통 규칙 모드를 선택합니다. 설정에 작성된 규칙이 순서대로 연결 경로를 결정합니다. 전역 모드는 코어로 들어온 연결을 전역 프록시 그룹으로 보내므로, 규칙이 접속에 영향을 주는지 잠시 확인할 때 유용합니다. 직접 연결 모드에서는 코어로 들어온 연결이 대상에 바로 접속합니다. 모드는 코어에 들어온 트래픽의 처리 방식만 결정합니다. 전역 모드가 기기 전체의 트래픽을 가로채는 것은 아니며 시스템 프록시나 TUN을 대신하지도 않습니다.

새로 설치한다면 다운로드 페이지의 Clash Plus부터 살펴보고, 인터페이스 취향에 따라 Clash Verge Rev, FlClash, Clash Nyanpasu를 비교해 보세요. Clash for Windows는 업데이트가 중단됐습니다. 이전하기 전에 설정과 사용자 지정 규칙을 백업한 뒤 새 클라이언트로 가져오세요. 기존 클라이언트의 화면 설정이 그대로 옮겨지지 않을 수 있으므로 혼합 포트, 서비스 모드, TUN, DNS 재정의를 항목별로 확인해야 합니다. 두 클라이언트가 동시에 시스템 프록시를 제어하지 않도록 하세요.

노드 속도 측정값은 보통 코어가 테스트 주소에 요청을 보내 얻은 응답 시간이며, 다운로드 대역폭이나 동영상 재생 속도, 게임 성능을 뜻하지는 않습니다. 테스트 주소와 제한 시간, 서버 부하, 대상 사이트가 연결된 네트워크에 따라 결과가 달라집니다. 노드를 비교할 때는 같은 네트워크와 테스트 주소를 사용하고, 실제 앱에서도 확인하세요. 특정 노드가 시간 초과로 표시돼도 테스트 주소에 연결할 수 없었던 것일 수 있습니다. 로그를 먼저 확인하고 측정 결과 하나만 보고 노드를 삭제하지 마세요.

서비스 제공업체 페이지에서 Clash 또는 mihomo용이라고 명시된 구독 주소를 선택하세요. 클라이언트의 설정 또는 구독 화면에서 URL 가져오기와 같은 메뉴를 열고 주소를 붙여 넣어 저장한 다음, 해당 설정을 현재 사용 중인 설정으로 지정합니다. 계정 로그인 페이지, 주문 페이지, QR 코드 이미지 주소는 보통 구독 주소가 아닙니다. Base64 노드 목록이나 SIP008 데이터만 제공됐다면 클라이언트가 지원하는지 먼저 확인하세요. 파일 확장자만 YAML로 바꿔서는 사용할 수 없습니다.

먼저 클라이언트 코어가 정상적으로 실행 중인지 확인한 뒤 플랫폼에 맞게 권한을 설정하세요. Windows에서는 보통 클라이언트가 제공하는 서비스 모드를 설치하고 실행해야 합니다. macOS에서는 보조 프로그램을 설치하고 권한을 허용해야 할 수 있습니다. Linux는 클라이언트가 지원하는 권한 상승 방식이나 서비스 설정이 필요합니다. Android에서는 시스템 VPN 연결 요청을 확인하세요. 설정을 마친 뒤 TUN을 다시 켜고 로그를 확인합니다. 서비스 설치 실패를 반복적인 권한 상승으로 덮으려 하지 말고, 다른 VPN 앱을 동시에 켜지 마세요.

그렇지 않습니다. 7890은 자주 쓰이는 값일 뿐입니다. 혼합 포트는 하나의 수신 포트에서 HTTP와 SOCKS5 프록시 연결을 모두 받으며, 실제 포트 번호는 사용 중인 클라이언트 설정을 따릅니다. 브라우저 확장 프로그램이나 다른 앱에 프록시를 직접 입력할 때는 보통 로컬 주소로 127.0.0.1을 사용하고, 포트 번호는 클라이언트 설정과 일치시켜야 합니다. 포트가 사용 중이라는 메시지가 뜨면 이전 클라이언트를 종료하거나 해당 포트를 점유한 프로세스를 찾으세요. 포트를 변경했다면 직접 입력해 둔 모든 앱에서도 값을 바꿔야 합니다.

시스템 프록시는 앱에 프록시 설정을 제공할 뿐, 모든 프로그램이 이를 따르도록 강제하지는 않습니다. 먼저 시스템 프록시를 사용하는 브라우저로 테스트한 뒤, 클라이언트의 연결 화면에 해당 요청이 표시되는지 확인하세요. 명령줄 도구, 게임, 자체 네트워크 스택을 사용하는 앱은 프록시를 별도로 지정하거나 프로세스 환경 변수를 설정해야 할 수 있으며, TUN을 사용하는 방법도 있습니다. 연결이 클라이언트에 표시되는데도 DIRECT로 처리된다면 시스템 프록시를 반복해서 전환하지 말고 규칙 매칭 결과를 확인하세요.

두 기기를 같은 신뢰할 수 있는 로컬 네트워크에 연결하세요. 컴퓨터 클라이언트에서 로컬 네트워크 연결 허용을 켜고, 수신 주소가 루프백 주소로만 제한되지 않았는지 확인합니다. 다른 기기의 수동 HTTP 프록시에는 컴퓨터의 로컬 IP와 혼합 포트를 입력하세요. 127.0.0.1을 입력하거나 컴퓨터 주소 대신 라우터 게이트웨이를 입력하면 안 됩니다. 컴퓨터 방화벽에서는 필요한 사설 네트워크에만 해당 포트를 허용하세요. 일반 HTTP 프록시만으로 기기의 모든 앱이나 UDP 트래픽을 처리할 수 있는 것은 아닙니다.

구독을 업데이트하면 원격 설정을 다시 내려받기 때문에 생성된 파일을 직접 수정한 내용은 덮어쓰일 수 있습니다. 클라이언트에서 제공하는 재정의, 병합, 확장 설정 또는 스크립트 기능을 우선 활용해 개인 규칙과 원격 구독을 분리해서 관리하세요. 클라이언트마다 병합 순서가 다르므로 규칙을 추가한 뒤 최종 적용 설정을 확인하고 연결 화면에서 실제 매칭 결과를 검증해야 합니다. 클라이언트를 바꾸면 재정의 설정도 다시 구성하세요. 구독 주소와 함께 자동으로 옮겨질 것이라고 가정하면 안 됩니다.

규칙 모드를 유지하고 사용자 지정 규칙에 해당 사이트의 도메인 매칭을 추가하세요. 먼저 매칭될 수 있는 광범위한 규칙이나 기본 MATCH 규칙보다 앞에 배치해야 합니다. 예를 들어 DOMAIN-SUFFIX,example.com,DIRECT는 해당 도메인과 하위 도메인에 매칭됩니다. 사이트에 따라 로그인, 이미지, API용 별도 도메인에도 요청할 수 있으므로 연결 로그에서 필요한 항목을 확인해 추가하세요. 특정 사이트 하나를 위해 여러 서비스가 공유하는 대형 도메인 전체를 허용하지 마세요.

Fake-IP는 앱에 먼저 매핑된 IP 주소를 반환한 뒤, 코어가 연결을 원래 도메인과 연결해 규칙을 판정하고 후속 DNS 조회를 처리하는 방식입니다. 원격 서버의 실제 IP 주소는 아닙니다. 실제 DNS 결과나 로컬 네트워크 기기 검색, 특수 인증 절차에 의존하는 일부 앱에서는 호환성 문제가 생길 수 있습니다. 영향을 받는 도메인을 먼저 확인한 뒤 현재 코어가 지원하는 fake-ip-filter 방식에 맞춰 예외를 추가하세요. 변경 후에는 관련 앱을 다시 시작하고, 필요하면 DNS 캐시를 비운 다음 DNS 모드를 바꿔야 하는지 판단합니다.

먼저 어떤 도메인을 어떤 DNS 서버가 처리해야 하는지 기대하는 동작을 정하세요. 그런 다음 클라이언트의 DNS 설정, TUN의 DNS 가로채기 여부, 브라우저의 보안 DNS가 별도 경로를 사용하는지 확인합니다. 테스트 사이트에 표시되는 DNS 서버 이름이나 지역은 단서일 뿐, 그것만으로 결론을 내릴 수는 없습니다. 코어 로그와 시스템 DNS 설정을 살펴보고, 필요한 경우 패킷 캡처로 실제 요청을 확인하세요. 규칙상 직접 연결이 허용돼 로컬 DNS 조회가 발생하더라도 설정 의도에 어긋나지 않을 수 있습니다.

먼저 네트워크가 다시 연결될 때까지 기다린 다음 새 요청을 시도하세요. 네트워크를 바꾸면 기존 TCP 연결, DNS 캐시, TUN 경로가 잠시 작동하지 않을 수 있습니다. 기존 연결을 닫고, 노드 속도를 다시 측정하고, 현재 프록시 처리 방식을 다시 활성화한 뒤에도 해결되지 않으면 클라이언트를 재시작하세요. 로컬 네트워크를 공유 중이라면 컴퓨터 IP가 바뀌었는지도 확인합니다. 절전 모드에서 깨어날 때마다 문제가 반복되면 시스템 버전, 코어 로그, 복귀 시간을 기록해 네트워크 드라이버 문제인지 클라이언트 상태 복구 문제인지 구분하세요.

먼저 업데이트 로그의 상태를 확인하세요. 401이나 403은 인증, 취소된 링크, 접근 정책과 관련된 경우가 많고, 404는 주소가 변경됐을 수 있습니다. 시간 초과라면 네트워크와 구독 도메인의 DNS 조회를 확인하세요. 상태 코드만으로 서비스가 만료됐다고 단정하지 말고 제공업체 페이지에 로그인해 확인해야 합니다. 구독을 다운로드하려면 현재 사용할 수 없는 노드가 필요한 경우, 출처를 확인한 뒤 직접 연결로 업데이트하거나 사용 가능한 설정으로 먼저 전환해 보세요. 전체 구독 주소를 낯선 변환 서비스에 입력하지 마세요.

먼저 클라이언트의 프록시 처리를 잠시 끄고, 일반 네트워크에서 원래 직접 연결되던 사이트에 접속할 수 있는지 확인하세요. 그다음 코어가 실행 중인지, 구독이 유효한지, 시스템 시간이 정확한지 점검합니다. 노드 하나만 선택해 테스트하고 로그를 살펴 DNS 조회 실패, 연결 거부, 핸드셰이크 실패, 테스트 주소 시간 초과를 구분하세요. DNS, 포트, 실행 모드를 한꺼번에 바꾸지 말고 한 번에 하나씩 변경한 뒤 다시 테스트합니다. 원인을 찾기 전에는 설정 백업을 보관해 재설치로 단서를 잃지 않도록 하세요.

AppContainer를 사용하는 일부 앱은 네트워크 격리 때문에 로컬 루프백 프록시에 직접 연결할 수 없습니다. 먼저 일반 브라우저에서 같은 프록시가 정상 작동하는지 확인한 뒤, 클라이언트에 UWP 루프백 예외 기능이 있는지 살펴보고 필요한 앱에만 권한을 허용하세요. 이 작업에는 보통 관리자 권한이 필요하며, 앱을 다시 설치한 뒤에는 설정을 다시 확인해야 할 수 있습니다. 스토어 앱이 모두 UWP인 것은 아닙니다. TUN을 사용한다면 트래픽이 처리되는지도 별도로 확인하고, 모든 연결 실패를 루프백 문제로 단정하지 마세요.

먼저 시스템 네트워크 프록시 설정에서 남아 있는 수동 프록시나 자동 구성 스크립트를 끄세요. 기존 로컬 수신 포트의 서비스가 이미 중단됐을 수 있습니다. TUN을 켰었다면 클라이언트를 다시 실행해 정상적으로 TUN을 끄고, 라우팅이 복구될 때까지 기다린 다음 네트워크 어댑터의 DNS가 수동으로 지정된 상태인지 확인하세요. 회사나 기관에서 관리하는 기기의 관리 설정은 임의로 지우지 마세요. 복구 후 직접 연결을 다시 테스트하고 필요하면 네트워크에 재연결하세요. 다른 프로그램에도 영향을 줄 수 있는 전체 네트워크 초기화부터 실행하지 마세요.

먼저 현재 설정을 백업하고 시작 로그를 확인하세요. 설정 파싱 오류가 발생하면 YAML 들여쓰기, 중복 키, 프록시 그룹 참조, 코어가 지원하지 않는 필드를 중점적으로 살펴봅니다. 실행 직후 종료된다면 포트 점유 여부, 코어 파일의 손상 여부, 시스템 권한과 런타임도 확인하세요. 이전에 정상 작동했던 설정으로 교차 테스트할 수 있지만 데이터 폴더 전체를 바로 삭제하지는 마세요. 도움을 요청할 때는 클라이언트 이름과 시스템 아키텍처, 민감 정보를 가린 오류 내용을 제공하고 노드 비밀번호나 구독 인증 정보는 첨부하지 마세요.