Clash 자주 묻는 질문
및 문제 해결

먼저 클라이언트의 설정 페이지에서 구독을 가져온 뒤 설정을 활성화하고 정책 그룹을 선택합니다. 클라이언트는 창과 메뉴 막대, 시스템 연동 기능을 제공하고, mihomo 코어는 연결을 받아 DNS를 해석하고 규칙을 적용해 트래픽을 전달합니다. 구독에는 서버 정보가 포함되며 정책 그룹과 규칙이 들어 있는 경우도 있습니다. 클라이언트를 설치한다고 사용할 수 있는 프록시 서비스가 생기는 것은 아닙니다. 문제를 해결할 때는 창 설정, 코어 실행, 구독 내용 중 어느 부분에 문제가 있는지 먼저 구분해 불필요한 재설치를 피하세요.

일상적으로는 규칙 모드를 사용하고, 연결 페이지에서 실제로 적용된 규칙과 출구를 확인하세요. 규칙 모드는 설정에 따라 연결별로 직접 연결 또는 프록시를 선택합니다. 전역 모드는 코어에 들어온 연결에 전역 정책을 적용하지만, 사용할 출구는 별도로 선택해야 합니다. 직접 연결 모드는 대상에 바로 연결합니다. 전역 모드는 짧은 비교 테스트에 적합하며 앱 트래픽을 코어로 전달하는 기능을 대신하지는 않습니다. 앱의 연결이 코어에 들어오지 않는다면 모드를 바꿔도 결과는 달라지지 않습니다. 테스트가 끝나면 규칙 모드로 되돌리고 연결을 새로 만들어 기존 연결의 영향을 없애세요.

브라우저처럼 시스템 프록시 설정을 따르는 앱에는 먼저 시스템 프록시를 사용하세요. 시스템 프록시를 따르지 않는 앱이나 일부 UDP 트래픽까지 처리해야 한다면 TUN을 고려할 수 있습니다. 시스템 프록시는 운영체제의 프록시 설정을 바꾸고, TUN은 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 받아 처리하므로 관련 권한이 필요합니다. 두 기능을 함께 켰을 때의 동작은 클라이언트 구현과 라우팅 설정에 따라 달라집니다. 문제를 확인할 때는 한 번에 하나의 트래픽 경로만 테스트하고 연결 기록이 나타나는지 확인한 뒤 조합을 조정하세요. 다른 VPN이 기본 경로를 사용 중인지도 확인해야 합니다.

macOS에서는 Apple 메뉴의 ‘이 Mac에 관하여’를 열어 Apple 칩이면 Apple 칩용 설치 파일을, Intel 프로세서이면 Intel용 설치 파일을 선택하세요. Windows에서는 설정의 시스템 정보에서 시스템 종류를 확인하고, Android에서는 기기 아키텍처와 클라이언트 요구 사항에 맞는 패키지를 선택합니다. 다운로드 페이지의 클라이언트 안내와 배포처 요구 사항을 함께 확인하고, 특히 최소 지원 운영체제 버전을 살펴보세요. mihomo 코어 패키지는 주로 명령줄, 서버, 라우터 환경을 위한 것입니다. 그래픽 인터페이스가 필요하다면 창과 설정 관리 기능을 제공하는 클라이언트를 선택하세요.

클라이언트의 설정 페이지를 열고 새 설정을 만들거나 가져오기를 선택한 다음, 구독 URL 전체를 링크 입력란에 붙여 넣으세요. 다운로드가 완료되면 해당 설정을 현재 사용 항목으로 지정합니다. 로컬 파일은 파일 가져오기를 선택하거나, 클라이언트에서 지원하는 경우 config.yaml을 끌어다 놓으면 됩니다. 가져온 뒤에는 설정 이름과 오류 메시지를 확인하고 프록시 페이지에서 정책 그룹을 선택하세요. 클라이언트마다 버튼 이름은 조금씩 다를 수 있지만 설정 가져오기, 활성화, 출구 선택 순서로 진행해야 합니다. 구독 URL의 인증 정보는 그대로 유지하고 공개 게시판에는 올리지 마세요.

먼저 오류 메시지에 줄 번호가 표시되는지 확인한 다음, 다운로드한 파일이 Clash 또는 mihomo에서 인식할 수 있는 YAML인지 확인하세요. 로그인 페이지나 오류 웹페이지, 다른 클라이언트 전용 형식일 수도 있습니다. YAML 들여쓰기에는 공백을 사용하고 같은 단계의 항목은 들여쓰기를 맞춰야 합니다. 직접 수정할 때는 콜론 뒤 공백과 목록의 계층 구조에 특히 주의하세요. 일반 Base64 노드 목록은 완전한 설정 파일로 바로 사용할 수 없는 경우가 있으므로 서비스 제공자에게 맞는 구독 형식을 요청하세요. 수정 전에 원본을 복사해 두고, 수정 후 설정을 다시 불러오세요. 인증 정보가 포함된 설정 전체를 낯선 변환 사이트에 올리지 마세요.

