Clash 자주 묻는 질문

먼저 코어와 인터페이스를 구분해야 합니다. 코어는 설정을 읽고 규칙에 따라 연결을 전달하며, GUI 클라이언트는 구독 관리와 모드 전환, 시스템 설정을 담당합니다. mihomo는 Clash Meta에서 이름이 바뀐 코어 프로젝트로, 특정 데스크톱 앱을 뜻하지 않습니다. 문제를 확인할 때는 클라이언트 이름과 코어 버전을 함께 기록하세요. 인터페이스가 열려도 클라이언트가 실행된 것일 뿐, 코어가 포트를 정상적으로 열었다는 뜻은 아닙니다.

먼저 서비스 제공업체에서 받은 유효한 구독 링크를 준비하세요. 구독 링크로 서버 주소와 연결 매개변수, 정책 그룹을 가져오는 경우가 많으며, 클라이언트 자체에는 사용할 수 있는 프록시 서비스가 포함되어 있지 않습니다. 가져오기 전에 서비스 이용 기간과 트래픽 한도, 지원 형식을 확인하세요. 링크에는 접속 인증 정보가 포함될 수 있으므로 비밀번호처럼 관리해야 합니다. 도움을 요청할 때는 전체 링크와 계정 정보, 서버 인증 항목을 가리고 공개 댓글에 구독 링크를 붙여 넣지 마세요.

평소에는 규칙 모드를 선택해 설정의 규칙에 따라 요청을 프록시로 보내거나 직접 연결하세요. 전역 모드는 전체 정책에서 선택한 경로로 트래픽을 보내므로 잠깐 비교 테스트할 때 유용합니다. 다만 코어로 들어온 트래픽에만 적용되며, 선택한 경로가 반드시 프록시인 것은 아닙니다. 직접 연결 모드에서는 코어로 들어온 요청이 대상에 바로 연결됩니다. 모드를 바꿔도 시스템 프록시가 자동으로 켜지지는 않습니다. 테스트가 끝나면 원래 설정으로 되돌려 임시 설정을 계속 사용하지 않도록 하세요.

먼저 시스템 프록시를 켜고 브라우저가 연결되는지 확인하세요. 시스템 프록시는 운영체제에 프록시 주소를 등록하는 방식이며, 앱에서 이를 사용할지는 앱 구현에 따라 다릅니다. TUN은 가상 네트워크 인터페이스로, 라우팅을 통해 더 많은 앱의 트래픽을 처리할 수 있지만 권한이 필요하고 다른 VPN·라우팅·DNS 설정과 충돌할 수 있습니다. 특별한 이유가 없다면 TUN은 꺼 둔 채로 사용하세요. 시스템 프록시를 사용하지 않는 앱의 트래픽까지 처리해야 한다면 별도로 테스트하면 됩니다.

로컬 진입점과 원격 출구를 나누어 생각하면 이해하기 쉽습니다. 앱이 이 기기에서 열어 둔 포트에 연결하면, 코어가 규칙에 따라 요청을 대상에 직접 연결하거나 프록시 서버로 전달합니다. mixed-port는 HTTP와 SOCKS 프록시 요청을 모두 받는 혼합 포트입니다. 7890은 흔히 쓰이는 설정값일 뿐이므로 현재 클라이언트의 설정을 확인하세요. 127.0.0.1은 현재 기기를 가리킵니다. 휴대폰에 이 주소를 입력하면 컴퓨터가 아니라 휴대폰 자신을 가리킵니다.

먼저 구독 업데이트 로그를 열어 가져오기에 성공했는지 확인한 다음, 해당 설정이 선택되고 활성화되어 있는지 살펴보세요. 링크를 복사할 때 앞뒤 공백을 제거하고 계정 관리 페이지 주소를 잘못 사용하지 않도록 주의하세요. 가져오기는 성공했는데 노드가 없다면 로그인 페이지가 반환되었거나 형식이 호환되지 않거나 서비스 제공업체가 콘텐츠를 할당하지 않았을 수 있습니다. 웹페이지 HTML을 YAML 설정으로 가져오지 마세요. 서비스 제공업체에 mihomo 호환 구독 형식을 확인하고, 복구할 수 있도록 기존 설정을 보관하세요.

먼저 서비스 계정이 만료되었는지, 구독이 초기화되었는지 확인한 뒤 서비스 제공업체의 계정 페이지에서 링크를 다시 복사하세요. 401은 대개 인증과 관련이 있고, 403은 접근 제한이나 웹사이트 보안 장치 때문에 발생할 수 있으므로 상태 코드만으로 요금 미납이라고 단정할 수 없습니다. 브라우저에서는 가져오기가 되는데 클라이언트에서 실패한다면 업데이트 시간, 요청 방식, 서비스 제공업체가 요구하는 클라이언트 식별 정보를 확인하세요. 전체 링크를 공개된 곳에서 반복 테스트하지 말고, 인증 정보를 낯선 변환 서비스에 입력하지 마세요.

