Clash 자주 묻는 질문

Clash 클라이언트는 설정 가져오기, 프록시 그룹 선택, 연결 상태 확인 등의 인터페이스를 제공합니다. mihomo 커널은 설정을 해석하고 규칙을 매칭해 네트워크 연결을 처리합니다. 구독은 보통 서비스 제공자가 관리하며 노드나 전체 설정을 제공합니다. 클라이언트를 설치해도 프록시 서비스가 제공되는 것은 아닙니다. 문제를 해결할 때는 먼저 현재 활성화된 설정을 확인하고, 커널이 실행 중인지 확인한 다음 노드가 작동하는지 점검하세요. 구독 문제를 설치 문제로 오인하지 않도록 주의하세요.

규칙 모드는 설정에 있는 규칙을 위에서 아래로 적용하므로 일반적인 트래픽 분할에 적합합니다. 전역 모드는 커널에 들어온 연결을 전역 프록시 그룹에서 처리하지만, 해당 그룹에서 직접 연결을 선택할 수도 있습니다. 직접 연결 모드는 커널에 들어온 트래픽을 목적지에 바로 연결합니다. 전역 모드가 모든 앱의 트래픽을 자동으로 가져오는 것은 아닙니다. 특정 사이트에서 문제가 생기면 전역 모드로 잠시 바꿔 비교 테스트해 보세요. 테스트가 끝나면 규칙 모드로 되돌리고 연결 기록에서 실제로 적용된 규칙을 확인하세요.

시스템 프록시는 앱에 로컬 프록시 주소를 제공하며, 이 설정을 따르는 프로그램에만 적용됩니다. TUN 모드는 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 가져오므로 시스템 프록시를 사용하지 않는 일부 앱에도 적용할 수 있지만, 일반적으로 관리자 권한이나 서비스 모드가 필요합니다. 실제 적용 범위는 라우팅, 제외 항목, DNS, 시스템 제한에 따라 달라집니다. 설정과 노드를 먼저 시스템 프록시로 확인한 다음 앱에 필요한 경우 TUN을 활성화하세요. 여러 설정을 한꺼번에 바꾸면 문제 원인을 찾기 어려워질 수 있습니다.

지연 시간 테스트는 보통 지정된 테스트 주소에 한 번 요청을 보내는 데 걸리는 시간을 측정하며, 노드의 지속적인 대역폭을 나타내지는 않습니다. 동영상 재생과 다운로드 속도는 출구 서버 혼잡, 대상 사이트, 패킷 손실, 서비스 속도 제한, 로컬 Wi-Fi 환경에도 영향을 받습니다. 먼저 속도 테스트와 실제 앱이 같은 노드를 사용하는지 확인한 다음, 같은 파일이나 같은 동영상 화질로 비교하세요. 지연 시간이 가장 짧은 순서만으로 노드를 판단하지 말고, 테스트 주소나 네트워크가 다른 결과를 직접 비교하지도 마세요.

파일 확장자만으로 호환성을 판단할 수는 없습니다. 클라이언트마다 사용하는 커널이 다를 수 있고, 가져오는 과정에서 DNS, TUN, 규칙 설정을 추가할 수도 있습니다. 일부 프로토콜과 설정 항목은 특정 커널에서만 지원됩니다. 이전하기 전에 기존 설정과 로컬 오버라이드를 보관하고, 새 클라이언트의 커널 종류를 확인한 다음 파싱 로그에서 구체적인 항목 오류를 살펴보세요. 더 이상 유지 관리되지 않는 클라이언트라면 인식되지 않는 항목을 계속 삭제하기보다 지속적으로 관리되는 버전으로 이전하는 편이 좋습니다.

계정 관리 페이지나 웹 공유 주소가 아니라 구독 URL을 복사했는지 먼저 확인하고, URL 앞뒤에 공백이나 줄바꿈이 붙지 않았는지도 살펴보세요. 다음으로 업데이트 로그를 확인하세요. 로그인 페이지로 이동하거나 응답이 비어 있거나 지원하지 않는 형식이 반환되면 목록이 표시되지 않을 수 있습니다. 설정이 현재 사용 중으로 지정되어 있는지, 노드 제공자를 별도로 업데이트해야 하는지도 확인하세요. 전체 구독 URL에는 다른 사람이 구독 내용을 열람할 수 있는 접근 정보가 포함될 수 있으므로 공개 게시판에 올리지 마세요.

401 또는 403은 일반적으로 요청이 승인되지 않았음을 뜻하며, 서비스 제공자의 접근 제한으로 발생할 수도 있습니다. 먼저 서비스 계정 페이지에서 구독 유효 기간과 트래픽 잔여량을 확인하고, URL이 재설정되었는지 살펴본 뒤 새 주소를 복사해 업데이트하세요. 클라이언트의 구독 요청이 잘못된 규칙에 차단되지 않았는지, 시스템 시간이 정확한지도 확인하세요. 제한을 우회하려고 계속 재시도하지 마세요. 새 주소에서도 같은 상태 코드가 반환되면 오류 발생 시간과 상태 코드를 기록해 서비스 제공자에게 문의하고, URL의 접근 정보는 공개하지 마세요.

