Clash 문제 해결 가이드

인터넷에 연결되지 않을 때: 로컬 연결부터 원격 경로까지

먼저 문제가 발생하는 범위를 확인하세요

클라이언트 화면이 열리고 프록시 스위치가 켜져 있어도 네트워크 요청이 성공했다는 뜻은 아닙니다. 발생 시각, 네트워크 종류, 현재 설정, 오류가 난 앱을 기록한 뒤 보통 직접 접속할 수 있는 사이트와 실제로 문제가 발생한 사이트를 각각 열어 보세요. 프록시를 끄고 다시 테스트하세요. 두 사이트 모두 열리지 않으면 Wi-Fi 연결, 게이트웨이 또는 네트워크 인증부터 확인합니다. 프록시를 켰을 때만 실패한다면 로컬 포트, 규칙, 원격 출구를 중점적으로 살펴보세요.

다른 프록시 클라이언트, 브라우저 프록시 확장 프로그램, 네트워크를 가로챌 수 있는 도구를 일시적으로 종료해 두 프로그램이 시스템 설정을 덮어쓰지 않도록 하세요. 설정을 바로 삭제하거나 시스템 프록시와 TUN을 동시에 켜서 해결하려고 하지 마세요. 현재 로그를 보관하고, 한 가지 연결 방식으로 문제를 재현하세요. 회사 관리 기기에서는 관리 정책을 따르고, 충돌을 해결하려고 보안 구성 요소를 제거하지 마세요.

명시적 프록시 요청으로 시스템 설정 우회하기

클라이언트 설정에서 혼합 포트를 확인하고 커널이 실행 중인지 확인하세요. 아래 명령의 포트는 예시이므로 실제로 수신 중인 값으로 바꿔야 합니다. 프록시를 명시적으로 지정하면 브라우저가 시스템 프록시 설정을 따르는지 여부를 별도로 확인할 수 있습니다. Windows에서는 일부 터미널에서 같은 이름의 명령 별칭과 충돌하지 않도록 curl.exe를 사용하세요. 다른 플랫폼에서는 보통 curl을 사용하면 됩니다.

curl --noproxy "" --proxy http://127.0.0.1:7897 \
  --connect-timeout 10 --max-time 25 \
  -I https://example.com/

로컬 포트 연결이 즉시 거부되면 요청이 프록시 커널에 도달하지 않은 것이므로 커널 상태와 포트를 먼저 확인하세요. 원격 응답을 기다리다 시간 초과되면 로그에서 대상 주소, 적용된 규칙, 출구를 확인합니다. HTTP 응답을 받았지만 상태 코드가 성공이 아니더라도 일부 연결 경로는 성립한 것입니다. 서버의 거부, 로그인 요구, 콘텐츠 접근 제한을 단순히 로컬 프록시 장애로 볼 수는 없습니다. 위 명령은 응답 헤더만 확인합니다. 이 요청 방식을 지원하지 않는 사이트는 일반 GET 요청으로 다시 테스트하세요.

규칙 적용과 출구 연결 상태 구분하기

연결 또는 로그 화면을 열고 실패한 요청을 한 번 재현한 뒤, 도메인에 어떤 규칙이 적용됐는지, 어떤 프록시 그룹에 들어갔는지, 그룹에서 어떤 출구를 선택했는지 확인하세요. 규칙 모드에서는 대상 요청이 직접 연결되거나 차단 규칙에 걸릴 수 있습니다. 전체 모드로 잠시 전환해 비교할 수 있지만, 이는 진단용입니다. 전체 모드에서는 되는데 규칙 모드에서 실패한다면 규칙 순서와 프록시 그룹 선택을 확인하세요. 두 모드 모두 실패한다면 출구 연결을 점검하고 분할 규칙 목록을 반복해서 수정하지 마세요.

웹페이지 하나도 로그인 도메인, 정적 리소스, API 도메인에 의존할 수 있습니다. 홈페이지는 표시되는데 로그인 버튼이 계속 대기한다면 홈페이지에 규칙을 추가하기보다 실패한 하위 요청을 확인하세요. 브라우저 개발자 도구의 네트워크 탭에서 실패한 도메인을 찾고 클라이언트의 연결 기록과 대조할 수 있습니다. 화면을 공유하기 전에는 전체 URL의 쿼리 매개변수, 계정 식별자, 구독 정보를 가리세요. 오류 이름과 적용된 규칙만 남기면 됩니다.

마지막으로 같은 대상을 사용해 복구 여부를 확인하세요. 명시적 프록시 요청, 브라우저, 프록시가 필요한 다른 앱이 각각 정상 작동하는지 테스트합니다. 규칙 모드로 되돌리고 임시 디버그 로그를 끄세요. 테스트 상태를 장기 설정으로 남기지 마세요. 브라우저만 실패하고 명령은 성공한다면 시스템 프록시 섹션을 확인하세요. 로그에 이름 해석 오류가 있다면 DNS 섹션으로 이동하세요. 단계별 점검 목록은 연결은 됐지만 웹페이지가 열리지 않을 때 확인할 사항을 참고하세요.

노드 시간 초과: DNS 조회·핸드셰이크·전송을 구분하세요

오류가 발생한 단계를 확인하세요

화면의 시간 초과는 연결 확인용 URL에서 발생할 수도 있고 실제 서비스 요청에서 발생할 수도 있습니다. 둘은 서로 대체할 수 없습니다. 연결 확인에 한 번 실패했다고 출구를 전혀 사용할 수 없는 것은 아닙니다. 확인 대상이 접근을 제한하거나 확인 요청에 규칙이 적용됐을 수 있습니다. 먼저 하나의 출구와 대상을 정해 적은 횟수로 반복 요청하고, 해당 시각의 로그를 확인해 서버 도메인 DNS 조회 실패, 서버 연결 시간 초과, 프로토콜 핸드셰이크 실패, 대상 사이트 응답 지연을 구분하세요.

