Clash 문제 해결 가이드

인터넷에 연결되지 않을 때: 직접 연결·프록시·규칙 구분하기

“Clash를 켠 뒤 인터넷에 연결되지 않는다”는 증상만으로는 원인을 알 수 없습니다. 브라우저가 이미 종료된 로컬 프록시를 계속 사용하거나, 코어는 정상적으로 포트를 열었지만 사용할 수 있는 출구가 없을 수 있습니다. 어떤 앱에서 문제가 생기는지, 모든 사이트에서 발생하는지, 클라이언트를 종료하면 해결되는지 먼저 기록하세요. 특정 사이트만 안 되는 경우와 시스템 전체가 오프라인인 경우는 다른 경로로 확인해야 합니다. 처음부터 프로그램을 다시 설치하거나 설정을 모두 지우고 시스템 DNS를 변경하지 마세요. 여러 조건이 한꺼번에 바뀌어 원래 원인을 파악하기 어려워집니다.

직접 연결을 복구한 뒤 로컬 프록시 확인하기

클라이언트에서 시스템 프록시와 TUN 모드를 끈 다음 정상적으로 종료하세요. 운영체제의 네트워크 설정에 수동 프록시가 남아 있지 않은지 확인하고, 평소 프록시 없이 접속하는 사이트를 열어 보세요. 여전히 연결되지 않으면 Wi-Fi 로그인 절차가 완료됐는지, 게이트웨이에 연결되는지, 다른 기기도 인터넷에 연결되지 않는지 확인하세요. 이 단계에서는 아직 Clash 문제라고 단정할 수 없습니다. 먼저 기본 네트워크 연결을 복구하세요. 회사 네트워크나 관리 대상 기기라면 기존 자동 설정 스크립트와 프록시 설정을 보존하고, 조직에서 배포한 정책을 임의로 삭제하지 마세요.

직접 연결이 복구되면 클라이언트 하나만 실행하고 TUN은 끈 상태로 둡니다. 실행 로그에서 설정이 정상적으로 로드됐는지 확인하고 설정 화면에서 혼합 포트를 찾으세요. 아래 예시는 실제 수신 포트가 7890인 경우의 로컬 HTTP 프록시 테스트입니다. 포트가 다르면 숫자를 바꾸세요. 이 요청은 프록시 연결 경로가 응답을 받을 수 있는지 확인하기 위한 것으로 모든 앱이 프록시를 사용한다는 뜻은 아닙니다. 리디렉션 응답이 오더라도 HTTP 계층에서 응답을 받았다는 의미입니다.

curl -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com

Windows PowerShell에서는 curl.exe를 사용하면 같은 옵션을 실행하면서 이름이 같은 다른 명령이 호출되는 일을 피할 수 있습니다. 로컬 포트에 연결할 수 없다는 메시지가 나오면 코어가 실행 중인지, 포트가 변경됐는지, 보안 프로그램이 로컬 포트 수신을 차단하는지 확인하세요. 로컬 포트에는 연결되지만 이후 핸드셰이크에서 시간 초과가 발생하면 앱 연결 단계 이후의 문제이므로 노드 시간 초과 항목에서 출구 경로를 확인하세요. 브라우저 확장 프로그램의 프록시 설정을 반복해서 바꾸지는 마세요.

모드를 바꿔 규칙이 원인인지 확인하기

시스템 프록시를 켠 뒤 규칙 모드에서 같은 주소를 테스트하세요. 이어서 잠시 전역 모드로 바꾸고 실제 노드가 선택돼 있는지 확인합니다. 전역 모드에서는 접속되지만 규칙 모드에서 실패한다면 규칙 일치 여부, 정책 그룹의 대상 또는 규칙 데이터베이스 로드를 확인하세요. 두 모드 모두 실패하면 노드, DNS와 로컬 연결을 먼저 점검하세요. 전역 모드도 앱이 실제로 클라이언트에 연결돼야 작동합니다. 시스템 프록시를 무시하는 앱의 트래픽까지 자동으로 처리하는 것은 아니므로 모드 이름만으로 트래픽 경로를 판단하지 마세요.

연결 목록에서 방금 접속한 도메인을 찾아 적용된 규칙, 출구 정책과 오류 로그를 확인하세요. 출구가 DIRECT이고 해당 대상에 직접 연결할 수 없다면 모든 도메인에 전역 모드를 영구 적용하지 말고 규칙을 수정해야 합니다. 규칙은 보통 위에서부터 순서대로 적용되므로 앞쪽의 범위가 넓은 규칙이 뒤쪽의 세부 규칙보다 먼저 적용될 수 있습니다. 수정 전에 정책 이름이 현재 설정에 있는지 확인하세요. 규칙에서 참조하는 이름은 노드 또는 정책 그룹 이름과 일치해야 합니다.

문제 범위에 맞춰 변경 사항 좁히기

특정 브라우저에서만 문제가 생기면 프록시 확장 프로그램이 없는 다른 브라우저로 비교하고 확장 프로그램, 독립 DNS와 캐시를 확인하세요. 특정 사이트만 안 된다면 사이트 점검, 인증서 오류 또는 계정 제한 여부를 살펴보세요. 인증서 경고가 표시되면 먼저 시스템 시간을 확인하세요. 접속을 복구하려고 인증서 검증을 끄면 안 됩니다. 자세한 내용은 HTTPS 인증서 오류 원인과 해결 방법을 참고하세요. 사이트에서 반환한 접속 거부 페이지를 시스템 전체의 인터넷 연결 오류로 오인하지 마세요.

노드 시간 초과: DNS 조회·연결·핸드셰이크 구분하기

노드 테스트 시간 초과는 특정 테스트 요청이 제한 시간 안에 완료되지 않았다는 뜻일 뿐, 노드가 고장 났다는 뜻은 아닙니다. 테스트 주소, DNS, 서버 포트, 프로토콜 핸드셰이크와 대상 사이트 모두 같은 결과를 일으킬 수 있습니다. 노드 하나를 선택해 실제로 접속하고 문제가 발생한 시점의 로그와 비교하세요. 구독 전체를 반복해서 한꺼번에 테스트하지 마세요. 동시 요청이 많으면 속도 제한이 걸릴 수 있고, 현재 접속과 무관한 오류가 로그에 섞여 개별 요청을 찾기 어려워집니다.

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

