왜 문제가 날 때 먼저 연결 로그를 보나요?
프록시를 켠 뒤 특정 사이트만 하얀 화면이거나 타임아웃이 난다면, 사용자는 보통 노드를 바꾸거나 구독을 의심합니다. 그런데 실제로는 그 요청이 애초에 잘못된 출구로 분류됐거나, DNS가 Clash가 기대하는 IP와 어긋나 규칙이 엉뚱한 줄에 매칭된 경우가 많습니다. 이때 가장 빠른 단서가 바로 Clash 로그에 찍히는 규칙 적중(rule hit)과 연결 목적지, 선택된 정책 그룹·노드 정보입니다.
분류 규칙 설계 자체는 Clash 분류 규칙 최적 전략에서 다룬 것처럼 DOMAIN·GEOIP·MATCH 순서와 DNS 모드가 한 세트로 움직입니다. 로그는 그 세트가 실제 트래픽에 어떻게 적용됐는지를 사후 검증해 주는 창입니다. 따라서 「사이트가 안 열린다」는 증상 하나를 놓고도, 로그만 제대로 읽을 수 있으면 규칙 미스인지 프록시 경로 문제인지 이름 해석 문제인지를 빠르게 가를 수 있습니다.
로그를 켜고 필터링하기
Clash Meta(Mihomo) 코어는 일반적으로 info 수준에서도 연결·규칙 매칭 요약을 남깁니다. GUI 클라이언트(예: Windows의 Clash Verge 계열)에서는 설정에서 로그 레벨을 올리거나, 연결 패널·로그 뷰어를 열어 실시간으로 확인합니다. 터미널에서 코어를 직접 돌리는 경우에는 설정 파일의 log-level을 info 이상으로 두고, 표준 출력 또는 지정한 로그 파일을 tail 해 보세요.
문제 재현이 중요합니다. 브라우저에서 해당 사이트를 새로고침하거나, 터미널에서 curl로 동일 호스트에 요청을 보내는 순간에 로그가 한 줄씩 붙는지 확인하세요. 브라우저만 문제이고 터미널은 정상이면 시스템 프록시 미적용이나 TUN 미포함 앱 가능성이 커집니다. 이때는 Clash TUN 모드 가이드에서 설명한 것처럼 가상 어댑터로 앱 전체를 같은 규칙에 태우는지부터 점검하는 편이 낫습니다.
로그에서 꼭 볼 필드: 호스트, 규칙, 정책, 체인
구현·버전에 따라 표기는 조금씩 다르지만, 연결 한 건을 따라갈 때는 대개 아래를 묶어서 봅니다.
목적지 호스트 또는 IP — 브라우저 주소창의 도메인과 일치하는지, 서브도메인까지 같은지 확인합니다. CDN이나 API 전용 호스트가 따로 찍히면 규칙을 그 도메인 기준으로 잡아야 합니다.
매칭된 규칙 유형과 이름 — 예를 들어 DOMAIN-SUFFIX, GEOIP, MATCH 등 어떤 줄에 걸렸는지가 표시됩니다. 여기서 의도와 다른 유형이 보이면 규칙 순서나 Rule Provider 병합 결과를 의심합니다.
선택된 정책(프록시 그룹)과 실제 노드 — 규칙이 PROXY 같은 그룹을 가리키면, 그 안의 Selector·URL-Test 결과로 최종 아웃바운드가 정해집니다. 로그에 체인이나 proxy 이름이 찍히면 지연이 노드 쪽인지, 아예 핸드셰이크가 실패하는지까지 이어서 볼 수 있습니다.
DIRECT vs REJECT — 사이트가 안 열릴 때 로그에 REJECT 계열이 보이면 광고 차단·보안 규칙에 걸린 것일 수 있습니다. 반대로 해외 서비스가 DIRECT로만 나가면 방화벽·지역 제한에 막히는 패턴과 맞물릴 수 있습니다.
규칙 문제인지 DNS 문제인지 나누기
규칙 적중은 「이 IP(또는 이 연결)에 대해 어떤 줄이 이겼는가」를 말합니다. 반면 DNS는 그 전에 「이 도메인이 어떤 IP로 풀렸는가」를 결정합니다. fake-ip 모드에서는 클라이언트가 내부 대역의 가짜 주소를 돌려주고, 실제 매칭은 스니퍼나 도메인 정보에 의존하는 경우가 있어, 로그에 찍히는 목적지가 사용자가 생각한 퍼블릭 IP와 다르게 보일 수 있습니다.
접속이 실패할 때 다음 순서를 권장합니다. 먼저 로그에서 같은 요청에 대해 규칙이 일관되게 찍히는지 확인합니다. 매 요청마다 다른 규칙으로 튀면 병합 순서나 Provider 갱신 타이밍 문제일 수 있습니다. 다음으로 해당 도메인을 수동으로 조회했을 때의 IP와, Clash DNS 설정(nameserver, fallback, fake-ip)이 기대와 맞는지 대조합니다. DNS만 고쳤는데 규칙 매칭이 바뀌었다면 원인은 규칙이 아니라 이름 해석 쪽에 가깝습니다.
TLS/SNI가 있는 연결에서는 로그에 서버 이름이 분명히 남는 경우가 많아, 규칙을 DOMAIN 기준으로 추가할지 IP 기준으로 잡을지 판단하는 데 도움이 됩니다. 반대로 순수 IP 접속만 있을 때는 GEOIP·IP-CIDR 규칙에 더 잘 걸립니다.
YAML 규칙과 로그를 대조하는 법
프로필의 rules: 블록은 위에서 아래로 읽히며 첫 매칭에서 결정됩니다. 로그에 MATCH만 반복된다면 앞선 구체 규칙이 없거나 모두 빗나간 것입니다. 특정 사이트만 문제라면 로그에 찍힌 호스트 문자열을 복사해 DOMAIN 또는 DOMAIN-SUFFIX 줄을 넓은 DIRECT보다 위에 두는지 검토하세요.
Rule Provider를 여러 개 쓰면 실제 메모리에 올라간 순서가 사용자가 편집기에서 보는 것과 다를 수 있습니다. 로그의 규칙 이름이 예상 Provider와 다르면, 클라이언트의 프로필 병합·우선순위 문서를 확인하고 한 번에 한 Provider만 꺼 보는 식으로 원인을 좁히는 것이 좋습니다. Windows 초기 설정은 Clash Verge Rev Windows 가이드와 함께 보면 GUI에서 로그·프로필 위치를 맞추기 쉽습니다.
# Conceptual snippet — replace group names with your profile
rules:
- DOMAIN-SUFFIX,problem-site.example,PROXY_GROUP
- GEOIP,CN,DIRECT
- MATCH,PROXY_GROUP위는 개념 예시입니다. 실제로는 LAN·프로바이더 관리 도메인·REJECT 목록 등이 더 앞에 옵니다. 중요한 것은 로그에 찍힌 한 줄의 매칭 결과가 이 목록 중 어디와 같은지를 대응시키는 것입니다.
지연·노드 문제는 로그에서 어떻게 보이나요?
규칙이 올바른 프록시 그룹을 가리키는데도 타임아웃이면, 다음은 아웃바운드 지연과 핸드셰이크 오류를 봅니다. 같은 그룹에서 다른 노드를 고르면 즉시 나아지는지, 특정 프로토콜(UDP, QUIC)만 실패하는지도 구분하세요. 지연 숫자만 나쁜 경우와 연결 자체가 끊기는 경우는 대응이 다릅니다.
회사망이나 이중 VPN 환경에서는 Clash 로그만으로 부족할 때가 있어, 그때는 운영체제 라우팅 표와 방화벽 로그를 함께 보아야 합니다. 그래도 규칙 적중이 계속 의도와 같다면, 코어 대신 상위 네트워크나 대상 서비스 장애를 의심할 수 있습니다.
자주 나오는 패턴 정리
해외 사이트가 DIRECT로 찍힌다 — GEOIP나 국내 직결 묶음이 너무 앞에 있거나, DNS가 국내 IP로만 보이게 만든 경우입니다. 도메인 규칙을 앞으로 당기거나 DNS 모드를 조정합니다.
브라우저만 안 되고 터미널은 된다 — 시스템 프록시를 쓰지 않는 브라우저 프로필, 확장 프로그램의 별도 프록시, 또는 TUN 미적용입니다. TUN을 켠 뒤에도 같다면 브라우저 쪽 보안 DNS를 끄고 다시 시도해 보세요.
규칙은 맞는데 여전히 느리다 — 규칙은 성공했고 병목은 노드 품질·혼잡입니다. 측정 URL과 그룹 타입(url-test 간격 등)을 사용자의 주요 사이트에 맞추는 편이 낫습니다.
합법 사용·회사 정책
본 글은 기술적으로 연결 경로를 이해하고 고장을 줄이기 위한 일반 정보입니다. 거주지 법령과 서비스 약관을 준수하고, 소속 기관의 IT 정책이 있다면 우선합니다. 특정 서비스의 지역 제한을 우회하도록 조장하는 목적의 내용은 다루지 않습니다.
정리하며
사이트가 열리지 않을 때 Clash 연결 로그는 규칙·DNS·노드 중 어디를 손댈지 정하는 나침반이 됩니다. 규칙 적중 한 줄이 의도와 다르면 YAML 순서와 Provider를, 같으면 DNS와 아웃바운드 품질을 의심하는 흐름이 실무에서 잘 맞습니다. 설정을 여러 번 바꿀수록 로그와 프로필을 짝으로 두고 기록해 두면 같은 문제를 다시 헤매지 않습니다.
클라이언트별 설치와 기본 구성은 문서가 흩어져 있어 처음엔 막막할 수 있습니다. ClashFast 다운로드 페이지에서 플랫폼에 맞는 패키지를 한곳에서 받으면 출처를 줄이면서 시작할 수 있습니다. 로그 읽는 법을 익혔다면 → Clash를 무료로 내려받아 연결 패널을 열고, 지금 쓰는 사이트가 어떤 규칙에 걸리는지 직접 확인해 보세요.