연결 거부는 대상 주소에서 거부 응답을 보냈거나 중간 장비가 연결을 차단했을 가능성이 큽니다. 연결 시간 초과는 정해진 시간 안에 예상한 응답을 받지 못했다는 뜻일 뿐, 서버가 종료됐다는 의미는 아닙니다. 인증 실패나 인증서 이름 불일치 등은 다른 유형의 문제이므로 시간 제한을 늘려 덮어서는 안 됩니다. 빨간색 시간 초과 표시만 캡처하기보다 오류 원문을 기록하세요.

시스템 시간과 서버 연결 정보 확인하기

자동 시간 설정을 켜고 날짜, 시간대, 실제 시간이 맞는지 확인하세요. 인증서를 사용하는 연결은 유효기간을 확인하므로 시스템 시간이 잘못되면 정상적인 설정도 핸드셰이크에 계속 실패할 수 있습니다. 그런 다음 구독 업데이트 후 서버 주소, 포트, 전송 매개변수가 로컬 설정에 의해 덮어쓰이지 않았는지 확인하세요. 노드를 복사할 때 경로, 서비스 이름, 전송 계층 설정이 빠지면 기본 연결은 성립해도 프록시 프로토콜 핸드셰이크가 완료되지 않을 수 있습니다.

서버 포트만 따로 테스트하려면 PowerShell에서 아래 명령을 사용할 수 있습니다. 예시 도메인은 명령 사용법을 설명하기 위한 것이므로 설정에 있는 서버 주소로 바꾸세요. 테스트 성공은 TCP 포트에 연결할 수 있다는 뜻일 뿐, 인증·TLS·상위 프록시 프로토콜까지 정상이라는 의미는 아닙니다. 테스트 실패 결과만으로 UDP 전용 서비스의 상태를 판단할 수도 없습니다. 테스트를 위해 전체 노드 설정을 공개하지 마세요.

Test-NetConnection -ComputerName example.com -Port 443

인증서 검증을 끄는 방법은 일반적인 해결책으로 권장하지 않습니다. 인증서 오류가 발생하면 서버 이름, 시스템 신뢰 체인, 시스템 시간, 관리형 검사 장비가 네트워크에 있는지를 확인하세요. 특정 SNI 또는 전송 경로가 필요한 설정은 추측하지 말고 서비스 제공업체에 매개변수를 확인하세요. 만료된 구독에 오래된 서버 주소가 남아 있다면 구독 업데이트로 해결될 수 있지만, 업데이트 전에 로컬 덮어쓰기 설정을 백업하세요.

비교 테스트로 로컬 네트워크 제한 확인하기

기기, 설정, 대상을 그대로 둔 채 현재 Wi-Fi를 휴대폰 핫스팟으로만 바꿔 테스트하세요. 핫스팟에서는 연결되지만 기존 네트워크에서는 안 된다면 원래 네트워크 경로, 인증 상태 또는 접근 정책으로 문제 범위를 좁힐 수 있습니다. 같은 네트워크에 연결된 다른 기기로도 비교하세요. 클라이언트와 출구를 동시에 바꾸면 변수가 너무 많아져 복구 후에도 원인을 알기 어렵습니다.

일부 네트워크는 특정 연결 방식만 허용하며 UDP가 특히 제한될 수 있습니다. 웹페이지는 TCP로 열리지만 UDP를 사용하는 앱이 실패한다면 출구 프로토콜, 커널, 원격 서비스가 해당 트래픽을 지원하는지 확인하세요. TUN은 앱의 패킷을 가로챌 수 있지만 UDP를 지원하지 않는 출구에 UDP 기능을 추가하지는 않습니다. IPv6 문제를 확인할 때는 실제 연결에 사용된 주소 계열도 비교해 한 경로의 장애를 모든 연결 경로의 장애로 오해하지 않도록 하세요.

다른 출구는 같은 조건에서 정상인데 하나의 연결 지점만 실패한다면 실패 시각, 오류 유형, 네트워크 비교 결과를 기록해 서비스 제공업체에 전달하세요. 모든 연결 지점이 실패하지만 직접 연결은 정상이라면 클라이언트 커널, DNS, 로컬 방화벽을 점검하세요. 지나치게 자주 반복해서 확인하지 말고 적절한 확인 주기로 되돌리세요. 계속해서 동시에 연결을 검사하면 로그를 파악하기 어려워지고 원격 제한이 걸려 문제가 더 복잡해질 수 있습니다.

구독 업데이트 실패: 링크·응답 내용·설정 병합 확인하기

다운로드 실패와 파싱 실패 구분하기

구독 업데이트는 요청 주소 확인, 내용 수신, 설정 파싱, 설정 적용 단계를 거칩니다. 다운로드 시간 초과는 보통 앞의 두 단계에서 발생하고, 파싱 실패는 내용을 받았지만 클라이언트가 지원하는 설정 형식이 아닌 경우에 발생할 수 있습니다. 오류가 네트워크 요청, HTTP 상태 코드, YAML 문법, 커널 설정 검증 중 어디에 해당하는지 확인하세요. 모든 오류를 링크 만료로 돌리지 마세요. 업데이트 전에 현재 정상 작동하는 설정을 내보내 마지막 유효한 사본을 보관하세요.

