Clash 문제 해결 가이드

인터넷 연결 안 됨: 기본 네트워크와 프록시 경로 구분하기

프록시를 끈 상태에서 네트워크 확인하기

모든 웹페이지가 열리지 않는다면 노드를 계속 바꾸기보다 현재 연결부터 끊으세요. 클라이언트의 시스템 프록시와 TUN을 끄고 운영체제의 프록시 설정이 원래대로 돌아왔는지 확인하세요. 클라이언트가 비정상 종료됐다면 화면에서 스위치가 사라졌더라도 시스템 프록시가 해제되지 않았을 수 있습니다. 브라우저에서 별도의 프록시 확장 프로그램을 사용하지 않는지 확인한 뒤, 평소 프록시 없이 접속할 수 있는 사이트를 열어 보세요. 무선 네트워크에 웹 로그인이 필요한지도 확인하세요.

프록시를 꺼도 연결되지 않으면 라우터, 네트워크 인증, IP 주소 할당, 다른 VPN의 잔여 설정부터 점검하세요. 클라이언트 설정은 그대로 둔 채 같은 기기에서 휴대폰 핫스팟으로 바꿔 접속해 볼 수 있습니다. 핫스팟에서는 정상이고 기존 네트워크에서만 문제가 생기면 원인은 기존 네트워크 환경에 있을 가능성이 큽니다. 네트워크 아이콘에 연결됨으로 표시된다고 인터넷까지 되는 것은 아닙니다. 보통은 기기가 로컬 네트워크에 접속했다는 뜻입니다.

명시적 프록시 요청으로 문제 발생 단계 구분하기

기본 네트워크가 정상이라면 코어를 실행하고 TUN을 잠시 끈 뒤 로컬 프록시 연결 지점 하나만 사용하세요. 아래 예시에서는 혼합 포트가 실제로 7890이라고 가정합니다. Windows에서는 일부 PowerShell 환경에서 curl이 다른 명령으로 해석될 수 있으므로 curl.exe를 사용하세요. macOS와 Linux에서는 curl을 사용할 수 있습니다. 명령에 지정하는 포트는 클라이언트 실행 설정과 일치해야 합니다.

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

연결이 거부되면 해당 포트에서 수신 대기 중인 프로세스가 없거나 클라이언트 코어 시작에 실패했을 가능성이 큽니다. 로컬 프록시 연결은 성공했지만 이후 상위 연결 오류가 발생했다면 노드 항목을 확인하세요. 대상 서버에서 HTTP 응답을 받았다면 상태 코드가 접근 거부더라도 요청이 원격 서버까지 도달한 것입니다. 이를 단순히 로컬 프록시가 작동하지 않는 문제로 볼 수는 없습니다. 이 테스트는 해당 주소에 보낸 한 번의 요청만 확인하므로 모든 사이트가 정상이라는 뜻은 아닙니다.

연결 기록에서 연결 지점과 출구 확인하기

클라이언트의 연결 페이지를 열고 필터를 지운 다음 브라우저에서 페이지를 새로고침하세요. 새 연결이 기록되지 않으면 앱이 실제로 프록시를 사용하는지, 우회 목록에 걸렸는지, 로컬 포트를 잘못 입력했는지 확인하세요. 연결이 기록됐다면 대상 도메인, 일치한 규칙, 정책 그룹, 최종 출구 순으로 살펴보세요. 정책 그룹은 중간 선택 단계일 뿐입니다. 요청이 최종적으로 어디로 전송되는지 확인하려면 실제 노드까지 펼쳐 봐야 합니다.

규칙 모드에서 일부 사이트만 접속되지 않는다면 규칙 매칭, DNS 또는 사이트 자체의 문제일 수 있습니다. 전체 모드로 잠시 전환해 테스트할 때는 전체 모드의 정책 그룹에서 사용 가능한 출구를 선택했는지 확인하세요. 여전히 직접 연결로 설정되어 있으면 안 됩니다. 전체 모드에서는 정상이고 규칙 모드에서만 실패한다면 두 요청의 매칭 결과를 비교하고 해당 규칙을 수정한 뒤 규칙 모드로 돌아가세요. 세 가지 모드의 트래픽 차이는 규칙·전체·직접 연결 모드 비교를 참고하세요.

복구할 때 여러 연결 방식을 한꺼번에 적용하지 않기

시스템 프록시, 앱 내 프록시, TUN을 함께 사용한다고 반드시 문제가 생기는 것은 아니지만 원인을 찾기는 어려워집니다. 먼저 연결 방식 하나만으로 정상 작동하는 기준을 만든 다음 설정을 하나씩 복구하세요. 특히 노드 도메인 연결이 다른 VPN에 다시 넘겨지거나 상위 프록시가 동일한 로컬 포트를 가리키지 않도록 하세요. 요청이 순환 전달되면 로그에 연결 기록만 반복해서 쌓이고 대상 사이트의 응답은 오지 않을 수 있습니다.

마지막으로 서로 다른 사이트 두 곳을 브라우저와 명령줄에서 각각 테스트하세요. 한 사이트만 실패한다면 전역 네트워크 설정 변경을 멈추고 해당 사이트의 규칙, 인증서, 계정 제한, 서비스 상태를 확인하세요. 클라이언트를 종료한 뒤 네트워크가 다시 끊기면 시스템이 여전히 로컬 프록시를 가리키는지 확인하세요. TUN을 다시 켰을 때만 문제가 재현된다면 구독을 다시 가져오기보다 라우팅, DNS 가로채기, 권한을 점검하세요.

노드 시간 초과: DNS 조회·연결·핸드셰이크 확인

어느 단계에서 시간 초과가 발생하는지 먼저 확인하기

노드 시간 초과는 원인이 하나가 아닙니다. 서버 도메인을 조회하지 못했을 수도 있고, IP 주소를 찾았지만 전송 연결을 맺지 못했을 수도 있습니다. 연결은 됐지만 암호화 핸드셰이크에서 실패했을 수도 있습니다. 먼저 노드 하나를 직접 선택해 자동 전환의 영향을 없애고 실제 접속을 시도한 뒤 같은 시간대의 로그를 확인하세요. 속도 테스트 목록에서만 실패하고 실제 웹페이지는 열린다면 노드가 고장 났다고 단정할 수 없습니다.

