Clash 문제 해결 가이드

인터넷에 연결되지 않음: 문제 발생 계층 구분

먼저 일반 인터넷 연결이 정상인지 확인

클라이언트의 시스템 프록시와 TUN을 끄고 앱을 완전히 종료한 뒤, 평소 직접 접속할 수 있는 사이트를 브라우저에서 열어 보세요. 공용 Wi-Fi는 로그인 인증 페이지를 거쳐야 할 수 있습니다. 유선 연결이나 정상적인 Wi-Fi 아이콘만으로 인터넷 접속이 보장되지는 않습니다. 이 상태에서도 연결되지 않으면 라우터, 인증 상태와 다른 기기의 연결을 먼저 점검하세요. 기본 네트워크가 복구되기 전에 노드를 계속 바꾸지 마세요. 매번 같은 근본 원인이 결과에 영향을 줍니다.

클라이언트를 종료한 뒤에도 직접 연결이 되지 않는다면 시스템에 로컬 프록시 주소가 남아 있는지, 다른 VPN이 여전히 라우팅을 제어하는지 확인하세요. 클라이언트를 정상 종료해도 다른 프로그램이 바꾼 설정까지 복구되지는 않을 수 있습니다. 원래 값을 기록한 뒤 더 이상 사용하지 않는 수동 프록시를 해제하세요. 조직에서 관리하는 기기라면 관리자 정책을 따르세요. 네트워크 어댑터를 모두 초기화하면 업무용 네트워크의 고정 주소나 전용 경로까지 삭제될 수 있으므로 피하세요.

로컬 연결 지점과 프록시 출구 확인

클라이언트를 다시 실행하고 설정 하나만 불러온 뒤 TUN은 꺼 둡니다. 코어가 정상적으로 실행됐는지와 혼합 포트의 실제 값을 확인하세요. 아래 명령은 로컬 7890 포트에서 대기 중인 경우를 가정합니다. 화면에 다른 포트가 표시되면 명령도 수정하세요. Windows에서는 일부 터미널이 명령을 다른 도구로 해석할 수 있으므로 curl.exe를 사용하세요. 테스트 주소는 결과를 일관되게 비교하기 위한 것으로, 모든 사이트에 접속할 수 있는지를 보장하지는 않습니다.

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

프록시를 명시한 직후 연결 거부가 발생하면 원격 노드가 아니라 로컬 대기 상태부터 확인하세요. 코어가 시작되지 않았거나 포트가 잘못됐거나 다른 클라이언트가 해당 포트를 사용 중일 수 있습니다. 로컬 포트에는 연결되지만 원격 응답을 기다리다 시간 초과가 발생한다면 요청은 다음 단계까지 진행된 것입니다. 연결 로그에서 대상 주소, 출구 정책과 핸드셰이크 오류를 확인하세요. 두 결과는 서로 다른 계층을 가리키므로 같은 방법으로 해결할 수 없습니다.

변수를 하나씩 바꿔 모드와 규칙 확인

로컬 연결 지점이 정상이라면 규칙 모드에서 테스트 요청에 실제로 적용된 규칙을 확인하세요. 잠깐 비교할 때는 전역 모드를 사용해 알려진 출구 하나를 선택하고 테스트 주소는 그대로 유지할 수 있습니다. 전역 모드에서는 성공하고 규칙 모드에서는 실패한다면 구독을 계속 수정하지 말고 규칙 순서, 정책 그룹 선택과 직접 연결 출구를 확인하세요. 전역 모드로 문제가 있는 노드를 고칠 수는 없습니다. 테스트가 끝나면 기존 모드로 되돌리세요.

정책 그룹에 이름이 표시된다고 해서 사용 가능한 구성원이 선택된 것은 아닙니다. 그룹이 실제로 존재하는 노드나 제공자를 참조하는지 확인하세요. 특히 구독 업데이트 뒤 이름이 바뀌어 참조가 끊겼는지 살펴보세요. 규칙은 위에서 아래 순서로 적용됩니다. 앞쪽의 포괄적인 직접 연결 규칙이 요청을 먼저 가로챌 수 있으며, 마지막 기본 규칙도 실제 정책을 가리켜야 합니다. 규칙 전체를 한꺼번에 교체하지 말고 연결 기록으로 적용 항목을 확인한 뒤 필요한 부분만 수정하세요.

복구한 뒤 브라우저, 새로 연 터미널과 원래 문제가 발생한 앱을 각각 테스트하세요. 브라우저만 성공한다면 프록시 연결 방식도 확인해야 합니다. 도메인 요청만 실패한다면 DNS 항목을 살펴보세요. 여전히 결과가 일정하지 않다면 절전 모드에서 복귀한 직후인지, 네트워크를 막 전환했는지, 다른 네트워크 도구가 실행 중인지 기록하세요. 이런 조건을 남기면 막연히 ‘켜져 있는데 안 된다’고 설명하는 것보다 원인을 찾기 쉽습니다.

노드 시간 초과: 전송과 핸드셰이크 확인

속도 테스트 실패와 실제 서비스 연결 실패 구분

클라이언트의 지연 시간 테스트는 보통 지정된 주소에 요청을 보내므로 해당 테스트 경로만 보여 줍니다. 테스트 주소가 차단되거나 리디렉션되거나 일시적으로 응답하지 않으면 노드가 시간 초과로 표시되어도 일반 사이트는 열릴 수 있습니다. 반대로 테스트에 성공해도 가벼운 요청 하나가 완료됐다는 뜻일 뿐, 동영상 전송이나 업로드, 장시간 연결이 안정적이라는 보장은 없습니다. 먼저 실제 문제가 발생한 앱으로 다시 테스트한 다음 노드를 사용할 수 없는 것으로 판단하세요.

