Clash 문제 해결: 증상 진단부터 연결 복구까지

1. Clash는 연결됐지만 인터넷이 되지 않을 때

클라이언트 미실행, 프록시 미적용, 설정 오류를 먼저 구분하세요

“인터넷이 되지 않음”은 브라우저에 나타나는 결과일 뿐이며, 문제는 서로 다른 세 지점에서 발생할 수 있습니다. 첫 번째는 클라이언트 코어가 정상적으로 실행되지 않아 로컬 프록시 포트가 수신 대기하지 않는 경우입니다. 두 번째는 코어는 정상이나 브라우저나 앱이 요청을 Clash로 전달하지 않는 경우입니다. 세 번째는 트래픽이 Clash에 도달했지만 노드, 규칙 또는 DNS 오류로 대상 사이트에 도달하지 못하는 경우입니다. 먼저 클라이언트 상태 페이지나 로그 페이지를 확인하세요. 로그에 새 기록이 전혀 없다면 대개 앱 트래픽이 클라이언트로 들어오지 않은 것이므로 시스템 프록시, 브라우저 프록시 확장 프로그램과 TUN 모드를 점검해야 합니다. 웹페이지를 열 때 로그에 요청이 계속 기록되지만 끝에 timeout, connection refused 또는 DNS error가 표시되면 노드와 DNS 경로를 추가로 확인하세요.

로컬 포트가 수신 대기 중인지 확인하려면 클라이언트 설정에서 혼합 포트를 찾으세요. 일반적인 설정 키는 mixed-port입니다. 포트 번호가 특정 값이어야 하는 것은 아니며, 클라이언트에 표시된 포트가 시스템 프록시, 브라우저 확장 프로그램 또는 터미널 환경 변수와 일치하는지가 중요합니다. Windows에서는 터미널에서 netstat를 실행하고, macOS와 Linux에서는 lsof를 사용할 수 있습니다. 명령 결과가 있다는 것은 어떤 프로세스가 포트를 사용 중이라는 뜻이지만, 그 프로세스가 현재 클라이언트인지도 확인해야 합니다. 이전 클라이언트의 잔여 프로세스가 포트를 점유하면 새 클라이언트가 시작되지 않을 수 있습니다.

netstat -ano | findstr LISTENING
lsof -nP -iTCP -sTCP:LISTEN

로컬 연결과 프록시 연결을 비교 테스트하세요

먼저 시스템 프록시와 TUN을 끄고, 원래 로컬 네트워크에서 직접 열리는 사이트에 접속해 기본 네트워크가 정상인지 확인하세요. 그런 다음 시스템 프록시만 켜고 같은 사이트에 접속하면서 Clash 로그를 확인합니다. 이 비교로 Wi-Fi 인증 미완료, 케이블 연결 끊김, 게이트웨이 오류 또는 통신사 네트워크 장애를 구분할 수 있습니다. 프록시를 꺼도 접속할 수 없다면 Clash 설정을 계속 조정해도 해결되지 않으므로 먼저 시스템 네트워크를 복구하세요. 프록시를 끄면 정상이고 켜면 모두 실패한다면 문제는 로컬 포트, 규칙, 노드 또는 DNS에 집중됩니다.

브라우저 캐시와 확장 프로그램의 영향을 배제하려면 명령어로 로컬 프록시를 명시해 테스트할 수도 있습니다. 포트는 클라이언트 설정 페이지에 표시된 혼합 포트로 바꾸세요. 명령어는 응답을 반환하지만 브라우저가 실패한다면 코어와 노드는 대체로 정상이며 브라우저 프록시 확장 프로그램, HTTPS 검사 소프트웨어 또는 시스템 프록시 덮어쓰기 설정을 확인해야 합니다. 명령어도 시간 초과가 발생하면 같은 시각의 로그를 확인해 어떤 정책 그룹과 노드가 선택됐는지 파악하세요.

curl -I --proxy http://127.0.0.1:7890 https://example.com
curl -I --socks5-hostname 127.0.0.1:7890 https://example.com

규칙 모드와 정책 그룹 선택 확인

규칙 모드는 도메인, IP와 규칙 세트에 따라 직접 연결, 프록시 또는 거부를 결정합니다. 구독을 업데이트하면 정책 그룹이 기본 선택으로 돌아가거나 이미 만료된 노드를 참조할 수 있습니다. 프록시 또는 정책 그룹 페이지를 열고 현재 그룹이 최종적으로 어떤 노드를 선택하는지 단계별로 확인하세요. 가장 바깥쪽 그룹 이름만 봐서는 안 됩니다. 규칙이 잘못 적용됐는지 확인하려면 잠시 글로벌 모드로 전환하고 사용 가능한 것으로 확인된 노드를 선택해 테스트하세요. 글로벌 모드에서는 복구되지만 규칙 모드에서 실패한다면 클라이언트와 노드는 정상일 가능성이 높으므로 규칙 세트, 정책 그룹 참조와 규칙 순서를 중점적으로 확인해야 합니다. 글로벌 모드에서도 실패한다면 노드와 DNS를 계속 점검하세요.

규칙 문제를 가리기 위해 글로벌 모드를 장기간 사용하지 마세요. 규칙은 위에서 아래로 매칭되므로 앞쪽의 포괄적인 규칙이 뒤의 더 정확한 도메인 규칙을 가로챌 수 있습니다. 예를 들어 모든 사설 주소를 직접 연결하는 것은 대체로 합리적이지만, 잘못된 IP 대역이나 지나치게 넓은 도메인 접미사는 대상 요청이 프록시를 우회하게 만들 수 있습니다. 모드를 반복해서 바꾸기보다 연결 기록에서 실제로 매칭된 규칙을 확인하는 편이 효과적입니다. 사용자 규칙을 수정한 뒤에는 설정을 다시 불러오고, YAML 문법 오류 때문에 클라이언트가 이전 설정으로 되돌아가지 않았는지도 확인하세요.

루프백 프록시와 방화벽 차단 점검

일부 보안 소프트웨어는 로컬 루프백 연결을 차단할 수 있습니다. 클라이언트는 실행 중으로 표시되지만 127.0.0.1로 향하는 모든 프록시 요청이 실패하는 형태입니다. 방화벽 규칙을 바로 삭제하기보다 관련 네트워크 필터링 기능을 잠시 중지해 비교 테스트를 진행하세요. 기업용 기기는 관리 정책으로 시스템 프록시가 고정되어 있을 수도 있습니다. 이 경우 설정 스위치가 잠시 정상처럼 보여도 몇 초 뒤 원래 값으로 돌아갑니다. 시스템 프록시 페이지에서 로컬 주소와 포트가 계속 유지되는지 확인하고, 두 개의 프록시 도구가 동시에 시스템 설정을 기록하고 있지 않은지도 점검하세요.

절전 모드에서 깨어난 뒤, Wi-Fi를 전환한 뒤 또는 VPN 연결이 끊긴 뒤 문제가 발생했다면 먼저 클라이언트를 종료하고 프로세스가 끝났는지 확인한 후 다시 실행하세요. 네트워크 인터페이스가 바뀌면 기존 연결과 DNS 캐시가 이미 사라진 인터페이스에 계속 묶여 있을 수 있습니다. 시스템 프록시 스위치를 계속 눌러보는 것보다 클라이언트를 재시작하는 편이 수신 대기 포트와 연결 풀을 완전히 재구성하는 데 효과적입니다. 그래도 복구되지 않으면 시스템 네트워크 인터페이스나 운영체제를 재시작하고, 문제가 반복되는지 판단할 수 있도록 재시작 전 로그를 보관하세요.

2. 노드 시간 초과, 핸드셰이크 실패 및 연결 거부

개별 노드 문제인지 전체 그룹 문제인지 먼저 판단하세요