로그에 도메인 조회 실패가 표시되면 먼저 노드 서버 자체의 DNS를 확인하세요. 연결 거부는 포트에 서비스가 없거나 연결이 명시적으로 차단된 경우가 많습니다. 연결 시간 초과는 네트워크에서 패킷이 버려졌거나 방화벽이 차단했거나 서비스에 도달할 수 없는 상황일 수 있습니다. 인증서 검증, 인증 실패, 프로토콜 미지원은 다른 단계의 문제입니다. 오류 유형 전체를 보존하세요. 끝부분의 timeout만 잘라내면 원인을 찾을 단서가 사라집니다.

서버 포트 확인하기: 포트 탐색 결과를 결론으로 여기지 않기

노드 주소와 포트는 본인의 유효한 설정에서 확인하세요. 공개 조회 사이트에 입력하지 마세요. Windows PowerShell에서는 아래 대화형 명령으로 주소와 포트를 입력할 수 있습니다. 입력한 값은 웹페이지 예시로 저장되지 않습니다. 이 명령은 TCP 연결만 테스트하며 프록시 프로토콜, 계정, TLS, UDP 서비스는 확인하지 않습니다. 명백한 TCP 연결 불가 문제를 먼저 배제할 때 사용하세요.

$server = Read-Host "노드 서버 도메인 또는 주소 입력"
$port = [int](Read-Host "노드 포트 입력")
Test-NetConnection -ComputerName $server -Port $port

UDP 기반 프로토콜은 TCP 테스트 결과만으로 정상 여부를 판단할 수 없습니다. TCP 연결 테스트에 성공해도 엉뚱한 서비스에 연결됐을 수 있습니다. 반대로 서버가 ICMP를 차단할 수도 있으므로 ping이 되지 않는다고 프록시 포트를 사용할 수 없는 것은 아닙니다. 노드 도메인이 여러 IP 주소를 반환한다면 클라이언트가 실제로 어느 주소에 연결했는지도 확인하세요. IPv4와 IPv6의 연결 가능 여부는 다를 수 있으며 다른 기기에서 성공했다고 같은 경로를 이용했다는 뜻은 아닙니다.

프로토콜에 맞게 인증 정보와 시간 확인하기

구독을 업데이트한 직후 일부 노드에서 문제가 생겼다면 다운로드 성공 여부만 보지 말고 현재 설정에 실제 적용됐는지 확인하세요. 비밀번호, 사용자 ID, 암호화 방식, 전송 방식, TLS 설정은 서버 측 정보와 일치해야 합니다. 인터넷 글을 보고 필드를 임의로 바꾸거나 한 프로토콜의 필드를 다른 프로토콜에 복사하지 마세요. 클라이언트가 설정을 가져왔다는 것은 파일 구조를 받아들였다는 뜻일 뿐, 서버가 인증 정보를 인정한다는 뜻은 아닙니다.

시스템 날짜, 시간대, 시간 동기화에 문제가 있으면 인증서가 아직 유효하지 않거나 만료됐다는 오류가 발생할 수 있습니다. 자동 시간 설정을 복구한 뒤 연결을 다시 시도하세요. 인증서 검증을 꺼서 문제를 장기간 우회하지 마세요. 도메인, 인증서, 중간 네트워크 문제를 가릴 수 있습니다. 설정의 서버 도메인과 TLS 서비스 이름은 다를 수 있으므로 변경 가능 여부는 서비스 제공업체 안내를 따르세요. IP 주소로 바꾸면 기존 핸드셰이크 조건이 깨질 수도 있습니다.

교차 테스트로 문제 범위 좁히기

같은 노드에서 네트워크 변경, 같은 네트워크에서 노드 변경, 같은 설정으로 지원되는 클라이언트 변경 순서로 테스트하세요. 매번 조건 하나만 바꾸세요. 기존 네트워크에서는 모두 실패하고 핫스팟에서는 정상이라면 네트워크 출구 제한, UDP 사용 가능 여부, IPv6 경로를 중점적으로 확인하세요. 어떤 환경에서든 노드 하나만 실패하면 서비스 제공업체에 먼저 문의하세요. 한 기기에서 모든 노드가 실패하지만 다른 기기에서는 정상이라면 해당 기기의 보안 소프트웨어, 시간, 코어 호환성을 점검하세요.

자동 선택 정책 그룹은 상태 검사 결과에 따라 노드를 일시적으로 제외할 수 있습니다. 상태 검사 주소가 실제 사용 목적에 적합한지 확인한 다음 요청이 어디로 전달되는지 살펴보세요. 검사 주소 자체가 차단되면 정상 노드 여러 개가 한꺼번에 비정상으로 표시될 수 있습니다. 복구를 위해 검사 간격을 지나치게 짧게 설정하지 마세요. 잦은 검사는 요청량만 늘릴 뿐 서버 문제를 해결하지 못합니다. 노드가 실제로 작동하는 것을 확인한 뒤 자동 선택으로 되돌리세요.

구독 오류: 다운로드·파싱·적용 단계 구분하기

가져오기와 파싱 중 어디서 실패했는지 먼저 확인하기

구독을 가져오는 과정은 원격 콘텐츠 다운로드, 형식 파싱, 실행 설정 생성, 설정 적용 단계로 나뉩니다. 다운로드 실패가 표시되면 HTTP 상태 코드나 연결 오류를 확인하세요. 설정 형식 오류가 표시된다면 적어도 콘텐츠 일부를 가져온 것이므로 응답 내용을 점검하세요. 업데이트 성공으로 표시됐는데 노드가 없다면 현재 활성화된 설정이 무엇인지 확인하세요. 서로 다른 문제를 새로고침만 반복해 해결하려고 하지 마세요.