같은 네트워크에서 여러 노드를 비교한 뒤, 같은 노드를 신뢰할 수 있는 다른 네트워크에서도 테스트하세요. 한 노드만 실패하면 해당 노드의 서비스 상태와 설정값을 우선 확인하세요. 현재 네트워크에서 모든 노드가 실패하고 네트워크를 바꾸면 성공한다면 접속 네트워크의 제한이나 라우팅 문제일 가능성이 큽니다. 테스트 중에는 클라이언트 모드와 설정을 그대로 유지해야 네트워크와 설정 중 무엇이 차이를 만들었는지 판단할 수 있습니다.

연결 단계별로 로그 확인

클라이언트 로그 화면을 열고 잠시 로그 수준을 높인 뒤 요청을 한 번 보내고 관련 행을 바로 기록하세요. 파싱 오류는 서버 주소를 가져오기 전 발생합니다. 연결 시간 초과는 보통 전송 연결을 맺는 동안 발생하고, 핸드셰이크 실패는 프로토콜 협상 단계까지 진행됐다는 뜻입니다. 원격 연결 종료, 인증 실패와 인증서 오류를 모두 네트워크 속도 문제로 해석해서는 안 됩니다. 가장 먼저 발생한 오류를 확인하세요. 그 뒤에 이어지는 오류는 처음 실패의 연쇄 반응일 수 있습니다.

TLS 연결에서는 먼저 시스템 날짜와 시간대, 자동 시간 설정이 정상인지 확인하세요. 다음으로 서버 측 설정과 서버 이름, 전송 유형, 경로 등의 값이 일치하는지 살펴보세요. 서버 주소와 인증서 검증에 쓰이는 이름은 서로 다를 수 있으므로 추측으로 바꾸지 마세요. 인증서 오류를 해결한다며 인증서 검증을 건너뛰는 설정을 일반적인 해결책으로 사용해서는 안 됩니다. 설정 오류를 숨기고 연결 상대의 신원 확인을 약화할 수 있습니다.

프로토콜 지원과 테스트 조건 확인

일부 전송 방식은 UDP에 의존하며, 현재 네트워크가 일반 웹 연결은 허용하면서 UDP를 제한할 수 있습니다. 이 경우 로컬 포트만 바꾸지 말고 서비스에서 제공하는 다른 전송 옵션으로 비교하세요. 그렇다고 모든 UDP 앱이 사용할 수 없다고 단정해서는 안 됩니다. 노드 프로토콜의 기반 전송과 프록시를 사용하는 앱의 전송은 별개이므로 지원 여부와 규칙을 각각 확인해야 합니다.

오래된 코어는 구독에 포함된 새 프로토콜 필드를 인식하지 못할 수 있습니다. 로그에 해당 유형을 지원하지 않는다는 내용이 명확히 표시되면 클라이언트가 실제로 사용하는 코어를 확인한 뒤 호환 클라이언트나 구독 형식을 선택하세요. 다운로드 페이지에서 Clash Plus를 먼저 확인하거나 운영체제에 맞는 유지 관리 중인 다른 클라이언트를 선택할 수 있습니다. 코어와 필드 차이는 원본·Meta·mihomo 코어 비교를 참고하세요. 설정 파일 확장자만으로 호환성을 판단하지 마세요.

짧은 시간에 병렬 테스트를 많이 실행하면 로컬 네트워크와 원격 서비스에 부하가 커져 시간 초과가 더 발생할 수 있습니다. 자동 테스트를 멈추고 노드 하나를 고정한 다음 이전 연결이 끝날 때까지 기다렸다가 몇 차례만 요청하세요. 서비스 제공자에게 문의할 때는 민감 정보를 가린 오류 단계, 접속 네트워크 유형과 재현 시각을 전달하고 인증 정보는 공개하지 마세요. 복구 후에는 가벼운 요청과 지속 연결을 모두 확인해 테스트 주소만 다시 응답하는 상태가 아닌지 살펴보세요.

구독 업데이트 오류: 다운로드와 파싱 구분

설정을 실제로 가져왔는지 확인

구독 업데이트 오류는 크게 두 단계에서 발생합니다. 주소에서 콘텐츠를 가져오지 못했거나, 가져온 콘텐츠를 현재 클라이언트가 읽지 못한 경우입니다. 업데이트 안내와 로그를 확인해 DNS 조회, 연결 시간 초과, 접근 거부 중 무엇인지, 아니면 설정 파싱 오류인지 구분하세요. 구독 목록에 예전 노드가 계속 보여도 업데이트가 성공했다는 뜻은 아닙니다. 많은 클라이언트가 마지막으로 사용 가능한 캐시를 유지하므로 화면에서 계속 사용할 수 있는 것과 원격 업데이트 성공은 별개입니다.

서비스 관리 페이지에서 구독 주소 전체를 다시 복사하고 공백, 줄바꿈 또는 메신저가 덧붙인 문장부호가 들어갔는지 확인하세요. 주소의 쿼리 매개변수는 인증에 쓰일 수 있으므로 임의로 지우면 요청이 실패할 수 있습니다. 시스템 클립보드의 내용은 다른 앱에서 읽을 수도 있습니다. 주소를 확인한다며 출처를 알 수 없는 변환 사이트에 보내지 마세요. 링크가 공개됐다면 서비스의 관리 기능에서 구독 인증 정보를 교체하세요.

접근 거부가 항상 클라이언트 문제인 것은 아닙니다. 구독 만료, 트래픽 조건, 요청 빈도 제한이나 서버 정책 때문일 수도 있습니다. 주소를 열었을 때 로그인 화면, 오류 안내 또는 웹 인증 페이지가 표시되면 페이지를 가져오는 데는 성공했지만 설정을 가져온 것은 아닙니다. 확인할 때는 응답 유형과 오류 내용만 살펴보면 되며 전체 응답을 공유할 필요는 없습니다. 일시적으로 요청이 제한됐다면 업데이트를 계속 누르지 말고 서비스 안내에 따라 기다리거나 계정 상태를 확인하세요.

