Clash 연결은 됐는데 인터넷이 안 될 때: 시스템 프록시·DNS·규칙 점검 가이드

클라이언트 실행 상태와 웹사이트 연결은 다릅니다

Clash 클라이언트에 ‘연결됨’이라고 표시되어도 커널이 실행 중이거나 설정을 불러왔거나 모바일 VPN 인터페이스가 만들어졌다는 뜻일 수 있습니다. 대상 웹사이트가 정상 응답한다는 의미는 아닙니다. 노드 옆에 지연 시간이 표시되더라도 해당 테스트 주소가 그 경로로 접속된다는 것만 확인할 수 있으며, 문제가 발생한 웹사이트까지 정상이라는 보장은 없습니다.

점검할 때는 직접 접속되는 웹페이지 하나와 실제로 열리지 않는 웹페이지 하나를 정해 두세요. 설정은 한 번에 하나씩만 바꾸고 브라우저 오류, 요청 시간, 연결 로그를 기록합니다. 그래야 변경 후 우연히 해결된 것인지 특정 단계에 문제가 있었는지 구분할 수 있습니다.

먼저 설정을 기록하세요: 현재 설정 이름, 실행 모드, 혼합 포트, 선택한 정책 그룹, 시스템 프록시와 TUN의 켜짐 여부를 적어 둡니다.
기본 네트워크부터 확인하세요: 클라이언트가 제어하는 시스템 프록시와 TUN을 잠시 끄고 직접 접속되는지 확인합니다. 호텔, 학교 또는 공공 Wi-Fi는 먼저 로그인 인증을 해야 할 수 있습니다.
여러 트래픽 가로채기 도구를 동시에 사용하지 마세요: 다른 VPN, 프록시 프로그램, 브라우저 프록시 확장 프로그램이 트래픽 경로를 바꿀 수 있습니다. 하나씩 일시 중지해 확인한 뒤 원래 설정으로 되돌리세요.
실제로 사용하는 커널을 확인하세요: 클라이언트의 정보 화면이나 시작 로그에서 mihomo 사용 여부를 확인합니다. 클라이언트와 커널에 따라 메뉴, DNS 항목, TUN 기능이 다를 수 있습니다.

1단계: 브라우저 트래픽이 로컬 프록시로 들어가는지 확인

시스템 프록시 주소와 로컬 수신 포트 확인

시스템 프록시는 앱이 프록시 설정을 따를 때만 작동하며 모든 프로그램의 트래픽을 자동으로 가로채지는 않습니다. Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 수동 프록시를 확인할 수 있습니다. macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’를 확인하세요. 메뉴 이름은 운영체제 버전에 따라 달라질 수 있습니다.

같은 컴퓨터에서 HTTP 프록시를 사용할 때는 보통 127.0.0.1과 실제 혼합 포트를 입력합니다. 자동 프록시 스크립트를 사용한다면 PAC 주소가 현재 클라이언트에서 제공되는지 확인하세요. 브라우저 프록시 확장 프로그램이나 Firefox의 별도 연결 설정이 시스템 설정보다 우선할 수도 있습니다.

명령줄에서 시스템 프록시 자동 감지를 우회하고 로컬 포트를 직접 지정해 테스트하세요. 아래 명령은 해당 요청에만 적용되며 시스템 설정은 바꾸지 않습니다. Windows에서는 curl이 다른 명령의 별칭으로 처리되는 일부 PowerShell 환경을 피하려면 curl.exe를 사용하세요.

# macOS / Linux
curl -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

# Windows PowerShell
curl.exe -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

여기서 example.com은 명령어 설명을 위한 실제 도메인입니다. 문제를 확인할 때는 접속되지 않는 웹사이트에도 같은 테스트를 실행하세요. -I는 HEAD 요청을 보냅니다. 403 또는 405가 반환되더라도 HTTP 응답을 받은 것이지만, 웹페이지가 정상적으로 모두 로드된다는 뜻은 아닙니다.

테스트 결과	우선 확인할 원인	다음 단계
127.0.0.1:7890 연결 거부	포트 미수신, 커널 미실행 또는 포트 입력 오류	시작 로그와 실제 수신 설정 확인
프록시를 직접 지정하면 응답이 오지만 브라우저는 실패	시스템 프록시가 적용되지 않았거나 브라우저에 별도 프록시 설정이 있음	프록시 확장 프로그램, PAC, 브라우저 연결 설정 확인
로컬 프록시에는 연결되지만 이후 시간 초과	로컬 진입은 정상이며 DNS, 규칙 또는 출구에 문제가 있을 수 있음	발생 시간에 맞춰 커널 연결 로그 확인
407 응답	프록시에 인증이 필요함	로컬 프록시 인증 설정과 요청 자격 증명 확인