노드 테스트에서 시간 초과가 발생했다고 해서 클라이언트 전체가 손상된 것은 아닙니다. 먼저 같은 정책 그룹에서 서로 다른 지역과 진입 경로를 사용하는 노드를 두 개 이상 선택하고 동일한 테스트 주소로 반복 확인하세요. 특정 노드만 실패하고 다른 노드는 연결된다면 해당 노드의 중단, 진입 주소 변경, 포트 접근 불가 또는 만료된 구독 정보가 원인일 수 있습니다. 사용 가능한 노드로 전환하고 서비스 제공자가 구독을 업데이트할 때까지 기다리세요. 같은 구독의 모든 노드가 실패하지만 다른 설정은 정상이라면 해당 구독이나 서비스 회선에 문제가 있는 것입니다. 모든 설정과 모든 노드가 동시에 시간 초과될 때만 로컬 네트워크, 방화벽, 시스템 시간과 프로토콜 호환성을 점검하세요.

클라이언트에 내장된 지연 시간 테스트는 보통 지정된 URL로 HTTP 요청을 한 번 보내며, 단순한 ICMP ping이 아니라 “테스트 요청을 완료하는 데 걸린 시간”을 측정합니다. 현재 네트워크에서 테스트 주소에 접근할 수 없거나 리디렉션되거나 특수한 핸드셰이크가 필요하면 실제로 사용 가능한 노드도 시간 초과로 표시될 수 있습니다. 따라서 실제 웹페이지 접속과 연결 로그를 함께 확인하고 빨간색 지연 표시 하나만으로 결론을 내리지 마세요. 노드로 대상 사이트는 열리지만 테스트만 실패한다면 안정적이고 응답 본문이 작은 테스트 주소로 바꾸거나 실제 접속 결과를 주요 판단 기준으로 삼으세요.

일반적인 오류의 방향 파악

시스템 시간, IPv6와 프로토콜 필드 확인

TLS 유형의 노드는 올바른 시스템 시간에 의존합니다. 시간 오차가 크면 인증서가 아직 유효하지 않거나 이미 만료된 것으로 판단될 수 있습니다. 시스템 자동 시간 동기화를 켜고 시간대가 올바른지 확인하세요. 가상 머신, 듀얼 부트 환경과 장시간 절전 상태였던 기기에서 특히 시간 오차가 발생하기 쉽습니다. 로그가 인증서 이름이나 핸드셰이크 매개변수를 가리킨다면 구독에서 생성된 서버 이름, 전송 방식과 포트가 완전한지도 확인하세요. 노드를 직접 편집할 때 필드 오탈자, 들여쓰기 또는 불리언 값 유형 오류로 인해 코어가 예상과 다른 매개변수를 불러올 수 있습니다.

IPv6도 자주 발생하는 별도의 원인입니다. 노드 진입 도메인이 IPv4와 IPv6 주소를 함께 반환하지만 현재 네트워크의 IPv6 연결이 불완전하면, 클라이언트가 IPv6을 먼저 시도한 뒤 계속 시간 초과될 수 있습니다. 먼저 시스템에서 대상 도메인의 IPv4와 IPv6 확인 결과를 테스트한 다음 클라이언트의 IPv6 옵션을 잠시 꺼서 비교하세요. 끈 직후 복구된다면 로컬 IPv6 라우팅을 수정하거나 DNS 응답 정책을 조정하거나, 설정에서 사용 가능한 주소 계열을 명시해야 합니다. 모든 노드를 무효로 표시하는 것은 올바른 해결책이 아닙니다.

네트워크 유형과 외부 연결 제한 점검

회사, 학교, 호텔과 공공 Wi-Fi는 비표준 포트를 제한하거나 먼저 웹 인증을 요구할 수 있습니다. 먼저 Clash를 끄고 임의의 HTTP 페이지를 열어 인증 페이지를 표시한 뒤 로그인하고 노드를 다시 테스트하세요. 모바일 핫스팟은 매우 유용한 비교 네트워크입니다. 같은 기기, 같은 클라이언트와 같은 설정이 핫스팟에서는 정상이고 고정 네트워크에서만 실패한다면 클라이언트 설정은 기본적으로 올바르며 원래 네트워크의 DNS, 라우팅 또는 접근 제어에 문제가 있는 것입니다. 반대로 다른 네트워크에서도 같은 노드만 실패한다면 노드 측 문제일 가능성이 높습니다.

접근할 수 없는 문제를 가리기 위해 시간 초과 시간을 계속 늘리지 마세요. 시간 초과 설정은 지연이 큰 회선을 감내하기 위한 것이며 잘못된 주소, 닫힌 포트 또는 없는 경로를 고칠 수는 없습니다. 장기간 관찰해야 한다면 고정 노드로 안정적인 사이트에 연속 접속하며 연결 단계에서 실패하는지 전송 단계에서 실패하는지 기록하세요. 연결 단계에서 즉시 거부되면 서버 포트 상태일 가능성이 높고, 오래 기다린 뒤 시간 초과되면 패킷 손실, 라우팅 블랙홀 또는 진입점 필터링에 가깝습니다. 연결 후 자주 끊기면 MTU, 네트워크 전환과 회선 품질을 확인하세요.

구독 업데이트 후 호환성 문제

구독을 업데이트한 뒤 모든 노드가 오류로 바뀌었고 업데이트 전에는 정상 작동했다면, 먼저 최근에 사용 가능했던 설정으로 되돌리거나 백업에서 복원하세요. 구독 내용에 현재 코어가 지원하지 않는 프로토콜 필드가 추가됐거나 정책 그룹 이름이 바뀌어 규칙이 존재하지 않는 그룹을 참조할 수 있습니다. 설정 로드 로그에서 unknown field, unsupported, proxy group not found 등의 메시지를 중점적으로 확인하세요. 클라이언트 호환성 문제라면 다운로드 페이지에서 계속 유지 관리되는 클라이언트를 선택하세요. 데스크톱과 모바일 플랫폼에서는 Clash Plus를 우선 확인할 수 있습니다. 손상된 캐시 설정에 계속 덮어쓰지 말고 원본 구독을 다시 가져오세요.

3. 구독 가져오기 실패, 업데이트 실패 또는 빈 설정

주소가 완전한지 확인하고 구독과 웹페이지를 구분하세요

구독 실패가 발생하면 먼저 복사한 것이 서비스 관리 페이지의 홈, 사용 설명서 페이지 또는 브라우저 주소 표시줄에서 잘린 리디렉션 링크가 아닌 완전한 구독 주소인지 확인하세요. 구독 주소에는 보통 경로와 쿼리 매개변수가 포함되며, 메신저 줄바꿈, QR 코드 인식, 브라우저 번역 또는 텍스트 정리 도구 때문에 끝부분 문자가 삭제될 수 있습니다. 주소를 일반 텍스트 편집기에 붙여넣고 시작 프로토콜, 도메인, 경로와 쿼리 부분이 완전한지 확인하며 앞뒤 공백도 살펴보세요. 계정 식별에 사용되는 접근 매개변수가 포함될 수 있으므로 구독 원문을 스크린샷, 로그 공유 또는 공개 포럼에 게시하지 마세요.

브라우저에서 구독 주소를 열면 YAML 텍스트, 인코딩된 내용 또는 파일 다운로드가 반환될 수 있습니다. 로그인 페이지, 인증 코드 페이지, 요금제 설명 또는 HTML 오류 페이지가 보인다면 클라이언트가 이를 설정으로 파싱할 수 없는 것이 정상입니다. 브라우저에서 다운로드된다고 해서 클라이언트에서도 반드시 업데이트되는 것은 아닙니다. 브라우저가 기존 프록시, 로그인 Cookie 또는 다른 DNS를 사용했을 수 있기 때문입니다. 반대로 브라우저에서 열리지 않는다고 주소가 무효인 것도 아닙니다. 일부 서비스는 특정 요청 헤더를 요구합니다. 가장 확실한 판단 기준은 클라이언트 업데이트 로그의 HTTP 상태와 파싱 오류입니다.

HTTP 상태로 요청 단계를 파악하세요

첫 가져오기에서 네트워크 의존성 처리

