Clash 문제 해결 가이드

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

트래픽 가로채기를 끄면 원래 네트워크가 복구되는지 확인

Clash를 켠 뒤 모든 웹페이지가 열리지 않거나, 클라이언트에는 실행 중으로 표시되는데 앱이 계속 로딩되는 증상입니다. 문제가 발생한 앱, 접속하려는 웹사이트, 발생 시각을 기록한 다음 「시스템 프록시」와 「TUN 모드」를 끄고 클라이언트 창은 열어 두세요. 브라우저에서 평소 프록시 없이 접속되던 사이트를 방문합니다. 이때도 연결되지 않는다면 Wi-Fi 로그인 인증, 라우터 연결, 시스템 네트워크 설정, 다른 VPN을 먼저 확인하세요. 프록시 클라이언트만이 원인이라고 단정할 수 없습니다. 학교, 호텔, 공용 네트워크는 트래픽 가로채기를 끈 상태에서 먼저 인증해야 하는 경우가 많습니다.

트래픽 가로채기를 끈 직후 연결이 복구된다면 문제 범위를 로컬 연결 지점, 규칙 선택 또는 프록시 출구로 좁힐 수 있습니다. 「구독」 또는 구성 목록에서 구성을 내려받기만 한 것이 아니라 실제로 선택했는지 확인하세요. 이어서 「프록시」를 열고 현재 정책 그룹에서 사용할 수 있는 출구를 선택했는지 확인합니다. 일부 그룹은 이전 선택을 기억합니다. 구독을 업데이트한 뒤 구성원 이름이 바뀌면 화면상으로는 실행 중이어도 실제로는 사용할 수 있는 항목이 없을 수 있습니다. 구독을 전부 삭제하지 말고, 먼저 정상 작동이 확인된 구성으로 바꿔 비교하세요.

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

다음으로 TUN은 끈 채 클라이언트의 코어만 켜세요. 「설정」에서 실제 혼합 포트를 확인합니다. 아래 예시의 7897과 다르면 해당 포트 번호로 바꾸세요. 명시적 프록시 요청은 브라우저가 시스템 프록시를 따르는지와 관계없이 동작하므로, 클라이언트가 요청을 전달할 수 있는지와 앱이 프록시에 연결되는지를 따로 확인할 수 있습니다. Windows PowerShell에서는 curl이 다른 명령으로 해석되는 구형 환경을 피하기 위해 curl.exe를 사용하세요. 예시 도메인은 HTTPS 요청 대상일 뿐, 현재 네트워크에서 프록시 없이 접속할 수 있어야 한다는 뜻은 아닙니다.

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

HTTP 상태 줄이 반환되면 적어도 해당 요청에 서버가 응답한 것입니다. 접근 거부 상태라도 연결 자체가 성립하지 않은 경우와는 다릅니다. 127.0.0.1에 연결할 수 없다는 메시지가 나오면 코어가 실행 중인지, 포트 번호가 맞는지 확인하세요. 로컬 포트 연결은 성공했지만 이후 시간 초과가 발생한다면 아웃바운드 로그를 살펴봅니다. 브라우저는 실패하는데 명시적 요청은 성공한다면 노드를 계속 바꾸지 말고 시스템 프록시 섹션에서 앱 연결 지점을 확인하세요.

로그로 규칙 오류와 아웃바운드 연결 실패 구분하기

「로그」를 열고 일반 정보 수준을 유지한 채 화면을 지운 다음, 실패 요청을 한 번만 재현하세요. 시각, 대상 도메인, 일치한 규칙, 최종 정책 그룹을 확인합니다. 요청이 DIRECT로 잘못 전달됐다면 대상 네트워크에 프록시가 필요한 경우 규칙 순서나 모드 선택이 원인일 가능성이 높습니다. 비교를 위해 잠시 「전역」 모드로 전환한 뒤 테스트가 끝나면 「규칙」 모드로 되돌릴 수 있습니다. 전역에서는 되지만 규칙 모드에서 안 된다면 모든 연결을 한 출구로 보내기보다는 일치한 규칙을 확인하세요. 기존 연결에는 이전 정책이 유지될 수 있으므로 모드를 바꾼 뒤 페이지를 다시 열거나 새 연결을 시작해야 합니다.

특정 앱의 로그가 전혀 없다면 앱이 현재 연결 지점을 거치지 않거나 별도의 네트워크 프로세스를 사용할 수 있습니다. 먼저 브라우저로 확인한 다음 해당 앱의 프록시 설정을 살펴보세요. 로그에 REJECT가 표시되면 광고 차단, 개인정보 보호 규칙, 사용자 지정 규칙 중 무엇이 적용됐는지 확인합니다. 관련 규칙만 조정하고 전체 규칙 목록을 지우지 마세요. 규칙 우선순위는 규칙 문법과 일치 순서 안내에서 확인할 수 있습니다.

변경 후 원래 프록시 없이 접속되던 사이트까지 열리지 않으면 가장 최근의 정상 상태로 즉시 되돌리세요. TUN을 끄고 DNS 설정을 원래대로 복구한 다음 다른 네트워크 트래픽 제어 도구를 종료하고 다시 테스트합니다. 시스템 네트워크 스택 전체를 바로 초기화하지 마세요. 시스템 수준 초기화는 일부 어댑터나 네트워크 설정을 삭제해 원격 데스크톱, 가상 머신, 회사 네트워크 접속까지 중단시킬 수 있습니다. 제한된 범위의 복구가 효과가 없다고 확인된 뒤에 고려하세요.

노드 시간 초과: 오류 주소로 실패 지점 찾기

연결, 핸드셰이크, 대상 사이트 접속을 구분하세요