스위치 표시만 보지 말고 연결 목록으로 확인

클라이언트의 연결 목록을 열고 대상 웹페이지를 새로고침한 다음 같은 도메인이나 대상 IP가 있는지 확인하세요. 일반적인 시스템 프록시 요청은 연결 기록에 표시되어야 합니다. 새 기록이 전혀 없다면 먼저 브라우저에서 프록시로 들어가는 경로를 점검하고 DNS는 아직 바꾸지 마세요. TUN이 켜져 있으면 일반 직접 연결 명령도 가로채질 수 있으므로 ‘프록시를 직접 지정하지 않음’이 클라이언트를 실제로 우회했다는 뜻은 아닙니다.

2단계: 로컬 DNS, 커널 DNS, 프록시 측 도메인 조회 구분

웹페이지에 ERR_NAME_NOT_RESOLVED가 표시되면 도메인을 실제로 조회하는 주체가 누구인지 확인해야 합니다. 브라우저가 보안 DNS를 사용할 수도 있고, 운영체제가 라우터에 질의하거나, mihomo가 별도의 상위 DNS 서버를 사용할 수도 있습니다. 프록시 프로토콜이 도메인 조회를 원격에 맡기는 경우도 있습니다. 각 경로의 결과는 서로 다를 수 있습니다.

먼저 시스템 DNS 조회를 확인한 뒤 프록시 요청과 비교

# example.com을 실제로 문제가 발생한 도메인으로 바꾸세요
nslookup example.com

# SOCKS5: 대상 도메인을 로컬에서 조회
curl -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy socks5://127.0.0.1:7890 https://example.com/

# SOCKS5h: 대상 도메인 조회를 SOCKS 프록시에 맡김
curl -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy socks5h://127.0.0.1:7890 https://example.com/

Windows에서도 아래 두 명령은 curl.exe로 실행하세요. 혼합 포트는 HTTP와 SOCKS 요청을 모두 받을 수 있습니다. HTTP 포트만 설정되어 있다면 실제 SOCKS 수신 포트로 바꿔야 합니다. socks5h는 대상 도메인의 조회를 로컬 SOCKS 프록시에 맡길 뿐, 이후 커널과 원격 서버 중 어디에서 조회할지는 규칙과 출구 프로토콜에 따라 달라집니다.

로컬 조회는 실패하지만 프록시를 거치면 성공: 시스템 DNS와 브라우저 보안 DNS를 우선 확인하고, 두 요청이 서로 다른 네트워크 경로를 사용하는지도 살펴보세요.
두 요청 모두 실패: DNS 문제라고 단정할 수 없습니다. 커널 로그에서 DNS 시간 초과, 규칙 적용, 출구 연결 실패 여부를 계속 확인하세요.
시스템 조회는 성공하지만 브라우저에서 오류 발생: 브라우저 보안 DNS를 확인하세요. 시스템에서 조회한 결과를 사용하지 않을 수 있습니다.

fake-ip와 DNS 가로채기 구분하기

mihomo가 fake-ip 모드를 사용하면 클라이언트 DNS에서 매핑 주소를 반환하는 것은 정상적인 동작입니다. 흔히 기본 범위로 198.18.0.1/16을 사용합니다. 이 주소만으로 DNS 오염을 판단할 수는 없습니다. 이후 연결이 같은 커널에서 계속 처리되는지, 커널이 도메인 매핑을 유지하는지가 중요합니다.

시스템에서 fake-ip를 받았지만 TUN이나 관련 라우팅이 꺼져 있으면 앱이 해당 주소에 접속하지 못할 수 있습니다. 먼저 트래픽을 처리하는 방식을 일치시킨 다음 캐시를 지우세요. DNS를 변경한 뒤 Windows에서는 ipconfig /flushdns를 실행할 수 있습니다. macOS에서는 아래 두 명령을 실행한 다음 기존 연결을 끊고 다시 테스트하세요:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

3단계: 규칙 적용 결과와 실제 정책 그룹 선택 확인

트래픽이 커널에 들어오고 도메인 조회가 되더라도 규칙에 의해 잘못된 출구로 전달될 수 있습니다. Clash 방식의 규칙은 대개 위에서부터 순서대로 확인해 먼저 일치하는 규칙을 적용합니다. 마지막의 MATCH는 앞선 규칙에 일치하지 않는 요청에 적용되는 기본 규칙입니다. 정책 그룹 이름만으로는 요청이 실제로 어떤 노드를 거쳤는지 알 수 없습니다.

