문제 해결 예상 읽기 시간 12분

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

시스템 프록시, 포트 충돌, 정책 그룹, 규칙 매칭, DNS와 Fake-IP를 차례로 확인해 연결됨인데 인터넷이 안 되는 원인을 찾습니다.

1. 먼저 ‘연결됨’이 어느 단계의 상태인지 확인하세요

Clash 그래픽 클라이언트에서 코어가 실행 중이거나 시스템 프록시가 켜져 있고 노드 지연 시간이 표시되더라도, 브라우저가 해당 노드를 통해 웹사이트에 접속할 수 있다는 뜻은 아닙니다. 웹 요청은 앱의 프록시 설정, 로컬 리스닝 포트, 규칙과 정책 그룹, 노드 연결, 도메인 조회, 대상 사이트까지 여러 단계를 거칩니다. 어느 한 단계라도 문제가 있으면 ‘클라이언트는 정상인데 웹페이지가 계속 로딩 중’인 상황이 생길 수 있습니다.

현재 사용 중인 클라이언트 이름, 코어 종류, 설정, 모드, 로컬 프록시 포트를 기록해 두세요. Clash, Clash Meta(현재 이름은 mihomo), 그래픽 클라이언트마다 메뉴 명칭이 다를 수 있으므로 ‘프록시’, ‘연결’, ‘로그’ 등은 사용 중인 화면의 표기를 따르세요. 시스템 설정 경로는 운영체제에 맞게 확인하면 됩니다.

  1. 현재 설정을 복사해 보관하고 시스템 프록시와 TUN의 기존 상태를 기록하세요.
  2. 문제를 안정적으로 재현할 수 있는 웹페이지를 정한 뒤, 설정을 한 번에 하나씩만 바꾸고 다시 시도하세요.
  3. 다른 프록시, VPN, 브라우저 프록시 확장 프로그램이 실행 중이라면 먼저 종료하세요. 여러 프로그램이 시스템 설정을 번갈아 변경하는 상황을 피할 수 있습니다.
  4. Clash의 시스템 프록시와 TUN을 잠시 끄고 일반 웹사이트에 직접 접속할 수 있는지 확인하세요. 테스트가 끝나면 원래 상태로 되돌리세요.

2. 시스템 프록시가 올바른 포트를 가리키는지 확인하세요

시스템 프록시는 해당 설정을 따르는 앱에 요청을 전달할 로컬 주소를 알려주는 기능입니다. 모든 기기의 트래픽을 가로채는 것은 아니며, 명령줄 도구, 게임, 독립 실행 앱이 모두 프록시를 사용한다고 보장할 수 없습니다. 브라우저에 별도의 프록시 확장 프로그램이 있다면 시스템 설정을 덮어쓸 수도 있습니다.

Windows와 macOS에서 확인할 위치

현재 설정의 혼합 프록시 포트가 7890이라고 가정하면, 기기의 시스템 프록시 주소는 보통 127.0.0.1, 포트는 7890이어야 합니다. 포트 번호는 예시이므로 클라이언트에 표시된 실제 리스닝 포트와 일치하는지 확인하세요. HTTP 프록시는 CONNECT를 통해 HTTPS도 전달할 수 있으므로 웹페이지가 HTTPS라는 이유만으로 시스템 프록시 주소를 원격 노드 주소로 바꾸지 마세요.

# 로컬 프록시 필드 예시이며 전체 구독 설정이 아닙니다
mixed-port: 7890
allow-lan: false
mode: rule

mixed-port는 HTTP와 SOCKS 프록시 연결을 모두 받습니다. 설정에서 port와 socks-port를 따로 사용한다면 두 포트를 구분해야 합니다. SOCKS만 지원하는 포트를 시스템 HTTP 프록시에 입력하면 안 됩니다. 수정한 뒤 클라이언트에서 설정을 다시 불러오고 화면에 표시된 실제 포트를 확인하세요. 그래픽 클라이언트의 재정의 설정과 파일 내용이 다를 수 있습니다.

3. 포트와 명시적 프록시로 문제 범위를 좁히세요

시스템 프록시 설정이 올바르게 보여도 로컬 포트가 리스닝 중이 아니면 브라우저는 연결할 수 없습니다. 클라이언트 로그에서 시작 실패, 설정 파싱 실패, address already in use 또는 bind 오류를 먼저 확인하세요. 포트가 이미 사용 중이라면 점유 프로세스를 확인하고, 정체를 모르는 시스템 프로세스를 바로 종료하지 마세요.

7890 포트가 리스닝 중인지 확인

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