서비스 제공업체 계정 페이지에서 구독 링크를 다시 복사하고, 클립보드에 줄바꿈이나 앞뒤 공백, 채팅 앱이 붙인 문장부호가 섞이지 않았는지 확인하세요. 링크에는 접근 인증 정보가 들어 있는 경우가 많으므로 공개 변환 사이트, 온라인 YAML 검사기, 공개 문의 게시판에 붙여 넣지 마세요. 브라우저에서 링크가 열린다고 해서 클라이언트도 같은 프록시, 요청 헤더, 네트워크 경로를 사용했다거나 응답이 호환되는 설정이라는 뜻은 아닙니다.

응답의 실제 형식 확인하기

클라이언트에서 다운로드 오류 세부 정보를 볼 수 있다면 상태 코드와 응답 형식을 먼저 확인하세요. 웹페이지, 로그인 페이지, 접근 확인 페이지를 받으면 커널이 첫 HTML 행을 YAML로 읽으려다 문법 오류처럼 보이는 메시지를 표시할 수 있습니다. 성공 상태 코드도 올바른 내용이라는 보장은 없습니다. 서버가 성공 코드와 함께 안내 문구를 반환할 수도 있습니다. 파일 앞부분을 로컬에서 확인해 설정 구조, 노드 텍스트, 웹페이지 중 무엇인지 판단하세요. 인증 정보가 포함된 파일 전체를 올려 도움을 요청하지 마세요.

클라이언트마다 지원하는 구독 형식이 다릅니다. 다른 프로토콜이나 앱을 위해 생성된 내용을 파일 확장자만 바꿔 Clash 설정으로 사용할 수는 없습니다. 제공업체에서 Clash 또는 mihomo 호환 구독 형식을 선택한 다음 다시 가져오세요. 설정이 프록시 제공자나 규칙 제공자를 참조한다면 기본 설정을 가져온 뒤 외부 리소스도 다운로드할 수 있는지 확인해야 합니다. 기본 파일을 가져오는 데 성공해도 참조된 리소스까지 준비됐다는 뜻은 아닙니다.

YAML 및 덮어쓰기 설정 오류 찾기

직접 편집한 뒤 파싱 오류가 발생했다면 들여쓰기에 공백을 사용했는지, 같은 수준의 키가 정렬됐는지, 목록 항목 앞에 하이픈이 있는지 확인하세요. 특수 문자가 포함된 문자열은 올바르게 따옴표로 묶어야 하지만, 모든 숫자와 불리언 값에 무조건 따옴표를 붙여서는 안 됩니다. 아래는 문법을 비교하기 위한 유효한 일부 구조이며 바로 연결할 수 있는 완성 설정이 아닙니다. 실제 프록시 그룹과 출구는 구독에서 제공됩니다.

mixed-port: 7897
mode: rule
log-level: info
allow-lan: false

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

클라이언트는 구독 원문, 전역 덮어쓰기, 스크립트 처리, 화면 설정을 병합해 커널에 전달할 수 있습니다. 원본 파일의 문법이 올바르더라도 최종 설정에서 존재하지 않는 프록시 그룹을 참조하면 실패할 수 있습니다. 최근 추가한 덮어쓰기나 스크립트를 잠시 비활성화하고 원본 구독을 적용해 보세요. 문제가 해결되면 항목을 하나씩 다시 켜 충돌 원인을 찾으세요. 자동 업데이트되는 원본 파일을 직접 수정해 계속 사용하는 것은 피하세요. 다음 업데이트에서 변경 사항이 사라질 수 있습니다.

자동 업데이트가 실패한다면 앱이 백그라운드에서 실행 중인지, 기기가 절전 상태인지, 업데이트 간격의 단위가 무엇인지도 확인하세요. 클라이언트마다 분, 시간, 내부 초 단위로 값을 저장할 수 있으므로 다른 곳의 수치를 그대로 적용하지 마세요. 작동하지 않는 링크로 매우 짧은 간격의 요청을 반복하지 마세요. 먼저 수동 업데이트가 성공하는지 확인한 뒤 자동 실행 일정을 복구하세요. 설정 위치와 실패 유형은 구독 자동 업데이트 간격 안내를 참고하세요.

복구 여부를 확인할 때는 업데이트 시각만 보지 말고 대상 설정이 선택됐는지, 커널에 정상 적용됐는지, 프록시 그룹 참조가 존재하는지도 확인하세요. 서버 응답이 계속 잘못된다면 상태 코드, 오류 행 번호, 요청 시각에서 민감 정보를 가려 제공업체에 전달하세요. 형식 점검은 구독 파싱 오류 자체 점검 절차를, 기본 구독 개념은 도움말 센터를 참고하세요.

속도가 느릴 때: 연결 대기와 지속 전송 구분하기

어느 단계에서 느린지 먼저 확인하세요

웹페이지가 오랫동안 빈 화면으로 있다가 한꺼번에 나타나는 경우와 파일 다운로드가 빠르게 시작된 뒤 속도가 떨어지는 경우는 원인이 다를 수 있습니다. 전자는 DNS 조회, 연결 재시도, 핸드셰이크, 중요한 리소스 대기와 관련될 수 있습니다. 후자는 출구 용량, 패킷 손실, 원격 서버 속도 제한, 로컬 Wi-Fi 품질 문제일 수 있습니다. 모든 사이트가 느린지, 특정 사이트나 앱만 느린지 먼저 구분한 뒤 같은 대상, 파일, 네트워크로 비교하세요. 서버별 차이를 클라이언트 성능 차이로 오해하지 않도록 주의하세요.

브라우저 개발자 도구의 네트워크 타임라인을 보면 연결 대기, 첫 바이트 대기, 콘텐츠 다운로드를 구분할 수 있습니다. 통계 스크립트나 글꼴 같은 리소스 하나가 계속 대기해도 페이지 완료가 늦어질 수 있습니다. 클라이언트 로그는 출구와 규칙 정보를 제공하지만 페이지의 리소스 의존성을 보여주는 브라우저 기록을 대신하지는 않습니다. 실제로 시간이 오래 걸리는 요청을 찾고 직접 연결인지 프록시인지 확인하는 편이 전체 설정을 반복해서 바꾸는 것보다 효과적입니다.

