Clash 노드 타임아웃 및 연결 불가 문제 해결 순서

구독 유효성, 노드 지연 테스트, 포트 점유, 시스템 프록시 상태, 방화벽 차단 순서로 연결 실패 문제를 단계별로 점검하고 각 단계에 맞는 해결 방법을 제시합니다.

노드 타임아웃이나 연결 불가는 Clash 및 그 파생 코어(Clash Meta, mihomo)를 사용하면서 가장 흔하게 마주치는 문제 유형이지만, 겉으로 보이는 증상이 같아도 원인은 완전히 다른 경우가 많습니다. 구독 자체가 이미 만료되었을 수도 있고, 노드 서버 쪽에 일시적인 문제가 생겼을 수도 있으며, 로컬 네트워크 설정이 충돌하고 있을 수도 있습니다. 무작정 하나씩 추측하며 시도하면 시간을 낭비하기 쉬우므로, 바깥쪽에서 안쪽 순서로 고정된 절차에 따라 하나씩 배제해 나가야 빠르게 원인을 찾을 수 있습니다. 이 글에서 제시하는 점검 순서는 한 가지 원칙을 따릅니다. 먼저 데이터 소스가 정상인지 확인하고, 그다음 소프트웨어가 정상적으로 동작하는지 확인하고, 마지막으로 시스템 환경이 프록시 트래픽을 제대로 허용하고 있는지 확인하는 순서입니다.

점검 전 기본적인 상황 판단

구체적인 단계에 들어가기 전에 먼저 문제의 범위를 파악해야 합니다. 클라이언트를 열어 연결 실패 안내 문구와 영향 범위를 관찰하면 점검 방향을 좁힐 수 있습니다.

  • 모든 노드가 연결되지 않는 경우: 구독, 시스템 프록시, 방화벽처럼 전반적인 문제일 가능성이 높습니다.
  • 일부 노드만 연결되지 않고 나머지는 정상인 경우: 해당 노드 서버 자체의 문제이거나, 지연 테스트 결과 자체가 원래 비정상적이었을 가능성이 높습니다.
  • 이전에는 잘 되다가 갑자기 전부 안 되는 경우: 먼저 구독이 만료됐는지, 트래픽이 소진됐는지 확인하고, 그다음 새로 설치한 프로그램이 포트를 점유하고 있는지 확인합니다.
  • 새 기기나 새 시스템으로 바꾼 뒤 연결이 안 되는 경우: 먼저 시스템 프록시와 방화벽 설정을 확인합니다. 새로운 환경에서 가장 빠지기 쉬운 설정이기 때문입니다.

이러한 초기 판단을 마친 뒤, 아래 다섯 단계를 순서대로 점검하면 대부분 두 번째에서 네 번째 단계 사이에서 구체적인 원인을 찾을 수 있습니다.

1단계: 구독이 유효한지 확인

구독 만료는 모든 노드가 타임아웃되는 가장 흔한 원인이지만 쉽게 간과됩니다. 클라이언트 화면에는 노드 목록이 여전히 표시되지만, 그 뒤에 있는 서비스가 이미 응답을 멈춘 경우가 많기 때문입니다. 구독 유효성은 다음 몇 가지 관점에서 확인할 수 있습니다.

  1. 구독 만료일과 남은 트래픽 확인: 대부분의 구독 서비스는 링크나 패널에 만료일과 남은 트래픽 정보를 제공합니다. 클라이언트의 구독 관리 페이지에도 보통 이 두 항목이 표시되므로, 만료되었거나 트래픽이 소진되었는지 확인합니다.
  2. 구독 수동 업데이트: 클라이언트의 구독 목록에서 수동 업데이트(보통 새로고침 아이콘이나 "구독 업데이트" 버튼)를 실행해 봅니다. 업데이트가 실패하며 네트워크 오류나 링크 무효 안내가 나오면 구독 주소 자체에 문제가 있다는 뜻입니다.
  3. 업데이트 시각이 이상한지 확인: 자동 업데이트 시각이 오랫동안 예전 시각에 머물러 있다면, 정기 업데이트가 네트워크 문제로 계속 실패하고 있을 가능성이 있으며, 현재 노드 목록은 사실상 오래된 캐시 데이터입니다.
  4. 구독 링크가 잘리지 않았는지 확인: 구독 링크를 수동으로 복사해서 가져올 때 링크 끝부분의 파라미터가 누락되기 쉬워, 링크가 가리키는 내용이 불완전해질 수 있습니다. 링크를 처음부터 다시 완전하게 복사하는 것이 이 가능성을 배제하는 가장 간단한 방법입니다.