먼저 클라이언트 안내에 따라 서비스 구성 요소를 설치하거나 시스템 네트워크 권한을 승인한 뒤 TUN을 다시 켜세요. Windows에서는 서비스가 설치되어 실행 중인지 확인하고, macOS에서는 승인 대기 중인 네트워크 확장 또는 VPN 요청이 있는지 살펴보세요. Android에서는 VPN 연결을 허용했는지 확인하세요. 그런 다음 다른 VPN이 네트워크 트래픽 처리 경로를 점유하고 있는지 확인합니다. 시스템 보안 기능을 끄거나 네트워크 어댑터를 반복해서 삭제하지 마세요. 로그의 구체적인 오류를 보관한 뒤 권한·드라이버·라우팅 충돌 중 무엇이 원인인지 확인하세요.

먼저 현재 설정을 백업한 뒤 마지막으로 정상 작동했던 버전으로 되돌리세요. YAML은 들여쓰기로 계층을 표현하는 설정 형식이므로 공백을 사용하고 탭 문자를 섞지 마세요. 로그에 표시된 줄 번호를 참고해 콜론과 목록의 들여쓰기를 확인하세요. 로그에 address already in use가 표시되면 프록시 프로그램이 중복 실행 중인지 확인하고, 충돌하는 프로세스를 종료하거나 로컬 수신 포트를 변경하세요. 포트를 변경한 뒤에는 시스템 프록시와 앱에 설정된 프록시 주소도 함께 업데이트해야 합니다.

수정한 대상이 구독 원본 파일인지, 클라이언트에서 제공하는 오버라이드 설정인지 먼저 확인하세요. 구독 업데이트 시 설정 파일을 다시 내려받는 경우가 많아 다운로드한 파일을 직접 수정하면 변경 사항이 덮어써질 수 있습니다. 포트·DNS·사용자 지정 규칙을 유지하려면 클라이언트가 지원하는 오버라이드·병합·확장 설정 기능을 우선 사용하고, 규칙이 삽입되는 순서도 확인하세요. 클라이언트마다 병합 방식이 다르므로 저장 후에는 실제 적용된 설정과 코어 로그를 확인해야 합니다. 편집기 내용만 확인해서는 안 됩니다.

먼저 클라이언트의 연결 목록을 열고 테스트할 대상에 접속한 뒤 대상 도메인, 적용된 규칙, 최종 출구를 확인하세요. 시스템 프록시가 켜져 있어도 모든 앱이 프록시를 사용하는 것은 아닙니다. 연결 목록에 요청이 표시된다고 해서 반드시 프록시를 거친다는 뜻도 아닙니다. curl -I -x http://127.0.0.1:7890 https://example.com 명령으로 로컬 HTTP 진입점을 테스트할 수 있습니다. 포트는 실제 설정값으로 바꾸세요. 결과는 해당 요청에만 적용됩니다.

먼저 명령 하나에 프록시를 명시해 로컬 포트를 사용할 수 있는지 확인하고, 그다음 환경 변수 설정을 고려하세요. 많은 명령줄 도구가 시스템 프록시 설정을 읽지 않습니다. curl에서는 -x로 주소를 지정할 수 있으며, 다른 도구는 해당 도구의 프록시 옵션을 확인하세요. 환경 변수의 형식과 읽는 방식은 셸과 도구에 따라 다르므로 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY가 어디서나 통용된다고 볼 수는 없습니다. 클라이언트를 종료하거나 포트를 바꾼 뒤에는 이전 환경 변수를 정리하고 터미널을 다시 여세요.

먼저 규칙 순서를 확인하세요. 규칙은 보통 위에서 아래로 검사하며, 먼저 일치하는 규칙이 있으면 뒤쪽 항목은 실행되지 않습니다. 따라서 특정 도메인 규칙은 관련된 포괄 규칙과 MATCH 대체 규칙보다 앞에 두어야 합니다. 정책 그룹이 실제로 존재하는지, 대소문자가 일치하는지, 요청에 규칙과 대조할 도메인이 포함되어 있는지도 확인하세요. 연결 목록에 IP만 표시된다면 DNS와 도메인 식별을 추가로 점검하세요. 설정을 저장한 뒤 다시 불러오고 새 연결을 만들어 검증하세요.

먼저 설정에서 GEOIP 또는 GEOSITE 규칙을 실제로 사용하는지 확인한 다음, 클라이언트의 데이터 업데이트 메뉴를 이용하세요. GeoIP는 IP의 지리적 분류에, GeoSite는 도메인 목록 분류에 사용되며 서로 대체할 수 없습니다. 수동으로 설정해야 한다면 mihomo가 지원하는 geox-url, 자동 업데이트 옵션, 현재 데이터 형식이 서로 맞는지 확인하세요. 다운로드에 실패하면 구체적인 로그를 살펴보세요. 업데이트 후 관련 데이터를 다시 불러오거나 코어를 재시작한 뒤 연결 기록에서 규칙 적용 여부를 확인하세요.