연결 지점과 대상을 유지해 비교하기

시스템 업데이트, 클라우드 동기화 등 대역폭을 사용하는 작업을 일시 중지하고 다운로드 하나로 확인하세요. Wi-Fi가 불안정하다면 공유기 가까이에서 사용하거나 유선 네트워크와 비교해 보세요. 여러 속도 측정 도구를 동시에 실행하지 말고 한 번의 연결 확인 결과만으로 출구 순위를 정하지 마세요. 확인용 사이트의 응답 시간은 해당 요청의 경로만 보여줍니다. 대용량 다운로드 속도나 실제 서비스 체감 속도와 같지 않습니다.

명시적 프록시 요청의 단계별 시간을 확인하려면 curl로 구간별 소요 시간을 출력할 수 있습니다. 아래 명령은 일반 페이지 출력을 유지하고 끝에 시간을 표시합니다. 실제 테스트에서는 대상을 하나로 고정하세요. HTTP 프록시를 통해 HTTPS에 접속하면 일부 시간에 프록시 협상이 포함될 수 있으므로 특정 항목을 원격 서버만의 응답 시간으로 간주하지 마세요. 절대값 하나로 판단하기보다 같은 조건에서 반복 측정한 결과의 변화를 비교하세요.

curl --noproxy "" --proxy http://127.0.0.1:7897 \
  --connect-timeout 10 --max-time 30 \
  --write-out '\nconnect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n' \
  https://example.com/

직접 연결 요청도 느리다면 로컬 네트워크와 대상 사이트를 먼저 확인하세요. 특정 출구만 느리다면 같은 설정의 다른 사용 가능한 출구와 비교할 수 있습니다. 모든 출구에서 특정 사이트만 느리고 다른 사이트는 정상이라면 대상 서비스 부하, 지역별 네트워크 경로, 앱 자체 제한이 원인일 수 있습니다. 이 경우 클라이언트를 재설치할 근거는 없습니다. 나중에 다시 테스트할 수 있도록 대상, 시각, 출구 선택을 기록하세요. 단순히 속도가 느리다고만 적지 마세요.

규칙에 따른 우회 경로와 전송 방식 확인하기

직접 연결할 수 있는 리소스가 규칙에 따라 원격 출구로 전달되면 연결 거리가 길어질 수 있습니다. 반대로 프록시가 필요한 인터페이스가 직접 연결되면 재시도가 오래 걸릴 수 있습니다. 특히 세션 일관성이 필요한 로그인 서비스에서 메인 페이지와 API 도메인이 서로 다른 출구를 사용하는지 확인하세요. 명백히 잘못된 도메인 규칙만 수정하고, 정체를 모르는 주소를 광범위한 전역 우회 목록에 추가하지 마세요. 수정 후 새로 연결해야 이전 출구를 사용하는 기존 연결이 갱신됩니다.

브라우저가 UDP 기반 HTTP/3을 먼저 시도했다가 다른 연결 방식으로 전환할 수 있습니다. 출구나 네트워크가 이 경로를 지원하지 않으면 전환을 기다리는 동안 첫 접속이 간헐적으로 느려질 수 있습니다. 먼저 클라이언트, 출구 프로토콜, 네트워크 기능을 확인한 뒤 기록을 남겨 브라우저를 비교 테스트하세요. 특정 프로토콜을 끄는 방법은 원인 확인에 도움이 될 수 있지만, 모든 기기에 일괄 적용할 최적화 방법은 아닙니다.

TUN 사용 중 작은 페이지는 열리지만 큰 요청이 멈출 때에만 경로 MTU나 관련 네트워크 장비 동작을 확인하세요. 인터넷에서 찾은 MTU 값을 그대로 적용하거나 DNS, 프로토콜 스택, MTU를 동시에 바꾸지 마세요. 기존 값을 기록하고 시스템 프록시와 비교하세요. TUN에서만 문제가 재현된다면 로그와 네트워크 환경을 확인하면서 한 항목씩 조정합니다. 프록시 전달은 원래 네트워크의 패킷 손실을 없애지 않으며 가상 네트워크 어댑터가 연결 용량을 자동으로 높여 주지도 않습니다.

복구 후에는 실제로 사용하는 서비스로 확인하세요. 같은 웹페이지를 열고 같은 서비스에 로그인하며 같은 리소스를 다운로드합니다. 임시 테스트 조건을 해제하고 평소 규칙으로 되돌린 다음, 효과를 설명할 수 있고 개선이 확인된 설정만 유지하세요. 정해진 시간에만 문제가 발생한다면 클라이언트 설정을 계속 바꾸기보다 시간대를 기록하는 편이 유용합니다. 특정 앱만 이상하다면 해당 앱의 캐시, 확장 프로그램, 별도 프록시 설정도 확인하세요.

DNS 문제: 시스템·앱·커널의 이름 조회 경로 확인하기

먼저 도메인을 누가 조회하는지 확인하세요

DNS 문제는 도메인이 열리지 않거나 첫 접속이 오래 걸리거나 앱마다 같은 사이트의 결과가 다르게 나타나는 형태로 발생할 수 있습니다. 시스템 DNS, 브라우저 보안 DNS, 앱 내장 DNS, mihomo DNS가 동시에 작동할 수 있습니다. 실패한 도메인, 오류 유형, 사용 중인 트래픽 처리 방식을 기록하세요. IP 주소로 직접 접속이 되는 것은 단서일 뿐 HTTPS 도메인 테스트를 대신하지 못합니다. 인증서, 호스트 이름, 서버 가상 호스트가 도메인에 의존할 수 있습니다.