로그 설정에서 잠시 info 수준을 선택한 뒤 실패한 시간과 대상을 기록하세요. 노드 도메인 조회에 실패했다면 DNS를 확인하고, 서버 주소 연결이 시간 초과됐다면 현재 네트워크에서 서버에 도달할 수 있는지 확인하세요. 서버에 연결된 뒤 TLS 또는 인증 오류가 발생하면 프로토콜 설정, 시스템 시간과 구독 상태를 확인합니다. 필요하면 잠시 debug로 바꾸되 상세 로그를 계속 켜 두지 마세요. 전체 주소나 인증 정보가 포함된 로그를 공개하지 마세요.

오류 문구는 앞뒤 맥락과 함께 확인하세요. 같은 timeout도 노드 연결에서 발생할 수 있고 대상 사이트의 응답을 기다리다 발생할 수도 있습니다. 로그에서 원격 주소를 찾아 노드 서버인지 대상 사이트인지 구분하세요. 필드 이름은 코어와 클라이언트에 따라 다르므로 영어 단어 하나만 검색해 결론을 내리지 마세요. Clash 실행 로그 확인 방법을 참고해 요청별로 시간, 대상, 정책과 오류를 정리하세요.

한 번에 한 가지씩 비교해 범위 좁히기

클라이언트와 설정은 그대로 두고 현재 Wi-Fi에서 휴대폰 핫스팟으로 전환한 뒤 같은 노드와 주소를 테스트하세요. 핫스팟에서는 되지만 기존 네트워크에서 실패한다면 기존 네트워크의 출구, 방화벽 또는 DNS를 우선 확인할 수 있습니다. 두 네트워크에서 모두 실패하면 다른 노드로 비교하세요. 일부 노드에서만 문제가 생기면 서비스 제공자에게 노드 점검, 계정 만료일 또는 연결 제한을 문의하세요. 노드 하나의 문제 때문에 시스템 네트워크 설정 전체를 바꾸지 마세요.

Windows에서는 Test-NetConnection으로 알고 있는 서버의 TCP 포트를 확인할 수 있고, macOS나 Linux에서는 nc를 사용할 수 있습니다. 직접 설정한 서버 주소와 포트를 입력하고 노드 자격 증명을 공개 터미널에 붙여 넣지 마세요. TCP 연결에 성공해도 포트에 연결할 수 있다는 뜻일 뿐, 앱 프로토콜과 인증, 트래픽 전달까지 정상이라는 보장은 없습니다. UDP 기반 전송도 TCP 테스트 한 번으로 사용 가능 여부를 판단할 수 없습니다. ICMP ping이 차단돼도 노드가 프록시 서비스를 정상 제공할 수 있습니다.

프로토콜 호환성과 자동 선택 확인하기

설정을 가져오는 데 성공해도 현재 코어가 모든 프로토콜 필드를 지원한다는 뜻은 아닙니다. 다른 클라이언트에서 가져왔거나 구독 변환을 거쳤거나 최신 프로토콜이 포함된 설정이라면 로그에서 알 수 없는 유형, 누락된 필드 또는 핸드셰이크 호환 오류를 확인하세요. 먼저 사용 중인 프로젝트에서 계속 지원하는 릴리스로 업데이트하거나, 현재 코어에 맞는 설정을 서비스 제공자에게 요청하세요. 클라이언트를 바꿔야 한다면 설치 파일 다운로드 페이지에서 Clash Plus를 확인한 뒤 필요한 프로토콜을 지원하는지 살펴보세요. 출처가 불분명한 코어 파일을 섞어 사용하지 마세요.

자동 선택 정책은 이전 테스트 결과를 계속 사용하거나 실제 서비스와 다른 테스트 주소를 이용할 수 있습니다. 검증된 노드 하나를 직접 선택하고 이번 문제 해결에 필요하지 않은 자동 전환은 잠시 끈 뒤 실제 연결을 확인하세요. 노드 연결은 되지만 트래픽이 많을 때 끊긴다면 패킷 손실, 경로 MTU와 서버 제한도 확인해야 합니다. 속도 테스트 간격을 더 짧게 설정하지 마세요. 해결 후 원래 테스트 정책을 복구하고 새 연결에 현재 선택한 노드가 실제로 사용되는지 확인하세요.

구독 오류: 다운로드·파싱·적용 단계별 확인

구독 업데이트는 원격에서 내용을 가져오고, 설정으로 파싱하고, 선택한 설정을 코어에 적용하는 세 단계로 진행됩니다. 다운로드는 완료됐지만 설정이 적용되지 않은 경우와 구독을 아예 가져오지 못한 경우는 서로 다른 문제입니다. 설정 화면의 마지막 업데이트 결과와 실행 로그를 확인해 어느 단계에서 실패했는지 파악하세요. 구독을 반복해서 삭제하고 다시 추가하지 마세요. 로컬 오버라이드, 규칙 선택과 기존 설정까지 함께 지워져 사용할 수 있던 캐시 설정을 복구하지 못할 수 있습니다.

내용을 가져오지 못하면 주소와 접속 경로 확인하기

서비스 제공자의 계정 페이지에서 구독 주소 전체를 다시 복사하고 처음과 끝이 잘렸는지, 복사 과정에서 줄바꿈이 들어갔는지 확인하세요. QR 코드로 가져온 내용도 웹페이지 주소가 아닌 구독 URL인지 확인해야 합니다. 구독 주소에는 접속 자격 증명이 포함될 수 있으므로 온라인 검사 사이트나 공개 변환 페이지에 올리지 마세요. 지원팀에 문의할 때는 오류 코드, 발생 시간과 일부를 가린 도메인만 제공하세요. 주소의 경로와 쿼리 매개변수에도 민감한 정보가 들어 있을 수 있습니다.

