Clash 자주 묻는 질문

클라이언트는 구독 관리, 모드 전환, 시스템 연동을 담당하고 커널은 설정을 해석해 규칙에 따라 연결을 처리합니다. mihomo는 Clash Meta의 흐름을 이어받은 커널 프로젝트이며, 화면에 표시되는 이름과 커널 이름이 다를 수 있습니다. 구독은 서비스 제공자가 관리하는 원격 설정 소스입니다. 클라이언트를 설치해도 사용할 수 있는 구독이 자동으로 생기지는 않습니다. 문제가 생기면 먼저 화면 조작, 커널 오류, 구독 내용 중 어느 단계에서 발생했는지 확인하세요.

구독 링크는 원격 설정을 다시 가져오는 주소이고, 로컬 YAML은 기기에 저장된 설정 사본입니다. 원격 구독을 업데이트하면 기존 프록시 항목, 프록시 그룹 또는 규칙이 바뀔 수 있지만, 로컬 파일은 보통 직접 수정하거나 다시 가져와야 합니다. 일부 링크는 프록시 항목만 제공하므로 전체 설정에 프록시 제공자로 연결해야 하며, 완전한 Profile처럼 바로 사용할 수 없습니다. 가져오기 전에 클라이언트가 요구하는 형식을 확인하고, 현재 정상 작동하는 설정 사본도 보관하세요.

일상적으로는 규칙 모드를 사용해 현재 설정된 규칙에 따라 연결을 적절한 정책으로 보냅니다. 전역 모드는 커널이 처리하는 연결을 전역 정책 그룹으로 보내며, 이 그룹에서 사용할 출구를 선택해야 합니다. 직접 연결 모드는 커널에 들어온 연결을 대상에 바로 연결합니다. 모드는 클라이언트가 처리하는 트래픽에만 적용되므로 기기의 모든 앱이 자동으로 연결되는 것은 아닙니다. 문제를 진단할 때 전역 모드로 잠시 바꿔 비교한 뒤 규칙 모드로 되돌리면 규칙 문제와 노드 문제를 구분하는 데 도움이 됩니다.

시스템 프록시는 운영체제에 HTTP 또는 SOCKS 프록시 주소를 등록해 해당 설정을 따르는 앱에서 사용합니다. TUN 모드는 가상 네트워크 인터페이스로 라우팅 조건에 맞는 트래픽을 처리하므로 시스템 프록시를 읽지 않는 프로그램에 적합하지만, 권한과 라우팅, DNS 설정이 필요합니다. 처음 설정할 때는 시스템 프록시만 켜서 확인한 다음 필요에 따라 TUN을 테스트하세요. 일부 클라이언트에서는 둘을 함께 사용할 수 있지만 필수는 아닙니다. 문제를 찾을 때는 변수를 줄이도록 각각 따로 테스트하세요.

Fake-IP 모드에서는 설정된 주소 풀의 매핑 주소를 앱에 반환합니다. 커널은 매핑 정보를 이용해 도메인을 식별하고 연결을 처리하므로 DNS 조회 결과가 실제 목적지 주소와 다를 수 있습니다. 이것만으로 DNS 조회가 실패한 것은 아닙니다. 일부 로컬 네트워크 서비스나 실제 주소에 의존하는 프로그램은 호환되지 않을 수 있으므로, 제외 범위를 넓히기보다 해당 도메인에 예외를 설정하세요. DNS 모드를 변경한 뒤에는 클라이언트 안내에 따라 설정을 다시 불러오고, 시스템과 앱에 남아 있는 이전 DNS 캐시도 정리해야 합니다.

설정 또는 구독 화면에서 새 항목이 정상적으로 다운로드됐는지 확인한 뒤 선택하거나 활성화하고 현재 설정으로 지정하세요. 버튼 이름은 클라이언트마다 다를 수 있습니다. 구독 주소를 저장했다고 해서 커널이 해당 설정을 불러온 것은 아닙니다. 이어서 로그의 로드 결과와 프록시 그룹 화면을 확인하세요. 다운로드는 됐는데 프록시 그룹이 없다면 내용에 프록시 항목만 있는지, 클라이언트와 형식이 호환되는지 확인합니다. 기존 설정은 보관하고 같은 주소를 반복해서 가져오지 마세요. 현재 활성화된 항목을 헷갈릴 수 있습니다.

먼저 기기 시간과 일반 네트워크 연결을 확인하고, 구독 주소가 완전한지 살펴보세요. 복사할 때 공백이나 줄바꿈이 함께 들어가지 않았는지도 확인해야 합니다. 다음으로 업데이트 로그를 확인합니다. 401이나 403은 인증 또는 접근 정책과 관련된 경우가 많고, 404는 주소가 만료됐을 가능성이 있으며, 시간 초과는 접속 경로를 점검해야 합니다. 상태 코드는 단서일 뿐이므로 제공자의 안내를 우선하세요. 클라이언트가 구독 다운로드 프록시를 지원한다면 직접 연결과 사용 가능한 프록시를 각각 테스트하세요. 그래도 실패하면 제공자에게 링크 상태를 문의하고, 인증 정보가 포함된 전체 주소를 공개하지 마세요.