먼저 TUN을 끄고 클라이언트 설정에서 서비스 모드, 보조 서비스 또는 권한 설치 메뉴를 찾아 안내에 따라 시스템 권한을 허용한 뒤 TUN을 다시 켜세요. Windows에서는 보통 관리자 권한이 있는 백그라운드 서비스를 설치하고 시작해야 합니다. macOS에서는 권한이 필요한 보조 프로그램을 승인해야 할 수 있으므로 클라이언트 안내를 따르세요. 그래도 실패하면 로그에서 권한, 장치 또는 라우팅 오류를 확인하고 다른 VPN을 잠시 종료한 뒤 다시 시도하세요. 권한 문제를 해결하려고 모든 앱을 장기간 높은 권한으로 실행하지 마세요. 조직에서 관리하는 기기라면 먼저 네트워크 및 보안 정책에서 해당 작업을 허용하는지 확인하세요.

먼저 클라이언트 설정에서 실제로 수신 중인 mixed-port와 수신 주소가 로컬 루프백 주소인지 확인하세요. 포트 사용 중 메시지가 표시되면 다른 프록시 프로세스를 종료하거나 사용 가능한 포트로 변경한 뒤, 해당 포트를 사용하는 앱 설정도 함께 수정하세요. 터미널 도구는 시스템 프록시 설정을 따르지 않을 수 있습니다. curl -x http://127.0.0.1:7890 https://example.com을 사용해 명시적 프록시 요청을 테스트하고, 포트 번호는 실제 설정값으로 바꾸세요. 환경 변수가 필요하다면 필요한 터미널 세션에서만 설정하고 테스트 후 삭제하세요. 로컬 접속을 위해 LAN 수신을 함부로 허용하지 마세요.

먼저 정책 그룹 유형을 확인하고 수동 선택이 필요한지 자동 감지를 사용할지 결정하세요. select는 수동으로 고른 항목을 유지하므로 출구를 고정할 때 적합합니다. url-test는 설정된 테스트 주소와 검사 주기에 따라 후보를 선택합니다. fallback은 순서대로 후보의 사용 가능 여부를 확인해 선택하며 장애 전환에 초점을 둡니다. 테스트 결과는 지정된 주소에 연결할 수 있는지만 보여 주며 모든 서비스의 상태를 나타내지는 않습니다. 특정 웹사이트가 열리지 않으면 출구 하나를 수동으로 고정해 비교한 뒤, 적용된 규칙의 정책 그룹을 확인하세요. 자동 전환으로 테스트 조건이 계속 바뀌지 않도록 주의해야 합니다.

매번 다시 다운로드되는 구독 파일을 직접 수정하지 말고, 클라이언트의 덮어쓰기, 설정 병합 또는 확장 규칙 메뉴에 사용자 설정을 저장하세요. 구독 업데이트는 보통 원격 설정을 교체하며, 로컬 수정 사항을 유지하는지는 클라이언트 구현에 따라 다릅니다. 먼저 적용되어야 하는 사용자 지정 규칙은 관련된 일반 규칙보다 앞에 배치하고, 참조하는 정책 그룹 이름이 실제로 존재하는지 확인하세요. 저장 후 최종 적용 설정을 확인하고 연결 페이지에서 규칙이 적용되는지 검증합니다. 클라이언트를 바꾸면 덮어쓰기 메뉴나 병합 문법이 달라질 수 있으니 새 클라이언트 안내에 따라 옮기세요.

클라이언트의 연결 페이지를 열고 대상 웹사이트에 다시 접속한 뒤 해당 도메인이나 대상 주소를 찾아 적용된 규칙, 정책 그룹, 최종 출구를 확인하세요. 새 연결 기록이 보이지 않는다면 분류 규칙을 계속 수정하기 전에 시스템 프록시나 TUN이 트래픽을 받아들이는지 확인하세요. 규칙을 바꾼 뒤에는 대상 앱의 기존 연결을 종료하고 다시 테스트해야 합니다. 이미 연결된 트래픽은 즉시 경로가 바뀌지 않는 경우가 많습니다. 브라우저 캐시, 앱 자체 프록시, 암호화 DNS도 확인 결과에 영향을 줄 수 있습니다. 필요하면 별도의 테스트 요청을 보내고 DNS 로그를 함께 확인해 도메인이 올바르게 인식되는지 살펴보세요.

