프록시 스위치는 초록색이고 노드도 연결됐다고 표시되는데 웹페이지는 계속 로딩만 되는 경우, 겉으로는 정상인데 실제로는 안 되는 상태입니다. 원인은 대개 시스템 프록시가 실제로 적용됐는지, 노드 자체가 접속 가능한지, DNS 해석이 정상인지, 규칙이 예상한 정책 그룹에 매칭됐는지, 브라우저에 예전 연결 캐시가 남아 있는지 이 다섯 가지 중 하나입니다. 무작정 노드를 바꿔가며 시도하지 말고 정해진 순서대로 하나씩 점검해야 가장 빠르게 문제 지점을 찾을 수 있습니다.
1단계: 시스템 프록시가 실제로 적용됐는지 확인
클라이언트 화면에 '연결됨'이라고 표시되는 건 클라이언트와 노드 사이에 프록시 터널이 만들어졌다는 뜻일 뿐, 시스템 전체 트래픽이 그 터널로 흘러들어가고 있다는 의미는 아닙니다. 가장 자주 놓치는 부분이며 점검의 출발점입니다.
시스템 네트워크 설정에서 프록시 항목을 확인합니다(Windows는 '설정 → 네트워크 및 인터넷 → 프록시', macOS는 '시스템 설정 → 네트워크 → 고급 → 프록시'). 주소와 포트가 클라이언트가 로컬에서 사용하는 포트(보통 127.0.0.1:7890 같은 혼합 포트)를 가리키는지 확인합니다.
클라이언트가 시스템 프록시 자동 설정 기능을 켰다면 이 항목이 클라이언트에 의해 자동으로 채워진 상태여야 합니다. 한 번 수동으로 끈 다음 클라이언트 화면에서 다시 켜서 설정이 올바르게 다시 쓰이는지 확인해 보세요.
TUN 모드(가상 네트워크 어댑터로 전체 트래픽을 가로채는 방식)를 사용한다면 시스템 프록시 설정과는 무관하므로, 네트워크 어댑터 목록에 클라이언트가 만든 가상 어댑터가 있는지, 활성화 상태인지를 확인해야 합니다.
시스템 프록시 항목이 비어 있거나 포트가 맞지 않거나, TUN 모드에서 해당 가상 어댑터를 찾을 수 없다면 트래픽이 아예 클라이언트로 들어가지 않고 있다는 뜻이므로 이후 단계를 점검하는 건 의미가 없습니다. 이 부분을 먼저 해결해야 합니다.
2단계: 노드 연결성 — 프록시 스위치 다음으로 확인할 것
시스템 프록시가 정상 작동함을 확인했다면, 다음은 '터널은 만들어졌지만 노드 자체가 외부로 나가지 못하는' 경우를 배제해야 합니다. 클라이언트의 '연결됨' 상태는 보통 핸드셰이크 성공만을 의미하며, 해당 노드가 현재 트래픽을 정상적으로 전달하고 있음을 뜻하지는 않습니다.
클라이언트 노드 목록에서 현재 사용 중인 노드로 지연 시간 테스트를 실행합니다. 타임아웃이 뜨거나 지연 시간이 비정상적으로 높다면 같은 구독의 다른 사용 가능한 노드로 바로 전환합니다.
클라이언트에 내장된 로그 패널을 열어 연결 거부나 핸드셰이크 실패 같은 기록이 있는지 확인합니다. 이런 로그는 대개 로컬 설정 문제가 아니라 노드 쪽 문제를 가리킵니다.
모든 노드에서 테스트가 실패한다면 구독 서버 자체에 문제가 있거나 로컬 네트워크에서 출구 프로토콜로 가는 포트가 차단됐을 가능성이 큽니다. 이건 별도의 문제이므로 사이트 내 '모든 노드 타임아웃' 관련 점검 방법을 참고해 따로 처리하세요.
참고
노드를 바꾸기 전에 먼저 지연 시간 테스트 결과를 확인하세요. 감으로 바꾸다 보면 실제 원인(DNS나 규칙 문제 등)을 '노드가 안 좋다'로 잘못 판단하기 쉽습니다.
3단계: DNS 해석 — 도메인이 올바른 주소로 변환되는지
프록시 링크도 정상이고 노드도 접속 가능한데 웹페이지가 계속 로딩만 된다면, 도메인 해석 단계에서 막혀 있을 가능성이 큽니다. DNS 요청이 프록시를 거치지 않거나 로컬에 잘못된 결과가 캐시돼 있으면 브라우저는 영원히 응답이 오지 않는 연결을 계속 기다리게 됩니다.
클라이언트 설정에서 DNS 항목을 확인해 fake-ip나 클라이언트 내장 원격 DNS 포워딩이 활성화돼 있는지, 원래 사용하던 로컬 DNS 서버를 그대로 쓰고 있지는 않은지 확인합니다.
시스템 명령줄에서 반드시 프록시를 거쳐야 접속 가능한 도메인으로 해석 테스트를 실행합니다. 로컬 통신사 DNS에서 흔히 나오는 오류 주소나 타임아웃이 반환된다면 해당 해석 요청이 프록시를 거치지 않았다는 뜻입니다.
클라이언트가 규칙 안에서 DNS 분기 설정을 지원한다면, DNS 조회가 '직접 연결' 정책 그룹으로 잘못 분류돼 있는 규칙이 있는지 확인하세요. 이런 설정은 프록시 링크가 정상이어도 도메인 해석이 계속 실패하게 만듭니다.
로컬 DNS 캐시를 지웁니다(Windows는 ipconfig /flushdns, macOS는 sudo killall -HUP mDNSResponder 실행). 이후 대상 웹사이트에 다시 접속해 보세요.
DNS 단계의 문제는 보통 '일부 사이트는 열리고 일부는 안 열림', 같은 사이트인데도 시간대에 따라 결과가 다르게 나타나는 식으로 드러납니다. 이런 현상을 관찰했다면 노드보다는 해석 단계를 먼저 의심해야 합니다.
4단계: 규칙 매칭 — 분명히 연결됐는데 왜 안 열리는가
Clash와 Clash Meta(mihomo) 코어는 모두 규칙(rules)에 따라 각 연결이 어느 정책 그룹으로 흘러갈지 결정합니다. 규칙이 대상 사이트를 '직접 연결'이나 이미 실패한 정책 그룹으로 잘못 분류하면, 프록시 자체가 완전히 정상이어도 해당 사이트는 여전히 열리지 않습니다.
클라이언트의 연결 패널이나 로그를 열어 대상 사이트 요청이 실제로 어떤 규칙에 매칭됐고 어느 정책 그룹으로 분류됐는지 확인합니다. 정책 그룹 자체가 '연결됨'으로 표시되는지만 보지 마세요.
매칭된 정책 그룹에서 현재 선택된 실제 노드가 사용 불가능한 상태라면, 규칙이 정확히 매칭됐어도 연결은 여전히 실패합니다. 해당 정책 그룹 안의 노드 상태를 따로 확인해야 합니다.
사용자 정의 규칙이 많고 순서가 뒤엉켜 있으면 앞쪽의 광범위한 규칙이 먼저 매칭돼 뒤쪽의 정확한 규칙이 적용되지 않는 경우가 생기기 쉽습니다. 임시로 사용자 정의 규칙을 비우고 구독의 기본 설정으로 되돌려 다시 테스트해서 문제가 사라지는지 확인해 보세요.
TUN 모드를 사용할 때는 시스템 핵심 프로세스나 브라우저 프로세스를 가로채기 대상에서 제외하는 규칙이 있는지도 확인해야 합니다. 이런 제외 규칙은 브라우저 요청이 프록시를 완전히 건너뛰게 만듭니다.
증상
가능한 원인
해결 방향
모든 사이트가 안 열림
시스템 프록시 미적용 / TUN 어댑터 비활성화
1단계로 돌아가 프록시 설정 재확인
일부 사이트만 안 열리고 나머지는 정상
규칙이 잘못된 정책 그룹에 매칭
연결 로그로 실제 매칭된 규칙 확인
웹페이지가 오류 없이 계속 로딩만 됨
DNS 해석이 프록시를 안 거치거나 캐시됨
로컬 DNS 캐시 삭제 및 fake-ip 설정 확인
특정 정책 그룹에서 전부 타임아웃
해당 그룹의 실제 노드가 사용 불가
정책 그룹 내 다른 사용 가능한 노드로 전환
5단계: 브라우저와 로컬 캐시 — 마지막 관문
앞의 네 단계를 모두 정상으로 확인했는데도 특정 웹페이지가 계속 안 열린다면, 프록시 링크가 아니라 브라우저 자체에 남은 예전 연결이나 인증서 캐시가 원인인 경우가 많습니다.
브라우저의 프라이빗/시크릿 창으로 대상 사이트를 다시 열어 브라우저 확장 프로그램과 로컬 캐시의 영향을 배제합니다.
브라우저에서 인증서 오류나 연결 재설정 메시지가 뜬다면 시스템 시간이 정확한지 확인하세요. 시간 오차가 크면 TLS 핸드셰이크 검증이 실패하는데, 이게 프록시 문제처럼 보일 수 있습니다.
일부 브라우저는 같은 도메인에 대해 연결 풀을 계속 유지하는데, 노드나 정책 그룹을 바꾼 뒤에도 이전 연결이 제때 해제되지 않을 수 있습니다. 브라우저 프로세스를 재시작하면 이런 잔여 문제는 대부분 해결됩니다.
위 다섯 단계를 가까운 것부터 순서대로 점검하면 '연결됐는데 웹페이지가 안 열리는' 대부분의 상황을 10분 안에 구체적인 문제 지점까지 찾아낼 수 있습니다. 점검 결과 클라이언트 버전 자체의 호환성 문제로 판단된다면 최신 버전으로 업데이트한 뒤 다시 테스트해 보세요.