Clash 자주 묻는 질문

Clash는 처음에 프록시 코어와 설정 생태계를 가리켰습니다. Clash Meta는 파생 코어 프로젝트의 이전 이름이며, 이후 mihomo라는 이름으로 유지 관리되고 있습니다. 그래픽 클라이언트는 구독 가져오기, 정책 그룹 선택, 시스템 프록시 설정, 로그 표시를 담당하고, 코어는 설정을 해석하고 규칙을 적용해 연결을 만듭니다. 클라이언트 이름이 비슷해도 코어와 지원 프로토콜까지 같다는 뜻은 아닙니다. 문제를 해결하기 전에 정보 페이지에서 클라이언트 이름과 버전, 코어 버전을 확인한 뒤 해당 프로젝트의 설정을 기준으로 점검하세요. 다른 클라이언트의 화면을 그대로 참고하면 안 됩니다.

클라이언트는 실행 화면과 네트워크 처리 기능을 제공하며, 설정 파일은 프록시 서버, 정책 그룹, 규칙, DNS 설정을 정의합니다. 클라이언트만 설치한다고 연결할 수 있는 프록시 서버가 생기는 것은 아닙니다. 설정 파일이 있다면 설정 화면에서 URL 또는 로컬 파일로 가져온 뒤 활성화하고, 정책 그룹에 사용할 수 있는 항목이 표시되는지 확인하세요. 구독에는 접속 정보가 포함되는 경우가 많으므로 신뢰할 수 있는 출처에서만 받으세요. 전체 링크를 공개 게시판이나 온라인 변환 사이트, 문제 화면 캡처에 붙여 넣지 마세요.

평소에는 규칙 모드를 사용하세요. rules에 적힌 순서대로 연결을 DIRECT, 프록시 정책 그룹 또는 REJECT로 보냅니다. 전역 모드는 코어에 들어온 연결을 전역 정책으로 처리하므로 규칙이 결과에 영향을 주는지 잠시 비교할 때 유용합니다. 직접 연결 모드는 이미 가로챈 연결을 대상에 바로 연결합니다. 모드 선택은 트래픽 가로채기 설정과 다릅니다. 앱이 시스템 프록시, 명시적 프록시 또는 TUN을 사용하지 않으면 전역 모드로 바꿔도 해당 앱의 트래픽을 자동으로 가로채지 않습니다. 테스트가 끝나면 규칙 모드로 되돌리고 새 연결을 만들어 확인하세요.

시스템 프록시는 프록시 주소를 운영체제 설정에 지정하며, 해당 설정을 따르는 앱에서 주로 사용됩니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 조건에 맞는 트래픽을 가로채므로 시스템 프록시를 무시하는 프로그램에 적합합니다. 두 기능을 반드시 함께 켜야 하는 것은 아닙니다. 먼저 시스템 프록시로 브라우저 연결을 확인하고, 필요한 앱에 따라 TUN을 활성화해 한 번에 여러 설정을 바꾸지 마세요. TUN이 실제로 가로채는 범위는 라우팅, 제외 항목, DNS 설정에도 달려 있습니다. 스위치가 켜졌다는 이유만으로 모든 트래픽이 가로채졌다고 판단하면 안 됩니다.

대체로 프록시 서버, 정책 그룹, 일반 규칙은 재사용할 수 있지만, 대상 클라이언트의 코어가 같은 문법과 프로토콜을 지원해야 합니다. 네트워크 인터페이스 이름, 파일 경로, 스크립트, 외부 제어 인터페이스, TUN 관련 설정은 운영체제에 맞게 조정해야 하는 경우가 많습니다. 이전할 때는 원본 설정을 가져와 파싱 결과를 확인한 다음 트래픽 가로채기 기능을 별도로 켜세요. 이전 기기의 실행 디렉터리를 새 설치 경로에 그대로 복사해 덮어쓰지 마세요. 구독을 업데이트하면 로컬 수정 사항이 덮어써질 수 있으므로, 지속적으로 사용할 변경 사항은 클라이언트가 지원하는 덮어쓰기 또는 병합 설정에 넣는 편이 좋습니다.

