Clash는 연결됐지만 인터넷이 안 될 때: 시스템 프록시·DNS·규칙 모드 문제 해결 체크리스트

STATE DEFINITION

먼저 ‘연결됨’이 정확히 무엇을 의미하는지 확인하세요

Clash 클라이언트에 ‘실행 중’, ‘연결됨’이 표시되거나 VPN 아이콘이 나타나는 것은 보통 코어가 시작되고 설정 파일이 로드되었거나, 시스템에서 VPN 인터페이스 권한을 부여했다는 뜻입니다. 브라우저 트래픽이 Clash로 들어왔다는 의미도 아니며, 현재 정책 그룹에서 선택한 노드가 대상 주소에 접속할 수 있다는 보장도 아닙니다. 문제를 해결할 때는 ‘프로그램 상태’, ‘트래픽 유입 경로’, ‘규칙 판단’, ‘노드 출구’를 나누어 확인해야 합니다.

웹 요청은 대략 다음 경로를 거칩니다. 애플리케이션이 연결을 시작하면 운영체제가 프록시 설정이나 라우팅에 따라 트래픽을 Clash로 전달하고, Clash가 대상 도메인을 해석합니다. 이후 규칙 엔진이 프록시 그룹, DIRECT 또는 REJECT를 결정하고, 프록시 그룹이 실제 노드를 선택한 다음 노드가 원격 연결을 수립합니다. 어느 한 단계에서든 문제가 생기면 페이지가 계속 로딩되거나, 도메인 해석이 실패하거나, 연결이 재설정되거나, 일부 애플리케이션만 인터넷에 연결되지 않을 수 있습니다.

TRAFFIC PATH

로컬 네트워크에서 게이트웨이에 연결할 수 있고 기기에 유효한 주소가 할당되어 있습니다.
애플리케이션 트래픽이 시스템 프록시 또는 TUN 인터페이스를 통해 Clash로 들어옵니다.
DNS가 사용할 수 있는 결과를 반환하고 Fake-IP 매핑이 정상적으로 작동합니다.
규칙이 예상한 정책 그룹에 매칭되며 잘못된 DIRECT 또는 REJECT로 처리되지 않습니다.
정책 그룹에서 선택한 노드가 TCP, UDP 또는 QUIC 연결을 수립할 수 있습니다.
방화벽, 보안 프로그램 및 다른 VPN이 중간에서 트래픽을 차단하지 않습니다.

스위치를 반복해서 켜고 끄는 것보다 클라이언트의 연결 기록을 확인하는 편이 효과적입니다. 웹페이지를 연 뒤 연결 목록에 새 항목이 전혀 없다면 문제는 대개 시스템 프록시, TUN 라우팅 또는 애플리케이션 자체의 프록시 설정에 있습니다. 연결 기록은 있지만 DNS 오류가 표시되면 DNS 설정을 확인해야 합니다. 특정 정책 그룹에 매칭된 기록과 시간 초과가 함께 나타난다면 노드와 상위 네트워크를 점검하세요.

NETWORK BASELINE

프록시를 끄고 기본 네트워크 확인

문제 해결을 시작할 때는 설정 파일은 유지한 채 시스템 프록시와 TUN 모드를 잠시 끄세요. 구독을 삭제하거나 클라이언트를 바로 재설치할 필요는 없습니다. 그런 다음 로컬 게이트웨이, 일반 웹사이트, DNS를 차례로 테스트합니다. 이렇게 하면 ‘네트워크 자체가 끊긴 경우’와 ‘트래픽이 Clash를 거친 뒤 끊긴 경우’를 구분할 수 있습니다. Clash를 끈 뒤에도 어떤 웹사이트도 열리지 않는다면 프록시 규칙을 수정하기보다 Wi-Fi, 모바일 네트워크, 라우터 인증, 학교 네트워크 로그인 또는 통신사 연결부터 해결해야 합니다.