복사한 내용이 서비스 사이트 홈페이지, 결제 페이지, 브라우저 공유 주소가 아니라 전체 구독 링크인지 확인하세요. 복사 중 들어간 줄바꿈, 앞뒤 공백, 메신저에서 잘린 쿼리 매개변수도 요청을 바꿀 수 있습니다. 구독 주소에는 보통 접근 권한이 포함되므로 민감 정보로 취급해야 합니다. 화면 공유 중에는 주소를 표시하지 말고 온라인 변환기, 공개 문의 게시판, 검색 엔진에 붙여넣지 마세요. 유출됐다면 서비스 측에서 링크를 재설정하세요.

응답 내용에 따라 가져오기 오류 확인하기

상태 코드는 문제를 좁히는 단서일 뿐 최종 원인을 알려주지는 않습니다. 예를 들어 접근 제어 페이지가 정상 상태 코드를 반환해도 본문에는 로그인 안내가 들어 있을 수 있습니다. 브라우저에서 링크가 열린다고 클라이언트에서도 가져올 수 있는 것은 아닙니다. 브라우저는 이미 로그인했거나 별도의 프록시를 사용하거나 필요한 쿠키를 저장했을 수 있습니다. 브라우저 세션 정보를 설정 파일에 복사하려 하지 말고 서비스 제공업체가 공식 지원하는 클라이언트 구독 기능을 우선 사용하세요.

YAML과 구독 형식의 호환성 확인하기

Clash 설정 파일, 노드 목록, 다른 클라이언트의 구독 형식은 서로 다릅니다. 인코딩된 노드 링크 목록만으로는 완전한 YAML 설정을 바로 실행할 수 없을 수 있습니다. 전체 설정에는 정책 그룹, 규칙, DNS가 포함될 수 있으며 클라이언트가 템플릿으로 부족한 부분을 보완하기도 합니다. 가져오기 메뉴에서 완전한 설정 파일을 요구하는지 노드 제공자를 요구하는지 먼저 확인하세요. 확장자만 바꿔 형식을 변환하지 마세요.

YAML에서 흔히 발생하는 오류로는 탭을 사용한 들여쓰기, 잘못된 목록 계층, 닫히지 않은 따옴표, 최상위 필드의 중복 정의가 있습니다. 오류 줄만 보지 말고 바로 앞줄도 함께 확인하세요. 파서가 오류를 발견한 위치가 실제로 처음 잘못 입력한 위치와 다를 수 있습니다. mihomo 로컬 설정은 해당 코어의 검사 명령을 사용할 수 있습니다. 여기서 config.yaml은 현재 디렉터리에서 검사할 파일을 뜻합니다. 실행 전에 유일한 백업 파일이 아닌지 확인하세요.

mihomo -t -f config.yaml

검사를 통과했다는 것은 설정 구조와 관련 참조를 코어가 받아들일 수 있다는 뜻입니다. 노드 계정이 유효하거나 모든 규칙 리소스가 실시간으로 업데이트된다는 보장은 없습니다. 알 수 없는 필드나 지원되지 않는 프록시 유형이 표시되면 클라이언트 이름만 보지 말고 포함된 코어를 확인하세요. 교체가 필요하면 다운로드 페이지에서 운영체제에 맞는 유지 관리 중인 클라이언트를 선택하고 기존 설정을 비교용으로 보관하세요.

업데이트 후 실제 적용 결과 확인하기

구독을 업데이트한 뒤 설정 목록에서 올바른 설정이 활성화돼 있는지 확인하고 정책 그룹이 이전 노드 이름을 참조하고 있지는 않은지 살펴보세요. 서버에서 노드 이름을 바꾸면 수동 선택이 작동하지 않을 수 있습니다. 로컬 재정의 설정이 이전 규칙을 남기거나 새 DNS 설정을 덮어쓸 수도 있습니다. 백업한 다음 재정의 설정을 잠시 비활성화해 비교하고, 구독 자체와 로컬 병합 과정 중 어느 쪽에서 문제가 생기는지 확인한 뒤 해당 단계만 수정하세요.

여러 기기에서 구독을 함께 사용하더라도 클라이언트마다 업데이트 주기, 캐시, 템플릿이 다를 수 있습니다. 컴퓨터에서 업데이트됐다고 휴대폰에도 같은 내용이 적용된 것은 아닙니다. 노드 이름과 설정 업데이트 시각을 비교하되 구독 링크를 공개하지 마세요. 동기화 범위는 컴퓨터와 휴대폰에서 설정을 함께 사용하는 방법을 참고하세요. 자동 업데이트가 정상으로 돌아온 뒤에는 직접 재시도하는 횟수를 줄여 요청 제한으로 다시 문제가 생기지 않게 하세요.

마지막으로 구독을 가져올 때 현재 사용할 수 없는 프록시에 의존하는지 확인하세요. 클라이언트에서 업데이트 경로를 선택할 수 있다면 기본 네트워크가 정상인 상태에서 직접 연결과 현재 사용 가능한 출구를 비교해 보세요. 사용 가능한 노드가 하나도 없는데 실패한 프록시를 통해 모든 구독 요청을 보내도록 강제하지 마세요. 서비스 제공업체가 특정 접속 방식을 지정했다면 그 안내를 따르고, 출처를 알 수 없는 변환 서비스를 함께 사용하지 마세요.

속도 저하: 첫 바이트·전송 속도·안정성을 나눠 확인하기

어떤 작업에서 느린지 구체적으로 확인하기

웹페이지가 표시되기까지 오래 걸리는 문제, 다운로드 시작 후 속도가 낮은 문제, 동영상 재생 중 버퍼링이 반복되는 문제는 각각 DNS 조회와 핸드셰이크, 지속적인 데이터 전송 속도, 연결 품질 변동과 관련될 수 있습니다. 먼저 어느 단계에서 느려지는지 기록한 뒤 적절한 방법으로 테스트하세요. 클라이언트 목록의 노드 지연 시간은 대개 짧은 요청을 기준으로 합니다. 대용량 파일 다운로드 속도와 같지 않으며 특정 동영상 사이트나 코드 저장소의 체감 속도를 직접 보여주지도 않습니다.