「시간 초과」는 원인이 하나로 정해진 오류가 아닙니다. 클라이언트의 연결 테스트는 특정 확인 주소에 요청할 수 있지만, 브라우저는 다른 사이트에 접속하므로 결과가 다를 수 있습니다. 먼저 대상 페이지를 직접 열어 본 뒤 같은 시각의 로그를 확인하세요. 테스트 버튼에서만 시간 초과가 발생하고 실제 접속은 정상이라면 테스트 주소와 규칙 경로를 점검하세요. 테스트 결과 하나만으로 아웃바운드가 작동하지 않는다고 판단하지 마세요. 반대로 테스트에 성공해도 테스트 요청이 완료됐다는 뜻일 뿐, 모든 웹사이트와 UDP, 대용량 전송이 정상이라는 보장은 없습니다.

dial tcp 뒤에 나오는 주소를 확인하세요. 프록시 서버 주소일 수도 있고 직접 연결하는 대상 주소일 수도 있습니다. 전자에서 연결이 실패하면 서버 도메인 해석, 포트, 네트워크 연결 상태를 살펴보세요. 후자에서 실패한다면 요청이 왜 직접 연결을 선택했는지 먼저 확인해야 합니다. connection refused는 대개 연결이 명시적으로 거부됐음을 뜻합니다. 해당 포트에서 서비스가 대기 중이지 않거나 중간 장비가 거부했을 수 있습니다. i/o timeout은 제한 시간 안에 읽기나 쓰기가 끝나지 않았다는 뜻이며, 이것만으로 서비스 제공자가 중단됐다고 단정할 수는 없습니다.

네트워크와 아웃바운드를 교차 테스트해 범위 좁히기

같은 아웃바운드와 대상을 유지한 채 기기를 현재 Wi-Fi에서 휴대폰 핫스팟으로 바꿔 보세요. 핫스팟에서는 작동한다면 원래 네트워크가 해당 포트나 전송 방식을 제한하거나 경로 품질에 문제가 있을 수 있습니다. 원래 네트워크로 돌아와 다른 아웃바운드를 선택해 테스트합니다. 특정 아웃바운드만 실패하면 설정 만료 여부와 서버 변경 여부를 확인하고, 구독 제공자에게 발생 시각과 오류 내용을 전달하세요. 모든 네트워크에서 모든 아웃바운드가 실패한다면 로컬 기기의 시간, 구독 유효성, 코어 호환성을 우선 확인하는 편이 좋습니다.

UDP 기반 전송은 일반적인 TCP 포트 검사만으로 프로토콜 사용 가능 여부를 확인할 수 없습니다. 일부 네트워크는 웹 접속은 허용하면서 UDP를 제한할 수 있습니다. 이런 경우 여러 전송 방식을 지원하는 아웃바운드를 비교용으로 사용할 수 있습니다. 프로토콜 이름, 포트, 전송 필드를 임의로 다른 프로토콜에 맞춰 바꾸지 마세요. 클라이언트의 값은 서버 설정과 일치해야 합니다. 연결이 실패해도 방화벽을 바로 끌 필요는 없습니다. 먼저 차단 기록을 확인하고 앱이나 특정 포트에 필요한 규칙만 추가한 뒤, 테스트가 끝나면 임시 허용 규칙을 삭제하세요.

TLS, 인증 정보, 코어 호환성 확인하기

핸드셰이크 오류가 발생하면 먼저 시스템 시간이 자동으로 동기화되는지 확인하고 서버 이름, SNI, 인증 정보, 전송 경로를 점검하세요. 서버 도메인을 IP 주소로 바꾸면 인증서 이름 확인 결과가 달라질 수 있으므로 일반적인 해결책으로 사용하면 안 됩니다. 구독에서 제공한 매개변수는 그대로 유지하세요. 직접 설정한 경우 각 항목을 서버 안내와 대조합니다. 프로토콜이나 설정 필드를 인식하지 못한다면 현재 클라이언트가 사용하는 코어를 확인하세요. 구형 오리지널 Clash는 모든 mihomo 확장 기능을 지원하지 않습니다.

최근에 설정을 옮겼다면 mihomo와 오리지널 코어의 차이를 참고해 프로토콜, 규칙 제공자, 스니핑 관련 필드를 확인하세요. 클라이언트를 업데이트할 때는 현재 설정을 보존한 뒤 설치 파일 페이지에서 기기에 맞는 빌드를 선택하세요. 출처가 불분명한 실행 파일로 코어를 덮어쓰지 마세요. 클라이언트, 구독, DNS, 모든 규칙을 한꺼번에 업데이트하면 문제가 생긴 뒤 원인을 찾기 어렵습니다.

도움을 요청할 때는 「시간 초과」라는 두 단어만 캡처하지 말고 실패 요청 직전과 직후의 로그를 함께 보관하세요. 클라이언트 이름, 운영체제, 네트워크 종류, 특정 아웃바운드에만 영향을 주는지, 네트워크를 바꿔 테스트한 결과를 제공하면 도움이 됩니다. 비밀번호, 구독 매개변수, 전체 서버 식별 정보는 가리세요. 로그 항목을 읽는 방법은 Clash 실행 로그 읽는 법에서 확인할 수 있습니다.

구독 업데이트 실패: 다운로드와 파싱 단계 확인하기

링크를 가져오지 못한 문제인가요, 내용을 불러오지 못한 문제인가요?

구독 업데이트가 실패하면 현재 사용 중인 설정을 보존하고 삭제 후 다시 추가하지 마세요. 구독 카드의 오류 상세 정보를 열어 콘텐츠 가져오기와 파싱 중 어느 단계에서 실패했는지 확인합니다. 연결 시간 초과나 도메인 조회 실패는 대개 다운로드 단계의 문제입니다. YAML 형식 오류, 지원되지 않는 프록시 유형, 정책 그룹 참조 오류는 보통 파싱 단계에서 발생합니다. 두 문제는 해결 방법이 다릅니다. 업데이트 버튼을 반복해서 눌러도 형식 오류는 해결되지 않으며, 서버 요청 제한에 걸려 명확한 오류를 더 복잡하게 만들 수 있습니다.

