Clash 문제 해결 가이드

인터넷에 연결되지 않음: 로컬 네트워크와 프록시 경로 구분하기

프록시를 끈 상태의 네트워크부터 확인하기

브라우저에서 모든 사이트가 열리지 않으면 먼저 클라이언트의 시스템 프록시와 TUN 모드를 끄고, 평소 직접 접속할 수 있는 사이트를 테스트하세요. 클라이언트를 종료해도 운영체제에 수동 프록시 설정이 남아 있을 수 있으니 네트워크 설정도 확인해야 합니다. 프록시를 꺼도 인터넷에 연결되지 않는다면 노드를 계속 바꾸기보다 Wi-Fi, 이더넷 케이블, 라우터, 네트워크 로그인 필요 여부부터 점검하세요.

호텔, 학교, 공용 Wi-Fi는 먼저 인증 페이지에 접속해야 하는 경우가 많습니다. 프록시나 사용자 지정 DNS 때문에 인증 페이지로 이동하지 못하면 Wi-Fi에 연결된 상태에서도 웹페이지가 열리지 않을 수 있습니다. 프록시를 일시 중지하고 네트워크 인증을 마친 뒤 클라이언트를 다시 켜세요. 같은 네트워크의 다른 기기도 직접 접속할 수 없다면 네트워크 자체부터 해결해야 합니다. 직접 연결이 정상임을 확인해야 이후 프록시 경로를 비교할 수 있습니다.

프록시를 지정한 요청으로 문제 위치 좁히기

클라이언트를 다시 켠 뒤 코어가 실행 중인지 확인하고 설정에 표시된 실제 혼합 포트를 확인하세요. 아래 명령어는 일반적인 로컬 포트를 예로 든 것이므로 실제 포트가 다르면 먼저 수정해야 합니다. 첫 번째 명령은 프록시 환경 변수를 무시하고, 두 번째 명령은 로컬 HTTP 프록시를 명시적으로 사용합니다. Windows에서는 curl.exe를, macOS와 Linux에서는 curl을 사용하세요. 다른 명령어 별칭을 같은 도구로 착각하지 않도록 주의하세요.

curl --noproxy "*" -I --connect-timeout 10 https://example.com
curl -x http://127.0.0.1:7890 -I --connect-timeout 10 https://example.com

현재 네트워크에서 접속 가능한 사이트로 테스트 주소를 바꾸고 두 요청에 같은 주소를 사용하세요. 두 번째 요청에서 즉시 연결 거부 오류가 발생하면 로컬 수신 포트나 코어가 문제일 가능성이 큽니다. 프록시 요청은 HTTP 응답을 받는데 브라우저에서는 접속이 안 된다면 브라우저 확장 프로그램, 시스템 프록시, 앱 자체 네트워크 설정을 확인하세요. 사이트가 접속을 거부하는 상태 코드를 반환한 것은 프록시 연결 실패와 다릅니다.

모드, 정책, 규칙의 실제 적용 여부 확인하기

로컬 포트에 연결되지만 사이트가 열리지 않는다면 먼저 현재 모드가 규칙, 전역, 직접 연결 중 무엇인지 확인하세요. 규칙 모드에서는 기본 화면에 선택된 노드만 볼 것이 아니라 연결 기록에 적용된 규칙과 정책 그룹을 확인해야 합니다. 하위 정책 그룹이 작동하지 않는 노드를 선택하고 있거나, 트래픽이 먼저 적용된 직접 연결 규칙으로 빠져나갈 수 있습니다. 연결 기록의 대상 도메인, 규칙, 최종 아웃바운드를 하나씩 대조하세요.

비교를 위해 잠시 전역 모드로 바꾸고 사용 가능한 노드를 직접 지정할 수 있습니다. 전역 모드에서는 정상이고 규칙 모드에서 실패한다면 규칙 순서, 규칙 세트 로딩, DNS를 중점적으로 확인하세요. 두 모드 모두 실패하면 노드 연결을 먼저 점검하세요. 전역 모드는 원인 파악을 위한 도구이지 모든 문제의 장기적인 해결책은 아닙니다. 비교를 마친 뒤 원래 모드로 되돌리고 해당 규칙을 수정해, 직접 연결해야 하는 서비스까지 프록시로 보내지 않도록 하세요.

복구 순서와 중단 기준

일부 사이트만 접속되지 않는다면 대상 서비스 장애 여부, 출구 지역 제한 여부, 계정의 접근 권한을 확인하세요. 브라우저에서 인증서 오류가 발생하면 기기의 날짜와 시간대도 확인해야 합니다. 인증서 검증을 끄는 방식으로 해결해서는 안 됩니다. 네트워크에서 다른 VPN, 가속 프로그램, 보안 소프트웨어를 사용 중이라면 한 번에 하나만 종료하고 테스트하세요. 여러 프로그램이 기본 경로를 동시에 바꾸면 요청 경로가 서로 덮어쓰일 수 있습니다.

각 단계를 마칠 때마다 기존 테스트 주소로 다시 확인하고 직접 연결, 프록시를 지정한 요청, 브라우저 접속 결과를 기록하세요. 세 가지 모두 정상으로 돌아온 뒤 다른 네트워크 도구를 하나씩 다시 켜세요. 추가 지원이 필요하다면 단순히 “연결 실패”라고 설명하기보다 오류 메시지 원문과 발생 단계를 전달하세요. 기본 연결이 복구되면 시스템 프록시 설정 가이드에서 평소 사용 방법을 확인할 수 있습니다.

노드 시간 초과: 테스트 실패와 실제 접속 불가 구분하기

어떤 테스트에서 시간 초과가 발생했는지 확인하기

클라이언트의 노드 속도 테스트는 보통 지정된 URL로 요청을 보내고 응답 시간을 측정합니다. 전체 다운로드 속도를 측정하는 것은 아니며 모든 앱이 같은 노드로 접속할 수 있다는 보장도 없습니다. 테스트 URL 자체가 제한되어 있거나 예상과 다른 응답을 보내는 경우, 시간 제한이 너무 짧은 경우에도 테스트가 실패할 수 있습니다. 먼저 실제 서비스에 해당 노드를 사용해 보고 테스트 조건 문제인지 프록시 연결 문제인지 판단하세요.