평소 사용하는 대상을 하나 선택하고 비슷한 시간대에 직접 연결, 고정된 프록시 출구, 다른 네트워크를 비교하세요. 여러 속도 테스트를 동시에 실행하면 테스트 자체가 대역폭을 점유합니다. 클라우드 드라이브 동기화, 시스템 다운로드 등 백그라운드 작업을 멈추고 무선 신호도 확인하세요. 라우터 연결은 정상이더라도 무선 간섭이 심하면 속도가 느릴 수 있습니다. 유선으로 연결하거나 액세스 포인트 가까이에서 테스트해 비교하세요.

전체 소요 시간만 보지 말고 단계별 시간을 확인하기

아래 명령은 로컬 HTTP 프록시를 통해 요청을 보내고 연결, 핸드셰이크, 첫 바이트, 전체 소요 시간을 출력합니다. 각 값은 curl이 기록한 누적 시간 지점이므로 서로 더하면 안 됩니다. HTTP 프록시를 통해 HTTPS 터널을 만들 때는 일부 시간에 프록시 협상 과정이 포함됩니다. 원격 도메인 조회 시간도 로컬 조회 시간에 반영되지 않을 수 있습니다. 따라서 같은 조건끼리 비교하는 데는 적합하지만 DNS 서비스 성능을 단독으로 판정하기에는 적합하지 않습니다.

curl.exe -o NUL -sS --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 -w "connect=%{time_connect}\ntls=%{time_appconnect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n" https://example.com/

macOS와 Linux에서는 curl.exe를 curl로 바꾸고 출력 파일 NUL은 /dev/null로 바꾸세요. 작은 페이지 테스트는 연결 과정을 확인하는 용도이며 최대 대역폭을 측정하기에는 적합하지 않습니다. 지속 다운로드 속도를 비교하려면 신뢰할 수 있고 테스트를 허용하는 파일 제공처를 선택하고 파일과 시간대를 동일하게 유지하세요. 대상 서버의 속도 제한도 고려해야 합니다. 특정 사이트 하나의 제한 속도를 전체 프록시 네트워크의 한계로 여기지 마세요.

정책 그룹 전환과 연결 재사용 확인하기

자동 선택 그룹은 출구를 자주 바꿀 수 있지만 이미 맺어진 연결은 기존 노드를 계속 사용할 수 있습니다. 노드를 바꾼 직후 새로고침해도 브라우저가 이전 연결을 재사용해 화면의 선택과 다른 결과가 나올 수 있습니다. 대상 페이지를 닫고 해당 연결을 종료한 뒤 다시 테스트하세요. 모든 연결을 일괄 종료하는 방법은 다운로드, 회의, 진행 중인 작업을 중단하므로 일반적인 해결 방법으로 사용하지 마세요.

같은 지역 이름을 사용한다고 동일한 경로라는 뜻은 아니며 거리가 가까워도 통신사 간 품질이 좋다고 보장할 수 없습니다. 비교할 때는 정책 그룹 이름만 고정하지 말고 최종 노드까지 동일하게 지정하세요. 특정 출구에서만 서비스가 느리다면 지역 제한, 혼잡, 서버 응답을 확인하세요. 같은 네트워크에서 여러 출구가 모두 느리고 휴대폰 핫스팟에서는 정상이라면 분기 규칙을 계속 추가하기보다 로컬 네트워크, 통신사 경로, 다른 터널 소프트웨어를 먼저 점검하세요.

UDP·MTU·리소스 사용량을 신중하게 점검하기

일부 앱은 QUIC 같은 UDP 전송을 사용하므로 프록시 경로의 UDP 지원 여부가 사용 경험에 영향을 줄 수 있습니다. 비교를 위해 브라우저의 관련 실험 기능을 잠시 끌 수 있지만 프로토콜을 영구적으로 비활성화하는 방법을 일반적인 최적화로 삼지는 마세요. TCP는 정상인데 UDP 앱만 불안정하다면 노드 프로토콜, 클라이언트 설정, 현재 네트워크에서 UDP를 허용하는지 먼저 확인한 다음 필요한 부분에만 규칙이나 앱 설정을 조정하세요.

TUN 환경에서 작은 웹 요청은 정상인데 대용량 전송이 멈춘다면 경로 MTU와 관련 있을 수 있지만 이 현상만으로 원인을 확정할 수는 없습니다. 서버 속도 제한과 패킷 손실부터 확인하고 설정을 백업한 뒤 클라이언트가 지원하는 범위에서 한 번에 하나의 값만 바꿔 테스트하세요. MTU를 무작정 아주 작게 설정하면 패킷 수가 늘고 전송 속도가 떨어질 수 있습니다. 기업 네트워크나 여러 터널이 겹친 환경에서는 네트워크 관리자와 함께 확인하세요.

속도가 느려지면서 CPU 사용량이 크게 늘었다면 상세 로그, 잦은 상태 검사, 여러 설정 업데이트 작업을 동시에 실행했는지 확인하세요. 연결 수가 계속 늘어나는 원인은 앱의 반복 재시도일 수도 있습니다. 추가 작업을 잠시 멈춘 뒤 앱 하나만 사용해 다시 테스트하세요. 원인이 원격 서비스나 상위 네트워크에 있다면 로컬 DNS를 계속 바꾸지 마세요. DNS 설정은 이미 맺어진 연결의 지속 전송 속도를 높이지 못합니다.

DNS 이상: 조회 경로와 Fake-IP 확인하기

기기 자체 조회와 프록시 내부 조회를 먼저 구분하기

브라우저에서 도메인 오류가 발생하면 운영체제 DNS 확인자, 브라우저 보안 DNS, 클라이언트 DNS, 노드 서버의 조회 경로 중 하나 이상이 원인일 수 있습니다. 먼저 조회에 실패한 도메인이 대상 사이트인지 노드 서버인지 확인하세요. 노드 도메인을 조회할 수 없다면 아직 상위 서버에 연결하지 못한 것입니다. 대상 도메인에서 문제가 생겼다면 프록시 연결 지점과 DNS 모드를 함께 확인하세요. 모든 조회 요청을 같은 공용 DNS 주소로 무조건 보내지 마세요.