HTTP 상태 코드는 응답 의미에 맞게 처리하세요. 인증 관련 오류라면 계정과 주소가 유효한지 먼저 확인합니다. 요청이 너무 많다는 응답이 오면 기다렸다가 다시 업데이트하고, 서버 오류가 발생하면 현재 설정을 보존하세요. 브라우저에서 서비스 사이트가 열려도 구독 API에 접속할 수 있다는 뜻은 아닙니다. 도메인과 인증 방식이 다를 수 있습니다. 브라우저에 내용이 표시되더라도 설정이 올바르다는 보장은 없습니다. 로그인이나 인증 페이지도 성공 상태를 반환할 수 있습니다.

구독 도메인에 프록시 연결이 필요한 경우 기존의 정상 설정으로 연결한 뒤 업데이트하세요. 클라이언트가 업데이트 요청을 직접 연결로 고정한다면 구독 다운로드 설정을 확인합니다. 반대로 현재 프록시가 작동하지 않는데 구독을 반드시 프록시로 다운로드하도록 하면 연결이 반복해서 실패할 수 있습니다. 클라이언트의 직접 연결 또는 프록시 옵션을 사용해 한 번에 하나씩 비교하세요. 클라이언트 여러 개를 이어서 사용하지 마세요. 로컬 포트와 시스템 프록시 설정이 서로 덮어쓸 수 있습니다.

내용은 가져왔지만 형식 오류가 표시될 때

파싱에 실패하면 전체 YAML 설정, 노드 목록과 클라이언트 전용 공유 형식을 구분하세요. 이 형식들은 항상 같은 가져오기 메뉴에서 사용할 수 있는 것이 아닙니다. 전체 설정은 설정 관리에서 불러오고, 노드 제공자는 메인 설정에서 참조해야 합니다. 노드 목록을 정책 그룹과 규칙이 포함된 메인 설정으로 가져오면 필드가 빠지거나 정책을 찾을 수 없다는 오류가 날 수 있습니다. 제공자의 가져오기 안내를 확인하고 현재 클라이언트에 맞는 링크를 선택하세요. 파일 확장자만 보고 형식을 판단하지 마세요.

YAML은 들여쓰기와 자료형에 민감합니다. 직접 수정할 때는 탭 대신 공백을 사용하고 목록 항목과 상위 필드의 계층을 확인하세요. 메신저에서 복사한 전각 콜론이나 굽은 따옴표가 들어가지 않도록 주의합니다. 오류 행은 파서가 문제를 발견한 위치일 뿐 실제로 빠진 기호는 바로 앞 행에 있을 수 있습니다. 들여쓰기 하나를 고치려고 따옴표를 전부 바꾸지 마세요. 암호, 정규식 또는 특수 문자가 포함된 이름은 따옴표가 필요할 수 있습니다.

업데이트 후 코어에서 실제로 사용하는 설정 확인하기

설정 목록으로 돌아가 방금 업데이트한 항목이 선택돼 있는지 확인한 뒤 로그에서 다시 불러오기가 완료됐는지 확인하세요. 업데이트 후 현재 설정을 자동으로 전환하지 않는 클라이언트도 있습니다. 화면에 보이는 노드 목록이 다른 설정에서 가져온 것일 수도 있습니다. 정책 그룹 이름과 새 연결의 출구를 확인하세요. 오래 열어 둔 웹페이지는 기존 연결을 계속 사용할 수 있으므로 유일한 확인 방법으로 삼지 마세요. 테스트 탭을 닫고 새 요청을 시작하는 것이 좋습니다.

업데이트 후 노드는 모두 표시되는데 규칙이 사라졌다면 로컬 오버라이드가 rules 또는 proxy-groups 목록 전체를 덮어쓰는지 확인하세요. 배열을 바꾸거나 추가하는 방식은 클라이언트의 병합 방식에 따라 다르며 모든 클라이언트가 동일하게 처리하지 않습니다. 오버라이드 하나를 잠시 끄고 구독 자체의 문제인지 병합 결과의 문제인지 비교하세요. 해결 후 장기간 유지할 로컬 설정은 지원되는 오버라이드 위치에 넣어 다음 구독 업데이트 때 다시 덮어쓰이지 않도록 하세요.

가져오기 메뉴와 설정 선택을 더 확인하려면 설치 및 설정 가이드를 참고하세요. 형식 차이와 구독 업데이트 방법은 고객센터의 설치·설정 FAQ에서 확인할 수 있습니다. 구독 다운로드가 복구된 뒤 적절한 자동 업데이트 주기를 설정하세요. 자주 새로고침하는 것은 노드 시간 초과나 계정 문제의 만능 해결책이 아닙니다.

속도 저하: 응답 지연과 지속 전송 구분하기

웹페이지 로딩, 동영상 버퍼링과 대용량 파일 다운로드는 서로 다른 병목 때문에 느려질 수 있습니다. 속도 테스트 화면의 노드 지연 시간은 테스트 요청의 응답 상태를 주로 보여줄 뿐, 사용 가능한 대역폭이나 특정 사이트의 CDN 경로를 보장하지 않습니다. 처음 열 때만 느린지, 전송 내내 느린지, 특정 앱만 느린지 먼저 구분한 뒤 같은 네트워크와 대상, 시간대에서 비교하세요. 서로 다른 사이트나 파일의 결과를 직접 비교해 노드 성능을 판단하지 마세요.

먼저 로컬 네트워크와 백그라운드 사용량 배제하기

시스템 업데이트, 클라우드 동기화와 다른 다운로드를 일시 중지하고 Wi-Fi 신호가 안정적인지 확인한 뒤 같은 대상을 반복 테스트하세요. 노트북은 잠시 유선 네트워크를 사용하고 휴대폰은 Wi-Fi와 모바일 데이터로 비교할 수 있습니다. 직접 연결도 동시에 느리다면 로컬 네트워크와 통신사 출구를 먼저 확인하세요. 프록시 경로만 느리다면 다른 노드와 비교합니다. 여러 속도 테스트 사이트를 동시에 실행하면 대역폭을 나눠 쓰게 되고 연결 수의 영향도 커지므로 테스트는 하나씩 진행하세요.

