증상은 비슷한데, 원인은 완전히 다를 수 있습니다

Clash 계열 클라이언트를 켠 뒤에도 브라우저가 하얀 화면에서 멈추거나, 특정 사이트만 자꾸 타임아웃되고, 잠깐 됐다가 또 끊기는 패턴은 흔합니다. 이때 사용자 입장에서는 모두 「연결 실패」로 느껴지지만, 내부적으로는 로컬 머신에서 프록시 포트를 제대로 열지 못한 경우와 이미 포트는 열렸는데 업스트림 노드·회선 쪽에서 응답이 늦거나 끊기는 경우로 나뉩니다. 전자는 설정 파일의 mixed-port·port·socks-port 충돌이나 다른 프로그램의 점유가 대표적이고, 후자는 로그에 자주 등장하는 dial tcp 이후의 지연·실패 메시지로 추적하게 됩니다.

이 글은 TUN·DNS 같은 넓은 주제 대신, 로그 한 줄을 보고 다음 액션을 정하는 데 초점을 맞춥니다. 네트워크 정책·서비스 약관·지역 규정은 사용자 환경마다 다르므로, 허용된 용도와 본인 책임 범위 안에서만 적용하시기 바랍니다. 용어와 기본 흐름을 먼저 익히려면 Clash 사용 문서를 함께 보는 것을 권장합니다.

1단계: 로그를 볼 수 있게 만들기

GUI 래퍼(예: Verge 계열)를 쓰면 코어 로그가 별도 패널에 모입니다. 코어만 단독으로 돌릴 때는 표준 출력이나 지정한 로그 파일에 같은 메시지가 쌓입니다. 문제 재현 직전에 로그 레벨을 info 이상으로 잠시 올려 두면, 포트 바인딩 실패와 아웃바운드 다이얼 실패가 동시에 섞여 나와도 구분하기 쉽습니다. 다만 장시간 debug를 켜 두면 디스크와 UI가 무거워질 수 있으니, 원인을 좁힌 뒤에는 다시 낮추는 습관이 좋습니다.

로그에는 타임스탬프·레벨·메시지가 한 줄로 붙는 형식이 일반적입니다. 아래에서 인용하는 영어 구문은 실제 코어·버전에 따라 단어 순서가 조금 달라질 수 있지만, 핵심 키워드(bind, address already in use, dial tcp, timeout 등)는 대부분의 Mihomo(Clash Meta) 계열에서 비슷하게 나타납니다.

2단계: 「포트·리슨」 쪽 이상 징후

로컬에서 HTTP·SOCKS 리스너를 열지 못하면, 브라우저가 프록시 주소로 붙는 순간부터 실패합니다. 이때 로그에는 서버 주소로 나가기 전에 막힌 흔적이 남습니다. 대표적으로 다음과 같은 표현이 보이면 포트 충돌·권한·설정 오류를 우선 의심하세요.

• listen tcp … bind: address already in use — 이미 다른 프로세스가 같은 포트를 쓰고 있음
• listen … permission denied — 특정 OS·환경에서 보호된 포트나 권한 문제
• mixed-port·port·socks-port 관련 오류가 시작 직후 반복 — YAML에서 서로 다른 키가 같은 숫자를 가리키거나, 중복 인스턴스가 동시에 떠 있음

설정 파일에서 mixed-port는 HTTP와 SOCKS를 한 포트에서 받는 편의 옵션이고, port는 전통적인 HTTP 프록시 포트, socks-port는 SOCKS5 전용입니다. 일부 구성에서는 mixed만 쓰고 나머지를 0으로 두기도 하지만, 의도치 않게 둘 다 같은 포트 번호를 가리키면 충돌이 납니다. 또 다른 Clash 인스턴스·이전에 크래시 난 프로세스·VPN/보안 소프트웨어가 같은 포트를 잡고 있는 경우도 흔합니다.

listen tcp :7890: bind: address already in use

위와 비슷한 한 줄이 보이면, 먼저 7890(또는 설정한 값)을 누가 쓰는지 OS 도구로 확인하는 것이 빠릅니다. macOS·Linux에서는 lsof -i :7890, Windows에서는 netstat -ano로 PID를 찾아 충돌 프로세스를 종료하거나, Clash 쪽 포트 번호를 바꾸면 됩니다. 브라우저·시스템 프록시 설정이 예전 포트를 가리키고 있으면 포트를 바꾼 뒤 클라이언트와 OS 설정을 함께 맞춰야 합니다.

3단계: 「dial tcp」 이후의 노드·회선 징후

리슨이 정상이라면, 로그의 다음 단계는 보통 업스트림 프록시 서버로 TCP 연결을 시도하는 부분입니다. 여기서 자주 보는 접두가 dial tcp 또는 connect 계열입니다. 이어서 나오는 호스트·포트는 노드 주소이므로, 메시지가 이 단계에서 오래 머무르거나 실패하면 노드 가용성·방화벽·지역 라우팅·혼잡 쪽을 의심합니다.

• dial tcp … i/o timeout — TCP 핸드셰이크나 응답이 제한 시간 안에 오지 않음
• TLS … handshake timeout / EOF — 전송 구간은 열렸지만 TLS·프로토콜 협상에서 끊김
• connection reset by peer — 상대방이 연결을 강제로 끊었거나 중간 장비가 리셋