# macOS 또는 lsof가 설치된 Linux
lsof -nP -iTCP:7890 -sTCP:LISTEN

Windows에서는 조회한 프로세스 ID를 Get-Process -Id에 입력해 이름을 확인할 수 있습니다. macOS와 Linux는 보통 출력에 프로세스 이름이 표시됩니다. 리스닝 결과가 없다면 코어가 실제로 시작됐는지, 포트가 변경됐는지, 리스닝 주소에 127.0.0.1이 포함되는지 확인하세요. 같은 기기에서 클라이언트를 두 개 실행 중이라면 사용하지 않는 쪽을 먼저 종료하세요.

시스템 설정을 거치지 않고 프록시를 직접 지정하세요

Windows에서는 curl.exe를 사용해 구버전 PowerShell의 curl 별칭에 따른 동작 차이를 피하세요. macOS와 Linux에서는 아래 명령의 curl.exe를 curl로 바꾸면 됩니다. 이 명령은 기본 연결 확인 대상으로 example.com을 사용합니다. 이후 문제가 발생하는 실제 웹사이트 주소로 바꿔 비교하세요.

# 로컬 HTTP 혼합 프록시 포트를 명시적으로 사용
curl.exe --noproxy "" -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/

# 애플리케이션 프록시를 사용하지 않는 비교 테스트
curl.exe --noproxy "*" -I --connect-timeout 10 --max-time 20 https://example.com/
확인 결과다음 점검 항목
127.0.0.1에 즉시 연결할 수 없음포트, 리스닝 주소, 코어 실행 상태를 확인하세요.
명시적 프록시는 성공하지만 브라우저는 실패시스템 프록시, 브라우저 확장 프로그램, 브라우저 자체 DNS 설정을 확인하세요.
로컬 연결은 성공하지만 이후 핸드셰이크가 시간 초과됨노드 연결 로그, 정책 그룹, 도메인 조회 결과를 확인하세요.
대상 사이트의 HTTP 응답을 받음애플리케이션 계층 응답은 받은 상태입니다. 403, 405 등의 상태 코드는 사이트의 접근 제한 여부를 함께 확인해야 합니다.

주의: --noproxy "*"는 애플리케이션 계층 프록시만 우회합니다. TUN이 켜져 있다면 요청이 여전히 가상 네트워크 인터페이스를 거칠 수 있으므로, 이를 완전한 직접 연결 테스트로 간주하면 안 됩니다. 일부 사이트는 HEAD 요청을 허용하지 않습니다. 405가 나오면 -I를 빼고 일반 GET 요청으로 테스트하세요.

4. 지연 시간만 보지 말고 정책 그룹을 확인하세요

노드 지연 시간 테스트는 보통 특정 테스트 주소에만 연결합니다. 테스트에 성공해도 모든 웹사이트에 접속할 수 있다는 뜻은 아닙니다. 구독 업데이트 성공은 설정을 다운로드하고 파싱했다는 의미일 뿐, 노드 서비스가 작동하거나 계정 트래픽이 남아 있거나 대상 사이트가 해당 출구 IP의 접속을 허용한다는 보장은 없습니다.

  1. 클라이언트의 ‘프록시’ 또는 ‘정책 그룹’ 화면을 열고 대상 트래픽이 실제로 사용하는 그룹을 찾으세요.
  2. 해당 그룹이 최종적으로 특정 노드, 다른 정책 그룹, DIRECT 또는 REJECT를 선택하는지 확인하세요.
  3. 정상 작동이 확인된 노드를 직접 선택하고 웹페이지 연결을 다시 시도하세요. 지연 시간 테스트를 한 번 누르는 것으로 점검을 끝내지 마세요.
  4. 정책 그룹이 여러 단계로 구성되어 있다면 각 단계에서 최종 선택을 확인하세요. 상위 그룹에는 ‘프록시’로 표시되지만 하위 그룹에서 직접 연결로 빠질 수 있습니다.

비교를 위해 잠시 전역 모드로 전환하고 전역 정책 그룹에서 실제 노드를 선택했는지 확인할 수 있습니다. 전역 모드에서는 되지만 규칙 모드에서는 실패한다면 규칙과 그룹부터 확인하세요. 두 모드 모두 실패하면 노드 핸드셰이크, 네트워크 차단, DNS를 계속 점검해야 합니다. 테스트가 끝나면 원래 모드로 되돌리고 전역 모드를 장기적인 해결책으로 사용하지 마세요.

5. 연결 기록에서 어떤 규칙이 적용됐는지 확인하세요