처음 설치할 때 사용할 수 있는 노드가 아직 없고 현재 네트워크에서 구독 도메인에 직접 연결할 수 없다면 “설정을 다운로드하려면 프록시가 필요하지만 프록시는 설정을 다운로드한 뒤에야 생기는” 순환이 발생합니다. 모바일 핫스팟처럼 접근 가능한 다른 네트워크에서 처음 가져오기를 완료하거나, 신뢰할 수 있는 기기에서 설정을 다운로드한 뒤 클라이언트가 지원하는 로컬 가져오기 방식으로 불러오세요. 완료 후 원래 네트워크로 돌아와 업데이트하면 됩니다. 설정에 노드 인증 정보와 정책 정보가 포함될 수 있으므로 구독 내용을 온라인 변환 사이트에 함부로 전달하지 마세요.

기존 설정이 있다면 먼저 사용 가능한 노드를 선택하고 시스템 프록시를 켠 뒤 구독을 업데이트하세요. 일부 클라이언트는 “프록시를 통한 업데이트” 또는 업데이트 프록시 옵션을 제공합니다. 이 옵션이 참조하는 정책 그룹이 최종적으로 사용 가능한 노드를 선택하는지 확인하세요. 업데이트가 여전히 직접 연결로 실행된다면 로그에서 구독 도메인 연결 기록을 찾아 DIRECT가 선택됐는지 프록시 정책이 선택됐는지 확인하세요. 규칙 모드에서 구독 도메인이 잘못 직접 연결되는 것은 매우 흔한 업데이트 실패 원인입니다. 정확한 도메인 규칙을 추가한 뒤 설정을 다시 불러오세요.

설정 다운로드는 성공했지만 목록이 비어 있음

업데이트 성공 메시지는 표시되지만 노드나 정책 그룹이 비어 있다면 네트워크 요청은 완료됐으나 반환 내용이 클라이언트가 기대한 구조가 아닐 수 있습니다. 먼저 설정 관리 페이지에서 파일 크기와 업데이트 시간을 확인하세요. 지나치게 작은 파일은 오류 메시지나 빈 응답일 가능성이 높습니다. 클라이언트에서 원본 설정을 볼 수 있다면 proxies, proxy-groups, rules 같은 최상위 필드가 있는지 확인하세요. 원격 제공자만 포함한 설정은 proxy-providers에 의존할 수도 있습니다. 이 경우 기본 파일을 성공적으로 불러온 뒤에도 제공자 파일을 계속 다운로드해야 하며, 후속 요청이 실패하면 노드 목록이 비어 있을 수 있습니다.

mixed-port: 7890
mode: rule
proxies:
  - name: example-node
    type: socks5
    server: 192.0.2.10
    port: 1080
proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - example-node
rules:
  - MATCH,PROXY

위 구조는 필드 간 관계를 설명하기 위한 예시이며 예시 주소는 문서용 예약 주소입니다. 실제 설정은 구독 서비스가 생성해야 합니다. YAML은 공백으로 들여쓰기하며 탭을 사용할 수 없습니다. 같은 수준의 필드는 들여쓰기 폭이 같아야 하고, 콜론이나 샵 또는 특수 문자가 포함된 이름은 따옴표로 감싸는 것이 좋습니다. 파서가 줄 번호를 알려주면 오류가 표시된 줄의 바로 앞 줄부터 확인하세요. 실제로 따옴표나 들여쓰기가 빠진 위치는 이전 줄에 있는 경우가 많습니다.

캐시, 덮어쓰기와 중복 설정

클라이언트에는 원격 구독, 로컬 복사본과 현재 실행 중인 설정이 동시에 보관될 수 있습니다. 구독을 업데이트했지만 새 설정으로 전환하지 않으면 실행 중인 내용은 바뀌지 않습니다. 이름이 같은 설정이 여러 개 있으면 판단도 어려워집니다. 업데이트 후 현재 활성 항목, 업데이트 시간과 설정 출처가 일치하는지 확인하고 다시 불러오기를 실행하세요. 설정 관리 페이지에 계속 이전 내용이 표시되면 필요한 사용자 규칙을 먼저 내보내고 실패한 구독 항목을 삭제한 뒤 다시 추가하세요. 손상된 캐시에 계속 덮어쓰는 방식은 피해야 합니다.

구독은 업데이트되지만 일정 시간이 지나면 다시 실패한다면 실패 당시의 네트워크, 시스템 프록시 상태와 반환 상태를 기록하세요. 서버가 짧은 시간에 반복되는 요청을 제한할 수 있으므로 업데이트 버튼을 계속 누르지 마세요. 자동 업데이트 간격은 서비스 제공자의 권장값을 기준으로 설정하는 것이 좋습니다. 가져오기 경로와 기본 설정 과정은 빠른 시작 가이드에서 확인할 수 있으며, 다운로드 페이지의 자주 묻는 질문은 설치 패키지와 클라이언트 선택 문제를 해결하는 데 도움이 됩니다.

4. 연결은 정상이지만 속도가 느리거나 끊기고 다운로드가 불안정할 때

노드, 회선과 로컬 설정을 나누어 테스트하세요

속도 저하는 노드 탓으로 돌리기 쉽지만 실제 경로에는 로컬 기기, 라우터, 접속 네트워크, 노드 진입점, 노드 출구와 대상 사이트가 모두 포함됩니다. 먼저 프록시를 끄고 기본 네트워크를 테스트한 뒤 프록시를 켜고 하나의 노드를 고정해 같은 사이트, 같은 파일을 비슷한 시간대에 반복 테스트하세요. 테스트 서버 위치, 동시 연결 방식과 캐시 정책이 다르므로 여러 속도 측정 사이트를 동시에 사용해 결론을 내리지 마세요. 직접 연결 자체가 이미 혼잡하다면 Wi-Fi 신호, 라우터 부하 또는 통신사 회선을 먼저 해결하세요. 직접 연결은 안정적이고 프록시에서만 느려진다면 노드와 설정을 점검하세요.

노드를 테스트할 때는 정책 그룹을 고정해 테스트 중 url-test가 자동으로 전환되지 않도록 하세요. 먼저 같은 지역의 노드 두 개를 비교하고 그다음 다른 지역의 노드를 비교하면 개별 노드 부하와 국제 라우팅 차이를 구분할 수 있습니다. 지연 시간은 상호작용 응답을 판단하는 데 적합하지만 지속 대역폭을 의미하지는 않습니다. 지연 시간은 조금 높아도 패킷 손실이 적은 노드가 지연은 낮지만 지터가 큰 노드보다 실제 웹페이지와 동영상 재생에서 안정적일 수 있습니다. 3단계 점검 절차는 노드·회선·로컬 설정 점검 목록에서 계속 확인할 수 있습니다.

혼잡 시간대와 대상별 차이를 관찰하세요

저녁 시간이나 특정 네트워크 환경에서만 느려진다면 대개 회선 혼잡과 관련이 있습니다. 정상 시간대와 문제가 발생한 시간대를 기록하고 한 번의 테스트 결과로 설정을 영구 변경하지 마세요. 모든 대상 사이트가 느려졌다면 진입 회선, 노드 부하와 로컬 네트워크를 우선 고려하세요. 한 사이트만 느리다면 노드 출구에서 해당 사이트로 가는 경로, 대상 사이트의 속도 제한 또는 콘텐츠 전송 지역 불일치일 수 있습니다. 웹페이지는 정상인데 대용량 파일만 느리다면 첫 화면 속도보다 지속 대역폭, 동시 연결 제한과 전송 프로토콜을 확인하세요.

정책 그룹의 자동 테스트가 지나치게 잦아도 불안정해질 수 있습니다. url-test는 테스트 결과에 따라 노드를 선택하므로 네트워크가 흔들릴 때 출구가 계속 바뀔 수 있고, 이미 만들어진 연결과 새 연결이 서로 다른 경로를 사용해 로그인 상태나 장시간 연결에 영향을 줄 수 있습니다. 낮은 지연 시간을 원하면 url-test, 사용 가능성을 우선하면 fallback, 연결을 분산해야 할 때는 load-balance를 고려하세요. 세 방식의 동작과 매개변수 차이는 정책 그룹 설정 상세 가이드를 참고하세요. 자동 전환 주기를 실제 네트워크 변화 주기보다 지나치게 짧게 설정하지 마세요.