설정 유형과 업데이트 경로 확인

전체 설정, 노드 목록과 규칙 모음은 서로 다른 콘텐츠입니다. 전체 설정에는 포트, 정책 그룹과 규칙이 포함될 수 있습니다. 프록시 제공자에는 보통 노드 데이터만, 규칙 제공자에는 지정된 동작 유형의 규칙만 넣어야 합니다. 노드 목록을 전체 설정으로 가져오면 규칙과 정책 그룹이 빠질 수 있고, 전체 설정을 규칙 모음 주소로 넣으면 구조 오류가 발생합니다. 서비스에서 제공하는 항목의 유형을 확인한 다음 클라이언트에서 해당 기능을 선택하세요.

구독을 내려받을 때도 네트워크 연결이 필요합니다. 일부 설정은 업데이트 요청을 프록시로 보내지만 사용할 수 있는 노드가 이번 업데이트에 의존해 순환 의존성이 생길 수 있습니다. 클라이언트가 지원하는 직접 연결 업데이트를 임시로 사용하거나 이미 검증된 다른 출구로 전환할 수 있습니다. 단, 해당 구독 주소에 그 방식의 접속이 허용되어야 합니다. 이 문제를 해결하려고 인증 정보가 포함된 주소를 제삼자에게 대신 가져오도록 넘기지 마세요.

파싱 오류와 로컬 덮어쓰기

YAML 오류가 발생하면 먼저 오류 근처의 들여쓰기, 콜론과 목록 기호를 확인하세요. 들여쓰기는 공백을 사용하고 탭은 피하세요. 특수 문자가 포함된 문자열은 문법에 맞게 따옴표로 묶어야 합니다. 오류 행 번호는 파싱을 더 진행하지 못한 위치를 가리킬 수 있으므로 바로 앞 행도 점검하세요. 로드에 성공하게 만들려고 오류가 난 필드를 바로 삭제하지 마세요. 해당 필드에 인증, 전송이나 정책 관계가 들어 있다면 파싱 오류가 실행 오류로 바뀔 뿐입니다.

mode: rule
log-level: info
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

이 예시는 목록 계층과 규칙 작성법을 확인하기 위한 것으로 프록시 출구가 포함되지 않아 전체 구독을 대체할 수 없습니다. 기존 설정의 정책 그룹 이름이 다른 경우 규칙에도 공백과 대소문자까지 완전히 같은 이름을 사용해야 합니다. 파싱이 통과한 뒤에도 정책이 없다는 메시지가 표시되면 규칙, 정책 그룹, 노드나 제공자 순서로 참조를 확인하세요. 원격 업데이트에서 이전 이름이 삭제됐는지도 살펴보세요.

수정하기 전에 현재 설정을 백업한 뒤 별도 사본에 새 구독을 가져오세요. 노드, 정책 그룹과 규칙이 모두 있는지 확인한 다음 전환하고, 기존 캐시와 설정을 동시에 삭제하지 마세요. 자동 업데이트만 실패하고 수동 업데이트는 성공한다면 예약 작업이 절전, 백그라운드 제한 또는 시작 시점의 네트워크 미연결 영향을 받는지 확인하세요. 기본 개념은 자주 묻는 질문을 참고하세요. 작업 순서는 설정 가이드에서 확인할 수 있으며, 이 장에서는 오류 상황과 복구 근거를 다룹니다.

속도 저하: DNS 조회와 전송 구분

어느 단계에서 느린지 먼저 기록

페이지가 오랫동안 비어 있거나 전송이 시작된 뒤 속도가 낮거나 재생 중 주기적으로 멈추는 현상은 각각 DNS 조회, 연결 설정, 전송량 또는 연결 안정성 문제일 수 있습니다. 버튼을 누른 뒤 첫 응답이 오기까지 걸린 시간과 전송 시작 후에도 계속 느려지는지를 기록하세요. 지연 시간 표시 하나만으로 판단하지 마세요. 가벼운 테스트는 전송 데이터가 적으므로 결과 시간이 짧다고 대용량 다운로드도 빠른 것은 아닙니다. 반대로 왕복 시간이 길어도 지속 전송 속도가 반드시 제한되는 것은 아닙니다.

같은 대상을 비슷한 시간대에 같은 기기로 테스트하고 다른 다운로드, 클라우드 동기화와 시스템 업데이트는 먼저 중지하세요. Wi-Fi 신호가 약하거나 기기가 액세스 포인트를 전환하거나 라우터 부하가 크면 직접 연결과 프록시가 모두 느려질 수 있습니다. 유선 연결이나 액세스 포인트 가까운 위치에서 비교할 수 있지만, 한 번의 비교에서 기기, 네트워크, 대상 사이트와 노드를 동시에 바꾸지 마세요. 변수가 너무 많으면 속도가 개선돼도 재현 가능한 결론을 내리기 어렵습니다.

실제 출구와 연결 재사용 여부 확인

연결 화면에서 대상 도메인, 적용된 규칙과 실제 출구를 확인하세요. ‘자동 선택’이라는 이름의 정책 그룹도 실제 연결이 예상한 구성원을 사용한다는 보장은 없습니다. 테스트 주소와 실제 서비스 요청의 경로도 다를 수 있습니다. 정책을 전환해도 기존 장시간 연결은 이전 출구를 계속 사용할 수 있으며 브라우저 연결 풀과 앱 세션이 바로 새로 만들어지는 것은 아닙니다. 테스트 세션을 종료하거나 자연스럽게 끝날 때까지 기다린 뒤 새로 비교하세요. 기존 연결로 전환 적용 여부를 판단하지 마세요.

