Clash 연결은 됐는데 웹페이지가 열리지 않을 때: 포트부터 규칙까지 점검하기

먼저 구분할 항목: 코어 실행, 노드 속도 측정, 웹 접속

Clash 클라이언트에 ‘연결됨’이라고 표시되거나 서비스가 실행 중이라는 것은 실행 단계 중 하나가 시작됐다는 뜻일 뿐입니다. 브라우저 요청은 앱의 프록시 설정, 로컬 리스닝 포트, 규칙 선택, 노드 연결, 대상 웹사이트를 차례로 거칩니다. 노드 속도 측정에서 몇 ms가 표시되더라도 측정 대상 주소에 그 시점에 접속할 수 있었다는 뜻이며, 모든 웹사이트와 프로토콜을 사용할 수 있다는 의미는 아닙니다.

이 문서는 데스크톱 클라이언트와 mihomo 코어를 함께 사용하는 일반적인 환경을 기준으로 설명합니다. 클라이언트마다 설정 이름이 다를 수 있으므로 화면에 실제로 표시된 리스닝 포트와 적용된 설정을 확인하세요. 먼저 클라이언트 이름과 버전, 코어 버전, 현재 설정 이름, 문제가 발생한 시간을 기록하세요. 처음부터 클라이언트를 재설치하고 구독을 바꾸고 DNS까지 수정하지 마세요.

재현 가능한 항목 세 가지 기록하기

문제 범위: 모든 웹사이트에 접속할 수 없는지, 특정 도메인만 안 되는지 확인하세요. 브라우저만 문제인지, 터미널이나 다른 앱도 문제인지도 살펴보세요.
요청 경로: 시스템 프록시, 브라우저 프록시 확장 프로그램, TUN 모드 중 무엇을 사용 중인지 확인하세요. 다른 VPN도 실행 중인지 살펴보세요.
문제 발생 시점의 기록: 페이지를 새로고침하면서 클라이언트의 ‘연결’ 목록에서 대상 도메인을 찾고, ‘로그’에서 같은 시각의 오류를 확인하세요.

1단계: 브라우저가 시스템 프록시를 사용하는지 확인

Clash Verge Rev에서 흔히 볼 수 있는 화면을 기준으로 설명합니다. ‘설정’ → ‘시스템 프록시’에서 스위치를 확인한 다음 운영체제에서 실제 프록시 주소를 확인하세요. 클라이언트에서 노드를 선택해도 모든 앱이 자동으로 해당 노드를 사용하는 것은 아닙니다. 시스템 프록시도 시스템 설정을 따르지 않는 모든 앱을 제어할 수는 없습니다.

클라이언트에서 실제 ‘혼합 포트’를 확인하세요. 예를 들어 화면에 7897이라고 표시되면 로컬 프록시 주소는 127.0.0.1:7897이어야 합니다. 다른 클라이언트는 7890을 사용할 수도 있으니 기본값을 그대로 입력하지 마세요.
Windows 11에서 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’를 열어 ‘프록시 서버 사용’의 주소와 포트를 확인하세요. 자동 구성 스크립트가 함께 설정되어 있다면 최종 요청 경로에 영향을 줄 수 있습니다.
macOS에서 ‘시스템 설정’ → ‘네트워크’ → 현재 연결된 네트워크 → ‘세부사항’ → ‘프록시’를 열어 웹 프록시와 보안 웹 프록시가 예상한 주소를 가리키는지 확인하세요.
Firefox에서 ‘설정’ → ‘일반’ → ‘네트워크 설정’ → ‘설정’을 열어 시스템 프록시를 사용하는지 확인하거나 수동 프록시 설정을 점검하세요. 다른 브라우저의 프록시 확장 프로그램이 시스템 설정보다 우선할 수도 있습니다.

문제를 확인하는 동안 브라우저 프록시 확장 프로그램을 잠시 끄고, 명확한 프록시 경로 하나만 사용하세요. HTTP 혼합 포트에 SOCKS 전용 포트를 입력하거나 컨트롤러 포트를 트래픽 진입점으로 사용하지 마세요. external-controller는 관리 인터페이스용이며 웹 요청을 프록시하지 않습니다.

명시적 프록시 요청으로 브라우저 설정 우회하기

현재 혼합 포트가 7897이라고 가정하고 Windows PowerShell에서 다음 명령을 실행하세요. 일부 PowerShell 환경에서 같은 이름의 별칭이 인자 해석에 영향을 주는 것을 피하기 위해 curl.exe를 사용합니다. macOS와 Linux에서는 명령어 이름을 curl로 바꾸면 됩니다.

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

