Clash 연결은 됐는데 인터넷이 안 될 때: 구독·모드·DNS 점검 가이드

‘코어 실행’과 ‘요청 성공’은 다릅니다

Clash 클라이언트에 ‘연결됨’이라고 표시되어도, 그래픽 인터페이스가 로컬 코어에 연결됐거나 시스템 프록시가 켜졌다는 뜻일 수 있습니다. 구독에 포함된 노드가 작동한다거나 브라우저 요청이 올바른 정책 그룹을 거친다는 보장은 없습니다. 전체 연결 과정은 앱에서 요청 전송 → 로컬 프록시 또는 TUN에서 트래픽 처리 → 규칙 매칭 → 정책 그룹 선택 → 노드 연결 → 대상 웹사이트 응답 순입니다. 어느 단계에서든 문제가 생기면 웹페이지가 계속 로딩되는 것처럼 보일 수 있습니다.

Clash는 프록시 코어와 설정 생태계를 통칭하는 이름으로 널리 쓰이며, Clash Meta는 이후 mihomo라는 이름으로 개발을 이어가고 있습니다. 그래픽 클라이언트마다 메뉴 위치, 설정 덮어쓰기 방식, 코어 기능이 다릅니다. 문제를 해결하기 전에 클라이언트의 ‘정보’ 또는 ‘코어’ 화면에서 실제 버전을 확인하세요. 설정은 해당 코어가 지원하는 항목을 기준으로 적용하고, 다른 사람이 사용하는 YAML 파일 전체를 현재 구독 설정에 그대로 덮어쓰지 마세요.

같은 조건에서 테스트하기

현재 설정 이름, 프록시 모드, 정책 그룹에서 선택한 노드, HTTP 또는 혼합 포트, TUN 사용 여부를 기록합니다.
다른 VPN, 프록시 클라이언트, 브라우저 프록시 확장 프로그램은 잠시 끄세요. 여러 연결 경로가 서로 덮어쓰는 상황을 방지하되, 조직에서 요구하는 보안 프로그램은 유지합니다.
평소 프록시 없이 접속할 수 있는 웹사이트와 현재 프록시 경로가 필요한 웹사이트를 하나씩 정하고, 테스트할 때마다 같은 주소를 사용합니다.
클라이언트의 연결 목록과 로그를 열고, 우선 Info 수준으로 문제를 한 번 재현합니다. 정보가 부족하면 Debug를 잠시 켭니다.

1단계: 구독이 유효하고 설정이 적용됐는지 확인

‘구독 업데이트 성공’은 클라이언트가 업데이트 작업을 마쳤다는 뜻일 뿐, 요금제에 데이터가 남아 있거나 방금 받은 설정이 현재 사용 중이라는 뜻은 아닙니다. 설정 또는 구독 화면에서 원하는 설정이 선택되어 있는지 확인한 다음, 프록시 화면에 예상한 노드와 정책 그룹이 표시되는지 살펴보세요. 이전 노드가 계속 보인다면 사용하지 않는 다른 구독을 업데이트했는지 먼저 확인합니다.

요금제 상태: 서비스 제공업체 계정 페이지에서 만료일, 남은 데이터, 기기 제한을 확인하세요. 클라이언트에 표시되는 사용량은 보통 구독 응답 헤더를 기준으로 하므로 정보가 없거나 늦게 반영될 수 있습니다.
다운로드 오류: HTTP 401 또는 403은 인증 실패나 접근 정책 제한, 404는 사용할 수 없는 경로, 429는 요청 횟수 제한을 의미하는 경우가 많습니다. 업데이트 버튼을 연속해서 누르지 마세요.
설정 파일 오류: 로그에 YAML 파싱 실패, 알 수 없는 필드, 정책 그룹을 찾을 수 없다는 메시지가 나타나면 먼저 설정 호환성 문제를 해결하세요. 로그인 페이지나 오류 페이지의 HTML은 Clash 설정으로 사용할 수 없습니다.
원격 리소스: 기본 설정은 적용됐더라도 proxy-providers 또는 rule-providers 업데이트가 실패하면 노드가 누락되거나 규칙이 예상과 다르게 적용될 수 있습니다.

