헬프 센터: Clash 자주 묻는 문제 해결 가이드

클라이언트는 트래픽을 분배하는 도구일 뿐입니다: 설정을 읽고 규칙에 따라 각 연결을 직접 연결할지 프록시를 거칠지 결정합니다. 노드는 구독 제공자(서비스 업체 또는 자체 구축한 서버)가 제공하며, 클라이언트 자체에는 노드가 포함되어 있지 않습니다.

그래서 클라이언트를 설치한 후에도 구독을 가져와야 실제로 사용할 수 있는 출구가 생깁니다. 두 가지 모두 필요하며 순서도 정해져 있습니다: 먼저 껍데기를 설치하고, 그다음 알맹이를 넣습니다.

규칙 모드는 설정에 있는 규칙을 하나씩 확인해 직접 연결할 트래픽은 직접 연결하고 나머지는 프록시를 거치게 하는, 평소에 쓰는 기본 모드입니다. 전역 모드는 규칙을 보지 않고 모든 트래픽을 프록시로 보내며, 직접 연결 모드는 프록시를 잠시 끈 것과 같습니다.

사용 팁: 평소에는 규칙 모드를 걸어 두고, '규칙이 매칭되지 않은 것 같다'는 의심이 들 때만 잠깐 전역 모드로 바꿔 확인한 뒤 다시 되돌리세요. 전역 모드를 계속 켜 두면 트래픽이 낭비되고 원래 직접 연결됐어야 할 접속까지 느려집니다.

Clash 계열 클라이언트가 기본으로 사용하는 로컬 혼합 프록시 포트로, HTTP와 SOCKS5가 하나의 포트를 함께 사용합니다. 앱이 트래픽을 127.0.0.1:7890으로 넘기면 코어가 규칙에 따라 다시 전달합니다.

포트 번호는 설정에서 변경할 수 있습니다. 변경한 뒤에는 시스템 프록시나 다른 앱에 입력한 포트 값도 함께 갱신해야 하며, 그렇지 않으면 '클라이언트는 켜져 있는데 트래픽이 안 들어온다'는 겉보기 오류가 생길 수 있습니다.

코어(현재 주류는 mihomo)는 프로토콜, 규칙 매칭, 트래픽 전달을 담당하는 엔진과 같은 존재이고, Clash Plus나 Clash Verge Rev 같은 클라이언트는 그 위에 씌운 조작용 껍데기로 구독 관리, 스위치, 인터페이스를 담당합니다.

서로 다른 클라이언트라도 설정 형식은 대체로 호환되는데, 밑에서 돌아가는 것이 같은 계열의 코어이기 때문입니다. 껍데기는 사용 습관에 따라 고르면 되며, 세부 차이는 비교 평가에서 확인할 수 있습니다.

이 사이트에 수록된 클라이언트는 모두 무료로 다운로드할 수 있으며, 대부분 프로젝트의 코드가 오픈소스로 공개되어 있습니다. 비용이 드는 것은 노드 구독 자체로, 이는 서비스 업체의 대역폭과 회선 비용이며 클라이언트와는 무관합니다.

가장 먼저 추천하는 것은 Clash Plus로, 인터페이스가 간단하고 mihomo 코어가 내장되어 있으며 Android 5.0 이상에서 설치할 수 있습니다. 더 많은 커스터마이징이 필요하다면 Clash Meta for Android나 FlClash를 선택할 수 있습니다.

각 클라이언트의 APK 다운로드 링크와 시스템 요구 사항은 다운로드 페이지의 Android 영역에 모여 있으며, 카드에 적힌 사양 설명을 보고 하나를 고르면 됩니다.

서비스 업체가 제공한 URL을 복사한 뒤 클라이언트의 '설정/구독' 페이지에서 'URL로 가져오기'를 선택하고, 붙여넣은 뒤 저장하고 한 번 업데이트합니다. 가져오기가 성공했다는 표시는 노드 목록에 내용이 나타나는 것입니다.