주소, 게이트웨이 및 네트워크 인증 확인

기기에 정상적인 IPv4 또는 IPv6 주소가 할당되었는지 확인하세요. 자동으로 할당된 비정상적인 로컬 주소라면 안 됩니다.
호텔, 공항, 학교 네트워크 등에서는 먼저 웹 인증을 완료한 뒤 시스템 프록시나 TUN을 시작하세요.
Wi-Fi를 모바일 핫스팟으로 바꿔 테스트하세요. 핫스팟에서는 작동하고 기존 네트워크에서만 실패한다면 해당 네트워크의 DNS, UDP 제한, 방화벽 정책을 중점적으로 확인하세요.
시스템 날짜와 시간대를 확인하세요. 시간 오차가 크면 TLS 인증서 검증이 실패해 여러 HTTPS 웹사이트가 동시에 열리지 않을 수 있습니다.

단계별 테스트로 DNS와 연결 문제 구분

먼저 IP 연결을 테스트한 다음 도메인 해석을 테스트하세요. Windows에서는 터미널에서 ping 1.1.1.1과 nslookup example.com을 사용할 수 있습니다. macOS와 Linux에서는 ping -c 4 1.1.1.1, dig example.com 또는 nslookup example.com을 사용하세요. 일부 네트워크는 ICMP를 제한하므로 ping 실패만으로 인터넷 연결이 끊겼다고 단정할 수 없습니다. 브라우저 접속과 DNS 조회 결과도 함께 확인해야 합니다.

TRAFFIC INGRESS

시스템 프록시, 포트 및 TUN 트래픽 유입 경로 확인

Clash의 일반적인 트래픽 가로채기 방식은 시스템 프록시와 TUN입니다. 시스템 프록시는 운영체제의 HTTP, HTTPS 또는 SOCKS 프록시 설정을 따르는 애플리케이션에 주로 영향을 줍니다. TUN은 가상 네트워크 인터페이스와 라우팅을 이용해 더 넓은 범위의 TCP 및 UDP 트래픽을 처리합니다. 두 방식 모두 클라이언트에서 통합 관리할 수 있지만, 문제 해결 단계에서는 현재 어느 방식을 사용하는지 분명히 해야 노드 문제와 시스템 프록시 문제를 혼동하지 않습니다.

시스템 프록시는 켜져 있지만 브라우저 연결 기록이 없음

먼저 시스템 프록시 주소가 로컬 루프백 주소를 가리키고 있는지, 포트가 현재 설정의 수신 포트와 일치하는지 확인하세요. 일반적인 설정에서는 mixed-port를 사용해 HTTP와 SOCKS 연결을 함께 수락합니다. 오래된 설정에서는 port와 socks-port를 각각 사용할 수도 있습니다. 클라이언트가 설정을 갱신해 포트가 바뀌었는데 운영체제에는 이전 포트가 남아 있으면 브라우저에 프록시 서버 연결이 거부되었다는 메시지가 즉시 표시됩니다.

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

브라우저나 애플리케이션에 별도 프록시가 설정되어 있는지도 확인하세요. 별도 프록시가 시스템 설정보다 우선 적용될 수 있으며, 이미 종료된 다른 클라이언트를 계속 가리키고 있을 수도 있습니다. 명령줄 도구가 데스크톱 운영체제의 프록시 설정을 자동으로 읽는 것도 아닙니다. 터미널 프로그램만 실패한다면 Clash 전체가 작동하지 않는다고 판단하기보다 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 환경 변수를 확인하세요.

TUN은 켜져 있지만 모든 요청이 시간 초과됨

TUN 모드는 가상 인터페이스, 라우팅 테이블 및 시스템 권한에 의존합니다. 처음 활성화할 때 Windows에서는 네트워크 구성 요소를 설치하거나 시작하기 위해 관리자 권한을 요구할 수 있고, macOS, iOS, Android에서는 VPN 권한을 요청합니다. 권한이 취소되었거나 가상 인터페이스 초기화에 실패했거나 기본 경로가 기록되지 않으면 화면에는 코어가 실행 중으로 표시되더라도 실제 트래픽은 처리 경로에 제대로 들어가지 않을 수 있습니다.