웹페이지는 열리는데 속도 테스트만 시간 초과로 표시된다면 테스트 주소의 프로토콜과 접속 가능 여부를 확인하고, 클라이언트나 구독 제공자가 안내하는 테스트 방법을 우선 사용하세요. 노드 하나를 확인하려고 여러 노드를 연속으로 동시에 측정하지 마세요. 동시 요청이 많으면 연결 제한에 걸리거나 현재 네트워크 자원을 소모할 수 있습니다. 노드 하나를 선택해 결과가 나올 때까지 기다린 다음, 이미 사용 가능한 것으로 확인된 다른 노드와 비교하세요.

로그의 연결 단계별로 서버 접속 확인하기

연결 로그에 표시되는 도메인 확인 실패, 연결 거부, 핸드셰이크 실패, 읽기·쓰기 시간 초과는 각각 다른 문제를 가리킵니다. 도메인 확인에 실패했다면 아직 서버 주소를 찾지 못한 상태입니다. 연결 거부는 대개 대상 포트에서 연결을 받지 않는다는 뜻이고, 핸드셰이크 실패는 프로토콜 설정, 인증 정보, 기기 시간, 네트워크 간섭과 관련될 수 있습니다. 화면의 빨간 상태만 캡처하지 말고 가장 낮은 단계의 원인까지 포함해 전체 오류 내용을 기록하세요.

Windows에서는 다음 명령으로 구독에 포함된 노드 서버의 TCP 포트에 연결할 수 있는지 확인할 수 있습니다. 주소와 포트는 실제 노드 정보로 바꾸세요. 이 테스트로 확인할 수 있는 것은 TCP 연결 여부뿐이며 프록시 인증 성공 여부는 알 수 없습니다. UDP를 주로 사용하는 노드는 TCP 테스트 실패만으로 사용할 수 없다고 단정할 수 없습니다. 노드 정보를 공개 게시판에 올리지 마세요.

Test-NetConnection -ComputerName example.com -Port 443

서버가 도메인을 사용한다면 먼저 예상한 유형의 주소로 해석되는지 확인하세요. 일부 네트워크에서 IPv4만 사용할 수 있는데 연결할 수 없는 IPv6 경로를 먼저 시도하면 대기 후 실패할 수 있습니다. 필요한 경우 결과를 기록해 둔 상태에서 클라이언트의 IPv6 관련 설정을 임시로 바꿔 비교할 수 있습니다. 다만 일부 프로토콜은 TLS 핸드셰이크에 서버 도메인이 필요하므로 구독에서 서버 도메인을 바로 삭제하지 마세요.

프로토콜 설정과 구독 상태 확인하기

노드가 기본 연결은 수립하지만 핸드셰이크 단계에서 실패한다면 구독을 새로고침하고 계정 상태, 이용 기간, 기기 제한을 확인하세요. 노드 정보를 직접 복사할 때 암호화 방식, 전송 유형, 서버 이름, 경로, 공개 키 같은 항목이 빠지기 쉽습니다. 다른 노드의 값을 조합하지 말고 현재 클라이언트에서 지원하는 전체 설정을 다시 가져오세요. 이름이 비슷해도 프로토콜마다 설정 항목을 서로 바꿔 쓸 수 있는 것은 아닙니다.

일부 최신 프로토콜은 최신 코어 기능이 필요합니다. 화면에 노드 이름이 표시되어도 코어가 모든 설정을 올바르게 불러온다는 뜻은 아닙니다. 시작 로그에서 지원되지 않는 프록시 유형이나 설정 항목이 있는지 확인하세요. 유지보수가 중단된 Clash for Windows 또는 ClashX Meta를 사용한다면 기존 설정을 보관한 뒤 클라이언트 다운로드 페이지에서 유지보수 중인 클라이언트를 선택해 확인하세요. 일반적인 선택지로는 Clash Plus를 우선 고려할 수 있습니다.

네트워크와 노드를 교차 테스트해 범위 좁히기

같은 기기를 휴대전화 핫스팟에 연결했을 때 문제가 해결된다면 기존 네트워크의 출구, 인증, 라우팅, 방화벽을 우선 확인할 필요가 있습니다. 다만 핫스팟과 기존 네트워크의 IP 프로토콜이 다를 수 있으므로 이 결과만으로 특정 통신사가 노드를 제한한다고 단정할 수는 없습니다. 클라이언트와 설정은 그대로 둔 채 두 네트워크의 DNS 응답과 오류 발생 단계를 비교해야 네트워크 차이와 설정 차이를 구분할 수 있습니다.

노드 하나만 실패하고 다른 노드는 정상이라면 전역 DNS와 시스템 프록시를 바꾸지 말고 해당 노드의 사용 가능 여부와 설정을 확인하세요. 여러 네트워크에서 모든 노드가 실패한다면 구독 계정과 클라이언트 호환성을 점검하세요. 자동 정책 그룹이 문제가 있는 노드를 계속 선택할 수도 있으므로 문제를 해결하는 동안은 아웃바운드 하나를 고정하세요. 복구한 뒤 정책 그룹 유형과 선택 기준을 참고해 테스트 동작을 조정하세요.

구독 실패: 다운로드·파싱·적용 단계별로 확인하기

먼저 오류가 발생한 단계 확인하기

구독 가져오기는 링크 내용 가져오기, 설정 파싱, 연결된 리소스 다운로드, 설정 활성화로 이어지는 여러 단계의 작업입니다. 업데이트 오류가 발생해도 기존 설정까지 반드시 사용할 수 없게 된 것은 아닙니다. 일부 클라이언트는 마지막으로 업데이트에 성공한 내용을 유지합니다. 설정 카드의 업데이트 시간과 활성화 상태를 먼저 확인하고 오류 세부 정보를 읽으세요. 사용 가능한 기존 설정을 삭제해 구독을 업데이트할 네트워크 경로까지 잃지 않도록 주의하세요.