주의: 구독 업데이트가 성공했는데 노드 수가 이전과 완전히 동일하다고 해서 구독이 반드시 유효한 것은 아닙니다. 서비스 제공자가 관리를 중단하면 노드 목록이 오랫동안 변화가 없을 수 있으므로, 이 경우 2단계의 지연 테스트를 함께 확인해야 합니다.

2단계: 노드 지연 테스트

구독이 유효함을 확인한 다음 단계는 구체적으로 어떤 노드에 문제가 있는지 판단하는 것입니다. Clash 클라이언트는 보통 노드 목록 옆에 지연 테스트 기능을 제공하며, 클릭하면 각 노드에 네트워크 탐지를 실행해 왕복 시간(밀리초)을 표시합니다. 결과를 볼 때 다음 상황들을 구분해서 확인해야 합니다.

  • 구체적인 밀리초 값이 표시되는 경우(예: 80ms): 해당 노드는 현재 정상적으로 연결되며, 타임아웃 문제는 이 노드에 있는 것이 아니므로 시스템 쪽 원인을 계속 점검해야 합니다.
  • 타임아웃 또는 무응답이 표시되는 경우: 해당 노드 서버가 현재 사용 불가능한 상태로, 서버 유지보수, 회선 불안정, 또는 해당 노드가 대규모로 제한받고 있을 가능성이 있습니다. 같은 그룹 내 다른 노드로 전환해 봅니다.
  • 모든 노드가 타임아웃으로 표시되는 경우: 지연 테스트 자체도 네트워크 연결을 통해 이루어지므로, 테스트 요청조차 나가지 못한다면 문제는 대개 노드 서버가 아니라 로컬 네트워크 환경에 있습니다. 이 경우 뒤쪽의 포트, 시스템 프록시, 방화벽 점검으로 넘어가야 합니다.

지연 테스트에 사용되는 URL은 보통 설정에서 직접 지정할 수 있습니다. 기본 테스트 주소 자체가 현재 네트워크 환경에서 도달하지 않는다면(예: 기본값으로 특정 사이트를 사용하는 경우) 테스트 결과가 전체적으로 비정상적으로 나올 수 있으므로, 테스트 주소를 바꿔서 다시 시도해 테스트 경로 자체의 문제를 배제할 수 있습니다.

특정 노드만 지속적으로 지연이 높거나 자주 타임아웃되고, 같은 구독의 다른 노드는 정상이라면 대개 해당 노드의 회선 품질 문제입니다. 이 경우 노드를 바로 바꾸는 것이 가장 직접적인 해결 방법이며, 그 노드 하나를 붙잡고 계속 점검할 필요는 없습니다.

3단계: 포트 점유 확인

지연 테스트조차 완료되지 않는다면, 다음으로 Clash가 사용하는 로컬 포트가 다른 프로그램에 점유되어 있는지 확인해야 합니다. Clash 코어가 시작될 때 프록시 요청을 받기 위해 로컬 포트 여러 개를 열어두는데, 일반적으로 HTTP 프록시 포트, SOCKS5 프록시 포트, 혼합 포트(mixed-port)가 있습니다. 이 포트들이 이미 다른 프로그램에 점유되어 있으면 코어가 정상적으로 리스닝을 시작하지 못해 모든 트래픽이 전달되지 않는 문제가 생길 수 있습니다.

포트 점유는 다음과 같은 방식으로 확인할 수 있습니다.

  1. 클라이언트의 로그 패널을 열어 코어 시작 시 "포트가 이미 사용 중"이나 "bind: address already in use"와 같은 오류 메시지가 있는지 확인합니다.
  2. 시스템 명령줄에서 포트 점유 상태를 조회합니다. Windows에서는 명령줄 도구로 특정 포트를 사용 중인 프로세스를 확인할 수 있습니다.
netstat -ano | findstr 7890

macOS와 Linux에서는 다음 명령을 사용할 수 있습니다.

