01 · 재현 조건 만들기
점검 기준: 문제가 발생한 계층부터 확인하기
연결 경로를 여섯 단계로 나누기
Clash의 한 번의 접속은 “클라이언트에서 웹사이트로” 이어지는 단순한 직결이 아닙니다. 전체 경로에는 최소한 애플리케이션, 시스템 프록시 또는 TUN 가로채기, 로컬 수신 포트, Clash 규칙 매칭, 프록시 노드, 대상 사이트의 여섯 단계가 포함됩니다. 브라우저에서 페이지가 열리지 않는다는 사실만으로는 그중 한 단계 이상이 실패했다는 것만 알 수 있으며, 노드가 고장 났거나 구독이 손상되었다고 단정할 수 없습니다. 올바른 방법은 기기에 가까운 단계부터 확인하는 것입니다. 먼저 일반 네트워크가 정상인지 확인하고, Clash 프로세스가 실행 중인지 확인한 다음 포트, 프록시 그룹, 규칙 매칭, 노드 연결과 대상 사이트 상태를 점검하세요. 가까운 단계부터 먼 단계로 확인하면 원격 노드만 반복해서 바꾸면서 로컬 포트 충돌 같은 기본 문제를 놓치는 일을 피할 수 있습니다.
시작하기 전에 현재 환경을 기록하세요. 최소한 운영체제, 클라이언트 이름, 네트워크 유형, 프록시 모드, 선택한 프록시 그룹, 문제가 특정 앱에만 발생하는지 모든 앱에 발생하는지, Clash를 끄면 네트워크가 복구되는지를 적어 두어야 합니다. Windows와 macOS 데스크톱에서는 우선 Clash Plus를 사용할 수 있습니다. 다른 클라이언트와 시스템 요구 사항은 다운로드 센터에서 확인하세요. 설치 직후 첫 연결에서 문제가 발생했다면 먼저 빠른 시작 튜토리얼에 따라 기본 설정을 완료한 뒤 문제 해결 단계로 넘어가세요. 이전에는 정상적으로 작동했다면 시스템 업데이트, 구독 업데이트, WiFi 전환, 보안 소프트웨어 설치, 설정 파일 수정 등 최근 변경 사항도 기록해야 합니다.
최소 테스트 환경 만들기
최소 테스트 환경에는 브라우저 하나, 정상 작동이 확인된 설정 파일 하나, 프록시 노드 하나만 남깁니다. 다른 프록시, VPN, 네트워크 필터, 패킷 캡처 도구와 로컬 개발용 프록시는 먼저 종료해 여러 프로그램이 시스템 프록시를 동시에 변경하거나 같은 포트를 점유하지 않게 하세요. 브라우저의 독립 프록시 확장 프로그램은 끄고 일반 창에서 테스트합니다. 확장 프로그램이 시스템 설정을 우회하거나 이전 포트를 기억하고 있을 수 있습니다. 일시적으로 규칙 모드로 전환하고 프록시 그룹에서는 특정 노드 하나를 선택하세요. 자동 선택이나 로드 밸런싱 그룹부터 사용하지 마세요. 자동 그룹은 백그라운드에서 대상을 바꾸므로 두 번의 테스트 조건이 달라져 문제가 노드 때문인지 정책 때문인지 판단하기 어렵습니다.
기본 설정은 단순하게 유지해야 합니다. 자주 사용하는 수신 관련 필드는 우선 혼합 포트, LAN 허용 여부, 규칙 모드와 로그 수준으로 줄일 수 있습니다. 수정 전에 원본 파일을 백업하고, 수정한 뒤에는 텍스트만 저장하지 말고 클라이언트에서 다시 불러오세요. 아래 조각은 로컬 검증에 적합합니다. 클라이언트가 그래픽 인터페이스로 해당 필드를 관리한다면 인터페이스가 생성한 설정을 우선 사용해 GUI 설정과 수동 파일이 서로 덮어쓰지 않게 하세요.
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090mixed-port는 HTTP와 SOCKS 연결을 모두 받아 포트 혼동을 줄여 줍니다. allow-lan: false는 테스트 범위를 로컬로 제한합니다. mode: rule은 실제 규칙 경로를 유지하며, log-level: info만으로도 보통 규칙 매칭과 연결 오류를 확인할 수 있습니다. 점검이 끝난 뒤 LAN 공유, 스크립트, 오버라이드와 복잡한 DNS를 다시 활성화하세요. 처음부터 로그 상세도를 지나치게 높이지 마세요. 반복 출력이 많아지면 최초의 핵심 오류가 묻히고 모바일 기기의 저장 공간과 배터리도 더 많이 사용합니다.
로그에서 최초 실패 지점 확인하기
로그는 시간, 대상, 규칙, 정책, 노드, 오류 순서로 읽습니다. 먼저 로그를 지우거나 현재 시간을 기억한 뒤 접속을 한 번만 시도하세요. 로그에 새 기록이 전혀 없다면 문제는 대개 애플리케이션과 Clash 사이에서 발생한 것이므로 시스템 프록시, 브라우저 프록시 또는 TUN 가로채기를 확인해야 합니다. 로그에 대상 도메인과 규칙은 나타나지만 아웃바운드 연결이 만들어지지 않는다면 프록시 그룹과 노드를 계속 확인하세요. 연결은 시작되었지만 인증서 오류, 연결 재설정, 거부 또는 시간 초과가 반환된다면 시간, DNS, 네트워크 제한과 원격 상태를 점검해야 합니다. 마지막 한 줄만 캡처하지 마세요. 바로 앞 줄에 적용된 규칙, 프록시 그룹과 실제 대상 주소가 포함되어 있는 경우가 많습니다.
매 라운드마다 변수 하나만 바꾸고 결과를 “복구됨, 변화 없음 또는 증상 변경”으로 기록하세요. 예를 들어 먼저 노드를 바꾸고 결과를 확인한 뒤 모드를 변경합니다. 노드 교체, 구독 새로 고침, DNS 변경과 라우터 재시작을 동시에 하지 마세요. 증상이 달라진 것도 중요한 정보입니다. 로그가 전혀 없다가 연결 시간 초과로 바뀌었다면 시스템 프록시 경로는 복구된 것이므로 다음 단계는 노드와 네트워크 계층이어야 합니다. 한 라운드가 끝나면 가장 뚜렷한 증상에 맞춰 뒤의 장으로 이동하세요. 여러 증상이 동시에 있다면 프로세스가 시작되지 않음, 로그 없음, 모든 노드 실패처럼 상위 계층의 문제를 먼저 해결합니다.
02 · 모든 페이지가 열리지 않음
Clash 인터넷 연결 불가: 로컬 네트워크·프록시 가로채기·규칙 출구 구분하기
먼저 종료 전후를 비교하기
인터넷에 연결되지 않을 때 첫 단계는 노드를 계속 바꾸는 것이 아니라 두 가지 상황을 비교하는 것입니다. Clash를 완전히 종료하고 시스템 프록시가 꺼져 있는지 확인한 뒤 평소 안정적으로 접속되는 사이트를 방문하세요. 이때도 접속할 수 없다면 문제는 기본 네트워크, 라우터, 통신사 네트워크 또는 시스템 DNS에 있으며 Clash 설정을 계속 바꿔도 해결되지 않습니다. 종료 직후 접속이 복구된다면 이상은 프록시 가로채기 이후에 있다는 뜻입니다. 클라이언트를 다시 시작하되 시스템 프록시는 아직 켜지 말고 설정이 정상적으로 로드되는지, 구문 오류가 없는지, 제어판에 프록시 그룹이 표시되는지 확인하세요. 클라이언트 자체가 정상인 것을 확인한 뒤 시스템 프록시를 켜고 두 번째 접속을 시도합니다.
“종료”는 창을 닫는 것만이 아니라 프로세스를 끝내는 것을 의미합니다. 일부 데스크톱 클라이언트는 기본 창을 닫아도 트레이에 남아 시스템 프록시를 계속 유지합니다. Windows에서는 알림 영역과 작업 관리자를, macOS에서는 메뉴 막대와 활성 상태 보기를 확인하세요. 프로세스를 강제 종료한 뒤 네트워크가 복구되고 정상 종료 후에는 계속 끊긴다면 종료 과정에서 시스템 프록시가 복원되지 않은 경우가 많습니다. 먼저 시스템 네트워크 설정에서 프록시 서버를 끈 다음 클라이언트를 다시 시작하세요. 정체를 알 수 없는 네트워크 설정을 바로 삭제하지 마세요. 먼저 기존 값을 기록해야 하며, 특히 기업 네트워크나 개발 환경에서는 고정 프록시를 사용하고 있을 수 있습니다.
로컬 수신 포트 확인하기
시스템 프록시가 가리키는 주소는 Clash가 실제로 수신 중인 주소와 일치해야 합니다. 일반적인 로컬 주소는 127.0.0.1이고 혼합 포트는 7890으로 설정할 수 있지만, 구체적인 값은 현재 설정을 기준으로 해야 합니다. 시스템이 여전히 이전 포트를 가리키면 브라우저가 존재하지 않는 서비스에 요청을 전달하므로 모든 페이지가 즉시 실패합니다. 다른 프로세스가 포트를 점유할 수도 있으며, 클라이언트 로그에는 주소가 이미 사용 중이거나 수신에 실패했다는 메시지가 나타나는 경우가 많습니다. 이때는 포트를 점유한 프로그램을 종료하거나 Clash의 수신 포트와 시스템 프록시 포트를 함께 변경해야 합니다. 한쪽만 바꾸면 안 됩니다.
# Windows: 7890 포트 확인
netstat -ano | findstr :7890
# macOS / Linux: 수신 프로세스 확인
lsof -nP -iTCP:7890 -sTCP:LISTEN명령어에 출력이 없다면 포트가 정상적으로 수신되지 않는 것입니다. 현재 Clash 클라이언트가 아닌 프로세스라면 먼저 용도를 확인하세요. 포트가 수신 중이라고 해서 트래픽이 반드시 외부로 나가는 것은 아니므로 요청이 로그에 들어오는지도 확인해야 합니다. 브라우저가 접속할 때 로그가 완전히 멈춰 있다면 시스템 프록시가 적용되지 않았거나 애플리케이션이 시스템 설정을 우회하는 경우가 많습니다. 로그에 요청은 나타나지만 모두 DIRECT로 향한다면 모드와 규칙을 확인하세요. 요청이 프록시 그룹에 들어간 뒤 실패한다면 노드 시간 초과 장으로 이동합니다.
모드 전환으로 범위 좁히기
일시적으로 전역 모드로 전환하고 특정 노드 하나를 선택해 진단에만 사용하세요. 전역 모드에서는 접속되지만 규칙 모드에서는 안 된다면 노드와 로컬 포트는 대체로 정상이며, 규칙 순서, 규칙 세트 다운로드와 최종 MATCH를 중점적으로 확인해야 합니다. 규칙은 위에서 아래로 매칭되며 먼저 일치한 규칙에서 판단이 끝납니다. 지나치게 넓은 DOMAIN-SUFFIX, 잘못된 GEOIP 출구 또는 앞부분에 있는 MATCH,DIRECT 때문에 대상 트래픽이 잘못된 정책으로 향할 수 있습니다. 규칙을 수정한 뒤에는 규칙 모드로 되돌리고 전역 모드로 설정 오류를 장기간 가리지 마세요.
전역 모드에서도 실패한다면 같은 노드를 다른 네트워크에서 테스트하세요. 예를 들어 가정용 WiFi에서 휴대폰 핫스팟으로 전환합니다. 핫스팟에서는 되지만 기존 네트워크에서는 안 된다면 설정과 노드는 대체로 정상이며 라우터, 방화벽, IPv6 경로 또는 현재 네트워크의 특정 연결 제한을 확인해야 합니다. 두 네트워크 모두 실패하면 다른 회선의 노드로 바꿔 보세요. 노드 하나만 실패한다면 문제는 해당 노드에 한정됩니다. 모든 노드가 실패하지만 직결은 정상이라면 구독 내용이 완전한지, 시스템 시간이 정확한지, 클라이언트 커널이 정상적으로 로드되는지, 보안 소프트웨어가 클라이언트의 네트워크 연결을 차단하는지 확인하세요.
일부 애플리케이션은 UDP, QUIC 또는 자체 네트워크 스택을 사용하므로 브라우저가 정상이라고 해서 모든 앱이 정상인 것은 아닙니다. 먼저 대상 앱의 QUIC를 끄거나 TCP로 바꿔 테스트한 뒤 노드가 UDP를 지원하는지 확인하세요. LAN 공유 환경에서는 접속 기기가 Clash를 실행 중인 호스트의 LAN 주소를 프록시 주소로 사용해야 하며 127.0.0.1을 사용하면 안 됩니다. 후자는 항상 접속 기기 자체를 의미합니다. 공유 설정에서는 allow-lan을 활성화하고 적절한 주소에서 수신하도록 설정하며 시스템 방화벽도 허용해야 합니다. 구체적인 포트 관계는 혼합 포트와 LAN 공유 안내를 참고하세요.
03 · 노드가 시간 초과로 표시됨
노드 시간 초과: 테스트 주소·핸드셰이크 단계·네트워크 경로 확인하기
지연 시간 테스트는 전체 속도 테스트가 아닙니다
클라이언트에 “시간 초과”가 표시되는 것은 제한 시간 안에 테스트 주소 연결이나 HTTP 요청이 완료되지 않았다는 뜻인 경우가 많으며, 노드가 모든 대상에서 사용할 수 없다는 의미는 아닙니다. 테스트는 로컬 네트워크, 노드 입구, 노드 출구, DNS와 테스트 사이트를 거치므로 어느 한 단계만 느려도 시간 초과가 발생할 수 있습니다. 클라이언트마다 테스트 주소, 시간 초과 기준, 연결 재사용 여부가 다르므로 같은 노드라도 Clash Plus, Clash Verge Rev 또는 다른 클라이언트에서 결과가 완전히 같을 필요는 없습니다. 지연 시간 수치는 다운로드 속도와도 다릅니다. 자세한 원리는 노드 지연 시간 테스트 원리를 참고하세요.
노드 하나를 선택해 서로 다른 두 대상에 실제로 접속하세요. 일반 웹페이지 하나와 작은 정적 리소스 하나가 적합합니다. 실제 접속은 정상인데 패널 테스트만 시간 초과라면 해당 노드 출구에서 테스트 URL에 접근할 수 있는지와 구독의 상태 확인 매개변수를 우선 확인하세요. 실제 접속도 실패한다면 로그의 오류 단계부터 살펴봅니다. 연결 거부는 대상 포트에 서비스가 없거나 입구에서 연결을 거부했을 가능성이 큽니다. 연결 시간 초과는 패킷에 응답이 없는 경우에 가깝습니다. TLS 핸드셰이크 오류는 시스템 시간, 인증서 체인, SNI와 중간 네트워크를 확인해야 하며, 이름 해석 실패는 먼저 DNS 장으로 이동하세요.
개별 노드·프록시 그룹·네트워크 비교하기
자동 선택 그룹의 시간 초과가 그룹 내 모든 노드의 시간 초과를 뜻하지는 않습니다. 프록시 그룹을 펼쳐 특정 노드를 직접 선택하고 같은 네트워크에서 연속 두 번 테스트하세요. 첫 번째 테스트에는 DNS와 핸드셰이크 비용이 포함될 수 있으므로 두 번째 테스트로 안정성을 확인할 수 있습니다. 이후 다른 지역 또는 다른 프로토콜의 노드로 바꿔 반복합니다. 같은 묶음의 노드만 실패한다면 구독 서비스의 회선 점검, 입구 주소 변경 또는 프로토콜 매개변수 불일치일 수 있습니다. 모든 노드가 동시에 실패한다면 노드를 하나씩 삭제하기보다 로컬 방화벽, 네트워크 제한, 시스템 시간과 설정 파싱을 우선 확인하세요.
다시 휴대폰 핫스팟으로 네트워크를 비교하세요. 핫스팟에서 복구된다면 클라이언트, 설정과 노드가 최소한 연결을 만들 수 있다는 뜻이므로 기존 WiFi 경로를 점검해야 합니다. 공용 네트워크에서는 먼저 웹 인증을 완료해야 하는 경우가 많습니다. 프록시를 켜기 전에 일반 HTTP 페이지에 접속해 인증을 완료한 다음 Clash를 시작하세요. 기업 네트워크는 제한된 외부 포트만 허용할 수 있고, 가정용 라우터에는 IPv6, MTU 또는 DNS 전달 문제가 있을 수 있습니다. “핫스팟으로 바꾸면 된다”를 단순한 노드 불안정으로 치부하지 마세요. 이는 문제가 접속 네트워크와 관련 있다는 분명한 증거이므로 기록해 두어야 합니다.
시간·IPv6·MTU 확인하기
TLS 연결에는 정확한 시스템 시간이 필요합니다. 기기 시간이 크게 어긋나면 인증서가 아직 유효하지 않거나 이미 만료된 것으로 판단되어 로그에 핸드셰이크 또는 인증서 오류가 나타날 수 있습니다. 시스템 자동 시간 동기화를 켜고 클라이언트를 다시 시작한 뒤 테스트하세요. IPv6 환경에서는 도메인이 AAAA 주소로 우선 해석되지만 현재 노드나 로컬 네트워크에 안정적인 IPv6 출구가 없을 수 있으며, 이 경우 일부 대상이 오래 기다린 뒤 실패합니다. 진단 중에는 설정에서 IPv6를 일시적으로 끄고 다시 로드한 뒤 DNS 캐시를 지워 보세요. 문제가 사라지면 계속 끈 상태로 둘지 로컬과 노드의 IPv6 지원을 수정할지 결정합니다.
작은 페이지는 열리지만 큰 파일이나 일부 앱이 멈춘다면 MTU가 원인일 수 있습니다. TUN 모드는 캡슐화 계층을 추가하고 일부 네트워크는 조각화된 패킷을 제대로 처리하지 못해 큰 패킷이 손실될 수 있습니다. 먼저 TUN을 끄고 시스템 프록시만 사용해 테스트하세요. 시스템 프록시는 정상인데 TUN에서 시간 초과가 발생한다면 클라이언트의 MTU 설정, 시스템 가상 네트워크 어댑터와 다른 VPN 드라이버를 확인해야 합니다. MTU는 감으로 크게 바꾸지 말고 조금씩 낮추면서 같은 대상에 재시험하세요. 정상으로 돌아오면 유효한 값을 기록하고 LAN과 핫스팟에서 다른 설정이 필요한지도 확인합니다.
| 로그에 나타나는 현상 | 우선 확인할 항목 | 다음 단계 |
|---|---|---|
| connection refused | 노드 주소, 포트, 원격 서비스 | 같은 구독의 다른 노드로 변경하고 서비스 제공자에게 문의 |
| i/o timeout | 접속 네트워크, 방화벽, 라우팅 경로 | 핫스팟으로 전환하고 다른 프로토콜 노드 비교 |
| TLS handshake error | 시스템 시간, SNI, 인증서와 중간 네트워크 | 자동 시간 동기화 후 노드 매개변수 확인 |
| no such host | DNS 상위 서버와 도메인 철자 | DNS 장에 따라 해석 경로 확인 |
상태 확인 매개변수도 잘못된 판단을 만들 수 있습니다. 테스트 주소는 안정적이고 용량이 작으며 로그인이 필요 없는 응답을 반환해야 합니다. 확인 간격은 모바일 네트워크를 계속 점유할 정도로 짧아서는 안 되고, 시간 초과 값도 현재 네트워크의 정상 핸드셰이크에 필요한 시간보다 짧아서는 안 됩니다. 설정 제공자가 여러 자동 그룹을 내려준다면 각 그룹이 참조하는 노드 집합과 테스트 주소를 따로 확인하세요. 상태 확인을 수정하면 감지 정확도는 높아질 수 있지만 실제로 고장 난 노드를 복구할 수는 없습니다. 최종 판단은 실제 접속, 로그 단계, 다른 네트워크 비교와 같은 그룹의 다른 노드 결과를 함께 봐야 합니다.
04 · 설정을 업데이트할 수 없음
구독 실패: 링크·응답 내용·파싱·설정 오버라이드 확인하기
다운로드 실패와 파싱 실패부터 구분하기
구독 업데이트에는 서로 독립적인 두 단계가 있습니다. 먼저 클라이언트가 네트워크를 통해 내용을 다운로드하고, 그다음 커널이 이를 설정으로 파싱합니다. 다운로드 단계의 실패는 연결 시간 초과, 비정상 상태 코드, 인증서 오류 또는 구독 도메인을 해석하지 못하는 형태로 나타나는 경우가 많습니다. 파싱 단계의 실패는 대개 내용은 이미 받았지만 YAML 구문, 필드 유형, 노드 매개변수 또는 규칙 제공자 형식이 요구 사항에 맞지 않는 경우입니다. 두 문제의 해결 방향은 완전히 다릅니다. 로그에서 최초 오류를 찾아 HTTP 상태, 응답 본문 길이 또는 YAML 줄 번호가 나타나는지 확인하세요. “업데이트 실패”라는 알림만 보인다면 상세 로그나 설정 관리 화면에서 구체적인 원인을 확인해야 합니다.
구독 링크를 복사할 때 전체 쿼리 매개변수를 보존하세요. 메신저가 링크를 잘라 버리거나 특수 문자를 이스케이프하거나 끝에 문장 부호를 추가할 수 있습니다. 가장 안전한 방법은 서비스 제공자 관리 화면의 복사 버튼을 사용한 뒤 일반 텍스트 편집기에 붙여 넣어 확인하는 것입니다. 링크는 https://로 시작해야 하며 공백과 줄바꿈이 없어야 합니다. 구독에 임시 토큰이 필요하다면 재설정 후 이전 링크가 무효화될 수 있습니다. 구독 링크에는 접근 자격 증명이 포함되는 경우가 많으므로 공개 로그, 스크린샷 또는 온라인 파서에 붙여 넣지 마세요.
링크를 노출하지 않고 네트워크 응답 확인하기
브라우저에서 구독 링크를 직접 열어 텍스트가 다운로드되는지, 로그인 페이지로 이동하는지, 오류 페이지가 반환되는지 확인할 수 있습니다. 브라우저에서도 접속할 수 없다면 문제는 클라이언트 파싱에 있지 않으므로 기본 네트워크, 도메인 해석, 계정 상태와 서버 제한을 확인해야 합니다. 브라우저에서는 다운로드되지만 클라이언트에서는 안 된다면 클라이언트가 구독을 업데이트할 때 직결하는지 현재 프록시를 거치는지 확인하세요. 일부 네트워크에서는 구독 도메인에 접근할 수 없어 기존 설정으로 먼저 연결한 뒤 업데이트해야 할 수 있습니다. 반대로 잘못된 프록시 규칙 때문에 구독 요청이 고장 난 노드로 향할 수도 있으므로, 이때는 프록시를 잠시 끈 뒤 업데이트하세요.
명령줄로 확인할 때는 전체 링크가 공유 터미널 기록에 남지 않게 하세요. 로컬의 임시 환경에서 요청을 실행하고 응답 헤더와 앞부분 몇 줄만 확인하는 방식이 좋습니다. 정상 응답은 일반적으로 YAML 설정 또는 인코딩된 구독 내용이며 HTML 로그인 페이지가 아닙니다. 성공 상태 코드라도 내용이 웹페이지라면 클라이언트는 파싱 단계에서 실패합니다. 리디렉션이 여러 번 발생하면 최종 도메인의 인증서가 정상인지, 기기 시간이 정확한지, 네트워크 인증 페이지가 요청을 가로채지 않았는지 확인하세요.
YAML 줄 번호와 필드 유형 확인하기
파싱 오류에는 대개 줄 번호가 표시됩니다. 해당 줄과 바로 앞줄을 텍스트 편집기에서 먼저 확인하세요. 따옴표 누락, 들여쓰기 오류 또는 콜론 뒤 공백 누락은 다음 줄에서 발견되는 경우가 많습니다. YAML 들여쓰기에는 공백을 사용해야 하며 탭을 섞어 쓸 수 없습니다. 콜론, 샵 또는 특수 기호가 포함된 텍스트 값은 따옴표로 감싸세요. 불리언 값은 true 또는 false를 사용하고 포트는 숫자여야 합니다. 프록시 그룹이 참조하는 노드 이름은 노드 목록과 완전히 일치해야 하며 대소문자와 공백도 차이로 처리됩니다.
proxy-groups:
- name: "노드 선택"
type: select
proxies:
- "자동 선택"
- "DIRECT"
rules:
- DOMAIN-SUFFIX,example.com,노드 선택
- GEOIP,CN,DIRECT
- MATCH,노드 선택구독 원본 파일은 파싱되지만 클라이언트 오버라이드 후 실패한다면 스크립트, 설정 병합, 규칙 오버라이드와 사용자 지정 템플릿을 잠시 끄고 원본 구독을 다시 가져오세요. 클라이언트마다 오버라이드 적용 순서가 다를 수 있고, 오래된 템플릿이 이미 삭제된 프록시 그룹을 참조할 수도 있습니다. 복구되면 항목을 하나씩 다시 켜고 매번 다시 로드해 로그를 확인하세요. 이렇게 하면 상위 구독 자체의 오류인지 로컬 오버라이드의 구조 충돌인지 구분할 수 있습니다. 여러 기기에서 설정을 함께 사용할 때는 경로, 외부 규칙 파일과 플랫폼 전용 필드도 주의해야 하며, 관련 선택지는 여러 기기 간 설정 동기화 방법을 참고하세요.
업데이트 후에도 이전 설정이 적용될 때
업데이트가 성공했다고 해서 현재 실행 설정이 바뀐 것은 아닙니다. 일부 클라이언트는 “설정 다운로드”와 “설정 활성화”를 별도의 동작으로 나눕니다. 구독 목록에 새 시간이 표시된 뒤에도 해당 설정을 선택하고 다시 로드해야 합니다. 화면에 이전 프록시 그룹이 계속 표시된다면 현재 설정 이름, 파일 경로와 업데이트 시간을 확인해 같은 이름의 다른 항목을 업데이트한 것은 아닌지 살펴보세요. 테스트 설정의 그룹 이름을 잠시 알아보기 쉽게 바꾸면 커널이 실제로 어느 파일을 로드했는지 확인할 수 있으며, 완료 후 원래 이름으로 되돌리면 됩니다.
구독 자동 업데이트가 자주 실패한다면 업데이트 간격을 적절히 늘리고 여러 기기가 같은 시각에 반복 요청하지 않게 하세요. 모바일 운영체제는 백그라운드에서 클라이언트를 일시 중지해 예약 작업이 정확히 실행되지 않게 할 수 있으며, 이것이 링크가 무효라는 뜻은 아닙니다. 최종 판단 기준은 수동 업데이트로 유효한 내용을 얻을 수 있는지, 해당 내용이 파싱되는지, 현재 커널이 새 설정을 로드했는지입니다. 서버가 권한 또는 할당량 오류를 명확히 반환한다면 구독 제공자가 처리해야 하며, 클라이언트의 로컬 수정으로 서버 인증을 우회할 수는 없습니다.
05 · 연결되지만 속도가 느림
속도 저하: 지연·처리량·패킷 손실·규칙 경로를 따로 측정하기
먼저 “느림”이 어떻게 나타나는지 정의하기
속도 문제는 최소한 첫 화면이 느리게 열림, 지속적인 다운로드 저하, 동영상 버퍼링, 게임 끊김과 간헐적 연결 중단으로 나뉩니다. 각각 관련 지표가 다릅니다. 첫 화면은 DNS와 핸드셰이크 지연의 영향을 더 많이 받고, 지속적인 다운로드는 대역폭과 혼잡에 좌우되며, 실시간 앱은 패킷 손실과 지터에 더 민감합니다. 클라이언트에 표시되는 밀리초 수치만으로는 이러한 차이를 확인할 수 없습니다. 점검할 때는 같은 기기, 같은 네트워크, 같은 대상과 비슷한 시간대를 사용해 직결, 고정 노드 하나와 다른 고정 노드 하나를 비교하세요. 자동 선택 그룹은 출구를 바꾸므로 기준 테스트에 적합하지 않습니다.
테스트 전에 시스템 업데이트, 클라우드 동기화, 동영상 재생과 다른 기기의 대용량 작업을 일시 중지하세요. 브라우저 속도 측정은 확장 프로그램, 캐시와 QUIC의 영향을 받을 수 있으므로 시크릿 창에서 두세 번 반복하는 것이 좋습니다. 짧은 간격으로 계속 속도를 측정하지 마세요. 회선을 가득 채워 이후 결과를 왜곡할 수 있습니다. 첫 바이트까지 걸린 시간, 안정적인 다운로드 구간의 속도와 갑자기 0이 되는지 여부를 기록하세요. 직결도 느리다면 먼저 로컬 WiFi, 라우터 부하 또는 통신사 네트워크를 해결해야 합니다. 프록시에서만 느리다면 노드, 프로토콜과 규칙 경로를 비교하세요.
대상이 실제로 어느 출구를 사용하는지 확인하기
규칙 모드에서는 도메인마다 다른 프록시 그룹으로 들어갈 수 있습니다. 웹페이지의 주 도메인이 프록시를 사용한다고 해서 이미지, 동영상 조각과 API도 같은 출구를 사용한다는 뜻은 아닙니다. 연결 기록을 열고 대상 도메인을 검색해 매칭된 규칙과 정책을 확인하세요. 잘못된 규칙은 정적 리소스를 직결하거나, 원래 직결해야 할 서비스를 먼 경로로 보내거나, 여러 대용량 도메인을 혼잡한 노드로 보낼 수 있습니다. 규칙은 위에서 아래 순서로 매칭되며 구체적인 작성법과 순서는 Clash 규칙 라우팅 실전을 참고하세요.
일시적으로 전역 모드로 전환하고 같은 노드를 고정하면 규칙이 차이를 만드는지 확인할 수 있습니다. 전역 모드가 확실히 빠르더라도 전역 모드를 장기간 유지하지 말고 연결 기록을 비교해 규칙 모드에서 다른 정책으로 향하는 도메인을 찾으세요. 두 모드 모두 느리다면 규칙이 주원인이 아닙니다. 같은 지역의 다른 노드로 바꿔 보세요. 하나의 노드만 느리다면 해당 회선의 혼잡이나 출구 품질 문제일 가능성이 큽니다. 현재 WiFi에서 모든 노드가 느리고 핫스팟에서는 정상이라면 로컬 네트워크, MTU, IPv6와 라우터의 트래픽 관리 설정을 확인하세요.
DNS·연결 재사용·프로토콜 차이
DNS 응답이 느리면 새 도메인을 열 때마다 기다리게 되지만 이미 만들어진 다운로드 연결은 정상적으로 유지될 수 있습니다. 처음 열 때 느리고 새로 고침 후 빨라지거나 페이지 일부 리소스만 늦게 나타나는 것이 대표적인 증상입니다. 이때 로그에서 도메인 해석에 걸린 시간을 확인하고 Clash DNS와 시스템 DNS를 비교하세요. 서로 전달하는 로컬 DNS 도구를 여러 개 동시에 사용하지 마세요. 요청이 지나치게 긴 경로를 거치거나 순환할 수 있습니다. Fake-IP 모드에서는 앱이 먼저 예약 주소를 받고 Clash가 실제 도메인으로 매핑합니다. 매핑 캐시가 비정상적이거나 앱이 시스템 해석을 우회하면 간헐적인 멈춤으로 나타날 수 있습니다.
일부 네트워크에서는 UDP가 불안정하고 브라우저는 QUIC를 우선 사용할 수 있습니다. 브라우저의 QUIC를 일시적으로 끄거나 관련 트래픽이 TCP로 폴백하도록 설정해 보세요. 안정성이 좋아진다면 문제는 UDP 경로에 집중된 것입니다. 노드에 UDP 지원이라고 표시되어 있어도 현재 접속 네트워크, 라우터와 출구 경로가 안정적이라는 보장은 없습니다. 게임과 음성 앱에서는 최저 지연보다 지속적인 패킷 손실을 확인해야 합니다. TUN 모드는 더 많은 트래픽을 가로채지만 가상 네트워크 어댑터와 추가 캡슐화도 도입합니다. 시스템 프록시는 빠른데 TUN만 느리다면 MTU, 네트워크 어댑터 드라이버와 제외 라우팅을 확인하세요.
자동 선택 그룹에 합리적인 매개변수 사용하기
자동 선택은 보통 상태 확인 결과에 따라 노드를 고르지만 테스트 주소의 경로와 실제 업무 경로는 다릅니다. 테스트 지연이 가장 낮다고 처리량이 가장 높다는 뜻은 아닙니다. 웹에 적합한 노드가 대용량 파일이나 실시간 앱에도 적합하다고 보기는 어렵습니다. 용도별로 독립된 프록시 그룹을 만들 수 있습니다. 일상적인 브라우징에는 자동 선택을 사용하고, 다운로드나 동영상에는 수동으로 고정하며, 직결 서비스는 DIRECT로 유지하세요. 품질 차이가 큰 노드를 수십 개 넣어 자주 검사하는 그룹을 만들지 마세요. 계속되는 테스트가 자원을 소모하고 출구가 반복해서 바뀔 수 있습니다.
특정 시간대에 속도가 떨어지는 원인은 회선 혼잡이나 로컬 무선 간섭인 경우가 많습니다. 유선 네트워크를 사용하거나 라우터 가까이에서 다시 측정해 WiFi와 원격 경로를 구분하세요. 같은 노드를 비혼잡 시간대에도 비교해야 합니다. 대용량 파일 다운로드가 처음에는 빠르다가 계속 느려진다면 출구 제한, 혼잡 제어 또는 서버 측 속도 제한일 수 있습니다. 속도가 주기적으로 0이 되었다가 회복되면 패킷 손실, 네트워크 전환 또는 연결 재설정에 더 가깝습니다. 시간, 노드와 대상을 기록한 뒤 회선을 바꿀지 결정하고, 한 번의 측정만으로 전체 설정을 즉시 다시 작성하지 마세요.
06 · 도메인 해석 이상
DNS 문제: 해석 진입점·모드·캐시·폴백 경로 확인하기
DNS 장애의 특징 파악하기
DNS 문제는 도메인을 입력해도 열리지 않거나, 이미 알고 있는 주소로는 응답이 오거나, 일부 도메인만 정상이고 다른 도메인은 실패하거나, 네트워크를 바꾼 뒤에도 이전 결과가 계속 남는 형태로 나타납니다. 로그에는 no such host, 해석 시간 초과, 상위 서버 연결 불가 또는 Fake-IP 매핑 누락이 표시될 수 있습니다. 인증서 이름 불일치도 잘못된 해석에서 비롯될 수 있지만 시스템 시간과 네트워크 인증 페이지도 함께 배제해야 합니다. 실패한 도메인 하나를 선택해 시스템 해석 결과와 Clash 로그의 해석 과정을 각각 기록하세요. 여러 도메인을 한꺼번에 테스트하지 마세요.
DNS 경로는 브라우저 보안 DNS, 시스템 해석기, 로컬 필터 프로그램, Clash DNS, 라우터와 상위 서버를 거칠 수 있습니다. 경로가 길수록 순환, 캐시 불일치와 라우팅 오류가 발생하기 쉽습니다. 점검할 때는 브라우저의 독립 보안 DNS와 다른 로컬 DNS 도구를 잠시 끄고 요청이 시스템과 Clash만 거치게 하세요. 브라우저는 복구되지만 다른 앱은 원래 정상이라면 브라우저의 독립 해석이 원인일 가능성이 큽니다. 모든 앱이 실패한다면 Clash DNS 수신, TUN 가로채기와 상위 서버 접근 가능성을 계속 확인하세요.
redir-host와 Fake-IP 이해하기
redir-host는 보통 실제 해석 주소를 반환한 뒤 규칙에 따라 연결을 처리합니다. Fake-IP는 먼저 예약 주소 범위에서 매핑 주소를 반환해 Clash가 도메인 정보를 유지하고 더 일찍 규칙을 실행할 수 있게 합니다. Fake-IP는 원격 노드 주소가 아니며 hosts 파일에 직접 입력해서도 안 됩니다. 일부 LAN 장치, 게임, 기업용 앱 또는 특수한 DNS 동작을 사용하는 소프트웨어는 Fake-IP와의 호환성이 낮을 수 있으므로 해당 도메인을 필터 목록에 추가해 실제 주소를 반환하도록 할 수 있습니다. 필터는 재현이 확인된 도메인에만 적용하고, 너무 넓은 와일드카드로 대부분의 요청을 제외하지 마세요.
dns:
enable: true
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "localhost.ptlogin2.qq.com"
nameserver:
- 1.1.1.1
- 8.8.8.8예시는 필드 간 관계를 보여 주기 위한 것이며 모든 네트워크가 같은 상위 서버를 사용해야 한다는 뜻은 아닙니다. ipv6: false는 진단용 스위치로 적합하며 IPv6 경로가 안정적인 것을 확인한 뒤 다시 켤 수 있습니다. 상위 DNS는 현재 네트워크에서 접근 가능해야 합니다. 상위 서버 자체에 프록시가 필요하고 프록시 연결이 다시 해당 DNS에 의존한다면 시작 순환이 발생할 수 있습니다. 복잡한 설정에서는 프록시 노드 도메인 해석용 독립 상위 서버를 지정할 수 있지만, 프록시가 아직 연결되지 않은 상태에서도 이 부분이 작동해야 합니다.
캐시와 수신 충돌 확인하기
DNS를 수정한 뒤에는 Clash 캐시, 시스템 캐시와 브라우저 캐시를 모두 고려해야 합니다. 먼저 설정을 다시 로드하고 클라이언트를 재시작한 다음 시스템 해석 캐시를 새로 고치고, 마지막으로 브라우저를 닫았다가 다시 여세요. 웹페이지 새로 고침만으로는 기존 연결이나 브라우저 내부 캐시가 계속 사용될 수 있습니다. Windows에서는 ipconfig /flushdns를 사용할 수 있고, macOS에서는 시스템 명령으로 캐시를 새로 고칠 수 있습니다. 모바일에서는 보통 비행기 모드를 켰다 끄거나 네트워크 연결을 재시작해 일부 상태를 정리합니다. 캐시 삭제는 검증을 위한 조치일 뿐 매번 연결할 때 실행해야 하는 절차가 되어서는 안 됩니다.
Clash DNS가 로컬 53번 포트에서 수신해야 한다면 시스템 서비스, 컨테이너 도구 또는 다른 DNS 프로그램이 이미 해당 포트를 사용하고 있을 수 있습니다. 로그에 바인딩 실패가 나타나면 TUN 가로채기 이후의 조회가 응답을 받지 못할 수 있습니다. 실제 수신 프로세스를 확인하고 어느 프로그램이 해석 진입점을 담당할지 결정하세요. 두 서비스가 서로를 상위 서버로 가리키게 하지 마세요. 예를 들어 시스템 DNS가 로컬 필터를 가리키고 필터가 Clash를 가리키며 Clash가 다시 시스템 기본 DNS를 가리키면 순환이 발생할 수 있습니다. 최소 경로에는 명확한 진입점과 명확한 외부 상위 서버가 있어야 합니다.
IPv6와 분할 해석 처리하기
도메인이 A와 AAAA 레코드를 동시에 반환하면 앱이 IPv6를 먼저 시도할 수 있습니다. 로컬에 IPv6 주소는 있지만 출구가 완전하지 않으면 요청이 시간 초과될 때까지 기다린 뒤 IPv4로 폴백하므로 DNS가 느린 것처럼 보입니다. Clash DNS에서 IPv6 응답을 일시적으로 끄면 이를 확인할 수 있습니다. 끈 뒤 복구된다면 모든 해석 이상을 상위 DNS 오류로 돌리지 말고 라우터 프리픽스, 시스템 기본 경로와 노드의 IPv6 지원을 계속 점검하세요.
분할 해석 설정은 도메인에 따라 다른 상위 서버를 선택해 잘못된 해석을 줄이는 데 적합하지만, 규칙과 프록시 출구가 서로 맞아야 합니다. 어떤 도메인이 직결 DNS로 해석되었는데 최종적으로 프록시를 통해 접속하면 반환 주소가 프록시 출구에 적합하지 않을 수 있으며 반대의 경우도 마찬가지입니다. 연결 기록에서 도메인, 해석 주소와 규칙 정책을 확인해 세 가지가 예상대로 일치하는지 확인하세요. 특정 도메인 하나만 이상하다면 먼저 정확한 규칙을 추가해 검증하고 전체 DNS를 즉시 바꾸지 마세요. 특정 서비스만 계속 실패한다면 주소창의 주 도메인뿐 아니라 관련 도메인이 여러 개 필요한 서비스인지도 확인해야 합니다.
07 · 스위치는 켜졌지만 앱이 직결함
시스템 프록시가 적용되지 않음: 포트·우회 목록·앱의 프록시 방식 확인하기
시스템 프록시는 시스템 설정을 따르는 앱에만 영향을 줍니다
시스템 프록시를 켜면 클라이언트는 운영체제의 HTTP, HTTPS 또는 SOCKS 프록시 주소를 로컬 Clash 포트로 지정합니다. 이 설정을 사용할지는 애플리케이션이 결정합니다. 주요 브라우저는 보통 시스템 프록시를 따르지만 게임, 명령줄 도구, 스토어 앱, 가상 머신과 일부 크로스 플랫폼 프로그램은 완전히 무시할 수 있습니다. 따라서 “브라우저는 되지만 특정 앱은 직결한다”는 사실이 시스템 프록시 스위치의 고장을 의미하지는 않습니다. 먼저 시스템 프록시를 따르는 브라우저로 기본 경로를 확인한 뒤 대상 앱이 명시적 프록시를 지원하는지 또는 TUN 모드의 가로채기가 필요한지 확인하세요.
시스템 설정에서 서버 주소와 포트를 확인하세요. 주소는 보통 127.0.0.1이고 포트는 현재 mixed-port 또는 해당 HTTP 포트와 일치해야 합니다. 설정을 업데이트하거나 클라이언트를 바꾸면 포트가 변경될 수 있지만 시스템에는 이전 값이 남아 있을 수 있습니다. Clash Plus와 Clash Verge Rev처럼 여러 클라이언트를 사용할 때는 시스템 프록시를 동시에 켜지 마세요. 나중에 시작한 프로그램이 설정을 덮어쓰고 종료 순서에 따라 더 오래된 값으로 복원될 수 있습니다. 점검 중에는 클라이언트 하나만 실행하세요.
브라우저와 명령줄을 따로 확인하기
브라우저에 독립 프록시 확장 프로그램이 설치되어 있으면 확장 프로그램 설정이 시스템 프록시를 덮어쓸 수 있습니다. 확장 프로그램을 잠시 끄고 브라우저를 다시 시작하세요. 시크릿 창이 모든 확장 프로그램을 비활성화하는 것은 아니므로 확장 프로그램 관리 화면에서 확인해야 합니다. 명령줄 도구는 보통 HTTP_PROXY, HTTPS_PROXY와 ALL_PROXY 환경 변수를 읽으며 그래픽 인터페이스의 시스템 프록시 설정이 자동으로 전달되지 않을 수 있습니다. 변수를 설정할 때 HTTP와 SOCKS 프로토콜을 구분하고 현재 터미널과 전역 환경 중 어느 범위에 적용되는지도 확인하세요.
# 현재 shell에만 HTTP 프록시 설정
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
# 테스트 완료 후 삭제
unset HTTP_PROXY
unset HTTPS_PROXYWindows PowerShell, 개발 도구와 컨테이너는 각각 고유한 프록시 설정 진입점을 가집니다. 명령 하나를 작동시키기 위해 시스템, Git, 패키지 관리자, 컨테이너와 편집기의 설정을 모두 동시에 바꾸지 마세요. 문제가 해결된 뒤 원상 복구하기 어려워집니다. 먼저 현재 터미널에만 임시로 설정하고 요청이 Clash 로그에 들어오는지 확인하세요. 성공한 뒤에야 설정을 지속할지 결정합니다. 로그에 요청이 없다면 해당 도구가 지정한 프록시를 아직 사용하지 않는 것입니다. 로그에는 요청이 있지만 실패한다면 규칙 또는 노드 문제로 이동하세요.
우회 목록과 자동 설정 확인하기
시스템 프록시에는 보통 프록시를 거치지 않을 호스트 목록을 설정할 수 있습니다. localhost, LAN 주소와 기업 내부망은 자주 우회되지만 너무 넓은 와일드카드는 일반 도메인까지 잘못 제외할 수 있습니다. Windows에서는 자동 검색이나 PAC 스크립트가 동시에 켜져 있을 수 있고, macOS는 네트워크 서비스마다 프록시 설정을 따로 저장합니다. Clash를 끈 뒤에도 시스템에 프록시가 표시된다면 자동 프록시 스크립트, 관리 정책 또는 다른 상주 프로그램이 있는지 확인하세요. 수정 전에는 원래 설정을 기록하고 조직에서 관리하는 기기의 정책을 강제로 제거하지 마세요.
LAN 주소는 보통 직결해야 라우터, 프린터 또는 파일 공유에 접근할 때 프록시 노드로 우회하지 않습니다. TUN을 켠 뒤 LAN 리소스가 사라진다면 제외 라우팅, 사설 주소 규칙과 엄격한 라우팅 설정을 확인하세요. 시스템 프록시 모드와 TUN 모드는 서로 다른 트래픽을 처리할 수 있으므로 둘을 단순히 함께 켠 뒤 문제를 판단하면 안 됩니다. 진단할 때는 먼저 시스템 프록시만, 다음에는 TUN만 따로 테스트하세요. 둘 다 정상인 것을 확인한 뒤에야 함께 켤 필요가 있는지 판단합니다.
종료 후 남은 프록시 처리하기
클라이언트가 충돌하거나 강제 종료되거나 시스템이 종료될 때 프록시 설정이 복원될 시간이 부족할 수 있습니다. 대표적인 증상은 재부팅 후 Clash가 아직 실행되지 않았는데 시스템 프록시를 따르는 모든 앱의 연결이 즉시 실패하는 것입니다. 먼저 시스템 네트워크 설정에서 수동 프록시를 끄고 클라이언트를 시작한 뒤 시스템 프록시를 정상적으로 한 번 전환하세요. 문제가 반복되면 클라이언트의 서비스 모드, 데몬 또는 시작 프로그램 권한 문제를 확인하고 현재 유지 관리되는 버전을 사용하세요. 재설치 전에는 필요한 설정을 내보내고 다운로드 센터에서 플랫폼에 맞는 설치 패키지를 선택하세요.
기업 보안 소프트웨어가 프로그램의 시스템 프록시 변경을 차단할 수 있습니다. 화면의 스위치는 켜진 것처럼 보여도 시스템 값은 바뀌지 않는 경우가 있습니다. 이때는 클라이언트 버튼보다 시스템 프록시 페이지를 직접 확인하는 편이 정확합니다. 반대로 시스템 값은 바뀌었지만 보안 소프트웨어가 로컬 수신 포트 통신을 막을 수도 있습니다. 포트 확인 명령으로 Clash가 수신 중인지 확인하고 브라우저 요청이 로그에 들어오는지 관찰하세요. 시스템 설정, 포트 수신과 로그 요청 세 가지가 모두 확인되어야 시스템 프록시 경로가 구축되었다고 판단할 수 있습니다.
08 · 시작되지 않거나 반복해서 종료됨
클라이언트 충돌: 인터페이스·커널·설정·시스템 구성 요소 분리하기
먼저 충돌이 발생하는 단계를 확인하기
클라이언트 충돌은 시작 화면, 설정 로드, 커널 시작, TUN 활성화 또는 구독 업데이트 실행 등 여러 단계에서 발생할 수 있습니다. 단계에 따라 점검 방향이 달라집니다. 더블클릭 후 창이 전혀 나타나지 않는다면 시스템 이벤트 기록, 앱 로그 디렉터리와 보안 소프트웨어 차단 기록을 확인하세요. 창은 나타나지만 설정을 로드할 때 종료된다면 설정 구문, 지나치게 큰 규칙 세트 또는 오버라이드 스크립트를 우선 의심합니다. TUN을 켤 때만 종료된다면 가상 네트워크 어댑터, 서비스 권한과 다른 VPN 드라이버를 중점적으로 확인하세요. 단순히 “열리지 않는다”고만 기록하지 말고 마지막으로 표시된 화면과 마지막 로그를 적어 두세요.
이전 설정 자동 복원이나 시작 시 자동 실행을 먼저 끄면 프로그램이 시작하자마자 문제 상태를 반복해서 로드하는 일을 막을 수 있습니다. 클라이언트에 안전 모드나 설정 경로 지정 기능이 있다면 최소 설정으로 시작하세요. 안전 모드가 없다면 먼저 프로세스를 종료하고 설정 디렉터리를 백업한 뒤 현재 활성 설정을 원래 위치에서 옮겨 클라이언트가 빈 상태로 시작하게 하세요. 인터페이스에 들어가는 데 성공해도 전체 디렉터리를 즉시 되돌리지 마세요. 먼저 기본 설정 하나를 가져와 커널이 실행되는지 확인하고 구독, 오버라이드와 인터페이스 설정을 단계적으로 복원합니다.
그래픽 인터페이스와 커널 문제 구분하기
그래픽 클라이언트는 설정 관리와 시스템 통합을 담당하고 실제 프록시는 보통 mihomo 같은 커널 프로세스가 처리합니다. 인터페이스는 남아 있지만 커널이 반복해서 중지된다면 커널 로그의 설정 오류, 포트 점유와 권한 문제를 확인하세요. 인터페이스 자체가 응답하지 않지만 커널이 계속 실행 중이라면 네트워크는 잠시 정상일 수 있으며 문제는 인터페이스 캐시, 렌더링 구성 요소 또는 지나치게 큰 설정 목록에 가까울 수 있습니다. 작업 관리자나 활성 상태 보기로 어느 프로세스가 종료되는지 확인할 수 있습니다. 커널이 실행 중인 상태에서 인터페이스 인스턴스를 반복해서 시작하지 마세요. 제어 포트와 설정 파일 잠금을 서로 경쟁할 수 있습니다.
설정 검증에서는 먼저 구문을 배제하고 다음으로 리소스 규모를 배제해야 합니다. 대규모 규칙 세트, 지나치게 많은 프록시 노드와 잦은 상태 확인은 시작 시간과 메모리 사용량을 늘립니다. 프로그램이 잠시 응답하지 않는다고 해서 반드시 충돌한 것은 아닙니다. CPU, 메모리와 로그가 계속 변하는지 관찰하세요. 매번 같은 규칙 제공자를 로드한 뒤 멈춘다면 해당 제공자를 일시적으로 비활성화하거나 캐시를 정리한 뒤 다시 시도합니다. 원격 규칙 파일 다운로드가 완전하지 않아 손상된 캐시가 남을 수도 있습니다. 삭제하기 전에 구독에서 해당 파일을 다시 받을 수 있는지 확인하세요.
포트·권한·드라이버 충돌 확인하기
혼합 포트, 제어 포트와 DNS 포트가 점유되면 커널이 시작되지 않을 수 있습니다. 앞서 소개한 명령으로 점유 프로세스를 확인하고 설정에서 수신 주소가 실수로 중복 정의되지 않았는지 점검하세요. 낮은 번호의 포트나 TUN 장치에는 추가 권한이 필요할 수 있지만, 장기간 관리자 권한으로 실행하는 것을 유일한 해결책으로 삼아서는 안 됩니다. 먼저 클라이언트의 서비스 구성 요소가 올바르게 설치되었는지, 시스템 확장이 허용되었는지, 가상 네트워크 어댑터가 존재하는지 확인하세요. macOS는 시스템 업데이트 후 네트워크 확장 재승인이 필요할 수 있고, Windows 보안 정책도 드라이버 로드를 막을 수 있습니다.
다른 VPN, 가상 머신 네트워크, 컨테이너 플랫폼, 게임 가속기와 보안 소프트웨어는 네트워크 필터 드라이버를 설치할 수 있습니다. 프로그램을 열지 않았더라도 백그라운드 서비스가 실행 중일 수 있습니다. TUN 모드에서만 충돌하거나 네트워크가 끊긴다면 관련 서비스를 완전히 종료한 뒤 다시 테스트하세요. 일반 시스템 프록시가 안정적이라면 기본 커널과 노드는 사용할 수 있고 문제는 가상 네트워크 어댑터 경로에 집중된 것입니다. 다른 네트워크 소프트웨어를 하나씩 다시 활성화해 구체적인 충돌 항목을 찾고, 모든 도구를 한꺼번에 삭제하지 마세요.
초기화와 재설치의 올바른 순서
프로그램을 재설치해도 사용자 설정이 자동으로 삭제되지 않는 경우가 많아 손상된 설정이 재설치 후에도 계속 적용될 수 있습니다. 올바른 순서는 구독 주소 외에 필요한 정보를 먼저 내보내고 사용자 지정 규칙과 포트를 기록한 다음 클라이언트를 종료하고 설정 디렉터리를 백업하는 것입니다. 기존 디렉터리 이름을 바꾸면 새로 설치한 프로그램이 깨끗한 설정을 생성합니다. 빈 상태가 안정적인지 확인한 뒤 구독에서 다시 가져오세요. 기존 디렉터리 전체를 새 디렉터리에 바로 복사하면 캐시, 창 상태와 문제 설정까지 함께 복원됩니다.
시스템 이벤트 기록에 실행 구성 요소 누락, 파일 권한 이상 또는 프로그램 격리가 표시된다면 시스템 안내에 따라 복구하세요. 설치 패키지는 프로세서 아키텍처와 운영체제에 맞아야 합니다. Apple Silicon과 Intel, Windows x64와 다른 아키텍처를 혼용할 수 없습니다. 현재 클라이언트 선택과 플랫폼 지원은 다운로드 센터에서 확인하고, 데스크톱 플랫폼에서는 우선 Clash Plus를 고려하세요. 복구가 끝난 뒤 시작 시 자동 실행과 TUN을 다시 켜되 한 번에 하나만 활성화하고 재시작해 확인하세요. 충돌이 시작 순서나 권한 복원 때문에 발생하는 것은 아닌지 확인할 수 있습니다.
09 · Android 및 iOS
모바일 전용 점검: 백그라운드 제한·VPN 권한·네트워크 전환
먼저 VPN 설정과 시스템 상태 확인하기
Android와 iOS의 Clash 계열 클라이언트는 보통 시스템 VPN 인터페이스를 통해 트래픽을 가로챕니다. 처음 연결할 때는 사용자가 명시적으로 권한을 허용해야 하며, 시스템 상태 표시줄에 VPN 아이콘이 나타나야 합니다. 인터페이스에는 연결됨으로 표시되지만 상태 표시줄에 아이콘이 없다면 시스템 VPN 설정을 다시 확인하고 다른 VPN, 기업 보안 연결 또는 시스템 네트워크 도구가 같은 인터페이스를 사용하고 있지 않은지 확인하세요. 모바일 운영체제는 보통 하나의 활성 VPN만 허용합니다. 다른 앱을 시작하면 현재 연결이 끊길 수 있으며 클라이언트 인터페이스가 상태를 동기화하는 데 몇 초 걸릴 수 있습니다.
iOS에서는 Clash Plus를 사용할 수 있으며 다운로드 센터의 iOS 항목을 통해 App Store로 이동할 수 있습니다. Android에서는 다운로드 센터에서 Clash Plus, Clash Meta for Android, FlClash와 Surfboard를 비교할 수 있습니다. 클라이언트를 이전할 때 자동 연결 설정을 두 개 동시에 유지하지 마세요. 먼저 기존 클라이언트의 연결을 끊고 필요 시 연결을 끈 다음 새 설정을 가져오세요. 구독은 다시 가져올 수 있지만 사용자 지정 규칙과 오버라이드는 별도로 기록해야 플랫폼에서 지원하지 않는 필드를 그대로 복사하는 일을 피할 수 있습니다.
백그라운드 중지와 화면 잠금 후 연결 끊김 처리하기
Android 제조사의 배터리 정책은 화면이 꺼진 뒤 클라이언트, 커널 또는 VPN 서비스를 제한할 수 있습니다. 화면이 켜져 있을 때는 정상인데 몇 분간 잠그면 네트워크가 끊기고 앱을 다시 열면 즉시 복구되는 것이 대표적인 증상입니다. 시스템 배터리 설정에서 클라이언트의 백그라운드 실행을 허용하고 해당 앱의 절전 제한을 끄며 자동 시작이나 백그라운드 활동을 허용하세요. 제조사마다 메뉴 이름은 다르지만 판단 기준은 같습니다. 화면 잠금 중 VPN 아이콘이 사라지는지, 시스템에 앱 제한 기록이 있는지, 알림 영역의 상주 서비스가 제거되는지를 확인하세요.
iOS는 백그라운드 실행을 엄격하게 관리하지만 이미 연결된 시스템 VPN은 보통 네트워크 확장이 유지합니다. 자주 끊긴다면 필요 시 연결 규칙, 저전력 모드, 시스템 VPN 설정과 네트워크 확장 권한을 확인하세요. 앱 전환 화면에서 클라이언트를 반복해서 강제 종료하고 정기적인 구독 업데이트를 기대하지 마세요. 구독 업데이트는 앱을 열었을 때 수동으로 실행하고, 연결 안정성은 시스템 VPN 상태로 판단해야 합니다. 기기의 저장 공간이 부족하거나 시스템 업데이트가 진행 중인 경우에도 설정 저장과 확장 프로그램 시작에 영향을 줄 수 있습니다.
WiFi와 셀룰러 네트워크 전환
WiFi에서 셀룰러 네트워크로 전환하면 로컬 주소, DNS, MTU와 IPv6 환경이 모두 바뀌므로 기존 연결을 다시 만들어야 합니다. 잠깐 연결이 끊기는 것은 정상적인 전환 과정이지만, 계속 복구되지 않으면 VPN을 수동으로 끊었다가 다시 연결하고 새 네트워크에서 노드 연결이 다시 만들어지는지 확인하세요. 셀룰러에서는 되지만 특정 WiFi에서는 안 된다면 해당 WiFi에 웹 인증이 필요한지, VPN을 제한하는지, 비정상적인 IPv6나 DNS를 제공하는지 확인합니다. 공용 WiFi에서는 먼저 프록시를 끄고 브라우저에서 인증을 완료한 뒤 클라이언트를 연결하세요.
셀룰러 네트워크에서만 실패한다면 클라이언트의 모바일 데이터 사용이 차단되어 있지 않은지, 시스템 데이터 절약 모드가 켜져 있지 않은지, 구독 또는 노드 도메인이 셀룰러 DNS로 해석되는지 확인하세요. 듀얼 SIM 기기에서는 현재 데이터 SIM과 네트워크 전환 정책도 확인해야 합니다. 일부 시스템은 신호 변화 시 데이터 SIM을 자동으로 바꾸어 기존 연결을 무효화할 수 있습니다. 진단할 때는 하나의 데이터 SIM을 고정하고 스마트 전환을 끈 뒤 같은 노드로 테스트하세요. 복구된 후 자동 전환을 단계적으로 다시 켜서 네트워크를 바꿀 때마다 재연결이 필요한지 판단합니다.
앱별 프록시와 LAN 접근
Android 클라이언트에는 앱별 프록시 기능이 있는 경우가 많아 특정 앱만 프록시하거나 특정 앱을 제외할 수 있습니다. 설정이 잘못되면 브라우저는 정상인데 대상 앱이 직결하거나 시스템 구성 요소가 네트워크에 연결되지 않을 수 있습니다. 점검할 때는 앱별 규칙을 잠시 끄고 모든 앱이 같은 연결을 사용하게 하세요. 정상 작동을 확인한 뒤 제외 항목을 하나씩 추가합니다. 앱 업데이트, 패키지 이름 변경 또는 업무 프로필 공간 때문에 기존 선택이 무효화될 수 있으며, 개인 공간과 업무 공간은 서로 다른 VPN 권한을 가질 수도 있습니다. 연결 로그에서 대상 앱의 요청이 커널에 들어왔는지 확인하세요.
가정용 라우터, 화면 공유 기기와 LAN 서비스를 이용할 때는 사설 주소를 직결하도록 허용해야 합니다. VPN 연결 후 LAN 기기를 찾을 수 없다면 클라이언트의 “LAN 접근 허용” 옵션, 설정의 사설 주소 규칙과 시스템 로컬 네트워크 권한을 확인하세요. iOS는 로컬 네트워크 접근 권한을 별도로 묻습니다. 거부해도 프록시 자체는 작동할 수 있지만 기기 검색과 LAN 연결은 실패합니다. Android에서는 LAN 서비스를 검색하기 위해 주변 기기 또는 위치 관련 권한이 필요할 수도 있으며, 이는 프록시 노드의 정상 여부와는 관계가 없습니다.
모바일 최소 복구 절차
모바일에서 지속적으로 네트워크가 끊기면 정해진 순서로 처리하세요. 먼저 클라이언트 연결을 끊고 VPN을 끈 뒤 기본 네트워크가 정상인지 확인합니다. 그다음 비행기 모드를 한 번 전환해 네트워크를 복구합니다. 클라이언트를 열고 특정 노드를 선택해 규칙 모드로 다시 연결한 뒤 시스템 VPN 아이콘과 클라이언트 로그를 확인하세요. 여전히 실패하면 WiFi 또는 셀룰러 네트워크를 바꿔 비교합니다. 앱 데이터 삭제와 구독 삭제를 동시에 하지 마세요. 최초 오류의 단서가 사라집니다. 설정을 로드할 수 없거나 앱 상태가 손상된 것이 확인된 경우에만 필요한 설정을 백업한 뒤 초기화하세요.
재설치 후에도 실패한다면 원인은 대개 앱 파일이 아니라 시스템 VPN 설정, 네트워크 환경 또는 구독 노드에 있습니다. 시스템 설정에 남은 이전 VPN 설정을 삭제하고 기기를 재시작한 뒤 현재 클라이언트가 다시 권한을 요청하게 하세요. 특정 앱만 이상하다면 해당 앱의 비공개 DNS, 데이터 권한과 앱별 프록시를 확인합니다. 모든 앱이 이상하다면 노드, DNS와 네트워크 전환 경로로 돌아가세요. 모바일 점검의 핵심도 변수를 하나로 유지하는 것입니다. 클라이언트, 노드와 네트워크를 고정해 한 번 성공적으로 연결한 뒤 자동 선택, 백그라운드 정책과 앱별 규칙을 단계적으로 복원하세요.
이 페이지의 절차를 따라도 원인을 찾지 못했다면 최소 문제 보고서를 정리하세요. 기기와 운영체제, 클라이언트 이름, 문제가 발생한 네트워크, 현재 모드, TUN 활성화 여부, 재현 가능한 대상 하나, 정상에서 실패로 바뀐 구체적인 단계와 구독 정보를 가린 관련 로그를 포함해야 합니다. 클라이언트를 끄면 복구되는지, 핫스팟으로 전환하면 복구되는지, 다른 노드는 정상인지도 적으세요. 이러한 비교 결과가 “연결되지 않는다”는 한 문장보다 장애 계층을 판단하는 데 훨씬 도움이 되며, 구독 링크와 개인 네트워크 정보가 노출되는 것도 막을 수 있습니다.