신뢰할 수 있는 네트워크에서 LAN 연결 허용을 켜고 바인딩 주소, 방화벽, 프록시 인증을 확인하세요. 다른 기기에는 컴퓨터의 LAN IP 주소와 실제 수신 포트를 입력해야 하며 127.0.0.1을 입력하면 안 됩니다. 두 기기가 서로 통신할 수 있어야 하므로 게스트 네트워크나 무선 기기 격리 설정이 연결을 막을 수 있습니다. 수신 포트를 공용 인터넷에 노출하지 말고 사용이 끝나면 공유를 끄세요. LAN 기기가 HTTP 또는 SOCKS 프록시를 지원하는지도 각각 확인해야 합니다.

먼저 코어가 실행 중이며 로컬 포트가 시스템 설정과 일치하는지 확인하세요. 그런 다음 확장 프로그램, 별도 프록시 설정, 조직 정책이 브라우저 설정을 덮어쓰는지 살펴보세요. 프록시 관련 확장 프로그램을 잠시 끄고 새 브라우저 창에서 테스트하면서 연결 목록에 요청이 나타나는지 확인합니다. 기록이 없다면 우선 트래픽 진입점을 점검하세요. 기록은 있지만 직접 연결된다면 모드·규칙·정책 그룹을 확인하세요. 처음부터 DNS·구독·TUN을 한꺼번에 바꾸면 어떤 변경이 효과가 있었는지 판단하기 어렵습니다.

먼저 프록시를 끄고 기본 네트워크에서 일반 웹사이트에 접속할 수 있는지 확인하세요. 로그인해야 사용할 수 있는 공용 Wi-Fi인지도 살펴보세요. 그런 다음 서비스 계정 상태, 시스템 시간, 클라이언트 로그를 확인하고 다른 네트워크에서도 비교해 보세요. 시간 초과는 테스트가 제한 시간 안에 끝나지 않았다는 뜻일 뿐, 구독이 만료되었다는 증거는 아닙니다. 테스트 대상 주소에 접속할 수 없는 경우에도 결과가 달라질 수 있습니다. 특정 노드만 실패하면 해당 서버를 먼저 확인하고, 모든 노드가 실패하면 DNS·네트워크 제한·방화벽을 점검하세요.

먼저 실패한 대상이 웹사이트 도메인인지 프록시 서버 도메인인지 확인하세요. DNS는 도메인을 IP 주소로 변환합니다. 프록시 서버 자체의 도메인을 조회할 수 없다면 비슷한 노드로 바꿔도 해결되지 않을 수 있습니다. 로그에서 시간 초과·연결 거부·DNS 조회 반복 여부를 확인하고 상위 DNS 서버에 접속할 수 있는지 점검하세요. TUN 사용 중이라면 DNS 트래픽이 제대로 처리되는지도 확인해야 합니다. 여러 앱에서 동시에 DNS 처리를 켜지 마세요. 수정 전에 설정을 백업하고 한 번에 한 항목만 변경한 뒤 클라이언트 방식에 따라 캐시를 비우고 다시 테스트하세요.

먼저 문제가 발생한 앱이 실제로 앱 컨테이너 제한을 받는 앱인지 확인하세요. 스토어에서 설치한 모든 소프트웨어에 해당하는 것은 아닙니다. 일부 UWP 앱은 루프백 제한으로 로컬 프록시 포트에 접속하지 못합니다. 클라이언트에서 루프백 예외 도구를 제공한다면 필요한 앱에만 권한을 부여하세요. Windows의 CheckNetIsolation LoopbackExempt 도구로 확인한 뒤 정확한 패키지 패밀리 이름을 사용해 예외를 추가할 수도 있습니다. 일반적으로 관리자 권한이 필요합니다. 작업 후 대상 앱을 다시 시작하고 모든 앱에 일괄적으로 예외를 적용하지 마세요.

먼저 연결 정보가 남아 있는 문제와 네트워크 전환 문제를 구분하세요. Android에서는 VPN 상태, 백그라운드 실행 제한, 항상 사용 설정된 VPN을 확인하세요. iOS에서는 시스템 VPN 상태를 확인하고 연결을 다시 설정하세요. Wi-Fi와 모바일 네트워크를 전환한 뒤에는 네트워크가 안정될 때까지 기다렸다가 다시 연결하세요. 컴퓨터에서 클라이언트를 종료한 뒤 인터넷이 안 된다면 시스템 프록시가 중지된 로컬 포트를 계속 가리키는지 확인하세요. 네트워크를 복구한 뒤 클라이언트를 실행해 항목별로 테스트하고, 네트워크 설정 전체를 바로 초기화하지 마세요.