Clash 자주 묻는 질문

클라이언트는 설정 가져오기, 모드 전환, 연결 상태 표시를 담당하고, 커널은 설정을 해석하고 규칙을 적용해 프록시 연결을 수립합니다. Clash Meta는 확장 커널의 이전 명칭이며, 후속 프로젝트는 mihomo라는 이름을 사용합니다. 원래 Clash와는 지원 프로토콜 및 설정 항목이 완전히 같지 않습니다. 문제를 점검하기 전에 클라이언트의 정보 또는 커널 정보에서 두 이름을 확인하세요. 창 제목만으로 호환성을 판단하면 안 됩니다. 안내 문서의 메뉴 위치도 클라이언트마다 다를 수 있습니다.

클라이언트는 연결 및 트래픽 분배 도구이며, 프로그램을 설치했다고 프록시 서비스를 사용할 수 있는 것은 아닙니다. 직접 관리하는 서버 설정이나 서비스 제공업체가 발급한 유효한 구독을 가져온 다음 해당 설정을 활성화해야 합니다. 설정을 가져왔는데도 목록이 비어 있다면 규칙만 포함된 설정인지, 아직 불러오지 않은 프록시 프로바이더를 참조하는지, 실제로 해당 설정을 사용 중인지 확인하세요. 출처가 불분명한 공개 설정을 기본값으로 지정하지 마세요.

일반적으로는 규칙 모드를 사용해 규칙에 따라 연결을 직접 연결하거나 프록시 정책으로 보냅니다. 전역 모드는 커널에 들어온 연결을 전역 정책으로 처리하므로 짧은 비교 테스트에 적합합니다. 직접 연결 모드는 커널에 들어온 연결을 목적지에 직접 연결하도록 합니다. 세 모드는 커널 내부의 처리 방식만 바꾸며 클라이언트로 들어오지 않은 앱 트래픽까지 자동으로 가져오지는 않습니다. 전역 모드를 선택해도 시스템의 모든 프로그램이 프록시를 사용하는 것은 아니므로 시스템 프록시나 TUN 유입 경로를 확인해야 합니다.

지연 시간 테스트는 보통 지정된 테스트 주소에 한 번 요청할 뿐, 대상 사이트의 DNS 조회, 규칙 적용, 로그인 API, 지속적인 데이터 전송까지 확인하지는 않습니다. 먼저 연결 패널을 열고 대상에 접속할 때 연결 기록이 생기는지 확인한 뒤, 적용된 규칙과 최종 출구를 살펴보세요. 테스트는 성공했지만 서비스 이용에 실패한다면 같은 노드로 다른 대상에도 접속해 보고 직접 연결 결과와 비교하세요. 지연 시간 수치 하나만으로 노드 전체의 사용 가능 여부를 판단하지 말고, 지연 시간이 낮다고 다운로드 속도가 빠른 것도 아닙니다.

일부 기본 설정은 새 클라이언트에서도 사용할 수 있지만, 호환 여부는 설정 파일 확장자가 아니라 대상 커널에 따라 달라집니다. 이전하기 전에 기존 설정과 사용자 지정 규칙을 백업하고, 별도 설정에서 먼저 실행해 프로토콜 종류, 프록시 그룹 참조, 규칙 세트 경로, DNS 항목을 확인하세요. Clash for Windows는 유지 관리가 중단되었으므로 장기적으로 업데이트하며 사용하기에는 적합하지 않습니다. 대체 클라이언트를 선택할 때는 유지 관리 상태와 현재 구독 형식의 호환성을 함께 확인하세요.

요청 실패와 설정 해석 실패를 먼저 구분하세요. 시간 초과는 대개 접속 경로와 관련이 있고, 401 또는 403은 인증, 요청 제한, 링크 만료 등이 원인일 수 있습니다. 해석 오류라면 응답 내용이 웹페이지인지, 호환되지 않는 설정인지 확인하세요. 구독 만료 여부와 링크가 온전한지, 불필요한 공백이 포함되지 않았는지도 살펴보세요. 서비스 제공업체가 지원한다고 안내한 경우에만 요청 방식을 변경하세요. 브라우저에서 링크가 열린다고 클라이언트 요청도 성공하는 것은 아닙니다. 문제를 문의할 때는 전체 구독 주소와 인증 정보를 숨기세요.

오류가 발생한 줄 번호와 프로토콜 이름, 현재 커널 이름을 기록한 뒤 구독 제공업체가 요구하는 형식을 확인하세요. mihomo용 설정이 원래 Clash나 다른 클라이언트에서 바로 읽히는 것은 아니며, 이름이 같은 프로토콜도 확장 매개변수에 특정 버전이 필요할 수 있습니다. 오류가 난 항목을 하나씩 삭제하기보다는 대상 클라이언트에 맞는 구독을 다시 받는 편이 좋습니다. 구독 변환을 이용한다면 변환 서비스의 신뢰성을 먼저 확인하세요. 변환 서비스가 구독 내용과 접속 인증 정보를 볼 수 있기 때문입니다.