먼저 로그에서 오류가 발생한 줄 번호와 항목 이름을 확인한 뒤, 주변의 들여쓰기, 콜론, 목록의 하이픈, 따옴표 짝을 살펴보세요. YAML 들여쓰기에는 공백을 사용하고 탭을 섞지 마세요. 특수 문자가 포함된 값은 문법에 맞게 따옴표로 묶을 수 있습니다. 프록시 그룹이나 규칙 대상에서 오류가 발생했다면 참조한 이름이 실제로 존재하고 대소문자가 일치하는지 확인하세요. 수정 전에는 원본 파일을 저장하고 한 번에 한 곳만 바꾼 뒤 다시 불러오세요. 구독 업데이트로 수동 수정 내용이 덮어써질 수 있으므로 지속적으로 설정을 변경하려면 클라이언트의 오버라이드 기능을 사용하세요.

먼저 TUN을 끄고 시스템 프록시 모드에서 정상적으로 연결되는지 확인하세요. Windows에서는 클라이언트 안내에 따라 서비스 모드를 설치하거나 복구한 뒤 권한이 제대로 부여되었는지 확인하세요. macOS에서는 시스템이 요구하는 네트워크 확장 또는 VPN 권한을 확인하고, Linux에서는 TUN 장치와 프로세스에 필요한 권한을 확인하세요. 다른 VPN을 설치한 적이 있다면 잠시 연결을 끊고 가상 네트워크 어댑터 충돌 여부를 살펴보세요. 오류를 피하려고 보안 기능을 장기간 끄지 말고 로그에 표시된 권한, 드라이버, 장치 관련 안내에 따라 각각 조치하세요.

일부 UWP 앱은 네트워크 격리 제한 때문에 루프백 주소의 로컬 프록시에 직접 접근할 수 없습니다. 먼저 일반 브라우저가 같은 프록시로 인터넷에 연결되는지 확인한 다음, 클라이언트에 UWP 루프백 예외 도구가 있는지 살펴보고 필요한 앱에만 예외를 적용하세요. 예외를 허용해도 앱이 시스템 프록시를 반드시 사용하는 것은 아닙니다. 앱이 계속 프록시를 사용하지 않는다면 권한과 라우팅이 정상인지 확인한 뒤 TUN을 테스트할 수 있습니다. 앱을 업데이트하거나 다시 설치한 후에는 해당 패키지의 예외 상태를 다시 확인해야 할 수 있습니다.

구독 캐시 파일을 직접 수정하기보다 클라이언트에서 제공하는 규칙 오버라이드, 확장 설정, 병합 기능을 우선 사용하세요. 먼저 규칙에서 지정할 프록시 그룹이 실제로 있는지 확인한 다음, 더 구체적인 도메인 규칙을 포괄적인 규칙과 마지막 MATCH 앞에 배치하세요. 규칙은 처음 일치하는 항목이 적용되므로 MATCH 뒤에 있는 항목은 실행되지 않습니다. 저장 후 설정을 다시 불러오고 연결 기록에서 적용된 규칙과 정책을 확인하세요. 구독 업데이트 후에는 오버라이드가 계속 적용되는지도 살펴보세요.

현재 사용 중인 그룹이 자동 속도 테스트 유형인지, 수동 선택이 필요한 select 그룹인지 먼저 확인하세요. url-test는 설정된 테스트 주소, 간격, 시간 초과, 허용 오차를 기준으로 노드를 선택하며 실제 트래픽의 속도를 계속 측정하지는 않습니다. 그룹이 노드 제공자를 참조한다면 제공자가 업데이트되었는지도 확인하세요. 정책을 바꾼 뒤에도 기존 연결은 이전 노드를 계속 사용할 수 있습니다. 새 연결을 만들어 테스트하고, 필요한 경우 관련된 기존 연결만 종료하세요. 클라이언트 전체를 반복해서 재시작할 필요는 없습니다.

서비스 제공자가 제공하는 형식이 클라이언트 요구 형식과 다르고 클라이언트에서 직접 가져올 수 없을 때 구독 변환을 고려하세요. 변환 과정을 줄이려면 서비스 제공자에게 mihomo 또는 Clash 호환 설정을 먼저 요청하는 것이 좋습니다. 타사 변환 서비스는 전체 구독 URL을 볼 수 있으며 규칙, DNS, 프록시 그룹을 변경할 수도 있습니다. 사용하기 전에 처리 방식을 확인하고 변환 후에는 프로토콜 매개변수와 정책 참조를 점검하세요. 구독을 직접 가져올 수 있다면 인터페이스를 바꾸기 위해 별도로 변환할 필요는 없습니다.