클라이언트가 실행 중인 기기의 CPU와 메모리 사용량을 확인하세요. 저전력 라우터, 구형 휴대폰과 가상 머신은 프로토콜 암호화나 가상 네트워크 오버헤드로 제한될 수 있습니다. 전송량이 늘 때 단일 코어 사용률이 계속 높아지는지도 살펴보세요. 기기 전체의 평균 CPU 사용률이 낮다고 해서 연산 성능 병목이 아니라고 단정할 수 없습니다. 일반 PC에서는 같은 노드가 정상인데 라우터에서만 속도가 크게 떨어진다면 DNS 서버를 계속 바꾸기보다 기기 자원과 설정 복잡도를 확인하세요.

연결 기록에서 실제 출구 확인하기

연결 목록에서 느린 요청에 실제로 어떤 정책이 적용됐는지 확인하세요. 자동 선택, 부하 분산과 장애 조치 그룹은 요청마다 다른 출구를 사용할 수 있습니다. 브라우저가 노드를 바꾸기 전에 만든 연결을 재사용할 수도 있습니다. 테스트할 때는 노드 하나를 고정하고 기존 다운로드를 종료한 뒤 새 요청을 시작해 결과를 기록하세요. 전역 모드는 규칙을 비교하는 용도로만 사용하세요. 규칙 오류를 가리기 위해 계속 전역 모드를 쓰거나 직접 연결해야 하는 대용량 로컬 서비스까지 프록시로 보내지 마세요.

첫 화면은 빠르지만 이미지나 동영상이 느리다면 페이지의 하위 리소스 도메인과 각 도메인에 적용된 규칙을 확인하세요. 한 페이지가 여러 출처에서 리소스를 가져올 수 있으므로 메인 도메인의 프록시 연결이 정상이라고 미디어 도메인에도 같은 정책이 적용되는 것은 아닙니다. 일부 요청은 직접 연결되고 나머지는 프록시를 사용하면 연결이 중복되거나 지역이 달라지고 서버가 콘텐츠를 다시 선택할 수 있습니다. 실제로 문제가 생긴 리소스를 기준으로 규칙을 조정하세요. 최상위 도메인 전체를 같은 출구로 바꾸지 마세요.

전송 방식과 TUN 설정은 신중하게 조정

일부 동영상이나 브라우저는 보통 UDP 기반인 QUIC을 사용합니다. 노드나 현재 네트워크에서 UDP를 제대로 지원하지 않으면 요청이 반복해서 대기하거나 다른 전송 방식으로 전환될 수 있습니다. 근거가 있을 때만 앱의 QUIC을 잠시 끄고 비교하세요. 변경 전 값을 기록하고 테스트 후 원래대로 복구해야 합니다. TCP 다운로드가 정상이어도 UDP가 정상이라는 뜻은 아닙니다. 반대로 UDP를 사용하는 특정 작업이 실패해도 노드 전체가 작동하지 않는다고 단정할 수 없습니다. 속도 테스트 순위만으로 프로토콜을 선택하지 말고 실제 사용 환경을 고려하세요.

TUN에서만 문제가 발생한다면 먼저 TUN을 끄고 로컬 프록시를 명시해 접속한 결과와 비교하세요. 경로 MTU가 맞지 않으면 큰 패킷이 재전송될 수 있지만, MTU 변경이 모든 속도 문제의 해결책은 아닙니다. 패킷 캡처, 네트워크 환경 설명 또는 반복 비교로 원인을 뒷받침할 수 있을 때만 항목별로 조정하고 기존 값을 보관하세요. 프로토콜, DNS, MTU와 출구 노드를 한꺼번에 바꾸지 마세요. 문제가 해결돼도 원인을 알기 어렵고 이후 업데이트 때 같은 문제가 재발할 수 있습니다.

마지막으로 서버 용량, 계정 트래픽 제한과 대상 사이트 자체의 다운로드 정책을 확인하세요. 같은 노드에서 여러 기기가 같은 시간대에 느리고 노드를 바꾸자 정상으로 돌아온다면 테스트 시간, 대상 유형과 증상을 서비스 제공자에게 전달하세요. “지연 시간이 높다”고만 하기보다 연결 수립이 느린지 지속 전송 속도가 낮은지 구분하는 것이 원인을 찾는 데 도움이 됩니다. 평소에 계속 속도 테스트를 실행할 필요는 없습니다. 한 번의 테스트 결과보다 실제 사용이 안정적인지가 더 중요합니다.

DNS 문제: 조회 출처와 실제 경로 확인하기

DNS 문제는 특정 도메인만 열리지 않거나 노드 도메인 조회가 실패하고, 첫 연결이 오래 걸리거나 네트워크를 바꾼 뒤에도 이전 주소가 반환되는 형태로 나타날 수 있습니다. 먼저 시스템 DNS 조회, 브라우저 자체 조회와 코어 조회를 구분하세요. 이 기능들은 동시에 사용될 수 있고 조회 서버도 서로 다를 수 있습니다. 시스템 명령에서 조회가 성공해도 해당 명령이 사용한 경로만 정상이라는 뜻입니다. Clash 코어가 올바른 결과를 받았다는 보장은 없으며 브라우저도 자체 캐시를 사용했을 수 있습니다.

시스템 조회 결과와 클라이언트 연결 기록 비교하기

프록시가 트래픽을 가로채지 않는 상태에서 대상 도메인을 조회하고 사용한 DNS 서버와 반환 주소를 기록한 뒤 클라이언트를 켜고 해당 연결의 로그를 확인하세요. 아래 명령은 시스템에서 사용하는 DNS 결과를 확인할 뿐 코어의 DNS 서비스에 직접 질의하지 않습니다. 코어의 DNS 수신 포트에 직접 질의하려면 설정된 주소와 포트를 확인하고 포트 지정이 가능한 조회 도구를 사용하세요. 제어 인터페이스 포트를 DNS 포트로 사용하지 마세요.