TUN은 가상 네트워크 인터페이스를 만들고 경로를 설정해야 하므로 일반적으로 클라이언트의 서비스 모드, 시스템 권한 또는 관리자 권한이 필요합니다. 먼저 커널이 정상적으로 실행 중인지 확인한 다음 클라이언트 안내에 따라 서비스를 설치하거나 복구하고, 시스템이 관련 구성 요소를 차단하지 않는지도 살펴보세요. 계속 실패하면 로그에 기록된 어댑터 또는 경로 오류를 확인하고 다른 VPN이나 가상 네트워크 도구와 충돌하는지 점검하세요. 네트워크 설정을 여러 개씩 반복해서 바꾸지 말고 한 번에 하나만 조정하세요. TUN을 끈 상태의 결과도 비교할 수 있도록 남겨 두세요.

Windows에서는 시스템 정보에서 프로세서와 시스템 종류를 확인할 수 있습니다. 일반적인 Intel 또는 AMD 데스크톱은 x64를 사용하며, ARM 기기는 클라이언트가 네이티브 설치 파일이나 호환 실행을 지원하는지 확인해야 합니다. macOS는 이 Mac에 관하여에서 Apple 칩과 Intel을 구분하세요. Android는 기기가 지원하는 ABI에 맞춰 선택해야 하며, 시스템 비트 수만 보고 추측하면 안 됩니다. 다운로드 페이지에서 제공되는 빌드를 확인하고 프로젝트의 시스템 요구 사항과 대조하세요. 한 플랫폼의 설치 파일 이름만 바꿔 다른 플랫폼에서 사용하지 마세요.

로그에서 사용 중인 포트가 프록시 포트인지, 혼합 포트인지, 컨트롤 인터페이스 포트인지 확인한 다음 해당 포트를 수신 중인 프로세스를 찾으세요. 다른 프록시 클라이언트가 실행 중이라면 알 수 없는 프로세스를 강제 종료하기보다 해당 클라이언트를 정상적으로 종료하는 편이 안전합니다. 포트를 바꿔야 한다면 실제로 적용되는 설정이나 클라이언트 덮어쓰기 항목에서 변경하고, 브라우저와 터미널, 시스템 프록시 주소도 함께 업데이트하세요. 변경 후 관련 연결을 다시 시작하고 기존 포트가 더 이상 사용되지 않는지 확인하세요. 화면 설정만 바꾸고 커널은 이전 설정을 읽는 상황을 피해야 합니다.

연결 패널을 연 뒤 대상 앱에서 새 네트워크 요청을 보내고, 해당 도메인이나 대상 주소 또는 프로세스 기록이 나타나는지 확인하세요. 그런 다음 적용된 규칙과 출구를 확인합니다. 기존의 장시간 연결은 노드를 바꿔도 바로 다시 연결되지 않을 수 있으므로 페이지를 새로 고치거나 앱 연결을 다시 시작해야 합니다. 시스템 프록시가 켜져 있는 것만으로 모든 앱이 해당 설정을 따른다고 볼 수는 없습니다. 기록이 없는 앱은 노드나 규칙을 바꾸기 전에 먼저 프록시 유입 경로를 확인하세요.

규칙은 보통 위에서 아래 순서로 적용되며, 먼저 일치한 항목이 정책을 결정합니다. 따라서 뒤에 있는 구체적인 규칙이 앞쪽의 포괄적인 규칙에 가려질 수 있습니다. 현재 규칙 모드인지, 사용자 지정 규칙이 최종 설정에 포함됐는지, 정책 이름이 프록시 그룹 이름과 정확히 일치하는지 확인한 뒤 연결 패널에서 실제로 적용된 규칙을 살펴보세요. 클라이언트가 덮어쓰기를 지원한다면 병합 순서도 확인해야 합니다. 원격 구독에서 생성된 파일을 직접 편집하면 다음 업데이트 때 변경 내용이 사라질 수 있으므로, 계속 유지할 설정은 영구 덮어쓰기에 넣으세요.

다른 기기에서 프록시 서버 주소를 클라이언트가 실행 중인 기기의 LAN 주소로 설정하고 실제 프록시 포트를 입력해야 합니다. 127.0.0.1을 입력하면 안 됩니다. 수신 주소가 LAN 접속을 허용하는지, 시스템 방화벽에서 해당 포트를 허용했는지, 라우터에서 클라이언트 격리가 켜져 있지 않은지도 확인하세요. 신뢰할 수 있는 네트워크에서만 이 기능을 켜고 필요에 따라 인증 및 접근 제한을 설정하세요. 프록시 포트나 컨트롤 인터페이스를 인터넷에 공개하지 마세요. 시스템 프록시를 설정해도 다른 기기의 모든 앱에 자동으로 적용되지는 않습니다.

프록시 그룹 선택은 보통 이후에 새로 생성되는 연결에 적용됩니다. 이미 연결된 다운로드, 동영상, 메신저 연결은 이전 출구를 계속 사용할 수 있습니다. 먼저 대상 연결이 속한 정책 그룹을 확인한 다음 필요에 따라 연결을 종료하거나 앱에서 새 요청을 보내세요. 설정에 정책 그룹이 여러 개 있다면 기본 그룹만 바꿔도 특정 사이트에는 적용되지 않을 수 있습니다. 브라우저에 표시되는 출구는 캐시나 백그라운드 연결의 영향을 받을 수도 있으므로 노드를 반복해서 클릭하기보다 연결 패널의 기록을 함께 확인하세요.