명시적 HTTP 프록시나 원격 DNS 조회 방식의 SOCKS를 사용하면 대상 도메인 조회를 프록시 서버에서 처리할 수 있습니다. 따라서 시스템 명령의 조회는 실패하지만 브라우저의 프록시 접속은 성공할 수 있습니다. 반대로 시스템에서 조회가 성공해도 클라이언트 내부 DNS가 정상이라는 뜻은 아닙니다. 요청이 이동하는 경로를 먼저 정리하고 해당 연결 지점으로 테스트하세요. 시스템 DNS 결과만으로 클라이언트 내부 DNS를 판단하지 마세요.

Fake-IP 응답 이해하기

Fake-IP 모드는 도메인에 매핑 주소를 할당하고 코어가 이 주소를 원래 도메인으로 되돌려 연결을 처리합니다. 예약된 주소 대역이 보인다고 곧바로 DNS 조작을 의심할 필요는 없습니다. 먼저 해당 주소가 클라이언트 설정의 Fake-IP 범위에 속하는지 확인하세요. 앱이 이 주소를 캐시한 뒤 코어를 거치지 않고 직접 연결하면 실패할 수 있습니다. 모드를 바꾼 뒤에는 연결을 새로 만들고 필요하면 영향을 받은 앱을 다시 시작하세요.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  nameserver:
    - https://dns.alidns.com/dns-query

이 설정 조각은 필드 간 관계를 설명하기 위한 예시입니다. 기존 설정의 dns 블록 하나에 병합하고 구독 설정 전체를 덮어쓰지 마세요. 상위 DNS 주소는 예시일 뿐이므로 현재 네트워크에서 접속 가능한지 확인해야 합니다. 도메인 형식의 암호화 DNS 상위 서버를 사용하려면 해당 서버 도메인도 조회할 수 있어야 합니다. 초기 조회 방식은 사용하는 코어 문서를 따르세요. 회사 내부 도메인은 보통 내부 DNS가 필요하므로 전부 공용 서비스로 보내면 안 됩니다.

문제가 있는 특정 도메인에 예외 설정하기

로컬 네트워크 기기 검색, 일부 게임, 실제 DNS 응답 확인이 필요한 앱은 Fake-IP와 맞지 않을 수 있습니다. 먼저 실패하는 도메인을 찾아 fake-ip-filter에 추가해 결과를 비교하세요. 필터에 등록하면 실제 주소가 반환되지만 최종 트래픽이 직접 연결되는지는 규칙에 따라 달라집니다. 필터 목록은 직접 연결 목록이 아닙니다. 모든 도메인을 필터에 넣으면 이 모드의 주요 장점을 잃고 기존 트래픽 분기 동작도 달라질 수 있습니다.

브라우저에서 자체 암호화 DNS를 사용하면 예상한 로컬 DNS 경로를 우회할 수 있습니다. 진단 중에는 일시적으로 시스템 DNS 경로를 사용해 문제가 달라지는지 확인한 뒤 어떤 방식을 유지할지 결정하세요. TUN이 DNS를 가로채더라도 모든 암호화 조회를 투명하게 인식하는 것은 아닙니다. 특히 앱에 내장된 HTTPS 조회는 예외일 수 있습니다. 주소 매핑 방식은 Fake-IP와 필터 목록 안내에서 자세히 확인하세요.

조회 경로에 맞게 캐시를 지우고 IPv6 확인하기

먼저 설정이 적용됐는지 확인한 다음 문제가 있는 단계의 캐시를 지우세요. 설정이 적용되지 않은 상태라면 캐시를 지워도 잠시 달라졌다가 문제가 반복됩니다. Windows에서는 아래 시스템 캐시 정리 명령을 실행할 수 있습니다. 브라우저, 앱, 클라이언트에도 별도 캐시가 있을 수 있으므로 각 프로그램의 메뉴에서 정리하세요. macOS와 Linux의 캐시 방식은 시스템 서비스에 따라 달라지므로 같은 명령을 반복해서 실행하면 안 됩니다.

ipconfig /flushdns

같은 도메인에서 IPv4와 IPv6 주소가 모두 반환되면 앱이 현재 연결할 수 없는 주소 체계를 먼저 시도할 수 있습니다. 시스템의 IPv6 경로, 노드 출구, 클라이언트 DNS 설정을 확인하고 기기 전체의 IPv6를 바로 끄지 마세요. 통제된 테스트에서 주소 체계별 접속을 비교하고 실제로 원인이 확인된 경우 클라이언트가 지원하는 옵션을 조정하세요. DNS 응답 순서를 바꾼 뒤에는 결과를 확인할 수 있도록 연결을 새로 맺어야 합니다.

내부 도메인만 실패한다면 검색 접미사, 내부 DNS 주소, 접속 네트워크가 올바른지 확인하세요. 회사 VPN에 연결하면 도메인별 DNS 설정이 추가될 수 있는데 프록시 클라이언트의 일반 DNS 덮어쓰기가 이를 방해할 수 있습니다. 기업 정책은 유지하면서 내부 도메인의 DNS 조회와 라우팅 범위를 따로 설정하세요. 점검을 마칠 때는 공용 사이트, 로컬 네트워크 기기, 업무 서비스가 모두 접속되는지 확인해 외부 네트워크를 고치다 사내망이 끊기는 일이 없도록 하세요.

시스템 프록시 오류: 앱 연결 지점과 TUN 라우팅 확인하기

앱이 시스템 프록시를 사용하는지 확인하기

시스템 프록시 스위치는 운영체제에서 제공하는 프록시 설정을 바꿀 뿐 모든 프로그램이 프록시를 사용하도록 강제하지는 않습니다. 브라우저는 대체로 이 설정을 읽지만 명령줄 도구, 게임, 컨테이너, 일부 데스크톱 앱은 별도의 네트워크 스택을 사용할 수 있습니다. 연결 지점이 작동하는지 판단할 때는 클라이언트 연결 기록을 확인하세요. 앱에서 연결 기록이 전혀 생기지 않는다면 출구 규칙을 조정하기보다 해당 앱의 프록시 지원 방식부터 살펴보세요.

