Clash / mihomo · 질문 모음

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

구독, 트래픽 진입, 규칙, 아웃바운드 순서로 차근차근 확인하세요. 문제가 발생한 지점을 먼저 파악한 뒤 설정을 바꾸고, 한 번에 한 항목만 수정하면서 원래 설정을 복구할 수 있도록 보관하세요.

기본 개념

클라이언트, 코어, 서비스 설정의 역할을 먼저 구분해 설치 성공을 연결 완료로 착각하지 않도록 하세요.

Clash, mihomo, 클라이언트는 각각 어떤 역할을 하나요?

Clash는 일반적으로 프록시 코어와 관련 설정 생태계를 가리키며, mihomo는 이 생태계에서 계속 발전 중인 코어 프로젝트입니다. Clash Verge Rev, FlClash 등의 클라이언트는 설정 가져오기, 정책 선택, 시스템 연동 기능을 제공하고 실제 트래픽 처리는 코어가 담당합니다. 같은 설정을 가져올 수 있는지는 앱 이름만으로 판단할 수 없으며, 클라이언트에 포함된 코어 버전과 지원 필드에 따라 달라집니다. 호환성 문제를 문의할 때는 클라이언트 이름과 버전, 코어 버전을 함께 기록하세요.

클라이언트를 설치했는데 구독이나 설정이 왜 필요한가요?

클라이언트는 트래픽을 가로채고 규칙을 적용하는 기능을 제공하지만, 설치 파일만으로 프록시 서비스를 이용할 수 있는 것은 아닙니다. 실제로 연결하려면 보통 서비스 제공업체의 구독 링크나 직접 관리하는 프록시 서버 정보가 필요합니다. 가져온 뒤에는 설정이 활성화되었는지 확인하고, 정책 그룹에서 선택할 수 있는 아웃바운드가 있는지 살펴보세요. 일반 웹사이트 주소를 구독 주소로 착각하지 말고, 출처가 불분명한 온라인 변환 사이트에 구독 링크를 입력하지 마세요. 링크에 계정 리소스에 접근할 수 있는 인증 정보가 포함될 수 있습니다.

규칙 모드, 전역 모드, 직접 연결 모드는 어떻게 다른가요?

규칙 모드는 설정에 적힌 규칙 순서에 따라 아웃바운드를 결정하므로 웹사이트와 앱을 구분해 사용하는 데 적합합니다. 전역 모드는 코어가 처리하는 연결에 전역 정책을 일괄 적용하지만, 가로채지 않은 앱까지 프록시를 사용한다고 보장하지는 않습니다. 직접 연결 모드에서는 코어로 전달된 연결이 목적지에 바로 접속합니다. 문제를 확인할 때 잠시 전역 모드로 바꿔 비교해 볼 수 있지만, 테스트 후에는 원래 모드로 돌려놓으세요. 전역 모드에서는 되지만 규칙 모드에서는 안 된다면 규칙 매칭 결과와 해당 정책 그룹을 확인해야 합니다.

시스템 프록시와 TUN 모드를 함께 켜야 하나요?

시스템 프록시는 시스템 설정을 따르는 앱에 프록시 주소를 알리고, TUN은 가상 네트워크 인터페이스와 라우팅을 통해 더 많은 연결을 가로챕니다. 두 기능을 반드시 함께 켤 필요는 없으며 역할도 완전히 같지 않습니다. 처음 설정할 때는 시스템 프록시만 켜고 브라우저 연결을 확인한 다음, 게임이나 명령줄 도구 등 필요한 앱에 따라 TUN을 시도해 보세요. 일부 클라이언트는 두 기능을 함께 사용할 수 있지만, 문제가 생기면 한 번에 한 가지 방식만 사용하세요. 다른 VPN이나 프록시 도구까지 겹치면 원인을 찾기 어려워집니다.

Clash 무료 노드를 오래 사용할 수 있나요?

공개 공유된 프록시 아웃바운드는 언제든 작동을 멈출 수 있고, 운영 주체나 트래픽 정책, 유지 기간을 확인하기 어려운 경우가 많아 장기 사용을 기대하기 어렵습니다. 프록시는 웹사이트 자체의 암호화를 대신하지 않으므로 민감한 계정에 로그인할 때는 HTTPS가 정상인지 확인하고, 출처 불명의 인증서 설치 요구는 거부하세요. 연결이 실패하면 먼저 특정 아웃바운드 문제인지 로컬 트래픽 가로채기 문제인지 구분하세요. 아웃바운드를 바꾸려고 낯선 클라이언트를 반복해서 설치하지 마세요. 네트워크 서비스를 이용할 때는 현지 법률과 서비스 약관도 준수해야 합니다.

설치 및 설정

