Clash 연결됨으로 표시되지만 웹페이지가 열리지 않을 때: 시스템 프록시부터 DNS까지 점검하기

먼저 클라이언트 상태와 웹 요청을 구분하세요

Clash 클라이언트에 ‘연결됨’이라고 표시되는 것은 보통 코어가 실행 중이거나 프록시가 켜져 있거나 특정 연결 테스트에 성공했다는 뜻입니다. 브라우저의 모든 요청이 노드를 거쳤다는 의미는 아닙니다. 요청은 앱의 프록시 설정, 코어 규칙, 출구 노드, 도메인 이름 확인, 대상 서버를 차례로 거칩니다. 어느 한 단계에서든 문제가 생기면 웹페이지가 계속 로딩될 수 있습니다.

문제를 점검할 때는 매번 변수 하나만 바꾸세요. 현재 설정과 오버라이드 파일을 보존하고 클라이언트 이름, 코어 버전, 선택한 정책, 오류 발생 시간을 기록하세요. 클라이언트마다 설정 명칭이 다르므로 아래에서는 설정 필드, 시스템 메뉴와 확인 가능한 결과를 기준으로 설명합니다. 특정 클라이언트의 버튼 이름을 공통 메뉴처럼 가정하지 않습니다.

• 모든 앱에서 인터넷이 안 됨: 먼저 프록시와 TUN을 끄고 Wi-Fi, 유선 연결, 기본 게이트웨이와 네트워크 인증이 정상인지 확인하세요.
• 브라우저에서만 열리지 않음: 브라우저 확장 프로그램, 개별 프록시 설정, 보안 DNS와 캐시를 확인하세요.
• 일부 사이트만 열리지 않음: 적용된 규칙, 노드 출구와 대상 사이트의 제한을 먼저 확인하세요.
• TUN을 켠 뒤에만 인터넷이 끊김: 시스템 프록시로 정상 동작을 확인한 다음 라우팅 처리를 점검하세요.

1단계: 시스템 프록시가 실제 수신 포트를 가리키는지 확인

시스템 프록시 주소로 흔히 127.0.0.1:7890을 사용하지만, 7890이 고정값은 아닙니다. 현재 실행 중인 설정의 mixed-port 값을 확인하세요. 이 포트는 HTTP와 SOCKS 프록시 연결을 모두 받습니다. external-controller는 제어 인터페이스이므로 브라우저 프록시 포트로 지정하면 안 됩니다.

시스템 설정과 브라우저 설정 확인

• Windows 11: 「설정」→「네트워크 및 인터넷」→「프록시」에서 수동 프록시의 주소와 포트를 확인하세요. 클라이언트에서 자동 구성 스크립트를 사용한다면 실제로 활성화된 설정을 확인하고, 수동 프록시와 이전 스크립트를 함께 사용하지 않도록 하세요.
• macOS: 「시스템 설정」→「네트워크」→ 현재 네트워크 연결 →「세부사항」→「프록시」에서 HTTP, HTTPS 또는 SOCKS 설정이 클라이언트와 일치하는지 확인하세요.
• Firefox: 「설정」→「일반」→「네트워크 설정」→「설정」에서 시스템 프록시 사용 여부를 확인하거나 수동 설정의 주소와 포트를 점검하세요.
• 모바일에서는 보통 로컬 VPN이 트래픽을 처리하므로 데스크톱의 시스템 프록시 설정을 그대로 적용할 수 없습니다. 먼저 시스템에서 현재 활성화된 VPN 설정을 확인하세요.

포트가 실제로 수신 중인지 확인

아래 Windows PowerShell 명령은 TCP 7890의 수신 상태와 프로세스 번호를 확인합니다. 아무것도 출력되지 않으면 해당 포트에서 TCP 연결을 수신 중인 프로세스가 없는 것입니다. 이 경우 시스템 프록시가 코어에 연결되어 있다고 가정하면 안 됩니다.

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

macOS 또는 lsof가 설치된 Linux에서는 같은 포트를 확인할 수 있습니다:

lsof -nP -iTCP:7890 -sTCP:LISTEN

설정을 mixed-port: 7891로 바꿨다면 시스템 프록시, 명령줄 프록시와 앱 내 수동 프록시도 모두 7891로 맞춰야 합니다. 같은 기기에서 사용할 때 루프백 주소로 수신하는 것은 정상이며, 문제를 해결하려고 무턱대고 LAN 접근을 허용할 필요는 없습니다.

2단계: 프록시를 명시한 요청으로 브라우저 문제 분리