받은 것이 Clash 설정 직접 링크가 아니라 범용 공유 형식이라면, 먼저 구독 변환을 거친 뒤 가져와야 합니다. 형식 구분과 변환 방법은 구독 가져오기 튜토리얼에서 확인할 수 있습니다.

Android 클라이언트는 시스템 VPN 인터페이스(즉 TUN)를 통해 트래픽을 넘겨받으며, 처음 실행할 때는 반드시 '연결 요청' 권한 창이 나타납니다. '확인'을 누르면 되고, 이후 상태 표시줄에 열쇠 아이콘이 나타납니다.

거부하면 터널을 만들 수 없습니다. 실수로 거부했더라도 다시 설치할 필요 없이, 시스템 설정의 VPN 페이지에서 해당 앱을 찾아 다시 권한을 부여하면 됩니다.

노드 주소는 비정기적으로 교체되므로, 클라이언트의 자동 업데이트를 켜고 12~24시간 주기로 설정하는 것을 추천합니다. 연결이 안 될 때는 다른 점검을 하기 전에 먼저 구독을 수동으로 한 번 업데이트해 보세요.

업데이트 동작은 설정 텍스트 하나만 가져오는 것이라 트래픽 소모는 매우 적으니, 자주 업데이트한다고 트래픽이 많이 소모될까 걱정할 필요는 없습니다.

가능합니다. 설정은 YAML 순수 텍스트로, 규칙, 정책 그룹, DNS가 모두 그 안에 작성되어 있으며 어떤 텍스트 편집기로도 수정할 수 있습니다.

다만 구독 자동 업데이트가 수동으로 수정한 내용을 덮어쓸 수 있습니다. 장기적으로 커스터마이징하려면 클라이언트의 '오버라이드(Override)' 기능이나 로컬 설정 병합을 사용해 업데이트할 때마다 변경 사항이 자동으로 다시 적용되도록 하세요. 자세한 방법은 설정 심화에서 확인할 수 있습니다.

노드나 프록시 페이지에서 번개/속도 측정 버튼을 누르면, 클라이언트가 측정용 주소로 요청을 한 번 보내고 밀리초 수치를 표시합니다. 이 숫자는 '내 기기 → 노드 → 측정 서버'를 왕복하는 데 걸린 시간으로, 200ms 이내면 체감이 원활하고 500ms를 넘거나 타임아웃이 표시되면 다른 노드로 바꾸는 것이 좋습니다.

지연이 낮다고 대역폭이 크다는 뜻은 아니며, 응답이 빠르다는 것만 의미합니다. 노드를 고를 때 지연은 첫 번째 걸러내는 기준이며, 실제 속도는 회선 품질까지 봐야 합니다. 자세한 방법은 첫 연결 튜토리얼을 참고하세요.

세 단계로 확인합니다: ① 클라이언트의 연결 스위치가 켜져 있는지 확인, ② 속도 측정이 가능한 노드로 전환, ③ 임의의 IP 조회 페이지를 열어 표시되는 출구 IP와 지역이 원래 통신사가 아니라 노드가 위치한 곳으로 나오는지 확인합니다.

IP가 바뀌지 않았다면 시스템 프록시가 적용되지 않았거나 해당 앱이 프록시를 건너뛴 경우가 많습니다—아래 '문제 해결' 카테고리를 하나씩 대조해 확인하세요.

Android 클라이언트에는 대부분 '앱별 프록시' 설정이 있어 해당 앱을 화이트리스트나 블랙리스트에 추가하면 되며, 연결을 다시 시작하면 적용됩니다.

데스크톱에서는 규칙을 작성해야 합니다: 도메인 기준이면 DOMAIN-SUFFIX, 프로세스 이름 기준이면 PROCESS-NAME을 사용해 매칭 결과를 DIRECT나 특정 정책 그룹으로 지정합니다. 규칙 문법과 우선순위는 설정 심화에서 확인할 수 있습니다.