구독이 유효하고 설정을 불러올 수 있는지 먼저 확인한 다음 권한과 수신 포트를 살펴보세요. 설정이 정상적으로 시작되지 않았다면 정책을 바꾸는 것만으로 해결되지 않습니다.

구독이 만료되거나 업데이트가 실패하거나 403 오류가 나면 어떻게 하나요?

먼저 서비스 제공업체 계정 페이지에서 구독이 만료되었는지, 링크가 재설정되었는지 확인하세요. 복사 과정에서 공백이 들어갔거나 쿼리 매개변수가 빠지지 않았는지도 살펴보세요. 403은 보통 요청이 거부되었다는 뜻이지만, 접근 정책이나 클라이언트 식별 정보와 관련될 수도 있으므로 제공업체의 안내를 확인해야 합니다. 프록시를 통해 업데이트할 때만 실패한다면 클라이언트가 지원하는 경우 직접 연결로 업데이트해 보세요. 직접 연결이 되지 않으면 정상 작동을 확인한 아웃바운드를 사용하세요. 계속 실패하면 상태 코드와 발생 시간을 기록해 제공업체에 문의하고, 구독 링크 전체를 공개하지 마세요.

설정을 가져올 때 YAML 오류가 나거나 지원하지 않는 필드가 있다고 표시되면 어떻게 하나요?

먼저 파일 형식 오류인지 코어 호환성 문제인지 구분하세요. YAML은 들여쓰기 단계가 중요하므로 탭 대신 공백을 사용하고 콜론, 목록의 하이픈, 따옴표가 짝을 이루는지 확인하세요. 로그에 인식할 수 없는 필드가 표시되면 설정에 필요한 코어 종류와 현재 코어 버전을 비교하세요. 웹페이지에서 다운로드한 로그인 화면이나 오류 페이지는 설정 파일로 가져올 수 없습니다. 수정 전에 원본 파일을 보관하고 한 번에 한 곳만 바꾼 뒤 다시 확인하세요. 구독에서 생성된 설정은 업데이트 후 변경 사항이 사라지지 않도록 클라이언트의 오버라이드 기능으로 수정하는 것이 좋습니다.

TUN을 켤 수 없고 권한 부족이나 서비스 미설치 오류가 표시되면 어떻게 하나요?

먼저 현재 클라이언트와 운영체제가 선택한 TUN 구현을 지원하는지 확인하세요. Windows 클라이언트는 보통 제공되는 서비스 모드를 설치하고 실행해야 합니다. macOS에서는 시스템 안내에 따라 보조 서비스를 승인해야 할 수 있으며, Linux에서는 클라이언트 문서에 따라 가상 인터페이스와 라우팅에 필요한 권한을 설정해야 합니다. 모든 프로그램에 무조건 높은 권한을 부여하지 마세요. 권한을 승인한 뒤 코어를 다시 시작하고 인터페이스가 생성되었는지 확인하세요. 계속 실패하면 다른 VPN을 끄고 다시 시도한 뒤, 인터페이스 생성이나 라우트 추가 시 표시된 오류 원문을 기록하세요.

시스템 프록시를 켰는데 브라우저가 프록시를 사용하지 않으면 어떻게 하나요?

시스템 프록시 주소가 로컬 컴퓨터를 가리키는지, 포트가 현재 설정의 수신 포트와 일치하는지 확인한 다음 코어가 실행 중인지 살펴보세요. 브라우저 확장 프로그램, 별도 프록시 설정, 조직 정책이 시스템 설정을 덮어쓸 수 있으므로 충돌하는 항목을 끄고 테스트하세요. 클라이언트의 연결 기록을 열어 웹사이트에 접속할 때 새 연결이 생기지 않는다면 트래픽 진입 지점을 확인하세요. 연결 기록은 있지만 직접 연결로 처리된다면 모드와 규칙을 살펴보세요. IP 확인 사이트만으로 문제를 판단하지 마세요. 캐시, 웹사이트별 분류, 브라우저 동작도 결과에 영향을 줍니다.

포트가 이미 사용 중이거나 터미널에서 시스템 프록시를 사용하지 않을 때는 어떻게 설정하나요?

포트가 이미 사용 중이라면 중복 실행된 클라이언트를 종료하거나 포트를 점유한 프로세스를 확인한 뒤 mixed-port에 사용 가능한 포트를 지정하고 앱의 프록시 주소도 업데이트하세요. HTTP 프록시와 SOCKS 프록시는 임의로 바꿔 쓸 수 없으므로 앱이 지원하는 프로토콜에 맞춰 입력해야 합니다. 터미널 도구는 시스템 프록시를 자동으로 사용하지 않을 수 있어 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY를 별도로 설정해야 할 수 있습니다. 문제를 확인할 때는 우선 임시로 설정하고, 적용 여부를 확인한 뒤 지속 설정을 결정하세요. 클라이언트를 종료하기 전에는 더 이상 필요하지 않은 환경 변수를 정리하세요.