먼저 TUN을 잠시 끄고 코어는 계속 실행한 상태에서, 명령어에 프록시를 직접 지정해 테스트하세요. 브라우저 확장 프로그램과 시스템 프록시 선택 과정을 건너뛸 수 있습니다. Windows에서는 일부 PowerShell 환경에서 curl이 다른 명령으로 해석되는 문제를 피하기 위해 curl.exe를 사용하세요. macOS와 Linux에서는 curl을 사용합니다.

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

여기서 example.com은 공개 테스트용 도메인일 뿐, 고정된 속도 측정 대상은 아닙니다. --noproxy ""는 환경에 설정된 프록시 우회 목록이 테스트에 영향을 주지 않도록 합니다. 프록시를 명시하지 않은 경로를 테스트하려면 TUN을 끈 상태에서 다음을 실행하세요:

curl.exe --noproxy "*" --connect-timeout 10 --max-time 20 -I https://example.com

HTTPS 프록시 로그의 200 Connection established는 CONNECT 터널이 수락됐다는 뜻일 뿐입니다. 이후 TLS 핸드셰이크와 대상 서버의 응답도 확인해야 합니다. 대상 서버에서 403 또는 405가 반환됐다면 HTTP 응답을 한 번 이상 받은 것이지만, 사이트가 정상적으로 작동한다는 뜻은 아닙니다. 필요하면 일반 GET 요청으로 다시 확인하세요.

3단계: 모드, 규칙과 최종 출구 확인

클라이언트의 연결 목록을 열고 문제가 발생한 웹페이지를 새로고침한 뒤 도메인이나 프로세스로 해당 연결을 찾으세요. 홈 화면에 선택된 노드 이름만 보지 말고 매칭 규칙, 정책 그룹과 최종 노드를 확인해야 합니다. 규칙에 따라 해당 도메인이 DIRECT, REJECT 또는 다른 정책 그룹으로 전달될 수 있습니다.

• rule: 규칙을 위에서부터 확인하고 처음 일치한 규칙에 따라 정책이 결정됩니다. 앞쪽 도메인 규칙과 규칙 세트, 마지막의 MATCH를 확인하세요.
• global: 잠깐 비교 테스트할 때 사용하고 GLOBAL 정책에서 실제로 원하는 노드를 선택했는지 확인하세요. 전역 모드로 바꿔도 노드가 정상 작동한다는 보장은 없습니다.
• direct: 코어로 들어온 연결을 직접 연결로 처리합니다. 프록시 노드가 정상인지 확인하는 용도로는 사용할 수 없습니다.

같은 URL이 전역 모드에서는 열리지만 규칙 모드에서는 실패한다면 규칙 모드에서 실제로 어떤 출구를 사용하는지 확인하세요. 구독 규칙이 대상 사이트를 직접 연결로 보내거나, 중첩된 정책 그룹에서 사용할 수 없는 노드를 선택했을 수 있습니다. 수정한 뒤 rule 모드로 되돌리고 새 연결이 원하는 정책에 매칭되는지 확인하세요.

연결 목록에 기록이 없는 경우

목록에 필터가 적용되지 않았는지, 웹페이지가 캐시에서 바로 읽힌 것은 아닌지, 코어 로그에 테스트 시간대의 기록이 있는지 먼저 확인하세요. 그래도 요청이 보이지 않는다면 규칙을 고치기보다 앱의 연결 경로와 TUN 처리를 먼저 점검하세요. 브라우저가 별도의 프록시, VPN 또는 네트워크 확장 프로그램을 사용해 현재 코어에 요청을 보내지 않았을 수 있습니다.

4단계: 지연 시간 숫자만 보지 말고 노드 연결 확인

노드에 지연 시간이 표시된다는 것은 클라이언트가 지정한 탐색 요청이 완료됐다는 뜻입니다. 모든 도메인, UDP 트래픽, IPv6 경로 또는 장시간 연결이 정상이라는 보장은 없습니다. 테스트 주소에는 연결되더라도 대상 사이트에서 출구를 제한하면 ‘지연 시간은 정상인데 웹페이지가 열리지 않는’ 상황이 생길 수 있습니다.

1. 대상 URL을 하나로 고정하고 노드 두 개를 각각 테스트하세요. 노드와 웹사이트를 동시에 바꾸지 마세요.
2. 구독 서비스의 이용 기간과 남은 트래픽, 노드 정보가 최신인지 확인하세요. 이미 신뢰하는 구독 주소에서만 업데이트하고 구독 URL을 온라인 검사 사이트에 입력하지 마세요.
3. 로그에서 노드 연결 시간 초과, 인증 실패, TLS 핸드셰이크 실패 또는 도메인 이름 확인 실패 등 구체적인 오류를 확인하세요.
4. 시스템 날짜와 시간을 확인하세요. 시간이 맞지 않으면 인증서 검증에 실패할 수 있으므로 인증서 검증을 끄고 문제를 감추면 안 됩니다.