DNS, IPv6와 연결 재사용을 확인하세요

웹페이지를 처음 열 때 느리지만 새로고침 후 빨라진다면 DNS 조회나 첫 연결 설정에 시간이 걸리는 경우가 많습니다. 로그에서 요청이 DNS 단계에 얼마나 머무는지 확인하고 로컬 DNS와 암호화 DNS를 각각 테스트하세요. DNS 서버는 많을수록 좋은 것이 아닙니다. 불안정한 서버를 병렬로 여러 개 조회하면 결과 차이가 커지고, 잘못된 fallback 필터 때문에 매번 추가 시간 초과를 기다릴 수도 있습니다. 먼저 안정적인 주 DNS 서버 한 그룹과 명확한 대체 정책만 유지한 뒤 결과를 평가하세요.

IPv6 경로 품질이 나쁘면 도메인이 IPv6 주소를 반환해 요청이 실패할 때까지 기다린 뒤 IPv4로 되돌아가므로 새 사이트마다 몇 초씩 느려질 수 있습니다. IPv6을 잠시 끄고 비교하면 방향을 확인할 수 있지만, 장기적인 해결책은 IPv6 연결을 복구하거나 DNS와 라우팅 정책을 일치시키는 것입니다. DNS에서 IPv6 응답만 끄고 다른 앱은 IPv6을 직접 사용하게 두면 새로운 동작 차이가 생길 수 있으므로, 변경할 때마다 연결 로그로 확인하세요.

TUN, MTU와 LAN 기기를 점검하세요

TUN 모드는 데이터를 가상 인터페이스로 캡슐화하므로 MTU가 적절하지 않으면 작은 요청은 정상이어도 큰 응답이나 업로드에서 재전송이 자주 발생합니다. 일부 사이트만 열리고 다른 사이트는 로딩에서 멈추거나 텍스트는 보이지만 이미지와 동영상이 실패하는 것이 전형적인 증상입니다. 클라이언트가 지원하는 범위에서 TUN 인터페이스 MTU를 조금씩 낮추고, 매번 작은 범위만 조정해 같은 대상을 테스트하세요. 광대역, 모바일 네트워크, 가상 머신과 VPN이 겹친 환경은 사용 가능한 MTU가 다르므로 다른 네트워크의 고정값을 그대로 적용하지 마세요.

LAN에서 라우터가 프록시를 실행한다면 단말 트래픽이 실제로 해당 라우터를 통과하는지, 보조 라우터 게이트웨이와 DNS 주소가 일치하는지 확인하세요. 단말이 다른 DNS를 사용하면 도메인 조회가 예상한 정책을 우회할 수 있습니다. 이중 라우터나 Mesh 로밍으로 기기가 다른 출구로 전환될 수도 있습니다. 데스크톱 클라이언트에서 LAN 공유와 로컬 TUN을 동시에 켤 때는 라우터 프록시와 중복 전달되지 않도록 하세요. 중복 프록시는 핸드셰이크를 늘리고 소스 주소를 바꾸며, 문제 로그를 두 기기로 분산시킵니다.

로컬 리소스와 백그라운드 작업

클라이언트 인터페이스가 버벅인다고 해서 프록시 처리량이 부족한 것은 아닙니다. 시스템이 파일 동기화, 사진 백업, 게임 업데이트 또는 가상 머신을 실행 중이면 CPU, 디스크와 네트워크 리소스가 서로 경쟁합니다. 작업 관리자나 활성 상태 보기를 통해 백그라운드 프로세스가 네트워크를 모두 사용하는지 확인하세요. 보안 소프트웨어의 HTTPS 검사는 모든 연결을 검사해 지연 시간을 크게 늘릴 수 있으므로 임시 비교 테스트로 영향을 판단하세요. 조직의 승인이 없는 기기에서는 관리 정책을 변경하지 마세요.

최종적으로 “기본 네트워크 속도, 고정 노드 성능, 문제 시간대, 대상 유형, TUN 활성화 여부” 다섯 가지를 기록하세요. 단순히 “느리다”고만 하면 지연 시간, 대역폭, 패킷 손실과 DNS 조회 시간 중 무엇이 문제인지 판단할 수 없습니다. 재현 가능한 조건을 확보한 뒤 더 안정적인 노드를 선택하거나 정책 그룹을 조정하고 DNS 또는 MTU를 수정하세요. 노드를 장기간 사용할 수 없다면 복잡한 매개변수를 계속 쌓기보다 교체하는 편이 확실합니다. 로컬 설정을 여러 번 수정해 추적하기 어렵다면 백업 후 최소 설정을 새로 만들어 기능을 하나씩 복구하세요.

5. DNS 조회 실패, 오염, 누출과 순환 조회

도메인 문제인지 연결 문제인지 먼저 확인하세요

DNS 오류는 노드 시간 초과로 오해하기 쉽습니다. 가장 직접적인 구분 방법은 도메인과 IP를 비교하는 것입니다. 도메인 접속은 실패하지만 알고 있는 IP로는 연결된다면 DNS 경로를 우선 점검해야 합니다. 도메인이 주소로 정상 해석되지만 연결이 계속 시간 초과되면 노드, 라우팅과 방화벽을 확인하세요. nslookup, dig 또는 시스템 기본 조회 명령으로 반환 레코드를 확인하고, Clash 로그에서 조회가 시스템 DNS, Clash DNS 또는 원격 DNS 중 어디에서 처리됐는지도 살펴보세요.

nslookup example.com
dig A example.com
dig AAAA example.com
ipconfig /flushdns
sudo dscacheutil -flushcache

명령줄 결과와 브라우저 결과가 다를 수 있습니다. 브라우저는 자체 보안 DNS, 캐시 또는 확장 프로그램을 사용할 수 있지만 터미널은 보통 시스템 리졸버를 사용합니다. 먼저 브라우저의 사용자 지정 DNS를 끄고 모든 앱이 같은 경로를 사용하는지 비교하세요. 브라우저만 이상하다면 Clash의 글로벌 DNS를 수정하는 것이 첫 번째 선택은 아닙니다. 브라우저, 터미널과 클라이언트 업데이트가 모두 실패한다면 시스템 DNS 또는 네트워크 출구 문제일 가능성이 높습니다.

redir-host와 fake-ip의 차이를 이해하세요

redir-host는 실제 해석 주소를 반환해 동작이 직관적이지만, 규칙 판단이 해석 결과에 의존할 수 있고 네트워크에 따라 반환값이 달라질 수 있습니다. fake-ip는 앱에 예약 주소를 반환한 뒤 Clash가 도메인 매핑을 저장하고 후속 연결을 인계하므로 더 이른 단계에서 도메인 기준으로 트래픽을 분기할 수 있습니다. fake-ip 모드에서 예약 주소가 보이는 것은 정상이며 이를 실제 서버 주소로 보면 안 됩니다. 실제 문제는 앱이 Clash를 우회해 fake-ip에 직접 접속하거나 매핑 기록이 만료된 뒤 연결이 제대로 복원되지 않는 경우입니다.

일부 LAN 검색, 프린터, 게임과 실제 IP에 의존하는 앱은 fake-ip에 적합하지 않습니다. 필터 목록으로 특정 도메인만 실제 주소를 반환하도록 설정할 수 있습니다. 필터 규칙은 문제가 발생한 구체적인 도메인부터 시작하고, 지나치게 넓은 접미사를 한 번에 추가하지 마세요. 그러면 많은 요청이 fake-ip 도메인 매핑의 장점을 우회하게 됩니다. 수정 후 클라이언트 DNS 캐시와 앱 캐시를 지우고 원래 상황을 다시 테스트하세요.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost"
    - "time.*"
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

