먼저 현상을 확인하세요
클라이언트가 실행되지 않은 것인지, 프록시가 연결을 가로채지 못한 것인지, 규칙을 잘못 선택한 것인지, 원격 노드에 접근할 수 없는 것인지 구분하세요. 여러 설정을 동시에 바꾸지 않는 것이 좋습니다.
TROUBLESHOOTING INDEX
Clash 자주 묻는 질문과 문제 해결
설정 출처, 시스템 연결, 코어 로그, 네트워크 경로를 문제 발생 계층에 따라 차례로 점검하세요. 각 답변에 확인 방법과 다음 조치를 담았으며 FlClash와 주요 mihomo 클라이언트에 적용할 수 있습니다.
그다음 로그를 확인하세요
연결 대상, 적용된 규칙, 실제 정책, 오류 유형을 확인하세요. 웹페이지가 열리는지만 보는 것보다 로그가 더 정확합니다.
마지막으로 범위를 좁히세요
기본 설정, 전역 모드, 다른 네트워크를 대조군으로 사용하세요. 한 번에 조건 하나만 바꾸고 결과를 기록하면 됩니다.
BASIC MODEL
4 QUESTIONS
기초 개념
먼저 클라이언트, 코어, 구독, 실행 모드의 역할을 정리하세요. 개념을 정확히 구분해야 이후 점검에서 인터페이스 문제를 노드 장애로 잘못 판단하지 않습니다.
Clash, FlClash, mihomo는 각각 무엇인가요?
Clash는 일반적으로 규칙 기반 프록시 도구와 그 설정 생태계를 가리킵니다. FlClash는 그래픽 인터페이스를 제공하는 크로스 플랫폼 클라이언트로, 설정 관리와 정책 전환, 시스템 연동을 담당합니다. mihomo는 프로토콜 연결, DNS 처리, 규칙 매칭을 담당하는 대표적인 호환 코어입니다. 문제를 점검할 때는 먼저 인터페이스 조작, 시스템 권한, 코어 실행이라는 세 가지 층위를 구분해야 합니다.
Clash Meta와 기존 Clash 설정은 어떤 관계인가요?
mihomo는 널리 쓰이는 Clash YAML 구조를 이어받으면서 더 많은 프로토콜, 규칙 세트, DNS 옵션을 추가했습니다. 기본 필드인 proxies, proxy-groups, rules는 대체로 계속 사용할 수 있지만, 일부 확장 필드는 호환 코어에서만 적용됩니다. 설정을 이전할 때는 먼저 클라이언트의 설정 검사 기능으로 파일을 해석한 다음, 로그에 알 수 없는 필드나 형식 오류가 있는지 확인해야 합니다.
구독 링크와 YAML 설정 파일은 어떻게 다른가요?
구독 링크는 원격 설정에 접근하는 주소로, 클라이언트가 새로 고칠 때마다 내용을 다시 요청합니다. YAML 파일은 특정 시점에 로컬에 저장한 전체 설정입니다. 구독은 노드와 규칙 업데이트를 계속 받는 데 적합하고, 로컬 파일은 디버깅과 오프라인 보관에 유용합니다. 구독으로 생성된 설정을 직접 수정하면 다음 업데이트에서 덮어써질 수 있으므로, 오래 유지할 변경 사항은 클라이언트가 지원하는 오버라이드나 병합 설정에 넣어야 합니다.
규칙, 전역, 직접 연결 모드는 어떻게 선택해야 하나요?
규칙 모드는 rules 목록을 위에서부터 순서대로 매칭하므로 일상적인 사용에 적합합니다. 전역 모드는 모든 연결을 선택한 정책으로 전달하므로 노드를 임시로 테스트할 때 유용합니다. 직접 연결 모드는 프록시를 우회해 문제가 프록시 경로에서 발생했는지 확인할 때 사용합니다. 문제를 점검할 때는 먼저 전역 모드에서 단일 노드를 테스트한 뒤 규칙 모드로 돌아와 정책 그룹과 규칙 매칭 결과를 확인하세요.
INSTALL AND CONFIG
4 QUESTIONS
설치 및 설정
설정 가져오기, 시스템 구성요소 설치, 네트워크 권한 부여는 처음 사용할 때 가장 자주 중단되는 단계입니다. 클라이언트를 반복해서 재설치하기보다 오류 메시지를 기준으로 먼저 처리하세요.
구독 링크가 갑자기 만료되었거나 새로 고침에 실패하면 어떻게 하나요?
먼저 브라우저에서 구독 주소를 열어 텍스트가 반환되거나 설정 파일이 다운로드되는지 확인하세요. 만료, 인증되지 않음, 빈 응답이 표시되면 구독 제공업체에서 주소를 갱신해야 합니다. 브라우저에서는 열리지만 클라이언트에서 실패한다면 시스템 시간, 클라이언트의 프록시 업데이트 설정, 로그의 HTTP 상태 코드를 확인하세요. 현재 문제가 있는 설정으로 업데이트 요청이 반복 전달되지 않도록 시스템 프록시를 잠시 끈 뒤 다시 시도할 수도 있습니다.
YAML을 가져온 뒤 파싱 오류가 표시되면 어떻게 원인을 찾나요?
먼저 오류가 발생한 줄 번호를 기준으로 들여쓰기, 콜론 뒤 공백, 목록의 하이픈, 따옴표의 짝이 맞는지 확인하세요. YAML에서는 Tab 들여쓰기를 사용할 수 없으며 같은 단계는 동일한 개수의 공백을 사용해야 합니다. 오류 위치가 정상처럼 보이면 바로 앞 줄에 콜론이나 괄호가 빠지지 않았는지도 확인하세요. 최근 추가한 dns, proxy-groups, rules 내용을 구간별로 제거해 설정이 로드될 때까지 범위를 좁힌 다음, 문제가 있는 필드를 찾아낼 수 있습니다.
TUN 모드를 켤 때 권한 부족 메시지가 표시되면 어떻게 하나요?
Windows에서는 일반적으로 관리자 권한으로 서비스 모드를 설치하거나 시작해야 합니다. macOS에서는 시스템 안내에 따라 네트워크 확장 또는 보조 구성요소를 허용해야 합니다. Linux에서는 코어 프로세스에 TUN 장치를 만들고 라우팅을 수정할 권한이 필요합니다. 권한을 부여한 뒤에는 클라이언트를 완전히 종료하고 다시 시작하세요. 그래도 실패하면 다른 VPN, 가상 네트워크 카드 도구, 보안 소프트웨어가 관련 네트워크 구성요소를 사용 중인지 확인하세요.
macOS에서 클라이언트나 네트워크 확장 실행이 차단되면 어떻게 하나요?
먼저 설치 패키지가 현재 프로세서 아키텍처와 맞는지 확인하고, Apple Silicon 기기에서는 ARM 빌드를 우선 선택하세요. 시스템이 실행을 차단하면 시스템 설정의 개인정보 보호 및 보안 페이지에서 방금 차단된 앱을 찾아 수동으로 허용할 수 있습니다. TUN을 활성화한 뒤 네트워크 확장 안내가 표시되면 같은 설정 영역에서 권한을 부여하세요. 권한을 승인한 후 클라이언트를 다시 열고, 여러 버전의 보조 구성요소를 동시에 남겨 두지 마세요.
DAILY OPERATION
4 QUESTIONS
활용 팁
시스템 프록시, UWP 루프백, 속도 측정, 수신 포트는 서로 다른 지점에서 작동합니다. 앱 유형에 맞는 연결 방식을 선택하는 편이 노드를 자주 바꾸는 것보다 효과적입니다.
시스템 프록시를 켰는데도 브라우저가 계속 직접 연결되면 어떻게 하나요?
먼저 클라이언트가 실행 중인지 확인하고, 시스템 프록시 페이지의 주소와 mixed-port 또는 HTTP 포트가 일치하는지 확인하세요. 그런 다음 브라우저에 별도의 프록시 확장 프로그램, 고정 프록시 설정, 보안 DNS 정책이 활성화되어 있는지 살펴보세요. 이러한 설정이 시스템 프록시를 우회할 수 있습니다. 로그 페이지에서 브라우저 요청이 나타나는지도 확인할 수 있습니다. 기록이 전혀 없으면 시스템 프록시가 연결을 가로채지 못한 경우가 많고, 기록은 있지만 DIRECT로 처리된다면 규칙 매칭을 추가로 점검해야 합니다.
Windows 스토어 앱에서 프록시를 사용할 수 없을 때 UWP 루프백은 어떻게 설정하나요?
일부 UWP 앱은 기본적으로 로컬 루프백 프록시 주소에 접근할 수 있어 일반 데스크톱 프로그램은 정상인데 스토어 앱만 실패할 수 있습니다. 클라이언트에서 제공하는 UWP 루프백 도구로 대상 앱의 루프백 예외를 선택하고 저장하세요. 해당 메뉴가 없다면 PowerShell의 Get-AppxPackage로 앱 패키지 이름을 찾은 뒤 시스템의 CheckNetIsolation 도구로 예외를 추가할 수 있습니다. 변경 후에는 대상 앱을 완전히 종료하고 다시 시작해야 합니다.
Clash 노드 속도 측정 결과는 어떻게 판단해야 하나요?
지연 시간 테스트는 보통 테스트 주소와 연결을 설정하는 데 걸린 시간만 보여 주며, 실제 다운로드 속도와 같지 않고 안정성을 완전히 나타내지도 않습니다. 같은 테스트 주소를 기준으로 노드를 비교하고, 연속 접속과 다운로드 결과, 로그의 시간 초과 기록을 함께 살펴보세요. 시간 초과로 표시된 노드는 서버에 연결할 수 없는 경우도 있지만 현재 테스트 주소를 지원하지 않는 경우도 있습니다. 전역 모드로 전환한 뒤 일반 HTTPS 웹사이트에 접속해 다시 확인할 수 있습니다.
mixed-port, HTTP 포트, SOCKS 포트는 어떻게 설정하나요?
mixed-port는 HTTP와 SOCKS 연결을 모두 받을 수 있어 앱을 수동으로 설정할 때 보통 가장 편리합니다. port는 HTTP 프록시만 제공하고 socks-port는 SOCKS 프록시만 제공합니다. 포트 값은 다른 프로그램이 사용하지 않아야 하며, 시스템 프록시 주소는 일반적으로 로컬 주소와 해당 포트를 함께 사용합니다. 로컬 네트워크 기기에서 연결해야 한다면 LAN 접근 허용도 켜고, 방화벽에서 신뢰할 수 있는 네트워크 범위를 제한하세요.
FAULT ISOLATION
4 QUESTIONS
문제 해결
연결 시간 초과, DNS 이상, 시작 실패는 대조 테스트로 범위를 좁혀야 합니다. 로그를 보관하고 한 번에 조건 하나만 바꾸면 원인을 더 빠르게 찾을 수 있습니다.
노드는 사용 가능으로 표시되는데 연결이 계속 시간 초과되면 어떻게 하나요?
먼저 전역 모드로 전환하고 해당 노드를 고정 선택해 규칙이 다른 정책을 선택한 상황을 배제하세요. 이어서 기기 시간이 정확한지, 네트워크에서 노드 서버에 접근할 수 있는지, 프로토콜 매개변수가 완전한지 확인하고 로그에서 연결 시간 초과인지 TLS 오류인지 인증 실패인지 구분하세요. 같은 구독의 모든 노드가 시간 초과되면 다른 네트워크에서 테스트하고 방화벽을 확인하세요. 단일 노드만 실패한다면 보통 구독을 새로 고치거나 노드를 교체해야 합니다.
Fake-IP를 켠 뒤 일부 앱에서 인터넷에 연결할 수 없으면 어떻게 하나요?
Fake-IP는 예약 주소를 반환하고 코어가 도메인 매핑을 관리하므로, LAN 검색이나 특정 게임 플랫폼, 로컬 기기 도메인에 의존하는 앱과 호환되지 않을 수 있습니다. 먼저 로그에서 실패한 도메인을 확인한 다음 필요한 도메인만 fake-ip-filter에 추가하세요. 범위가 지나치게 넓은 와일드카드 규칙을 바로 추가하는 것은 피해야 합니다. 많은 앱에서 문제가 발생한다면 DNS를 코어가 처리하고 있는지, nameserver를 사용할 수 있는지, 시스템에 다른 DNS 도구가 함께 실행 중인지도 확인하세요.
클라이언트가 시작 직후 종료되거나 코어가 실행되지 않을 때는 어떻게 점검하나요?
먼저 남아 있는 프로세스를 종료하고 다시 시작한 뒤, 클라이언트 로그 디렉터리의 마지막 기록을 확인하세요. 흔한 원인으로는 프록시 포트 충돌, 현재 YAML 파싱 실패, 서비스 구성요소 권한 부족, 이전 코어 프로세스가 종료되지 않은 문제가 있습니다. 일단 정상 작동이 확인된 기본 설정으로 전환해 시작 과정을 검증할 수 있습니다. 기본 설정이 정상이라면 DNS, 노드, 정책 그룹, 규칙을 차례로 복원하면서 오류를 일으키는 부분을 찾으세요.
구독을 가져온 뒤 정책 그룹이 없거나 노드 목록이 비어 있으면 어떻게 하나요?
먼저 구독 응답에 노드 정의가 실제로 포함되어 있는지 확인하세요. 로그인 페이지, 오류 메시지, 빈 설정이 반환된 것은 아닌지 살펴봐야 합니다. 노드는 있지만 정책 그룹이 비어 있다면 proxy-groups가 정의되어 있는지, 그룹에서 참조하는 노드 이름이 proxies의 이름과 완전히 일치하는지 확인하세요. 구독 변환이나 오버라이드 후 문제가 생겼다면 변환 규칙을 잠시 비활성화하고 다시 가져오세요. 로그의 프록시를 찾을 수 없음, 빈 정책 그룹, 필드 형식 오류 메시지는 설정 위치를 직접 가리킬 수 있습니다.