모든 노드가 서버 연결 단계에서 시간 초과된다면 현재 네트워크가 관련 전송 포트를 제한하는지도 확인하세요. 휴대전화 핫스팟으로 바꿔 경로를 비교할 수 있지만, 이는 원인을 좁히기 위한 방법일 뿐 노드 설정이 올바르다는 증거는 아닙니다.

5단계: 시스템 DNS, 코어 DNS와 브라우저 보안 DNS 구분

DNS 문제를 점검할 때는 먼저 ‘어느 쪽에서 이름을 확인하는지’를 구분해야 합니다. 시스템 리졸버, mihomo DNS 모듈과 브라우저의 암호화 DNS는 서로 다른 경로를 사용할 수 있습니다. 시스템의 nslookup이 성공해도 코어 DNS가 정상이라는 뜻은 아니며, 코어 DNS가 정상이어도 브라우저가 같은 경로를 사용한다는 보장은 없습니다.

관찰한 뒤 nameserver를 변경하세요

Windows에서는 먼저 시스템 DNS의 응답을 확인할 수 있습니다. 명령어 결과에 사용한 서버와 응답 주소가 표시됩니다. 요청 시간이 초과되면 해당 DNS 서버에 네트워크로 연결할 수 있는지 추가로 확인하세요.

nslookup example.com

mihomo를 사용 중이고 코어 DNS를 따로 확인하려면, 포트가 사용 중이 아닌지 확인한 뒤 아래 내용을 기존 dns 블록에 합치세요. 진단용 조각이며 노드, 정책 그룹과 규칙은 포함하지 않으므로 단독으로 실행할 수 있는 완전한 설정이 아닙니다.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1

여기서 1.1.1.1은 일반 DNS 업스트림의 예시이며 현재 네트워크에서 접근할 수 있는지는 환경에 따라 다릅니다. 기업이나 학교에서 지정한 DNS를 사용해야 한다면 네트워크 환경에 맞는 설정을 유지하세요. 공용 DNS가 모든 문제를 해결하는 것은 아닙니다. 설정을 적용한 뒤 dig가 설치된 터미널에서 지정 포트를 조회할 수 있습니다:

dig @127.0.0.1 -p 1053 example.com A

fake-ip 모드에서 설정된 범위의 매핑 주소가 반환되는 것은 정상일 수 있습니다. 이 주소는 도메인과 이후 연결을 연결하는 데 쓰이며 대상 사이트의 실제 공인 IP 주소가 아닙니다. 앱에서 매핑 주소를 받았더라도 이후 연결이 코어를 우회하면 웹페이지가 열리지 않을 수 있습니다. 따라서 Fake-IP는 실제 트래픽 처리 경로와 함께 점검해야 합니다.

• 노드 서버에 도메인 이름을 사용하는 경우: 먼저 서버 도메인이 정상적으로 확인되는지 확인하세요. mihomo의 proxy-server-nameserver를 사용하면 노드 서버 도메인을 조회할 업스트림을 지정해 프록시 연결 전에 해당 프록시에 의존하는 순환 문제를 피할 수 있습니다.
• fallback 사용: fallback-filter와 함께 DNS 응답 중 사용할 결과를 선택하는 기능입니다. 모든 연결 시간 초과에 적용할 수 있는 범용 예비 설정은 아닙니다.
• 브라우저 보안 DNS 사용: 시스템 DNS로 잠시 전환해 비교한 뒤 필요한 설정을 복구하세요. 브라우저와 코어의 여러 업스트림을 한꺼번에 바꾸지 마세요.
• 일부 사이트만 느리거나 멈춤: A 및 AAAA 레코드와 IPv6 연결을 비교하세요. 먼저 curl -4와 curl -6으로 확인하고, IPv6를 끄는 것을 기본 해결책으로 삼지 마세요.

Windows에서는 DNS 설정을 변경한 뒤 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 지우고 브라우저를 다시 시작할 수 있습니다. 이 명령은 모든 브라우저 캐시나 코어의 Fake-IP 매핑을 지우지 않으며, 연결할 수 없는 DNS 업스트림도 해결하지 못합니다.

6단계: 시스템 프록시가 정상 작동한 뒤 TUN과 방화벽 점검

