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

코어는 설정을 파싱하고 규칙을 매칭해 연결을 수립합니다. GUI 클라이언트는 구독 관리, 설정 전환, 로그 표시를 담당합니다. mihomo는 Clash.Meta의 개발 방향을 이어가지만, 지원하는 프로토콜과 필드는 기존 Clash와 완전히 같지 않습니다. 클라이언트에 따라 설정 메뉴가 다를 수 있으므로 문제를 확인할 때는 클라이언트 이름, 코어 종류, 운영체제를 함께 기록하세요. 화면 버전이 같더라도 두 기기의 프로토콜 지원 범위까지 같다고 볼 수는 없습니다.

클라이언트는 연결을 관리하는 도구이며, 설치 파일에는 보통 바로 사용할 수 있는 원격 연결 정보가 들어 있지 않습니다. 구독이나 설정 파일에는 서버 주소, 인증 정보, 프록시 그룹, 분기 규칙이 포함됩니다. 가져오기 전에 제공업체가 현재 코어에서 지원하는 형식인지 확인하고, 웹페이지 주소나 계정 관리 페이지를 구독 링크로 착각하지 마세요. 구독 주소에는 계정 정보가 포함될 수 있으므로 포럼이나 스크린샷, 온라인 변환 도구에 공개하지 마세요. 도움을 요청할 때는 민감한 정보를 삭제한 오류 내용만 공유하세요.

규칙 모드는 설정의 규칙을 순서대로 확인하고, 일치한 정책에 따라 프록시 또는 직접 연결을 사용합니다. 일상적인 사용에 적합합니다. 전역 모드는 코어로 들어오는 연결에 전역 정책을 적용하므로, 분기 규칙이 문제인지 잠깐 확인할 때 유용하지만 모든 앱의 트래픽을 자동으로 가져오지는 않습니다. 직접 연결 모드도 코어로 들어온 연결만 대상으로 하며, 클라이언트를 종료하는 기능은 아닙니다. 점검을 마치면 규칙 모드로 되돌리고, 전역 또는 규칙 프록시 그룹에 테스트용 항목이 선택된 상태는 아닌지 확인하세요.

시스템 프록시는 운영체제에 프록시 주소를 등록해 해당 설정을 따르는 앱에 적용합니다. 앱 자체 프록시를 사용하거나 시스템 프록시를 무시하는 프로그램도 있습니다. TUN은 가상 네트워크 어댑터와 라우팅을 이용해 조건에 맞는 트래픽을 처리하므로 다른 앱까지 적용해야 할 때 적합하지만, 권한·라우팅·DNS 설정이 필요합니다. 처음 설정할 때는 시스템 프록시로 구독이 작동하는지 먼저 확인한 뒤 필요에 따라 TUN을 켜세요. 두 기능을 동시에 켠다고 항상 더 나은 것은 아니므로, 문제가 생기면 각각 따로 테스트해 트래픽 경로가 뒤섞이지 않게 하세요.

클라이언트의 구독, 설정 또는 Profiles 페이지에서 URL 가져오기를 선택하고, 제공업체가 안내한 전체 구독 주소를 붙여 넣은 뒤 다운로드나 업데이트를 실행하세요. 설정 이름이 표시되어도 활성화된 것은 아닙니다. 현재 설정으로 지정하고, 프록시 그룹에 선택 가능한 아웃바운드가 표시되는지 확인한 다음 적절한 노드를 선택하세요. 이후 규칙 모드로 전환하고 시스템 프록시를 켠 뒤 브라우저에서 실제로 이용할 서비스를 열어 보세요. 파싱 오류가 표시되면 구독 형식부터 확인하고, 연결 비밀번호를 무작정 바꾸지 마세요.

먼저 코어 로그에서 권한 부족, 가상 네트워크 어댑터 생성 실패, 라우팅 추가 실패 중 무엇인지 확인하세요. Windows 클라이언트는 보통 서비스 모드를 설치하고 실행해야 합니다. macOS에서는 네트워크 확장을 승인하거나 관리자 권한을 부여해야 할 수 있고, Linux에서는 클라이언트 서비스와 네트워크 관리 권한에 따라 달라집니다. 클라이언트에서 제공하는 서비스 설치 메뉴를 우선 사용하고, 모든 프로그램을 계속 높은 권한으로 실행하지 마세요. 다른 VPN이나 가상 네트워크 어댑터 도구를 함께 사용 중이면 연결을 잠시 중지하고 테스트하세요. 권한 문제가 해결된 뒤 TUN 설정을 확인하면 됩니다.