사용 팁

실제 연결 기록으로 변경 사항을 확인하고 새 연결과 기존 연결, 설정 업데이트, 네트워크 환경 변화를 구분하세요.

정책 그룹을 바꿨는데 재생 중인 동영상에 변화가 없는 이유는 무엇인가요?

정책 변경은 대부분 새로 생성되는 연결부터 적용되며, 이미 연결된 트래픽은 기존 아웃바운드를 계속 사용할 수 있습니다. 재생을 일시 중지하고 해당 웹페이지를 닫았다가 다시 열거나, 클라이언트의 연결 화면에서 관련 연결만 종료한 뒤 새 연결 기록의 정책 경로를 확인하세요. 접속 대상이 방금 수정한 정책 그룹에 실제로 매칭되는지도 살펴보세요. 일부 설정은 동영상, 다운로드, 기타 트래픽에 서로 다른 그룹을 사용합니다. 파일 전송이나 회의 등 진행 중인 작업이 중단될 수 있으므로 평소에 모든 연결을 한꺼번에 종료하지 마세요.

규칙이 예상대로 적용되는지 어떻게 확인하나요?

연결 기록에서 대상 도메인이나 앱을 기준으로 방금 발생한 요청을 찾아 어떤 규칙과 정책 그룹이 매칭되었는지, 최종 아웃바운드가 무엇인지 확인하세요. 규칙은 보통 위에서 아래로 적용되므로 범위가 넓은 규칙이 앞에 있으면 뒤의 세부 규칙보다 먼저 적용될 수 있습니다. 수정하기 전에 대상 도메인과 현재 매칭 결과를 기록하고, 필요한 세부 규칙을 적절한 위치에 배치하세요. MATCH는 보통 마지막 기본 규칙으로 사용됩니다. GEOSITE나 규칙 세트를 사용한다면 관련 데이터 파일과 rule-providers가 정상적으로 로드되었는지도 확인하세요.

구독 업데이트 후 직접 수정한 규칙이 사라지는 이유는 무엇인가요?

구독에서 생성된 파일을 직접 편집하면 다음 업데이트 때 원격 내용으로 덮어써질 수 있습니다. 규칙을 계속 유지하려면 클라이언트에서 제공하는 오버라이드, 병합 또는 스크립트 확장 기능을 사용하고 적용 순서를 확인하세요. 클라이언트마다 기능 위치와 병합 방식이 다릅니다. 저장 전에 백업을 내보내고, 업데이트 후에는 편집기 내용만 보지 말고 최종 적용된 설정을 확인하세요. 새 규칙에서 참조하는 정책 그룹이 실제로 존재해야 합니다. 그렇지 않으면 설정 로드가 실패하거나 아웃바운드 참조 오류가 발생할 수 있습니다.

노드 지연 시간은 정상인데 다운로드와 동영상이 느린 이유는 무엇인가요?

지연 시간 테스트는 보통 한 번의 요청에 대한 왕복 시간만 보여 주며, 지속적인 대역폭이나 혼잡도, 특정 웹사이트의 접속 품질을 나타내지는 않습니다. 먼저 같은 다운로드 대상을 고정하고 직접 연결과 여러 아웃바운드를 비교한 뒤, 로컬 Wi-Fi 상태와 백그라운드 다운로드, 서버 속도 제한을 확인하세요. 특정 웹사이트만 느리다면 해당 사이트에 실제로 적용된 아웃바운드와 DNS 응답 주소를 살펴보세요. 테스트 버튼의 결과만 비교해서는 안 됩니다. 원인을 파악할 수 있도록 테스트 조건을 일정하게 유지하고 DNS, 모드, 노드를 동시에 바꾸지 마세요.

공용 Wi-Fi를 사용한 뒤 구독을 다시 가져와야 하나요?

대부분은 그럴 필요가 없습니다. 호텔, 학교, 교통시설 네트워크에서는 먼저 웹페이지에서 로그인 인증을 해야 할 수 있으며, 프록시나 TUN이 인증 페이지 열기를 방해할 수 있습니다. 먼저 트래픽 가로채기를 잠시 끄고 네트워크 인증을 마친 뒤 일반 웹페이지에 접속되는지 확인하고 기존 설정을 복구하세요. 네트워크를 바꾼 뒤 일부 연결이 계속 이상하면 해당 연결을 다시 만들고 DNS 상태를 확인하세요. 네트워크가 한 번 바뀌었다고 기존 설정을 삭제하지 마세요. 계정 링크가 실제로 만료되었거나 제공업체가 교체를 안내한 경우에만 구독을 다시 가져오세요.

문제 해결

먼저 문제가 발생한 범위를 확인하고 다음으로 오류 유형을 살펴보세요. 브라우저는 되지만 특정 앱만 실패하는 경우와 모든 앱이 연결되지 않는 경우는 점검 순서가 다릅니다.