먼저 설정 화면에서 전체 오류 메시지를 확인하세요. 시간 초과라면 네트워크 연결과 업데이트에 현재 프록시가 필요한지 점검합니다. HTTP 401 또는 403 오류는 구독 권한과 링크의 유효성을 확인하세요. 인증서 오류가 나면 시스템 시간을 먼저 맞춘 뒤 인증서 체인과 네트워크 환경을 점검하세요. 인증서 검증을 바로 끄면 안 됩니다. 파싱 오류라면 응답이 웹페이지나 로그인 안내, 다른 형식의 노드 목록이 아니라 Clash YAML인지 확인하세요. 링크를 다시 복사할 때 앞뒤 공백은 제거하고 전체 매개변수는 유지하되, 공개 로그에 링크가 노출되지 않도록 주의하세요.

먼저 클라이언트의 설정 검사 기능을 사용하고 오류가 표시된 줄에서 들여쓰기, 필드, 참조 문제를 확인하세요. YAML 계층은 공백으로 들여쓰고 탭은 사용하지 마세요. 정책 그룹이 참조하는 노드 이름과 규칙이 가리키는 정책 그룹 이름은 대소문자까지 정의된 이름과 일치해야 합니다. 지원되지 않는 프록시 유형이나 필드가 나오면 계속 재설치하기보다 코어 호환성을 확인하세요. 수정 전에는 원본 파일을 보관하고 한 번에 한 항목만 바꾼 뒤 다시 검사하세요. 파일을 가져올 수 있다는 것은 읽기에 성공했다는 뜻일 뿐입니다. 설정을 활성화하고 코어가 정상적으로 시작됐는지도 확인해야 합니다.

먼저 코어가 실행 중인지 확인한 다음 시스템 프록시 설정의 수신 주소와 포트가 클라이언트 설정과 일치하는지 살펴보세요. 7890은 흔히 쓰이는 혼합 포트의 예일 뿐, 모든 클라이언트의 현재 포트가 7890이라는 뜻은 아닙니다. 브라우저 프록시 확장 프로그램, 수동 프록시 설정, 시스템 우회 목록을 확인해 다른 설정이 클라이언트 설정을 덮어쓰지 않는지 점검하세요. 연결 화면을 열고 새 탭에서 대상 사이트에 접속해 해당 연결과 적용된 규칙이 표시되는지 확인합니다. 기록이 전혀 없으면 먼저 트래픽 가로채기 경로를 점검하세요. 연결이 DIRECT로 표시되면 노드만 바꾸지 말고 규칙과 정책을 확인하세요.

Windows에서는 먼저 TUN을 끄고 클라이언트에 서비스 모드 설치 또는 복구 메뉴가 있는지 확인하세요. 안내에 따라 권한을 승인한 뒤 클라이언트를 다시 시작합니다. 일부 클라이언트는 관리자 권한으로 실행해 관련 작업을 완료할 수도 있습니다. macOS와 Linux에서는 프로젝트 문서에 따라 네트워크 확장, 보조 서비스 또는 필요한 권한을 허용하세요. Windows 절차를 그대로 적용하면 안 됩니다. 서비스가 시작되지 않으면 로그의 구체적인 오류를 먼저 확인한 뒤 보안 소프트웨어 차단, 가상 네트워크 인터페이스, 다른 VPN과의 충돌을 점검하세요. 권한 문제를 해결한 뒤 TUN을 켜고, 설치를 반복하지 마세요.

현재 활성화된 설정이 방금 가져온 설정인지, 이름만 같은 다른 설정인지 먼저 확인하세요. proxy-providers를 사용한다면 제공자 리소스가 정상적으로 다운로드됐는지, 정책 그룹의 use, filter 또는 exclude-filter가 모든 항목을 제외하지 않았는지 점검하세요. 설정에 프록시 정의가 있다고 해서 모든 정책 그룹에 자동으로 표시되는 것은 아닙니다. 구독 응답이 불완전하거나 요금제가 만료됐거나 코어가 해당 프로토콜을 지원하지 않아 항목이 누락될 수도 있습니다. 원본 설정을 보관하고 업데이트 오류를 확인하세요. 사용자 지정 덮어쓰기를 잠시 끄면 구독 문제와 로컬 병합 문제를 구분하는 데 도움이 됩니다.

