Clash 연결됐지만 웹페이지가 안 열릴 때: 노드 지연부터 DNS까지 항목별 점검 체크리스트
프록시는 켜져 있는데 브라우저가 계속 로딩 중이라면 노드, 규칙, DNS, 시스템 프록시 중 어딘가 문제입니다. 쉬운 것부터 어려운 순서로 아홉 가지 점검 항목과 해결법을 정리했습니다.
먼저 문제 범위를 확인한 뒤 어디를 볼지 정한다
"연결은 정상인데 웹페이지가 안 열린다"는 말 뒤에는 전혀 다른 원인이 숨어 있을 수 있습니다. 본격적으로 점검하기 전에 1분만 투자해 범위를 좁히면 이후 절반 이상의 시간을 아낄 수 있습니다.
- 일부 사이트만 안 열리고 나머지는 정상: 규칙 분기나 특정 노드 문제일 가능성이 크고, 전체 네트워크 장애는 아닙니다.
- 국내 사이트를 포함해 모든 사이트가 안 열림: 먼저 시스템 프록시, TUN 네트워크 어댑터, 또는 로컬 네트워크 자체를 의심해야 하며 Clash 노드와는 관련이 적습니다.
- 웹페이지는 열리지만 속도가 매우 느리고 이미지가 제대로 로딩되지 않음: 대부분 노드 지연이나 대역폭 문제이며, "연결 자체가 안 되는" 상황과는 다릅니다.
- 구독을 교체하거나 설정을 바꾼 직후에 발생: 설정 파일의 규칙이나 DNS 항목을 먼저 의심하고, 한 번 설정을 되돌려보면 빠르게 확인할 수 있습니다.
현상을 위 항목 중 하나로 분류한 뒤 아래 점검 순서를 따라가면 됩니다. 모든 항목을 처음부터 끝까지 다 확인할 필요는 없습니다.
점검 항목 1~3: 노드 자체에 문제가 있는가
1. 현재 선택한 노드가 실제로 연결 가능한가
프록시 페이지에 표시되는 "연결됨"은 대부분 클라이언트와 코어 사이의 제어 연결이 정상이라는 뜻일 뿐, 선택된 노드 자체가 외부 인터넷에 접속 가능하다는 의미는 아닙니다. 프록시 페이지를 열어 현재 정책 그룹의 노드에 지연 테스트를 한 번 실행하세요. 타임아웃이 표시되거나 지연이 세 자리 숫자 이상이면서 접속이 안 된다면, 지연이 낮은 다른 노드로 바꿔 확인해 보세요. 다른 노드로 열린다면 노드 쪽 문제이니 2, 3번 항목을 계속 확인하고, 노드를 바꿔도 안 열린다면 규칙과 DNS 항목으로 넘어가세요.
2. 정책 그룹이 실패한 노드를 선택하고 있는가
select 또는 url-test 정책 그룹을 사용할 때 구독 제공자 측에서 특정 노드를 일시적으로 내렸다면 클라이언트가 이를 알려주지 않고 정책 그룹은 계속 그 실패한 항목에 머물러 있게 됩니다. 로그 페이지에서 dial tcp: connection refused나 i/o timeout이 다량으로 나타나는지 확인하세요. 특정 노드 이름에 집중적으로 나타난다면 그룹 내 다른 노드로 수동 전환하거나, 정책 그룹 유형을 url-test로 바꿔 코어가 지연이 비정상적인 노드를 자동으로 건너뛰게 하세요.
3. 구독이 만료됐거나 만료 직전인가
일부 구독은 트래픽이나 사용 기간이 만료되면 곧바로 가져오기 실패 오류를 내지 않고, 모든 노드를 접속 불가능한 자리채우기 노드로 바꿔버립니다. 겉보기엔 "연결은 정상인데 어떤 사이트도 안 열리는" 상태로 나타납니다. 구독 제공처 관리 페이지에서 만료일과 남은 트래픽을 확인하는 것이 클라이언트를 반복해서 재시작하는 것보다 훨씨 빠른 확인 방법입니다.
점검 항목 4~6: 규칙이 트래픽을 잘못된 방향으로 보내고 있는가
4. 프록시로 가야 할 도메인이 규칙 때문에 직결로 처리됨
Clash는 위에서 아래로 규칙을 순서대로 매칭하며, 하나가 먼저 일치하면 그 아래는 확인하지 않습니다. 커스텀 규칙에 너무 넓게 작성된 DOMAIN-SUFFIX나 DOMAIN-KEYWORD가 있으면, 원래 프록시로 가야 할 도메인이 그보다 먼저 DIRECT로 매칭될 수 있습니다. 로그 페이지에서 로그 레벨을 debug로 바꾸고 안 열리는 사이트에 접속해, 해당 도메인이 어떤 규칙에 매칭되어 어떤 정책 그룹으로 떨어지는지 확인하면 문제 규칙을 바로 찾을 수 있습니다.
5. 규칙셋(rule-provider)이 정상적으로 가져와지지 않음
원격 규칙셋을 사용할 때 가져오기가 실패하면 코어는 대부분 조용히 빈 규칙셋이나 이전 캐시를 사용하며 프록시 연결 자체를 끊지는 않습니다. 설정 페이지에서 규칙셋의 업데이트 시각을 확인하거나, 설정 파일에 다음과 같은 기본 규칙을 추가해 보세요:
rule-providers:
reject:
type: http
behavior: domain
url: "https://example.com/reject.txt"
path: ./ruleset/reject.txt
interval: 86400
rules:
- RULE-SET,reject,REJECT
- MATCH,PROXY
마지막의 MATCH,PROXY는 규칙셋에 걸리지 않은 모든 트래픽에 명확한 목적지를 지정해, 정의되지 않은 동작으로 빠지는 것을 막아줍니다.
6. FINAL / MATCH 규칙이 잘못된 정책 그룹을 가리킴
설정 파일 마지막의 기본 규칙(구버전 문법 FINAL, 신버전 문법 MATCH)이 잘못해서 DIRECT로 되어 있으면, 앞선 규칙에 매칭되지 않은 모든 도메인이 직결로 처리되며, 로컬 착지 노드가 없는 네트워크 환경에서는 대규모로 접속이 안 되는 상황이 됩니다. 설정 파일의 마지막 줄을 확인해 직결이 아니라 프록시 정책 그룹을 가리키는지 확인하세요.
점검 항목 7~9: DNS와 시스템 계층의 숨은 함정
7. DNS 해석이 오염되거나 잘못된 IP를 반환함
트래픽이 프록시를 거쳐도, 도메인 해석 단계에서 Clash가 가로챈 DNS가 아니라 로컬 통신사 DNS를 사용한다면 해석 결과가 여전히 오염될 수 있고, 잘못된 IP를 받으면 프록시가 아무리 빨라도 사이트가 열리지 않습니다. 설정 파일의 dns 항목이 활성화되어 있는지, enhanced-mode가 fake-ip 또는 redir-host로 설정되어 있는지 확인하세요:
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- 223.5.5.5
fallback:
- tls://1.1.1.1:853
fallback-filter:
geoip: true
geoip-code: CN
fake-ip 모드에서는 클라이언트가 도메인에 가상 IP를 부여하고 코어 계층에서 실제 요청을 복원하는 방식으로, 대부분의 로컬 DNS 오염을 피할 수 있어 현재 기본으로 권장되는 모드입니다.
8. 시스템 프록시가 실제로 적용되지 않음
일부 앱(특히 커맨드라인 도구, 일부 게임 클라이언트, 구버전 브라우저)은 시스템 프록시 설정을 읽지 않아서, Clash가 화면에서는 연결됨으로 표시되어도 이런 프로그램은 그대로 직결로 접속하며 자연히 프록시가 필요한 사이트는 열리지 않습니다. 시스템 프록시를 명확히 지원하는 앱(Chrome, Edge 등)으로 바꿔 다시 테스트해 보세요. 그 앱에서는 열린다면 앱이 시스템 프록시를 사용하지 않는 것이 원인이며 Clash 자체 문제가 아니므로, 해당 앱에 별도로 프록시 주소를 설정하거나 TUN 모드로 전환해 가로채도록 해야 합니다.
9. TUN 모드와 시스템 프록시가 동시에 켜져 충돌함
TUN 모드는 네트워크 계층에서 모든 트래픽을 가로채는데, 동시에 시스템 프록시도 수동으로 설정되어 있으면 두 경로가 겹쳐 라우팅 루프나 트래픽 중복 처리가 발생하기 쉽고, 간헐적으로 안 열리거나 상태가 오락가락하는 형태로 나타납니다. 둘 중 하나의 방식만 남기세요: TUN을 켰다면 시스템 프록시는 끄고, 반대의 경우도 마찬가지로 둘 다 동시에 켜지 않도록 합니다.
아홉 가지 점검 항목을 하나의 흐름으로 정리하면
어느 계층이 문제인지 확신이 없다면 아래 순서대로 진행하면 대부분 5분 안에 원인을 찾을 수 있습니다:
- 노드를 바꿔 테스트해서 노드 자체의 실패 여부를 제외한다(점검 항목 1~3).
- 로그 레벨을
debug로 바꿔 문제를 재현하고, 도메인이 어떤 규칙에 매칭되는지 확인한다(점검 항목 4~6). enhanced-mode가fake-ip인지 확인해 DNS 오염 여부를 점검한다(점검 항목 7).- 시스템 프록시를 명확히 지원하는 앱으로 바꿔 대조 테스트를 한다(점검 항목 8).
- TUN과 시스템 프록시가 동시에 켜져 있는지 확인한다(점검 항목 9).
이 다섯 단계를 마치면 "연결은 정상인데 안 열리는" 문제의 90% 이상은 구체적인 원인을 찾을 수 있습니다. 모든 항목을 확인해도 여전히 문제가 남아 있다면 설정 파일 자체의 작성 방식이 잘못됐을 가능성이 높으니, 출처가 명확하고 구조가 단순한 예시 설정으로 먼저 교체해 테스트한 뒤 클라이언트 자체에 이상이 없음을 확인하고 커스텀 규칙을 하나씩 다시 추가하는 것을 권장합니다.