nslookup example.com

fake-ip를 사용하는 설정에서는 클라이언트가 도메인에 연결하기 위한 예약 주소를 반환한 뒤 코어가 연결을 원래 도메인으로 복원할 수 있습니다. 이런 결과만 보고 DNS 변조라고 단정하지 마세요. 이후 연결도 같은 코어가 처리하는지, 도메인 매핑이 유효한지가 중요합니다. 앱이 매핑 주소를 받았지만 TUN이나 로컬 프록시를 우회해 직접 연결하면 접속이 실패할 수 있습니다. 트래픽 가로채기를 끈 뒤에도 이전 매핑이 캐시에 남으면 일시적으로 접속이 되지 않을 수 있습니다.

부트스트랩 조회와 업스트림 접속 이해하기

암호화 DNS 서버의 도메인 이름도 먼저 조회해야 합니다. 노드 도메인을 조회하는 요청이 아직 연결되지 않은 프록시에 의존하면 순환 문제가 생길 수 있습니다. DNS 업스트림에 연결할 수 있는지, 노드 도메인을 어느 쪽에서 조회하는지 먼저 확인한 뒤 규칙 기반 라우팅 설정을 살펴보세요. 온라인에서 찾은 DNS 설정 전체를 구독 설정에 그대로 덮어쓰지 마세요. proxy-server-nameserver 등의 필드를 현재 코어가 지원하는지, 기존 설정에 같은 기능이 있는지도 확인해야 합니다.

아래는 mihomo를 사용하는 클라이언트에서 참고할 수 있는 일부 필드 예시입니다. 일반 도메인과 프록시 서버 도메인의 조회 출처를 구분하기 위한 것으로 전체 설정이 아닙니다. TUN과 DNS 수신 주소는 설정하지 않았으므로 시스템 DNS 요청을 자동으로 가로채지 않습니다. 설정을 합칠 때 문서 끝에 같은 최상위 키를 추가하지 말고 기존 dns 항목을 수정하세요. 중복 키가 있으면 파서에 따라 결과가 달라질 수 있습니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://dns.google/dns-query
  proxy-server-nameserver:
    - 1.1.1.1

예시에 사용된 업스트림은 현재 네트워크에서 접속할 수 있어야 하며 특정 공용 DNS를 모든 네트워크에서 정답처럼 사용할 수는 없습니다. 회사 내부망, 학교 네트워크와 가정용 LAN은 내부 도메인 조회에 전용 DNS가 필요할 수 있습니다. 업스트림을 모두 바꾸면 공용 사이트는 열리더라도 프린터, 내부 시스템이나 로컬 도메인이 작동하지 않을 수 있습니다. 이런 경우 공용 서버를 계속 추가하기보다 도메인별로 내부 DNS 경로를 유지하세요. 업스트림 여러 개가 입력 순서대로 단순히 대체 서버로 사용되는 것도 아닙니다.

캐시·IPv6 문제와 누수 오인 배제하기

조회 경로를 바꾼 뒤 대상 앱을 다시 열고 새 연결을 테스트하세요. 필요하면 시스템 DNS 캐시를 비웁니다. Windows에서는 ipconfig /flushdns를 사용할 수 있고 systemd-resolved를 사용하는 Linux에서는 resolvectl flush-caches를 실행할 수 있습니다. 다른 운영체제에서는 해당 DNS 서비스에 맞는 방법을 사용하세요. 캐시 삭제는 이전 결과만 지울 뿐 연결할 수 없는 업스트림을 복구하지 않습니다. 변경 직후 문제가 해결됐더라도 실제 경로를 다시 확인해 일시적인 캐시 변화와 근본적인 해결을 구분하세요.

DNS 누수 여부는 예상한 정책과 함께 판단해야 합니다. 테스트 페이지에 DNS 서버가 표시돼도 테스트 요청이 그 경로를 사용했다는 뜻일 뿐 모든 도메인 요청이 프록시를 우회한다는 증거는 아닙니다. 브라우저의 보안 DNS, 시스템 비공개 DNS, TUN의 DNS 가로채기 범위와 분기 정책이 일치하는지 확인하세요. IPv6도 따로 점검해야 합니다. IPv4만 가로채면 앱이 IPv6를 통해 다른 경로로 연결될 수 있습니다. IPv6를 무조건 끄지 말고 클라이언트와 네트워크의 지원 여부를 먼저 확인하세요.

시스템 프록시가 작동하지 않을 때: 앱이 코어에 연결되는지 확인하기

시스템 프록시는 운영체제가 앱에 제공하는 프록시 설정이며 모든 트래픽을 처리하는 네트워크 터널은 아닙니다. 브라우저, 명령줄 도구, 게임과 시스템 서비스마다 이 설정을 지원하는 방식이 다릅니다. 따라서 스위치가 켜져 있어도 클라이언트가 설정을 기록하려 했다는 뜻일 뿐 모든 프로그램이 프록시를 사용한다는 보장은 없습니다. 먼저 클라이언트의 연결 목록을 열고 대상 앱에서 새 요청을 보내세요. 해당 요청이 목록에 나타나는지 확인하는 것이 연결 경로를 판단하는 중요한 첫 단계입니다.

시스템 설정이 제대로 적용됐는지 먼저 확인하기

시스템 네트워크 프록시 설정에서 주소가 로컬 기기를 가리키고 포트가 클라이언트의 혼합 포트와 일치하는지 확인하세요. 클라이언트가 다른 기기에서 실행 중일 때만 그 기기의 LAN 주소를 사용하고 수신 설정과 방화벽도 별도로 확인해야 합니다. 127.0.0.1은 항상 현재 기기 자신을 가리키므로 원격 컴퓨터 주소로 사용하지 마세요. 로컬 브라우저를 연결하기 위해 LAN 연결 허용을 켜지 마세요. 수신 범위만 넓어질 뿐 로컬 포트가 틀린 문제는 해결되지 않습니다.