다른 VPN, 네트워크 가속기 및 유사한 프록시를 끈 뒤 다시 테스트하세요. 여러 프로그램이 동시에 기본 경로나 DNS를 변경하면 라우팅 우선순위 충돌이 발생하기 쉽습니다. TUN만 끄고 시스템 프록시를 켰을 때 브라우저가 다시 작동한다면 노드와 기본 프록시 포트는 대체로 정상이며, 문제 범위는 TUN 권한, 인터페이스 스택, 라우팅, DNS 가로채기 설정으로 좁힐 수 있습니다.

DNS PIPELINE

DNS 해석, Fake-IP 및 캐시 문제 확인

DNS 문제는 도메인을 입력하면 열리지 않지만 IP로 직접 접속하면 응답이 있거나, 연결 로그에 해석 시간 초과가 계속 나타나거나, 일부 도메인만 정상이고 다른 도메인은 실패하거나, 네트워크를 바꾼 뒤에도 이전 결과가 계속 사용되는 형태로 나타납니다. Clash Meta, 즉 mihomo는 내장 DNS 모듈을 통해 일반 해석, Fake-IP 매핑, 분할 조회 및 폴백 판단을 수행할 수 있습니다. 설정 필드가 유효하다고 해서 상위 DNS가 현재 네트워크에서 반드시 연결 가능하다는 뜻은 아닙니다.

조회가 Clash에 도달하는지 먼저 확인

DNS 로그를 활성화하거나 클라이언트 로그를 확인하면서 테스트 도메인에 접속할 때 조회 기록이 나타나는지 확인하세요. 시스템이 여전히 이전 DNS 서버에 조회를 보내고 있다면 TUN의 DNS 가로채기가 적용되지 않았거나 브라우저에서 별도의 보안 DNS를 사용 중일 수 있습니다. 문제를 해결할 때는 브라우저의 독립 DNS를 잠시 꺼서 조회 경로를 하나로 유지하세요. Clash DNS가 정상임을 확인한 뒤 필요에 따라 다시 활성화하면 됩니다.

상위 프로토콜과 네트워크 환경 확인

기존 UDP DNS, TCP DNS, DoH, DoT는 서로 다른 네트워크 조건을 요구합니다. 모바일 네트워크에서 연결되는 상위 주소가 회사나 학교 네트워크에서도 연결된다는 보장은 없습니다. 특히 프록시 노드가 아직 연결되지 않은 상태에서 도메인 형식의 프록시 서버 주소가 프록시를 통해서만 접근 가능한 DNS에 의존하면 시작 단계에서 의존성 순환이 발생할 수 있습니다. 프록시 서버 도메인을 해석하는 기본 DNS는 현재 로컬 네트워크에서 직접 접근할 수 있어야 합니다.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - 223.5.5.5

위 예시는 필드 간 관계만 보여 주는 것이므로 기존 구독 설정을 그대로 덮어쓰면 안 됩니다. 구독 제공자나 클라이언트의 덮어쓰기 기능이 설정을 관리한다면 해당 덮어쓰기 계층에서 수정해야 하며, 그렇지 않으면 다음 구독 갱신 때 로컬 편집 내용이 사라집니다. IPv6를 활성화했지만 로컬 네트워크의 IPv6 라우팅이 불안정하면 애플리케이션이 연결할 수 없는 주소를 먼저 시도할 수 있습니다. 비교 테스트를 위해 Clash DNS의 IPv6 반환을 잠시 끌 수는 있지만, 최종 설정은 반복적인 시행착오가 아니라 실제 네트워크 환경에 맞춰 결정해야 합니다.

Fake-IP 모드에서 나타나는 특수 현상