구독 링크를 복사할 때 공백, 줄바꿈, 한국어 문장 부호, 메신저가 덧붙인 설명이 포함되지 않았는지 확인하세요. 링크의 쿼리 매개변수에는 인증 정보가 포함될 수 있으므로 임의로 삭제하거나 공개하면 안 됩니다. 제공자가 로그인 후 전용 구독 링크를 발급하도록 안내한다면 계정 웹페이지 주소가 아니라 해당 절차를 이용하세요. 일반 웹페이지 주소가 브라우저에서 열리더라도 클라이언트가 파싱할 수 있는 설정을 반환하는 것은 아닙니다.

다운로드 실패와 업데이트 경로 순환 문제 해결하기

요청 시간 초과, 연결 재설정, 도메인 확인 오류가 발생하면 먼저 구독 도메인에 접속할 수 있는지 확인하세요. 그런 다음 클라이언트가 구독 업데이트에 직접 연결, 현재 프록시, 사용자 지정 다운로드 경로 중 무엇을 사용하는지 점검하세요. 일부 네트워크에서는 구독 서비스에 직접 연결할 수 없지만 기존 노드는 정상일 수 있습니다. 이 경우 기존 설정을 통해 업데이트 요청을 보내도록 임시로 바꿀 수 있습니다. 반대로 기존 프록시가 이미 작동하지 않는데 업데이트도 프록시를 강제로 사용하면 순환 문제가 생기므로 접속 가능한 다운로드 경로로 바꾸세요.

인증 실패나 접근 거부가 발생하면 제공자에게 링크 상태, 계정 제한, 새 주소 발급 필요 여부를 확인하세요. 요청이 지나치게 잦으면 일시적으로 제한될 수 있으므로 업데이트 버튼을 연속으로 눌러도 빨라지지 않습니다. 로그에 서버 인증서 오류가 표시되면 먼저 시스템 시간과 네트워크 로그인 상태를 확인하세요. 인증서 검증을 전역에서 건너뛰도록 설정해 구독 업데이트를 계속하는 것은 피하세요. 오류 원인을 감출 뿐 아니라 연결 보안도 낮아집니다.

설정 형식 오류와 코어 호환성 문제 구분하기

다운로드 후 YAML 파싱 오류가 발생하면 오류 줄 주변의 들여쓰기, 콜론, 따옴표를 확인하세요. YAML은 보통 공백으로 들여쓰기하므로 코드를 복사할 때 탭이 섞이거나 키에 전각 콜론이 들어가면 파일을 불러오지 못할 수 있습니다. 다만 표시된 위치는 파서가 멈춘 곳일 뿐 실제 오류는 바로 앞줄에 있을 수도 있습니다. 마지막으로 정상 작동한 파일을 복구한 뒤 복사본에서 수정하세요. 구독 파일 전체를 새로 작성하지 마세요.

서버가 로그인 페이지, 점검 페이지, 구조화된 오류 메시지를 반환했는데도 설정 파일로 저장되면 이후 파싱 오류가 발생할 수 있습니다. 이 경우 들여쓰기를 반복해서 바꾸기보다 응답 내용의 첫 부분이 설정 형식에 맞는지 확인하세요. 프로토콜 호환성 문제라면 제공자가 Clash 또는 mihomo용으로 표시한 형식을 선택하고 현재 클라이언트에서 사용하는 코어가 관련 항목을 지원하는지 확인해야 합니다.

노드 목록은 표시되지만 설정을 활성화할 수 없다면 규칙 세트와 프록시 프로바이더가 정상적으로 로드되었는지도 확인하세요. 설정 본문, 노드 프로바이더, 규칙 프로바이더는 서로 다른 주소에서 가져올 수 있으며, 어느 하나라도 실패하면 최종 사용에 영향을 줄 수 있습니다. 로그에 특정 리소스 이름이 명시되어 있다면 해당 리소스의 경로, 접속 방식, 형식을 따로 확인하세요. 모든 오류를 기본 구독 링크 문제로 돌리지 마세요.

사용자 지정 규칙과 보안 범위 유지하기

구독을 업데이트하면 원격에서 관리되는 항목이 덮어써지는 경우가 많습니다. 포트, LAN 연결 허용, 사용자 지정 규칙은 클라이언트에서 지원하는 재정의, 병합, 확장 기능으로 보관하세요. 적용 순서는 클라이언트 안내를 기준으로 합니다. 다운로드한 파일을 직접 편집하면 현재 세션에서만 유지될 수 있습니다. 업데이트를 한 번 실행한 뒤 사용자 지정 규칙이 남아 있는지 확인하고, 텍스트만 살펴보지 말고 연결 기록으로 실제 적용 여부를 검증하세요.

설정에 원격 리소스와 스크립트 확장이 있다면 출처와 용도를 확인하세요. 구독 주소는 접속 자격 증명과 같으며 변환 서비스가 노드 정보를 확인할 수도 있으므로 출처를 알 수 없는 사이트에 함부로 전달하면 안 됩니다. 변환이 필요한 경우와 지원 형식은 구독 변환 FAQ를, 기본 가져오기 절차는 구독 가져오기 가이드를 참고하세요.

속도 저하: 노드·경로·기기를 단계별로 비교하기

대기 시간·지연 시간·처리량을 나눠 기록하기

웹페이지가 처음 열릴 때 오래 걸리는 문제, 동영상 재생 끊김, 파일 다운로드 속도 저하는 서로 다른 단계에서 발생할 수 있습니다. 첫 접속 지연은 DNS, 핸드셰이크, 규칙 리소스 로딩과 관련이 있는 경우가 많습니다. 다운로드가 계속 느린 경우에는 회선 대역폭, 혼잡, 대상 서버 제한의 영향을 더 많이 받습니다. 노드 속도 테스트의 응답 시간은 사용 가능한 대역폭과 다릅니다. 응답 시간이 낮은 노드도 혼잡 시간대에는 처리량이 떨어질 수 있으므로 속도 문제의 근거로 단정하지 마세요.