규칙 모드는 보통 설정 순서대로 규칙을 확인하고 처음 일치하는 규칙에 따라 처리합니다. 앞쪽에 너무 포괄적인 규칙이 있으면 뒤에 있는 도메인 규칙은 적용되지 않을 수 있습니다. 규칙 이름만 보고 결과를 추측하지 말고 ‘연결’ 또는 ‘로그’에서 테스트 도메인, 일치 규칙, 사용된 정책, 최종 노드를 확인하세요.

# 규칙 순서 예시. Proxy는 설정에 이미 존재하는 정책 이름이어야 합니다
rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOIP,LAN,DIRECT
  - MATCH,Proxy

위 예시는 매칭 순서를 설명하기 위한 것으로, 모든 구독에 그대로 적용할 수 있는 규칙 템플릿이 아닙니다. MATCH는 기본 규칙이므로 우선 적용할 규칙 뒤에 배치해야 합니다. 기존 설정에서 규칙 세트를 사용한다면 해당 세트가 정상적으로 로드됐는지, 연결된 정책이 존재하는지도 확인하세요.

규칙 필드의 의미는 설정 필드 안내에서 확인할 수 있습니다. 구독으로 생성된 파일을 수정하기 전에는 클라이언트가 지원하는 오버라이드 또는 병합 기능을 먼저 사용하세요. 캐시 파일을 직접 수정하면 다음 구독 업데이트 때 덮어써질 수 있습니다.

6. 기기 DNS, 코어 DNS, Fake-IP를 구분하세요

DNS 문제의 해결책이 항상 ‘다른 서버로 바꾸기’인 것은 아닙니다. 시스템 조회, 브라우저 보안 DNS, 프록시 코어 DNS, 프록시 서버 주소 조회는 서로 다른 경로를 사용할 수 있습니다. 먼저 로그에서 lookup 실패, DNS 요청 시간 초과, 원격 IP 연결 시간 초과, TLS 핸드셰이크 실패를 구분한 뒤 어느 계층을 바꿀지 판단하세요.

시스템 DNS가 정상이어도 코어 DNS가 정상이라는 뜻은 아닙니다

nslookup example.com으로 시스템 기본 DNS 경로의 결과를 확인할 수 있습니다. 하지만 브라우저에서 보안 DNS를 사용하거나 프록시 코어가 직접 조회하면 이 경로를 사용하지 않을 수 있습니다. mihomo의 nameserver에 DoH 주소가 설정되어 있다면 DoH 서비스에 연결할 수 있는지, 도메인의 초기 조회가 가능한지, DNS 요청 경로가 설정과 일치하는지도 확인하세요.

예를 들어 상위 서버를 https://dns.example.com/dns-query로 설정한다고 해서 네트워크 연결 문제가 자동으로 해결되지는 않습니다. 이 형식은 문법 설명용이며, 예시 도메인을 실제로 사용할 수 있는 DNS 서비스로 취급하면 안 됩니다. 도메인 형식의 노드 주소를 사용하는 경우 노드 도메인 조회에 실패하는지도 확인하세요. 노드가 연결되기도 전에 해당 노드를 통해 DNS 서비스를 조회하려는 순환 의존성이 생길 수 있습니다.

198.18 주소는 정상적인 Fake-IP 결과일 수 있습니다

Fake-IP 모드에서는 DNS가 198.18.0.0/16 범위의 주소를 반환하는 것이 일반적인 설정 동작입니다. 이 주소는 코어 내부 매핑에 사용되며 웹사이트의 실제 공인 IP가 아닙니다. 주소 자체가 DNS 변조를 뜻하지는 않습니다. 이후 연결이 같은 코어에서 처리되고 해당 도메인 매핑을 찾을 수 있는지가 중요합니다.

# Windows: 시스템 DNS 캐시 비우기
ipconfig /flushdns

# macOS: 시스템 DNS 캐시 비우기. 두 번째 명령은 관리자 권한이 필요합니다
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

캐시를 비워도 잘못된 상위 서버 설정은 해결되지 않으며 브라우저 자체 캐시가 지워지지 않을 수도 있습니다. DNS 설정을 바꿀 때마다 코어 설정을 다시 불러오고 새 테스트 연결을 만드세요. 상위 서버, Fake-IP 모드, 모든 분할 라우팅 규칙을 한꺼번에 바꾸면 접속이 복구되더라도 원인을 확인하기 어렵습니다.

7. 시스템 프록시는 되지만 TUN이 안 될 때는 라우팅 처리를 확인하세요