시스템 도구에서 DNS 조회가 성공해도 클라이언트의 이름 조회 경로가 정상이라는 뜻은 아닙니다. 명시적 HTTP 프록시는 보통 대상 도메인의 조회를 프록시에 맡길 수 있습니다. SOCKS 요청이 로컬에서 DNS를 조회할지는 호출 방식에 따라 다릅니다. 브라우저에서 별도의 보안 DNS를 사용하면 시스템 조회 결과를 우회할 수도 있습니다. 문제를 진단할 때는 한 가지 경로를 정해 테스트하고, 어떤 도구를 사용했는지 기록해 서로 다른 DNS 조회 결과를 섞어 비교하지 마세요.

주요 DNS 매개변수의 역할과 한계 이해하기

nameserver는 일반적인 상위 DNS 서버를 지정합니다. default-nameserver는 도메인으로 지정된 상위 DNS 서버 자체의 주소를 조회할 때 사용하며, 초기 조회 경로를 마련해 줍니다. proxy-server-nameserver는 프록시 서버 도메인 조회에 사용되므로 일반 웹사이트의 DNS 조회와는 별개의 문제입니다. fallback과 필터 조건은 후보 결과를 선택하는 데 관여하며, 모든 요청이 시간 초과된 뒤에만 차례로 호출되는 단순 예비 목록이 아닙니다.

아래 예시는 fake-ip 모드의 기본 동작을 살펴보기 위한 최소 구성으로, 전체 TUN 및 분할 규칙 설정은 포함하지 않습니다. 상위 DNS 주소는 매개변수 설명용이므로 네트워크에서 접근할 수 있는 주소를 선택하세요. 불필요하게 LAN에 DNS 서비스를 제공하지 않도록 수신 주소를 로컬로 제한합니다. 클라이언트 화면이나 덮어쓰기 파일에서 이미 DNS를 관리하고 있다면 같은 위치에서 수정하고, 여러 설정이 서로 덮어쓰게 두지 마세요.

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

fake-ip는 커널이 매핑을 관리하는 가상 주소를 반환하며 웹사이트 서버의 실제 주소가 아닙니다. 테스트 네트워크 대역의 주소가 표시된다고 해서 DNS가 잘못된 것은 아닙니다. 이후 연결이 해당 매핑을 관리하는 커널로 계속 전달되는지 확인해야 합니다. 앱이 가상 주소를 받은 뒤 TUN을 우회해 직접 연결하거나 커널이 재시작된 뒤 앱이 오래된 캐시를 사용하면 DNS 조회는 정상처럼 보여도 연결이 실패할 수 있습니다.

캐시와 트래픽 처리 순서에 따라 복구하기

먼저 설정을 적용하고 커널이 실행 중인지 확인한 다음 시스템과 앱에서 장애와 관련된 캐시를 지우고 요청을 다시 보냅니다. Windows에서는 아래 명령으로 시스템 DNS 캐시를 지울 수 있습니다. 브라우저 자체 캐시와 연결 풀을 초기화하려면 브라우저를 재시작해야 할 수 있습니다. 다른 시스템에서는 해당 플랫폼에 맞는 방법을 사용하세요. Windows 명령을 공통 절차로 적용하지 마세요. 캐시를 자주 비워도 잘못된 상위 DNS 서버나 트래픽 처리 경로는 해결되지 않습니다.

ipconfig /flushdns

TUN의 DNS 하이재킹은 보통 지정된 DNS 트래픽을 대상으로 하며, 모든 앱의 자체 암호화 DNS를 일괄 처리한다는 뜻은 아닙니다. 커널 DNS가 표준이 아닌 포트에서 수신하더라도 시스템이 자동으로 해당 포트에 쿼리를 보내지는 않습니다. 이를 위해 시스템 설정 또는 TUN 전달 설정이 필요합니다. 로그에 DNS 요청이 없다면 상위 DNS를 바꾸기 전에 요청이 커널에 들어오는지 확인하세요. 사용되지 않는 설정을 바꾸는 일을 피할 수 있습니다.

LAN 기기 이름, 회사 내부 도메인, 멀티캐스트 이름은 별도로 고려해야 합니다. 공용 DNS 서버는 보통 내부 이름을 알지 못합니다. 모든 쿼리를 공용 서버로 보내면 프린터나 사내 서비스에 연결되지 않을 수 있습니다. 실제 도메인과 네트워크 요구사항에 맞춰 DNS 정책이나 fake-ip 필터를 설정하고 기존 내부 DNS 경로를 유지하세요. 특정 도메인을 필터링해도 시스템이 그 이름을 자동으로 조회할 수 있게 되는 것은 아닙니다.

일반 웹사이트, 기존에 실패한 도메인, 필요한 내부 서비스를 각각 테스트한 뒤 프록시 서버 도메인도 안정적으로 조회되는지 확인하세요. 특정 DNS 설정을 끈 뒤에만 복구된다면 해당 설정이 어느 경로에 적용됐는지 기록한 다음 유지 여부를 결정하세요. 매개변수 조합과 DNS 하이재킹은 mihomo DNS 설정 자세히 알아보기를 참고하세요. 오류 로그 한 줄을 지우려고 DNS 설정 전체를 교체하지 마세요.

시스템 프록시 미작동: 포트·앱·트래픽 처리 방식 확인하기

로컬 포트부터 확인한 뒤 시스템 프록시 점검하기