클라이언트의 연결 화면에서 대상 도메인이나 프로세스를 찾아 적용된 규칙, 정책 체인, 출구 노드를 확인하고 현재 프록시 그룹의 선택과 비교하세요. 브라우저에 표시된 출구 IP만으로는 다른 앱의 연결 경로를 알 수 없습니다. 연결 기록에 해당 앱이 없다면 시스템 프록시를 우회하는지 또는 TUN 제외 대상인지 먼저 확인하세요. 테스트 전에 앱의 기존 연결을 종료하고 요청을 다시 보내세요. 도메인 규칙을 판단할 때는 DNS 기록도 함께 확인하고 대상 IP만으로 결론을 내리지 마세요.

로컬 규칙 오버라이드, 프록시 그룹 선택, DNS 및 TUN 사용자 지정 설정과 보관해야 할 설정 파일을 백업하세요. 구독 URL과 설정에는 접근 인증 정보가 포함될 수 있으므로 안전한 곳에 보관하고 공개 저장소나 공개 클라우드 드라이브에 올리지 마세요. 이전 후에는 새 클라이언트가 설정을 불러올 수 있는지 확인한 뒤 사용자 지정 항목을 하나씩 복원하세요. 클라이언트마다 내부 데이터 디렉터리의 호환성이 다를 수 있으므로 내보내기 기능이나 읽을 수 있는 설정을 우선 사용하고 프로그램 데이터 디렉터리 전체를 그대로 덮어쓰지 마세요.

먼저 프록시를 끄고 기본 네트워크를 테스트해 시스템 시간, 게이트웨이, 일반 웹사이트 접속이 정상인지 확인하세요. 다음으로 현재 설정에 유효한 노드가 있는지, 구독이 만료되었는지, 테스트 주소에 접속할 수 있는지 살펴보세요. 다른 노드를 선택해 실제 대상 웹사이트로 비교하고, 필요하다면 휴대전화 핫스팟으로 바꿔 로컬 네트워크 제한과 서버 장애를 구분하세요. 통합 속도 테스트만 시간 초과되고 실제 접속은 정상이라면 테스트 주소와 테스트 규칙을 확인하세요. 모든 노드가 작동하지 않는다고 바로 단정하지 마세요.

먼저 커널이 실행 중인지, 로컬 수신 포트와 시스템 프록시에 입력된 포트가 일치하는지 확인하고 포트 충돌이 있는지도 살펴보세요. 그런 다음 브라우저에서 별도의 프록시 확장 프로그램을 사용 중인지, 시스템 설정을 따르지 않는 프록시 설정이 적용되어 있는지 확인하세요. 다른 VPN과 프록시 프로그램을 잠시 끄고 클라이언트 하나만 실행해 테스트하세요. 요청이 연결 기록에 나타나면 규칙, 노드, DNS를 계속 확인하세요. 기록이 전혀 없다면 앱에서 로컬 프록시까지의 연결 경로를 중점적으로 점검하세요.

먼저 연결 기록에서 대상 도메인을 찾아 REJECT로 차단되었는지, 실수로 직접 연결을 선택했는지, 사용할 수 없는 프록시 그룹으로 들어갔는지 확인하세요. 전역 모드와 작동이 확인된 노드 하나를 사용해 잠시 테스트해 보세요. 접속이 되면 트래픽 분할 경로에 차이가 있을 가능성이 있지만, 이것만으로 DNS가 정상이라고 단정할 수는 없습니다. 로그에 이름 해석 실패나 비정상 주소가 표시되면 DNS 상위 서버, 도메인 정책, 브라우저 보안 DNS를 확인하세요. 한 번에 한 항목만 변경하고 새 연결을 만들어 검증하세요.

먼저 어떤 도메인을 어느 리졸버에서 처리할지, DNS 요청이 프록시를 거쳐야 하는지 기대하는 동작을 정리하세요. 커널 DNS, TUN의 DNS 하이재킹 설정, 시스템 리졸버, 브라우저 보안 DNS를 확인해 여러 경로가 서로 다르게 작동하지 않도록 하세요. 브라우저의 암호화 DNS는 시스템 DNS 처리 경로를 우회할 수 있고, 시스템 프록시만으로 모든 DNS 요청이 처리되는 것도 아닙니다. 커널 로그와 네트워크 패킷 캡처를 함께 확인하세요. 검사 사이트에 표시되는 리졸버 위치는 참고 정보로만 활용해야 합니다.

먼저 시스템 프록시가 종료된 로컬 포트를 계속 가리키는지 확인하고, 해당 설정을 끄거나 종료 전 설정으로 복원하세요. TUN을 사용했다면 클라이언트를 다시 실행해 TUN을 끈 뒤 정상 종료하고, 남아 있는 가상 네트워크 어댑터, 라우팅, DNS 설정을 확인하세요. 조직 정책으로 관리되는 기기에서는 기존 프록시 설정을 임의로 변경하지 마세요. 복구 전에 원래 설정을 기록하고 네트워크 전체 초기화부터 실행하지 마세요. 일반적인 복구 방법으로 해결되지 않는 것이 분명할 때만 운영체제 안내에 따라 추가로 조치하세요.