자동 선택과 장애 조치는 서로 다른 문제를 해결합니다. 자동 선택은 보통 테스트 결과에 따라 구성원을 고르고, 장애 조치는 사용 가능 여부에 더 중점을 둡니다. 어느 쪽도 모든 대상에서 가장 빠른 전송을 보장하지 않습니다. 검사 간격이 너무 짧으면 테스트 요청이 잦아질 수 있습니다. 재생 중 끊기는 문제라면 먼저 안정적인 출구 하나를 고정해 관찰한 뒤 자동 정책을 다시 사용할지 결정하세요. 계속 전환하면 연결 유지가 중요한 서비스에 변수가 더해집니다.

대상별 차이와 프로토콜 제한 확인

특정 사이트만 느리다면 같은 노드로 다른 사이트도 비교하고 대상이 콘텐츠 전송 네트워크를 사용하는지 확인하세요. 출구에 따라 서로 다른 캐시 위치가 선택될 수 있으며 개별 원본 서버가 속도를 제한할 수도 있습니다. 이 경우 DNS를 전역 변경해도 효과가 없을 수 있습니다. DNS 조회가 프록시 측에서 수행되거나 연결이 기존 주소를 재사용할 수 있기 때문입니다. 먼저 도메인을 어느 쪽에서 조회하는지, 모든 요청이 느린지 특정 대용량 리소스만 느린지 확인한 뒤 조치 위치를 정하세요.

일부 앱은 UDP 기반 전송을 시도하며 경로가 불안정하면 실패한 뒤 다른 방식으로 전환할 수 있습니다. 클라이언트, 노드와 접속 네트워크가 모두 이 경로에 영향을 줄 수 있습니다. 앱에서 공식적으로 제공하는 설정으로 제한된 범위에서 비교할 수 있지만, 특정 프로토콜을 비활성화한 상태를 기기 전체의 기본 설정으로 확대하지 마세요. 문제가 해결되면 원래 설정과 변경 사항을 기록하고 장기적인 호환성에 영향이 없는지 확인하세요.

TUN 환경에서 작은 요청은 성공하지만 큰 응답이 멈추는 경우에만 경로 MTU나 패킷 분할 문제를 추가로 의심하세요. 먼저 Wi-Fi 패킷 손실과 원격 속도 제한을 배제한 뒤 클라이언트가 지원하는 매개변수 하나씩 테스트하세요. MTU를 임의로 매우 낮추면 캡슐화와 처리 부담이 커지고 실제 라우팅 문제를 가릴 수도 있습니다. 기본값을 기록하고 값을 바꿀 때마다 연결을 다시 설정하세요. 개선이 재현되지 않으면 출처를 알 수 없는 값을 유지하지 말고 원래대로 되돌리세요.

기기 자원과 테스트 조건 확인

전송 중 프로세서, 메모리와 디스크 사용량을 확인하세요. 코어의 프로세서 사용률이 계속 높고 다른 네트워크 프로그램도 자원을 사용한다면 동시 연결을 줄이고 불필요한 디버그 로그를 끈 뒤 결과를 비교하세요. 규칙이 많다는 사실만으로 속도 저하를 설명할 수는 없습니다. 실제 코어, 규칙 동작과 기기 자원을 함께 살펴보세요. 보안 소프트웨어의 네트워크 검사도 부담을 더할 수 있지만 속도 테스트를 위해 기기 보호를 계속 끄는 것은 권장하지 않습니다.

원인을 파악한 뒤 효과가 확인된 변경만 남기세요. 특정 노드의 용량이나 원격 사이트 문제라면 로컬 설정으로 해결을 보장할 수 없습니다. 서비스에서 제공하는 다른 출구를 선택하거나 원격 복구를 기다리세요. 절전 모드에서 깨어난 뒤에만 느려진다면 성능 매개변수를 계속 추가하기보다 네트워크 인터페이스와 라우팅 복구를 먼저 확인하세요. 가상 네트워크 어댑터가 트래픽을 처리하는 원리는 TUN 모드 설정 안내를 참고하세요.

DNS 문제: 조회 경로 추적

어느 구성 요소가 DNS 조회를 수행하는지 확인

DNS 문제는 도메인이 열리지 않는 형태로 나타나지만, 모든 도메인 오류가 같은 확인자에서 비롯되는 것은 아닙니다. 브라우저가 별도의 암호화 DNS를 사용할 수 있고 운영체제에는 자체 캐시가 있으며 클라이언트 코어도 프록시 측 조회를 처리할 수 있습니다. 먼저 문제가 발생한 앱이 어떤 경로를 사용하는지 확인한 뒤 해당 로그를 살펴보세요. 시스템 조회 명령이 정상이라고 해서 그 명령에 사용된 경로가 작동한다는 것만 확인할 수 있습니다. 브라우저나 프록시 측에서 같은 주소를 얻었다는 뜻은 아닙니다.

아무 사이트의 IP 주소에 직접 접속하는 것만으로 판단하지 마세요. HTTPS는 인증서 확인과 서비스 선택에 도메인을 사용하는 경우가 많아 주소로 직접 접속하면 DNS가 정상이어도 거부될 수 있습니다. 클라이언트 로그, 시스템 조회 결과와 같은 도메인에 대한 요청 결과를 함께 확인하세요. 로그에 로컬 대기 실패나 원격 인증 오류가 이미 표시됐다면 DNS 캐시를 계속 지워도 도움이 되지 않습니다.

Fake-IP와 실제 주소 모드 이해