그런 다음 테스트 URL을 실제로 접속되지 않는 사이트로 바꾸세요. 명시적 프록시 요청은 성공하지만 브라우저에서는 실패한다면 브라우저 확장 프로그램, 시스템 프록시, 연결 캐시 또는 브라우저 자체의 보안 DNS 설정부터 확인하세요. 노드를 바로 바꿀 필요는 없습니다. 403 또는 405가 반환되면 HTTP 응답을 받은 것입니다. 웹사이트가 접속을 제한하거나 HEAD 요청을 허용하지 않을 수 있으므로 -I를 빼고 비교해 보세요. 이 응답만으로 프록시에 연결되지 않았다고 단정할 수는 없습니다.

2단계: 혼합 포트 리스닝 및 포트 충돌 확인

명시적 프록시 요청에 127.0.0.1에 연결할 수 없다는 메시지가 즉시 표시되면 먼저 로컬 리스닝을 확인하세요. 이 경우 요청이 노드에 도달하기 전이므로 원격 서버를 바꿔도 대개 해결되지 않습니다. Windows에서는 PowerShell에서 다음 명령을 실행하세요.

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

결과에 나온 프로세스 ID를 Get-Process -Id 1234에 넣어 현재 사용 중인 코어가 해당 포트를 점유하고 있는지 확인하세요. 여기서 1234는 명령 형식의 예시이므로 조회 결과에 나온 값으로 바꿔야 합니다. macOS에서는 다음 명령으로 리스닝 중인 프로세스를 확인할 수 있습니다.

lsof -nP -iTCP:7897 -sTCP:LISTEN

확인 결과	흔한 원인	다음 단계
리스닝 결과 없음	코어가 시작되지 않았거나, 설정 로드에 실패했거나, 포트가 잘못 입력됨	시작 로그와 실제 혼합 포트 확인
다른 프록시가 포트를 점유함	이전 클라이언트나 백그라운드 서비스가 계속 실행 중	해당 프로그램을 정상 종료하고 트래픽 진입점을 하나만 유지
IPv6 루프백 주소에서만 리스닝	리스닝 주소와 요청 주소가 일치하지 않음	적용된 설정과 클라이언트의 리스닝 설정 확인
정상적으로 리스닝하지만 요청 시간이 초과됨	요청이 코어에 들어온 뒤의 경로에 문제가 있음	모드, 정책 그룹, 로그를 계속 확인

포트를 바꿔야 한다면 사용 중이 아닌 포트를 선택하세요. 예를 들어 7897을 17897로 바꾼 뒤 코어에서 설정을 다시 불러오세요. 이어서 시스템 프록시, 브라우저 확장 프로그램, 터미널의 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY도 확인하세요. 클라이언트만 바꾸고 기존 진입점을 그대로 두면 계속 잘못된 포트에 연결됩니다.

3단계: 규칙 모드와 전역 모드 비교

로컬 진입점이 정상인지 확인한 뒤 클라이언트의 ‘프록시’ 페이지에서 모드를 확인하세요. 규칙 모드는 규칙에 따라 정책을 선택하고, 전역 모드는 전역 정책 선택을 사용하며, 직접 연결 모드는 프록시 노드를 거치지 않습니다. 이는 트래픽을 처리하는 방식이며 시스템 프록시나 TUN 모드 사용 여부와는 별개의 설정입니다.

규칙 모드에서 대상 웹사이트에 접속한 뒤 연결 상세 정보에 표시되는 규칙, 정책 그룹, 최종 노드, 오류 내용을 기록하세요.
잠시 전역 모드로 전환하고 전역 정책에서 사용할 수 있는 노드를 명시적으로 선택하세요. 전역 정책이 여전히 DIRECT 또는 REJECT를 선택하고 있다면 비교해도 의미가 없습니다.
같은 웹사이트에 다시 접속하세요. 전역 모드에서는 접속되지만 규칙 모드에서는 안 된다면 규칙과 규칙이 지정하는 정책 그룹을 집중적으로 확인하세요.
테스트가 끝나면 원래 사용하던 규칙 모드로 돌아가 임시 진단 설정이 계속 남지 않도록 하세요.

두 모드 모두 실패한다면 로그에서 노드 연결 시간 초과, 인증 실패, TLS 핸드셰이크 실패, 인증서 오류가 있는지 확인하세요. 다른 노드로 교차 테스트할 수 있지만 대상 URL과 테스트 경로는 그대로 유지해야 합니다. 노드 속도 측정은 성공했는데 실제 웹사이트에 접속할 수 없다면 출구 제한, 대상 사이트의 제한, 노드 프로토콜 매개변수 등이 원인일 수 있습니다. 지연 시간만으로 노드 문제를 배제할 수는 없습니다.

4단계: 규칙 순서, 정책 그룹, 최종 출구 확인