서비스 제공자의 관리 페이지에서 구독 주소 전체를 다시 복사하고, 앞뒤 공백이나 줄바꿈, 메신저의 문장부호, 웹페이지에 표시된 설명이 함께 복사되지 않았는지 확인하세요. 구독 링크의 쿼리 매개변수는 인증에 쓰이는 경우가 많으므로 임의로 삭제하거나 바꾸면 안 되며, 스크린샷이나 게시판에 공개해서도 안 됩니다. 가능하면 클라이언트에서 직접 가져오세요. 낯선 온라인 변환 사이트에 링크를 제출하지 마세요. 브라우저로 확인해야 한다면 방문 기록, 다운로드 기록, 동기화 기능에 전체 주소가 저장될 수 있다는 점을 먼저 확인하세요.

HTTP 응답으로 해결 방향 판단하기

401 또는 403이 표시되면 대개 인증, 계정 상태, 서버 접근 정책을 확인해야 합니다. 로컬 혼합 포트를 바꿀 문제는 아닙니다. 404는 경로가 만료됐거나 서버가 리소스를 의도적으로 숨겼다는 뜻일 수 있으므로 제공자가 안내한 주소를 다시 확인하세요. 429는 요청이 너무 잦다는 뜻입니다. 연속해서 재시도하지 말고 서버 안내에 따라 기다리세요. 5xx는 서버나 상위 서비스 문제일 가능성이 높습니다. 발생 시각을 기록하고 잠시 후 다시 시도하세요. 모든 클라이언트를 바로 재설치할 필요는 없습니다.

성공 상태가 반환돼도 구성 본문이 아니라 로그인 페이지, 인증 페이지, 오류 안내를 받을 수 있습니다. 오류 내용에 <html>, 문서 유형 선언, 웹 로그인 화면이 포함됐는지 확인하세요. Clash 구성은 보통 프록시, 정책 그룹, 규칙 등의 관련 필드를 포함한 YAML 매핑입니다. 일반 노드 목록과 완전한 구성은 서로 다릅니다. 서비스 제공자가 구독 형식을 여러 개 제공한다면 현재 클라이언트와 호환되는 항목을 선택하세요. 클라이언트 이름이나 요청 식별자를 바꾸는 것은 제공자가 명시적으로 요구할 때만 의미가 있습니다.

업데이트 경로의 의존성과 구성 충돌 해결하기

현재 네트워크에서 구독 주소에 직접 연결할 수 없는데 클라이언트 업데이트 요청은 기본적으로 직접 연결을 시도할 수 있습니다. 반대로 업데이트 요청이 이미 끊긴 프록시를 통과하는 경우도 있습니다. 구독 업데이트 옵션에서 현재 프록시를 통해 가져올 수 있는지 확인하고, 직접 연결과 사용 가능한 프록시 경로를 각각 테스트하세요. 기존 아웃바운드가 모두 작동하지 않으면 구독 서비스에 접속할 수 있는 네트워크로 잠시 전환해 업데이트하세요. 「연결하려면 먼저 업데이트해야 하지만, 업데이트하려면 먼저 연결해야 하는」 상황을 피할 수 있습니다. 프록시 서버 도메인도 정상적으로 조회되어야 합니다.

파싱 오류에 줄 번호가 표시되면 해당 줄과 앞뒤 들여쓰기를 먼저 살펴보세요. YAML은 공백으로 계층을 표현하므로 탭 문자를 섞지 마세요. 같은 계층에서 키 이름이 중복되면 값이 덮어써지거나 파싱 오류가 발생할 수 있습니다. 아래는 코어가 구성을 불러올 수 있는지 확인하기 위한 독립적인 최소 직접 연결 구성입니다. 프록시 아웃바운드는 제공하지 않으며 구독을 대체하지도 않습니다. 로컬 테스트용 구성을 새로 만들어 사용하고 원격 구독 본문을 직접 덮어쓰지 마세요.

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

최소 구성은 불러오지만 구독 구성은 실패한다면 구독 내용, 코어 지원 여부, 로컬 오버라이드를 계속 점검하세요. 일부 클라이언트는 업데이트 결과에 「병합」, 「스크립트」, 「오버라이드」를 적용합니다. 이전 오버라이드가 더 이상 존재하지 않는 정책 그룹을 참조하면 원격 본문은 정상이어도 최종 구성에 오류가 날 수 있습니다. 추가 처리 기능을 하나씩 끄고 업데이트한 뒤 확인하세요. 원인을 찾으면 해당 참조만 수정하고 사용자 지정 설정을 모두 영구적으로 버리지 마세요.

업데이트에 성공한 뒤에도 현재 선택된 구성, 정책 그룹 구성원, 사용할 수 있는 아웃바운드를 다시 확인하세요. 일부 클라이언트는 다운로드에 성공해도 새 구성으로 자동 전환하지 않습니다. 구독 주소가 유출된 것으로 의심되면 제공자 관리 페이지에서 링크를 재설정한 뒤 모든 기기에서 업데이트하세요. 메신저에서 메시지를 삭제해도 이미 복사된 인증 정보는 취소되지 않습니다.

속도 저하와 간헐적 끊김: 대역폭, 지연 시간, 앱 동작 구분하기

막연한 「느림」을 재현 가능한 증상으로 바꾸기

먼저 어디서 느린지 구체적으로 확인하세요. 페이지 첫 화면이 늦게 뜨는지, 동영상 재생 중 버퍼링이 반복되는지, 다운로드 속도가 낮은지, 일정 시간 후 연결이 끊기는지 구분합니다. 페이지 시작이 느리면 DNS, 연결 설정, TLS 핸드셰이크가 관련될 수 있습니다. 다운로드가 계속 느리다면 전송량, 회선 혼잡, 서버 제한을 살펴보세요. 일정 시간이 지난 뒤 끊긴다면 절전, 백그라운드 제한, 연결 유지 기능을 확인해야 합니다. 클라이언트의 지연 시간 숫자만으로 다운로드 대역폭을 판단할 수 없습니다. 왕복 지연이 낮아도 원격 출구가 혼잡할 수 있습니다.