Fake-IP는 먼저 애플리케이션에 예약 주소를 반환한 뒤 코어가 도메인 매핑에 따라 후속 연결을 처리합니다. 따라서 198.18.0.0/16 범위의 주소가 보이는 것은 일반적으로 정상적인 작동 방식이며, 도메인이 공인망의 잘못된 주소로 해석되었다는 뜻이 아닙니다. 실제로 확인해야 할 것은 애플리케이션 연결이 Clash에 포착되었는지와 매핑 기록이 남아 있는지입니다. DNS 조회는 Clash를 통과했지만 후속 연결이 Clash를 우회하면 애플리케이션이 받은 Fake-IP로는 직접 접속할 수 없습니다.

로컬 네트워크 장치 검색, 프린터, 라우터 관리 도메인 및 실제 주소에 의존하는 일부 서비스는 Fake-IP 필터에 추가해야 할 수 있습니다. 필터는 명확한 도메인에 한해 설정하고, 넓은 범위의 도메인을 모두 제외하지 않는 것이 좋습니다. 그렇지 않으면 규칙 매칭과 DNS 분할 결과를 예측하기 어려워집니다. 변경 후에는 시스템 DNS 캐시를 지우고 영향을 받은 애플리케이션을 완전히 종료한 뒤 다시 시작해 이전 연결 풀이 과거 결과를 계속 사용하지 않도록 하세요.

RULE DECISION

규칙 모드, 정책 그룹 및 노드 출구 확인

연결 기록이 나타났다면 각 요청이 어떤 규칙에 매칭되었는지, 어느 정책 그룹으로 전달되었는지, 정책 그룹이 최종적으로 어떤 노드를 선택했는지 확인하세요. Clash의 규칙은 선언된 순서대로 매칭되며, 일반적으로 적용 가능한 첫 번째 규칙을 찾으면 이후 규칙을 계속 검색하지 않습니다. 앞쪽의 범용 규칙이 뒤쪽의 정밀한 규칙을 가릴 수 있고, 마지막의 MATCH는 앞에서 매칭되지 않은 요청을 처리합니다.

모드 전환으로 비교하되 글로벌 모드를 해결책으로 사용하지 마세요

규칙 모드를 잠시 글로벌 모드로 전환하고 이미 사용 가능하다고 확인한 노드를 선택하세요. 웹사이트가 정상화되면 시스템 프록시, DNS 기본 경로, 노드 출구는 정상일 가능성이 높고, 문제는 규칙 세트나 정책 그룹 선택 또는 DIRECT 라우팅에 있을 수 있습니다. 글로벌 모드에서도 실패한다면 노드, 프로토콜 호환성, 방화벽을 계속 확인해야 합니다. 비교가 끝나면 규칙 모드로 되돌리고 구체적인 규칙을 수정하세요. 글로벌 모드로 잘못된 매칭을 장기간 가리는 것은 피해야 합니다.

직접 연결 모드는 로컬 웹사이트가 잘못 프록시로 전달되는지 확인하는 데도 사용할 수 있습니다. DIRECT에서는 접속되지만 규칙 모드에서 실패한다면 해당 도메인이 프록시 그룹에 매칭되는지, 선택한 노드가 대상에 적합한지 확인하세요. 반대로 프록시 모드에서는 접속되지만 DIRECT에서 시간 초과가 발생한다면 현재 로컬 네트워크의 직접 연결 경로를 사용할 수 없는 것이므로 적절한 프록시 정책으로 처리해야 합니다.

정책 그룹 이름이 존재한다고 해서 사용 가능한 노드가 선택된 것은 아닙니다

