Clash for Windows 트래픽·Connections·코어 로그로 지연·미경유 진단하기

왜 Connections·로그를 봐야 하나

사용자가 체감하는 문제는 대개 세 가지로 줄어듭니다. 첫째, 사이트는 열리는데 매우 느리다. 둘째, 특정 앱·도메인만 실패한다. 셋째, IP 조회·제한 정책상 프록시를 타야 하는데 DIRECT로 나간다. 이 세 가지는 모두 「지금 이 연결이 어떤 규칙으로 어떤 노드 체인을 탔는지」를 보면 원인 범위가 달라집니다.

브라우저 개발자 도구는 한 탭의 HTTP만 보여 주지만, Clash의 Connections는 코어가 실제로 잡은 5·4계층 흐름에 가깝게 보여 줍니다. 로그는 같은 순간 코어가 DNS를 어디서 물었는지, 규칙 일치 문자열이 무엇인지, 다이얼 오류가 TLS인지 타임아웃인지를 남깁니다. 두 화면을 나란히 두면 추측으로 노드를 갈아끼우는 횟수를 줄일 수 있습니다.

패널을 열기 전에 확인할 것

Connections가 비어 있거나 로그만 조용하면, 대부분 트래픽이 Clash까지 오지 않은 상태입니다. General에서 System Proxy가 켜져 있는지, 모드가 Rule 또는 Global인지 먼저 확인합니다. 게임·터미널·일부 Microsoft Store 앱은 시스템 프록시를 무시하므로 그때는 TUN이나 앱별 프록시가 필요합니다. 반대로 회사 PC에서는 GPO가 프록시를 덮어 Connection 행 자체가 생기지 않을 수도 있습니다.

활성 프로필이 방금 받은 구독인지도 같이 봅니다. 프로필은 바꿨는데 예전 빈 구성이 선택된 채라면, Connections에 잡히는 행이 없거나 예상과 다른 DEFAULT 규칙만 반복됩니다. 구독 갱신 오류는 보통 Profiles 카드나 로그에 HTTP 코드로 먼저 드러납니다.

Connections 화면에서 무엇을 읽나

Clash for Windows의 Connections(연결) 탭은 실시간으로 호스트·포트·프로토콜·프로세스(가능한 경우)·다운로드/업로드 누적을 보여 줍니다. 버전·스킨에 따라 열 이름이 조금 다를 수 있으나 의미는 동일합니다. 한 행은 코어 관점에서의 하나의 플로우에 가깝고, 페이지를 새로 열 때마다 행이 추가·갱신됩니다.

관찰 포인트	해석
호스트 / SNI	어느 도메인 요청인지 구별합니다. CDN 뒤에 있어도 일단은 사용자가 입력한 이름에 맞는 행을 찾습니다.
Chain / Policy	어느 프록시 그룹·노드를 거쳤는지, DIRECT인지 표시됩니다. 기대한 그룹 이름과 다르면 규칙 순서를 의심합니다.
Rule / Match 힌트	UI에 규칙 라벨이 보이면 어떤 RULE 줄에 맞았는지 추적하기 쉽습니다. 안 보이면 로그의 rule match와 시간을 맞춥니다.
업링크·다운링크 바이트	멈춘 페이지도 TCP 연결은 살아 있어 바이트가 안 오를 수 있고, 반대로 배경 동기화는 잘 돌아갑니다. 체감과 수치를 함께 봅니다.

특정 사이트만 느릴 때는 그 사이트를 연 직후 목록에서 같은 호스트 묶음을 찾아 체인이 원하는 노드로 나갔는지를 먼저 확인합니다. 체인은 맞는데 속도가 나쁘면 노드 품질·지역 라우팅·혼잡 쪽으로 방향을 돌리고, 체인이 DIRECT라면 GEOIP·DOMAIN 규칙이 의도와 다르게 맞았는지 봅니다.

트래픽·통계는 어디에서 보나

CFW 본체는 대시보드 성격의 대역폭 그래프를 제공하는 편이라, 「오늘 총 몇 GB」 같은 계정형 통계보다는 실시간 다운/업 속도 확인에 가깝습니다. 세부 호스트별 장기 누적은 Connections 행의 바이트 카운터로 순간값을 보는 방식이 일반적입니다. 대시보드가 있는 빌드에서는 메인 창 하단이나 별도 카드에 현재 세션 요약이 표시되기도 하니, 사용 중인 CFW 버전의 스크린샷 설명과 함께 대조해 보세요.