테스트할 때 기기, 대상, 앱을 동일하게 유지하고 클라우드 드라이브 동기화, 시스템 업데이트 등 대용량 작업을 잠시 중지하세요. 먼저 프록시를 통하지 않은 로컬 네트워크 상태를 확인한 다음 같은 대상으로 두 아웃바운드를 비교합니다. Wi-Fi, 브라우저, 프로토콜, 웹사이트를 한꺼번에 바꾸지 마세요. 매번 조건이 달라져 결과를 비교할 수 없습니다. 속도 측정 사이트가 규칙에 따라 직접 연결될 수도 있습니다. 직접 연결 결과를 프록시 성능으로 착각하면 결론이 정반대가 될 수 있으니 연결 목록에서 실제 아웃바운드를 확인하세요.

네트워크 경로와 기기 부하를 구간별로 확인하기

Wi-Fi 신호 막대가 많아도 간섭이 적다는 뜻은 아닙니다. 라우터 가까이에서 사용하거나 안정적인 주파수 대역으로 전환하고, 잠시 유선 연결을 해보면 로컬 무선 문제를 확인하는 데 도움이 됩니다. 같은 아웃바운드가 휴대폰 핫스팟에서는 안정적이고 집 Wi-Fi에서는 끊긴다면 먼저 로컬 네트워크 경로를 점검하세요. 회사 네트워크, 공유 회선, 저녁 시간대의 혼잡도도 사용 가능한 전송량에 영향을 줄 수 있습니다. 혼잡 시간대 테스트 한 번이 좋지 않았다고 인터넷에서 본 「고속 설정」을 모든 구성에 적용하지 마세요.

시스템 작업 관리자나 활성 상태 보기를 열어 CPU, 메모리, 디스크 사용량이 계속 높은지 확인하세요. 프록시 연결이 많으면 클라이언트 화면, 코어, 다른 보안 소프트웨어가 동시에 리소스를 사용할 수 있습니다. 실제 전송을 관찰하는 동안 로그 상세 수준을 낮추고 계속 갱신되는 디버그 창을 닫아 보세요. 속도 측정 수치를 높이려고 필요한 보안 기능을 끄지는 마세요. 네트워크 요청은 정상이지만 화면만 느리다면 UI 성능과 코어의 트래픽 전달을 나눠서 점검하세요.

규칙, 프로토콜, 대용량 전송 점검하기

특정 사이트만 느리고 다른 사이트는 정상이라면 서로 다른 콘텐츠 전송 도메인을 사용하는지, 일부 리소스가 다른 아웃바운드로 전달되는지 확인하세요. 브라우저 페이지는 여러 도메인에 동시에 연결될 수 있습니다. 기본 도메인은 프록시를 통하지만 이미지나 미디어 리소스는 직접 연결되면 텍스트는 먼저 뜨고 동영상은 늦게 나타날 수 있습니다. 연결 목록과 로그에서 관련 요청을 확인한 뒤 실제로 일치한 도메인에 맞춰 규칙을 조정하세요. 사용자 지정 규칙은 먼저 일치하는 규칙보다 앞에 두고 최종 기본 규칙은 유지하세요. MATCH 뒤에 규칙만 추가해서는 적용되지 않습니다.

시스템 프록시는 정상인데 TUN을 켠 뒤 대용량 전송이 자주 멈춘다면 TUN을 끄고 라우팅과 MTU를 비교 점검하세요. MTU가 맞지 않으면 작은 요청은 정상인데 큰 패킷 전송이 멈출 수 있습니다. 다만 모든 끊김의 공통 원인은 아닙니다. 값을 바꾸기 전에 원래 값을 기록하고, 클라이언트와 네트워크 환경의 안내를 따라 조금씩 테스트하세요. 다른 사람이 사용하는 가상 네트워크 어댑터 매개변수를 그대로 복사하지 마세요. UDP에 의존하는 전송을 사용한다면 현재 네트워크의 UDP 품질과 속도 제한도 고려해야 합니다.

브라우저가 QUIC을 시도하거나 앱이 별도의 UDP 세션을 만들 수 있습니다. 이런 트래픽에서만 문제가 발생한다면 관련 설정을 제공하는 테스트 앱에서 해당 기능을 잠시 꺼 비교한 뒤 다시 켜세요. 한 번의 테스트를 통과시키려고 모든 UDP를 전역 차단하지 마세요. 음성 통화, 게임 및 다른 서비스에 영향을 줄 수 있습니다. 정책을 바꾼 뒤에는 새 연결을 만들어야 합니다. 진행 중인 다운로드나 동영상 세션은 새 아웃바운드로 즉시 전환되지 않을 수 있습니다.

특정 앱에서만 계속 느리다면 해당 앱의 프록시 설정과 캐시를 지우기 전에 다른 앱의 유사한 요청은 정상인지 확인하세요. 일부 플랫폼은 출구 주소, 계정, 콘텐츠 서버에 따라 서로 다른 경로를 배정합니다. 아웃바운드를 바꾼 뒤 잠시 나아져도 클라이언트에 문제가 있다는 뜻은 아닐 수 있습니다. 안정적으로 작동하는 설정을 우선 유지하고, 계정 재인증이나 진행 중인 작업 중단을 유발할 수 있는 잦은 재연결은 피하세요.

DNS 문제: 시스템 조회와 코어 조회 구분하기

도메인 조회 실패가 모든 연결 실패를 뜻하지는 않습니다

서버를 찾을 수 없다는 메시지, 로그의 no such host, 같은 웹사이트가 때로 열리고 때로는 연결할 수 없는 주소로 조회되는 증상이 나타날 수 있습니다. 먼저 도메인 철자를 확인한 뒤 오류가 프록시 서버의 도메인 조회에서 발생했는지 최종 웹사이트 조회에서 발생했는지 구분하세요. 프록시 서버 도메인 조회에 실패하면 전체 아웃바운드가 영향을 받지만 특정 웹사이트 조회 실패는 해당 사이트만 영향을 받을 수 있습니다. IP 주소로 직접 접속하는 것만으로 도메인 테스트를 완전히 대신할 수는 없습니다. HTTPS 인증서, 가상 호스트, 콘텐츠 전송에 도메인이 필요할 수 있습니다.