lsof -i :7890
  1. 다른 프로그램이 Clash가 사용해야 할 포트를 점유하고 있다면 해당 프로그램을 종료하거나, 클라이언트 설정에서 Clash가 사용하는 포트 번호를 변경해 충돌을 피할 수 있습니다.
  2. 포트 번호를 변경한 뒤에는 코어를 재시작해 설정을 적용해야 하며, 시스템 프록시 설정에 기록된 포트 번호도 함께 갱신되었는지 확인해야 합니다. 두 값이 일치하지 않으면 시스템 프록시가 더 이상 아무도 감시하지 않는 포트를 가리키게 됩니다.

참고: Clash 클라이언트를 동시에 두 개 실행하거나, 이전 프로세스가 완전히 종료되지 않은 상태에서 다시 실행하는 것이 포트 충돌의 가장 흔한 원인입니다. 시스템을 재시작하거나 관련 프로세스를 완전히 종료하면 대부분 해결됩니다.

4단계: 시스템 프록시 상태 확인

포트가 정상적으로 리스닝 중인데도 브라우저 등 애플리케이션이 여전히 프록시를 통해 인터넷에 접속하지 못한다면, 시스템 프록시가 실제로 적용되고 있는지 확인해야 합니다. 시스템 프록시는 어떤 애플리케이션이 트래픽을 Clash에 넘길지를 결정합니다. 이 설정이 잘못되면 노드와 포트가 모두 정상이어도 트래픽이 Clash를 거치지 않습니다.

  • 클라이언트 내 시스템 프록시 스위치 확인: 클라이언트 설정에서 "시스템 프록시로 설정" 또는 유사한 옵션이 켜져 있는지 확인합니다. 일부 클라이언트는 재시작 후 이 스위치 상태를 자동으로 복원하지 않으므로 수동으로 다시 켜야 할 수 있습니다.
  • 운영체제의 프록시 설정 확인: 시스템 네트워크 설정에서 프록시 주소와 포트가 클라이언트가 현재 사용하는 포트와 일치하는지 확인합니다. 특히 포트 번호를 수동으로 변경한 뒤에는 시스템 레벨의 프록시 설정이 자동으로 동기화되지 않는 경우가 있습니다.
  • 시스템 프록시와 TUN 모드 구분: 시스템 프록시는 시스템 프록시 설정을 따르는 애플리케이션에만 적용됩니다. 명령줄 도구, 일부 게임, 백그라운드 서비스는 시스템 프록시 설정을 읽지 않을 수 있으며, 이 경우 시스템 프록시가 켜져 있어도 해당 애플리케이션은 여전히 연결 불가로 표시됩니다. 이때는 시스템 프록시 레벨에서 계속 점검하기보다 TUN 모드로 전환해 모든 트래픽을 처리하도록 해야 합니다.
  • 브라우저나 애플리케이션 자체의 프록시 설정: 일부 브라우저는 시스템 프록시와 별도로 자체 네트워크 설정 항목을 가지고 있습니다. 브라우저에 "시스템 프록시 사용 안 함"이 설정되어 있으면 시스템 프록시가 정상적으로 동작하고 있어도 해당 브라우저는 Clash를 통해 인터넷에 접속할 수 없습니다.

이 단계에 문제가 없는지 확인하는 간단한 방법은 클라이언트의 연결 로그나 트래픽 패널을 열어 실시간 연결 기록이 발생하는지 관찰하는 것입니다. 브라우징 요청을 보낸 뒤에도 패널에 새로운 연결이 전혀 나타나지 않는다면, 트래픽이 Clash로 유입되지 않고 있다는 뜻이며 문제는 시스템 프록시 설정 단계에 있는 것으로 볼 수 있습니다.

5단계: 방화벽 차단 확인