이 패턴은 로컬 포트는 비어 있는데도 발생할 수 있습니다. 즉 사용자가 포트를 바꿔도 증상이 그대로이면, 다음 단계는 노드 교체·다른 프로토콜·다른 리전으로의 A/B 테스트가 됩니다. 반대로 dial은 성공하는데 애플리케이션 레벨에서만 느리다면 DNS·규칙·특정 도메인 매칭을 의심해야 해서, 이 글의 초점과는 조금 결이 다릅니다. DNS 쪽을 같이 보고 싶다면 사이트 내 DNS 유출 방지 가이드와 문서의 DNS 항목을 대조해 보세요.

dial tcp 198.51.100.10:443: i/o timeout

한 줄에 나온 IP·포트가 구독에 있는 노드와 일치하는지 확인하면, 「특정 노드만 죽는지」를 빠르게 가릴 수 있습니다. url-test·fallback 그룹을 쓰는 경우, 로그에 같은 시간대에 여러 노드로 연쇄적인 dial 실패가 찍히면 회선 전체 이슈일 가능성이 큽니다.

4단계: 판별 순서(짧은 체크리스트)

현장에서 시간을 아끼려면 아래 순서를 권장합니다. 각 단계에서 「이상 없음」이면 다음으로 넘어가세요.

1. 시작 직후 로그 스캔: bind·already in use·listen 오류가 있으면 포트·중복 실행을 먼저 해결합니다.
2. YAML 포트 키 점검: mixed-port, port, socks-port, (사용 중이면) redir-port 등이 서로 겹치지 않는지, 그리고 시스템 프록시가 가리키는 값과 일치하는지 봅니다.
3. 단일 노드로 고정 테스트: 자동 선택 그룹 대신 지연 낮은 노드 하나만 골라 직접 연결해 봅니다. 이때도 dial 타임아웃이면 로컬 포트 문제가 아니라 업스트림 쪽 가능성이 큽니다.
4. 다른 네트워크에서 재현: 같은 기기로 테더링·다른 Wi-Fi에서만 정상이면, 원래 LAN이나 ISP 경로 이슈일 수 있습니다.
5. 코어·GUI 버전 정렬: 구버전에서 특정 프로토콜 파싱 버그가 나면 로그에 TLS·프록시 핸드셰이크 오류가 반복될 수 있습니다. 안정적인 빌드는 공식 다운로드 페이지에서 받는 흐름이 관리하기 쉽습니다.

이 순서의 장점은 로그 상에서 원인 축을 먼저 나눈다는 점입니다. 포트 문제를 노드 교체로 해결하려 하거나, 반대로 노드 장애를 포트 변경만으로 넘기려 하면 시간만 소모하기 쉽습니다.

mixed-port와 단일 포트를 같이 쓸 때의 흔한 실수

많은 사용자가 브라우저 확장·OS 설정에 127.0.0.1:7890 같은 한 주소만 넣어 둡니다. 이때 Clash 쪽은 mixed-port: 7890으로 맞추고 HTTP·SOCKS를 동시에 받게 하는 경우가 많습니다. 그런데 예전 프로필에 port: 7890과 socks-port: 7890이 남아 있거나, 다른 도구가 7890을 쓰도록 설치되어 있으면 충돌이 납니다. 로그에 mixed 관련 메시지와 함께 bind 오류가 보이면, 숫자 한 개가 겹쳤는지부터 표로 적어 보는 것만으로도 정리가 빨라집니다.

또 한 가지는 관리자 권한 없이 TUN·리다이렉트 포트를 켠 경우입니다. 환경에 따라 특정 포트 범위는 일반 사용자에게 막혀 있어, 리슨 실패가 권한 메시지로 나타날 수 있습니다. 이때는 포트를 높은 번호로 옮기거나, 정책에 맞게 권한·드라이버 설치를 갖추는 쪽이 맞습니다.

타임아웃 로그를 볼 때의 해석 주의점

i/o timeout은 「노드가 나쁘다」는 뜻만은 아닙니다. 로컬 방화벽이 아웃바운드를 드롭하면 비슷하게 보일 수 있고, DNS가 느리면 애플리케이션이 먼저 지쳐 끊는 경우도 있습니다. 그래도 같은 설정으로 어제는 되고 오늘만 안 된다면, 구독 노드의 지리적 거리·피크 시간·차단 정책 변화를 함께 의심해야 합니다. 장기적으로는 지연 테스트 URL·interval·tolerance를 현실적으로 맞추는 것이 재시도 폭주를 줄입니다. 자동 선택과 튜닝 개념을 더 깊게 보고 싶다면 속도 최적화 팁에서 url-test·fallback 운용을 참고하면 좋습니다.

한눈에 보는 키워드 대응표

아래는 로그에 자주 등장하는 패턴과 우선 조치 방향을 요약한 것입니다. 정확한 문자열은 빌드마다 다를 수 있으니, 키워드 중심으로 기억하세요.

정리

연결 문제를 로그로 나누면 대응이 단순해집니다. 리슨 단계에서 터지면 로컬 포트와 설정을, dial 이후에 터지면 노드와 경로를 보면 됩니다. 규칙 기반 클라이언트는 한번 구조를 잡아 두면 앱·사이트 단위 제어가 매끄럽고, 로그만 읽을 줄 알아도 운영 부담이 크게 줄어듭니다. 비슷한 범주의 도구와 비교해도, 한 설정 트리에서 프록시·DNS·규칙을 같이 다루는 방식은 재현과 트러블슈팅에 여전히 유리한 편입니다.

최신 코어와 검증된 클라이언트 패키지를 유지하면 파싱·TLS 스택 쪽에서 생기는 오해 가능성도 줄어듭니다. 설치 경로를 한곳으로 정리해 두면 로그 해석과 업데이트가 한결 가벼워집니다.

→ Clash를 무료로 내려받아, 로그 기반 점검과 안정적인 프록시 환경을 함께 갖춰 보세요