Windows의 사용자 프록시와 WinHTTP 설정은 별개의 연결 지점이므로 일부 서비스는 사용자 인터페이스의 프록시 설정을 따르지 않습니다. macOS는 네트워크 서비스별로 프록시 설정을 저장하므로 유선과 무선 연결을 바꾼 뒤 현재 서비스의 설정을 확인하세요. Linux에서는 데스크톱 프록시, 환경 변수, 앱 내부 설정도 서로 다를 수 있습니다. 한 앱을 작동시키기 위해 모든 연결 지점에 같은 값을 입력하지 말고 해당 앱이 실제로 어떤 설정을 읽는지 확인하세요.

포트·환경 변수·우회 목록 확인하기

클라이언트의 혼합 포트를 바꿔도 앱 내부 프록시와 터미널 변수는 이전 포트를 계속 가리킬 수 있습니다. 현재 실행 설정에서 실제 포트를 확인한 다음 로컬에서 수신 중인지 점검하세요. 아래는 Windows와 Linux에서 사용하는 확인 명령입니다. 포트가 사용 중이라면 해당 프로세스를 확인하고 모든 수신 프로세스를 무작정 종료하지 마세요.

# Windows PowerShell
Get-NetTCPConnection -LocalPort 7890 -State Listen

# Linux
ss -lntp 'sport = :7890'

터미널의 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY는 도구마다 영향을 줄 수 있지만 지원 방식은 통일돼 있지 않습니다. 변수 값을 확인할 때 인증 정보가 포함돼 있을 수 있다는 점에 유의하세요. 현재 터미널의 변수를 바꿔도 이미 실행 중인 다른 프로그램에 자동으로 반영되지 않습니다. 데스크톱 앱은 터미널 환경 변수를 상속하지 않을 수도 있습니다. 우회 목록에 대상 도메인이 포함돼 있으면 앱이 직접 연결해 클라이언트 기록에 남지 않을 수 있습니다.

TUN 사용에 필요한 권한·라우팅·제외 항목 확인하기

TUN은 가상 네트워크 인터페이스를 통해 트래픽을 가로채므로 시스템 프록시를 사용하지 않는 앱을 처리할 때 유용하지만, 적절한 시스템 권한과 라우팅 설정이 필요합니다. 먼저 클라이언트 보조 서비스가 설치됐거나 권한 승인이 완료됐는지 확인한 뒤 가상 인터페이스가 만들어지고 라우팅 정보가 실제로 적용됐는지 살펴보세요. 화면의 스위치가 켜져 있어도 로그에 권한 부족이 표시된다면 트래픽 가로채기는 완료되지 않은 것입니다. 컨테이너, 원격 데스크톱, 서버 환경에서는 잘못된 라우팅으로 관리 연결이 끊길 수 있으므로 특히 주의하세요.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

이 예시는 해당 필드를 지원하는 mihomo 환경용이며 모든 플랫폼에서 그대로 사용해야 하는 것은 아닙니다. 클라이언트가 인터페이스에서 TUN 설정을 생성하고 덮어쓸 수 있으므로 지정된 메뉴에서 수정하세요. 네트워크 인터페이스가 여러 개이거나 가상 머신, 다른 VPN이 함께 작동하면 자동으로 선택한 출구 인터페이스가 틀릴 수 있으므로 기본 라우팅을 확인해야 합니다. DNS 포트를 가로챈다고 모든 암호화 DNS 트래픽까지 가로채는 것은 아닙니다.

다른 프록시와 네트워크 전환 후 남은 설정 확인하기

브라우저 확장 프로그램, 다른 VPN, 기업 보안 소프트웨어, 프록시 클라이언트가 함께 작동하면 시스템 프록시, 가상 인터페이스, 라우팅을 서로 변경할 수 있습니다. 진단할 때는 직접 끌 수 있는 도구만 잠시 중지하고 기업 필수 정책은 유지한 채 기존 상태를 기록하세요. 시스템 프록시를 제어하는 프로그램을 하나만 남긴 뒤 다른 프로세스가 설정을 되돌리는지 확인하세요. 스위치를 반복해서 눌러 다른 프로그램과 설정을 두고 경쟁하지 마세요.

무선에서 유선으로 바꾸거나 절전 모드에서 복귀하거나 핫스팟에 연결한 뒤에는 기본 네트워크 인터페이스와 게이트웨이가 달라질 수 있습니다. 네트워크를 바꾼 뒤에만 TUN이 작동하지 않는다면 연결을 끊고 트래픽 가로채기를 다시 시작한 다음 새 연결 기록을 확인하세요. 다시 켜면 복구되는 경우에는 시스템 전체를 정기적으로 재시작하기보다 인터페이스 감지와 클라이언트 로그를 점검하세요. macOS 권한 문제는 네트워크 확장 및 키체인 설정 안내를 참고하세요.

검증할 때 시스템 프록시를 따르는 브라우저 하나와 원래 프록시를 따르지 않던 앱 하나를 각각 확인하세요. 브라우저는 정상인데 다른 앱은 실패한다면 시스템 프록시 경로는 복구됐을 수 있지만 TUN이나 앱 설정은 더 확인해야 합니다. 마지막으로 클라이언트를 종료하고 기본 네트워크가 복구되는지 테스트하세요. 프록시 주소가 해제되고 가상 라우팅이 정리된 것까지 확인해야 전체 복구가 끝난 것입니다. 신뢰할 수 없는 네트워크에 로컬 프록시 포트를 장기간 열어 두지 마세요.

시작 오류와 충돌: UI·코어·설정 문제 분리하기

어떤 프로세스가 종료됐는지 먼저 확인하기

클라이언트 창이 닫히는 것, 시스템 트레이 아이콘이 사라지는 것, 코어가 중지되는 것은 서로 다른 현상입니다. 창을 닫아도 백그라운드에서 계속 실행되는 프로그램이 있는가 하면 화면은 남아 있는데 코어가 충돌했을 수도 있습니다. 시스템 트레이, 작업 관리자 또는 시스템 모니터에서 상태를 확인한 다음 로컬 포트와 로그를 살펴보세요. 창이 보이지 않는다고 프로그램을 여러 번 실행하지 마세요. 인스턴스가 겹치면 포트, 설정 디렉터리, 보조 서비스를 서로 차지하려 해 새로운 시작 문제가 발생할 수 있습니다.