오류 로그의 필드명과 줄 번호를 기록하고 주변 줄을 확인하세요. YAML 들여쓰기에는 공백을 사용하고 같은 단계에서는 들여쓰기를 통일해야 합니다. 목록 기호 뒤에는 공백이 필요하며, 콜론·따옴표·프록시 그룹 이름도 확인하세요. 알 수 없는 프록시 유형이나 지원하지 않는 필드 오류라면 들여쓰기만 고치지 말고 코어의 지원 여부를 확인해야 합니다. 먼저 설정을 백업한 뒤 한 번에 한 부분만 수정하고 다시 불러오세요. 구독으로 생성된 설정은 다음 업데이트 때 덮어써질 수 있으므로, 지속적으로 적용할 변경은 클라이언트가 지원하는 오버라이드나 병합 기능에 넣으세요.

시작 프로그램 등록은 클라이언트 실행을 시도하게 할 뿐, 시스템 프록시·TUN·백그라운드 서비스까지 함께 켜준다는 뜻은 아닙니다. 재부팅 후 클라이언트 프로세스와 코어가 실행 중인지 확인하고, 현재 설정이 로드됐는지, 시스템 프록시가 켜져 있는지, TUN 서비스가 정상인지 살펴보세요. 일부 데스크톱 운영체제의 자동 시작은 로그인 후 실행을 의미하며 로그인 전 실행을 뜻하지 않습니다. 네트워크 연결 전에 구독 업데이트가 실패했다면 연결이 완료된 뒤 직접 한 번 업데이트하세요. 시작 순서 문제를 구독 오류로 오해하지 않도록 합니다.

클라이언트의 규칙 오버라이드, 확장 설정 또는 설정 병합 기능을 우선 사용하고, 구독 다운로드로 생성된 임시 파일은 직접 수정하지 마세요. 규칙은 보통 위에서 아래 순서로 적용됩니다. 구체적인 도메인 규칙은 포괄적인 규칙과 최종 기본 규칙보다 앞에 두고, 대상 정책 이름은 기존 프록시 그룹과 정확히 일치시켜야 합니다. 저장 후 설정을 다시 불러오고 연결 목록에서 해당 요청에 어떤 규칙이 적용됐는지 확인하세요. 기존 연결은 이전 정책을 계속 사용할 수 있으므로 새 연결을 만들어 검증해야 합니다. 잘못 분기될 때 복원할 수 있도록 수정 전에 백업해 두세요.

지연 시간 테스트는 지정한 테스트 주소에 요청을 완료하는 데 걸리는 시간을 주로 측정합니다. 사용 가능한 대역폭과는 다르며 모든 서비스의 체감 속도를 보여주지도 않습니다. 다운로드 속도는 서버 부하, 회선 혼잡, 패킷 손실, 대상 사이트, 로컬 네트워크의 영향을 받습니다. 노드를 비교할 때는 같은 네트워크와 대상, 비슷한 시간대를 유지하세요. 먼저 서비스가 안정적으로 열리는지 확인한 뒤 전송 속도를 살펴보세요. 지연 시간이 가장 낮은 노드만 반복해서 선택하지 말고, 특정 사이트만 느리다면 실제 적용된 규칙과 출구 정책도 확인하세요.

두 기기가 서로 통신할 수 있는 같은 LAN에 연결되어 있어야 합니다. 컴퓨터에서 LAN 연결 허용을 켜고, 수신 주소가 로컬 루프백 주소로만 제한되지 않았는지 확인하세요. 방화벽에서는 신뢰할 수 있는 네트워크에만 프록시 포트를 허용합니다. 다른 기기에는 컴퓨터의 LAN IP와 실제 mixed-port 포트를 입력하세요. 127.0.0.1을 입력하면 안 됩니다. 수동 HTTP 프록시는 보통 해당 설정을 따르는 앱에만 적용되며 모든 트래픽을 처리하지는 않습니다. 사용 후에는 공유를 끄고, 공용 네트워크에서 접근 제어가 없는 프록시 포트를 열어 두지 마세요.