먼저 문제가 Fake-IP 모드에서만 발생하는지 확인한 뒤, 로그에서 영향을 받는 실제 도메인을 찾아 꼭 필요한 도메인만 fake-ip-filter에 추가하세요. 저장 후 설정을 다시 불러오고 앱 연결을 새로 만드세요. 필터 규칙의 동작은 fake-ip-filter-mode 등의 설정에도 영향을 받으므로 현재 설정을 함께 확인해야 합니다. LAN 기기의 사설 IP 라우팅과 직접 연결 규칙도 올바른지 살펴보세요. DNS 모드를 바꾼 뒤에는 이전 조회 결과가 캐시에 남을 수 있으니 관련 앱을 다시 시작하고 시스템 DNS 캐시를 비우세요. 공용 도메인을 대량으로 제외하면 도메인 식별과 트래픽 분류 결과가 달라질 수 있으므로 피하세요.

먼저 기기 시간, 네트워크 연결, 서비스 제공자 계정 상태를 확인한 다음 업데이트 로그의 HTTP 상태 코드와 오류 내용을 살펴보세요. 401은 인증 정보가 없거나 만료된 경우가 많습니다. 403은 접근 제한과 관련될 수 있으며 정확한 원인은 제공자의 안내를 확인해야 합니다. 시간 초과가 발생하면 구독 주소 자체에 접속할 수 없는지, 현재 프록시 경로가 다운로드에 영향을 주는지 구분하세요. 클라이언트에서 업데이트 네트워크 경로를 선택할 수 있다면 직접 연결과 프록시를 각각 테스트하세요. 마지막으로 작동했던 설정은 보존하고 전체 내용을 먼저 삭제하지 마세요. 로그를 공유하기 전에는 구독 URL, 인증 정보, 서버 로그인 정보를 가리세요.

후보 출구 하나를 고정하고 로그에서 DNS 조회 실패, 연결 거부, 핸드셰이크 실패, 단순 시간 초과 중 무엇인지 확인한 뒤 다른 네트워크에서도 비교해 보세요. 클라이언트의 테스트 주소에 연결할 수 없어 테스트는 실패해도 일부 서비스는 작동할 수 있으므로 실제 대상 웹사이트도 함께 확인해야 합니다. 구독이 유효한지, 기기 시간이 정확한지 확인하고 보안 프로그램이나 방화벽이 코어 프로세스를 차단하는지도 살펴보세요. 같은 네트워크에서 모든 후보가 실패하면 먼저 기기와 네트워크 경로를 점검하세요. 일부 후보만 실패한다면 오류 발생 시각과 로그에서 민감 정보를 지운 뒤 서비스 제공자에게 문의하세요.

운영체제에서 현재 사용 중인 네트워크 연결의 프록시 설정을 확인해 주소와 포트가 실행 중인 클라이언트와 일치하는지 살펴보세요. 브라우저 확장 프로그램이나 별도 프록시 설정이 시스템 설정을 덮어쓰는지도 확인해야 합니다. 명시적 프록시 요청은 성공하지만 브라우저 연결 기록이 없다면 우선 앱의 프록시 경로를 점검하세요. 클라이언트를 종료한 뒤 인터넷이 안 된다면 시스템에 이미 수신이 중단된 포트를 가리키는 프록시 설정이 남아 있을 수 있습니다. 시스템 네트워크 설정에서 남은 프록시를 끄고 다시 시도하세요. macOS에서는 현재 사용 중인 네트워크 서비스를 확인하고, Windows에서는 사용자 프록시와 WinHTTP 설정을 구분해 불필요한 설정을 바꾸지 않도록 하세요.

먼저 문제가 발생한 앱이 실제로 AppContainer에서 실행되고 로컬 루프백 주소를 가리키는 시스템 프록시를 사용하는지 확인하세요. 클라이언트에 UWP 루프백 예외 도구가 있다면 권한을 허용한 뒤 프록시에 접근해야 하는 앱만 선택하고, 앱을 완전히 종료했다가 다시 실행하세요. 관리자 터미널에서 CheckNetIsolation LoopbackExempt -s를 실행해 기존 예외를 확인할 수도 있습니다. 예외를 추가할 때는 정확한 패키지 계열 이름이 필요합니다. 루프백 예외는 앱의 로컬 프록시 접근 제한만 해결하며 구독이나 DNS 문제를 고치지는 않습니다. TUN은 별도의 트래픽 처리 경로이므로 따로 검증해야 하며, 조직에서 관리하는 기기라면 관리 정책을 따르세요.