시스템 프록시 스위치는 시스템 프록시 설정을 기록할 뿐 모든 프로그램이 이를 따른다는 뜻은 아닙니다. 먼저 명시적 프록시 요청으로 커널 포트가 작동하는지 확인하고 시스템의 프록시 호스트가 로컬 루프백 주소인지, 포트가 클라이언트 설정과 일치하는지 확인하세요. 혼합 포트를 바꾼 뒤에도 시스템 설정, 브라우저 확장 프로그램, 터미널 환경 변수에 이전 값이 남아 있을 수 있습니다. 클라이언트 설정 화면의 새 숫자만 확인하지 말고 각 연결 지점을 모두 점검하세요.

포트가 충돌하면 커널 실행이 실패하거나 다른 프로세스가 사용할 포트를 이미 점유했을 수 있습니다. Windows PowerShell에서는 수신 프로세스를 확인하고 macOS 또는 Linux에서는 lsof를 사용할 수 있습니다. 예시 포트는 실제 값으로 바꾸세요. 프로세스를 찾았더라도 먼저 어떤 앱인지 확인하고 알 수 없는 시스템 프로세스를 강제 종료하지 마세요. 충돌 앱을 닫거나 사용 가능한 포트로 바꾼 뒤 설정을 다시 적용하세요.

# Windows PowerShell
Get-NetTCPConnection -LocalPort 7897 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# macOS / Linux
lsof -nP -iTCP:7897 -sTCP:LISTEN

브라우저·터미널·시스템 서비스 구분하기

브라우저 프록시 확장 프로그램이 시스템 설정을 덮어쓸 수 있으며, 일부 앱에는 자체 프록시 메뉴가 있습니다. 터미널 도구는 보통 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY 환경 변수를 읽지만 지원 여부는 도구마다 다릅니다. 환경 변수는 대개 프로세스를 시작할 때 전달되므로 이미 실행 중인 터미널이나 편집기에 변경 사항이 즉시 반영되지 않을 수 있습니다. 브라우저가 정상이라고 백그라운드 서비스도 같은 프록시를 사용한다고 판단하지 마세요.

Windows의 사용자 프록시 설정은 일부 시스템 서비스가 사용하는 WinHTTP 설정과 다릅니다. 특정 서비스를 점검할 때 netsh winhttp show proxy로 환경을 확인할 수 있지만, WinHTTP 설정 가져오기나 초기화를 일반 브라우저의 고정 해결책으로 사용하면 안 됩니다. macOS에서는 연결되지 않은 인터페이스가 아니라 현재 사용하는 네트워크 서비스를 확인하세요. Linux 데스크톱에서 프록시가 작동하는지는 데스크톱 환경과 앱 구현에 따라서도 달라집니다.

TUN 모드는 권한과 라우팅을 별도로 확인해야 합니다

시스템 프록시를 따르지 않는 앱은 TUN을 고려할 수 있지만, 활성화하기 전에 클라이언트의 서비스 구성 요소나 권한 요구사항을 충족했는지 확인하세요. TUN 스위치가 켜져 있어도 가상 네트워크 어댑터와 라우팅이 정상적으로 설정된 것은 아닙니다. 로그에서 장치 생성 실패, 권한 부족, 라우팅 충돌이 있는지 확인하세요. 프로토콜 스택 옵션은 호환성에 영향을 줄 수 있으므로 클라이언트에서 지원하는 옵션을 하나씩 테스트하고 프로토콜 스택, DNS, 출구를 한꺼번에 바꾸지 마세요.

다른 VPN, 가상 머신 네트워크, 컨테이너 네트워크, 보안 소프트웨어가 TUN 라우팅과 겹칠 수 있습니다. 먼저 불필요한 네트워크 도구를 종료하고 시스템 프록시와 TUN의 동작을 비교하세요. 커널이 원격 서버에 직접 연결할 수 있어야 합니다. 라우팅이 잘못되면 이 연결이 다시 프록시로 들어가 순환할 수 있습니다. 클라이언트의 자동 라우팅 및 인터페이스 감지 기능을 사용한다면 현재 유효한 네트워크 인터페이스를 정확히 감지했는지도 확인하세요.

LAN 공유를 사용하려면 LAN 연결 허용을 별도로 켜고 수신 주소와 방화벽 범위를 올바르게 설정해야 합니다. 다른 기기에서 127.0.0.1은 그 기기 자신을 가리키므로 이 컴퓨터의 프록시에 연결하는 데 사용할 수 없습니다. 공유를 위해 방화벽 전체를 끄거나 로컬 프록시 포트를 공용 인터넷에 노출하지 마세요. 신뢰할 수 있는 LAN에서만 접근을 허용하고 네트워크를 바꾼 뒤 기존 접근 규칙이 여전히 적절한지 확인하세요.

클라이언트를 종료한 뒤 인터넷에 연결되지 않는다면 수신이 중단된 로컬 포트를 가리키는 시스템 프록시 설정이 남아 있는지 먼저 확인하세요. 남은 설정을 직접 끄고 다른 앱이 프록시나 자동 설정 스크립트를 추가했는지도 확인합니다. 연결을 복구한 뒤 클라이언트를 하나만 실행해 확인하고, 여러 자동 시작 항목이 서로 설정을 덮어쓰지 않도록 하세요. 시스템 프록시와 TUN의 기본 차이는 도움말 센터를 참고하세요. 처음 설정하는 순서는 빠른 시작 가이드에서 확인할 수 있습니다.

클라이언트 충돌: UI·커널·설정 문제 분리하기

먼저 어느 부분이 종료됐는지 확인하세요

창만 닫힌 경우, 트레이에 남아 있는 경우, 커널이 중지된 경우, 전체 프로세스가 종료된 경우는 서로 다른 문제입니다. 먼저 트레이 아이콘과 시스템 프로세스 목록을 확인하고 로그 기록이 계속되는지 살펴보세요. 닫기 버튼을 눌렀을 때 창이 트레이로 숨는 동작은 일반적으로 설정에 따른 것이며 충돌이 아닙니다. 화면은 정상인데 커널이 반복해서 재시작한다면 모든 현상을 UI 문제로 돌리기보다 설정 적용 오류, 리소스 경로, 권한을 먼저 확인하세요.