일부 프로그램(일부 게임, 명령줄 도구가 자주 그렇습니다)이 시스템 프록시 설정을 읽지 않을 때, TUN은 시스템 하단에 가상 네트워크 카드를 만들어 앱을 가리지 않고 모든 트래픽을 코어로 끌어들입니다.

Android 클라이언트는 원래부터 TUN 방식이라 별도로 켤 필요가 없고, 데스크톱에서 켜려면 관리자 권한이 필요하며 Fake-IP와 DNS 하이재킹을 함께 사용하는 것을 추천합니다. 조합 원리는 설정 심화 페이지의 해당 챕터에서 확인할 수 있습니다.

url-test 유형의 정책 그룹은 주기적으로 지연을 측정해 가장 빠른 노드로 자동 전환하며, fallback 유형은 순서대로 사용 가능한 첫 번째 노드를 찾습니다.

노드를 직접 고르기 귀찮다면 자주 쓰는 규칙을 이런 그룹으로 지정하면 됩니다. 측정 주기와 전환 허용치는 설정에서 조정할 수 있으며, 허용치를 크게 하면 노드 간 왔다갔다 하는 현상을 줄일 수 있습니다.

순서대로 네 단계: ① 기기 자체가 인터넷에 정상적으로 접속되는지, ② 구독 링크가 만료되었는지—브라우저로 URL을 직접 열어 텍스트를 받을 수 있는지 확인, ③ 프록시로 인해 루프가 생겼는지—구독을 업데이트할 때 프록시를 잠시 끄거나 구독 도메인을 직접 연결로 설정, ④ 서비스 업체가 링크를 변경했는지 확인합니다.

이 네 단계로 대부분의 문제를 찾을 수 있습니다. 모두 정상인데도 실패한다면 클라이언트의 UA 설정이 구독 서버 측에서 차단되고 있는지 확인해 보세요.

먼저 구독을 업데이트해 최신 노드를 받습니다. 그래도 전부 타임아웃이면 순서대로 확인합니다: 로컬 네트워크(모바일 데이터나 다른 Wi-Fi로 바꿔 시도), 측정 주소가 잘못 입력되지 않았는지, 구독 서비스가 만료되지 않았는지.

일부 노드가 타임아웃되는 것은 정상적인 교체이므로 신경 쓰지 않아도 되며, 전체가 빨간색으로 표시될 때만 위 순서대로 점검하면 됩니다.

시스템 프록시는 어디까지나 '권고'일 뿐이라 앱이 무시할 수 있습니다. 데스크톱의 해결 방법은 TUN 모드를 켜 시스템 계층에서 강제로 넘겨받는 것이고, Android에서는 먼저 앱별 프록시 목록을 확인해 대상 앱이 제외되어 있는지 살펴봐야 합니다.

Windows 스토어 앱은 별도의 루프백 제한도 함께 받으며, 처리 방법은 다음 항목에서 확인할 수 있습니다.

UWP 앱은 기본적으로 시스템 네트워크 격리에 의해 로컬 루프백 접근이 막혀 있어 127.0.0.1에도 접근하지 못하므로 로컬 프록시 포트를 이용할 수 없습니다. 이는 클라이언트의 오류가 아니라 시스템 설계 때문입니다.

시스템에 내장된 CheckNetIsolation 도구나 클라이언트의 'UWP 루프백 해제' 메뉴를 이용해 해당 앱을 허용하면 됩니다. 전체 절차와 확인 방법은 UWP 루프백 제한 해제 튜토리얼에서 확인할 수 있습니다.

다음을 순서대로 시도해 보세요: 지연이 낮은 노드로 변경, 정책 그룹을 url-test 자동 선택으로 전환, 구독에서 트래픽 배율이 높은 노드에 주의, 저녁 피크 시간대 피하기, 사용 중인 프로토콜 확인(일부 오래된 프로토콜은 피크 시간에 속도 제한을 받기 쉬움).

모든 노드가 느리다면 대부분 회선 쪽 문제이니 구독 서비스 업체에 문의해 확인하세요. 클라이언트 쪽에서 할 수 있는 조정은 여기까지입니다.