설정 화면에서 해당 구독의 편집 또는 업데이트 설정을 열고 자동 업데이트 간격과 업데이트 프록시 옵션을 찾으세요. 단위와 항목 이름은 클라이언트마다 다를 수 있으므로 화면 안내를 따르세요. 제공업체의 권장 사항에 맞춰 간격을 설정하고, 요청 제한에 걸릴 만큼 자주 업데이트하지 마세요. 직접 연결로 업데이트할 수 없지만 기존 프록시는 정상이라면 프록시를 통한 업데이트를 시도해 볼 수 있습니다. 반대로 구독 업데이트를 먼저 해야 연결할 수 있는 상황에서 이미 작동하지 않는 프록시를 업데이트 경로로 선택하면 순환 문제가 생깁니다. 수동 업데이트가 성공한 뒤 자동 업데이트 기록도 예상대로 실행되는지 확인하세요.

규칙은 순서대로 평가되며, 일치하는 규칙을 찾으면 보통 이후 규칙은 확인하지 않습니다. 구체적인 도메인 규칙을 포괄적인 규칙보다 앞에 두고 MATCH 기본 규칙은 마지막에 배치하세요. 예를 들어 DOMAIN-SUFFIX,github.com,Proxy를 사용하려면 설정에 Proxy라는 정책 그룹이 실제로 있어야 합니다. 구독 업데이트로 변경 사항이 사라지지 않도록 클라이언트의 규칙 덮어쓰기 기능으로 규칙을 추가하거나 앞쪽에 배치하세요. 저장한 뒤 설정을 다시 불러오고 새 연결을 만들어 실제로 적용된 규칙을 확인하세요. 기존 장시간 연결은 규칙을 바꿔도 새 경로로 즉시 전환되지 않을 수 있습니다.

연결 화면에서 대상 도메인, 프로세스 이름 또는 대상 주소로 필터링한 다음 적용된 규칙, 정책 체인, 최종 선택된 프록시를 확인하세요. 정책 그룹 이름은 선택을 시작하는 지점일 뿐 최종 연결 경로와 같지 않을 수 있습니다. 정책 그룹이 중첩되어 있다면 정책 체인을 따라가며 확인하세요. 테스트 전에 대상 앱의 기존 연결을 닫고 새 요청을 보내 연결 재사용으로 인한 영향을 줄이세요. 브라우저에 표시된 외부 IP만으로 알 수 있는 것은 해당 요청의 결과뿐입니다. 다른 앱, UDP 또는 모든 도메인이 같은 경로를 사용하는지까지 확인할 수는 없습니다.

먼저 클라이언트에서 로컬 네트워크 접근을 허용하고 수신 주소가 로컬 루프백에만 제한되지 않는지 확인하세요. 다른 기기에서는 클라이언트가 실행 중인 컴퓨터의 로컬 IP 주소와 실제 포트를 입력합니다. allow-lan: false는 로컬 네트워크 접근이 허용되지 않는다는 뜻이며, 구체적인 기본값은 현재 설정에 따라 다릅니다. 방화벽은 신뢰할 수 있는 사설 네트워크와 필요한 주소에만 허용하고, 코어가 지원한다면 인증도 설정하세요. 프록시 포트를 공용 인터넷에 노출하지 마세요. 테스트가 끝나면 불필요한 공유를 끄고 외부 제어 인터페이스가 함께 노출되지 않았는지도 확인하세요.

클라이언트와 코어 버전, 운영체제 버전, 발생 시각, 작업 순서, 구체적인 오류 유형은 남겨 두세요. 로그 수준은 보통 info로 설정하고, 문제를 재현할 때만 잠시 높인 뒤 원래대로 되돌려 불필요한 로그가 계속 쌓이지 않도록 합니다. 공유 전에는 구독 URL, 인증 매개변수, 비밀번호, 제어 인터페이스 키, 공개를 원하지 않는 접속 도메인과 주소를 가리세요. 설정 디렉터리 전체를 올리지 마세요. 문제와 관련된 최소한의 로그와 민감 정보를 제거한 설정 일부를 제공하고, 시스템 프록시와 TUN이 켜져 있었는지도 함께 적으세요.