구독 가져오기, 앱 업데이트, TUN 전환, 절전 모드에서 복귀, 시스템 로그인 중 충돌 직전 어떤 작업을 했는지 기록하세요. 앱 로그 끝부분과 시스템 오류 기록의 시각을 대조해 보관하되 설정 폴더 전체를 제출할 필요는 없습니다. 로그에 서버 주소, 방문 도메인, 설정 경로가 포함될 수 있으므로 먼저 민감 정보를 가리세요. 문제를 안정적으로 재현할 수 있다면 여러 장의 스크린샷보다 재현 순서를 명확히 정리하는 편이 유용합니다.

백업 후 최소 구성으로 실행하기

클라이언트를 종료하고 관련 프로세스가 끝났는지 확인한 다음 설정 폴더를 별도 위치에 복사하세요. 백업에는 구독, 덮어쓰기 파일, 필요한 사용자 설정을 포함하되 공개 클라우드에 업로드하지 마세요. 그런 다음 클라이언트에서 지원하는 별도 설정 디렉터리나 초기화 방법으로 테스트 환경을 실행하세요. 데이터 디렉터리 위치를 모른다면 설정에서 설정 폴더 열기 메뉴를 먼저 확인하세요. 사용자 디렉터리의 정체를 모르는 파일을 바로 삭제하지 마세요.

최소 구성으로 실행되면 정상 작동을 확인한 설정을 가져온 뒤 덮어쓰기, 스크립트, 화면 설정을 하나씩 복구하세요. 특정 항목을 복구한 뒤 문제가 재현되면 원인 범위를 좁힌 것입니다. 설정 오류는 오류 행과 최종 병합 결과를 확인해 수정하세요. UI 데이터베이스나 창 상태 문제라면 프록시 프로토콜을 바꿀 필요가 없습니다. 설치 패키지에 포함된 별도 커널을 출처와 호환성이 불분명한 파일로 직접 교체하지 마세요.

mihomo 설정 문법을 로컬에서 확인할 때는 커널에서 제공하는 테스트 옵션을 사용할 수 있습니다. 아래 명령은 현재 디렉터리에 실행 파일과 테스트 설정이 있다고 가정합니다. 이 테스트로 커널이 설정을 받아들일 수 있는지는 확인할 수 있지만 서버 연결, 규칙의 의도한 작동, 구독 리소스의 지속적인 다운로드까지 보장하지는 않습니다. 명령 출력에 민감한 경로가 포함될 수 있으므로 전달 전에 확인하세요.

# macOS / Linux
./mihomo -t -f ./config.yaml

# Windows PowerShell
.\mihomo.exe -t -f .\config.yaml

아키텍처·실행 환경·권한 확인하기

다시 다운로드하기 전에 운영체제와 프로세서 아키텍처를 확인하세요. 특히 Intel과 Apple Silicon, Android 기기의 설치 패키지 아키텍처를 구분해야 합니다. 설치가 완료돼도 필요한 모든 종속성이 충족된 것은 아닙니다. 그래픽 실행 환경, 시스템 구성 요소, 설치 위치 권한도 실행에 영향을 줄 수 있습니다. 앱이 안내하는 구체적인 누락 구성 요소나 시스템 오류에 따라 처리하고 출처가 불분명한 복구 도구를 무더기로 설치하지 마세요.

Windows에서는 이벤트 뷰어로 오류 모듈을 찾고, macOS에서는 시스템 충돌 보고서와 앱 시작 기록을 확인할 수 있습니다. Linux에서는 사용자 세션 로그와 터미널에서 실행했을 때의 출력을 살펴보세요. 터미널에서 실행하면 그래픽 종속성 오류를 확인하는 데 도움이 될 수 있지만 문제를 덮으려고 데스크톱 앱을 계속 관리자 권한으로 실행하지 마세요. 서비스 구성 요소에 권한이 필요하다면 클라이언트가 제공하는 설치 및 관리 절차를 사용하세요.

보안 소프트웨어가 구성 요소를 격리했다면 격리 기록, 설치 출처, 감지 사유를 확인하세요. 보안을 무조건 끄지 마세요. 설치 디렉터리에 쓰기 권한이 없거나 동기화 프로그램이 사용 중이면 업데이트 후 파일이 불완전해질 수 있습니다. 앱을 완전히 종료한 뒤 다운로드 센터에서 운영체제에 맞는 설치 패키지를 선택해 다시 설치하세요. 문제를 계속 확인하는 데 필요한 설정과 로그가 삭제되지 않도록 데이터를 백업해 두세요.

Clash for Windows와 ClashX Meta는 지원이 중단됐습니다. 최신 시스템과의 호환성 문제가 발생하면 현재 환경에 맞는 클라이언트로 옮기는 방안을 고려하세요. 우선적으로 Clash Plus를 추천하며, Linux에서는 Clash Verge Rev와 FlClash도 확인할 수 있습니다. 이전할 때는 먼저 설정을 가져오고 기본 연결을 확인한 다음 사용자 지정 기능을 하나씩 복구하세요. 다른 클라이언트의 화면 설정 폴더 전체를 그대로 복사하지 마세요. 설정 문법이 호환돼도 내부 데이터 형식은 다를 수 있습니다.

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

Android에서 VPN 권한과 앱 적용 범위 확인하기