select 유형의 정책 그룹은 구성원을 직접 선택해야 합니다. url-test는 테스트 주소와 주기에 따라 자동으로 선택하고, fallback은 일반적으로 사용 가능성 순서에 따라 전환합니다. 자동 테스트 결과는 특정 시점에 테스트 주소로 연결한 상태만 반영하므로 모든 웹사이트, 모든 프로토콜 또는 장시간 연결의 안정성을 완전히 나타내지는 못합니다. 지연 시간은 정상인데 웹페이지가 열리지 않는다면 정책 그룹의 속도 측정 결과만 보지 말고 실제 요청 로그를 확인하세요.

정책 그룹이 REJECT, 사용할 수 없는 노드 또는 이미 만료된 하위 정책 그룹을 선택하고 있지 않은지 확인하세요.
서로 다른 지역과 회선의 노드 두 개를 수동으로 전환하며 같은 웹사이트를 반복 테스트하세요.
TCP 웹페이지는 정상인데 게임, 음성 통화 또는 QUIC만 문제가 있다면 노드가 UDP를 지원하는지, TUN이 UDP를 처리하는지 확인하세요.
특정 웹사이트만 실패한다면 도메인 규칙, IP 규칙, 규칙 세트 업데이트 상태, 최종 MATCH 처리 대상을 확인하세요.
구독을 갱신한 직후 문제가 생겼다면 정책 그룹 이름과 규칙 참조가 여전히 일치하는지 확인하세요. 규칙이 더 이상 존재하지 않는 그룹을 가리키는 경우가 있습니다.

SYSTEM BOUNDARY

방화벽, 포트 충돌 및 다른 네트워크 소프트웨어 점검

다른 기기에서는 설정이 작동하지만 현재 기기에서만 계속 실패한다면 운영체제 수준의 제한을 확인해야 합니다. 방화벽은 클라이언트 화면의 실행은 허용하면서 코어 프로세스의 외부 연결을 차단할 수 있고, 보안 정책은 로컬 프로그램이 프록시 포트를 수신하는 것을 막을 수 있습니다. 클라이언트 업데이트 후 코어 파일 경로가 바뀌면 기존 허용 규칙이 새 경로에 자동으로 적용되지 않을 수 있으므로 네트워크 권한을 다시 확인하세요.

현재 Clash 코어가 포트를 수신 중인지 확인

Windows에서는 netstat -ano | findstr 7890으로 포트와 프로세스 번호를 확인할 수 있습니다. macOS와 Linux에서는 lsof -i :7890을 사용하세요. 포트를 다른 프로그램이 이미 사용 중이면 Clash 로그에 대개 수신 실패가 표시됩니다. 이때는 충돌하는 프로그램을 종료하거나 설정과 시스템 프록시에서 포트를 함께 변경해야 하며, 한 곳만 수정해서는 안 됩니다.

여러 트래픽 가로채기 프로그램을 중복으로 사용하지 마세요

기업용 VPN, 가상 머신 네트워크, 컨테이너 네트워크, 게임 가속 도구, 트래픽 필터링 프로그램은 라우팅을 변경하거나 가상 네트워크 카드를 설치하거나 DNS를 수정할 수 있습니다. 문제를 해결할 때는 하나씩 종료하고, 변경할 때마다 기본 경로와 연결 기록을 확인하세요. 시스템을 재시작한 직후 잠시 정상으로 돌아왔다가 특정 네트워크 프로그램을 시작하면 다시 끊긴다면 충돌 원인을 추적하는 단서가 됩니다.

로컬 네트워크 공유 환경은 추가 점검이 필요합니다

다른 기기가 로컬 네트워크를 통해 이 기기의 Clash에 연결한다면, 현재 기기 설정에서 LAN 접근을 허용하고 프록시 포트가 시스템 방화벽을 통과하도록 해야 합니다. 클라이언트 기기에는 Clash가 실행 중인 기기의 로컬 네트워크 주소를 입력해야 하며 127.0.0.1을 입력해서는 안 됩니다. 루프백 주소는 항상 클라이언트 기기 자체를 가리키기 때문입니다. 접근 제어를 위해 신뢰할 수 있는 네트워크에서만 수신을 개방하고, 클라이언트가 지원하는 인증 필드로 사용 범위를 제한하세요.