구독을 프록시를 통해서만 업데이트할 수 있고 사용 가능한 노드가 없다면, 서비스 제공업체가 허용하는 범위에서 다른 네트워크를 사용하거나 공식 대체 구독 주소를 시도해 보세요. 전체 구독 URL을 낯선 변환 사이트나 공개 게시판에 붙여 넣지 마세요. URL에 포함된 액세스 토큰은 계정 자격 증명과 같은 역할을 할 수 있습니다.

2단계: 지연 시간만 보지 말고 노드 확인하기

지연 시간 테스트에 성공해도 해당 시점에 지정된 테스트 주소로 탐색 요청이 응답을 받았다는 뜻일 뿐입니다. 테스트 사이트에 접속된다고 대상 웹사이트도 열리는 것은 아니며, 지연 시간이 80ms라고 해서 대역폭이 충분하다는 보장도 없습니다. 웹페이지 접속에는 DNS, TLS, 여러 리소스 도메인, UDP 요청 등이 관여하므로 단일 탐색 테스트보다 복잡합니다.

노드를 직접 선택해 비교 테스트

대상 트래픽을 실제로 처리하는 정책 그룹에서 노드를 직접 선택하세요. 문제를 확인하는 동안 자동 선택 그룹이 출구 노드를 계속 바꾸지 않도록 합니다.
대상 웹사이트에 접속한 뒤 로그에서 시간, 노드 이름, 오류를 기록합니다. 다른 경로의 노드로 바꾼 다음 같은 요청을 반복하세요.
휴대전화 핫스팟으로 바꿔 다시 테스트합니다. 같은 노드가 특정 Wi-Fi에서만 실패한다면 해당 네트워크의 외부 접속 제한, 인증 페이지, DNS를 추가로 확인하세요.

증상	우선 확인할 항목
특정 노드 하나만 계속 시간 초과	노드 서비스, 주소 확인, 포트, 현재 네트워크에서 해당 서버까지의 연결 상태
모든 노드가 실패하지만 직접 연결은 정상	구독 상태, 코어 호환성, 공통으로 사용하는 DNS, 로컬 차단
대부분의 웹사이트는 정상이고 특정 사이트만 실패	대상 웹사이트의 제한, 규칙 적용, 지역 조건, 특정 리소스 도메인
인증서 날짜 오류 발생	기기 시간, 시간대, 시스템 인증서, 네트워크의 HTTPS 검사

로그의 connection refused는 보통 특정 연결 대상이 연결을 거부했다는 뜻이며, i/o timeout은 해당 작업이 제한 시간 안에 완료되지 않았음을 의미합니다. 오류에 표시된 대상 주소를 확인해 어느 구간에서 발생했는지 판단하세요. TLS 오류를 없애려고 인증서 검증을 건너뛰는 옵션을 바로 켜지 말고, 먼저 시스템 시간을 맞추고 노드 설정을 확인하세요.

3단계: 프록시 모드로 문제 범위 좁히기

규칙 모드는 규칙 목록에 따라 트래픽을 전달할 정책을 결정합니다. 전역 모드는 코어가 처리하는 요청을 전역 정책으로 보내고, 직접 연결 모드는 대상에 바로 연결합니다. 여기서 ‘전역’은 아웃바운드 정책을 뜻할 뿐, 모든 앱이 자동으로 Clash를 거친다는 의미는 아닙니다. 시스템 프록시를 사용하지 않고 프록시를 별도로 설정하지 않았으며 TUN에도 연결되지 않은 프로그램은 코어를 우회할 수 있습니다.

먼저 규칙 모드에서 문제를 재현하고 연결 목록에 표시되는 규칙과 출구를 기록합니다.
전역 모드로 잠시 전환하고, 앞 단계에서 확인한 노드를 직접 선택한 다음 같은 웹페이지를 엽니다.
전역 모드에서는 되지만 규칙 모드에서는 실패한다면 규칙, 정책 그룹, 직접 연결 경로의 DNS를 집중적으로 확인합니다. 두 모드 모두 실패하면 프록시 연결 지점과 DNS를 계속 확인하세요.
테스트가 끝나면 규칙 모드로 되돌리세요. 프록시가 필요 없는 트래픽을 전역 출구로 계속 보내지 않도록 합니다.