Fake-IP 모드에서는 앱에 가상 주소를 반환한 뒤 코어가 매핑을 통해 도메인을 찾아 라우팅합니다. 따라서 시스템 조회에서 가상 주소가 표시되는 것은 예상된 동작이며 잘못된 DNS 응답을 뜻하지 않습니다. 핵심은 이후 연결도 같은 코어로 들어가야 한다는 점입니다. 조회 요청은 클라이언트를 거치지만 연결이 클라이언트를 우회하면 앱이 가상 주소로 직접 접속하려 할 수 있습니다. 가상 주소를 공인 IP로 바로 바꾸기보다 먼저 트래픽이 빠짐없이 전달되는지 확인하세요.

일부 로컬 네트워크 서비스, 기기 검색이나 특수 앱은 가상 주소와 잘 맞지 않을 수 있습니다. 실제로 문제가 생긴 도메인만 필터링하되, 모든 도메인을 필터 목록에 넣으면 모드의 주요 동작이 달라지므로 피하세요. 필터 문법과 추가 모드는 코어마다 다를 수 있으니 호환성을 먼저 확인하세요. 원리와 적용 범위는 Fake-IP와 redir-host 비교를 참고하세요.

상위 DNS와 초기 조회 의존성 확인

아래는 mihomo 호환 설정을 위한 DNS 예시이며 전체 프록시 설정은 아닙니다. 공용 DNS를 사용해 초기 조회, 암호화 조회와 지정 도메인 정책의 계층을 보여 줍니다. 실제 네트워크 접근성과 필요에 따라 DNS 서버를 선택하세요. 이 예시에는 대기 주소가 지정되어 있지 않으며 운영체제의 DNS도 자동으로 바꾸지 않습니다. 클라이언트가 트래픽을 넘겨받아야 앱 요청이 이 설정에 도달합니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost"
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://cloudflare-dns.com/dns-query
  nameserver-policy:
    "example.com":
      - https://dns.google/dns-query

도메인 형식의 암호화 DNS를 사용하면 코어가 먼저 DNS 서버 자체의 주소를 알아내야 합니다. 이것이 초기 조회 의존성의 일부입니다. 초기 조회가 되지 않으면 이후 암호화 요청도 시작할 수 없습니다. 노드 서버가 도메인 주소를 사용하는 경우에도 안정적인 조회 경로가 필요합니다. 노드 주소를 알아내는 유일한 방법이 아직 연결되지 않은 프록시에 의존하게 하지 마세요. 순환 의존성이 의심되면 노드 도메인 조회와 프록시 측 조회에 대한 클라이언트의 별도 설정을 확인하세요.

nameserver-policy는 지정 도메인에 사용할 DNS 서버를 선택하는 설정으로, 연결 분류 규칙이나 출구 정책을 대신하지 않습니다. fallback과 필터 조건의 동작은 코어 문서를 기준으로 이해해야 하며, 기본 DNS 서버 실패 후에만 시작되는 예비 목록으로 단순하게 해석해서는 안 됩니다. DNS 서버를 더 추가하면 조회 정보가 전달되는 범위가 커질 수 있고, 정확성이나 개인정보 보호가 자동으로 향상되지는 않습니다. 먼저 최소한의 서버 구성으로 안정성을 확인한 뒤 실제로 필요한 예외만 추가하세요.

순서대로 캐시 정리와 검증

설정을 수정한 뒤 코어를 다시 불러오고 테스트 앱의 기존 세션을 종료하세요. 필요한 경우 시스템 DNS 캐시도 비울 수 있습니다. 기존 가상 주소 연결이 남아 있는데 코어의 매핑만 지우면 주소와 도메인 연결이 일시적으로 끊길 수 있습니다. 사내 도메인에는 내부 DNS가 필요합니다. 공용 DNS로 바꾸면 해결되지 않을 뿐 아니라 기존에 접속할 수 있던 업무 서비스가 작동하지 않을 수 있습니다.

검증할 때는 공용 도메인, 로컬 네트워크 이름과 원래 문제가 발생한 앱을 각각 확인하세요. 개인정보 검사 페이지에 특정 DNS 사업자가 표시되는 것은 단서일 뿐 모든 조회 경로를 증명하지는 않습니다. 브라우저 설정, 시스템 인터페이스와 코어 로그를 함께 확인하세요. 추가 검사 방법은 DNS 누출 검사와 방지 설정을 참고하고, 단일 검사 결과로 전체 경로 분석을 대신하지 마세요.

프록시 문제: 트래픽 전달 범위 확인

시스템 프록시와 TUN 구분

시스템 프록시는 시스템 설정을 따르는 앱에 프록시 연결 지점을 제공할 뿐 모든 프로그램의 트래픽을 자동으로 가져오지는 않습니다. 일부 터미널 도구, 게임과 백그라운드 서비스는 자체 네트워크 설정을 사용해 시스템 프록시를 무시할 수 있으며 이는 정상 동작일 수 있습니다. TUN은 가상 네트워크 어댑터와 라우팅을 통해 트래픽을 전달하지만 인터페이스, 권한과 제외 규칙의 영향을 받습니다. 스위치가 켜져 있어도 클라이언트가 설정 적용을 시도했다는 뜻일 뿐 대상 요청이 코어를 거쳤다는 보장은 없습니다.

먼저 TUN을 끈 상태에서 시스템 프록시를 테스트하세요. 브라우저에서 새 세션을 열고 연결 화면에 대상 요청 기록이 남는지 확인하세요. 이어서 프록시를 명시하는 명령으로 비교합니다. 명령은 성공하지만 브라우저가 실패하면 브라우저 프록시 확장, 앱 자체 프록시와 우회 목록을 확인하세요. 명령도 로컬 연결 지점에 연결하지 못한다면 대기 설정 점검으로 돌아가세요. 앱 설정을 계속 바꾸지 마세요.

포트, 환경 변수와 플랫폼 설정 확인