이 예시는 일반적인 필드 구조를 보여주기 위한 것이며 실제 DNS 주소는 현재 네트워크에서 접근 가능한지에 따라 선택해야 합니다. DNS 서버 자체에 프록시를 거쳐야 한다면 시작 단계에서도 사용할 수 있는 기본 조회 경로가 있는지 확인하세요. 그렇지 않으면 클라이언트가 암호화 DNS에 연결하기 위해 먼저 해당 도메인을 해석해야 하지만, 그 도메인 해석이 아직 연결되지 않은 프록시에 의존해 순환 의존이 발생합니다.

DNS 순환과 시작 단계 의존성 처리

노드 서버가 도메인을 사용한다면 Clash는 프록시를 만들기 전에 노드 진입점을 먼저 해석해야 합니다. 모든 nameserver가 해당 프록시를 통해서만 접근 가능하면 시작 단계에서 사용할 수 있는 리졸버가 없어집니다. 해결 방법은 노드 도메인을 직접 연결로 해석할 수 있는 bootstrap 리졸버를 준비하거나, 설정에서 지원할 경우 명시적인 default-nameserver를 사용하는 것입니다. 기본 리졸버는 프록시 연결을 돕는 역할이며 모든 앱 조회를 담당할 필요는 없습니다. 설정 후 시작 로그에서 노드 진입점 해석이 프록시 연결보다 먼저 발생하고 중복 시간 초과가 없는지 확인하세요.

TUN 모드는 시스템의 모든 DNS 트래픽을 인계할 수도 있습니다. 시스템 DNS가 Clash를 가리키고 Clash의 업스트림이 다시 시스템 수신 주소를 잘못 가리키면 조회가 로컬에서 순환합니다. 업스트림 주소가 현재 클라이언트 자체의 DNS 수신 포트가 아닌지, 다른 프록시 소프트웨어를 통해 다시 전달되지 않는지 확인하세요. LAN 라우터, 광고 차단기와 클라이언트가 동시에 DNS 서비스를 제공한다면 요청 순서를 그려보는 것이 도움이 됩니다. 앱에서 시스템으로, 시스템에서 Clash로, Clash에서 업스트림으로 이어지는 각 단계에는 명확하고 중복되지 않는 대상이 있어야 합니다.

DNS 누출과 트래픽 분기 일관성

DNS 누출은 일반적으로 도메인 조회가 실제 연결과 다른 네트워크 경로를 사용하는 것을 뜻합니다. 반드시 인터넷이 끊기는 것은 아니지만 해석 결과와 프록시 출구 지역이 어긋나 콘텐츠 전송 오류, 비정상적인 사이트 리디렉션 또는 불안정한 속도가 발생할 수 있습니다. 규칙 모드에서는 프록시가 필요한 도메인을 적절한 원격 조회 경로로 처리하고 직접 연결 도메인은 로컬에서 조회하도록 할 수 있습니다. 핵심은 DNS 규칙과 연결 규칙을 일치시키는 것입니다. 모든 조회를 하나의 원격 서버로 강제하면 로컬 서비스와 LAN 도메인이 작동하지 않을 수 있습니다.

누출을 확인할 때 하나의 웹페이지 결과에만 의존하지 마세요. 웹페이지에는 특정 요청이 사용한 조회 서비스만 반영되며 브라우저 보안 DNS, 사전 연결과 캐시가 결과에 영향을 줄 수 있습니다. 더 확실한 방법은 캐시를 지운 뒤 새 도메인을 조회하면서 Clash DNS 로그, 시스템 패킷 캡처 또는 업스트림 조회 기록을 함께 관찰하는 것입니다. 조회가 예상한 경로를 거치는지 확인한 다음 개인정보 보호나 지역 일치 문제를 판단하세요.

캐시를 지우고 최소 설정으로 복구하세요

DNS를 수정한 뒤에는 클라이언트 자체 캐시, 운영체제 캐시, 브라우저 캐시와 라우터 캐시 등 여러 계층을 정리해야 합니다. 보통 Clash 코어를 먼저 재시작하고 시스템 DNS를 갱신한 다음 브라우저를 완전히 종료했다가 다시 열면 됩니다. 라우터 재시작은 공인 IP, 무선 연결과 DHCP 상태를 동시에 바꾸므로 첫 단계로 권장하지 않습니다. 정리 후 잠시 정상이다가 다시 실패한다면 자동 오버라이드 설정, DHCP가 배포하는 DNS와 브라우저 정책이 이전 설정을 다시 기록하는지 확인하세요.

복잡한 설정에서 원인을 찾기 어렵다면 최소 DNS 설정을 구성하세요. 접근 가능한 기본 리졸버 하나, 강화 모드 하나만 두고 추가 스크립트와 오버라이드는 끈 상태에서 일반 도메인만 테스트합니다. 안정성을 확인한 뒤 fallback, 트래픽 분기와 필터 규칙을 하나씩 추가하세요. 항목을 추가할 때마다 동작을 기록하면 대형 설정을 복사하는 것보다 느리더라도 문제를 일으킨 필드를 정확히 찾고 네트워크 환경 차이를 코어 결함으로 오해하는 일을 줄일 수 있습니다.

6. 시스템 프록시는 켜졌지만 브라우저나 터미널에서 작동하지 않을 때

시스템 프록시는 시스템 설정을 따르는 앱에만 영향을 줍니다

시스템 프록시는 운영체제의 모든 트래픽을 가로채는 기능이 아닙니다. 브라우저와 일부 데스크톱 앱은 시스템 HTTP, HTTPS 또는 SOCKS 설정을 읽지만, 터미널 명령어, 게임, 가상 머신과 일부 크로스 플랫폼 앱은 이를 완전히 무시할 수 있습니다. 따라서 “브라우저는 되지만 터미널은 안 됨”은 대개 Clash 문제가 아니라 두 종류의 앱이 서로 다른 프록시 진입점을 사용하는 문제입니다. 더 많은 트래픽을 처리해야 한다면 TUN 모드를 고려하고, 단일 명령만 처리할 때는 환경 변수를 명시하는 편이 제어와 해제가 쉽습니다.

운영체제의 프록시 설정을 열어 서버 주소가 로컬 루프백 주소인지, 포트가 Clash의 현재 혼합 포트와 일치하는지 확인하세요. 클라이언트에서 설정이나 포트를 바꿔도 이전 시스템 설정이 동기화되지 않을 수 있습니다. 자동 프록시 스크립트, 기업 설정과 다른 프록시 소프트웨어가 수동 설정을 덮어쓰는지도 확인해야 합니다. Windows의 서로 다른 네트워크 설정 메뉴가 결국 같은 프록시 항목을 기록할 수 있으므로 여러 위치에서 반복해 수정하면 혼란이 커집니다. 클라이언트 상태와 시스템에 실제로 저장된 값을 기준으로 판단하세요.

브라우저 확장 프로그램과 독립 DNS

프록시 확장 프로그램은 시스템 프록시를 덮어쓸 수 있습니다. 확장 프로그램이 직접 연결, 자동 전환 상태이거나 이전 포트를 참조하면 시스템 프록시 스위치를 켜도 예상대로 작동하지 않습니다. 브라우저 시크릿 창에서 프록시 관련 확장 프로그램을 잠시 끄고 시스템 프록시만으로 테스트하세요. 복구된다면 제어 방식을 하나로 통일하세요. Clash가 시스템 프록시를 기록하게 하거나 확장 프로그램이 Clash 로컬 포트를 명시적으로 가리키게 해야 하며, 두 규칙이 동시에 판단하도록 두지 마세요.

브라우저 내장 보안 DNS가 시스템 조회 경로를 우회해 웹페이지 도메인 해석과 Clash 설정을 다르게 만들 수도 있습니다. 일반적으로 프록시 TCP 연결 자체에는 영향을 주지 않지만 규칙 매칭, 지역 결과와 문제 판단에 영향을 줍니다. 테스트할 때는 시스템 기본 DNS를 잠시 사용해 브라우저와 터미널의 동작이 일치하는지 확인한 뒤 브라우저 독립 조회를 켤지 결정하세요. 브라우저와 터미널을 나누어 점검하는 방법은 시스템 프록시가 작동하지 않을 때의 해결 방법을 참고하세요.

터미널에 환경 변수 설정