RECOVERY CHECKLIST

정해진 순서로 설정을 복구하고 재확인

개별 테스트를 마쳤다면 임시 변경 사항을 안정적인 설정으로 정리해야 합니다. 여러 임시 DNS, 중복 규칙 또는 글로벌 모드를 계속 유지하지 마세요. 다음 순서는 대부분의 데스크톱 및 모바일 클라이언트에 적합하며, 문제 해결 결과를 설정 관리자에게 전달하기도 쉽습니다.

기본 네트워크 확인: 시스템 프록시와 TUN을 끄고 현재 네트워크에서 인증을 완료한 뒤 일반 사이트에 접속할 수 있는지 확인합니다.
코어 시작: 설정을 로드한 뒤 시작 로그를 확인하고 YAML 해석, 포트 수신, 규칙 세트 로드가 성공했는지 확인합니다.
시스템 프록시만 활성화: 브라우저로 테스트 웹사이트에 접속해 연결 목록에 기록이 나타나는지 확인합니다.
DNS 확인: 도메인 조회 결과와 로그를 확인하고 캐시를 삭제한 뒤 같은 도메인을 다시 테스트합니다.
노드 확인: 글로벌 모드에서 잠시 알고 있는 정상 노드를 선택한 다음 규칙 모드로 돌아와 결과를 비교합니다.
규칙 확인: 실제 매칭 항목, 정책 그룹, 최종 노드를 확인하고 잘못된 DIRECT, REJECT 또는 그룹 이름 참조를 수정합니다.
TUN만 활성화: VPN 권한, 가상 인터페이스, 라우팅이 정상인지 확인한 뒤 시스템 프록시를 따르지 않는 애플리케이션을 테스트합니다.
보안 경계 복구: 필요한 방화벽과 네트워크 소프트웨어를 다시 활성화하고 충돌이 발생하는지 하나씩 확인합니다.

자주 나타나는 증상과 우선 점검 항목

연결 목록이 비어 있음: 시스템 프록시 주소, 포트, 애플리케이션의 별도 프록시, TUN 권한 및 라우팅 처리를 먼저 확인하세요.
도메인은 실패하지만 IP에는 연결됨: Clash DNS, 시스템 DNS, 브라우저의 별도 DNS, 상위 DNS 연결 가능 여부 및 캐시를 먼저 확인하세요.
글로벌 모드는 되지만 규칙 모드는 실패함: 규칙 순서, 규칙 세트 상태, MATCH 처리 대상, 정책 그룹 참조, DIRECT 경로를 확인하세요.
브라우저는 되지만 다른 애플리케이션은 실패함: 애플리케이션이 시스템 프록시를 우회하는지 확인하고, 필요한 경우 TUN 처리와 UDP 지원을 점검하세요.
모든 노드에서 동시에 시간 초과: 먼저 로컬 네트워크, DNS, 시스템 시간, 방화벽, 외부 연결 제한을 확인한 뒤 구독 노드 상태를 판단하세요.
구독 갱신 후 작동하지 않음: 설정 해석 로그, 정책 그룹 이름, 규칙 참조, 덮어쓰기 내용, 클라이언트 필드 호환성을 확인하세요.

문제가 계속되면 최소한의 진단 기록을 정리해 보세요. 운영체제와 클라이언트 버전, 코어 유형, 트래픽 가로채기 방식, 문제가 발생한 시간, 테스트 네트워크, 규칙 모드, 매칭된 정책, 민감 정보를 삭제한 오류 로그를 포함하면 됩니다. 전체 설정 파일이나 구독 링크는 공개하지 마세요. ‘이미 재설치했다’는 정보보다 명확한 연결 경로가 문제를 찾는 데 도움이 되며, 원인과 무관한 설정을 반복해서 변경하는 일도 줄일 수 있습니다.