TUN은 가상 네트워크 인터페이스를 통해 조건에 맞는 트래픽을 처리하며, 시스템 HTTP 프록시와는 진입 경로가 다릅니다. 가장 유용한 비교 방법은 TUN을 끄고 시스템 프록시만으로 브라우저를 테스트한 다음, 정상 작동을 확인한 뒤 TUN을 켜서 차이를 살펴보는 것입니다. Android의 VPN 인터페이스와 데스크톱 TUN은 비슷한 점이 있지만, 권한과 라우팅 관리는 플랫폼에서 처리하므로 메뉴 구성이 완전히 같지는 않습니다.

  1. 권한과 서비스 확인: 클라이언트에서 서비스 설치, VPN 권한, 네트워크 확장 권한을 요청하는지 확인하세요. 권한이 없으면 스위치가 켜져 보여도 라우팅이 제대로 설정되지 않았을 수 있습니다.
  2. 다른 VPN 제외: 다른 VPN, 보안 소프트웨어, 가상 네트워크 카드가 기본 경로나 DNS를 바꿀 수 있습니다. 통제된 환경에서 하나씩 종료해 비교하세요.
  3. DNS 처리 확인: 설정의 DNS 리스너와 dns-hijack가 현재 코어 및 플랫폼에서 지원되는지 확인하세요. 모든 DNS 트래픽이 자동으로 가로채진다고 가정하면 안 됩니다.
  4. IPv6 확인: 실패한 연결이 IPv6를 사용한다면 현재 경로, 노드, 설정이 해당 연결을 지원하는지 확인하세요. 코어의 IPv6 조회 옵션만 꺼도 앱이 이미 확보한 IPv6 주소를 사용하는 것을 막지 못할 수 있습니다.

MTU를 바꾸거나 방화벽을 끄는 작업부터 시작하지 마세요. 작은 요청은 성공하지만 큰 데이터 전송이 계속 멈추고, 라우팅과 노드가 정상인 것을 확인한 뒤에 MTU, 경로 MTU 탐색, UDP 전달을 점검하세요. 방화벽 문제를 확인할 때는 시스템 보호 기능을 장기간 끄지 말고 클라이언트 허용 규칙부터 확인하세요.

8. 결과를 기록하고 실패한 단계를 확인하세요

앞선 점검으로도 원인을 찾지 못했다면 ‘몇 번이나 재설치했다’는 설명보다 실패한 요청 정보를 정리하는 편이 도움이 됩니다. 테스트 시각, 대상 도메인, 시스템 프록시 포트, 모드, 정책 그룹, 일치 규칙, 로그에서 관련된 첫 오류를 기록하세요. 한 사이트에서만 문제가 생긴다면 대상 사이트의 점검 작업, 계정 제한, 출구 IP 차단 여부도 고려해야 합니다.

오류 또는 증상우선 확인할 항목
connection refused오류에 표시된 대상 주소를 기준으로 로컬 포트가 리스닝 중이지 않은지, 원격 서비스가 연결을 거부했는지 구분하세요.
lookup failed 또는 DNS timeout조회 대상이 웹사이트인지, 노드 도메인인지, DNS 상위 서버인지 확인하고 해당 조회 경로에 접근할 수 있는지 살펴보세요.
TLS 또는 인증서 오류시스템 시간, 인증서 호스트 이름, 노드 매개변수, 네트워크의 로그인 인증 페이지를 확인하세요.
브라우저에서만 실패프록시 확장 프로그램, 별도의 보안 DNS, 캐시, 브라우저 설정을 확인하세요.
TUN에서만 실패권한, 가상 네트워크 카드, 라우팅, DNS 처리, 다른 VPN과의 충돌을 확인하세요.

인증서 오류는 시스템 시간, 설정, 신뢰 체인을 따라 해결하세요. 인증서 검증을 건너뛰는 방법을 일반적인 해결책으로 사용하지 마세요. 로그 수준을 일시적으로 높여야 한다면 문제를 한 번만 재현한 뒤 원래 수준으로 되돌리세요. 로그를 공유하기 전에는 구독 링크, 액세스 토큰, 노드 비밀번호와 기타 개인 식별 정보를 삭제하세요.

마지막으로 세 가지를 확인할 수 있어야 합니다. 브라우저 요청이 코어에 전달됐는지, 코어가 예상한 규칙과 노드를 선택했는지, DNS와 원격 연결이 각각 어느 단계에서 성공하거나 실패했는지입니다. 이 순서대로 확인하면 ‘연결됨인데 인터넷이 안 됨’ 문제를 시스템 프록시, 노드, DNS를 무작정 바꿔 가며 반복하는 대신 구체적으로 해결할 수 있는 원인으로 좁힐 수 있습니다.

Clash 다운로드