많은 명령줄 도구가 HTTP_PROXY, HTTPS_PROXY와 ALL_PROXY를 읽습니다. 변수는 현재 터미널 세션 또는 해당 세션에서 실행한 프로세스에만 적용되며, 셸 설정 파일에 기록해야 새 세션에서도 유지됩니다. 먼저 임시로 설정해 테스트를 완료한 뒤 삭제하세요. 나중에 클라이언트가 실행되지 않을 때 모든 명령어가 작동하지 않는 포트를 가리키는 일을 막을 수 있습니다.

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5h://127.0.0.1:7890

curl -I https://example.com

unset HTTP_PROXY
unset HTTPS_PROXY
unset ALL_PROXY

socks5h의 h는 도메인도 프록시 측에서 해석한다는 뜻이며, 로컬 DNS와 프록시 경로가 달라지는 문제를 피하는 데 적합합니다. 도구마다 지원하는 변수와 프로토콜이 완전히 같지는 않습니다. 일부는 소문자 변수만 인식하고 자체 설정 파일을 사용하는 도구도 있습니다. curl은 성공하지만 패키지 관리자가 실패한다면 Clash를 계속 수정하지 말고 해당 도구의 프록시 문서를 확인하세요. Windows PowerShell에서는 현재 세션의 환경 변수를 사용할 수 있으며 창을 닫으면 자연스럽게 사라지므로 테스트에 적합합니다.

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
curl.exe -I https://example.com
Remove-Item Env:HTTP_PROXY
Remove-Item Env:HTTPS_PROXY

TUN 모드로 전환해야 할 때

앱에 프록시 설정이 없거나 시스템 프록시를 무시하거나 UDP 트래픽까지 처리해야 한다면 TUN 모드가 더 적합합니다. TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 통해 트래픽을 받으므로 시스템 프록시보다 적용 범위가 넓지만 VPN, 가상 머신, 컨테이너와 보안 소프트웨어와 충돌하기도 쉽습니다. 켜기 전에 다른 네트워크 가로채기 도구를 종료하고 기본 시스템 프록시 모드가 정상인지 확인하세요. 그러면 문제가 발생했을 때 노드가 아니라 가상 인터페이스, 라우팅 또는 권한 문제로 원인을 좁힐 수 있습니다.

TUN을 켠 뒤 시스템에 새 가상 인터페이스가 추가됐는지, 기본 경로가 합리적인지, DNS가 올바르게 인계됐는지 확인하세요. 일부 시스템은 인터페이스를 만들 때 관리자 권한이 필요합니다. 권한이 부족하면 화면의 스위치는 켜져도 코어 로그에는 장치 생성 실패가 기록될 수 있습니다. 절전 모드, 네트워크 전환 또는 VPN 연결 후에는 라우팅 우선순위가 바뀌어 일부 트래픽만 우회하거나 전체 연결이 끊길 수 있습니다. TUN을 껐다가 다시 켜면 라우팅을 재구성할 수 있지만, 자주 발생한다면 충돌 소프트웨어와 인터페이스 우선순위를 점검하세요.

LAN 연결과 원격 기기

휴대폰이나 다른 컴퓨터에서 이 기기의 Clash를 사용하려면 LAN 연결 허용을 켜고, 원격 기기에는 Clash가 실행 중인 기기의 LAN IP를 입력하세요. 127.0.0.1은 입력하면 안 됩니다. 루프백 주소는 항상 현재 기기 자신을 가리킵니다. 호스트 방화벽에서도 신뢰할 수 있는 LAN에서 해당 포트로 들어오는 연결을 허용해야 합니다. 먼저 호스트에서 포트가 어떤 주소에 바인딩됐는지 확인하세요. 루프백 주소만 수신하면 다른 기기는 연결할 수 없으며, LAN 인터페이스에서도 수신하도록 한 뒤 원격 기기에서 포트 접근성을 테스트하세요.

LAN 공유는 신뢰할 수 있는 네트워크에서만 사용하세요. 공공 Wi-Fi에서 공유할 필요가 없다면 이 옵션을 끄세요. 원격 기기가 로컬 포트에는 연결되지만 인터넷에 접속하지 못한다면 호스트 Clash 로그에 해당 기기에서 온 요청이 나타나는지 확인하세요. 로그가 없으면 요청이 도달하지 않은 것이므로 IP, 포트, 클라이언트 격리와 방화벽을 점검해야 합니다. 로그는 있지만 실패한다면 노드, 규칙과 DNS 경로를 계속 확인하세요. “원격 기기에서 호스트까지”와 “호스트에서 노드까지”를 구분하면 잘못된 기기에서 설정을 반복 수정하는 일을 피할 수 있습니다.

7. 클라이언트가 시작되지 않거나 반복 충돌하거나 포트가 사용 중일 때

인터페이스 종료와 코어 종료를 구분하세요

Clash 클라이언트는 일반적으로 그래픽 인터페이스와 프록시 코어로 구성됩니다. 창을 닫아도 코어가 백그라운드에서 계속 실행될 수 있고, 반대로 인터페이스는 정상적으로 열리지만 설정 오류나 포트 충돌 때문에 코어가 계속 종료될 수도 있습니다. 작업 표시줄, 메뉴 막대 아이콘과 프로세스 목록을 통해 두 경우를 구분할 수 있습니다. 시작되지 않으면 먼저 같은 종류의 클라이언트와 잔여 코어 프로세스를 종료한 뒤 하나의 클라이언트만 실행하세요. Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu 등 시스템 프록시를 기록하는 프로그램을 동시에 실행하면 포트, 시스템 프록시와 TUN 라우팅이 서로 덮어쓸 수 있습니다.

종료 지점을 판단하는 첫 번째 근거는 로그입니다. 인터페이스가 전혀 나타나지 않으면 시스템 이벤트 뷰어, 충돌 보고서 또는 터미널 실행 출력에서 정보를 찾으세요. 인터페이스는 보이지만 프록시 상태가 반복해서 중지된다면 코어 로그를 확인해야 합니다. 설정 파싱 오류에는 보통 필드나 줄 번호가 표시되고, 포트 충돌에는 address already in use, 권한 문제에는 permission denied가 나타납니다. 동적 라이브러리나 구성 요소가 없으면 앱 시작 단계에서 로드 실패가 보고됩니다.

포트 점유 원인 파악

혼합 포트, 제어 포트와 DNS 수신 포트 모두 충돌할 수 있습니다. 먼저 클라이언트 설정에서 관련 포트를 기록한 뒤 시스템 명령어로 점유 프로세스를 조회하세요. Windows의 PID는 작업 관리자 세부 정보 페이지에서 프로세스와 대응시킬 수 있고, macOS와 Linux의 lsof는 프로세스 이름을 직접 표시합니다. 포트가 사용 중이라는 이유만으로 시스템 프로세스를 즉시 종료하지 마세요. 먼저 이전 Clash 코어인지, 다른 프록시 도구인지 또는 업무용 서비스인지 확인해야 합니다. 필요한 프로그램이 해당 포트를 사용 중이라면 Clash 설정에서 비어 있는 포트로 바꾸고 시스템 프록시와 터미널 변수도 함께 업데이트하세요.

netstat -ano | findstr :7890
lsof -nP -iTCP:7890 -sTCP:LISTEN
ss -lntp | grep 7890

포트를 바꾼 뒤에도 충돌이 표시된다면 설정 파일이 인터페이스 설정을 덮어쓰거나 클라이언트가 여러 수신 설정을 동시에 불러오는 것일 수 있습니다. 현재 적용된 설정에서 mixed-port, port, socks-port, external-controller와 DNS listen을 확인하세요. 프로세스 확인과 포트 변경 절차는 포트 사용 중으로 시작되지 않을 때의 해결 방법을 참고하세요.

손상된 설정과 비호환 필드 처리