문제가 발생한 시점을 확인하세요. 실행 직후 종료된다면 환경, 권한, 설정 문제일 수 있습니다. 설정을 가져온 뒤 종료되면 콘텐츠와 리소스를 확인하세요. 한동안 실행한 뒤 종료된다면 메모리, 디스크, 로그 증가, 특정 연결이 원인일 수 있습니다. 데이터를 모두 지우기보다 마지막으로 정상 작동했던 작업과 그 이후의 변경 내용을 기록하는 편이 문제를 재현하고 원인을 찾는 데 도움이 됩니다.

시스템 아키텍처와 설치 환경 확인하기

설치 파일은 운영체제와 프로세서 아키텍처에 맞아야 합니다. Windows, macOS, Linux는 설치 방식이 다르며 파일 이름이 비슷하다고 호환되는 것은 아닙니다. macOS는 Apple Silicon과 Intel을 구분해야 합니다. Linux는 배포판의 패키지 형식, 런타임 라이브러리, 데스크톱 환경까지 고려해야 합니다. 플랫폼별 다운로드 페이지에서 Clash Plus 또는 현재 유지 관리 중인 운영체제 호환 클라이언트를 선택하세요. 오래된 가이드에 나온 설치 파일을 대신 사용하지 마세요.

보안 소프트웨어의 격리, 운영체제의 앱 제어, 파일 실행 권한 때문에 프로그램이 시작되지 않을 수도 있습니다. 먼저 시스템이 표시한 구체적인 안내와 파일 출처를 확인한 뒤 운영체제의 정상적인 절차에 따라 실행을 허용하세요. 보안 기능을 전역으로 끄거나 출처가 불분명한 사이트에서 누락된 구성 요소를 내려받지 마세요. 기업 기기의 설치 제한은 관리자에게 문의하세요. 정책을 우회하면 보조 서비스가 제대로 작동하지 않아 이후 트래픽 가로채기에도 문제가 생길 수 있습니다.

백업 후 최소 실행 환경 만들기

설정 손상을 해결하려면 클라이언트를 종료하고 데이터 디렉터리부터 백업하세요. 백업에는 구독 주소와 인증 정보가 포함될 수 있으므로 신뢰할 수 있는 로컬 위치에 보관하고 공개 저장소에 자동 동기화하지 마세요. 전체 디렉터리를 바로 삭제하기보다 클라이언트의 초기화 또는 새 설정 기능을 사용해 테스트하세요. 최소 설정으로 실행되면 구독, 규칙 리소스, 재정의 설정을 차례로 복구하고 각 단계마다 재시작해 확인하세요.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

이 최소 예시는 코어와 로컬 포트가 작동하는지 확인하기 위한 것으로 전체 트래픽을 직접 연결하며 프록시 출구는 제공하지 않습니다. 테스트 전에 포트를 사용 중인 프로세스가 없는지 확인하고 TUN을 잠시 끄세요. 이 환경이 정상 작동한다면 기존 설정의 프록시 유형, 규칙 제공자, 스크립트 재정의, 외부 리소스를 집중적으로 확인하세요. 실제 설정으로 복구하기 전에 유효한 구독으로 돌아왔는지 확인해 진단용 직접 연결 설정을 정상 상태로 착각하지 않도록 하세요.

포트 충돌과 리소스 부족 구분하기

로그에 주소가 이미 사용 중이라고 표시되면 어떤 프로세스가 포트를 열고 있는지 확인하고 이전 인스턴스, 다른 프록시, 시스템 서비스인지 파악하세요. 혼합 포트를 임시로 바꿔 테스트할 수 있지만 앱의 프록시 설정도 함께 변경해야 합니다. 제어 포트와 프록시 포트는 용도가 다르므로 화면에서 숫자 하나만 바꿨다고 모든 충돌이 해결되는 것은 아닙니다. 보조 서비스가 이전 설정을 계속 사용한다면 클라이언트 절차에 따라 서비스를 다시 시작하세요.

실행 후 점점 멈춘다면 디스크 여유 공간, 로그 파일 증가, 규칙 리소스 규모, 연결 수를 확인하세요. 디버그 로그를 계속 기록하면 디스크 쓰기 부담이 커질 수 있고 앱의 반복 재시도로 연결이 늘어날 수도 있습니다. 먼저 문제를 일으키는 앱을 중지하고 리소스 사용량이 줄어드는지 살펴보세요. 메모리 사용량이 높다는 이유만으로 누수를 단정하지 말고 사용량이 계속 늘어나는지, 회수되는지, 동일 조건에서 재현되는지 함께 확인하세요.

업데이트 후 문제가 생겼다면 업데이트 전후의 설정 변경과 시스템 안내를 기록하고 복구에 필요한 백업을 보관하세요. 클라이언트 업데이트, DNS 변경, 구독 교체를 동시에 진행하면 원인을 찾기 어렵습니다. 문제를 신고할 때 시스템 아키텍처, 클라이언트 이름, 코어 오류, 최소 재현 절차를 첨부하고 민감한 정보는 삭제하세요. 재현 조건이 명확해야 유지 관리자가 UI 문제, 코어 문제, 설정 호환성 문제를 구분할 수 있습니다.

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

Android VPN 권한과 단독 트래픽 가로채기 확인하기

Android 클라이언트는 대개 VpnService로 로컬 VPN 인터페이스를 만듭니다. 시스템 권한 승인 창은 기기의 네트워크를 가로채기 위한 단계이며 원격 VPN 서버에 연결됐다는 뜻이 아닙니다. 처음 실행할 때 권한이 승인됐는지 확인한 다음 상태 표시줄과 클라이언트의 연결 상태를 살펴보세요. 일반적인 환경에서는 한 사용자 계정에서 활성 VPN을 하나만 사용할 수 있습니다. 광고 차단기, 업무 프로필 VPN, 다른 프록시 앱이 현재 클라이언트와 충돌할 수 있습니다.