시스템 DNS, 브라우저의 보안 DNS, mihomo 내장 DNS는 서로 다른 단계입니다. 브라우저가 암호화된 DNS를 별도로 사용할 수 있고 일부 앱은 시스템 설정을 우회합니다. 따라서 시스템 조회가 성공해도 브라우저가 같은 경로를 사용한다는 보장은 없으며, 시스템 조회 실패가 프록시 코어의 DNS 조회 불가를 뜻하지도 않습니다. Windows에서는 nslookup example.com으로 시스템 조회 결과를 확인할 수 있습니다. 해당 도구를 제공하는 시스템에서는 dig example.com도 사용할 수 있습니다. 이런 명령의 결과는 클라이언트 로그와 함께 확인하고 단독으로 최종 결론을 내리지 마세요.

순환 의존성을 먼저 해결하고 캐시를 확인하세요

암호화 DNS 서비스는 자체 연결이 필요하고, 서버 이름을 조회해야 할 수도 있습니다. 프록시 연결에는 프록시 서버의 도메인 조회가 필요한데, 그 조회는 아직 연결되지 않은 프록시를 거쳐야 한다면 순환 의존성이 생깁니다. 구성에서 기본 DNS 조회, 프록시 서버 조회, 일반 대상 조회의 경로를 명확히 나누세요. 모든 DNS 요청을 무조건 프록시로 보내고 프록시 서버 도메인까지 같은 경로에 맡기지 마세요. 구독을 사용하는 경우 먼저 기존 DNS 설정을 복구한 뒤 로컬에서 필요한 항목을 하나씩 추가하세요.

DNS를 변경한 뒤에도 이전 캐시 때문에 결과가 잠시 그대로일 수 있습니다. 테스트 앱을 다시 열고 필요한 경우 코어 캐시를 지우거나 클라이언트 안내에 따라 코어를 재시작하세요. Windows에서는 필요한 경우 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 지울 수 있지만, 모든 브라우저와 앱의 캐시가 함께 삭제되지는 않습니다. 캐시 계층을 파악하지 않은 채 네트워크 어댑터를 반복 초기화하지 마세요. 처리할 때마다 같은 도메인으로 다시 테스트하고 로그의 요청 경로가 바뀌었는지 기록하세요.

fake-ip와 로컬 네트워크 도메인 예외 이해하기

fake-ip 모드에서는 코어가 예약 주소 범위의 매핑 주소를 앱에 반환한 뒤 내부 매핑을 통해 대상 도메인을 복원할 수 있습니다. 이는 정상 동작 방식이므로 해당 주소가 보인다고 바로 DNS 오염으로 판단하지 마세요. 앱이 코어 라우팅을 우회해 매핑 주소로 외부에 직접 연결하면 실패할 수 있습니다. 트래픽 가로채기를 끈 뒤에도 이전 매핑을 보유한 앱은 잠시 오류가 날 수 있습니다. 이때는 올바른 트래픽 가로채기를 복구하거나 앱 연결을 다시 만들고, 매핑 주소를 시스템 hosts 파일에 넣지 마세요.

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

이 구성은 mihomo 관련 필드를 보여 주며, 선택한 DNS 서비스에 현재 네트워크로 접속할 수 있어야 합니다. 모든 네트워크에 적용할 수 있는 완전한 DNS 구성은 아닙니다. 필요한 필드를 기존 dns 매핑에 병합하고 같은 최상위 키를 중복해서 추가하지 마세요. 로컬 네트워크 기기, 회사 내부 도메인, 분할 DNS는 라우터나 회사 DNS를 사용해야 할 수 있습니다. fake-ip에서 제외하는 것만으로 올바른 내부 DNS가 자동 선택되지는 않으므로 실제 환경에 맞게 조회 정책도 설정해야 합니다.

TUN을 켠 뒤 사내 프린터, NAS, 회사 도메인에 접근할 수 없다면 먼저 TUN을 끄고 확인한 뒤 DNS 하이재킹 범위, 내부 도메인 조회, 사설 IP 대역 라우팅을 점검하세요. 모든 내부 네트워크 요청을 원격 출구로 보내지 마세요. 회사 네트워크는 검색 접미사, 분할 DNS, 전용 VPN을 사용할 수 있으므로 공용 DNS만 바꾸면 내부 이름 조회가 더 어려워질 수 있습니다. 조직에서 관리하는 기기라면 관리자의 네트워크 지침을 따르고 관리 설정을 덮어쓰지 마세요.

웹페이지에 인증서 오류가 나타나도 인증서 검증을 꺼서 숨기지 마세요. 시스템 시간, 실제 접속 도메인, 인증서 발급 대상을 확인합니다. 잘못된 주소를 반환하는 DNS나 남아 있는 중간 프록시 설정도 비슷한 오류를 일으킬 수 있습니다. HTTPS 인증서 오류 안내에서 원인을 더 구분해 보세요. 복구를 마친 뒤에는 일반 웹사이트, 프록시가 필요한 웹사이트, 로컬 네트워크 리소스를 모두 테스트해 한 종류의 조회만 고치고 다른 경로를 망가뜨리지 않았는지 확인하세요.

시스템 프록시가 작동하지 않을 때: 연결 지점, 포트, 트래픽 가로채기 충돌 확인

시스템 프록시 스위치는 모든 기기 트래픽을 제어하지 않습니다

클라이언트에서 「시스템 프록시」를 켰는데 일부 프로그램이 직접 연결되거나, 브라우저는 되지만 터미널과 게임은 작동하지 않는 증상입니다. 시스템 프록시는 보통 운영체제의 관련 설정에 로컬 프록시 주소를 기록하는 기능입니다. 앱이 이를 따르는지는 앱의 네트워크 구현에 달려 있습니다. 브라우저, 시스템 서비스, 명령줄 도구는 서로 다른 프록시 방식을 사용할 수 있습니다. 먼저 브라우저와 명시적 프록시 요청으로 기준을 확인하세요. 특정 프로그램의 로그가 없다는 이유만으로 코어의 트래픽 전달 오류라고 단정하지 마세요.