Proxies 탭의 URL 테스트·지연 숫자는 트래픽 통계는 아니지만, Connections에서 특정 노드로만 붙는지 확인한 뒤 그 그룹의 품질을 수치로 비교하는 데 반드시 필요합니다. 지연은 낮은데 실제 전송이 느리면 ISP 경로나 SNI 차단, 패킷 손실 쪽을 의심합니다.

Logs 탭과 코어(Core) 로그 레벨

Logs는 GUI가 아니라 백엔드 코어 프로세스의 표준 로그를 보여 주는 창입니다. 디버깅 시 로그 레벨을 info 이상으로 올려 두는 편이 안전합니다. debug는 매치 문자열이 길게 나와 규칙 순서를 따라가기 좋지만, 장시간 켜 두면 디스크·CPU를 쓰므로 문제 재현 구간에만 씁니다.

자주 보는 패턴은 다음과 같습니다. rule 또는 match 관련 줄이면 어느 규칙이 이겼는지 추적합니다. DNS 오류면 리졸버가 응답하지 않거나 fake-ip와 실제 연결 단계가 어긋난 경우가 많습니다. dial tcp·i/o timeout·connection reset는 노드·방화벽·중간 장비에서 끊긴 흔적입니다. TLS 핸드셰이크 실패는 SNI 정책·중간 검사·잘못된 스니핑 설정과 연관될 수 있습니다.

시나리오별로 이렇게 읽기

느리지만 결국 열린다

Connections에서 해당 호스트 행의 체인이 기대한 프록시 그룹이면, 우선 다른 노드로 바꿔 같은 호스트 행이 빨리 안정되는지 봅니다. 로그에 반복 타임아웃만 쌓이면 노드 쪽이거나 중간 회선 문제일 확률이 큽니다. 반대로 처음 한두 번만 느리고 이후 빠르면 DNS 캐시·콜드 스타트·TLS 세션 재협상 패턴일 수 있습니다.

아예 안 열리거나 끊긴다

행이 아예 없으면 트래픽이 Clash에 안 들어온 것입니다. 행은 있는데 바이트가 안 오르면 스니핑·HTTPS 가로채기·MITM 정책이 섞였는지, 또는 해당 도메인이 IPv6 AAAA만 반환돼 경로가 꼬였는지 의심합니다. 로그에 DNS 실패와 dial 오류가 같이 있으면 전형적인 「이름은 됐는데 소켓이 안 붙는다」 분기입니다.

프록시를 탄 것 같은데 IP는 국내다

브라우저 IP 조회 사이트는 어떤 탭·어떤 DNS 경로로 질의했는지에 따라 결과가 달라질 수 있습니다. Connections에서 실제로 어떤 체인으로 나갔는지 확인한 뒤, 별도 탭에서 동일하게 테스트합니다. Rule 모드에서 IP 조회 도메인만 DIRECT로 빠지도록 구독이 짜여 있으면 사용자 기대와 어긋납니다.

규칙(룰) 적용을 의심할 때

Clash 규칙 엔진은 위에서 아래로 첫 일치에서 멈춥니다. 그래서 구독이 넣은 GEOIP,CN나 광범위한 DOMAIN-SUFFIX가 앞에 있으면, 사용자가 나중에 추가한 세밀한 줄이 아예 실행되지 않습니다. Connections·로그에서 잡힌 도메인 이름을 기준으로 프로필 YAML의 RULE 섹션을 스크롤하며 순서를 재점검합니다.

fake-ip를 쓰는 구성에서는 브라우저가 보는 IP와 코어 내부 매핑이 달라 보여 혼란이 생깁니다. 「연결은 됐는데 내용이 비정상」 패턴이면 「연결됐는데 인터넷이 안 될 때: DNS·fake-ip」를 같이 읽으면 DNS 축 검증이 빨라집니다. 스니핑(sniffer) 설정은 HTTPS 호스트 추론에 영향을 주므로, 특정 API만 깨질 때는 예외 도메인을 넣는 편이 안전합니다.

Clash Verge Rev 사용자 참고

