화면은 멀쩡한데 인터넷이 안 될 때: 왜 로그를 먼저 보나
많은 「Clash가 연결되지 않는」 상황은 비슷합니다. 구독은 불러오고, 프로필도 로드되고, 노드 목록도 길게 보이는데 브라우저는 계속 돌거나, 영상만 버퍼링하거나, 잠깐 됐다가 또 끊깁니다. 이때 UI는 설정이 있다는 것만 보여 줄 뿐, 실제 연결 과정에서 무엇이 실패했는지는 잘 알려 주지 않습니다. 커널은 그래도 원격에 접속해 전송 계층 핸드셰이크를 마치고, 이름을 확인하고, 규칙에 따라 트래픽을 보내야 합니다. UI가 멀쩡해 보여도 이 단계들 중 어느 하나에서 멈출 수 있습니다.
클라이언트 로그는 「뭔가 이상하다」를 「어떤 유형의 문제인지」로 바꾸는 가장 빠른 방법입니다. 먼저 확인(lookup)이 실패했는지, dial에서 타임아웃인지, IP까지 붙은 뒤 TLS에서 실패했는지 보면 노드 교체, DNS 모드 변경, 인증서·SNI 점검, LAN·방화벽 조치 중 무엇이 필요한지 판단할 수 있습니다. 여러 노드가 번갈아 타임아웃된다면 구독·노드 유지보수와 함께 일시적 장애와 지속적인 노드 품질 저하를 구분하는 것도 도움이 됩니다.
일반 클라이언트에서 로그는 어디서 보나
메뉴 이름은 제각각이지만, 잘 유지되는 Clash 계열 클라이언트는 대개 어딘가에 로그 패널이 있고, 디스크에 로그 파일을 남기는 경우도 많습니다. 우선 앱 안의 로그부터 보세요. 현재 돌아가는 코어에 맞춰 필터링된 상태이기 때문입니다. 핸드셰이크 세부 정보가 필요하면 잠시 debug 또는 trace로 올렸다가, 끝나면 info 등으로 되돌리세요. 정보가 너무 많으면 핵심 줄이 묻힙니다. 여러 클라이언트를 비교 중이라면 플랫폼별 클라이언트 비교를 참고하세요. 업데이트 빈도와 커널 버전이 곧 로그의 쓸모와 새 전송 방식 대응 여부로 이어집니다.
커뮤니티에 로그를 올릴 때는 구독 토큰, 전체 프록시 URL, 개인·업무 도메인은 반드시 가립니다. 타임스탬프와 줄 순서는 유지하세요. 문제 해결은 「무엇이 먼저 실패했는지」가 중요하고, 마지막 빨간 줄만큼 항상 정답은 아닙니다. 「최근 이벤트만 복사」를 지원하면, 거대한 전체 로그 대신 그 기능을 쓰는 편이 낫습니다.
timeout·「컨텍스트 데드라인」류 메시지 읽기
timeout은 허용된 시간 안에 응답을 받지 못했다는 뜻입니다. 코어 버전과 전송에 따라 표현은 다르지만, i/o timeout, 멈춘 듯한 dial tcp, deadline exceeded, context deadline exceeded 같은 조각을 자주 봅니다. 업스트림 호스트와 포트가 함께 나오면, 이미 라우팅 결정이 끝난 뒤 소켓 연결을 시도했다는 신호입니다.
해석은 맥락이 있습니다. 다른 노드는 되는데 하나만 타임아웃이면 노드 단절·혼잡·구독 항목 오류처럼 노드 단위 이슈로 보는 편이 맞습니다. 다른 리전으로 바꾸거나, 제공자가 서버를 갈아줄 때까지 기다리거나, 프로필에 지연 테스트 그룹이 있으면 실행해 보세요. 모든 노드가 동시에 타임아웃이면 「전 세계 서버가 동시에 죽었다」는 경우는 드뭅니다. 공통 전제를 찾으세요: 집 ISP의 특정 포트 차단, 호텔·캠퍼스 네트워크의 TCP 제한, 회사 방화벽, 또는 이미 죽은 프록시로 구독 갱신까지 보내 버리는 잘못된 전역 규칙 등입니다.
일부 사이트만 안 되고 나머지는 되는 경우도 있습니다. 공격적인 QoS, 지리적 라우팅, 데이터센터 IP 대역을 막는 원격 사이트일 수 있습니다. 실패하는 도메인 하나와 되는 도메인 하나를 골라 로그에서 비교하고, 같은 프록시를 쓰는지 확인하세요. 기본 연결이 안정된 뒤 분류(규칙) 쪽을 의심할 때는 규칙·분류 모범 사례를 함께 보세요. 죽은 노드로 오인하지 않도록 합니다.
예시 로그 줄(설명용)dial tcp 203.0.113.10:443: i/o timeout
proxy/DIRECT: connect failed: context deadline exceededTLS 핸드셰이크 실패와 인증서 단서
TCP는 붙었는데 보안 계층에서 실패하면, 로그는 timeout 말투에서 TLS 오류로 넘어갑니다. tls: handshake failure, 인증서와 이름 불일치, unknown authority, x509 검증 문제, ClientHello 직후 EOF 같은 문구가 흔합니다. 경로는 어느 정도 통하지만 암호화 터널이 안 서거나 검증에 실패한 단계입니다.
시스템 시각·시간대를 다시 확인하세요. TLS는 시계 오차에 민감하고, 몇 분만 틀려도 공격처럼 보이는 인증서 오류가 쏟아질 수 있습니다. 그다음 노드가 요구하는 SNI(서버 이름 표시)를 확인하세요. Trojan, TLS 위의 VLESS 등은 클라이언트가 보내는 호스트 문자열과 엣지 서버 인증서의 이름이 맞아야 하는 경우가 많습니다. 구독 화면의 표시 이름만 바꾸고 SNI가 엇갈리면 IP는 열려 있어도 핸드셰이크가 실패할 수 있습니다.
로그에 기업 게이트웨이·SSL 검사·알 수 없는 CA 루트가 직접적으로 나오면 Clash 단독 버그라기보다 경로 상에서 TLS를 끊는 장치를 보고 있는 경우가 많습니다. 그 네트워크를 벗어나거나, 정책상 가능할 때만 필요한 신뢰 루트를 가져오거나, 환경에서 허용하는 전송을 쓰는 식으로 대응합니다. 공용 Wi‑Fi에서만 터지면 브라우저로 로그인 전에 DNS·HTTP를 가로채는 캡티브 포털을 의심하세요.
로그 스트림에 보이는 DNS 확인 오류
연결은 이름으로 시작하므로 DNS 문제는 자주 「프록시가 고장」처럼 보입니다. dial 시도 앞에 나오는 lookup 실패, no such host, NXDOMAIN, 확인자 타임아웃을 주목하세요. 프록시 호스트 이름 자체를 확인 못 하면 노드를 아무리 바꿔도 소용없습니다. 흔한 원인은 ISP DNS 오염, 아직 안 올라온 터널로 원격 DNS를 미리 보내는 프로필, 회사 VPN의 분할 DNS가 쿼리를 가로채는 경우 등입니다.
완화는 층을 나눠 시도합니다. 먼저 Clash 없이 기기에서 같은 이름이 확인되는지 일반 도구로 봅니다. OS 확인자가 정상인지 가늠합니다. 둘째, 클라이언트 DNS 설정에서 다른 서버를 쓰거나, 터널이 터널을 요구하는 부트스트랩 문제를 피하는 정책으로 바꿉니다. 어떤 구성은 전체 규칙 모드 전에 프록시 자체 도메인을 잠깐 직접 확인해야 합니다. 셋째, 제공자 문서와 함께 DNS·연결 관련 FAQ를 읽어 보세요. 일부 환경에서는 특정 DNS 모드만 허용하거나 특정 확인자를 금지합니다.
프록시 IP는 되는데 특정 도메인만 실패하면 광고 차단·규칙 공급자가 확인 경로를 막았거나, 국내 확인이 필요한 특수 도메인일 수 있습니다. DIRECT에서도 같은지 교차 확인하세요. DIRECT는 되는데 PROXY만 안 되면 터널 안의 확인 경로가 시스템과 달라 정렬이 필요합니다.
로컬 네트워크·방화벽·캡티브 포털
「permission denied」, 어댑터 생성 실패, TUN 붙이기 반복 실패 같은 로그는 원격이 아니라 로컬을 가리킵니다. Windows 백신·「스마트」 라우터·학교망은 가상 어댑터를 막거나 투명 모드를 깨는 필터를 넣기도 합니다. 최근 TUN이나 권한 상승을 켰다면, 노드를 의심하기 전에 플랫폼별 TUN 전제 조건을 다시 확인하세요.
방화벽이 Clash 실행 파일이나 권한 도우미 서비스를 막을 수도 있습니다. 원격 IP 없이 바로 실패하거나 로컬 bind 오류만 보일 수 있습니다. 다른 네트워크에서 잠깐 테스트(휴대전화 핫스팟이 대표적)로 ISP 문제와 노트북 설정 문제를 빠르게 가릅니다. 테스트 후에는 실험용 규칙을 되돌려 두세요.
바로 따라 할 수 있는 점검 체크리스트
같은 곳을 맴도는 디버깅을 줄이려면 아래 순서를 쓰세요. 각 단계가 한 종류의 원인을 걷어 냅니다.
- 기기 시각·시간대를 확인하고, 자동 동기가 켜져 있는지 봅니다.
- 직접 연결 등 되는 네트워크에서 구독을 갱신한 뒤, 서로 다른 노드 세 개를 다시 테스트합니다.
- 로그에서 첫 오류 묶음을 읽습니다. 마지막 줄만 보지 말고 DNS·dial·TLS 중 무엇인지 구분합니다.
- 다른 물리 네트워크(핫스팟 등)에서 테스트해 ISP 포트 차단·캡티브 포털을 배제합니다.
- 모드를 단순화합니다. TUN과 포트 프록시를 잠깐 바꿔 가며 어느 층에서 깨지는지 봅니다.
- 최소 프로필(알려진 정상 노드 하나만)과 비교해 규칙·공급자 오염을 걸러냅니다.
- 유지보수 습관을 점검합니다. 오래된 노드·만료 엔드포인트는 갱신·교체 전까지 반복 타임아웃으로 나타납니다.
여러 네트워크에서 끝까지 TLS에서만 막힌다면 로그를 가린 뒤 제공자에게 문의하세요. 인증서 교체·엣지 호환 조정이 필요할 수 있습니다. 끝이 항상 DNS라면 암호화 스위트를 건드리기 전에 확인자 정책부터 고치세요.
마무리: 추측 대신 증거로
연결 실패는 겉 증상이 거의 항상 같아서(아무것도 안 열린다) 혼란스럽게 느껴집니다. 그 안에서는 보통 DNS → TCP → TLS 순의 흔적이 남습니다. 이 용어들에 익숙해지면 앞으로 가져올 모든 프로필에 통하고, 근본 원인을 고치지 않은 채 규칙만 뒤섞는 일을 줄일 수 있습니다.
진단을 숨기는 원클릭 도구와 달리, 읽기 쉬운 로그와 잘 유지되는 Meta 계열 코어를 함께 쓰는 클라이언트는 투명성과 수명 면에서 유리합니다. 재설치에 쓰던 시간을, 실제로 네트워크에 먹히는 한두 설정에 쓰게 됩니다.