시스템의 상시 연결 VPN과 VPN 미사용 시 연결 차단 옵션은 연결이 끊긴 뒤의 동작을 바꿉니다. 차단 옵션을 켜 둔 상태에서 클라이언트가 중지될 때 기기 전체가 오프라인이 된다면 무선 네트워크 고장이 아니라 시스템 정책에 따른 동작일 수 있습니다. 진단 전에 설정을 기록한 다음 필요한 경우에만 잠시 끄세요. 회사 관리 기기의 VPN을 임의로 삭제하지 말고 개인 프록시와 함께 사용할 수 있는지, 어떤 앱이 관리 대상인지 관리자에게 확인하세요.

화면 잠금 후 연결이 끊기면 백그라운드 제한 확인하기

화면이 켜져 있을 때는 정상인데 잠금 후 시간이 지나면 연결이 끊긴다면 배터리 최적화, 백그라운드 실행, 자동 시작, 제조사의 앱 절전 기능을 먼저 확인하세요. 클라이언트를 강한 절전 제한에서 제외한 뒤 화면을 잠가 다시 테스트하세요. 알림 권한만 허용하는 것으로는 부족할 수 있으며 알림이 표시된다고 코어가 계속 실행 중이라는 뜻은 아닙니다. 화면을 다시 켠 뒤 서비스 상태와 로그 시각을 확인해 프로세스 종료, 네트워크 일시 중단, 연결 만료 중 무엇이 원인인지 구분하세요.

휴대폰의 모든 절전 기능을 한꺼번에 끄지 마세요. 먼저 클라이언트만 백그라운드에서 실행되도록 허용하고 다른 앱 설정은 그대로 둔 채 같은 시간 동안 다시 테스트하세요. 시스템마다 메뉴 이름이 다르므로 설정에서 배터리 최적화, 백그라운드 실행, 자동 시작을 검색할 수 있습니다. 구체적인 경로는 Android 백그라운드 연결 끊김과 배터리 최적화 예외 설정을 참고하세요. 특정 네트워크에서만 문제가 재현된다면 라우터 절전 설정과 무선 네트워크 절전도 확인하세요.

iOS 터널 상태와 주문형 연결 확인하기

iOS에서 Clash Plus를 사용할 때는 먼저 클라이언트에서 설정이 활성화됐는지 확인하고, 시스템 VPN 상태에서 터널이 실제로 연결됐는지 확인하세요. 처음 사용할 때 권한 승인이 완료되지 않으면 구독을 저장했더라도 트래픽을 가로채지 않습니다. 설치하거나 다시 설치해야 한다면 iOS 다운로드 페이지에서 스토어로 이동하세요. 공식 웹사이트는 clashplus.io입니다. 다시 설치하기 전에 설정을 안전하게 백업했는지 확인하세요.

주문형 연결은 네트워크 전환, 인터넷 재연결, 특정 규칙 충족 시 터널을 자동으로 만들 수 있습니다. 사용자가 직접 끈 뒤 다시 연결되더라도 반드시 프로그램 오류는 아닙니다. 주문형 설정, 시스템에 남아 있는 다른 VPN 설정, 현재 활성 항목을 먼저 확인하세요. 모든 네트워크 프로필을 반복해서 삭제하지 마세요. 터널이 연결된 상태에서 특정 앱만 실패한다면 기기 네트워크를 초기화하기보다 트래픽 분기와 DNS를 확인하세요.

무선 네트워크와 모바일 데이터 차이 구분하기

같은 노드가 무선 네트워크에서는 정상이고 모바일 데이터에서는 실패한다면 UDP, IPv6, 통신사 경로, 모바일 데이터 권한이 원인일 수 있습니다. 먼저 클라이언트가 모바일 데이터 사용을 허용하는지 확인한 뒤 같은 노드로 비교하세요. 네트워크마다 주소 변환 방식이 다를 수 있으므로 서버에 ping이 된다고 프록시 프로토콜까지 사용할 수 있는 것은 아닙니다. 네트워크를 전환할 때는 조건 하나만 바꾸고 연결이 끊긴 시각과 다시 연결하는 데 필요한 절차를 기록하세요.

공용 무선 네트워크에서는 웹페이지 인증을 먼저 해야 할 수 있습니다. 트래픽 가로채기를 시작하면 로그인 페이지가 제대로 표시되지 않을 수 있으니 프록시 연결을 잠시 끊고 네트워크 로그인 후 다시 연결하세요. 인증 페이지가 신뢰할 수 있는지는 사용 중인 네트워크를 확인해 판단하세요. 출처를 알 수 없는 페이지에 구독 주소나 프록시 계정을 입력하지 마세요. 호텔이나 학교 네트워크에서 특정 프로토콜을 제한한다면 네트워크 관리자에게 허용되는 접속 방식을 문의하고 로컬 설정을 반복해서 초기화하지 마세요.

모바일에서는 앱별 프록시 목록도 확인해야 합니다. 선택한 앱만 프록시를 사용할지, 선택한 앱을 제외할지 설정 방향을 반대로 이해하면 한 앱은 연결 기록이 남고 다른 앱은 전혀 기록되지 않을 수 있습니다. 설정을 바꾼 뒤에는 보통 터널을 다시 연결하고 대상 앱도 재시작해야 합니다. 휴대폰 핫스팟에 연결된 기기가 휴대폰 프록시를 거치는지는 운영체제와 클라이언트 기능에 따라 다릅니다. 휴대폰에서 정상 접속된다고 핫스팟에 연결한 컴퓨터도 자동으로 같은 출구를 사용하는 것은 아닙니다.

기기 간 비교 시 휴대폰과 컴퓨터가 실제로 같은 구독 내용과 최종 노드를 사용하고 있는지, 한쪽은 규칙 모드인데 다른 쪽은 전체 모드가 아닌지 확인하세요. 모바일 메뉴가 간소화됐다고 코어 동작까지 완전히 같은 것은 아닙니다. 지원하지 않는 필드는 무시되거나 화면 설정으로 덮어쓰일 수 있습니다. 익숙하지 않은 용어는 용어집에서 확인하고 작업 순서를 다시 정리하려면 입문 가이드로 돌아가 가져오기, 선택, 연결, 확인 순서에 따라 정상 작동 기준을 다시 세우세요.