시스템 프록시 설정에 문제가 없고 트래픽이 이미 Clash로 들어갔는데도 여전히 타임아웃이 발생한다면, 마지막으로 방화벽이나 보안 소프트웨어가 Clash의 네트워크 접속을 차단하고 있는지 확인해야 합니다. 이 문제는 새로 설치한 시스템, 기업에서 관리하는 컴퓨터, 또는 보안 소프트웨어를 방금 업데이트한 뒤에 특히 자주 발생합니다.

  1. 시스템 기본 방화벽 확인: Clash 본체와 그 코어 프로세스가 방화벽의 인바운드·아웃바운드 규칙에서 허용되어 있는지 확인합니다. 처음 실행 시 차단당한 경우 운영체제가 보통 권한 승인 팝업을 띄우는데, 여기서 거부가 아니라 허용을 선택해야 합니다.
  2. 서드파티 보안 소프트웨어 확인: 일부 보안 소프트웨어는 프록시 계열 도구를 위험 프로그램으로 인식해 눈에 띄는 알림 없이 네트워크 요청을 조용히 차단합니다. 이 경우 보안 소프트웨어의 로그나 화이트리스트 설정에서 Clash 실행 파일을 수동으로 추가해야 합니다.
  3. 라우터 또는 게이트웨이 단계의 제한 확인: 일부 가정용 라우터나 회사 네트워크는 게이트웨이 단계에서 포트 제한이나 프로토콜 식별을 수행합니다. 로컬 단계의 모든 점검이 정상인데도 여전히 연결이 안 된다면, 네트워크 환경을 바꿔서(예: 휴대폰 테더링) 비교 테스트를 해보고 문제 범위를 좁힐 수 있습니다.
  4. 노드가 사용하는 전송 프로토콜이 특정하게 제한받고 있지 않은지 확인: 일부 네트워크 환경은 특정 프로토콜 특징을 식별해 방해합니다. 같은 구독에서 특정 프로토콜 유형의 노드는 전반적으로 타임아웃되는데 다른 프로토콜 유형의 노드는 정상이라면, 네트워크 환경이 해당 프로토콜을 제한하고 있는 것이므로 정상적으로 동작하는 프로토콜 유형의 노드를 우선적으로 선택해야 합니다.

주의: 방화벽을 끄고 테스트하는 것은 원인을 임시로 확인하는 용도로만 사용해야 합니다. 차단 원인을 확인한 뒤에는 방화벽을 다시 켜고 해당 프로그램에 대한 허용 규칙을 추가해야 하며, 시스템 보호 기능을 장기간 꺼두어서는 안 됩니다.

여전히 해결되지 않을 때의 추가 점검 항목

위 다섯 단계를 모두 점검했는데도 문제가 여전히 남아 있다면 다음 항목들을 추가로 확인해 볼 수 있습니다. 상대적으로 드물지만 실제로 연결 실패를 유발하는 경우들입니다.

  • 설정 파일 내 규칙 충돌: 규칙 세트를 직접 커스터마이징했다면, 원래 프록시로 처리되어야 할 트래픽이 잘못된 규칙으로 직접 연결 그룹에 분류되고 있는지, 또는 프록시 그룹의 정책 선택기 설정이 잘못되어 실제로 선택된 노드와 화면에 표시되는 노드가 다른지 확인합니다.
  • DNS 해석 이상: 프록시 연결이 정상이어도 DNS 해석에 문제가 있으면 브라우저는 접속 불가로 표시할 수 있습니다. 설정에서 DNS 관련 항목을 확인하거나, fake-ip 모드로 전환해 DNS 해석으로 인한 연결 실패 착시 현상인지 점검해 볼 수 있습니다.
  • 코어 버전과 설정 형식 불일치: 클라이언트나 코어 버전을 업데이트한 뒤 기존 설정 파일의 필드가 변경되거나 폐기되었을 수 있습니다. 로그에 설정 파싱 관련 경고나 오류가 있는지 확인합니다.
  • 시스템 시간 부정확: 일부 노드의 암호화 프로토콜은 시스템 시간 오차에 민감합니다. 시스템 시간이 실제 시간과 크게 차이 나면 핸드셰이크에 실패해 연결 타임아웃으로 나타날 수 있습니다. 시스템 시간을 확인하고 교정하면 이 유형의 문제를 배제할 수 있습니다.

이 다섯 단계와 추가 점검 항목을 순서대로 진행하면 대부분의 노드 타임아웃 문제는 그 안에서 명확한 원인을 찾을 수 있습니다. 소프트웨어를 무작정 재시작하거나 노드를 계속 바꾸기보다는, 먼저 로그를 확인하고 단계별로 점검하는 습관을 들이는 것이 훨씬 안정적으로 문제를 해결하는 방법입니다.

점검을 마쳤다면 클라이언트가 최신 버전인지 확인하세요

일부 연결 문제는 구버전 클라이언트와 코어 사이의 호환성 결함에서 발생합니다. 최신 버전으로 업데이트하고 설정 가이드를 다시 확인하면 같은 문제를 반복해서 겪지 않을 수 있습니다.

클라이언트 다운로드