「연결됨」이 실제로 의미하는 것
많은 클라이언트에서 보이는 「연결됨」은 로컬 리스닝 포트와 코어 기동까지를 가리키는 경우가 많습니다. 즉 「인터넷이 된다」와 동치가 아닙니다. 시스템 프록시가 Clash의 mixed나 http 포트를 가리키지 않거나, 브라우저 확장이 자체 프록시를 쓰고 있거나, 앱이 OS 프록시를 무시하면 패널은 초록색인데 트래픽은 Clash 밖으로 새어 나갑니다. 반대로 TUN을 켜 두었다면 시스템 표시와 무관하게 가상 인터페이스 쪽으로 붙어야 하므로, 어떤 경로로 패킷이 들어오는지부터 머릿속에 그려 두는 것이 첫 단계입니다.
이후 절차는 모두 재현 가능한 증거를 모으는 데 집중합니다. 브라우저 주소창에 문제가 되는 URL을 하나 고정해 두고, 같은 순간의 코어 로그 한 줄과 대조하는 방식이 가장 빠릅니다. 용어 정리는 문서 허브와 함께 보면 설정 파일의 블록 이름이 더 잘 맞물립니다. 아래 내용은 불법 우회나 타인의 통신을 관찰하는 방법이 아니며, 본인의 장비에서 합법적인 범위 안에서만 적용하세요.
실측 전 준비: 로그 레벨과 한 줄짜리 재현
원인을 가르기 위해서는 INFO 이상에서 rule hit나 DNS 관련 줄이 보이도록 맞추는 것이 좋습니다. 너무 조용하면 「아무 일도 없었다」처럼 보이고, 너무 시끄러우면 중요한 줄을 놓칩니다. 가능하면 GUI의 최근 연결 목록과 텍스트 로그를 같이 열어, 동일한 타임스탬프 근처만 좁혀 읽으세요. 한 번에 여러 사이트를 뒤지기보다, 하나의 호스트로 고정하는 편이 DNS인지 프록시인지 갈라 내기 쉽습니다.
Windows에서 시스템 프록시만 켠 상태라면 터미널 도구는 여전히 직통일 수 있습니다. 터미널까지 같은 정책으로 묶고 싶다면 환경 변수와 셸 설정을 점검하는 흐름이 별도로 필요합니다. macOS에서 비슷한 증상이면 터미널 프록시 가이드를 참고해 주세요.
1단계: 로그에서 「어느 정책에 붙었는지」를 먼저 본다
Clash 계열에서 가장 값진 단서는 종종 어느 규칙 줄에 매칭됐는지입니다. 로그에 DIRECT로 나가는데 회사망이나 ISP가 해당 목적지를 막고 있으면, 브라우저는 영원히 돌기만 합니다. 반대로 프록시 그룹으로 나갔는데 바로 뒤에 핸드셰이크 오류가 붙으면 DNS보다 노드·TLS 쪽을 우선 의심합니다.
규칙은 위에서 아래로 스캔되며 처음 참이 된 한 줄에서 결정이 납니다. 그 위에 넓은 GEOIP,CN나 거대한 RULE-SET이 있으면, 아래에 써 둔 예외는 실행되지 않습니다. 기대와 다른 policy가 찍힌다면 「내가 아는 그 도메인」이 아니라 실제로 연결에 쓰인 SNI나 호스트가 다를 수 있습니다. CDN 앞단의 다른 이름으로 붙는 경우가 흔합니다. 규칙 문법과 순서 감각을 다시 잡으려면 사용자 정의 규칙 입문 글의 순서 설명을 함께 보는 것이 좋습니다.
2단계: DNS 모드와 해석 실패를 구분한다
증상이 「하얀 화면에서 오래 멈춘 뒤 타임아웃」에 가깝다면 DNS 단계를 의심합니다. redir-host와 fake-ip는 호스트가 로그에 어떻게 찍히는지부터 규칙 매칭 타이밍이 달라집니다. fake-ip를 쓰는 프로필에서 IP 기반 규칙만 과하게 쌓아 두면, 브라우저가 보여 주는 주소와 실제 외부 왕복이 어긋나 첫 바이트까지의 시간만 길어지는 패턴도 나옵니다. 이때는 모드를 바꾸기보다, 지금 모드에 맞는 DOMAIN 계열 규칙과 순서를 맞추는 쪽이 안전합니다.
상위 DNS 서버가 느리거나 차단되면, 프록시 노드가 아무리 살아 있어도 앱은 시작조차 못 합니다. 로그에 DNS 타임아웃이나 NXDOMAIN에 가까운 흔적이 반복되면, nameserver 파이프와 fallback 그룹, 그리고 시스템 DNS와의 이중 질의를 점검하세요. 애드블록용 DNS를 쓰다가 특정 도메인만 죽는 경우도 같은 그룹에 속합니다. TUN과 DNS를 동시에 켠 환경에서는 루프나 이중 해석이 생기기도 하므로, TUN 모드 가이드에서 DNS 스택을 함께 정리해 보세요.
3단계: 규칙 누락·MATCH 폴백과 「가짜 직통」
프로필 끝의 MATCH가 의도치 않은 그룹을 가리키면, 일부 사이트만 프록시를 타지 않거나 반대로 전부 느린 우회만 합니다. 원격 규칙 세트가 오래됐거나 내려받기에 실패하면, 생각보다 많은 트래픽이 기본 폴백 줄로 떨어집니다. 이때 로그에는 특별한 에러가 없이 조용히 DIRECT나 단일 그룹만 찍히는 경우가 많아, 사용자는 「연결은 됐는데 왜 안 열리지」라는 느낌만 받게 됩니다.
해결 순서는 간단합니다. 규칙 프로바이더 캐시를 갱신하고, 실패한 세트가 있으면 잠시 로컬 예외 줄을 위쪽에 추가해 재현이 사라지는지 확인합니다. 장기적으로는 Rule Providers의 갱신 주기와 behavior를 운영 가능한 값으로 맞추는 것이 좋습니다. 세트를 크게 쪼개 관리하는 패턴은 Rule Providers 가이드에서 이어집니다.
4단계: TLS·인증서·SNI 메시지를 읽는다
DNS가 끝난 뒤 첫 TLS 핸드셰이크에서 막히면, 브라우저는 보안 경고나 끊김으로 표현합니다. 코어 로그에는 인증서 검증 실패, ALPN 불일치, SNI 관련 오류가 다른 어조로 남습니다. 중간에 HTTPS 검사를 하는 보안 제품이 있으면, Clash가 기대하는 체인과 실제 체인이 달라져 같은 사이트만 실패하는 모양이 나옵니다.
일부 노드 타입은 서버 이름 표시 방식에 민감합니다. 구독에 적힌 server와 실제 SNI가 어긋나면 연결은 시도되다 끊깁니다. 이때는 노드 편집 화면의 SNI·TLS 옵션을 제공자 문서와 맞추고, 동일한 호스트로 수동 SELECT 그룹에 고정해 재현이 사라지는지 확인하세요. 프로토콜별로 전송 계층이 어떻게 다른지는 프로토콜 비교 글을 참고하면 TLS가 개입하는 지점을 잡기 쉽습니다.
5단계: 노드 레이어—지연 표가 아니라 실제 왕복
대시보드의 지연 숫자는 측정 URL과 시점에 따라 들쭉날쭉합니다. 숫자가 초록색이어도 특정 목적지만 막히면, 그 경로의 핸드셰이크 로그를 봐야 합니다. connection reset류, 빈번한 재시도, 특정 포트만 실패하는 패턴은 노드 측 정책이나 중간 장비의 영향일 수 있습니다. 가능하면 같은 프로필로 다른 노드 하나만 골라 바꿔 넣고, 동일한 URL을 다시 열어 차이를 확인하세요.
구독 스냅샷이 오래되면 이름은 살아 있는데 실제 엔드포인트는 이미 바뀐 경우도 있습니다. 수동 새로고침 후에도 같은 증상이면, 로컬 캐시와 GUI의 선택 상태가 YAML과 동기화됐는지까지 확인합니다. 코어 버전이 문서와 어긋나면 옵션이 조용히 무시되기도 하니, 장기 운영이라면 업그레이드 가이드의 백업 절차를 한 번씩 밟아 두는 편이 안전합니다.
증상·로그 매트릭스로 한눈에 보기
정리하면 다음과 같습니다. 페이지가 아예 안 뜨고 로그에 DNS 타임아웃이 먼저 보이면 DNS 파이프와 모드를, rule hit가 DIRECT인데 목적지가 막히는 회선이면 규칙 순서와 세트 신선도를, 프록시로 나갔는데 곧바로 TLS 오류면 인증서·SNI·중간 검사를, 핸드셰이크 직후 끊기면 노드·프로토콜 호환을 우선합니다. 한 번에 모든 슬라이더를 움직이지 말고, 한 축만 바꾼 뒤 같은 URL로 다시 재현해 보세요.
체감 속도가 전반적으로 느린 경우와, 이번 글처럼 「아예 안 열린다」는 경우는 우선순위가 다릅니다. 전자는 URL-TEST 간격이나 이중 프록시 같은 변수가 앞에 오고, 후자는 DNS와 첫 매칭 줄이 앞에 옵니다. 혼합 증상이면 시간대를 나누어 로그를 두 벌 모아 비교하는 것이 좋습니다. 속도 쪽 체크리스트는 속도 최적화 팁과 짝을 이룹니다.
맺음말
「연결됐는데 인터넷이 안 된다」는 문장 하나에 여러 계층이 숨어 있습니다. 패널의 초록불에 안심하기보다, 같은 순간의 로그에서 정책 이름과 오류 한 줄을 짝지어 읽는 습관이 가장 큰 비용 대비 효과가 큽니다. Clash 계열은 규칙과 로그가 비교적 읽기 쉬워, 이런 고장 사슬을 스스로 풀기에 유리한 편입니다.
설치 파일을 다시 받거나 주변에 배포할 때는 출처가 분명한 페이지를 기준으로 맞추는 것이 재현과 보안에 모두 이롭습니다. GUI로 시작했더라도, 결국 한두 블록의 DNS와 rules만 정확히 이해해도 비슷한 증상에서 헤매는 시간이 크게 줄어듭니다.