새 설정을 가져온 직후 클라이언트가 충돌하거나 코어가 시작되지 않으면 먼저 이전 설정으로 되돌리세요. 인터페이스를 열 수 없다면 앱 데이터 디렉터리에서 설정을 백업한 뒤 최근 추가된 파일을 다른 곳으로 옮겨 기본 상태로 시작하게 할 수 있습니다. 클라이언트마다 데이터 디렉터리가 다르므로 경로를 확인하지 않은 상태에서 파일을 일괄 삭제하지 마세요. 클라이언트가 제공하는 초기화 또는 안전 시작 방식을 우선 사용하세요. 직접 처리할 때는 파일을 삭제하지 말고 이동해 사본을 남긴 뒤 복구를 확인하고 정리하세요.

설정 비호환은 코어 필드 변경, 지원되지 않는 스크립트 문법 또는 원격 규칙 형식 오류에서 자주 발생합니다. 로그의 마지막 연쇄 오류가 아니라 첫 번째 오류를 확인하세요. 첫 필드 파싱 실패로 이후 정책 그룹, 규칙과 DNS가 모두 만들어지지 않을 수 있습니다. 최소 설정으로 코어가 실행되는지 확인한 다음 프록시, 정책 그룹, 규칙과 DNS를 블록별로 추가하세요. 최소 설정이 안정적이면 원래 설정에 문제가 있는 것이고, 최소 설정도 종료된다면 프로그램 파일, 권한과 시스템 구성 요소를 확인해야 합니다.

권한, 앱 디렉터리와 시스템 차단

TUN 서비스 설치, 가상 인터페이스 생성과 시스템 프록시 기록에는 더 높은 권한이 필요할 수 있습니다. 일반 프록시 포트는 보통 클라이언트를 계속 관리자 권한으로 실행할 필요가 없지만, 서비스를 처음 설치할 때는 시스템 권한 요청이 나타날 수 있습니다. 권한을 거부해도 기본 시스템 프록시는 작동할 수 있지만 TUN은 시작되지 않을 수 있습니다. 로그를 통해 어떤 권한이 부족한지 확인하고 “항상 관리자 권한으로 실행”을 모든 문제의 해법으로 사용하지 마세요.

앱 디렉터리에 쓸 수 없으면 설정 저장 실패, 업데이트 실패 또는 시작 반복이 발생할 수 있습니다. 휴대용 프로그램을 보호된 디렉터리, 읽기 전용 디스크 또는 동기화 폴더에 두었을 때 특히 흔합니다. 클라이언트를 일반적인 앱 디렉터리에 설치하고 사용자 데이터 디렉터리에 쓰기 권한이 있는지 확인하세요. 보안 소프트웨어가 코어 파일을 격리하면 그래픽 인터페이스가 존재하지 않는 실행 파일을 계속 시작하려 할 수 있습니다. 시스템 보안 기록을 확인하고 출처를 검토한 뒤 복원할지 다운로드 페이지에서 유지 관리되는 클라이언트를 다시 설치할지 결정하세요.

업데이트 후 이상 현상과 클린 재설치

업데이트 후 충돌이 발생하면 먼저 시스템을 재시작해 이전 프로세스와 동적 라이브러리가 계속 점유 중인지 배제하세요. 그다음 구독 주소, 사용자 규칙과 오버라이드 설정을 백업하고 현재 설치 출처를 확인한 뒤 재설치하세요. 재설치는 사용자 데이터를 모두 바로 삭제하는 것이 아닙니다. 프로그램 파일이 원인이라면 설정을 보존해 복구할 수 있지만, 설정이나 데이터베이스 손상이 원인이라면 기존 데이터를 모두 보존할 때 문제가 다시 따라올 수 있습니다. 먼저 백업하고 새 설치를 빈 데이터로 시작하게 한 뒤 안정성을 확인하고 항목을 하나씩 가져오는 방식이 더 안전합니다.

Windows에서는 이벤트 뷰어의 애플리케이션 오류를 확인하고, macOS에서는 시스템이 생성한 충돌 보고서를 확인하세요. Linux는 터미널에서 시작하면 누락된 라이브러리와 권한 정보를 바로 볼 수 있는 경우가 많습니다. 로그를 공유할 때는 구독 주소, 노드 인증 정보, 로컬 사용자 이름과 디렉터리 같은 민감한 내용을 삭제하고 오류 전후의 맥락만 남기세요. 충돌이 안정적으로 재현된다면 “어떤 페이지를 열었는지, 어떤 유형의 설정을 가져왔는지, TUN을 켰는지, 직전에 무엇을 했는지”를 기록하세요. 종료 후 스크린샷 한 장만 제공하는 것보다 진단에 훨씬 유용합니다.

되돌릴 수 있는 안정 상태를 만드세요

복구 후 바로 기존 설정을 모두 켜지 마세요. 하나의 설정, 하나의 시스템 프록시 진입점과 기본 DNS로 일정 시간 사용한 뒤 TUN, 스크립트와 사용자 오버라이드를 활성화하세요. 변경할 때마다 작동하는 설정 사본을 보관하세요. 클라이언트는 현재 시스템에 맞고 계속 유지 관리되는 설치 패키지를 우선 선택해야 합니다. 데스크톱과 모바일 플랫폼에서는 Clash Plus를 먼저 확인할 수 있고, Linux에서는 Clash Verge Rev 또는 FlClash도 선택할 수 있습니다. 유지 관리가 중단된 소프트웨어는 기존 환경을 처리할 때만 적합하며 새 시스템 호환성 문제의 우선 해결책으로 삼지 마세요.

8. Android와 iOS 모바일 전용 점검

VPN 권한과 시스템 상태 확인

모바일 Clash 클라이언트는 일반적으로 시스템 VPN 인터페이스를 통해 트래픽을 인계하므로 앱 내부 버튼보다 상태 표시줄의 VPN 아이콘이 시스템 권한 부여 완료 여부를 더 잘 보여줍니다. 처음 연결할 때 시스템에 VPN 요청이 표시되며 이를 거부하면 클라이언트가 연결 중 상태에 머물거나 즉시 끊길 수 있습니다. 시스템 VPN 설정에서 현재 구성이 존재하는지 확인하고 다른 VPN, 광고 차단기 또는 기업 보안 앱이 같은 인터페이스를 사용하고 있지 않은지 점검하세요. 대부분의 모바일 운영체제에서는 한 번에 하나의 주요 VPN 연결만 허용되므로 두 앱을 단순히 겹쳐 실행할 수 없습니다.

Android에서는 “항상 켜진 VPN” 또는 “VPN 없이는 연결 차단”이 활성화돼 있을 수 있습니다. 이 설정이 다른 앱에 연결되어 있으면 Clash가 인터페이스를 만들 수 없습니다. Clash에 연결되어 있지만 클라이언트 코어가 시작되지 않은 경우에는 모든 네트워크가 시스템에서 차단될 수도 있습니다. 점검할 때는 강제 옵션을 잠시 끄고 기본 연결을 테스트한 뒤 클라이언트가 안정된 것을 확인하고 필요에 따라 다시 켜세요. iOS에서는 기존 VPN 구성을 삭제한 뒤 다시 권한을 부여하면 시스템에 저장된 구성과 현재 앱 상태가 맞지 않는 문제를 해결할 수 있습니다. 단, 조직 관리 구성인지 먼저 확인하세요.

백그라운드 제한, 배터리 최적화와 연결 끊김

모바일 운영체제는 백그라운드 앱을 제한합니다. 화면을 잠근 지 몇 분 뒤 프록시가 끊기고 클라이언트를 다시 열면 복구되는 경우는 대개 배터리 최적화, 백그라운드 활동 권한 또는 제조사 정리 정책과 관련이 있습니다. Android에서는 클라이언트를 배터리 최적화 제외 대상으로 설정하고 백그라운드 실행을 허용하며, 시스템의 자동 시작 관리에서 필요한 권한을 유지하세요. 제조사마다 메뉴 이름은 다르지만 판단 방법은 같습니다. 같은 네트워크에서 화면 켜짐, 화면 잠금과 절전 모드를 각각 테스트하며 VPN 아이콘과 클라이언트 로그가 언제 사라지는지 관찰하세요.