Android 클라이언트는 보통 시스템 VPN 인터페이스를 통해 트래픽을 처리합니다. 처음 연결할 때 시스템 권한이 필요하며 권한을 취소했거나 기기 정책으로 제한되면 앱 화면은 정상이어도 트래픽이 제대로 처리되지 않을 수 있습니다. 시스템 VPN 상태와 클라이언트 로그를 확인하고 다른 VPN, 업무 프로필 네트워크, 같은 범위를 사용하는 앱이 있는지도 살펴보세요. 알림 표시줄의 아이콘만 보고 출구와 DNS까지 정상이라고 판단하지 마세요.

Clash Plus, Clash Meta for Android, FlClash, Surfboard는 설정 형식과 메뉴 위치가 다릅니다. 가져올 때 해당 클라이언트에 맞는 형식을 선택하세요. 모든 Android 클라이언트가 같은 설정을 지원한다고 가정하면 안 됩니다. 앱별 프록시를 켰다면 문제가 발생한 앱이 의도한 범위에 포함됐는지 확인하세요. 일부 화면은 포함 목록, 다른 화면은 제외 목록을 사용하므로 선택 방식을 반대로 이해하면 브라우저는 되는데 특정 앱은 계속 직접 연결될 수 있습니다.

시스템의 항상 켜기 VPN과 VPN을 통하지 않는 연결 차단은 별도로 설정하는 항목입니다. 차단 옵션을 켠 상태에서 터널 연결이 끊기면 네트워크가 막히는 것은 Wi-Fi 장애가 아니라 시스템 정책에 따른 동작일 수 있습니다. 문제를 확인할 때 기존 설정을 기록하고 영향 범위를 이해한 뒤 비교 테스트하세요. 회사 관리 기기에서는 관리 정책을 따르고 업무 프로필 보안 설정을 임의로 바꾸지 마세요.

백그라운드 중단과 설치 실패를 각각 확인하세요

화면을 잠근 뒤 연결이 끊겼다가 클라이언트로 돌아오면 바로 복구되는 경우 배터리 최적화, 백그라운드 활동 제한, 제조사 자동 시작 관리 설정을 먼저 확인하세요. 필요한 백그라운드 실행을 허용한 뒤 잠금과 화면 켜기 과정을 한 번 끝까지 테스트하세요. 모든 절전 설정을 끄는 방식은 원인을 정확히 찾지 못할 뿐 아니라 배터리 수명에 영향을 줄 수 있습니다. 백그라운드 프로세스는 계속 실행되는데 Wi-Fi에서 모바일 네트워크로 전환한 뒤 실패한다면 백그라운드 권한보다 네트워크 재연결과 DNS를 중점적으로 확인하세요.

설치 시 호환되지 않는다는 메시지가 표시되면 시스템 요구사항과 프로세서 아키텍처를 확인하세요. 기존 앱 위에 설치하지 못하는 경우 서명이나 설치 출처가 다를 수도 있습니다. 앱 데이터를 삭제할 수 있으므로 제거하기 전에 설정을 내보내세요. 설치 오류를 우회하려고 알 수 없는 설치 패키지로 교체하거나 임의로 이전 버전으로 내리지 마세요. Android 앱과 아키텍처는 Android 다운로드 섹션에서 확인하고 첫 설정은 가이드를 따르세요.

iOS에서 터널 설정과 리소스 제한 확인하기

iOS에서는 iOS 다운로드 섹션에서 Clash Plus의 앱 스토어 페이지로 이동할 수 있습니다. 클라이언트 공식 웹사이트는 clashplus.io입니다. 연결 문제가 생기면 시스템 VPN 설정이 현재 클라이언트에 해당하는지 확인한 뒤 앱에 터널 생성 권한이 있는지 확인하세요. 남아 있는 이전 설정, 다른 네트워크 도구, 기기 관리 정책도 연결에 영향을 줄 수 있으므로 시스템에 표시된 상태를 기준으로 판단하세요.

iOS의 네트워크 확장 기능과 앱 화면은 별개의 프로세스 영역입니다. 앱 화면이 열려 있어도 터널이 계속 정상이라는 뜻은 아닙니다. 설정이 크거나 규칙 리소스가 많거나 업데이트가 잦으면 확장 기능에 부담이 될 수 있습니다. 먼저 작고 정상 작동을 확인한 설정으로 테스트한 다음 외부 리소스를 하나씩 복구하세요. 백그라운드 제한 문제를 구독 손상으로 단정하거나 로그도 없이 앱을 계속 재설치하지 마세요.

Wi-Fi·모바일 네트워크·로그인 페이지를 구분해 테스트하기

공용 Wi-Fi에서는 브라우저로 먼저 인증해야 할 수 있습니다. 프록시를 먼저 켜면 로그인 페이지가 표시되지 않을 수 있으므로 네트워크 안내에 따라 인증을 완료한 뒤 클라이언트를 켜세요. Wi-Fi와 모바일 네트워크는 IPv6, DNS, 접근 경로가 다를 수 있으므로 네트워크를 전환한 뒤 새 요청으로 테스트하세요. 집에서 같은 설정이 작동한다고 해서 회사 네트워크나 핫스팟의 경로 제한을 배제할 수는 없습니다.

휴대폰 핫스팟을 켜도 휴대폰 자체 VPN이 연결된 기기의 트래픽까지 처리해 준다고 보장할 수는 없습니다. 이는 시스템 구현에 따라 다릅니다. 컴퓨터를 휴대폰 핫스팟에 연결한 경우에도 컴퓨터의 시스템 프록시나 TUN 설정을 별도로 확인하세요. 모바일 연결을 복구한 뒤 화면 잠금, 화면 켜기, 네트워크 전환, 문제가 있던 앱을 각각 테스트하세요. 여전히 실패한다면 운영체제, 클라이언트 이름, 네트워크 조건, 민감 정보를 가린 로그를 정리한 뒤 이 안내서의 해당 섹션으로 돌아가 원인을 좁혀 보세요.