Fake-IP 모드는 도메인에 내부 매핑용 주소를 할당하고, 코어가 이후 연결을 해당 도메인과 연결해 규칙 분기를 돕습니다. 이 주소는 대상 서버의 실제 주소가 아니므로, 조회 결과만 보고 DNS 오류라고 판단해서는 안 됩니다. 프린터, NAS 또는 내부 도메인에 접속할 수 없다면 먼저 로컬 DNS와 도메인 접미사를 확인하세요. 그다음 코어 문서를 참고해 fake-ip-filter와 관련 DNS 정책을 설정합니다. 변경 후에는 관련 DNS 캐시를 비우고 새 연결을 만들어 테스트하세요. 이전 캐시 때문에 결과가 바뀌지 않은 것처럼 보일 수 있습니다.

먼저 기기의 시간과 기본 인터넷 연결을 확인한 뒤 구독 제공업체에서 계정 상태, 만료일, 링크 재발급 여부를 확인하세요. 401은 대개 인증 실패, 403은 요청 거부를 의미하지만 정확한 원인은 제공업체 안내를 따라야 합니다. 설정 내용 대신 로그인 페이지가 반환되면 올바른 구독 주소를 다시 발급받으세요. 시간 초과라면 구독 업데이트가 직접 연결로 다운로드되는지, 프록시를 거치는지 확인합니다. 전체 링크를 공개 페이지에 올리거나 출처가 불분명한 변환 사이트에 입력해 해결하려 하지 마세요.

먼저 프록시 연결을 끄고 로컬 네트워크 자체가 정상적으로 인터넷에 연결되는지 확인한 뒤, 설정 업데이트가 완료됐는지와 기기 시간이 정확한지 확인하세요. 테스트 주소에 접속할 수 없으면 모든 노드가 시간 초과로 표시될 수도 있으므로 실제 서비스 접속 결과와 코어 로그를 함께 살펴봐야 합니다. 노드 하나만 실패하면 해당 노드 상태를 확인하세요. 모든 연결이 DNS 조회나 핸드셰이크 단계에서 실패한다면 DNS, 인증 정보, 코어의 프로토콜 지원을 차례로 점검합니다. 원인을 구분할 수 있도록 한 번에 한 조건만 바꾸고 다른 VPN은 잠시 중지하세요. 포트·DNS·모드를 동시에 바꾸지 마세요.

먼저 클라이언트 연결 목록을 확인하세요. 기록은 있지만 직접 연결된다면 규칙과 정책 선택을 살펴보고, 기록 자체가 없다면 앱이 시스템 프록시를 사용하는지 확인합니다. 브라우저 확장 프로그램, 앱 자체 프록시 설정, 프록시 우회 목록이 시스템 설정을 덮어쓸 수 있습니다. 시스템의 프록시 주소와 포트가 현재 수신 주소와 일치하는지 확인하세요. 특히 mixed-port를 바꿨다면 함께 변경해야 합니다. 명령줄 도구는 별도의 프록시 환경 변수를 사용할 수도 있습니다. 일반 브라우저 요청이 코어에 들어오는지 확인한 뒤, 시스템 설정을 따르지 않는 앱에 TUN을 사용할지 검토하세요.

일부 AppContainer 앱은 네트워크 격리 때문에 로컬 루프백 프록시에 직접 연결할 수 없습니다. 먼저 일반 데스크톱 브라우저에서 같은 프록시로 대상 서비스에 접속되는지 확인하세요. 그런 다음 클라이언트가 제공하는 UWP 루프백 도구를 사용해 필요한 앱에만 루프백 예외를 추가합니다. 이 작업에는 보통 관리자 권한이 필요합니다. 스토어 앱이 모두 UWP인 것은 아니며, 모든 연결 실패가 루프백 제한 때문인 것도 아닙니다. 예외를 추가한 뒤에도 실패하면 연결 로그, 앱의 프록시 지원 여부, 방화벽 설정을 확인하세요. 모든 앱의 권한을 한꺼번에 허용하지 마세요.