명시적 HTTP 프록시 테스트는 성공하지만 TUN을 켠 뒤 실패한다면 트래픽 처리 경로를 중점적으로 확인하세요. TUN은 가상 네트워크 어댑터와 라우팅, 실행 권한에 의존합니다. 클라이언트 스위치가 켜져 있다는 것만으로 경로가 정상적으로 설정됐다고 볼 수 없습니다. 먼저 시작 로그에서 권한 부족, 장치 생성 실패 또는 라우팅 충돌이 없는지 확인하세요.

트래픽 처리 범위와 DNS 가로채기 확인

mihomo의 tun.auto-route는 라우트를 자동 설정하고 tun.auto-detect-interface는 출구 인터페이스를 식별하는 데 도움을 줍니다. 지원 여부는 사용 중인 코어와 플랫폼을 기준으로 확인하세요. 네트워크 어댑터가 여러 개이거나 다른 VPN 또는 가상 머신 네트워크가 있으면 자동 감지가 예상과 다를 수 있습니다.

tun.dns-hijack는 일치하는 일반 DNS 요청을 코어 DNS로 전달합니다. 흔히 사용하는 항목은 any:53입니다. TCP 53 요청도 일치시켜야 한다면 코어 지원 여부를 확인한 뒤 tcp://any:53을 설정하세요. 이 설정은 브라우저가 HTTPS 443으로 보내는 암호화 DNS 요청을 자동으로 처리하지 않으며, 정상 작동하는 업스트림 리졸버를 대신하지도 않습니다.

1. 다른 VPN, 게임 가속기 또는 중복 실행 중인 프록시 클라이언트를 잠시 종료하고 트래픽을 처리하는 프로그램 하나만 실행하세요.
2. 클라이언트에 필요한 서비스가 설치되어 실행 중인지 확인하세요. 또는 안내된 권한으로 실행한 다음 로그를 확인하세요.
3. Windows에서는 route print, Linux에서는 ip route로 라우팅을 확인하고 실제 출구를 점검하세요. 시스템 라우트를 무작정 삭제하지 마세요.
4. 방화벽에서 현재 코어 실행 파일의 네트워크 통신이 허용되어 있는지 확인하세요. 클라이언트 업데이트로 파일 경로가 바뀌면 기존 규칙이 더 이상 일치하지 않을 수 있습니다.
5. TUN을 사용할 때만 대용량 파일 전송이나 일부 HTTPS 페이지가 멈춘다면 MTU, 경로 MTU 탐색과 UDP 지원을 확인하세요. 근거 없이 네트워크 스택을 반복해서 바꾸지 마세요.

다시 사용하기 전: 설정 적용 여부와 결과 재현 확인

클라이언트에는 구독 원본, 오버라이드 설정과 최종 실행 설정이 함께 있을 수 있습니다. YAML 파일을 수정했다고 해서 코어가 그 파일을 읽는 것은 아닙니다. 클라이언트에서 현재 설정 출처를 확인한 다음 실제 적용된 포트, DNS와 TUN 필드를 확인하세요.

mihomo를 별도로 사용하는 경우 설정 디렉터리에서 아래 Windows 명령으로 문법을 확인할 수 있습니다. 현재 디렉터리에 mihomo.exe와 config.yaml이 있다는 전제입니다. GUI 클라이언트에서는 우선 내장 설정 검사 기능을 사용하고, 포트 충돌을 피하려고 코어를 하나 더 실행하지 마세요.

.\mihomo.exe -t -f .\config.yaml

문법 검사를 통과해도 설정을 읽을 수 있다는 뜻일 뿐, 노드와 DNS 또는 네트워크에 연결할 수 있다는 보장은 없습니다. 문제를 해결한 뒤 다음 순서로 마무리하세요:

• 평소 사용하는 규칙 모드로 되돌리고 직접 연결 대상 하나와 프록시 대상 하나의 실제 출구를 확인하세요.
• 브라우저를 다시 열어 이전에 실패한 URL을 확인하고 같은 시간대의 연결 기록도 살펴보세요.
• 임시 디버그 로그를 평소 수준으로 되돌리고 더 이상 필요하지 않은 테스트 수신 포트를 제거하세요.
• 최종 포트와 변경한 필드, 설정 적용 방법을 기록해 다음 구독 업데이트에서 수정 사항이 덮어쓰이지 않도록 하세요.

원인을 찾지 못했다면 클라이언트와 코어 버전, 시스템 버전, 오류 발생 시간, 시스템 프록시와 TUN의 활성화 상태, 민감한 정보를 가린 단일 요청 로그를 제공하세요. ‘연결됨’ 화면 한 장보다 간결하게 재현할 수 있는 절차가 문제를 파악하는 데 도움이 됩니다. 기본 설정은 사용 가이드를, 각 필드의 의미는 mihomo 고급 설정을 참고하세요.