4단계: 시스템 프록시와 로컬 수신 포트가 일치하는지 확인

아래 명령은 클라이언트에서 mixed-port: 7890을 실제로 사용한다고 가정합니다. 7890은 예시이므로 화면에 표시된 실제 포트로 바꿔야 합니다. 혼합 포트는 HTTP와 SOCKS 프록시 연결을 모두 받을 수 있지만, 전용 SOCKS 포트를 HTTP 프록시로 지정하면 안 됩니다. 데스크톱의 로컬 프록시 주소는 일반적으로 127.0.0.1이며, 같은 컴퓨터의 브라우저에서 접속하기 위해 LAN 공유를 켤 필요는 없습니다.

시스템 설정과 프록시를 지정한 요청 확인

Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 수동 프록시와 설정 스크립트를 확인할 수 있습니다. macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’로 이동하세요. 클라이언트가 시스템 프록시를 설정했다면 포트가 실제 수신 포트와 일치해야 합니다. Firefox처럼 브라우저 자체 프록시 설정을 사용하는 경우도 있습니다. ‘설정’ → ‘일반’ → ‘네트워크 설정’ → ‘설정’에서 시스템 프록시를 사용할지, 별도 포트를 지정했는지 확인하세요.

Windows PowerShell에서 먼저 포트가 수신 중인지 확인한 뒤, HTTP 프록시를 지정한 요청으로 테스트합니다. 구형 PowerShell의 같은 이름 별칭과 충돌하지 않도록 curl.exe를 사용하세요.

Windows PowerShell

Get-NetTCPConnection -State Listen -LocalPort 7890
curl.exe -I --connect-timeout 10 --max-time 20 -x http://127.0.0.1:7890 https://example.com/
curl.exe -I --connect-timeout 10 --max-time 20 --noproxy "*" https://example.com/

macOS와 Linux에서는 아래 요청을 비교 테스트에 사용할 수 있습니다. 테스트 주소는 공개된 예시이므로, 이후 실제로 열리지 않는 사이트 주소로 바꾸세요. -I는 HEAD 요청을 보냅니다. 이를 지원하지 않는 사이트라면 -o /dev/null -v로 일반 GET 요청을 보낼 수 있습니다.

macOS / Linux 터미널

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

127.0.0.1에 즉시 연결할 수 없음: 코어가 실행 중인지, 포트가 변경됐는지, 해당 포트를 수신하는 프로세스가 현재 클라이언트 소속인지 확인하세요.
프록시를 지정한 요청은 성공하지만 브라우저는 실패: 브라우저 프록시 확장 프로그램, PAC 스크립트, 별도 프록시 설정, 캐시에 남은 이전 연결을 먼저 확인하세요.
HTTP 407 발생: 로컬 프록시에서 인증을 요구하는지 확인하세요. 원격 노드 문제라고 단정할 수 없습니다.
연결 터널이 만들어진 뒤 TLS 실패: 터널이 만들어졌다고 웹페이지 접속까지 성공한 것은 아닙니다. TLS 오류와 코어 로그를 계속 확인하세요.

--noproxy "*"는 curl의 애플리케이션 프록시 설정만 우회하며 TUN이나 다른 VPN은 우회하지 않습니다. 실제 직접 연결 경로와 비교하려면 현재 상태를 기록한 뒤 관련 트래픽 처리 기능을 잠시 꺼야 합니다. 터미널이 데스크톱 시스템 프록시 설정을 읽는다는 보장도 없습니다. 오래된 환경 변수가 요청을 다른 포트로 보내지 않도록 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY를 확인하세요.

5단계: 어느 계층에서 DNS가 실패하는지 구분

DNS와 관련된 대상은 최소 세 가지입니다. 노드 서버 도메인, 사용자가 접속하는 웹사이트 도메인, 암호화된 DNS 서비스의 도메인입니다. 노드 서버 도메인을 확인할 수 없으면 프록시 터널도 만들어지지 않는 경우가 많습니다. 대상 도메인 확인에 실패하면 특정 사이트에서만 오류가 날 수 있습니다. DNS 상위 서버가 아직 연결되지 않은 프록시 경로에 의존하면 순환 참조가 발생할 수도 있습니다.