iOS는 백그라운드 네트워크 확장을 더 일관되게 관리하지만 저전력 모드, 네트워크 전환과 시스템 리소스 회수로 재연결이 발생할 수 있습니다. Wi-Fi에서 셀룰러 네트워크로 전환할 때마다 실패한다면 먼저 시스템이 인터페이스 전환을 완료할 때까지 기다린 뒤 수동으로 한 번 연결을 끊었다가 다시 연결하세요. 짧은 시간에 연결 버튼을 계속 누르면 완료되지 않은 상태가 여러 개 남을 수 있습니다. 앱을 종료하고 시스템 VPN 설정에서 연결을 끈 뒤 다시 시작하면 상태를 더 명확하게 확인할 수 있습니다.

Wi-Fi, 셀룰러 네트워크와 비공개 DNS

Wi-Fi에서만 실패하고 셀룰러 네트워크에서는 정상이라면 구독과 노드는 대체로 사용 가능하므로 Wi-Fi 인증, 라우터 DNS, IPv6과 클라이언트 격리를 확인하세요. 공공 Wi-Fi는 먼저 VPN을 끄고 웹 인증을 완료한 뒤 Clash를 연결해야 합니다. 셀룰러 네트워크에서만 실패한다면 모바일 네트워크의 IPv6, 데이터 절약, 통신사 액세스 포인트 또는 노드 진입점 접근성 때문일 수 있습니다. 지원 상태가 좋은 노드를 각각 선택하고 IPv6 관련 설정을 잠시 전환해 비교하세요.

Android의 비공개 DNS는 시스템 수준의 암호화 조회를 사용하므로 클라이언트 DNS 인계와 경로가 달라질 수 있습니다. 도메인은 열리지 않지만 IP는 접근 가능하다면 비공개 DNS를 잠시 자동으로 설정해 충돌 여부를 확인하세요. iOS의 암호화 DNS 프로파일, 콘텐츠 필터와 브라우저 독립 DNS도 비슷한 영향을 줍니다. 클라이언트 DNS, 시스템 비공개 DNS와 라우터 DNS를 동시에 수정하지 마세요. 먼저 한 계층만 비교하고 결과를 기록한 뒤 다음 단계로 넘어가세요.

앱별 프록시와 우회 목록

Android 클라이언트에는 앱별 프록시 기능이 있는 경우가 많습니다. 특정 앱만 연결되지 않고 브라우저는 정상이라면 해당 앱이 제외됐는지, 현재 모드가 “선택한 앱만 프록시”인데 앱을 선택하지 않은 것은 아닌지 확인하세요. 앱 업데이트, 복제 앱과 업무 프로필의 같은 이름 앱은 서로 다른 식별자를 가질 수 있으므로 각각 선택해야 합니다. 앱별 규칙을 바꾼 뒤에는 대상 앱을 완전히 종료하고 다시 열어야 합니다. 기존 연결은 새 경로로 자동 이동하지 않습니다.

시스템 서비스, LAN 기기와 결제 앱은 직접 연결이 필요한 경우가 있습니다. 명확한 장애가 있는 특정 앱만 우회 목록에 추가하고 많은 시스템 구성 요소를 한꺼번에 우회하지 마세요. 우회한 뒤에도 앱이 브라우저 엔진이나 공유 서비스를 통해 요청을 보내면 실제 경로가 앱 목록만으로 결정되지 않을 수 있습니다. 연결 로그의 대상 도메인과 프로세스 정보를 확인하고 규칙 설정과 함께 판단하는 것이 앱 이름만 보고 추측하는 것보다 정확합니다.

구독 업데이트와 저장소 권한

모바일에서 구독 주소를 복사하면 줄바꿈이 섞이거나 브라우저가 일부를 생략하기 쉽습니다. 클라이언트의 붙여넣기 가져오기 기능을 사용하고 주소의 앞뒤를 확인하세요. QR 코드 가져오기에 실패하면 텍스트 방식으로 바꿔 카메라 인식 문제와 네트워크 요청 문제를 구분할 수 있습니다. 업데이트 성공 메시지가 표시되지만 노드가 바뀌지 않는다면 현재 선택된 설정이 방금 업데이트한 구독인지 확인하고 수동으로 다시 불러오세요. 이전 설정이 계속 실행 중이면 화면의 구독 업데이트 시간만으로 코어가 전환됐다고 볼 수 없습니다.

일부 Android 버전은 파일 접근에 시스템 선택기를 사용합니다. 로컬 가져오기에서는 디렉터리나 클라우드의 자리표시자 파일만 허용하지 말고 실제 YAML 파일을 선택하세요. 클라우드 파일이 아직 다운로드되지 않았다면 클라이언트가 빈 내용을 읽을 수 있습니다. 먼저 파일 관리자에서 오프라인으로 저장한 뒤 클라이언트에서 가져오세요. 로그를 내보내거나 백업할 때도 저장 위치를 확인하세요. 앱 데이터를 삭제하면 내부 설정도 삭제되므로 초기화 전에 구독과 사용자 규칙을 백업해야 합니다.

모바일 기기 발열, 배터리 소모와 트래픽 이상

배터리가 계속 빠르게 소모되는 원인은 잦은 재연결, 접근할 수 없는 DNS, 지나치게 짧은 노드 테스트 주기 또는 많은 백그라운드 트래픽인 경우가 많습니다. 먼저 클라이언트에 연결 실패와 재시도가 계속 기록되는지 확인한 뒤 시스템 트래픽 통계에서 어떤 앱이 지속적으로 데이터를 전송하는지 살펴보세요. 자동 측정 간격이 너무 짧으면 모든 노드가 반복해서 연결을 만들고, 규칙 제공자와 구독 업데이트 실패도 재시도를 일으킬 수 있습니다. 자동 작업을 적절한 간격으로 되돌리고 필요하지 않은 상세 로그를 끄면 백그라운드 부담을 줄일 수 있습니다.

트래픽이 예상보다 크게 많다면 구독 서비스의 트래픽 통계 기준, 노드 배율과 기기 백그라운드 작업을 확인하세요. 클라이언트가 전달한 데이터는 대상 앱과 VPN 앱의 시스템 통계에 동시에 표시될 수 있으므로 단순히 합산하면 안 됩니다. 프록시 연결이 안정된 뒤 동영상 자동 재생, 클라우드 사진과 시스템 업데이트가 백그라운드 전송을 재개해 Clash 자체가 트래픽을 만든 것처럼 보일 수 있습니다. 일정한 시간 구간을 정하고 백그라운드 동기화를 끈 뒤 비교하는 편이 의미 있습니다.

모바일 복구 절차

다음 순서로 복구하는 것이 좋습니다. 먼저 VPN 연결을 끊고 다른 네트워크 인계 앱을 종료하세요. Wi-Fi 또는 셀룰러 네트워크의 직접 연결이 정상인지 확인한 뒤 Clash를 다시 열고 사용 가능한 것으로 확인된 설정과 노드를 선택합니다. VPN 권한을 허용하고 상태 표시줄과 연결 로그를 관찰한 다음 마지막으로 비공개 DNS, 앱별 프록시와 배터리 절약 설정을 복원하세요. 이 최소 상태에서도 기본 연결이 실패하면 Wi-Fi와 셀룰러 네트워크를 바꿔 교차 테스트해 기기 설정, 현재 네트워크 또는 구독 노드 문제를 빠르게 구분할 수 있습니다.

재설치해야 한다면 Android 다운로드 페이지 또는 iOS 다운로드 페이지에서 플랫폼에 맞는 클라이언트를 선택하세요. Clash Plus를 우선 선택할 수 있습니다. 재설치 전에 구독 주소와 필요한 규칙을 저장하고, 설치 후에는 먼저 하나의 설정을 가져와 기본 접속을 완료한 뒤 기존 설정을 단계적으로 복원하세요. 모바일 문제는 시스템 권한, 백그라운드 제한과 네트워크 전환이 함께 일으키는 경우가 많으므로 데스크톱 설정을 모두 복사하기보다 복구 단계를 단순하게 유지하는 편이 효과적입니다.