클라이언트 이름, 커널 정보, 운영체제, 오류 발생 시간, 재현 단계와 해당 시점 전후의 오류 로그를 남기세요. TUN, 시스템 프록시, 다른 VPN을 사용 중인지도 알려 주세요. 로그 수준은 문제를 재현하는 동안에만 일시적으로 높이고, 완료 후에는 평소 수준으로 되돌리세요. 공유하기 전에 구독 링크, 인증 매개변수, 노드 비밀번호, 컨트롤 인터페이스 키, 개인 접속 도메인을 숨기세요. 최소한의 재현 가능한 내용만 제출하고, 전체 설정을 공개 게시판에 그대로 올리거나 확인하지 않은 스크린샷을 업로드하지 마세요.

먼저 프록시를 끄고 기본 네트워크가 작동하는지 확인한 뒤 구독이 만료되지 않았는지, 시스템 시간이 올바른지, 커널 로그에 해석 또는 핸드셰이크 오류가 있는지 살펴보세요. 같은 설정을 현재 네트워크와 다른 신뢰할 수 있는 네트워크에서 각각 테스트하면 원인을 좁히는 데 도움이 됩니다. 노드 하나만 실패한다면 해당 노드 상태를 먼저 확인하세요. 모든 노드가 동시에 시간 초과되더라도 테스트 주소에 접속할 수 없는 경우가 있으므로 서버 전체 장애라고 단정할 수 없습니다. 각 테스트에서는 설정과 대상 주소를 고정하고 DNS, 모드, 노드를 동시에 바꾸지 마세요.

시스템 프록시의 주소와 포트가 현재 커널을 가리키는지 먼저 확인하고, 브라우저 확장 프로그램, 앱 자체 프록시 설정, 우회 목록이 시스템 설정을 덮어쓰는지도 살펴보세요. 일부 터미널 도구는 시스템 프록시를 읽지 않으므로 프록시 매개변수나 환경 변수를 별도로 설정해야 합니다. 이미 실행 중인 프로세스에는 이전 설정이 남아 있을 수 있습니다. 연결 패널에 기록이 전혀 없다면 먼저 트래픽 유입 경로를 해결하세요. 전역 모드는 트래픽을 강제로 가져오는 기능이 아닙니다. 커널에 들어온 연결만 처리하며 모든 앱이 시스템 프록시를 사용하도록 강제하지는 않습니다.

앱 컨테이너로 격리된 일부 Windows 앱은 기본적으로 로컬 루프백 주소에 접근할 수 없습니다. 그래서 브라우저는 되는데 특정 스토어 앱은 연결에 실패할 수 있습니다. 먼저 해당 앱이 실제로 시스템 프록시를 사용하는지, 프록시 포트가 열려 있는지 확인한 다음 클라이언트가 제공하는 루프백 예외 도구나 Windows의 CheckNetIsolation 도구로 해당 앱 패키지를 점검하세요. 필요한 앱에만 예외를 설정하고 모든 앱을 일괄 허용하지 않는 것이 좋습니다. TUN을 켠 뒤 문제가 해결되더라도 두 유입 경로의 차이를 기록하세요. 모든 연결 실패를 루프백 제한 탓으로 돌리면 안 됩니다.

먼저 도메인 이름을 어떤 DNS가 조회해야 하는지 정한 다음 앱 내 보안 DNS, 시스템 리졸버, 클라이언트 DNS, TUN의 DNS 가로채기가 기대한 대로 동작하는지 확인하세요. 브라우저 테스트 사이트에 표시된 DNS 출구는 참고 정보일 뿐 모든 앱의 조회 경로를 증명하지는 않습니다. 도메인마다 트래픽 분배 정책이 다를 수도 있습니다. 커널 로그와 연결 기록, 직접 제어할 수 있는 도메인 테스트를 함께 사용해 하나씩 확인하세요. DNS 설정 전체를 그대로 복사하지 말고, 특히 상위 DNS 서버에 접속할 수 있는지와 프록시 노드 도메인의 부트스트랩 조회가 되는지 확인해야 합니다.

그냥 무시하거나 출처가 불분명한 루트 인증서를 설치하면 안 됩니다. 일반적인 프록시 전달에는 브라우저의 HTTPS 내용을 복호화할 필요가 없습니다. 인증서 오류가 발생하면 시스템 시간, 대상 도메인, 인증서 체인을 확인하고 보안 프로그램의 HTTPS 검사, 포털 로그인 페이지, 비정상적인 DNS 응답이 있는지 살펴보세요. 프록시를 끈 경우, 신뢰할 수 있는 노드로 바꾼 경우, 다른 사이트에 접속한 경우를 비교하고 브라우저 오류 코드를 기록하세요. 계정이나 결제 페이지에서 오류가 발생했다면 민감한 정보를 입력하지 말고 오류 유형에 따라 원인을 확인하세요.