노드 연결 시간 초과가 계속되면 어떤 순서로 점검해야 하나요?

먼저 프록시를 끄고 기본 네트워크가 작동하는지 확인한 뒤, 구독 업데이트가 정상인지, 계정이 유효한지, 기기의 날짜와 시간이 정확한지 살펴보세요. 다음으로 다른 아웃바운드를 선택해 같은 대상에 접속해 보세요. 특정 아웃바운드만 실패하면 서비스 제공업체에 먼저 문의하고, 모든 아웃바운드가 실패하면 방화벽과 프록시 포트, 다른 VPN과의 충돌을 확인하세요. 마지막으로 로그를 살펴 서버 연결 시간 초과, 도메인 이름 확인 실패, 대상 사이트의 연결 거부를 구분하세요. 속도 테스트를 반복하는 것으로 원인 파악을 대신하지 말고 모든 시간 초과를 클라이언트 탓으로 돌리지 마세요.

로그에 DNS 조회 실패나 fake-ip 관련 오류가 나타나면 어떻게 하나요?

먼저 설정의 DNS 업스트림에 연결할 수 있는지, 프록시 서버 연결에 필요한 도메인 이름을 확인할 수 있는지 살펴보세요. 아직 연결되지 않은 프록시에 DNS 요청을 의존하면 순환 참조가 발생할 수 있습니다. 특정 앱에서만 문제가 생긴다면 앱 자체 암호화 DNS 사용 여부, 이전 주소 캐시 여부, fake-ip 호환 여부를 확인하세요. 변경을 마친 뒤 클라이언트가 제공하는 방법으로 DNS 캐시를 비우고 연결을 다시 만드세요. DNS 가로채기 도구를 여러 개 무작정 함께 사용하지 마세요. DNS 모드를 바꾸기 전에 기존 설정을 저장하고 TUN 라우팅도 함께 바뀌는지 확인하세요.

Windows UWP 앱이 연결되지 않을 때 로컬 루프백은 어떻게 확인하나요?

AppContainer 격리를 사용하는 일부 앱은 기본적으로 로컬 루프백 주소에 접근할 수 없어 브라우저가 정상이어도 로컬 프록시에 연결되지 않을 수 있습니다. 먼저 해당 앱이 이 경우에 해당하는지 확인한 다음, 클라이언트에서 제공하는 UWP 루프백 예외 기능을 사용해 필요한 앱만 허용하세요. 관리자는 시스템 명령 CheckNetIsolation LoopbackExempt -s로 기존 예외를 확인할 수 있습니다. 모든 스토어 앱에 해당하는 문제는 아닙니다. 허용한 뒤에도 실패한다면 앱이 시스템 프록시를 사용하는지, 연결이 코어까지 전달되는지 확인하세요.

클라이언트를 종료한 뒤 네트워크 연결이 끊기면 어떻게 복구하나요?

먼저 시스템에 로컬 컴퓨터를 가리키는 수동 프록시가 남아 있는지 확인하세요. 코어가 종료된 상태에서는 해당 주소가 작동하지 않으므로 남은 프록시 설정을 끄거나 클라이언트를 다시 실행한 뒤 트래픽 가로채기를 정상적으로 해제하세요. 앞서 TUN을 사용했다면 가상 인터페이스와 라우팅, DNS가 복구되었는지 확인하고 필요한 경우 클라이언트의 복구 기능을 사용한 뒤 네트워크에 다시 연결하세요. 회사 네트워크는 지정 프록시가 필요할 수 있으므로 설정을 바꾸기 전에 기존 값을 기록하세요. 전체 네트워크 초기화는 마지막 수단으로 미루세요. 기존 VPN, 고정 IP, 업무용 네트워크 설정이 사라질 수 있습니다.

구독 정보를 노출하지 않고 유용한 로그를 공유하려면 어떻게 해야 하나요?

먼저 운영체제와 클라이언트·코어 버전, 사용 중인 모드, 문제가 발생한 시간을 기록한 뒤 한 번 재현하고 전후의 관련 로그를 캡처하세요. 로그 수준을 임시로 높였다면 필요 이상으로 접속 세부 정보가 기록되지 않도록 확인 후 원래대로 돌려놓으세요. 제출 전에 구독 주소, 인증 매개변수, 서버 자격 증명, 공개하고 싶지 않은 도메인이나 IP를 삭제하고 필요하면 오류 유형과 규칙 경로만 남기세요. 설정 예시는 문제를 재현하는 데 필요한 최소 부분만 제공하고 삭제한 내용을 표시하세요. 구독 링크가 공개된 적이 있다면 게시물만 삭제하지 말고 서비스 제공업체에서 링크를 재설정하세요.