비교할 때는 기기, 대상 주소, 테스트 방법, 시간대를 고정하고 변수 하나만 바꾸세요. 먼저 같은 파일이나 서비스를 이용해 노드 두 개를 비교한 다음, 노드는 그대로 두고 네트워크를 바꾸세요. 속도 측정 도구는 데이터를 많이 사용하거나 서버 측 속도 제한을 유발할 수 있으므로 계정 데이터 한도를 확인한 뒤 테스트하세요. 클라우드 동기화, 시스템 업데이트, 대역폭 테스트를 동시에 실행하면 기기 자원을 나눠 쓰면서 속도가 떨어져 보일 수 있습니다.

먼저 노드와 출구 경로 확인하기

특정 노드만 느리다면 같은 지역 또는 다른 경로의 노드에서도 같은 현상이 나타나는지 확인하세요. 같은 지역이라고 라우팅 경로가 같다는 보장은 없고, 이름이 다르다고 출구가 서로 다른 것도 아닙니다. 저녁에 느려졌다가 다른 시간대에 회복된다면 혼잡과 서버 부하를 살펴볼 필요가 있습니다. 하루 종일 일정한 상한에서 멈춘다면 요금제, 대상 서비스, 라우터 속도 제한, 로컬 연결 속도도 확인하세요. 바로 클라이언트 문제로 단정하지 마세요.

특정 사이트나 다운로드 서버만 느리다면 같은 리소스에 다른 노드로 접속해 비교하세요. 일부 콘텐츠 전송 네트워크는 DNS나 출구 IP를 기준으로 서버를 배정하므로 노드를 바꾸면 다른 엣지 서버에 연결되어 속도가 크게 달라질 수 있습니다. 이때는 모든 트래픽을 전역 프록시로 바꾸기보다 대상 서비스에 맞춰 정책을 조정하세요. 규칙 적용 여부를 먼저 확인하고 해당 서비스에 별도 정책 그룹이 필요한지 판단하세요.

기기 자원과 네트워크 연결 방식 확인하기

작업 관리자나 활성 상태 보기에서 클라이언트 코어, 브라우저, 보안 소프트웨어의 CPU 사용량을 확인하세요. 높은 처리량, 복잡한 규칙, 많은 동시 연결은 처리 부담을 높일 수 있으며 상세 로그를 계속 켜 두면 디스크 쓰기도 늘어납니다. 원인을 찾은 뒤에는 일반 로그 수준으로 되돌리세요. CPU 사용량이 거의 100%인데 네트워크 사용량은 낮다면 더 빠른 노드를 찾기보다 기기 병목을 먼저 점검하세요.

약한 Wi-Fi 신호, 같은 주파수 대역의 간섭, Bluetooth 공존, 라우터 성능 부족도 속도 변동을 일으킬 수 있습니다. 가능하다면 이더넷 연결과 비교하고 다른 기기의 대용량 작업은 일시 중지하세요. 시스템 프록시와 TUN 모드를 전환할 때는 앱이 실제로 같은 노드를 사용하는지 확인해야 합니다. 두 모드가 서로 다른 규칙이나 DNS 경로를 사용한다면 속도 차이를 특정 연결 방식이 본질적으로 더 빠르다고 해석할 수 없습니다.

동시 연결 수·MTU·자동 정책은 신중하게 조정하기

동시 연결 수를 늘려도 회선 자체의 대역폭을 높일 수는 없으며 서버 연결 제한이 심해질 수도 있습니다. 동시 연결 설정은 현재 코어 문서와 실제 앱 동작을 바탕으로 조정하고, 다른 프로토콜의 값을 그대로 적용하지 마세요. 작은 웹페이지는 열리지만 대용량 파일이 멈추거나 특정 터널만 문제가 있다면 경로 MTU를 확인할 수 있습니다. 먼저 다른 VPN을 종료한 결과와 비교하고 기존 값을 기록한 뒤 조금씩 테스트하세요.

온라인에 공유된 MTU 고정값을 그대로 적용하지 마세요. 네트워크 연결 방식과 터널 캡슐화에 따라 유효한 페이로드 크기가 다릅니다. 무작정 낮추면 문제를 일시적으로 우회할 뿐 아니라 추가 오버헤드가 생길 수도 있습니다. TUN과 관련된 문제로 확인되면 클라이언트가 지원하는 진단 방법으로 단편화와 라우팅을 점검하고 복구 가능한 설정을 유지하세요. 웹페이지가 가끔 느린 것만으로 시스템 네트워크 스택을 수정할 근거가 되지는 않습니다.

자동 속도 측정 정책 그룹은 테스트 조건이 바뀌면 노드를 전환할 수 있지만 이미 연결된 트래픽까지 새 노드로 바뀌는 것은 아닙니다. 테스트할 때는 노드를 고정하고 끝난 뒤 자동 정책을 다시 켜세요. 단계별 점검과 결과 기록 방법은 Clash 속도 저하 단계별 해결 가이드에서, 테스트 메뉴와 기본 비교 방법은 노드 속도 측정 가이드에서 확인할 수 있습니다.

DNS 문제: DNS 조회 경로와 연결 주소 확인하기

오류 메시지로 DNS 점검 필요 여부 판단하기

로그에 도메인 확인 실패, 호스트를 찾을 수 없음, DNS 조회 시간 초과가 명확히 표시되면 DNS 단계를 확인하세요. 대상 IP에 연결한 뒤 인증에 실패했다면 DNS부터 바꾸는 것은 우선순위가 아닙니다. 일부 사이트만 열리고 다른 사이트는 계속 대기하는 현상도 DNS와 관련될 수 있지만, 대상 서비스 장애, 잘못 적용된 규칙, 연결할 수 없는 IPv6 경로에서도 비슷한 증상이 나타납니다. 연결 기록을 함께 확인하세요.