mixed-port는 HTTP와 SOCKS가 함께 사용하는 연결 지점이며 앱은 지원하는 프록시 프로토콜을 사용해야 합니다. 설정의 컨트롤 인터페이스는 프록시 포트가 아니므로 브라우저에 컨트롤 포트를 입력해도 웹 요청이 전달되지 않습니다. 대기 주소가 로컬 기기만 허용하면 휴대전화나 다른 기기에서 직접 연결할 수도 없습니다. 대기 범위를 로컬 네트워크로 넓히는 것은 별도의 보안 결정입니다. 테스트를 위해 모든 인터페이스를 기본적으로 열지 말고 인증과 방화벽도 함께 고려하세요.

터미널 도구는 프록시 환경 변수를 읽는 경우가 많지만 이미 실행 중인 프로세스는 새 값을 자동으로 받지 않습니다. 아래 명령은 현재 환경을 확인할 뿐 시스템 설정을 바꾸지 않습니다. 대문자와 소문자 변수, 우회 목록이 함께 설정되어 있는지도 살펴보세요. 도구마다 우선순위가 다를 수 있습니다. 기존 변수를 정리한 뒤에는 터미널을 새로 열어 다시 테스트하세요. 다른 창에서 설정을 바꿔도 기존 프로세스에 반영됐다고 볼 수 없습니다.

# macOS / Linux: 현재 프로세스가 상속한 프록시 변수 확인
env | grep -i proxy

# Windows PowerShell: 프록시 관련 환경 변수 확인
Get-ChildItem Env: | Where-Object Name -Match 'proxy'

TUN은 별도의 단계로 테스트

시스템 프록시 경로가 안정적으로 작동한 뒤 TUN을 켜고, 클라이언트에 필요한 서비스 설치와 권한이 완료됐는지 확인하세요. 권한을 얻기 위해 데스크톱 앱 전체를 장기간 높은 권한으로 실행하지 말고 클라이언트가 제공하는 서비스 방식을 우선 사용하세요. 가상 네트워크 어댑터가 나타나도 라우팅 적용을 보장하지는 않습니다. 대상 연결이 코어로 들어가는지와 현재 기본 네트워크 인터페이스를 올바르게 인식하는지 확인하세요.

여러 VPN, 가상 머신 네트워크나 다른 TUN 도구를 동시에 사용하면 라우팅이 겹칠 수 있습니다. 꼭 필요하지 않은 트래픽 전달 도구를 끄고 클라이언트 하나만 테스트하세요. 절전 모드에서 복귀하거나 네트워크를 바꾼 뒤에는 기존 인터페이스와 경로가 작동하지 않을 수 있습니다. 이때 TUN을 껐다 켜 클라이언트가 네트워크를 다시 검색하게 할 수 있습니다. 알 수 없는 시스템 경로를 바로 삭제하지 마세요. 업무용 VPN이나 가상 머신이 해당 경로를 사용할 수 있습니다.

로컬 네트워크 기기에 접속할 수 없다면 모든 트래픽을 직접 연결로 바꾸기보다 사설 주소의 라우팅과 우회 규칙을 확인하세요. 프린터, 네트워크 저장 장치와 사내 서비스는 각각 다른 검색 방식이 필요할 수 있습니다. 원격으로 현재 기기를 제어하는 중이라면 라우팅을 바꾸기 전에 복구 방법을 마련해 연결이 끊기지 않도록 하세요. 설정의 의미는 가상 네트워크 어댑터의 트래픽 전달 안내를 참고하세요.

최종 검증은 브라우저뿐 아니라 원래 실패한 프로그램에서도 진행하세요. 해당 프로그램이 시스템 프록시, 앱 자체 프록시 또는 TUN 중 무엇을 사용하는지 기록하고 클라이언트를 종료한 뒤에도 시스템 연결이 예상대로 복구되는지 확인하세요. 시스템 프록시를 따르지 않는 앱은 공식적으로 지원하는 연결 방식을 사용해야 합니다. 스위치가 작동하지 않는다고 해서 클라이언트 충돌로 단정하지 마세요. 트래픽 전달 범위가 명확해야 이후 규칙 적용과 DNS 진단도 정확하게 할 수 있습니다.

클라이언트 충돌: 복구 방법 보존

화면 종료와 코어 종료 구분

창이 사라졌거나 트레이 아이콘이 남아 있거나 프록시가 갑자기 멈추는 현상은 서로 다른 프로세스에서 비롯될 수 있습니다. 일부 클라이언트는 화면과 코어가 별도로 실행되므로 화면을 다시 시작해도 이전 코어가 종료되지 않을 수 있습니다. 코어가 충돌해도 화면에는 실행 중이 아니라고만 표시될 수 있습니다. 클라이언트 상태 화면과 시스템 프로세스 도구로 실제 상태를 확인한 뒤 최근 로그를 저장하세요. 클라이언트를 여러 개 연속 실행하면 남아 있는 프로세스가 포트를 점유해 처음 발생한 충돌 단서를 덮을 수 있습니다.

클라이언트를 종료한 뒤에도 시스템이 로컬 프록시를 가리키는데 해당 연결 지점이 사라졌다면 모든 웹페이지가 열리지 않을 수 있습니다. 먼저 시스템 프록시 항목에 따라 네트워크를 복구한 뒤 프로그램을 점검하세요. 설정을 저장하기 전에 데이터 폴더 전체를 지우지 마세요. 로컬 덮어쓰기, 정책 선택과 구독 기록이 들어 있을 수 있습니다. 백업은 관리되는 안전한 위치에 보관하고 공개 저장소와 동기화하거나 문의 첨부 파일로 바로 올리지 마세요.

아키텍처, 권한과 시작 오류 확인