먼저 로그에 표시된 필드, 프록시 유형, 줄 번호를 기록한 뒤 클라이언트에서 실제로 실행 중인 커널과 버전을 확인하세요. 새 설정에 이전 커널이 지원하지 않는 프로토콜이나 매개변수가 포함될 수 있으며, 화면을 업데이트해도 커널이 함께 업데이트된다는 보장은 없습니다. 직접 편집했다면 YAML 들여쓰기, 콜론 뒤 공백, 목록 계층을 확인하고 탭 문자는 사용하지 마세요. 구독 제공자에게 호환되는 형식으로 내보내 달라고 요청하거나 해당 설정을 지원하는 클라이언트를 사용하세요. 오류 필드를 무작정 지우고 원본 파일을 덮어쓰지 마세요.

먼저 클라이언트에서 서비스 모드를 설치하거나 시작해야 하는지 확인하고, 운영체제의 정상적인 권한 승인 절차에 따라 필요한 권한을 부여하세요. Windows에서는 백그라운드 서비스 상태를 확인하고, macOS에서는 시스템 권한 요청을 살펴보세요. Linux에서는 클라이언트 문서에 안내된 권한과 가상 인터페이스 요구 사항을 확인해야 합니다. 이어서 로그에서 권한 부족, 인터페이스 생성 실패, 라우팅 충돌이 있는지 확인하세요. 항상 최고 권한으로 실행하는 것은 일반적인 해결책이 아닙니다. 다른 VPN이나 TUN 프로그램을 먼저 종료한 다음 클라이언트 문서에 따라 서비스를 복구하세요.

이전하기 전에 구독 소스, 로컬 YAML, 클라이언트 오버라이드 내용을 각각 저장하고, 필요하다면 프록시 그룹 선택과 포트 설정도 기록하세요. 기존 클라이언트를 종료하고 시스템 프록시와 TUN을 끈 다음 새 클라이언트에서 사본을 가져옵니다. 사용 중인 커널이 설정의 프로토콜과 필드를 지원하는지도 확인하세요. 화면 설정이나 데이터베이스 형식이 다를 수 있으므로 애플리케이션 데이터 폴더 전체를 그대로 복사하지 마세요. 새 클라이언트에서 설정 로드, 연결 테스트, 재시작 후 확인까지 마친 뒤 기존 프로그램과 설정을 삭제할지 결정하세요.

구독 항목 설정에서 자동 업데이트와 업데이트 간격을 확인하고 제공자가 권장하는 빈도에 맞추세요. 너무 자주 요청하면 접근 제한이 걸릴 수 있습니다. 원격 구독은 보통 내용을 다시 다운로드하므로 다운로드된 파일을 직접 편집하면 수정 사항이 덮어써질 수 있습니다. 계속 유지해야 하는 규칙이나 DNS 변경은 클라이언트가 지원하는 오버라이드, 병합 또는 확장 설정에 넣는 편이 좋습니다. 업데이트 후에는 편집 화면만 보지 말고 최종 적용 설정과 로그를 확인해 사용자 지정 내용이 유지됐는지 점검하세요.

수동 선택 그룹은 보통 select에 해당하며 사용자가 현재 사용할 출구를 지정합니다. 자동 테스트 그룹은 보통 url-test에 해당하며 설정된 테스트 주소, 간격, 허용 오차에 따라 출구를 선택합니다. fallback은 사용 가능한 출구를 순서대로 사용하는 방식에 가깝고, 항상 가장 빠른 회선을 선택한다고 볼 수는 없습니다. 테스트 결과는 지정된 주소까지의 탐지 결과일 뿐 모든 서비스에서의 실제 체감 속도와 같지 않습니다. 전환 후에는 새 연결로 확인하세요. 기존에 오래 유지된 연결은 이전 출구를 계속 사용할 수 있습니다.

먼저 클라이언트에서 로컬 네트워크 연결 허용 여부, 수신 주소, 혼합 포트 설정을 확인하세요. 그런 다음 같은 신뢰할 수 있는 네트워크에 연결된 기기에서 컴퓨터의 로컬 IP 주소와 해당 포트를 입력합니다. 시스템 방화벽이 해당 네트워크에서 들어오는 연결을 허용하는지도 확인해야 합니다. 로컬 네트워크 수신만 켠다고 다른 기기에서 프록시를 자동으로 사용하는 것은 아닙니다. 접속할 기기에서 프록시를 설정하거나 명확한 게이트웨이 구성을 해야 합니다. 프록시 포트를 인터넷에 노출하지 말고, 사용이 끝나면 필요에 따라 로컬 네트워크 접근을 끄고 방화벽 예외를 정리하세요.