시스템 DNS, 브라우저 보안 DNS, 클라이언트 내장 DNS, 프록시 서버 측 DNS가 동시에 사용될 수 있습니다. 명령줄 도구에서 확인한 주소가 브라우저에서 실제로 사용한 주소와 다를 수도 있습니다. 먼저 요청 경로를 파악하세요. 앱이 어디에 DNS 조회를 요청하는지, 조회가 TUN을 통과하는지, 클라이언트가 매핑 주소를 반환하는지, 어느 아웃바운드가 최종 연결을 만드는지 확인해야 합니다. 시스템 DNS만 바꿔도 브라우저나 클라이언트가 가로챈 조회에는 영향을 주지 않을 수 있습니다.

fake-ip와 실제 주소 조회 이해하기

fake-ip가 활성화되면 클라이언트는 예약 주소 범위에서 매핑 주소를 앱에 반환하고, 이후 연결 과정에서 해당 도메인을 다시 찾아냅니다. 이 결과를 도메인 확인 오류로 볼 필요는 없으며, 해당 주소로 공용 인터넷 연결을 직접 테스트해서도 안 됩니다. 중요한 것은 매핑 주소를 받은 뒤에도 앱 연결이 같은 클라이언트를 통과하는지입니다. DNS는 프록시를 통과하지만 연결은 클라이언트를 우회하면 매핑 주소를 받고도 접속하지 못할 수 있습니다.

로컬 네트워크 기기 검색, 특수 도메인 사용, DNS 결과 직접 확인이 필요한 앱은 모두 fake-ip를 사용하는 방식과 맞지 않을 수 있습니다. 전체 DNS 기능을 끄기보다 해당 도메인에 예외를 설정하세요. 아래 설정 조각은 항목 간 관계를 보여주는 예시이며 완전한 설정 파일이 아닙니다. 수신 주소는 로컬 루프백을 사용하고 다른 서비스와 포트가 겹치지 않도록 하세요. 적용하기 전에 클라이언트의 설정 덮어쓰기 기능이 해당 항목을 지원하는지도 확인하세요.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

예시의 DNS 서버는 설정 문법 설명용이며 모든 네트워크에서 접속할 수 있는 것은 아닙니다. 실제 사용 시에는 현재 네트워크에서 안정적으로 연결되고 개인정보 보호 요구 사항에도 맞는 서버를 선택하세요. 로컬 포트에서만 수신하도록 설정해도 시스템 조회가 자동으로 그 포트에 전달되지는 않습니다. 클라이언트의 TUN DNS 가로채기나 명시적인 전달 기능이 별도로 필요합니다. DNS를 가로채기 위해 서버가 모든 네트워크 인터페이스에서 수신하도록 열지 마세요.

암호화 DNS 시작 시 의존성 순환 방지하기

DoH처럼 도메인 이름을 사용하는 상위 DNS 서버를 설정하면 클라이언트가 먼저 해당 서버의 도메인을 조회해야 할 수 있습니다. 이 단계가 아직 연결되지 않은 프록시나 같은 상위 서버에 다시 의존하면 시작 순환이 발생합니다. 코어 문서에 따라 접속 가능한 부트스트랩 DNS 경로를 설정하고, 프록시 노드 서버 도메인에 사용되는 DNS도 확인하세요. 설정 항목 지원 여부와 라우팅 규칙 적용 방식은 현재 코어의 동작을 기준으로 판단해야 합니다.

브라우저에서 사용자 지정 보안 DNS를 사용하면 시스템 DNS 정책을 우회해 클라이언트 규칙과 실제 연결 주소가 달라질 수 있습니다. 문제를 확인할 때는 기존 설정을 기록한 뒤 잠시 시스템 DNS를 사용하도록 바꿔 비교하세요. 정상으로 돌아온다면 브라우저에 별도 DNS 설정을 적용할지 결정하면 됩니다. 기업 네트워크의 내부 도메인은 지정된 DNS에서만 확인할 수 있으므로 공용 DNS를 모든 도메인의 대체 수단으로 사용하지 마세요.

캐시를 지우기 전에 설정이 올바른지 확인하기

DNS 설정을 바꾼 뒤에도 기존 연결, 브라우저 캐시, 시스템 캐시에 이전 결과가 남을 수 있습니다. 관련 페이지나 앱 연결을 먼저 닫고 운영체제에서 지원하는 방법으로 캐시를 새로고침하세요. Windows에서는 아래 명령을 실행할 수 있습니다. 다른 플랫폼은 시스템 환경에 따라 캐시 서비스와 명령이 다르므로 그대로 따라 하면 안 됩니다. 캐시를 지우면 새 조회가 시작될 뿐, 연결할 수 없는 상위 DNS 서버나 잘못된 규칙이 수정되지는 않습니다.

ipconfig /flushdns

정상 복구 기준은 예상한 DNS 경로에서 해당 도메인이 올바른 결과로 확인되고 실제 서비스에도 안정적으로 연결되는 것입니다. 규칙 모드에서는 넓은 IP 규칙보다 도메인 규칙이 먼저 적용되는지도 확인하세요. GEOIP, GEOSITE, 규칙 세트의 관계는 규칙 기반 트래픽 분기 실전 가이드에서 이어서 확인할 수 있습니다. 규칙 설계 문제를 DNS를 계속 바꾸는 방식으로 가리지 마세요.

시스템 프록시가 작동하지 않음: 포트·앱·TUN 확인하기

두 가지 트래픽 연결 방식 구분하기

시스템 프록시는 운영체제 설정을 따르는 앱에 프록시 주소를 알려줄 뿐 모든 네트워크 요청을 자동으로 가로채지는 않습니다. 일부 명령줄 도구, 게임, 자체 네트워크 설정을 사용하는 앱은 이 설정을 읽지 않습니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 대상 트래픽을 전달하므로 일반적으로 더 많은 트래픽을 처리하지만 권한, 라우팅, 제외 항목, 시스템 확장 상태의 영향을 받습니다. 두 기능을 모두 켜도 적용 범위가 단순히 합쳐지는 것은 아닙니다.