mihomo 규칙은 일반적으로 위에서 아래 순서로 매칭되며, 일치하는 규칙을 찾으면 해당 정책을 적용합니다. 도메인이 앞쪽 규칙에 의해 직접 연결 또는 거부 정책으로 전달되면 뒤쪽의 올바른 규칙은 적용되지 않습니다. 설정에 해당 도메인이 있는지만 검색하지 말고 ‘연결’ 상세 정보에 표시된 실제 매칭 결과를 기준으로 확인하세요.

설정을 바꾸기 전에 연결 상세 정보부터 확인

DIRECT에 매칭: 직접 연결이 예상된 범위인지 확인하고, 범위가 지나치게 넓은 도메인 접미사 규칙이나 IP 규칙이 먼저 매칭됐는지 살펴보세요.
REJECT에 매칭: 차단 규칙이나 외부 규칙 세트를 확인하고, 웹사이트가 사용하는 리소스 도메인도 거부되는지 살펴보세요.
프록시 그룹에 매칭: 그룹을 펼쳐 내부 선택을 확인하세요. 그룹 이름이 ‘프록시’여도 최종적으로 원격 노드를 사용한다는 뜻은 아닙니다. 직접 연결이나 다른 그룹이 선택되어 있을 수도 있습니다.
MATCH에 도달: 기본 정책을 확인하세요. 대개 앞선 규칙이 해당 요청을 처리하지 못했다는 의미입니다.

아래 예시는 규칙 순서만 보여 주며 구독 설정 전체를 대체할 수 없습니다. 참조된 PROXY는 현재 설정에 해당 이름의 노드나 정책 그룹이 있어야 합니다.

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,LAN,DIRECT
  - MATCH,PROXY

실제 웹사이트는 로그인, 정적 리소스, API 도메인에 동시에 요청을 보내는 경우가 많습니다. 홈페이지 HTML은 정상적으로 반환되지만 페이지가 계속 로딩된다면 API 도메인이 다른 규칙에 매칭됐을 수 있습니다. 브라우저 개발자 도구의 ‘네트워크’ 패널에서 실패한 요청의 도메인을 확인한 뒤 클라이언트 연결 목록에서 해당 기록을 찾아보세요.

구독을 업데이트하면 직접 수정한 구독 내용이 덮어써질 수 있습니다. 규칙을 계속 수정해야 한다면 클라이언트에서 제공하는 오버라이드, 병합 또는 확장 설정 기능을 우선 사용하고 변경 사항이 실제 적용된 설정에 반영됐는지 확인하세요. 구독에 이미 포함된 노드와 정책 그룹 전체를 인터넷에서 찾은 예시로 대체하지 마세요.

5단계: 시스템 DNS와 mihomo DNS를 따로 확인

DNS 오류는 도메인 조회 시간 초과나 실패, 또는 조회 결과를 연결에 사용할 수 없는 형태로 나타나는 경우가 많습니다. 먼저 어느 쪽에서 이름을 조회하는지 확인하세요. 시스템 리졸버, 브라우저의 보안 DNS, 코어 DNS, 원격 프록시 서버 중 하나일 수 있습니다. 각각의 요청 경로가 다를 수 있으므로 nslookup을 한 번 실행한 것만으로 전체 프록시 경로가 정상이라고 볼 수는 없습니다.

요청 경로별로 조회 결과 비교하기

nslookup example.com을 실행하고 시스템에서 사용하는 DNS 서버와 반환 결과를 기록하세요. 실제로 문제가 발생한 도메인도 같은 방식으로 테스트하세요.
클라이언트 로그에서 대상 도메인을 찾아 코어의 DNS 조회가 실패했는지, 아니면 조회에는 성공했지만 노드 연결이 실패했는지 확인하세요.
브라우저에서만 문제가 발생한다면 현재 설정을 기록한 다음 브라우저의 ‘보안 DNS’를 일시적으로 변경해 비교 테스트하세요. 테스트 후에는 원래 설정으로 되돌리거나 효과가 확인된 설정을 유지하세요.
설정에서 암호화 DNS를 사용한다면 DNS 서버 자체에 접속할 수 있는지 확인하세요. 현재 네트워크에서 연결할 수 없는 주소로 DNS 서버를 바꾸면 시간 초과만 더 발생합니다.

SOCKS를 테스트할 때는 socks5://와 socks5h://의 차이도 확인할 만합니다. curl에서는 후자를 사용하면 프록시 측에서 대상 도메인을 조회합니다. 현재 포트가 SOCKS를 지원한다면 다음 명령으로 비교 요청을 실행하세요.

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