Windows의 사용자 프록시 설정과 일부 서비스에서 사용하는 WinHTTP 프록시는 서로 다릅니다. macOS의 프록시 설정은 보통 네트워크 서비스에 연결되므로 다른 Wi-Fi나 유선 네트워크로 전환한 뒤 다시 확인해야 합니다. Linux 데스크톱의 시스템 프록시를 터미널 프로그램이 반드시 읽는 것도 아닙니다. 스위치가 저절로 꺼지거나 포트가 원래 값으로 돌아가고 주소가 반복해서 바뀐다면 다른 프록시 앱, 브라우저 확장 프로그램 또는 조직 정책이 설정을 관리하는지 확인하세요.

로그에 로컬 포트가 사용 중이라고 표시되면 어떤 프로그램이 점유하는지 확인한 뒤 해당 프로그램을 종료할지 포트를 바꿀지 결정하세요. Windows에서는 netstat -ano로 수신 포트와 PID를 확인할 수 있고, macOS에서는 lsof -nP -iTCP:7890 -sTCP:LISTEN으로 특정 포트를 확인할 수 있습니다. 프로세스 번호만 보고 알 수 없는 시스템 서비스를 강제 종료하지 마세요. 혼합 포트를 바꾼 뒤에는 시스템 프록시, 브라우저 수동 설정과 터미널 환경 변수도 함께 변경해야 합니다. 자세한 내용은 포트 사용 중 문제 해결 안내를 참고하세요.

터미널에서는 명령별로 프록시를 지정해 테스트하기

터미널 도구가 시스템 프록시 설정을 따르지 않으면 전역 환경 변수를 바꾸기 전에 명령 하나에 프록시를 명시하세요. 아래 두 명령은 각각 HTTP 프록시와 SOCKS 프록시를 사용합니다. socks5h의 h는 대상 도메인을 프록시 쪽에서 조회한다는 의미입니다. 로컬에서 먼저 조회한 뒤 연결하는 방식과 달라 DNS 경로를 비교할 때 유용합니다. 실행 전에 클라이언트가 해당 프로토콜을 열었는지 확인하세요. 혼합 포트는 보통 두 종류의 요청을 모두 받습니다.

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

프록시를 명시하면 성공하지만 기본 실행은 직접 연결한다면 도구가 프록시 설정을 어디서 가져오는지 확인해야 합니다. HTTP_PROXY, HTTPS_PROXY, ALL_PROXY와 NO_PROXY를 확인하고 대소문자가 다른 변수와 도구 설정 파일도 살펴보세요. 환경 변수 적용 순서는 프로그램마다 다르며 NO_PROXY 때문에 특정 도메인이 프록시를 우회할 수도 있습니다. 브라우저는 되는데 Git만 안 되는 경우 Git 자체에 저장된 프록시 설정이 원인일 수 있으므로 시스템 스위치만 바꾸지 마세요.

TUN이 필요한 경우 권한과 라우팅 확인하기

시스템 프록시를 사용하지 않는 앱을 연결해야 한다면 클라이언트 문서에 따라 TUN을 설정할 수 있습니다. 다만 먼저 기본 프록시 연결이 정상인지 확인해야 합니다. TUN을 켠 뒤 화면의 스위치만 보지 말고 서비스 권한, 가상 네트워크 어댑터와 라우팅이 실제로 설정됐는지 확인하세요. 다른 VPN, 가상 머신과 컨테이너 네트워크가 라우팅 충돌을 일으킬 수 있습니다. 관련 기능을 한 번에 하나씩 끄며 비교하고 복구 방법을 기록하세요. 알 수 없는 네트워크 어댑터를 바로 삭제하지 마세요. 회사 VPN을 계속 사용해야 한다면 네트워크 관리 지침을 우선 따르세요.

브라우저에서만 문제가 생기면 확장 프로그램이 프록시를 대신 설정하는지, 보안 DNS를 따로 사용하는지, 이전 연결을 계속 사용하는지 확인하세요. 확장 프로그램 일부는 시크릿 창에서도 실행할 수 있으므로 확장 프로그램이 없는 새 브라우저 프로필에서 테스트하는 것이 더 확실합니다. 브라우저와 터미널을 비교하는 전체 절차는 시스템 프록시 문제 해결 안내를, 기본 설정 위치는 가이드의 시스템 프록시 항목을 참고하세요.

문제 해결을 마치면 클라이언트를 정상 종료하고 시스템 프록시가 예상대로 복구됐는지 확인하세요. 프로세스를 강제 종료하거나 전원이 끊기면 시스템이 더 이상 수신하지 않는 로컬 포트를 계속 가리킬 수 있습니다. 이 설정이 남으면 클라이언트를 종료한 뒤 오히려 인터넷에 연결되지 않을 수 있습니다. 클라이언트를 다시 열고 시스템 프록시를 정상적으로 끄거나 시스템 설정에서 원래 값으로 복구하세요. 시작 프로그램은 앱의 실행 시점만 정합니다. 설정 로드, 코어 실행과 시스템 프록시 적용 여부는 각각 확인해야 합니다.

클라이언트 충돌: UI·코어·시스템 환경 구분하기

창이 사라졌는지, 트레이 아이콘은 남아 있는지, 연결이 모두 끊겼는지, 앱 자체가 시작되지 않는지에 따라 UI 프로세스, 코어 프로세스 또는 시스템 실행 환경의 문제일 수 있습니다. 작업 관리자나 활성 상태 보기에서 관련 프로세스가 실행 중인지 확인하고 클라이언트 로그 폴더의 마지막 기록을 확인하세요. 앱을 연달아 여러 번 실행하거나 애플리케이션 데이터 폴더 전체를 바로 삭제하지 마세요. 원래 설정, 오류 로그와 시작 상태가 문제를 찾는 데 가장 중요한 단서일 수 있습니다.

충돌을 일으킨 조건을 기록하고 복구 경로 보존하기