DNS를 바꾸기 전에 먼저 상태 확인

로그에 lookup, no such host, DNS timeout 같은 메시지가 있는지 확인하고 해당 도메인도 기록하세요.
Windows에서는 Resolve-DnsName example.com, macOS 또는 Linux에서는 nslookup example.com으로 시스템 DNS 조회를 확인한 뒤 클라이언트 로그 결과와 비교하세요.
브라우저의 보안 DNS 설정을 확인하세요. 브라우저에 내장된 DoH가 DNS 조회 경로를 바꿀 수 있습니다. 잠시 꺼서 다시 테스트한 다음 필요에 따라 원래 설정으로 되돌리세요.
시스템 DNS 캐시가 오래된 것이 확인된 경우에만 Windows에서 ipconfig /flushdns를 실행한 뒤 브라우저 연결을 다시 설정하세요.

시스템 DNS 조회에 성공해도 코어의 DNS가 정상이라는 뜻은 아닙니다. 두 경로에서 서로 다른 상위 서버를 사용할 수 있습니다. 반대로 시스템 DNS 조회가 실패해도 프록시를 통한 도메인 요청까지 반드시 실패하는 것은 아닙니다. 코어나 원격 서버에서 도메인을 확인할 수도 있습니다. nslookup 한 번만으로 모든 DNS 항목을 일괄 변경하지 마세요.

fake-ip 모드에서는 설정의 fake-ip-range에서 할당한 합성 주소가 표시될 수 있으며, 이는 정상일 수 있습니다. 예를 들어 198.18.0.0/16이 흔히 사용됩니다. 이 주소는 코어가 도메인과 연결을 연결해 관리하기 위한 것으로 실제 웹사이트 주소가 아닙니다. 앱이 합성 주소를 받은 뒤 트래픽이 이를 처리하는 코어로 돌아가지 않으면 연결이 실패합니다. hosts 파일에 합성 주소를 추가하지 말고 라우팅, DNS 가로채기, 다른 VPN과의 충돌을 확인하세요.

6단계: 규칙 적용과 정책 그룹의 최종 출구 확인

전역 모드에서는 되지만 규칙 모드에서 실패한다면 연결 목록을 열고 대상 도메인으로 요청을 찾아 적용된 규칙과 정책 경로를 확인하세요. 규칙은 일반적으로 위에서 아래 순서로 적용됩니다. 앞쪽의 광범위한 규칙이 요청을 먼저 처리할 수 있습니다. MATCH는 마지막에 사용하는 기본 규칙이므로, 적용되어야 할 다른 규칙보다 앞에 두면 안 됩니다.

아래 예시는 규칙 순서만 보여 주며 구독 설정 전체를 대체할 수 없습니다. example.com과 하위 도메인을 ‘웹 프록시’라는 정책 그룹으로 보내고 나머지는 직접 연결합니다. 사용하기 전에 해당 그룹이 실제로 존재하고 사용 가능한 노드가 선택되어 있는지 확인하세요.

규칙 순서 예시

rules:
  - DOMAIN-SUFFIX,example.com,웹 프록시
  - MATCH,DIRECT

DIRECT가 적용됨: 직접 연결이 의도한 동작인지, 현재 네트워크에서 해당 사이트에 직접 접속할 수 있는지 확인하세요.
REJECT가 적용됨: 차단 규칙이나 규칙 세트에 대상 도메인이 잘못 포함됐는지 확인하세요. 모든 보호 규칙을 한꺼번에 끄지 마세요.
프록시 그룹이 적용됐는데도 실패: 정책 경로를 펼쳐 최종 노드를 확인하세요. 그룹 이름이 같아도 출구가 같다는 보장은 없습니다.
메인 페이지는 열리지만 이미지나 로그인이 실패: CDN, 인증, API 도메인을 확인하세요. 요청마다 서로 다른 정책이 적용됐을 수 있습니다.

규칙 세트 다운로드 실패, 클라이언트의 로컬 덮어쓰기, 프로세스 규칙, 구독 업데이트가 최종 설정을 바꿀 수 있습니다. 구독 원본 파일뿐 아니라 현재 적용 중인 설정과 연결 기록을 확인하세요. 설정을 바꾼 뒤 새로 요청해야 합니다. 기존 장시간 연결은 이전 경로를 계속 사용할 수 있습니다.

