Clash 자주 묻는 질문

Clash는 일반적으로 규칙 기반 프록시 도구와 그 설정 생태계를 가리킵니다. Mihomo는 계속 발전하는 호환 코어로, 연결 처리와 규칙 매칭, DNS 등 네트워크 기능을 담당합니다. 클라이언트는 구독, 정책 그룹, 각종 설정을 관리하는 화면을 제공합니다. 화면에 표시되는 이름이 같아도 코어의 기능까지 같은 것은 아닙니다. 설정을 가져오기 전에 클라이언트에서 실제로 사용하는 코어와 지원하는 항목을 확인하세요. 설정을 파싱하는 중 오류가 나면 노드를 계속 바꾸기보다 기능 호환성부터 점검하는 편이 좋습니다.

클라이언트는 설정을 읽고 연결을 구성하는 프로그램이며, 설치만으로 프록시 서비스가 제공되지는 않습니다. 사용 권한이 있는 구독이나 설정 파일을 가져오고, 유효한 노드와 정책 그룹이 포함되어 있는지 확인해야 합니다. 먼저 설정 목록에 항목이 있는지 확인한 뒤 해당 설정을 활성화하고, 프록시 화면에서 사용할 노드를 선택하세요. 규칙만 있고 노드가 없는 파일로는 프록시 연결을 구성할 수 없습니다. 구독 만료 여부와 사용량, 서비스 상태는 구독 제공업체에 문의하세요.

평소에는 규칙에 따라 연결을 지정된 정책 그룹으로 보내는 규칙 모드를 사용하세요. 트래픽 분기 규칙이 문제인지 잠시 확인하려면 전역 모드로 전환해 사용 가능한 노드를 직접 선택한 다음, 테스트가 끝나면 규칙 모드로 돌아오면 됩니다. 직접 연결 모드는 일반적으로 코어에 전달된 연결을 대상에 바로 연결합니다. 여기서 전역 모드는 코어의 처리 방식일 뿐, 모든 앱의 트래픽이 코어로 전달된다는 뜻은 아닙니다. 앱의 트래픽이 코어를 거치는지는 시스템 프록시, 앱 설정 또는 TUN 사용 여부에 따라 달라집니다.

반드시 그렇지는 않습니다. 노드 테스트는 보통 코어가 해당 노드를 통해 지정된 테스트 주소에 접속하는 데 걸리는 시간을 측정하며, 그 요청의 응답 상태를 보여줄 뿐 대역폭을 측정하지는 않습니다. 테스트 주소와 네트워크 혼잡도, 대상 사이트의 위치에 따라 결과가 달라질 수 있습니다. 노드를 고를 때는 실제로 접속하려는 사이트나 다운로드 작업이 안정적으로 되는지 먼저 확인하세요. 짧은 간격으로 테스트를 반복하지 마세요. 여러 테스트를 동시에 실행하면 연결에 부담이 생겨 정상 노드도 일시적으로 시간 초과가 발생할 수 있습니다.

먼저 이 사이트의 다운로드 페이지에서 iOS 항목의 Clash Plus를 확인한 뒤, 페이지에 있는 App Store 링크를 통해 설치하세요. 제품 공식 웹사이트는 clashplus.io입니다. 처음 연결할 때는 시스템 안내에 따라 VPN 구성을 추가하도록 허용한 다음, 해당 클라이언트와 호환되는 구독을 가져오세요. 플랫폼마다 설정 항목과 화면 구성이 다를 수 있으므로 데스크톱의 서비스 설치, 시스템 프록시 포트, 드라이버 설정을 그대로 따라 하지 마세요. 각 기능의 지원 여부는 사용 중인 클라이언트의 안내를 확인하세요.

먼저 링크 전체를 다시 복사하고 앞뒤 공백, 줄바꿈, 메신저가 덧붙인 문장 부호를 제거하세요. 그런 다음 구독 제공업체가 안내한 Clash 형식 또는 호환 형식을 선택했는지 확인합니다. 오류가 다운로드 실패인지 파싱 실패인지도 살펴보세요. 다운로드 실패라면 네트워크와 링크 유효 기간, 로그인 상태를 확인하고, 파싱 실패라면 응답 내용이 설정 파일인지 확인하세요. 개인 인증 정보가 포함된 구독 링크를 공개 게시판에 올리지 마세요. 도움을 요청할 때는 민감한 정보를 제거한 오류 내용만 공유하세요.

현재 작동하는 설정은 그대로 두고, 바로 재설치하지 마세요. 갱신 요청과 노드 연결은 서로 다른 경로를 사용할 수 있으므로 기존 노드가 작동한다고 해서 구독 주소도 유효한 것은 아닙니다. 구독 만료 여부와 주소 변경 여부를 확인하고, 클라이언트에서 갱신 요청을 직접 연결 또는 프록시로 보낼 수 있는지 살펴본 뒤 수동으로 한 번 갱신하세요. 로그인 페이지나 오류 페이지가 반환되면 제공업체에 문의하세요. 기존 설정을 삭제하기 전에는 내보내 백업해 두어야 아직 작동하는 설정을 잃지 않습니다.