설치 파일은 운영체제와 프로세서 아키텍처에 맞아야 합니다. 파일을 내려받았다고 현재 시스템에서 실행할 수 있다는 뜻은 아닙니다. 설치 프로그램 거부, 실행 형식 오류와 실행 후 충돌을 구분해 점검하세요. 클라이언트를 다시 선택할 때는 클라이언트 목록에서 Clash Plus를 우선 확인하고 시스템 요구 사항도 살펴보세요. Clash for Windows와 ClashX Meta는 유지 관리가 중단된 선택지이므로 최신 시스템 호환 문제의 기본 해결책으로 권장하지 않습니다.

로그에 주소 사용 중이라고 표시되면 다른 코어가 실행 중인지, 다른 서비스가 같은 포트를 사용하는지 확인하세요. 이전 클라이언트에 속한 것이 확실한 프로세스는 종료하거나 로컬 대기 포트를 바꾸고 앱 설정도 함께 수정할 수 있습니다. 용도를 알 수 없는 시스템 프로세스는 종료하지 마세요. 권한 부족 오류가 발생하면 데이터 폴더에 쓰기 권한이 있는지, 다른 계정이 파일을 만들었는지, 보안 소프트웨어가 필요한 구성 요소를 격리했는지 확인하세요. 원인을 우회하려고 보호 기능을 모두 끄지 마세요.

설정 사본으로 문제 범위 분리

먼저 백업한 뒤 클라이언트가 지원하는 새 설정이나 별도 데이터 폴더로 최소 설정을 실행하세요. 새 환경은 안정적인데 기존 설정에서 바로 코어가 종료된다면 새로 추가한 제공자, 규칙 모음, 스크립트 지원과 필드 호환성을 집중적으로 확인하세요. 설정 문법을 통과했다고 외부 리소스를 모두 가져올 수 있거나 현재 코어가 모든 동작을 지원한다는 뜻은 아닙니다. 한꺼번에 전체 내용을 붙여 넣는 것보다 부분별로 복원하는 편이 문제를 일으킨 항목을 찾기 쉽습니다.

업데이트 뒤 문제가 생겼다면 화면과 코어가 각각 변경됐는지 기록하세요. 출처가 다른 코어 파일을 설치 폴더에 바로 덮어쓰지 마세요. 클라이언트가 시작 매개변수와 인터페이스를 특정 방식으로 사용할 수 있습니다. 공식 코어 관리 및 복구 기능을 우선 이용하세요. 이전 환경으로 복구하는 방법은 확인이나 임시 되돌리기에만 사용하고, 확인된 호환성 또는 보안 업데이트를 계속 무시하는 이유로 삼지 마세요.

화면만 흰색이고 코어가 계속 트래픽을 전달하는 경우에만 그래픽 렌더링과 화면 캐시를 추가로 확인하세요. 먼저 프로그램에 공식 그래픽 가속 설정이 있는지 확인한 뒤 하나씩 비교하세요. 화면 캐시를 지우기 전에 캐시와 사용자 데이터를 구분하세요. 인터넷의 포괄적인 경로 안내만 보고 폴더 전체를 삭제하지 마세요. 프로그램이 실행되지 않으면 열리지 않는 설정 화면에서 작업을 요구하기보다 시스템 로그나 클라이언트 로그 폴더에서 정보를 먼저 확보하세요.

자원 사용량 관찰과 재현 가능한 보고서 작성

메모리가 계속 늘거나 구독 새로고침 중 종료되거나 장시간 실행 후 충돌한다면 발생 조건을 기록하세요. 불필요한 자동 업데이트와 잦은 테스트를 멈추고 외부 리소스 범위를 줄인 뒤 재현 여부를 확인하세요. 디스크 공간 부족도 데이터베이스 쓰기와 로그 생성을 방해할 수 있습니다. 기본 여유 공간은 확보하되 전체 여유 공간뿐 아니라 클라이언트 데이터가 저장된 실제 파티션과 계정 할당량도 확인하세요.

복구한 뒤 백업 설정을 다시 불러와 정책 선택, 덮어쓰기와 업데이트 작업이 유지됐는지 확인하고 정상 종료와 재실행도 테스트하세요. 특정 설정에서만 문제가 생기면 오류를 일으키는 최소 부분까지 단계별로 복원할 수 있습니다. 최소 환경에서도 종료된다면 시스템 호환성, 실행 의존성이나 프로그램 결함을 계속 살펴보세요. 재설치는 복구 방법 중 하나일 뿐 모든 충돌의 원인을 설명해 주지는 않습니다.

모바일 문제: 백그라운드 실행과 네트워크 전환

Android: VPN 권한과 백그라운드 제한 확인

Android 클라이언트는 보통 시스템 VPN 인터페이스를 통해 트래픽을 전달합니다. 처음 연결할 때 명시적인 권한 승인이 필요합니다. 화면의 버튼이 켜져 있다는 것만으로 터널이 연결됐다고 볼 수 없으므로 시스템 VPN 상태와 클라이언트 연결 기록을 함께 확인하세요. 업무 프로필, 조직의 관리 정책이나 다른 VPN 앱이 같은 기능을 사용 중일 수 있습니다. 현재 어떤 서비스가 실제로 작동하는지 확인하고 두 도구가 트래픽 제어를 두고 반복해서 충돌하지 않도록 하세요.

Android 다운로드 페이지에서 Clash Plus를 먼저 확인하거나 호환성에 따라 Clash Meta for Android, FlClash 또는 Surfboard를 선택할 수 있습니다. 클라이언트마다 지원하는 설정 형식과 기능 범위가 다르므로 전체 Clash 설정 하나가 모든 앱에서 공통으로 사용된다고 볼 수 없습니다. 앱을 바꾸기 전에 필요한 설정을 내보내고 구독 서비스에서 해당 형식을 제공하는지 확인하세요.