브라우저는 정상인데 터미널만 실패한다면 먼저 터미널 프로그램이 시스템 프록시나 환경 변수를 지원하는지 확인하세요. 바로 클라이언트 오류로 판단하지 마세요. 반대로 로컬 프록시를 명시한 명령은 접속되는데 모든 브라우저에서 실패한다면 시스템 프록시가 올바른 네트워크 인터페이스에 설정됐는지, 브라우저 확장 프로그램이 별도 프록시를 지정했는지, 앱이 오래된 설정을 기억하고 있는지 확인하세요. 가장 단순한 경로부터 테스트한 다음 다른 도구를 하나씩 다시 켜세요.

포트 설정과 수신 주소

혼합 포트는 HTTP와 SOCKS 프록시 요청을 모두 받으며, 외부 제어 포트는 관리 인터페이스용입니다. 두 포트는 용도가 다릅니다. 브라우저 프록시 설정에 관리 포트를 입력하면 웹 트래픽이 전달되지 않는 것이 일반적입니다. 설정에 표시된 포트는 설정값일 뿐 실제 수신 여부는 시작 로그에서 확인해야 합니다. 포트가 이미 사용 중이면 코어가 시작되지 않거나 클라이언트에서 포트를 바꾸라는 안내가 표시될 수 있습니다.

이 기기에서 사용할 때 프록시 주소는 보통 127.0.0.1로 설정하며 LAN 연결을 허용할 필요가 없습니다. 아래 설정 조각은 로컬 프록시 포트만 보여주며 실제 노드는 포함하지 않습니다. 설정을 변경한 뒤 다시 불러오고 시스템 프록시에 지정된 포트도 확인하세요. 클라이언트에 별도 포트 설정이 있다면 인터페이스에서 변경하는 편이 좋습니다. 원격 구독을 업데이트한 뒤 이전 값으로 되돌아가는 일을 막을 수 있습니다.

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule

포트 점유와 TUN 라우팅 충돌 확인하기

Windows에서는 다음 명령으로 수신 대기 중인 포트와 프로세스 번호를 확인한 다음 작업 관리자에서 어떤 프로세스인지 살펴볼 수 있습니다. 포트를 사용 중이라는 이유만으로 정체를 모르는 프로세스를 종료하지 마세요. 이전 클라이언트, 남은 코어 프로세스, 다른 프록시 도구를 종료한 뒤 대상 클라이언트를 다시 시작하세요. 포트를 바꾼 뒤에는 브라우저, 터미널 환경 변수, LAN 기기의 주소도 함께 업데이트해야 합니다. 그렇지 않으면 이전 포트로 계속 연결을 시도합니다.

netstat -ano | findstr :7890

TUN을 켠 뒤 전체 네트워크 연결이 끊기면 먼저 TUN을 끄고 시스템 프록시가 작동하는지 확인한 다음, 가상 네트워크 인터페이스를 만들 권한이 있는지 점검하세요. 다른 VPN, 컨테이너 네트워크, 기업 보안 소프트웨어가 비슷한 라우팅 경로를 사용하거나 인터페이스 우선순위를 바꿀 수 있습니다. 기본 경로를 제어하는 도구는 한 번에 하나만 켜고 비교하세요. 시스템 네트워크 인터페이스를 삭제하거나 라우팅을 한꺼번에 초기화해 문제 범위를 넓히지 마세요.

종료 후 복구와 LAN 연결

클라이언트가 비정상 종료되면 시스템이 이미 중지된 로컬 프록시를 계속 가리킬 수 있습니다. 먼저 시스템 수동 프록시를 끄고 브라우저가 직접 연결되는지 확인하세요. 자동 구성 스크립트로 프록시를 설정했다면 해당 경로도 확인해야 합니다. 정상 종료와 프로세스 강제 종료는 설정 정리 방식이 다를 수 있습니다. 복구 후 클라이언트를 켰다가 끄는 과정을 한 번 테스트해 상태에 따라 설정이 제대로 복원되는지 확인하세요.

다른 기기에서 컴퓨터의 프록시를 사용할 때는 휴대전화 자체의 루프백 주소가 아니라 컴퓨터의 LAN 주소를 입력해야 합니다. 실제로 공유할 필요가 있을 때만 LAN 연결을 허용하고 신뢰할 수 있는 네트워크와 필요한 기기로 범위를 제한하세요. 관리 인터페이스를 함께 외부에 공개해서는 안 됩니다. 설정 방법과 방화벽 범위는 혼합 포트 및 LAN 연결 설정을 참고하세요. 이 기기에서만 사용할 경우 시스템 프록시 가이드를 확인하면 됩니다.

클라이언트 충돌: 화면·코어·설정 오류 구분하기

어느 구성 요소가 종료됐는지 확인하기

창 닫기, 트레이 아이콘 사라짐, 코어 중지는 서로 다른 상황입니다. 창을 닫아도 백그라운드에서 실행되는 클라이언트가 있으며, 반대로 화면은 열려 있지만 코어가 종료될 수도 있습니다. 먼저 트레이 아이콘, 시스템 프로세스, 로컬 수신 포트를 확인한 뒤 충돌 여부를 판단하세요. 서비스에 연결할 수 없다는 화면 메시지는 관리 인터페이스 주소가 바뀌었거나 백그라운드 서비스가 시작되지 않았다는 뜻일 수 있습니다. 프로그램 전체가 손상됐다고 단정하지 마세요.

충돌 직전 마지막으로 한 작업을 기록하세요. 설정 가져오기, 구독 업데이트, TUN 켜기, 네트워크 전환, 절전 모드에서 복귀 중 무엇이었는지 확인합니다. 안정적으로 재현되는 조건은 오류 화면 하나보다 문제 파악에 더 도움이 됩니다. 클라이언트 로그와 시스템 앱 오류 기록을 저장하고 두 기록의 오류 시간이 일치하는지 확인하세요. 코어에서 설정 오류가 먼저 발생하고 이후 화면에 연결 끊김이 표시된다면 화면 프로그램을 재설치하기보다 설정을 먼저 수정해야 합니다.

데이터를 보관한 채 설정 범위 좁히기

