먼저 ‘연결됨’이 정확히 어느 계층을 의미하는지 확인하세요
Clash 클라이언트에서 ‘시스템 프록시 사용’, ‘VPN 연결됨’ 또는 ‘커널 실행 중’으로 표시되는 것은 로컬 프록시 진입점이 시작되었다는 뜻일 뿐입니다. 원격 노드를 사용할 수 있다는 의미도, 브라우저 트래픽이 Clash로 들어왔다는 의미도 아닙니다. 전체 경로에는 최소한 애플리케이션, 시스템 프록시 또는 TUN, mihomo 커널, 규칙 매칭, DNS, 프록시 노드, 대상 웹사이트라는 7개 계층이 포함됩니다. 어느 한 계층에서든 중단되면 화면의 스위치는 계속 켜진 상태로 표시될 수 있습니다.
문제 해결 중에는 노드, DNS, 규칙, TUN을 동시에 변경하지 마세요. 한 번에 한 계층만 조정하고, 각 단계에서 재현 가능한 테스트 결과를 남기세요. 테스트 대상은 로컬 라우터 주소, 직접 연결할 수 있는 웹사이트, 프록시 정책이 필요한 웹사이트 등 세 가지를 준비하는 것이 좋습니다. 이렇게 하면 문제가 로컬 네트워크, 직접 연결 경로 또는 프록시 경로 중 어디에 있는지 빠르게 판단할 수 있습니다.
네 가지 증상으로 범위를 좁히세요
| 증상 | 우선 확인할 항목 | 흔한 문제 지점 |
|---|---|---|
| 모든 웹사이트가 열리지 않음 | 로컬 포트, 시스템 프록시, TUN | 프록시 포트가 수신 대기하지 않거나 트래픽이 잘못 가로채짐 |
| 직접 연결 사이트는 열리지만 프록시 사이트는 실패 | 노드, 구독, 정책 그룹 | 노드 만료, 정책 그룹에서 DIRECT 선택 |
| IP 주소는 접속되지만 도메인은 열리지 않음 | DNS | DNS 조회 시간 초과, DNS 변조 또는 Fake-IP 경로 불완전 |
| 브라우저는 되지만 다른 앱은 실패 | TUN, 애플리케이션의 프록시 지원 여부 | 앱이 시스템 프록시를 사용하지 않거나 UDP가 가로채지지 않음 |
1단계: 노드·구독·정책 그룹이 실제로 작동하는지 확인하세요
먼저 클라이언트의 프록시 또는 정책 페이지로 이동해 현재 트래픽을 실제로 처리하는 정책 그룹을 찾으세요. 많은 설정에서 최상위 그룹 이름은 ‘노드 선택’, ‘Proxy’ 또는 ‘GLOBAL’이며, 그 아래에 자동 선택·장애 조치·지역별 그룹이 한 단계 더 포함됩니다. 홈 화면에 특정 노드 이름이 표시된다고 해서 최종 출구가 반드시 해당 노드라는 뜻은 아닙니다. 정책 그룹을 단계별로 열어 경로에 DIRECT, REJECT 또는 이미 만료된 하위 정책 그룹이 잘못 선택되어 있지 않은지 확인하세요.
지연 시간 숫자만 확인하지 마세요
지연 시간 테스트는 보통 설정에 지정된 테스트 URL에 접속합니다. 80ms 또는 200ms로 표시되어도 해당 시점에 테스트 응답을 받았다는 뜻일 뿐입니다. 대상 사이트 연결은 TLS 핸드셰이크, 회선 혼잡, 서버 측 속도 제한 또는 UDP 지원 차이로 여전히 실패할 수 있습니다. 문제를 확인할 때는 안정성이 검증된 노드를 직접 선택하고, 서로 다른 도메인 두 곳에 연속으로 접속한 뒤 연결 로그를 확인하세요.
- 지연 시간에 ‘시간 초과’가 표시됨: 먼저 서로 다른 지역의 노드 두 개로 전환해 단일 노드 장애인지 확인하세요.
- 모든 노드가 동시에 시간 초과됨: 로컬 기본 네트워크, 구독 만료 여부, 노드 서버 도메인 DNS를 확인하세요.
- 지연 시간은 정상인데 웹페이지가 실패함: 정책 매칭, DNS, TLS 오류를 계속 확인하고 반복 측정은 피하세요.
- UDP 앱만 실패함: 노드 프로토콜 또는 서버에서 사용 가능한 UDP 포워딩을 제공하지 않거나, TUN 설정이 UDP를 가로채지 못하는 것일 수 있습니다.
구독을 다시 가져오고 업데이트 시간을 확인하세요
구독이 만료되어도 반드시 ‘가져오기 실패’로 표시되는 것은 아닙니다. 클라이언트가 이전 설정을 계속 보관해 노드 목록을 표시할 수도 있습니다. ‘설정’ → ‘구독’ 또는 ‘Profiles’ 페이지로 이동해 수동으로 업데이트하고, 업데이트 후 시간과 반환 메시지를 기록하세요. 상태 코드가 401 또는 403이면 구독 권한을 확인해야 합니다. 시간 초과라면 먼저 직접 연결로 구독 도메인을 열어 보세요. 반환 내용을 파싱할 수 없다면 로그인 페이지, 안내 페이지 또는 호환되지 않는 형식의 텍스트를 받은 것일 수 있습니다.
업데이트 후 현재 활성화된 설정이 목록에 있는 같은 이름의 이전 사본이 아닌 새 설정인지 확인하세요. 일부 데스크톱 클라이언트는 설정 목록에서 다시 활성화해야 합니다. 설정에서 provider를 사용한다면 provider 업데이트 시간도 확인해야 합니다. 기본 설정 업데이트가 성공했다고 원격 노드 목록까지 동기화된 것은 아닙니다.
2단계: 로컬 프록시 포트와 시스템 프록시를 확인하세요
데스크톱에서 가장 흔한 문제 지점은 커널은 한 포트에서 수신 대기하는데 운영체제나 브라우저는 다른 포트를 가리키는 경우입니다. 일반적인 설정은 HTTP 포트 7890, SOCKS5 포트 7891을 사용하거나 mixed-port 하나만 7890으로 활성화합니다. 포트 번호는 고정된 표준이 아니므로 현재 설정과 클라이언트 설정 페이지에 표시된 값을 기준으로 확인해야 합니다.
먼저 브라우저를 거치지 않고 로컬 포트를 직접 테스트하세요
Windows PowerShell, macOS 터미널 또는 Linux 셸에서 curl에 프록시를 지정해 테스트할 수 있습니다. 아래 예시는 mixed-port가 7890이라고 가정합니다:
curl -I --max-time 10 -x http://127.0.0.1:7890 https://example.com
curl -I --max-time 10 --proxy socks5h://127.0.0.1:7891 https://example.comHTTP 응답 헤더가 반환되면 애플리케이션에서 로컬 프록시로, 프록시에서 대상 사이트로 이어지는 기본 경로가 연결된 것입니다. 즉시 ‘Connection refused’가 나타나면 대개 포트가 수신 대기하지 않거나 포트 번호를 잘못 입력한 경우입니다. 10초 후 시간 초과가 발생하면 노드와 DNS를 계속 확인하세요. HTTP 프록시는 성공하지만 SOCKS5가 실패한다면 설정에서 socks-port가 실제로 활성화되어 있는지 확인하세요.
네트워크가 정상이라면 로컬 프록시 요청은 보통 0.2~3초 안에 응답 헤더를 반환합니다. 이 범위는 노드 품질의 기준은 아니지만, 매번 10초까지 안정적으로 멈춘다면 브라우저가 저절로 복구되기를 기다리지 말고 커널 로그를 확인해야 합니다.
시스템에 설정된 실제 프록시 주소를 확인하세요
- Windows 11 24H2: ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’를 열고 ‘프록시 서버 사용’의 주소와 포트를 확인하세요. 일반적인 주소는 127.0.0.1이며 포트는 클라이언트와 일치해야 합니다.
- macOS 15: ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 → ‘세부사항’ → ‘프록시’를 열고 웹 프록시와 보안 웹 프록시를 확인하세요. 클라이언트가 자동으로 관리하는 경우 다른 포트를 수동으로 추가 입력하지 마세요.
- Android 15: Clash 계열 클라이언트는 보통 시스템 VPN 인터페이스로 트래픽을 가로채므로 Wi-Fi의 수동 프록시에 127.0.0.1을 다시 입력할 필요가 없습니다.
- 브라우저: 프록시 확장 프로그램이 동시에 활성화되어 있지 않은지 확인하세요. 확장 프로그램이 이전 포트를 가리키면 시스템 프록시를 덮어쓰거나 우회할 수 있습니다.
시스템 프록시를 끄면 직접 연결이 정상인데 켠 직후 모든 요청이 실패한다면 문제 지점은 대개 로컬 프록시 포트 이후에 있습니다. 이때 로그에 연결 거부, 핸드셰이크 시간 초과 또는 정책 그룹을 찾을 수 없다는 메시지가 있는지 확인하세요. 시스템 프록시를 꺼도 어떤 웹사이트에도 접속할 수 없다면 Clash 설정을 계속 바꾸기보다 Wi-Fi, 유선 네트워크, 게이트웨이 또는 시스템 DNS부터 복구해야 합니다.
3단계: DNS 문제를 프록시 문제와 분리하세요
‘IP는 연결되지만 도메인은 연결되지 않음’은 전형적인 DNS 단서입니다. Clash Meta, 즉 현재 널리 사용되는 mihomo 커널은 로컬에서 도메인 조회, 규칙 매칭, Fake-IP 매핑을 수행할 수 있습니다. DNS 가로채기, 상위 DNS 연결, Fake-IP 트래픽 인계 중 한 단계라도 빠지면 브라우저가 계속 로딩되거나 일부 앱에서 네트워크를 사용할 수 없다고 표시될 수 있습니다.
먼저 도메인이 응답을 받는지 확인하세요
터미널에서 시스템 DNS 조회를 테스트하세요. Windows에서는 nslookup example.com, macOS와 Linux에서는 dig example.com을 사용할 수 있습니다. 설정이 Fake-IP 모드라면 198.18.0.0/16 범위의 매핑 주소가 반환되는 것은 정상일 수 있습니다. 이 주소는 계속 mihomo로 전달되어 커널이 도메인을 복원하고 규칙을 적용해야 합니다. 198.18.x.x가 표시되었다고 곧바로 DNS 오류로 판단하지 마세요.
실제로 확인해야 할 것은 조회가 계속 시간 초과되거나 SERVFAIL을 반환하는지, 또는 시스템이 Fake-IP를 받은 뒤 트래픽이 TUN으로 들어가지 않는지입니다. TUN을 끈 뒤에도 시스템에 Fake-IP가 캐시되어 있으면 웹페이지에 일시적으로 접속하지 못할 수 있습니다. 먼저 프록시를 중지하고 시스템 DNS 캐시를 갱신한 다음 커널과 TUN을 다시 시작해 보세요.
설정의 DNS 구조를 확인하세요
dns:
enable: true
listen: 0.0.0.0:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- https://1.1.1.1/dns-query
fallback:
- tls://8.8.8.8:853이 예시는 필드 간 관계를 보여 주기 위한 것이므로 기존 구독을 판단 없이 덮어쓰면 안 됩니다. 1053은 흔히 사용하는 로컬 수신 포트일 뿐입니다. 문제를 확인할 때 dns.enable이 켜져 있는지, 수신 포트를 다른 프로그램이 사용하고 있지 않은지, 상위 주소에 현재 네트워크에서 접근할 수 있는지 확인하세요. 도메인 형태의 DoH 서비스를 참조하는 설정이라면 해당 도메인을 조회하는 bootstrap 경로도 작동해야 합니다. ‘DNS 서버의 도메인을 다시 그 DNS 서버에 의존하는’ 순환을 피해야 합니다.
로그에 DNS timeout이 계속 나타나면 설정 제공자가 권장한 다른 상위 DNS로 잠시 전환해 비교하세요. nameserver만 변경하고 노드·규칙·TUN은 그대로 유지합니다. 전환 직후 복구되면 원래 상위 DNS 또는 접근 경로에 문제가 집중된 것입니다. 계속 실패한다면 53번 포트 가로채기, 방화벽, TUN 라우팅을 확인하세요.
4단계: TUN·시스템 프록시·다른 VPN의 충돌을 배제하세요
시스템 프록시는 프록시 설정을 능동적으로 읽는 앱에 주로 영향을 줍니다. 게임, 명령줄 프로그램, 일부 스토어 앱, UDP 트래픽은 이를 무시할 수 있습니다. TUN 모드는 가상 네트워크 카드와 라우팅으로 더 많은 트래픽을 인계하지만 기업용 VPN, 가상 머신 네트워크, 컨테이너 네트워크, 가속기, 보안 프로그램과 충돌하기도 쉽습니다.
스위치 조합으로 트래픽 인계 계층을 찾으세요
- 먼저 TUN을 끄고 시스템 프록시만 켜세요. 브라우저와 앞서 사용한 curl 명령을 테스트합니다.
- 브라우저가 복구되면 노드와 HTTP 프록시는 대체로 정상이며, 문제는 TUN 라우팅·DNS 가로채기 또는 권한에 집중됩니다.
- 그다음 시스템 프록시를 끄고 TUN만 켜세요. 브라우저와 시스템 프록시를 사용하지 않는 앱 하나를 테스트합니다.
- 두 기능을 각각 켰을 때는 정상인데 동시에 켜면 문제가 발생한다면 클라이언트가 라우팅을 중복 설정했는지 또는 DNS 인계가 두 곳에서 이루어지는지 확인하세요.
- 마지막으로 클라이언트가 권장하는 조합으로 되돌리세요. 설정 오류를 반복적인 스위치 전환으로 장기간 우회하지 마세요.
mihomo의 TUN 설정에는 일반적으로 enable, stack, auto-route, auto-detect-interface, dns-hijack 같은 필드가 포함됩니다. 지원되는 stack 옵션은 운영체제와 클라이언트에 따라 다릅니다. 현재 gVisor 경로에 문제가 있다면 클라이언트가 지원하는 경우 system으로 전환해 비교해 보세요. 변경 후에는 시스템 프록시만 껐다 켜는 것이 아니라 커널을 완전히 재시작해야 합니다.
Windows에서 서비스 모드나 TUN을 활성화하면 가상 네트워크 카드와 라우팅을 기록하는 데 적절한 권한이 필요합니다. ‘설정’ → ‘네트워크 및 인터넷’ → ‘고급 네트워크 설정’에서 가상 어댑터 상태를 확인하세요. macOS는 처음 사용할 때 보통 ‘시스템 설정’ → ‘일반’ → ‘로그인 항목 및 확장 프로그램’ → ‘네트워크 확장’에서 관련 확장을 허용해야 합니다. Android에서는 상태 표시줄에 VPN 아이콘이 있는지 확인하고, 시스템 VPN 페이지에서 다른 상시 VPN이 유일한 인터페이스를 점유하고 있지 않은지 확인하세요.
기본 네트워크 카드 인식을 확인하세요
노트북이 유선 네트워크에서 Wi-Fi로 전환되거나 핫스팟에 연결되거나 절전 모드에서 깨어나면 기본 출구가 바뀔 수 있습니다. auto-detect-interface가 현재 네트워크 카드를 제대로 인식하지 못하면 TUN 트래픽이 가상 인터페이스로 되돌아가 라우팅 루프가 발생할 수 있습니다. 대표적인 증상은 TUN을 켜면 지연 시간 테스트가 모두 시간 초과되고, 끄면 즉시 복구되는 것입니다. 먼저 커널을 재시작하고, 그래도 복구되지 않으면 사용하지 않는 가상 네트워크 카드와 이전 VPN을 연결 해제한 뒤 네트워크 연결을 다시 설정하세요.
5단계: 로그에서 규칙·핸드셰이크·연결 오류를 확인하세요
앞의 네 단계로도 위치를 찾지 못했다면 로그 수준을 일시적으로 info 또는 debug로 조정하세요. 일반적인 클라이언트 경로는 ‘설정’ → ‘로그 수준’ 또는 ‘설정’ → ‘매개변수 설정’ → ‘커널’입니다. 로그를 연 뒤 실패 요청을 한 번만 재현하고 해당 도메인을 즉시 확인하세요. 속도 테스트와 백그라운드 업데이트로 관련 없는 기록이 쌓이지 않도록 하세요.
다음 로그 단서를 중점적으로 확인하세요
| 로그 단서 | 의미 | 다음 단계 |
|---|---|---|
| match DIRECT | 요청이 규칙에 의해 직접 연결로 판정됨 | 규칙 순서, 규칙 세트 업데이트, 대상 도메인을 확인하세요 |
| match REJECT | 요청이 거부 규칙에 의해 차단됨 | 광고 차단 규칙 또는 사용자 지정 규칙을 확인하세요 |
| connection refused | 대상 포트가 연결을 적극적으로 거부함 | 노드를 바꾸고 서버 측 포트와 프로토콜 매개변수를 확인하세요 |
| i/o timeout | 연결 또는 읽기가 제한 시간을 초과함 | DNS, 노드 서버, 대상 사이트의 시간 초과를 구분하세요 |
| no such host | 도메인 조회 실패 | nameserver, 네트워크 권한, DNS 가로채기를 확인하세요 |
| TLS handshake timeout | TLS 핸드셰이크가 제한 시간 내 완료되지 않음 | 다른 노드를 테스트하고 시간, MTU, 회선 품질을 확인하세요 |
규칙은 위에서 아래로 매칭되며 일반적으로 첫 번째 일치 항목에서 멈춥니다. 사용자 지정 DOMAIN-SUFFIX, IP-CIDR 또는 프로세스 규칙을 일반 규칙보다 앞에 두면 대상이 잘못 DIRECT 또는 REJECT로 전달될 수 있습니다. 확인을 위해 잠시 전역 모드를 선택하고 사용 가능한 노드를 지정해 보세요. 전역 모드에서 복구되면 노드와 기본 프록시 경로는 대체로 정상이며 문제는 규칙 또는 provider에 있을 가능성이 큽니다. 전역 모드에서도 실패하면 노드·DNS·TUN을 계속 확인하세요.
전역 모드는 짧은 비교 테스트에만 사용하고 최종 해결책으로 삼지 마세요. 문제가 확인되면 규칙 모드로 돌아가 규칙 세트 출처, 정책 그룹 이름 또는 사용자 지정 오버라이드를 수정하세요. 설정의 정책 이름은 규칙에서 참조하는 이름과 완전히 일치해야 합니다. 대소문자, 공백, 기호가 달라도 로드 오류나 대체 동작이 발생할 수 있습니다.
마지막으로 정해진 순서대로 다시 테스트해 ‘우연히 복구된’ 상황을 피하세요
변경을 마친 뒤 먼저 커널을 5초간 중지했다가 다시 시작하세요. 이후 ‘로컬 네트워크, DNS, 로컬 프록시 포트, 노드, 규칙, TUN’ 순서로 확인합니다. 웹페이지 하나가 열리는지만 보지 말고 직접 연결과 프록시가 필요한 도메인, 브라우저와 비브라우저 앱, Wi-Fi 전환 후 상태까지 테스트하세요.
- Clash를 종료하고 기본 네트워크에서 로컬 게이트웨이와 직접 연결 사이트에 접속할 수 있는지 확인하세요.
- 커널을 시작하고 설정 로드가 완료되었는지, YAML 필드 또는 provider 오류가 없는지 확인하세요.
- 127.0.0.1과 현재 mixed-port를 지정해 curl 테스트를 실행하세요.
- 구독 업데이트 시간, 현재 노드, 최상위 정책 그룹 선택을 확인하세요.
- 도메인 조회 결과와 DNS 로그를 확인해 정상적인 Fake-IP와 실제 시간 초과를 구분하세요.
- 먼저 시스템 프록시로 다시 테스트한 다음 TUN만 켜서 어떤 조합에서 충돌이 발생하는지 확인하세요.
- 규칙 모드로 되돌리고 로그에서 요청이 예상한 정책에 매칭되었는지 확인하세요.
장애가 회사·학교·호텔 네트워크에서만 발생한다면 해당 네트워크가 UDP, 특정 포트 또는 암호화 DNS를 제한하는지도 고려해야 합니다. 모바일 핫스팟으로 비교 테스트를 한 번 진행하는 것이 가장 효과적입니다. 같은 기기와 같은 설정이 핫스팟에서는 정상이고 기존 네트워크에서만 실패한다면 범위를 로컬 네트워크 출구, 인증 페이지 또는 네트워크 정책으로 좁힐 수 있습니다. 인증을 완료한 뒤 Clash를 시작하면 호텔 Wi-Fi 로그인 페이지가 프록시 규칙에 차단되는 것도 방지할 수 있습니다.
이 순서의 핵심은 가장 짧은 경로부터 확인한 뒤 트래픽 인계 범위를 한 계층씩 늘리는 것입니다. 노드·DNS·시스템 프록시·TUN은 모두 ‘연결됨인데 인터넷이 안 되는’ 비슷한 증상을 만들 수 있지만 테스트 결과는 서로 다릅니다. 각 단계의 포트, 시간, 로그, 스위치 조합을 기록하면 클라이언트를 반복해서 재설치하는 것보다 실제 문제 지점을 훨씬 빠르게 찾을 수 있습니다.