데스크톱에서는 먼저 시스템 프록시를 켜고 브라우저에서 접속이 되는지 확인한 뒤, 필요한 경우 TUN을 사용하세요. 시스템 프록시는 해당 설정을 따르는 앱에 적합합니다. TUN은 더 많은 네트워크 연결을 전달하는 기능으로, 추가 시스템 권한과 라우팅, DNS 설정이 필요할 수 있습니다. 처음 설정할 때 여러 트래픽 전달 방식을 동시에 켜면 문제 원인을 찾기 어려워집니다. 모바일 기기는 보통 시스템 VPN 인터페이스를 사용하므로 데스크톱과 똑같은 스위치를 찾을 필요는 없습니다. 현재 클라이언트의 연결 상태를 기준으로 확인하세요.

먼저 클라이언트의 서비스 모드나 보조 서비스 설정을 확인하고, 안내에 따라 필요한 서비스를 설치하거나 시작하세요. Windows에서는 관리자 권한이 필요할 수 있고, macOS에서는 보조 구성요소를 허용해야 할 수 있습니다. Linux에서는 TUN 장치 접근 권한이나 네트워크 관리 권한이 필요할 수 있습니다. 권한을 허용한 뒤 클라이언트를 다시 시작하고 TUN만 켜서 테스트하세요. 알림을 없애기 위해 시스템 보안 기능을 끄지는 마세요. 문제가 계속되면 서비스 시작 오류를 기록하고 해당 클라이언트가 지원하는 운영체제 버전을 확인하세요.

구독을 갱신하면 원격 설정을 다시 다운로드해 기존 파일을 대체하는 경우가 많습니다. 다운로드된 파일을 직접 수정하면 갱신 시 변경 사항이 사라질 수 있습니다. 계속 유지할 규칙은 클라이언트가 지원하는 로컬 덮어쓰기, 확장 스크립트 또는 설정 병합 기능에 넣고, 갱신 후에도 적용되는지 확인하세요. 덮어쓰기 기능의 이름과 병합 순서는 클라이언트마다 다르므로 추가 전에 백업하세요. 수정 후에는 최종 적용 설정에서 규칙 위치와 정책 그룹 이름이 올바른지 확인해야 합니다. 편집기에 저장 완료 메시지가 표시되는 것만으로는 충분하지 않습니다.

시스템 프록시는 해당 설정을 읽는 앱에만 적용됩니다. 자체 프록시 설정을 사용하는 프로그램도 있고, 일부 유형의 연결은 시스템 HTTP 프록시를 거치지 않습니다. 먼저 클라이언트의 연결 목록을 연 뒤 대상 앱에서 요청을 한 번 보내 보세요. 연결 기록이 없다면 앱 내부의 프록시 설정을 확인하거나 TUN 사용을 고려하세요. 기록은 있지만 직접 연결로 표시되면 모드와 적용된 규칙, 정책 그룹을 확인해야 합니다. 스위치가 켜져 있다는 이유만으로 트래픽이 제대로 전달된다고 판단하지 말고, 모든 직접 연결을 노드 오류로 간주하지도 마세요.

클라이언트의 연결 목록이나 로그를 연 다음 대상 웹사이트에 접속하고, 도메인이나 프로세스 이름으로 새 연결을 찾으세요. 어떤 규칙이 적용되었는지, 어떤 정책 그룹과 최종 노드를 사용했는지 확인해야 합니다. 웹페이지는 여러 도메인에 동시에 요청을 보낼 수 있으므로 주요 요청을 각각 점검하세요. 규칙은 대개 위에서 아래 순서로 적용됩니다. 범위가 넓은 규칙을 앞에 두면 뒤의 규칙보다 먼저 연결을 처리할 수 있습니다. 설정을 바꾼 뒤에는 요청을 다시 보내고, 필요하면 기존 연결을 종료하세요. 이전 연결이 재사용되면 변경 사항이 없는 것처럼 보일 수 있습니다.

휴대폰과 컴퓨터가 서로 접속할 수 있는 로컬 네트워크에 있는지 확인하고, 컴퓨터 클라이언트에서 LAN 연결을 허용한 다음 수신 주소와 혼합 포트를 확인하세요. 휴대폰의 Wi-Fi 프록시 설정에는 127.0.0.1이 아니라 컴퓨터의 로컬 IP 주소와 해당 포트를 입력해야 합니다. 필요한 경우 컴퓨터 방화벽에서 연결을 허용하고, 라우터에서 기기 간 통신 차단이 설정되어 있는지도 확인하세요. 공유하기 전에 적절한 접근 제어를 설정하고 프록시 포트를 공인 인터넷에 노출하지 마세요. 사용이 끝나면 더 이상 필요하지 않은 공유 기능을 끄세요.