구독 업데이트, TUN 활성화, 테마 변경, 시스템 업그레이드 또는 절전 모드 해제 직후 충돌했는지 되짚어 보세요. 반복해서 재현할 수 있는 동작이 “가끔 충돌한다”는 설명보다 원인을 찾기 쉽습니다. 설정과 필요한 앱 옵션을 백업한 뒤 프록시를 가로채지 않는 상태로 클라이언트를 시작해 보세요. 창이 안정적으로 표시되면 기능을 하나씩 다시 켭니다. 충돌 후에는 시스템 프록시 설정이 남아 있는지도 확인하세요. 로그를 수집하는 동안 브라우저에 연결할 수 없는 문제가 별개의 고장으로 오인될 수 있습니다.

설치 파일이 운영체제와 프로세서 아키텍처에 맞는지 확인하세요. macOS에서는 Apple Silicon용과 Intel용 패키지를 구분해야 하며 Linux에서는 배포판, 패키지 형식과 그래픽 환경도 고려해야 합니다. 설치가 실패하거나 실행 직후 종료되면 시스템 메시지를 확인하세요. 출처가 불분명한 사이트에서 런타임, 드라이버를 받거나 동적 라이브러리를 바꾸지 마세요. 설치 파일을 바꿔야 한다면 다운로드 페이지에서 Clash Plus를 먼저 확인하고 실제 플랫폼과 사용 목적에 맞춰 지원 중인 다른 클라이언트도 비교하세요.

설정 로드 실패와 프로그램 충돌은 따로 확인하기

UI는 정상인데 코어가 반복해서 종료되면 설정 문법, 참조 파일과 규칙 제공자 경로를 확인하세요. 구독 설정에서 참조하는 파일을 다운로드하지 못해 전체 설정이 로드되지 않을 수 있습니다. 설정 폴더를 직접 옮긴 경우 상대 경로가 더 이상 유효하지 않을 수도 있습니다. 먼저 자동 업데이트를 일시 중지하고 백업 중 정상 작동이 확인된 설정으로 되돌린 뒤 안정성을 살펴보세요. 문제를 해결하려고 모든 규칙을 삭제하지 마세요. 로그에 표시된 파일이나 필드부터 하나씩 확인하고 복구하세요.

클라이언트에 설정 검사 기능이 있다면 먼저 실행한 뒤 코어를 다시 불러오세요. 명령줄 코어를 사용하는 경우 백업 후 아래 문법의 테스트 명령을 실행할 수 있습니다. 이 명령은 지정된 설정만 검사하며 정상 실행을 대신하지 않습니다. 설정에 상대 경로, 제공자 또는 외부 데이터베이스가 포함돼 있다면 실제 배포 환경에 맞는 작업 디렉터리도 지정해야 합니다. GUI 클라이언트는 설정을 추가로 병합해 최종본을 만들 수 있으므로 원본 구독과 실행 설정의 검사 결과가 다를 수 있습니다.

mihomo -t -f config.yaml

제어 인터페이스 주소, 혼합 포트 또는 DNS 수신 포트가 충돌하면 코어가 시작 직후 종료될 수 있습니다. 마지막 종료 메시지만 보지 말고 전체 오류를 확인하세요. 여러 인스턴스, 시작 작업과 서비스 모드를 동시에 실행하면 포트 충돌이 생기기 쉽습니다. 한 가지 실행 방식만 남기고 이전 프로세스가 포트를 계속 점유하지 않는지 확인한 뒤 다시 시작하세요. 로컬 연결 문제를 해결하려고 외부 제어 포트를 공용 네트워크에 노출하지 마세요. 시작 오류와 직접 관련이 없습니다.

권한·자원·UI 의존성 확인하기

TUN을 켰을 때만 종료된다면 클라이언트 서비스가 올바르게 설치됐는지, 운영체제에서 필요한 권한을 허용했는지, 보안 프로그램이 차단했는지 확인하세요. 명확히 필요한 프로그램과 작업에만 권한을 부여하고 보안 기능을 모두 끄지 마세요. Linux에서는 일반 사용자와 관리자 권한으로 실행할 때 설정 폴더와 파일 소유자가 달라질 수 있습니다. GUI를 관리자 권한으로 실행한 적이 있으면 일반 사용자가 같은 폴더에 쓰지 못해 설정 저장이나 시작에 실패할 수 있습니다.

오래 실행한 뒤 충돌한다면 메모리 사용량이 계속 증가하는지, 디스크 공간이 부족한지, 로그가 과도하게 쌓이는지 확인하세요. 연결 상세 정보처럼 자주 갱신되는 화면을 잠시 닫고 로그 수준을 낮춰 UI 갱신과 코어 연결 부하 중 무엇이 문제를 일으키는지 비교할 수 있습니다. 사용 중인 데이터베이스 파일을 바로 삭제하지 마세요. 먼저 앱을 종료하고 백업한 뒤 클라이언트 안내에 따라 다시 만들 수 있는 캐시만 정리하세요. 폴더의 용도를 확인하고 구독과 사용자 설정은 캐시로 취급하지 마세요.

문제를 신고할 때는 운영체제와 아키텍처, 클라이언트 이름, 재현 동작, TUN 사용 여부, 민감 정보를 가린 오류 로그와 설정을 바꾼 뒤 비교한 결과를 정리하세요. Clash for Windows와 ClashX Meta는 지원이 종료됐으므로 시스템 호환성 문제가 발생하면 보관용 패키지를 반복해서 설치하기보다 다른 클라이언트로 이전하는 방법을 고려하세요. 이전 전에 원본 설정을 저장하고 새 클라이언트 형식에 맞춰 다시 가져오세요. 개인 데이터 폴더 전체를 새 클라이언트에 그대로 덮어쓰지 마세요.

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

모바일은 시스템 VPN, 백그라운드 작업 관리와 네트워크 전환의 영향을 받으므로 데스크톱 시스템 프록시와 다른 방식으로 확인해야 합니다. 먼저 앱이 실제로 VPN 세션을 만들었는지, 대상 앱이 트래픽 가로채기 대상에 포함되는지 확인하세요. 상태 표시줄에 VPN 아이콘이 있어도 노드 인증, DNS 또는 대상 연결이 성공했다는 뜻은 아닙니다. 정상 작동이 확인된 노드 하나를 유지하고 브라우저와 다른 앱에서 각각 테스트하세요. 한 앱의 결과만으로 기기 전체의 네트워크 상태를 판단하지 마세요.