7단계: 필요한 경우에만 TUN, IPv6, UDP 확인

브라우저에서 프록시를 지정한 요청은 성공하지만 게임, 터미널 또는 다른 앱이 실패하면 먼저 해당 앱이 프록시를 지원하는지 확인하세요. 모든 프로그램이 시스템 프록시 설정을 따르는 것은 아닙니다. 더 넓은 범위의 트래픽 처리가 필요할 때만 TUN을 고려하세요. TUN을 켠 뒤에도 라우팅, 권한, DNS 설정이 올바른지 확인해야 합니다. 스위치만 켠다고 모든 문제가 해결되는 것은 아닙니다.

TUN 및 권한: 서비스 모드나 필요한 권한이 준비됐는지 확인하고, 가상 인터페이스 또는 라우팅 생성 실패 메시지가 로그에 있는지 살펴보세요.
네트워크 충돌: 필수적이지 않은 다른 VPN을 잠시 끈 뒤 다시 테스트하고, 라우팅 우선순위, 가상 네트워크 어댑터, DNS 처리 간 충돌을 확인하세요.
IPv6: 대상에 AAAA 레코드가 있는지, 실제 연결이 IPv6를 사용하는지 확인하세요. IPv4는 되지만 IPv6가 실패한다면 해당 경로나 출구를 수정하세요. 시스템 전체에서 IPv6를 끄는 것을 기본 해결책으로 삼지 마세요.
UDP 및 QUIC: 일부 브라우저는 UDP 443으로 HTTP/3을 사용합니다. TCP 웹 요청은 성공하지만 UDP를 사용하는 앱이 실패한다면 노드 프로토콜, 서버, 로컬 트래픽 처리 경로가 UDP를 지원하는지 확인하세요.

필요하다면 비교 테스트를 위해 브라우저 QUIC을 잠시 끌 수 있지만, 이를 일반적인 속도 향상 설정으로 여기지는 마세요. 큰 페이지는 멈추고 작은 요청은 정상이라면 경로 MTU, 패킷 손실, 네트워크 혼잡도 고려해야 합니다. 먼저 재현 상황을 기록하고 MTU 숫자를 여러 개 연속으로 시험하지 마세요.

마무리: 최소 설정으로 되돌리고 문제 기록 정리

원인을 찾은 뒤 규칙 모드, 평소 사용하는 DNS, 필요한 트래픽 처리 방식을 복구하고 비교 테스트용 임시 변경을 되돌리세요. 클라이언트를 종료한 뒤에도 수신 중인 프로그램이 없는 포트를 가리키는 시스템 프록시 설정을 남겨 두지 마세요. 클라이언트를 종료한 뒤 모든 웹페이지가 열리지 않는다면 브라우저를 바로 다시 설치하지 말고 시스템 프록시가 여전히 127.0.0.1:7890을 가리키는지 먼저 확인하세요.

문제 신고 시 다음 정보를 함께 전달

운영체제 버전, 클라이언트 버전, 실제 코어 버전, TUN·시스템 프록시·브라우저 보안 DNS 사용 여부
문제 발생 시각, 대상 도메인, 재현 단계, 전체 사이트에 영향을 주는지 특정 사이트에만 발생하는지
같은 사이트를 규칙 모드, 전역 모드, 다른 노드, 다른 네트워크에서 테스트한 결과
민감 정보를 삭제한 오류 로그, 적용된 규칙, 최종 출구. 구독 토큰, 노드 비밀번호, 전체 설정의 인증 정보는 공유하지 마세요.

‘여러 번 재시작했다’는 정보보다 ‘프록시를 지정한 요청은 성공하지만 브라우저는 실패한다’ 또는 ‘전역 모드는 성공하고 규칙 모드에서 DIRECT가 적용되면 실패한다’는 결과가 훨씬 유용합니다. 연결 단계를 나누어 확인한 근거가 있으면 문제를 앱 연결, 노드, DNS, 규칙 중 하나로 좁힐 수 있어 설정을 반복해서 바꾸며 새 문제가 생기는 일을 줄일 수 있습니다.