UI 이름은 다르지만 개념은 같습니다. 연결 목록·로그·프로필 전환이 어디에 있는지만 맞추면 이 글의 절차를 그대로 적용할 수 있습니다. 신규 사용자는 「Windows 11 Clash Verge Rev 설치」로 먼저 첫 연결을 만든 뒤, 이 문서로 진단 습관을 붙이면 학습 비용이 줄어듭니다.

현장 워크플로를 길게 밟을 때

실제 지원을 받거나 스스로 기록을 남길 때는 「증상 한 줄 + Connections 한 줄 + 로그 세 줄」이 최소 단위입니다. 증상은 「유튜브 4K만 버퍼링」「OAuth 콜백이 루프」「사내 Git만 느림」처럼 재현 순서까지 적습니다. Connections 쪽은 문제가 난 시각에 가장 가깝게 나타난 호스트, 체인에 찍힌 그룹 이름, DIRECT 여부를 그대로 복사합니다. 로그는 rule match가 있으면 그 규칙 이름, DNS 질의가 있으면 질의한 이름과 응답 형태, dial 오류면 타임아웃인지 리셋인지만 발췌해도 다음 행동이 달라집니다.

브라우저 확장 프로그램의 광고 차단·HTTPS 필터·별도 PAC이 켜져 있으면 Connections에 보이는 호스트와 주소창의 호스트가 어긋날 수 있습니다. 확장이 프록시를 직접 잡으면 OS 프록시와 이중으로 겹치기도 합니다. 이럴 때는 시크릿 창이나 확장을 모두 끈 프로필에서 같은 절차를 한 번 더 밟아 「깨끗한 기준선」을 만든 뒤 비교하는 편이 논쟁을 줄입니다.

멀티 프로필·멀티 디바이스 환경에서는 한 PC에 Clash 두 종류가 동시에 떠 있거나, 예전 포트를 물고 있는 좀비 프로세스가 남아 충돌하는 경우가 있습니다. 작업 관리자에서 과거에 쓰던 클라이언트 이름을 검색해 종료하고, 7890·9090 등 자주 쓰는 포트를 netstat로 점검해 보면 원인 후보를 빨리 줄일 수 있습니다. 포트를 바꿨다면 General에 표시된 mixed-port·HTTP 포트와 Windows 시스템 프록시에 적힌 숫자가 같은지 다시 맞춥니다.

방화벽·다른 VPN과 함께 쓸 때

Windows Defender 방화벽이 Clash 본체의 수신을 막으면 localhost 프록시는 살아 있어도 헬퍼·컨트롤러·스크립트 연결이 간헐적으로 끊길 수 있습니다. 처음 실행 시 뜨는 네트워크 프로필 허용 대화상자를 습관적으로 닫았다면, 방화벽 고급 설정에서 해당 실행 파일의 아웃바운드·인바운드 규칙을 확인합니다. 보안 제품을 추가로 켠 기업 PC는 앱별 트래픽 검사 때문에 TLS 핑거프린트가 달라지고, 로그에는 정상 연결처럼 보이다가 클라이언트만 실패하는 패턴이 나올 수 있습니다.

다른 상용 VPN과 Clash를 동시에 켜면 default route나 DNS가 둘 다 바뀌어 Connections 행과 실제 패킷 경로가 엇갈립니다. 이때는 먼저 한쪽을 완전히 끄고 단일 스택으로 재현해 본 뒤, 분할 터널링 가능 여부를 검토합니다. 회사 정책상 전역 VPN을 끌 수 없다면 Clash를 쓰지 않는 편이 안전하며, 문서화된 예외 없이 우회하면 징계 사유가 될 수 있습니다.

로그에 자주 보이는 패턴

아래 표는 의학이 아니라 현장에서 자주 쓰는 가설 생성표입니다. 한 줄만 보고 단정하지 말고, 같은 시각대 Connections의 체인과 같이 읽습니다.