화면을 잠근 뒤 연결이 끊겼다가 켜면 복구된다면 배터리 최적화와 백그라운드 실행 제한이 원인일 수 있습니다. 현재 앱의 배터리 정책, 백그라운드 데이터 권한과 제조사별 자동 실행 설정을 확인하세요. 계속 실행해야 하는 클라이언트에만 제한을 조정하고 모든 앱을 제한 없이 실행하도록 설정하지 마세요. 시스템에서 상시 연결 VPN이나 VPN을 거치지 않는 연결 차단을 사용 중이라면 터널이 종료될 때 네트워크가 차단되는 것은 시스템 정책에 따른 정상 동작일 수 있으며 Wi-Fi 고장을 뜻하지 않습니다.

iOS: 시스템 터널과 주문형 연결 확인

iOS에서는 다운로드 페이지의 Clash Plus 스토어 링크를 통해 설치할 수 있으며 공식 웹사이트는 clashplus.io입니다. VPN 설정을 처음 추가할 때 시스템 안내에 따라 권한을 허용하세요. 연결 아이콘은 시스템 상태를 보여 주는 단서일 뿐입니다. 실제 요청과 클라이언트 기록으로 트래픽 경로를 확인하세요. 다른 VPN 설정이 이미 있다면 현재 다른 터널이 사용 중인지 먼저 살펴보고 이전 설정의 상태를 현재 클라이언트 결과로 오해하지 마세요.

앱을 백그라운드로 보낸 뒤 설정 화면이 비활성 상태라고 해서 시스템 터널이 중지된 것은 아닙니다. 대상 앱이 연결되는지, 시스템 VPN 상태와 클라이언트를 다시 열었을 때의 로그를 함께 확인하세요. 주문형 연결 규칙을 사용한다면 현재 Wi-Fi 또는 셀룰러 네트워크가 조건에 포함되는지 점검하세요. 네트워크 이름이 바뀌거나 규칙이 다르게 적용되면 연결 동작도 달라질 수 있습니다. 운에 맡기듯 시스템 설정을 반복해서 삭제하지 마세요.

Wi-Fi와 셀룰러를 각각 확인

먼저 안정적인 Wi-Fi에서 연결을 테스트한 다음 Wi-Fi를 끄고 셀룰러로 전환하세요. 노드와 모드는 그대로 유지합니다. 셀룰러에서만 실패하면 클라이언트의 셀룰러 데이터 권한, 이동통신망 제한과 노드 전송의 접근성을 확인하세요. 특정 Wi-Fi에서만 실패하면 인증 페이지와 라우팅 제한을 먼저 점검하세요. 공용 네트워크에서 웹 로그인이 필요하다면 VPN이 인증 절차를 방해할 수 있습니다. 현재 시스템의 차단 정책을 확인한 뒤 잠시 연결을 끊고 로그인하세요.

네트워크를 전환한 뒤 기존 연결에 이전 주소와 경로가 남을 수 있으므로 잠시 실패했다고 구독을 다시 가져올 필요는 없습니다. 대상 앱의 이전 세션을 종료하고 클라이언트가 새 연결을 만들었는지 확인하세요. 필요하면 현재 터널을 껐다가 다시 켜세요. 비행기 모드를 반복 전환하면 네트워크, 주소와 세션 상태가 모두 바뀌므로 제한적인 복구 방법으로만 사용해야 하며 근본 원인을 확인하는 방법은 아닙니다. 전환 순간에 문제가 발생했는지 계속 이어지는지 기록하면 점검 범위를 크게 줄일 수 있습니다.

앱별 규칙과 로컬 네트워크 연결 확인

Android에서는 앱별 트래픽 전달 목록에서 앱이 빠지는 일이 특히 흔합니다. 앱이 제외되면 클라이언트 규칙이 완벽해도 요청이 클라이언트에 도달하지 않습니다. 목록이 포함 모드인지 제외 모드인지 확인하고 새로 설치한 앱이 적용 범위에 들어갔는지 살펴보세요. 앱이 다운로드를 위해 시스템 서비스를 호출하면 주 프로세스와 다르게 동작할 수도 있으므로 연결 로그를 확인하세요. 브라우저 하나가 된다는 이유로 다른 앱도 같은 경로를 사용한다고 판단하지 마세요.

휴대전화에서 로컬 네트워크 저장 장치, 화면 전송 또는 프린터에 연결할 수 없다면 로컬 네트워크 권한, 주소 대역 우회와 기기 검색 경로를 확인하세요. 기기 검색 프로토콜은 일반 웹 접속과 다르므로 기기 주소가 열려도 자동 검색까지 된다는 보장은 없습니다. 모든 사설 주소를 영구적으로 프록시로 보내거나 화면 전송을 복구하려고 전체 규칙을 지우지 마세요. 먼저 터널을 끄고 로컬 네트워크가 정상인지 확인한 다음 필요한 우회 조건을 하나씩 복구하세요.

마지막으로 화면을 켠 상태에서 사용, 화면을 잠근 뒤 복귀, Wi-Fi와 셀룰러 전환의 세 가지 상황을 다시 테스트하세요. 각 상황에서 원래 문제가 발생한 앱을 사용하고 기기를 재시작한 뒤에도 권한과 설정이 정상적으로 복구되는지 확인하세요. 특정 앱에서만 문제가 생긴다면 자체 DNS 사용 여부, 앱별 제외 여부와 백그라운드 제한을 기록하세요. 일반 연결 정보는 자주 묻는 질문을 참고하고, 최초 설정은 빠른 설정 가이드에 따라 진행하세요. 문제 해결 과정에서 모든 설정을 반복해서 새로 만들 필요는 없습니다.