Windows에서는 「설정 → 네트워크 및 인터넷 → 프록시」를 열고 주소와 포트가 현재 클라이언트 설정과 일치하는지 확인하세요. macOS에서는 「시스템 설정 → 네트워크」에서 현재 네트워크 서비스의 세부사항을 열고 「프록시」를 확인합니다. 시스템 버전에 따라 화면 위치는 다를 수 있습니다. Wi-Fi, 유선 네트워크, 네트워크 위치를 바꾼 뒤에는 어떤 서비스 설정이 실제로 적용 중인지도 확인하세요. 자동 프록시 스크립트와 수동 프록시가 다른 소프트웨어나 조직 정책에서 설정됐을 수 있습니다. 수정 전에 기존 값을 기록하고, 관리되는 기기의 정책을 임의로 덮어쓰지 마세요.

혼합 포트를 실제로 어떤 프로세스가 수신하는지 확인하기

클라이언트 화면에 포트가 표시된다고 코어가 해당 포트를 정상적으로 바인딩했다는 뜻은 아닙니다. 로그에서 주소 충돌, 권한 부족, 코어 시작 실패가 있었는지 확인하세요. 아래 명령은 혼합 포트 7897을 예시로 사용하며, 수신 중인 프로세스를 확인할 뿐 종료하지 않습니다. Windows PowerShell에서는 첫 번째 명령을 실행하세요. lsof가 설치된 macOS 또는 Linux 환경에서는 두 번째 명령을 사용할 수 있습니다. 권한 제한으로 정보가 충분하지 않으면 시스템 안내에 따라 조회 권한을 높이세요.

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

lsof -nP -iTCP:7897 -sTCP:LISTEN

이전 클라이언트가 포트를 사용 중이라면 작업 관리자나 활성 상태 보기에서 프로세스 이름을 확인한 뒤 이전 클라이언트를 정상 종료하세요. 프로세스 번호만 보고 시스템 서비스를 강제 종료하지 마세요. 다른 빈 포트를 쓰려면 앱의 프록시 설정과 터미널 명령도 함께 바꿔야 합니다. 클라이언트 포트만 바꾸고 시스템 프록시는 이전 포트를 가리키면 「코어는 실행 중이지만 앱이 연결되지 않는」 문제가 생깁니다. 반대로 이전 코어가 포트를 계속 점유하면 요청이 잘못된 설정으로 전달될 수 있습니다.

환경 변수와 TUN 모드를 단계별로 점검하기

터미널 프로그램은 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY를 읽을 수 있으며 일부만 사용하는 경우도 있습니다. 현재 세션에 이전 주소가 남아 있는지, 특히 컨테이너, 원격 개발 도구, 통합 터미널에서 확인하세요. 환경 변수는 프로세스가 시작될 때 상속되므로 시스템 변수를 바꿔도 이미 열려 있는 터미널에는 바로 반영되지 않을 수 있습니다. 먼저 단일 테스트 명령에 프록시를 명시해 작동을 확인한 뒤 장기 설정 여부를 결정하세요.

시스템 프록시를 따르지 않는 앱의 트래픽을 가로채야 할 때 TUN을 고려하세요. 다른 VPN, 네트워크 가속 도구, 중복된 TUN 인스턴스를 먼저 끄고 클라이언트에 필요한 권한이나 서비스 모드가 정상인지 확인합니다. TUN을 켠 뒤에는 스위치 상태만 보지 말고 가상 어댑터와 경로가 설정됐는지 확인하세요. 일부 클라이언트에서는 시스템 프록시와 TUN을 함께 사용할 수 있지만, 점검할 때는 각각 따로 테스트해야 여러 연결 지점을 거치거나 우회하고 다른 도구가 요청을 다시 쓰는 일을 방지할 수 있습니다.

Linux 데스크톱의 프록시 설정도 모든 프로그램에서 읽는 것은 아닙니다. 명령줄 앱, 샌드박스 앱, 시스템 서비스는 자체 설정을 사용할 수 있습니다. 컨테이너 안의 127.0.0.1은 호스트가 아니라 컨테이너 자체를 가리킵니다. 다른 기기나 컨테이너에서 프록시에 접속하려면 수신 주소, 방화벽, 접근 제어도 설정해야 합니다. 편의를 위해 프록시 연결 지점을 공용 네트워크에 노출하지 마세요. 로컬 네트워크에서 접근을 허용하더라도 신뢰할 수 있는 출처로 제한해야 합니다.

마지막으로 브라우저, 명시적 프록시 명령, 원래 작동하지 않던 앱을 각각 테스트하세요. 앞의 두 항목은 정상인데 대상 앱의 로그가 여전히 없다면 해당 앱의 연결 지점을 중심으로 점검합니다. TUN을 켰을 때만 실패한다면 구독을 반복해서 수정하지 말고 라우팅, 권한, DNS를 확인하세요. 이처럼 단계별로 확인하면 부팅 후 간헐적으로 실패하는 문제도 해결할 수 있습니다. 네트워크가 연결됐는지, 코어가 포트를 수신 중인지 확인한 다음 시스템 프록시가 올바르게 설정됐는지 살펴보세요.

클라이언트 충돌 및 시작 실패: 설정을 보존하고 원인 분리하기

창 닫힘, 백그라운드 실행, 코어 종료를 구분하세요

아이콘을 두 번 눌러도 창이 나타나지 않으면 시스템 트레이나 메뉴 막대, 프로세스 목록을 확인하세요. 일부 클라이언트는 창을 닫아도 백그라운드에서 실행됩니다. 다시 시작하면 기존 인스턴스가 열릴 수 있으므로 숨겨진 창이 곧 충돌을 뜻하지는 않습니다. 창은 열려 있는데 코어가 실행되지 않는다고 표시되면 그래픽 화면만 재설치하지 말고 코어 로그를 확인하세요. 프로세스가 시작 직후 사라지는 경우에 시작 충돌을 점검합니다. 마지막으로 정상 사용한 뒤 시스템 업데이트, 설정 이전, 보안 소프트웨어 설치, 비정상 종료 등 어떤 변경이 있었는지 기록하세요.