Android에서 VPN 점유와 백그라운드 제한 확인하기

Android에서 연결을 시작할 때는 시스템 VPN 권한을 허용해야 합니다. 연결을 눌렀는데 곧바로 중지된다면 다른 VPN, 방화벽, 광고 차단 또는 패킷 캡처 앱이 시스템 VPN 슬롯을 사용 중인지 확인하세요. 원격 서버가 없는 앱도 로컬 VPN으로 트래픽을 처리할 수 있습니다. 다른 앱을 정상 종료한 뒤 테스트하고 여러 앱의 연결을 반복해서 동시에 켜지 마세요. 업무 프로필이나 기기 관리 정책이 적용된 경우 관리 지침도 따라야 합니다. 개인 설정만으로 업무 프로필의 네트워크 정책을 바꿀 수는 없습니다.

연결 후 화면을 잠그면 인터넷이 끊기고 앱으로 돌아왔을 때 복구된다면 배터리 절약 설정, 백그라운드 실행 권한과 시스템의 앱 종료 여부를 먼저 확인하세요. 기기에서 허용하는 방식으로 클라이언트의 백그라운드 실행을 유지하고 연결 알림 상태도 확인하세요. 제조사마다 메뉴 이름이 다르므로 알림 허용만 보고 백그라운드 권한이 모두 설정됐다고 판단하지 마세요. 먼저 화면을 켠 채 짧게 테스트한 다음 잠금 상태에서 같은 작업을 반복하세요. 잠근 뒤에만 실패할 때 백그라운드 제한을 의심할 수 있습니다.

항상 켜기 VPN 또는 VPN을 거치지 않는 연결 차단을 설정하면 클라이언트가 중지될 때 인터넷이 끊길 수 있습니다. 시스템 VPN 설정에서 해당 옵션이 켜져 있는지 확인하고 보안 정책에 따른 동작과 앱 오류를 구분하세요. 문제 해결 중 옵션을 끄면 직접 연결이 다시 허용될 수 있다는 점을 이해한 뒤 테스트 후 원래대로 복구하세요. 앱별 프록시를 사용한다면 허용 목록과 제외 목록도 확인해야 합니다. 대상 앱이 제외돼 있으면 다른 앱이 프록시를 사용해도 자동으로 프록시에 연결되지 않습니다.

iOS에서 VPN 세션과 앱별 규칙 확인하기

iOS에서는 clashplus.io를 공식 사이트로 하는 추천 클라이언트 Clash Plus를 App Store의 Clash Plus 페이지에서 설치할 수 있습니다. 연결할 때 시스템에서 요청하는 VPN 구성 권한을 허용한 뒤 앱으로 돌아와 현재 설정과 정책을 확인하세요. 연결 스위치가 저절로 꺼지면 다른 VPN이나 기기 구성 프로파일이 네트워크를 관리하는지 먼저 확인하세요. 앱을 반복해서 재설치하는 것은 첫 번째 해결 방법이 아닙니다.

Safari나 특정 앱에서만 다르게 작동한다면 앱의 네트워크 설정, 캐시와 접속 경로에 영향을 줄 수 있는 개인정보 보호 기능을 확인하세요. iCloud 비공개 릴레이, 별도 DNS 설정 또는 다른 네트워크 확장 프로그램 때문에 예상과 다른 출구가 표시될 수 있습니다. 출구 조회 페이지의 위치 정보만으로 프록시가 작동하지 않는다고 판단하지 마세요. 클라이언트 연결 기록에서 도메인과 정책을 확인한 뒤 필요하면 기능 하나만 잠시 끄고 비교하세요. 매번 한 가지 설정만 변경하고 원래 값을 보관하세요.

Wi-Fi·모바일 데이터·절전 모드 전환 확인하기

Wi-Fi에서 모바일 데이터로 전환하면 IP 주소와 라우팅이 바뀌면서 기존 연결이 끊길 수 있습니다. 진행 중인 다운로드나 통화를 멈춘 뒤 새로 연결해 보세요. 그래도 실패하면 앱에서 연결을 끊었다가 VPN을 다시 연결합니다. 네트워크에 웹 로그인 절차가 필요하다면 먼저 인증을 완료한 뒤 프록시를 시작하세요. 인증 페이지가 열리지 않는다고 바로 노드 문제로 판단하지 마세요. 호텔, 공항과 학교 네트워크에서는 VPN 때문에 로컬 인증 페이지에 연결하지 못할 수 있습니다.

클라이언트가 모바일 데이터를 사용할 수 있는지, 현재 네트워크에 데이터 절약이나 백그라운드 제한이 적용됐는지 확인하세요. Wi-Fi에서는 정상인데 모바일 데이터에서 실패한다면 같은 설정과 대상을 사용해 비교하고 두 네트워크에서 노드 도메인을 조회하고 연결할 수 있는지 살펴보세요. 네트워크에 따라 IPv6, UDP 또는 경로 MTU 동작이 다를 수 있으므로 데스크톱 설정을 그대로 복사하지 마세요. 같은 노드에서 다른 전송 방식을 비교하고 필요하면 네트워크 유형과 오류 발생 시간을 서비스 제공자에게 전달하세요.

모바일에서 구독을 다시 가져온 뒤에는 새 설정이 선택됐는지 확인하세요. VPN 세션이 이전 설정을 계속 사용하고 있을 수 있습니다. 시스템 상태는 정상인데 특정 앱만 연결되지 않는다면 규칙과 앱별 설정을 다시 살펴보고 시스템 권한을 계속 확대하지 마세요. 평소 모드 선택은 규칙 모드와 전역 모드 가이드에서, 일반적인 사용 시 주의 사항은 고객센터의 사용 팁에서 확인하세요. 나중에 시스템을 업그레이드하거나 기기를 바꿀 때 참고할 수 있도록 최종 권한, 모드와 네트워크 조건을 기록해 두세요.