많은 명령줄 프로그램은 자체 옵션이나 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 같은 환경 변수만 읽고 데스크톱의 시스템 프록시 설정은 무시합니다. 먼저 클라이언트의 로컬 수신 주소와 포트를 확인한 뒤 사용 중인 도구가 지원하는 변수, 프록시 프로토콜, 대소문자 표기 규칙을 살펴보세요. HTTPS_PROXY 값에 반드시 https 프로토콜을 사용해야 하는 것도 아닙니다. 전역 시작 파일에 바로 추가하지 말고 현재 터미널 세션에서 먼저 테스트하세요. 테스트가 끝나면 임시 변수를 삭제해 클라이언트 종료 후에도 터미널이 이전 포트를 가리키지 않도록 하세요.

운영체제, 클라이언트 이름, 커널 버전, 오류가 발생한 시각, 재현 절차를 기록하고 해당 시간대의 설정 로드 또는 연결 오류만 발췌하세요. 공유하기 전에 구독 전체 주소, 액세스 토큰, 계정과 비밀번호, 개인 도메인 등 신원을 식별할 수 있는 정보를 삭제해야 합니다. 문제를 찾는 동안에는 로그 수준을 일시적으로 높일 수 있지만, 완료 후에는 평소 수준으로 되돌리세요. 설정 폴더 전체나 확인하지 않은 진단 압축 파일을 그대로 올리지 마세요. YAML을 보여줘야 한다면 필드 구조는 유지하되 민감한 값은 교육용 가짜 값으로 바꾸세요.

먼저 프록시를 끄고 기본 네트워크가 정상인지 확인한 다음 구독 업데이트가 성공했는지, 현재 프록시 그룹에 유효한 출구가 선택돼 있는지 살펴보세요. 같은 출구로 여러 대상에 접속해 보고, 가능하다면 다른 네트워크에서도 비교합니다. 로그에 도메인 조회 실패가 표시되면 DNS부터 확인하세요. 연결 설정 단계에서 시간 초과가 발생하면 노드 주소와 포트, 접속 경로를 점검합니다. 내장 테스트는 테스트 대상에 대한 결과일 뿐이며, 노드 하나의 시간 초과가 구독 전체의 만료를 의미하지는 않습니다. 처음부터 모든 설정을 초기화하지 마세요.

운영체제에 등록된 프록시 주소와 포트가 클라이언트의 실제 수신 값과 일치하는지 확인하고, 커널이 정상적으로 실행 중인지 살펴보세요. 이어서 브라우저 프록시 확장 프로그램, 별도 프록시 설정, PAC, 우회 목록을 점검합니다. 필요하면 임시 브라우저 프로필로 비교해 보세요. 클라이언트 연결 기록을 열고 새 요청을 보냅니다. 기록이 전혀 없다면 트래픽을 가져오는 경로를 먼저 확인하고, 기록은 있지만 직접 연결된다면 적용된 규칙을 살펴보세요. 페이지가 열리는지만으로 프록시 작동 여부를 판단하거나 DNS와 라우팅 설정을 한꺼번에 바꾸지 마세요.

AppContainer로 격리된 일부 Windows 앱은 로컬 루프백 프록시에 직접 접근할 수 없어 브라우저는 정상인데 특정 앱만 실패할 수 있습니다. 먼저 해당 앱이 실제로 로컬 프록시를 사용하는지 확인한 다음, 클라이언트에 UWP 루프백 또는 루프백 예외 도구가 있는지 살펴보세요. 필요한 앱에만 예외를 적용하고 도구의 안내에 따라 권한을 부여하세요. Microsoft 문서에 따라 CheckNetIsolation을 사용해 확인할 수도 있습니다. 모든 스토어 앱이 같은 제한을 받는 것은 아닙니다. 계속 실패하면 계정, 시스템 네트워크, 방화벽도 점검하세요.

먼저 TUN을 끄고 비교해 가상 인터페이스나 라우팅 처리와 관련된 문제인지 확인하세요. 다른 VPN, 가상 머신 네트워크, 보안 소프트웨어가 동시에 라우팅을 변경하는지도 살펴보고, 대상 서비스가 로컬 네트워크 검색이나 전용 DNS에 의존하는지 확인합니다. 필요하다면 사용 중인 커널과 클라이언트 문서에 따라 특정 네트워크 대역, 인터페이스 또는 도메인을 우회하도록 설정하세요. 한 번에 지나치게 넓은 주소 범위를 제외하지 마세요. 한 번에 하나씩 변경하고 테스트하며, 업무용 네트워크 설정은 먼저 네트워크 관리자의 지침을 따르세요.

먼저 운영체제에 로컬 포트를 가리키는 수동 프록시나 PAC 주소가 남아 있는지 확인하고, 더 이상 작동하지 않는 프록시 설정을 끄세요. 이전에 TUN을 사용했다면 기존 클라이언트를 다시 실행해 TUN과 시스템 프록시를 먼저 끈 다음 정상적으로 종료해 정리 작업을 진행합니다. 이어서 다른 VPN, 터미널 프록시 변수, DNS 설정이 여전히 적용 중인지 확인하세요. 네트워크 어댑터를 삭제하거나 모든 네트워크 설정을 초기화하지 마세요. 기본 네트워크에도 문제가 남아 있다면 시스템 진단 결과에 따라 처리하고 변경 전 설정을 기록해 두세요.