클라이언트에서 지원하는 경로 안내를 통해 설정과 로그 위치를 찾으세요. 폴더가 열리지 않으면 해당 클라이언트의 안내를 확인하고 다른 소프트웨어의 경로를 기준으로 파일을 삭제하지 마세요. 클라이언트와 관련 백그라운드 프로세스를 정상 종료한 뒤 설정 폴더 전체를 로컬 백업 위치에 복사하고, 구독 인증 정보는 안전하게 보관하세요. 백업은 복구용으로만 사용하고 공개 문의 게시판에 올리지 마세요. 로그만 확보할 수 있다면 시작 실패 직전과 직후의 기록, 시스템 이벤트 정보를 보관하세요.

실행 환경, 아키텍처, 차단 기록 확인하기

Windows에서 일부 클라이언트의 그래픽 화면은 WebView2 런타임에 의존합니다. 관련 로딩 오류가 나타나면 시스템이나 클라이언트 안내에 나온 공식 경로로 런타임을 복구하세요. 다른 클라이언트가 열린다고 해서 현재 클라이언트에 필요한 실행 환경까지 갖춰져 있다고 볼 수는 없습니다. 설치 파일 아키텍처가 운영체제와 맞는지, 압축을 완전히 풀었는지, 쓰기 권한이 있는 폴더에 설치했는지도 확인하세요. 압축 프로그램의 임시 미리보기 폴더에서 직접 실행하면 리소스 파일이나 데이터 폴더를 사용할 수 없을 수 있습니다.

macOS에서는 앱이 접근 가능한 위치에 제대로 설치됐는지, 시스템 보안 설정에 차단 사유가 기록됐는지 확인하세요. 보안 경고가 나타나면 설치 출처부터 확인하고 시스템 보호 기능을 일괄 해제하지 마세요. Linux에서는 패키지 의존성, 그래픽 세션, 파일 권한 문제를 구분해야 합니다. 터미널에서 앱을 실행하면 화면에 표시되지 않는 의존성 오류를 확인할 수 있습니다. 배포판과 데스크톱 환경마다 차이가 크므로 실제 오류를 기준으로 누락된 의존성만 설치하세요. 데스크톱 구성 요소 전체를 다시 설치하지 마세요.

보안 소프트웨어가 코어를 격리하면 창은 정상인데 연결이 계속 실패할 수 있습니다. 격리 기록과 파일 출처를 확인한 뒤 조치하고, 전체 디스크를 예외 경로로 추가하지 마세요. 포트 충돌도 코어 시작 실패의 원인이 될 수 있습니다. 포트 수신 상태 확인으로 이전 인스턴스가 점유 중인지 확인하세요. 서비스 모드에서는 그래픽 화면과 백그라운드 서비스가 따로 실행될 수 있습니다. 업데이트 후 경로가 일치하지 않으면 클라이언트에서 제공하는 서비스 관리 기능으로 복구하세요.

새 사용자 설정으로 비교하기

실행 환경에 뚜렷한 문제가 없다면 백업은 그대로 두고 기존 설정 폴더 이름을 바꾼 다음 클라이언트가 지원하는 방식으로 새 사용자 설정을 만드세요. 이 작업은 클라이언트를 완전히 종료한 뒤 진행해야 합니다. 데이터베이스를 쓰는 도중 폴더를 옮기지 마세요. 새 설정에서는 실행된다면 기존 상태, 오버라이드 스크립트, 손상된 설정, 화면 저장 데이터가 원인일 가능성이 높습니다. 신뢰할 수 있는 구독 하나만 가져와 정상 작동을 확인한 뒤 사용자 지정 규칙과 설정을 하나씩 복원하세요. 이전 폴더 전체를 새 폴더에 덮어쓰지 마세요.

새 설정으로도 시작할 수 없다면 시스템 앱 로그, 남은 디스크 공간, 폴더 권한을 계속 확인하세요. 시스템 디스크 공간이 부족하면 설정을 저장하지 못할 수 있고, 보호된 폴더가 필요한 데이터 업데이트를 막을 수도 있습니다. 이전에 관리자 권한으로 실행하다가 일반 사용자로 바꾼 경우 데이터 파일의 소유권이나 권한이 맞지 않을 수 있습니다. 해당 클라이언트 데이터 폴더만 복구하세요. 사용자 폴더 전체에 광범위한 쓰기 권한을 주거나 시스템 폴더에 재귀적으로 권한을 변경하지 마세요.

재설치가 필요하면 먼저 기존 프로그램을 정상적으로 제거하거나 종료하고, 클라이언트 안내에 따라 서비스를 처리한 뒤 설치 파일 페이지에서 적절한 빌드를 선택하세요. 새로 설치한다면 Clash Plus를 우선 고려할 수 있습니다. Clash Verge Rev나 FlClash를 사용 중이라면 기존 환경을 먼저 복구해 보세요. 보관된 클라이언트가 새로운 시스템 호환성 문제를 일으킨다면 같은 프로그램을 반복 설치해도 해결되지 않을 수 있습니다. 보안 기능을 계속 꺼 둔 채 사용하는 대신 설정을 이전하는 방안을 고려하세요.

모바일 점검: VPN 권한, 백그라운드 제한, 네트워크 전환

Android에서 연결됨으로 표시되는데 앱이 접속되지 않는 경우

Android에 VPN 아이콘이 표시돼도 시스템이 트래픽 가로채기를 설정했다는 뜻일 뿐, 구독, 아웃바운드, DNS가 모두 정상이라는 보장은 없습니다. 먼저 클라이언트를 화면에 띄운 채 실행하고, 가져온 구성을 선택한 뒤 브라우저로 테스트하고 로그를 확인하세요. 브라우저는 정상인데 특정 앱만 실패한다면 「앱별 프록시」 또는 우회 앱 목록을 확인해 해당 앱이 제외되지 않았는지 살펴봅니다. 클라이언트에 따라 「선택한 앱만 프록시 사용」 또는 「선택한 앱 우회」처럼 목록의 의미가 정반대일 수 있으므로 현재 모드를 먼저 확인하세요.