먼저 구독에 포함된 DNS 설정을 그대로 사용하고, DNS 해석 오류나 특정 앱과의 호환성 문제가 확인된 경우에만 변경하세요. Fake-IP는 코어가 연결을 식별할 수 있도록 도메인을 가상 주소에 매핑하는 기능이며, 웹사이트의 실제 주소를 바꾸는 것은 아닙니다. DNS 모드와 상위 DNS 서버, 필터 목록을 변경할 때는 한 번에 하나씩만 바꾸고 연결을 다시 만들어 확인하세요. 특정 기기 검색이나 게임, 로컬 도메인에서 문제가 발생하면 해당 항목에 한해 필터링을 검토하세요. 모든 도메인에 적용되는 예외를 무작정 추가하지 마세요.

먼저 시스템 배터리 사용량을 확인해 소모가 클라이언트 때문인지 실제 데이터 전송 때문인지 구분하세요. Android에서 화면을 끈 뒤 연결이 끊기면 백그라운드 실행 권한과 배터리 최적화, 상시 알림 설정을 확인하세요. 설정 위치는 제조사마다 다릅니다. 배터리 소모가 크다면 불필요한 노드 상태 확인과 잦은 구독 갱신을 줄이고, 로그에서 반복 재연결이 발생하는지 확인하세요. iOS는 시스템 VPN 상태와 네트워크 전환을 함께 살펴보세요. Android의 백그라운드 유지 방법을 그대로 적용하지 말고, 설정을 바꿀 때마다 충분히 안정적으로 사용한 뒤 결과를 비교하세요.

먼저 프록시를 끄고 일반적으로 직접 접속할 수 있는 웹사이트에 연결해 기본 네트워크가 정상인지 확인한 다음, 기기의 시간과 구독 유효 상태를 점검하세요. 그다음 노드 하나를 선택해 대상 웹사이트에 실제로 접속하고, 속도 테스트를 반복하는 대신 연결 오류를 확인하세요. 실제 접속은 정상인데 테스트만 실패한다면 테스트 주소가 적절하지 않을 수 있습니다. 모든 연결이 실패하면 가능한 경우 다른 네트워크에서도 비교해 보세요. 노드 하나만 실패한 경우와 모든 노드가 실패한 경우는 점검 방향이 다릅니다. 처음부터 설정을 모두 지우거나 DNS, 포트, 규칙을 한꺼번에 변경하지 마세요.

먼저 TUN을 끄고 네트워크가 복구되는지 확인하세요. 문제가 계속되면 시스템 프록시를 끄고 클라이언트를 정상 종료한 다음, 시스템에 수동 프록시 설정이 남아 있는지 살펴보세요. 연결이 복구되면 TUN 로그에서 라우팅, DNS, 가상 네트워크 어댑터 오류를 확인하고 다른 VPN이나 네트워크 제어 도구를 일시 중지한 뒤 단독으로 테스트하세요. 알 수 없는 시스템 네트워크 어댑터를 삭제하거나 라우팅을 일괄 초기화하지 마세요. TUN을 다시 켤 때는 항목별로 확인하고, 어떤 스위치가 문제를 일으키는지 기록해 해당 설정을 점검하세요.

브라우저는 정상인데 샌드박스 네트워크 환경을 사용하는 스토어 앱이 로컬 프록시에 연결하지 못한다면 UWP 루프백 제한을 확인해 볼 수 있습니다. 다만 모든 스토어 앱이 같은 제한을 받는 것은 아닙니다. 우선 클라이언트에서 제공하는 루프백 예외 도구를 사용해 필요한 앱만 허용하세요. 또는 CheckNetIsolation LoopbackExempt -s 명령으로 현재 예외를 확인할 수 있습니다. 예외를 변경하려면 관리자 권한이 필요할 수 있습니다. 변경 후 대상 앱을 다시 시작하고 연결 기록에서 트래픽이 코어로 전달되는지 확인하세요.

먼저 클라이언트 두 개나 다른 프록시 프로세스가 동시에 실행 중인지 확인하고, 중복 실행 중인 프로그램을 종료하세요. 수신 포트를 바꿔야 한다면 사용 중이지 않은 포트를 선택한 다음 시스템 프록시와 브라우저 확장 프로그램, 해당 포트를 수동으로 입력한 앱도 함께 업데이트해야 합니다. mixed-port는 HTTP와 SOCKS5 연결을 모두 받을 수 있지만, 사용하는 쪽에서 올바른 프로토콜을 선택해야 합니다. 변경 후 코어를 다시 시작하고 포트가 정상적으로 열렸는지 확인하세요. 설정만 바꾸고 앱의 포트 설정을 갱신하지 않으면 연결은 계속 실패합니다.

문제가 발생한 시간과 클라이언트·운영체제 정보, 현재 모드, 대상 도메인, 실패한 요청 전후의 오류 로그를 기록하세요. 먼저 규칙 모드와 노드를 선택한 전역 모드를 비교하고, 브라우저의 프록시 확장 프로그램이나 암호화 DNS, 캐시가 결과에 영향을 주는지도 확인하세요. 공유하기 전에 구독 링크와 노드 인증 정보, 제어 인터페이스 키, 개인 주소 정보를 삭제하세요. 설정 전체를 올리는 것보다 문제와 관련된 짧은 로그만 공유하는 편이 원인을 찾기 쉽고 민감한 정보 노출도 줄일 수 있습니다.