프로그램을 시작하자마자 종료된다면 먼저 설정 디렉터리와 사용자 지정 재정의 파일을 백업한 뒤 클라이언트에서 제공하는 설정 비활성화 또는 초기화 기능을 사용해 보세요. 데이터 디렉터리는 앱과 운영체제에 따라 다르므로 클라이언트 안내나 로그 위치에서 확인해야 합니다. 이름이 비슷한 사용자 디렉터리 전체를 삭제하지 마세요. 파일을 직접 옮겨야 한다면 클라이언트와 백그라운드 서비스가 완전히 중지된 상태에서 작업하고 복구할 수 있도록 원본 디렉터리를 보관하세요.

화면을 열 수 있다면 최근 추가한 규칙 프로바이더, 스크립트 확장, 복잡한 재정의 설정을 먼저 끄고 하나씩 다시 활성화하세요. 최소 설정으로 줄이는 목적은 어떤 항목이 문제를 일으키는지 확인하기 위한 것이지 구독 인증 정보를 직접 다시 조합하기 위한 것이 아닙니다. 특정 항목을 삭제한 뒤 정상으로 돌아왔다면 현재 코어의 지원 여부, 중복 병합 여부, 연결된 파일 경로의 유효성을 확인하세요. 바로 클라이언트 결함으로 단정하지 마세요.

시스템 호환성·권한·리소스 확인하기

설치 패키지 아키텍처가 기기와 일치해야 합니다. Windows, macOS, Linux 패키지는 파일 이름이 비슷하다는 이유만으로 서로 바꿔 사용할 수 없습니다. Linux에서는 배포판의 패키지 형식과 데스크톱 실행에 필요한 의존성도 확인하세요. 프로그램이 실행되지 않으면 먼저 시스템에 표시된 구체적인 원인을 살펴보세요. 다운로드 페이지에서 플랫폼에 맞는 클라이언트 링크를 사용하고, 일반적인 사용에는 Clash Plus를 우선 고려하세요. 출처가 불분명한 실행 파일로 바꾸지 마세요.

macOS에서는 시스템 설정에서 네트워크 관련 구성 요소를 명시적으로 허용해야 할 수 있고, Windows의 TUN 서비스에는 관리자 권한이 필요할 수 있습니다. 권한 오류는 시스템 안내에 따라 해결하고 시스템 보호 기능을 계속 끄지 마세요. 보안 소프트웨어가 파일을 격리했다면 경고 대상과 원인을 확인하세요. 다운로드 출처와 앱을 확인한 뒤 필요한 조치를 하되, 단일 프로그램의 실행 문제를 우회하려고 디스크나 사용자 디렉터리 전체를 예외 목록에 추가하지 마세요.

장시간 실행한 뒤 충돌한다면 메모리, 연결 수, 디스크 공간도 살펴보세요. 연결이 지나치게 많거나 재시도가 반복되거나 로그가 너무 상세하거나 리소스 업데이트가 멈추지 않으면 자원 사용량이 늘어날 수 있습니다. 불필요한 로그 수준을 낮추고 중복 작업을 중지한 뒤 안정성이 회복되는지 확인하세요. 캐시는 클라이언트가 제공하는 기능으로 정리하세요. 데이터베이스나 설정 캐시를 직접 삭제하기 전에는 코어를 종료해야 합니다. 쓰기 도중 중단되면 파일이 추가로 손상될 수 있습니다.

업데이트·롤백·유효한 기록 준비하기

업데이트한 뒤 문제가 생겼다면 설정 형식 변경, 새 기능 활성화, 기본 DNS 변경이 함께 있었는지 먼저 확인하세요. 현재 데이터를 백업한 뒤 유지보수 중인 클라이언트를 별도 설정으로 테스트하고, 두 프로그램에서 시스템 프록시와 TUN을 동시에 켜지 마세요. 롤백이 필요하면 신뢰할 수 있는 경로에서 기존 설정과 호환되는 설치 파일을 받으세요. 새 형식의 데이터가 이전 버전에서 덮어써지지 않도록 주의해야 합니다.

문제를 신고할 때 운영체제, 기기 아키텍처, 클라이언트 이름, 재현 절차, 민감 정보를 제거한 로그를 첨부하세요. 화면에서 실제 버전을 확인할 수 있다면 함께 제공하되 다운로드 파일 이름만 보고 추측하지 마세요. 로그에는 오류 유형과 발생 단계를 남기고 노드 인증 정보는 삭제해야 합니다. “실패”라는 단어만 남도록 내용을 자르면 원인을 파악할 수 없습니다. 설정 동기화와 백업 방법은 기기 간 설정 동기화 비교를 참고하세요.

복구 여부는 창이 다시 열리는지만으로 판단할 수 없습니다. 코어 시작, 포트 수신, 구독 업데이트, 실제 사이트 접속까지 정상인지 확인한 뒤 이전에 껐던 기능을 다시 활성화하세요. 특정 확장을 복구할 때마다 문제가 재현된다면 해당 확장은 끈 상태로 두고 호환성 요구 사항을 따로 확인하세요. 격리할 수 있는 문제 하나 때문에 클라이언트 데이터를 매번 전부 초기화할 필요는 없습니다.

모바일 문제: VPN 권한·백그라운드 실행·네트워크 전환

시스템 트래픽 처리 상태와 다른 VPN 확인하기

휴대전화에 연결 아이콘이 표시된다는 것은 시스템의 VPN 통로가 어떤 상태로 활성화되어 있다는 뜻일 뿐, 구독 노드, DNS, 대상 서비스가 모두 정상이라는 뜻은 아닙니다. 클라이언트에서 현재 설정, 선택된 정책, 로그를 확인한 다음 같은 웹페이지로 테스트하세요. 다른 VPN, 광고 차단기, 기업 네트워크 앱의 아이콘일 수도 있습니다. 어떤 앱이 실제 통로를 사용 중인지 확인해 Clash가 정상적으로 적용된 것으로 착각하지 않도록 하세요.