노드 테스트는 코어가 지정된 테스트 주소에 한 번 요청하는 과정입니다. 시간 초과는 테스트 주소에 연결할 수 없거나, 이름 확인에 실패했거나, 서버 연결이 실패해서 발생할 수 있으므로 모든 연결이 작동하지 않는다는 뜻은 아닙니다. 먼저 열리는 웹페이지가 프록시 규칙에 일치했는지 확인하세요. DIRECT 연결이나 캐시된 페이지일 수 있습니다. 같은 노드로 여러 대상을 접속해 보고 오류가 이름 확인, 핸드셰이크, 데이터 전송 중 어느 단계에서 발생하는지 확인하세요. 모든 대상에 실패할 때 서버 상태, 구독 유효 기간, 로컬 네트워크를 점검합니다. 테스트 주소는 클라이언트 문서에 따라 조정할 수 있으며, 한 번의 테스트 결과만으로 설정을 삭제하지 마세요.

먼저 TUN을 끄고 기본 네트워크가 복구되는지 확인한 다음, 테스트할 때는 트래픽을 가로채는 도구 하나만 남겨 두세요. 다른 VPN, 가상 머신 네트워크 인터페이스, 보안 소프트웨어가 기본 라우팅이나 DNS를 함께 변경하면 트래픽 우회, 루프백, 이름 확인 오류가 발생할 수 있습니다. 로그에서 네트워크 인터페이스 생성, 라우팅 추가, DNS 수신 오류를 확인하고 서비스 권한, 포트 점유, 자동 라우팅 설정을 순서대로 점검하세요. 시스템 라우팅을 전부 삭제하지 마세요. 회사 VPN도 함께 사용해야 한다면 해당 VPN의 네트워크 요구 사항에 맞춰 제외할 서브넷을 설정하세요. 두 자동 라우팅 기능이 별도 설정 없이 함께 작동한다고 가정하면 안 됩니다.

먼저 어떤 도메인을 어떤 이름 확인 경로로 처리할지, DNS 연결은 직접 연결할지 프록시를 거칠지 기준을 정하세요. DNS 검사 페이지에는 DNS 리졸버의 외부 경로가 표시됩니다. 표시된 지역이 다르다는 이유만으로 누출이라고 단정할 수는 없습니다. 브라우저의 보안 DNS, 시스템 암호화 DNS, IPv6, TUN의 DNS 가로채기 설정이 이름 확인 요청을 클라이언트 밖으로 보낼 수 있습니다. 테스트할 때 이러한 설정을 하나씩 기록하고 관련 캐시를 지운 뒤 다시 조회하세요. 클라이언트 로그도 함께 확인해 요청 경로를 파악합니다. fake-ip, nameserver, 시스템 DNS를 무작정 동시에 바꾸면 어떤 변경이 영향을 줬는지 알기 어렵습니다.

앱 컨테이너 제한이 있는 일부 Windows 앱은 브라우저가 정상이어도 로컬 루프백 프록시에 직접 연결하지 못할 수 있습니다. 먼저 문제가 있는 앱이 실제로 시스템 프록시를 사용하는지 확인한 뒤 클라이언트에 UWP 루프백 예외 설정 기능이 있는지 살펴보세요. 수동으로 설정해야 한다면 관리자 권한으로 터미널을 열고 CheckNetIsolation LoopbackExempt -s를 실행해 현재 예외를 확인한 다음 실제 앱 패밀리 이름에 맞춰 설정하세요. 다른 앱의 이름을 그대로 복사하지 마세요. 신뢰할 수 있고 꼭 필요한 앱에만 권한을 부여하고 기기 관리 정책을 따르세요. 루프백 예외로 노드나 규칙 오류를 해결할 수는 없습니다.

종료 후 인터넷이 되지 않으면 시스템 프록시가 더 이상 수신하지 않는 로컬 포트를 계속 가리키는지 확인하세요. 남아 있는 수동 프록시 설정을 끄고 다시 시도합니다. TUN을 사용했다면 보조 서비스나 가상 인터페이스가 계속 실행 중인지도 확인하세요. 포트가 사용 중이면 클라이언트가 두 개 실행 중인지 먼저 살펴보고, 중복 실행된 인스턴스는 정상적으로 종료하세요. 정체를 알 수 없는 시스템 프로세스를 바로 종료하지 마세요. mixed-port를 바꿔야 한다면 시스템 프록시와 해당 포트를 수동으로 지정한 앱도 함께 업데이트하세요. 문제가 해결된 뒤에는 클라이언트의 정상 종료 절차를 사용해 강제 종료로 설정이 남는 일을 방지하세요.