원격 조회 방식은 되지만 로컬 조회 방식은 실패한다면 로컬 DNS 경로를 우선 확인하세요. 다만 어떤 경로가 성공했는지는 연결 로그와 함께 살펴봐야 하며, 요청 한 번만으로 원인을 단정할 수는 없습니다.

Windows에서는 관련 설정을 바로잡은 다음 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 지우고 브라우저를 완전히 종료한 뒤 다시 여세요. 캐시 삭제는 마무리 작업일 뿐, 잘못된 DNS 업스트림이나 라우팅, 리다이렉션 설정을 바로잡는 방법은 아닙니다.

6단계: TUN, 라우팅, 다른 VPN을 각각 확인

명시적 HTTP 프록시로는 접속되지만 TUN을 켜면 실패한다면 가상 네트워크 어댑터, 라우팅 또는 DNS 가로채기 경로에 문제가 있을 가능성이 큽니다. TUN은 가상 네트워크 인터페이스로 트래픽을 처리하므로 앱이 시스템 HTTP 프록시를 따를 필요는 없습니다. 다만 서비스 권한 부족, 라우팅 충돌, 다른 VPN의 네트워크 설정 변경으로 인해 트래픽 경로가 잘못될 수 있습니다.

클라이언트의 ‘설정’에서 서비스 모드나 관련 서비스가 정상인지 확인한 다음 ‘TUN 모드’ 스위치를 확인하세요. 서비스 권한이 필요한 클라이언트라면 화면 안내에 따라 설치를 완료해야 합니다.
네트워크 정책에 문제가 없는지 확인한 뒤 TUN을 잠시 끄고 시스템 프록시만 켜세요. 같은 브라우저에서 같은 URL로 테스트하세요.
TUN에서만 실패한다면 적용된 설정의 tun.auto-route, tun.dns-hijack 등을 확인하고 다른 VPN이나 가상 네트워크 어댑터와 라우팅을 두고 충돌하는지 살펴보세요.
일부 HTTPS 페이지만 멈춘다면 로그와 패킷 캡처를 함께 확인해 MTU, IPv6 라우팅 등의 문제를 살펴보세요. 특정 MTU 값을 모든 환경에 통하는 해결책처럼 적용하지 마세요.

회사 기기나 관리되는 네트워크에서는 지정된 VPN, 인증서, DNS 정책을 사용해야 할 수 있습니다. 이 경우 관리자에게 호환 방법을 문의하세요. 네트워크 관리를 우회하려고 보안 구성 요소를 끄면 안 됩니다. 일반 개인 기기라면 먼저 중복 실행 중인 프록시 프로그램을 종료한 다음 남아 있는 서비스를 정리하세요.

문제 해결 결과 기록 및 설정 복원 확인

한 차례 점검을 마치면 아래 결과를 기준으로 추가 확인이 필요한 계층을 빠르게 파악할 수 있습니다. ‘연결 안 됨’이라고만 적기보다 구체적인 오류를 기록하면 재부팅이나 구독 업데이트 후에도 문제가 재현되는지 확인하기 쉽습니다.

테스트 결과	우선 확인할 항목	보관할 증거
로컬 프록시 포트에서 연결 거부	리스닝 포트 및 코어 시작 상태	리스닝 프로세스, 시작 오류
명시적 프록시는 성공하지만 브라우저는 실패	시스템 프록시 및 브라우저 설정	시스템 프록시 값, 확장 프로그램 상태
전역 모드에서는 성공하지만 규칙 모드에서는 실패	규칙 순서 및 정책 그룹 선택	매칭된 규칙, 최종 노드
시스템 프록시는 성공하지만 TUN은 실패	서비스 권한, 라우팅 및 DNS 가로채기	TUN 로그, 다른 VPN 상태
특정 웹사이트 하나만 접속 실패	리소스 도메인, 출구 제한 또는 웹사이트 상태	실패한 도메인, HTTP 상태 코드 및 발생 시간

문제를 문의할 때는 클라이언트와 코어 버전, 운영체제 버전, 실제 혼합 포트, 프록시 모드, TUN 상태, 재현 절차, 같은 시간대의 오류 로그를 제공하세요. 스크린샷이나 설정을 공유하기 전에 구독 주소, 인증 정보, 컨트롤 인터페이스 키, 개인 브라우징 기록을 삭제하세요.

다시 사용하기 전에 임시로 켠 전역 모드를 원래 모드로 되돌리고, 브라우저와 터미널에 이전 포트가 남아 있지 않은지 확인하세요. 처음 문제가 발생한 웹사이트와 로그인, 이미지, API 요청도 다시 테스트하세요. 기본 설정은 Clash 설정 가이드를 참고하세요. 오류 유형별로 계속 확인하려면 문제 해결 페이지를 이용하세요.