직접 연결 모드가 아닌 규칙 모드인지 확인하세요. 전역 모드는 전역 정책을 사용하므로 잠깐 비교 테스트를 할 때는 유용하지만, 곧바로 문제 원인을 단정하는 기준으로 삼아서는 안 됩니다.
연결 세부정보에서 문제가 발생한 도메인을 찾아 적용된 규칙 유형과 내용, 정책 체인을 기록하세요.
규칙 대상이 DIRECT, REJECT 또는 정책 그룹인지 확인하세요. 정책 그룹을 펼쳐 최종 선택된 실제 노드도 확인합니다.
해당 웹사이트의 기존 연결을 지운 다음 페이지를 새로고침하세요. 정책을 바꿔도 이미 연결된 세션이 새 출구로 즉시 옮겨가지는 않습니다.

아래는 규칙 순서를 보여 주는 최소 예시이며, 그대로 실행할 수 있는 완성된 설정은 아닙니다. 지정된 호스트 하나는 거부하고 나머지 요청은 직접 연결한다는 뜻입니다. 실제 설정에는 해당 도메인과 기존 정책 그룹을 사용하고 필요한 트래픽 분리 방식에 맞춰야 합니다.

rules:
  - DOMAIN,blocked.example.com,REJECT
  - MATCH,DIRECT

MATCH,DIRECT를 첫 줄로 올리면 뒤에 있는 도메인 규칙이 해당 요청을 처리하지 못합니다. 규칙 모음의 순서와 로드 상태도 확인하세요. 구독 업데이트에 성공했다는 것은 설정을 가져왔다는 뜻일 뿐, 모든 원격 규칙 모음이 내려받아졌다는 의미는 아닙니다.

전역 모드로 잠깐 비교해 범위 좁히기

전역 모드로 잠시 전환하고 노드를 하나 명확히 선택한 다음 같은 웹페이지에 접속해 보세요. 규칙 모드에서는 실패하지만 전역 모드에서는 성공한다면 연결 세부정보에서 적용된 규칙의 차이를 확인합니다. 두 모드 모두 실패하면 출구를 계속 점검하세요. 테스트 후에는 원래 모드로 되돌려 다른 앱까지 문제가 번지지 않도록 합니다. 전역 모드에서 성공하더라도 DNS 경로가 달라졌을 수 있으므로 로그도 함께 확인해야 합니다.

4단계: 출구 노드와 대상 웹사이트 확인

노드 지연 시간 테스트는 보통 설정에 지정된 테스트 URL 하나를 대상으로 합니다. 테스트에 성공해도 모든 웹사이트와 포트, UDP를 사용할 수 있다는 뜻은 아닙니다. 브라우저는 메인 사이트뿐 아니라 로그인 도메인, 이미지 도메인 등 여러 곳에 요청을 보낼 수 있습니다. 리소스 하나만 실패해도 화면이 비어 있거나 계속 로딩되는 것처럼 보일 수 있습니다.

노드 두 개를 비교하세요: 문제가 발생한 도메인, 프록시 진입 방식, 모드는 그대로 두고 최종 노드만 바꿉니다. 노드를 바꾼 뒤 해당 도메인의 기존 연결을 닫고 다시 시도하세요.
구독 상태를 확인하세요: 서비스 제공업체 페이지에서 만료일, 트래픽 잔량, 노드 상태를 확인합니다. 구독을 업데이트한 뒤 현재 실행 중인 설정이 새 내용으로 바뀌었는지도 확인하세요.
시스템 시간을 확인하세요: 시간이 맞지 않으면 TLS 인증서 검증이나 시간에 의존하는 인증에 문제가 생길 수 있습니다. 먼저 시스템 자동 시간 설정을 켜고 오류가 사라지는지 확인하세요.
프로토콜 호환성을 확인하세요: 지원되지 않는 프록시 유형, 암호화 방식, 설정 항목이 나타나면 현재 커널이 해당 기능을 지원하는지 확인하세요. 클라이언트에서 구독을 가져올 수 있다고 해서 커널이 모든 노드를 정상적으로 실행한다는 뜻은 아닙니다.