로그에 비슷하게 보이는 키워드	가능한 방향	다음 행동
DNS, resolve, nxdomain	리졸버 실패·도메인 오타·필터	구독 DNS 설정, fake-ip, 실제 ISP DNS와 비교
i/o timeout, deadline exceeded	노드 혼잡·경로 불안·UDP 차단	다른 노드, 가능하면 다른 프로토콜 그룹으로 교차 검증
connection reset, EOF	중간 장비 리셋·SNI 차단·협상 실패	스니핑·스플릿 설정, 동일 사이트를 다른 브라우저에서
certificate, tls, handshake	MITM·시계·스니핑 범위	시스템 시각, 회사 SSL 검사, sniffer exclude 목록
rule, match … DIRECT	규칙 순서·GEOIP 결과	YAML RULE 위에서부터 스캔, 조회 IP의 국가 라벨 확인

지연과 손실을 구분하기

사용자 입장에서는 둘 다 느리게 느껴집니다만, Connections에서 바이트가 꾸준히 오르면서 재생만 끊기면 대역폭·버퍼 이슈에 가깝고, 바이트가 한동안 멈췄다가 조금 오르면 지터·손실·협상 재시도에 가깝습니다. Proxies 탭의 핑은 ICMP나 짧은 TCP 측정이라 실제 HTTPS 다운로드와 항상 일치하지 않습니다. 핑은 낮은데 영상만 나쁘면 해당 CDN 엣지가 막힌 케이스일 수 있으니 같은 사이트의 다른 화질·다른 시간대를 같이 봅니다.

무선 환경에서는 AP 로밍 순간에 Connections 행이 잠깐 끊겼다가 같은 호스트로 다시 생기는 일이 흔합니다. 이때 로그에 연속된 dial 오류가 짧게 찍히면 네트워크 레이어 이슈를 먼저 의심하고, 프록시 설정을 만지기 전에 유선으로 재현해 보는 것이 시간을 아낍니다.

브라우저 밖(터미널·IDE)도 같은 방법이 통하나

터미널 도구는 환경 변수 HTTP_PROXY·HTTPS_PROXY를 안 쓰면 시스템 프록시만으로는 Connections에 안 잡힐 수 있습니다. IDE 내장 터미널은 부모 프로세스의 환경을 물려받기도 하고 안 물려받기도 합니다. 「터미널 HTTP·Git 프록시」에서 플랫폼별로 변수를 어디에 두는지 정리해 두고, Clash 쪽 Connections와 타임스탬프를 맞춰 보면 정책이 제대로 먹었는지 빠르게 확인할 수 있습니다.

컨테이너·WSL·가상머신 안에서의 연결은 또 다른 환경입니다. 호스트 Windows의 Clash 포트를 바라보게 만들었는지, 게스트가 자체 DNS를 쓰는지에 따라 같은 규칙이라도 다른 결과가 납니다. 이 경우 호스트 측 Connections에 게스트의 NAT 출구가 어떻게 찍히는지부터 보는 것이 순서입니다.

자주 묻는 질문

Q: Connections에 아무것도 안 보여요.

시스템 프록시가 꺼져 있거나, 테스트한 프로그램이 프록시를 따르지 않는 경우가 흔합니다. 브라우저로 먼저 재현하고, 필요하면 TUN을 켭니다. 다른 VPN·필터 드라이버가 같이 켜져 있으면 트래픽이 Clash로 안 들어올 수 있습니다.

Q: 로그가 너무 빨리 지나가요.

로그 레벨을 한 단계 낮추고, 문제 행동 직전에 창을 열어 둔 채 짧게 재현합니다. 파일로 남기는 옵션이 있는 빌드는 개인정보를 제거한 뒤 일부만 공유하세요.

Q: 설정을 바꿨는데도 같은 DIRECT가 반복돼요.

mixin·원격 구독이 RULE을 덮어쓰는지, 캐시된 프로필이 예전 파일인지 확인합니다. 코어 재시작 후에도 동일하면 구독 쪽 기본 정책이 강할 수 있습니다.

정리

Connections는 지금 이 연결이 어디로 나갔는지를 한눈에 보여 주고, 로그는 왜 그렇게 나갔는지를 문장으로 남깁니다. 두 가지를 같이 쓰면 노드만 무작정 바꾸는 대신 규칙·DNS·출구를 세 축으로 나누어 대응할 수 있습니다. 문제가 해결되면 Clash를 종료할 때 Windows 프록시가 남지 않도록 「종료 후 시스템 프록시 복구」도 함께 확인해 두면 좋습니다.

Clash 클라이언트를 무료로 내려받고, 사용 중인 GUI에 맞춰 동일한 진단 흐름을 유지하세요.