처음 연결할 때 시스템에서 VPN 트래픽 가로채기 권한을 요청합니다. 거부했다면 시스템 프록시처럼 보이는 옵션만 켜지 말고 클라이언트에서 다시 연결을 시작하세요. Android에서는 일반적으로 여러 VPN 앱이 동시에 트래픽을 가로챌 수 없습니다. 유사 프록시, VPN 기반 필터링 도구, 회사 네트워크 접속이 서로 설정을 대체할 수 있습니다. 테스트할 때는 트래픽 가로채기 도구를 하나만 남기세요. 업무 프로필, 관리 설정, 시스템 상시 연결 VPN에는 별도의 제한이 있을 수 있습니다. 관리되는 기기에서는 조직 정책을 먼저 확인하고 관리 구성 요소를 강제로 삭제하지 마세요.

화면을 잠그면 연결이 끊기거나 네트워크 전환 후 복구되지 않는 경우

화면이 켜져 있을 때는 정상인데 잠근 뒤 연결이 끊기면 배터리 최적화, 백그라운드 활동 권한, 제조사의 자동 시작 관리부터 확인하세요. 먼저 클라이언트가 시스템 요구에 따른 포그라운드 서비스 알림을 계속 표시하는지 확인한 다음 시스템 안내에 따라 필요한 백그라운드 실행을 허용합니다. 모든 끊김이 배터리 최적화 때문은 아닙니다. 네트워크 절전, Wi-Fi와 모바일 데이터 전환, 상위 연결 세션 만료도 비슷한 증상을 일으킵니다. 테스트할 때 화면을 잠근 시각, 네트워크 종류, 앱을 다시 열었을 때 즉시 복구되는지를 기록하세요.

Wi-Fi에서 모바일 데이터로 전환하면 기존 TCP 또는 UDP 세션을 그대로 사용할 수 없는 경우가 있습니다. 새 네트워크에서는 주소, 라우팅, DNS가 모두 바뀌기 때문입니다. 먼저 대상 앱에서 새 연결을 시작하고, 필요하면 클라이언트 연결을 끊었다가 다시 연결하세요. 연결이 복구되기도 전에 노드를 연달아 바꾸면 네트워크 전환 자체의 문제를 파악하기 어렵습니다. 특정 Wi-Fi에서만 실패한다면 같은 아웃바운드를 모바일 데이터와 비교하고, 해당 Wi-Fi에 웹 인증이 필요한지 또는 특정 전송 방식이 제한되는지 확인하세요.

시스템의 「비공개 DNS」와 클라이언트 내장 DNS가 동시에 조회에 영향을 줄 수 있습니다. 도메인 문제가 발생하면 현재 설정을 먼저 기록한 뒤 자동 모드와 클라이언트 권장 설정을 각각 테스트하세요. 모든 DNS를 서로 다른 서비스로 장기간 동시에 설정하지 마세요. 모바일 네트워크는 IPv6를 사용할 수 있습니다. 일부 도메인이나 프로토콜에서만 실패한다면 아웃바운드와 트래픽 가로채기 방식의 IPv6 지원을 확인하세요. 한 곳에서만 IPv6를 꺼도 다른 구성 요소가 해당 주소를 계속 우선 사용할 수 있습니다.

iOS 트래픽 가로채기 상태와 구성 확인

iOS 사용자는 iOS 설치 페이지에서 Clash Plus를 선택할 수 있으며, 제품 정보는 clashplus.io에서 확인할 수 있습니다. 설치 후 구독을 가져오고 구성을 선택한 다음 시스템 안내에 따라 VPN 구성을 추가하도록 허용하세요. 시스템에 연결됨으로 표시되는데 웹페이지가 열리지 않는다면 「대상 요청, 로그, 규칙, 아웃바운드」 순서로 점검해야 합니다. 시스템 연결 상태만으로 원격 서비스까지 정상이라고 판단할 수는 없습니다.

기기에 VPN 구성이 여러 개 있다면 현재 실제로 활성화된 구성을 확인하고, 필요할 때 자동 연결하는 규칙이 다른 트래픽 가로채기 항목을 시작하는지도 살펴보세요. 업무용 기기에는 관리되는 VPN이 있을 수 있으므로 일반 사용자가 임의로 삭제하지 마세요. 일부 네트워크 개인정보 보호 기능, 프로파일, 콘텐츠 필터링 방식도 요청 경로를 바꿀 수 있습니다. 테스트에 영향을 준다는 점이 분명할 때만 잠시 조정하고 테스트 후 복구하세요. 시스템에서 트래픽 가로채기를 시작할 수 없다면 다른 VPN을 정상적으로 끊은 뒤 권한을 다시 허용하고 연결하세요.

모바일에서는 클라이언트의 모바일 데이터 사용이 차단됐는지, 구독 업데이트가 Wi-Fi로 제한됐는지, 데이터 절약 모드가 백그라운드 작업에 영향을 주는지도 확인해야 합니다. 모바일 데이터에서만 구독 업데이트가 실패한다면 앱을 바로 삭제하지 말고 먼저 서비스 주소에 연결할 수 있는지 테스트하세요. 앱을 제거하면 로컬 설정과 규칙까지 함께 사라질 수 있습니다. 재설치하기 전에는 클라이언트가 지원하는 내보내기나 백업 기능으로 필요한 설정을 저장하고 인증 정보가 노출되지 않도록 보호하세요.

추가 문의가 필요하다면 기기 운영체제, 클라이언트 이름, 다른 VPN 사용 여부, 실패한 앱, 네트워크 종류, 같은 시각의 개인정보를 가린 로그를 정리하세요. 초기 설정을 빠뜨렸다면 빠른 시작 가이드를 다시 확인하세요. 구독이나 아웃바운드 문제로 확인됐다면 네트워크별 비교 결과를 함께 준비해 해당 서비스 제공자에게 문의하세요. 여러 기기를 동시에 초기화하기보다 가장 최근에 정상 작동한 설정을 보존하는 편이 복구에 유리합니다.