로그의 connection refused는 보통 연결 대상에서 거부했거나 해당 포트가 수신 대기 중이 아님을 나타냅니다. i/o timeout은 작업 시간이 초과됐다는 뜻일 뿐 DNS, 네트워크 경로, 원격 서버 중 어디가 원인인지 단독으로 알려 주지는 않습니다. x509 관련 오류는 인증서 도메인과 유효기간, 시스템 시간을 함께 확인하세요. 문제를 숨기려고 TLS 인증서 검증을 끄지 마세요.

특정 웹사이트에서만 403, 지역 제한 또는 CAPTCHA가 표시되고 다른 페이지는 정상이라면 HTTP 응답 단계까지 도달한 것입니다. 사이트 정책과 출구 조건을 확인하세요. 이 경우 로컬 혼합 포트를 계속 바꿔도 대개 해결되지 않습니다.

TUN 모드 및 브라우저에만 발생하는 문제 추가 점검

시스템 프록시는 정상인데 TUN을 켜면 실패

TUN은 가상 네트워크 인터페이스로 트래픽을 처리하므로 권한, 라우팅, DNS가 관련됩니다. 프록시를 직접 지정한 테스트는 정상이지만 TUN을 켠 뒤에만 인터넷이 끊긴다면 구독을 다시 가져오기보다 이 항목들을 먼저 확인하세요. 인터페이스 생성 실패, 권한 부족, 라우팅 설정 실패, DNS 요청 시간 초과가 로그에 있는지 살펴봅니다.

mihomo 설정에서 tun.auto-route, tun.auto-detect-interface, tun.dns-hijack은 각각 자동 라우팅, 출구 인터페이스 감지, DNS 가로채기와 관련됩니다. 구체적인 동작은 플랫폼과 클라이언트 구현에 따라 달라집니다. Wi-Fi를 바꾸거나 유선 연결을 뺐다 꽂거나 다른 VPN에 연결했다면 기존 출구 인터페이스와 라우팅 설정이 더 이상 맞지 않을 수 있습니다. 로그를 저장한 뒤 TUN을 다시 시작하고 같은 요청을 비교하세요.

명령줄은 되지만 브라우저에서만 접속되지 않음

브라우저 프록시 확장 프로그램을 잠시 끄고 Firefox의 ‘설정’ → ‘일반’ → ‘네트워크 설정’에서 별도 프록시를 사용하는지 확인하세요.
브라우저 보안 DNS를 확인하세요. 비교를 위해 잠시 끌 수 있지만, 확인이 끝나면 원래 설정으로 복구하고 커널 DNS는 동시에 바꾸지 마세요.
개발자 도구의 ‘네트워크’ 패널을 열고 메인 문서, 특정 스크립트나 이미지, 로그인 API 중 무엇이 실패하는지 확인하세요.
로그에 UDP 또는 QUIC 경로가 표시되면 먼저 일반 HTTPS 명령줄 요청과 비교하세요. HTTP 요청이 성공해도 노드에서 UDP를 지원한다는 뜻은 아닙니다.

Android에서는 클라이언트의 앱별 프록시 설정이 켜져 있는지, 대상 브라우저가 제외 목록에 있는지도 확인하세요. 시스템의 ‘비공개 DNS’ 때문에 예상과 다른 경로로 조회할 수도 있습니다. 모바일 VPN 아이콘은 인터페이스가 만들어졌다는 뜻일 뿐이므로 실제 요청과 클라이언트 로그를 기준으로 판단하세요.

설정을 복구하고 재현 가능한 점검 기록 남기기

점검이 끝나면 임시로 바꾼 전역 모드, 브라우저 설정, 로그 수준을 원래대로 복구하세요. 클라이언트 개발자나 서비스 제공업체에 문의할 때는 ‘연결됐는데 인터넷이 안 돼요’라는 화면보다 같은 문제를 재현할 수 있는 절차가 더 효과적입니다.

운영체제, 클라이언트, 커널의 실제 버전과 시스템 프록시 및 TUN의 켜짐 여부를 기록하세요.
문제가 발생하는 범위를 설명하세요. 모든 웹사이트인지, 특정 사이트인지, 특정 브라우저인지, TUN 모드에서만 발생하는지 적습니다.
프록시를 직접 지정한 HTTP 테스트, DNS 비교 결과, 적용된 규칙, 최종 출구 노드 유형을 첨부하세요.
같은 요청 전후의 관련 로그를 캡처하세요. 공유하기 전에 구독 주소, 인증 정보, 제어 인터페이스 키, 개인 접속 기록을 가리세요.

설정 항목은 이 사이트의 고급 설정에서 확인할 수 있습니다. 설치와 사용에 관한 자주 묻는 질문은 도움말 센터에서 찾아보세요.