Android 클라이언트는 보통 시스템 VPN 인터페이스로 트래픽을 처리하며 처음 연결할 때 사용자 권한이 필요합니다. 같은 인터페이스를 사용하는 다른 앱과 통로를 두고 충돌할 수 있습니다. 일부 기기에는 항상 켜진 VPN이나 VPN을 거치지 않는 연결 차단 설정도 있습니다. 기존 클라이언트가 중지된 뒤 이 제한 때문에 전체 네트워크가 끊길 수 있습니다. 문제를 확인할 때는 시스템 VPN 설정을 점검하고 현재 상태를 기록한 다음 어떤 제한을 임시로 끌지 결정하세요.

Android 백그라운드 중단과 앱별 트래픽 분기 확인하기

화면을 잠근 뒤 연결이 끊기거나 다른 앱으로 전환한 뒤 복구가 느리다면 배터리 최적화나 백그라운드 제한으로 클라이언트가 종료되는지 확인하세요. 시스템에서 제공하는 방식으로 필요한 백그라운드 실행과 알림을 허용한 뒤 개선되는지 살펴보세요. 네트워크 앱 하나를 위해 모든 앱의 백그라운드 권한을 일괄 해제할 필요는 없습니다. 제조사마다 설정 이름이 다르므로 프로세스가 계속 실행되는지, VPN이 다시 연결되는지, 로그에 재시작 기록이 있는지를 기준으로 판단하세요.

앱별 프록시 사용이나 앱 우회를 설정했다면 포함 목록과 제외 목록을 구분하세요. 앱이 프록시를 사용하지 않는다면 규칙 오류가 아니라 분기 설정에서 제외됐기 때문일 수 있습니다. 목록을 수정한 뒤에는 보통 연결을 다시 설정해야 하며 일부 앱은 기존 네트워크 세션을 유지할 수 있습니다. 대상 앱을 완전히 종료한 뒤 다시 연결해 확인하세요. 업무용 프로필, 앱 복제본, 기본 공간은 서로 다른 사용자 환경일 수 있으므로 하나의 목록이 모든 앱 복사본에 적용된다고 가정하지 마세요.

Wi-Fi에서는 정상이고 모바일 데이터에서 실패한다면 클라이언트의 모바일 데이터 권한, 데이터 절약 기능 활성화 여부, 현재 네트워크에서 사용할 수 있는 IPv4 또는 IPv6 경로를 확인하세요. 컴퓨터의 수신 주소와 시스템 프록시 설정을 그대로 적용하지 마세요. 휴대전화 자체의 VPN 연결과 컴퓨터 프록시를 공유받는 방식은 서로 다른 경로입니다. 경로를 비교할 때는 다른 쪽 연결을 먼저 꺼서 트래픽 우회로 인한 혼란을 막으세요.

iOS 네트워크 확장과 연결 복구 확인하기

iOS에서 Clash Plus를 사용할 때는 시스템에서 VPN 구성을 추가하도록 허용했는지, 현재 활성화된 구성이 해당 클라이언트의 것인지 확인하세요. 회사에서 관리하는 네트워크 구성이나 다른 주문형 연결 설정이 함께 있으면 네트워크를 전환할 때 서로 다른 연결이 시작될 수 있습니다. 관리 기기의 프로파일을 임의로 삭제하지 마세요. 먼저 담당 관리 부서에 조정 가능한 범위를 확인한 뒤 연결을 하나씩 테스트하세요.

Wi-Fi에서 모바일 데이터로 전환한 뒤 기존 연결이 끊겼는데 앱이 이전 세션을 유지할 수 있습니다. 먼저 클라이언트 연결을 끊었다가 다시 연결한 다음 대상 앱을 종료하고 다시 실행해 복구되는지 확인하세요. 절전 모드에서 깨어난 뒤에만 문제가 발생한다면 전환 전후의 네트워크 유형, 클라이언트 상태, 오류 시간을 기록하세요. 한 번 다시 연결된 것만으로 노드가 정상이라고 단정하지 마세요. 클라이언트 링크는 iOS 다운로드 안내에서 확인할 수 있습니다.

LAN 공유 프록시와 모바일 기기 자체 프록시 구분하기

휴대전화에서 컴퓨터의 프록시를 공유해 사용하려면 서로 통신할 수 있는 네트워크에 연결하고 컴퓨터의 현재 LAN 주소와 프록시 포트를 입력해야 합니다. 컴퓨터가 절전 모드에 들어가거나 주소가 바뀌거나 게스트 네트워크에서 기기 간 통신을 차단하거나 방화벽이 연결을 막으면 갑자기 접속되지 않을 수 있습니다. 휴대전화의 127.0.0.1은 휴대전화 자신을 가리키며 컴퓨터를 뜻하지 않습니다. 이름이 같은 Wi-Fi라도 기기 간 통신이 허용된다는 보장은 없으므로 네트워크 격리 정책을 먼저 확인하세요.

휴대전화에서 구독을 스캔하거나 복사할 때 전체 구독 링크를 가져왔는지, 웹페이지 공유 주소를 가져온 것은 아닌지 확인하세요. 휴대전화와 컴퓨터의 코어가 지원하는 기능이 다르면 같은 구독이라도 플랫폼에 맞는 형식을 선택해야 할 수 있습니다. 두 설정을 유지하려고 필드를 반복해서 수동으로 삭제하지 마세요. 업데이트 후 사용자 지정 규칙, 앱별 분기, DNS 동작을 각각 확인해 동기화 성공을 모든 플랫폼의 설정이 같아진 것으로 오해하지 않도록 하세요.

모바일 복구 기준에는 화면을 켠 상태에서의 접속, 잠깐 화면을 잠근 뒤의 접속, 네트워크 전환 후 재연결이 모두 포함되어야 합니다. 테스트 중에는 필요한 프록시 기능만 유지하고 안정성이 확인된 뒤 자동 정책과 앱별 분기를 다시 켜세요. 문제가 계속되면 이 페이지의 구독, DNS, 노드 항목을 순서대로 확인하세요. 일반적인 사용 문의는 자주 묻는 질문을, 처음 설정하는 경우에는 설정 가이드 전체 과정을 참고하세요.