문제 해결 예상 읽기 시간 12분

Clash 노드 시간 초과로 연결되지 않을 때: 로컬 네트워크부터 프록시 경로까지 점검 순서

로컬 네트워크, 구독 상태, 노드 가용성, 프록시 모드, DNS, 시스템 방화벽 순서로 Clash 연결 시간 초과 원인을 확인하세요.

Clash에 노드 시간 초과가 표시된다는 것은 특정 연결이나 지연 시간 테스트가 제한 시간 안에 유효한 응답을 받지 못했다는 뜻일 뿐, 노드 자체가 작동하지 않는다는 의미는 아닙니다. 문제는 로컬 네트워크 진입점, 구독 설정, 노드 서버, 정책 그룹 선택, DNS 확인, 시스템 프록시, TUN 라우팅, 방화벽 등 어느 계층에서든 발생할 수 있습니다. 여러 설정을 동시에 변경하면 원래의 장애 지점이 새로운 변수에 가려져 오히려 점검 시간이 길어집니다.

연결 경로를 따라 계층별로 확인하는 것이 좋습니다. 먼저 기기가 직접 인터넷에 연결되는지 확인하고, 설정이 실제로 업데이트되었는지 검증한 다음 노드와 프로토콜을 점검하세요. 이후 프록시 모드와 규칙 적용 결과를 확인하고, 마지막으로 DNS, TUN, 포트 점유, 보안 소프트웨어를 살펴봅니다. 각 단계의 결과를 기록하면 모든 웹사이트가 열리지 않는 문제를 네트워크 계층, 설정 계층, 전달 계층 중 하나로 좁힐 수 있습니다.

1. 시간 초과가 발생한 계층부터 구분하기

‘시간 초과’는 하나의 오류만을 뜻하지 않습니다. 클라이언트 화면의 지연 시간 테스트, 브라우저 로딩 실패, 로그에 기록된 연결 시간 초과는 서로 다른 경로를 검사할 수 있습니다. 일부 클라이언트는 지정된 HTTP 또는 HTTPS 주소로 지연 시간을 측정하며, 이 과정에는 DNS, TCP 연결, TLS 핸드셰이크, HTTP 응답이 포함됩니다. 따라서 ICMP Ping과는 같지 않습니다. 테스트 주소에 일시적으로 접근할 수 없어도 노드가 다른 요청을 전달할 가능성은 있습니다.

일반적인 증상과 초기 판단

클라이언트 화면과 실제 코어 상태도 구분해야 합니다. 그래픽 클라이언트는 설정 관리와 시스템 연동을 담당하고, Clash Meta(현재는 주로 mihomo라는 이름으로 유지 관리됨) 같은 코어는 규칙 매칭, 프로토콜 연결, 트래픽 전달을 담당합니다. 화면이 계속 실행 중이라고 해서 코어가 정상적으로 시작되었다는 뜻은 아닙니다. 로그에 설정 파싱 실패, 수신 포트 생성 실패, 권한 오류가 나타나면 먼저 코어를 정상 실행한 뒤 노드를 테스트하세요.

2. 로컬 네트워크 진입점과 시스템 기본 상태 확인하기

시스템 프록시를 끄고 TUN을 일시 중지한 뒤 평소 안정적으로 접속되는 웹사이트를 직접 열어 보세요. 직접 연결도 실패한다면 현재 문제의 유일한 변수가 Clash는 아닙니다. Wi-Fi 인증이 완료되었는지, 유선 인터페이스가 주소를 받았는지, 모바일 핫스팟에 데이터 연결이 있는지, 회사나 학교 네트워크에 웹 인증이 필요한지 먼저 확인하세요. 공용 네트워크의 인증 페이지는 보통 직접 연결로 먼저 열어야 하며, 프록시나 암호화 DNS가 인증 페이지 표시를 방해할 수 있습니다.

  1. 다른 VPN, 네트워크 가속기, 패킷 캡처 도구, 가상 네트워크 어댑터 프로그램을 잠시 종료해 여러 프로그램이 기본 경로나 DNS를 동시에 변경하지 않도록 하세요.
  2. 현재 네트워크에 다시 연결한 뒤 시스템이 유효한 IP 주소, 기본 게이트웨이, DNS 서버를 할당받았는지 확인하세요.
  3. 기기의 날짜, 시간, 시간대를 확인하세요. 시간 오차가 크면 TLS 인증서 검증이 실패해 구독 업데이트 실패나 HTTPS 연결 오류로 나타날 수 있습니다.
  4. 가정용 인터넷과 모바일 핫스팟을 각각 테스트하세요. 같은 설정이 핫스팟에서는 작동하고 가정용 인터넷에서는 작동하지 않는다면 라우터, 통신사 경로, 로컬 네트워크 정책과 관련된 문제일 가능성이 높습니다.
  5. 클라이언트를 다시 시작한 뒤 코어 시작 로그를 확인해 HTTP, SOCKS, mixed 수신 포트가 생성되었는지 확인하세요.

네트워크를 전환하면 이전 인터페이스와 경로가 잠시 남아 있을 수 있습니다. 특히 유선 네트워크에서 Wi-Fi로, 회사 네트워크에서 핫스팟으로 전환한 뒤에는 TUN이 자동으로 인식한 출력 인터페이스가 아직 갱신되지 않았을 수 있습니다. 이때는 먼저 TUN을 끄고 시스템 경로가 안정될 때까지 기다린 다음 다시 켜세요. 클라이언트에 ‘코어 다시 시작’이나 ‘설정 다시 불러오기’ 기능이 있다면 같은 구독을 반복해서 가져오기보다 해당 기능을 우선 사용하세요.

3. 구독 상태와 설정이 실제로 적용되었는지 확인하기

구독 업데이트 성공 메시지는 클라이언트가 어떤 다운로드 작업을 완료했다는 뜻일 뿐, 다운로드한 내용이 유효한 Clash 설정이라는 보장은 없습니다. 구독 주소 만료, 서버의 로그인 페이지 반환, 네트워크 인증 페이지로 대체된 응답, 현재 클라이언트와 호환되지 않는 구독 형식 때문에 노드 목록이 비어 있거나 이전 캐시가 계속 사용될 수 있습니다.

먼저 구독 업데이트 시간, 설정 파일 이름, 노드 수를 확인하세요. 노드 이름, 정책 그룹, 규칙이 서버의 최근 변경 사항과 다르면 수동으로 업데이트하고 로그를 확인하세요. YAML 파싱 오류의 흔한 원인으로는 들여쓰기 오류, 콜론 뒤 공백 누락, 문자열의 특수 문자를 올바르게 인용하지 않은 경우, 현재 코어가 지원하지 않는 필드를 참조한 경우가 있습니다.

구독 점검 순서

  1. 구독 주소가 여전히 유효하고 계정의 서비스가 만료되거나 일시 중지되지 않았는지 확인하세요.
  2. 직접 연결로 한 번 업데이트해 보세요. 직접 업데이트가 되지 않으면 이미 사용 가능한 프록시를 통해 다시 시도해 구독 서버로의 접근 경로를 판단하세요.
  3. 응답 내용이 설정 텍스트인지, HTML 로그인 페이지·오류 페이지·게이트웨이 인증 페이지인지 확인하세요.
  4. 클라이언트에서 실제로 방금 업데이트한 설정을 활성화했는지 확인하세요. 이전 설정, 예제 설정, 다른 로컬 파일이 활성화되어 있을 수 있습니다.
  5. 설정을 다시 불러온 뒤 정책 그룹 선택을 확인하세요. 그룹 내 노드 이름이 바뀌면 이전 선택이 초기화되거나 사용할 수 없는 항목을 가리킬 수 있습니다.

공개 로그, 스크린샷, 포럼 게시물에 전체 구독 주소, 노드 비밀번호, UUID, 인증서 필드, 액세스 토큰을 표시하지 마세요. 이러한 값은 연결 자격 증명입니다. 문제를 점검할 때는 보통 프로토콜 유형, 서버가 도메인인지 여부, 포트 범위, 전송 방식, TLS 상태, 오류 유형만 남기면 충분합니다.

가져온 뒤 코어가 시작되지 않으면 정상적으로 로드되는 이전 설정으로 잠시 되돌려 클라이언트와 네트워크 환경이 여전히 정상인지 확인한 다음 두 설정의 차이를 비교하세요. 설정 파일을 크게 삭제하거나 수정하기 전에는 원본 사본을 보관해야 합니다. 규칙 세트, 프록시 제공자, 외부 리소스 다운로드 실패 때문에 설정 로드가 오류 상태에서 멈출 수도 있습니다.

4. 노드, 프로토콜 매개변수, 서버 경로 검증하기

로컬 네트워크와 설정이 정상임을 확인한 뒤 구체적인 노드를 점검하세요. 먼저 같은 구독에서 지역과 진입점이 서로 다른 노드 두세 개를 선택해 테스트하세요. 특정 노드만 실패한다면 정책 그룹에서 해당 노드를 잠시 제외할 수 있습니다. 같은 서버의 여러 포트가 모두 실패한다면 서버 오프라인, 진입 도메인 확인 오류, 네트워크 경로 차단 가능성이 있습니다.

노드 매개변수는 주소와 포트만 맞는다고 충분하지 않으며 서버와 전체적으로 일치해야 합니다. 프로토콜에 따라 비밀번호, UUID, 암호화 방식, TLS, SNI, ALPN, 전송 계층, WebSocket 경로, gRPC 서비스 이름, Reality 관련 매개변수가 필요할 수 있습니다. 어느 한 필드라도 일치하지 않으면 TCP 연결 후 핸드셰이크 시간 초과가 발생하거나 연결이 종료될 수 있습니다.

로그 키워드로 오류 단계 찾기

노드 서버 주소 자체가 도메인이라면 Clash는 프록시 연결을 설정하기 전에 해당 도메인을 먼저 확인해야 합니다. 이때 사용하는 DNS가 아직 연결되지 않은 동일한 프록시 경로에 의존하면 시작 단계에서 의존성 문제가 발생합니다. mihomo 설정의 proxy-server-nameserver는 프록시 서버 도메인을 확인하는 데 사용할 수 있지만, 실제로 설정이 필요한지는 현재 DNS 구성과 코어 버전에 따라 결정해야 합니다.

IPv6도 별도로 확인해야 합니다. 네트워크에서 IPv6 주소를 할당받더라도 안정적인 IPv6 출구가 없을 수 있습니다. DNS가 AAAA 레코드를 반환하면 사용할 수 없는 경로를 기다리다가 연결 시간 초과가 발생합니다. 문제를 점검하는 동안에는 클라이언트 DNS에서 IPv6 응답을 일시적으로 끄거나 IPv6를 명확히 지원하는 네트워크로 전환해 비교해 보세요. 원인을 확인한 뒤 IPv4 우선 설정을 유지할지 IPv6 경로를 수정할지 결정하면 됩니다.

5. 프록시 모드, 정책 그룹, 규칙 적용 결과 확인하기

노드를 사용할 수 있다고 해서 트래픽이 반드시 해당 노드를 통과하는 것은 아닙니다. Clash의 규칙 모드는 위에서부터 규칙을 매칭하고, 일치하면 해당 정책 그룹이나 동작으로 넘깁니다. 대상 도메인이 앞쪽의 DIRECT 규칙에 걸리면 다른 프록시 노드로 바꿔도 결과는 달라지지 않습니다. 점검할 때는 연결 기록을 열어 대상 도메인, 대상 IP, 적용된 규칙, 아웃바운드 정책, 실제 노드를 확인하세요.

비교를 위해 잠시 전역 프록시 모드로 전환해 볼 수 있습니다. 전역 모드에서는 작동하고 규칙 모드에서는 실패한다면 규칙 순서, 규칙 세트 로드, 정책 그룹 선택을 중점적으로 확인하세요. 두 모드 모두 실패한다면 노드, DNS, 시스템 프록시, 네트워크 진입점과 관련된 문제일 가능성이 높습니다. 테스트가 끝나면 모든 트래픽이 예상 규칙에서 장시간 벗어나지 않도록 원래 모드로 되돌리세요.

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

위 예시는 기본 매칭 순서를 보여 줍니다. 특정 도메인 규칙을 먼저 배치하고, 지역 IP 규칙을 그다음에 두며, MATCH는 앞에서 일치하지 않은 연결을 마지막에 처리합니다. 광범위한 직접 연결 규칙을 특정 프록시 규칙보다 앞에 두면 뒤의 규칙은 실행되지 않습니다. 원격 규칙 세트를 사용할 때는 규칙 세트가 다운로드되고 정상적으로 파싱되었는지도 확인하세요.

정책 그룹 이름도 일치해야 합니다. 규칙이 가리키는 그룹이 실제로 존재해야 하며, 그룹 안에는 현재 사용 가능한 노드나 다른 유효한 정책 그룹이 포함되어야 합니다. 자동 선택 그룹은 주기적인 테스트 결과에 따라 노드를 고르지만 테스트 주소에 접근할 수 없으면 잘못 판단할 수 있습니다. 문제를 점검할 때는 자동 정책의 변동을 배제하도록 실제 접속으로 확인된 노드를 수동 선택하세요.

6. DNS 확인, fake-ip, 암호화 DNS 점검하기

DNS 문제는 노드 테스트에는 결과가 나오지만 도메인 접속이 계속 대기하는 형태로 나타나는 경우가 많습니다. 브라우저에 이름 확인 오류가 표시되지만 IP 주소로는 연결되는 경우도 있습니다. Clash의 DNS 모듈은 조회를 가로채 설정에 따라 실제 IP 또는 fake-ip를 반환할 수 있습니다. 시스템 DNS, 브라우저 보안 DNS, 클라이언트 DNS를 동시에 사용하면 조회 경로가 갈라지기 쉬우므로 요청을 실제로 어느 구성 요소가 처리하는지 먼저 확인해야 합니다.

DNS 점검 핵심 항목

  1. 로그에 DNS 조회 시간 초과, 존재하지 않는 이름, 업스트림 서버 접근 불가 메시지가 나타나는지 확인하세요.
  2. 브라우저의 독립적인 보안 DNS를 잠시 끄고 브라우저가 시스템 프록시와 시스템 DNS를 따르도록 해 추가 경로를 줄이세요.
  3. 설정의 nameserver에 지정된 서버가 현재 네트워크에서 접근 가능한지 확인하세요. 암호화 DNS의 도메인 자체에도 사용할 수 있는 부트스트랩 확인 경로가 필요합니다.
  4. fake-ip를 사용한다면 대상 앱의 호환성을 확인하고, 로컬 네트워크 기기·시스템 서비스·실제 IP가 필요한 도메인이 올바르게 처리되는지 확인하세요.
  5. 운영체제와 브라우저의 DNS 캐시를 삭제한 뒤 다시 테스트해 이전 기록이 설정 변경을 가리지 않도록 하세요.
dns:
  enable: true
  enhanced-mode: fake-ip
  ipv6: false
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

이 설정 예시는 필드 간 관계를 설명하기 위한 것이며 모든 네트워크에 그대로 적용해서는 안 됩니다. 일부 네트워크에서는 예시 업스트림에 안정적으로 접근할 수 없고, 기업 네트워크에서는 내부 도메인 확인을 위해 내부 DNS를 사용해야 할 수도 있습니다. 실제 설정은 현재 네트워크에서 접근 가능하고 사용 환경에 맞는 서버를 선택해야 합니다. IPv6를 끈 뒤 접속이 복구되었다면 모든 노드 문제를 DNS 탓으로 돌리기보다 IPv6 경로를 계속 점검해야 합니다.

fake-ip 모드는 예약된 주소 풀에서 매핑 주소를 반환한 뒤 코어가 도메인을 복원하고 규칙을 적용합니다. 로컬 네트워크 검색, 하드코딩된 DNS, 특수한 네트워크 감지에 의존하는 일부 프로그램은 필터 범위에 추가해야 할 수 있습니다. redir-host 모드는 실제 확인 결과를 반환하므로 호환 경로가 다르지만 업스트림 확인 품질에 더 크게 의존합니다. 향상된 모드로 전환하면 캐시와 연결 상태가 바뀌므로 테스트할 때 코어를 다시 시작하고 연결을 새로 시도하세요.

7. 시스템 프록시, 수신 포트, 방화벽 확인하기

브라우저는 보통 시스템 프록시를 읽지만 일부 앱은 자체 HTTP 또는 SOCKS 설정만 지원하고, 시스템 프록시를 전혀 읽지 않는 프로그램도 있습니다. 먼저 클라이언트에 표시된 수신 포트와 운영체제의 프록시 설정이 일치하는지 확인하세요. 예를 들어 클라이언트가 mixed 포트를 수신 중이라면 시스템 프록시가 이전 설정의 포트를 계속 가리켜서는 안 됩니다.

다른 프로세스가 포트를 사용 중이면 코어가 시작되지 않거나 다른 포트로 전환될 수 있습니다. 로그에 주소가 이미 사용 중이라는 메시지가 나타나면 해당 프로그램을 종료하거나 수신 포트를 변경한 뒤 시스템 프록시도 함께 업데이트하세요. 시스템 프록시를 가로채는 Clash 클라이언트를 두 개 동시에 실행하지 마세요. 서로 프록시 주소와 우회 목록을 반복해서 덮어쓸 수 있습니다.

시스템 방화벽이나 엔드포인트 보안 정책이 새 코어의 네트워크 접근, 로컬 포트 수신, TUN 가상 인터페이스 사용을 차단할 수 있습니다. 클라이언트를 업데이트하면 코어 실행 파일 경로가 바뀌어 기존 허용 규칙이 더 이상 적용되지 않을 수 있습니다. 시스템 보안 설정에서 현재 프로그램 경로와 네트워크 권한을 확인하고, 로그의 차단 시간이 테스트 시간과 일치하는지도 확인하세요.

8. TUN 모드를 켠 뒤 인터넷에 연결할 수 없을 때

TUN 모드는 가상 네트워크 인터페이스를 통해 더 많은 시스템 트래픽을 가로채며, 시스템 프록시를 읽지 않는 앱이나 투명한 전달이 필요한 환경에 적합합니다. 시스템 프록시보다 경로, DNS, 권한 변수가 많으므로 일반 시스템 프록시가 정상적으로 작동한 뒤 활성화해야 합니다. 시스템 프록시 모드에서도 연결되지 않는 상태에서 TUN을 바로 켜면 점검 계층만 늘어나는 경우가 많습니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

mihomo의 일반적인 TUN 설정에는 자동 경로와 출력 인터페이스 감지가 포함되지만, 지원되는 필드는 코어 버전과 클라이언트 구현에 따라 다릅니다. 활성화한 뒤 가상 인터페이스가 정상적으로 생성되었는지, 기본 경로가 만들어졌는지, 출력 인터페이스가 올바르게 인식되었는지 확인하세요. Windows에서는 해당 권한이 필요할 수 있고, macOS에서는 네트워크 확장 승인 과정이 필요할 수 있으며, Linux에서는 TUN 장치·Capability 권한·정책 라우팅을 확인해야 합니다.

활성화 직후 인터넷이 끊기면 먼저 TUN을 꺼서 기본 네트워크를 복구한 다음 다른 VPN과 가상 네트워크 어댑터 프로그램을 종료하세요. 코어를 다시 시작하고 네트워크를 가로채는 도구는 하나만 활성화하세요. 기기 절전, 네트워크 전환, 전화 접속 재연결 후 문제가 발생했다면 TUN이나 코어를 다시 시작해 현재 인터페이스를 기준으로 경로를 다시 생성하세요.

로컬 네트워크 우회 범위도 확인해야 합니다. 프린터, 라우터 관리 페이지, 로컬 서비스는 보통 직접 연결이 필요합니다. 잘못 가로채면 ‘네트워크가 모두 고장 난 것’처럼 보이지만 실제로는 사설 주소가 프록시로 전달된 것일 수 있습니다. 반대로 우회 범위가 지나치게 넓으면 대상 앱이 프록시를 완전히 건너뛸 수 있습니다. 앱 화면만 보고 추측하지 말고 연결 로그로 트래픽이 코어에 진입했는지 확인하세요.

9. 변수를 최소화해 최종 검증하기

계층별 점검을 마친 뒤 최소한의 테스트 조합으로 확인하세요. 정상적으로 로드되는 설정 하나, 수동으로 선택한 노드 하나, 명확한 프록시 모드 하나, 안정적인 대상 사이트 하나, 하나의 네트워크 진입점을 사용합니다. 먼저 브라우저를 검증한 뒤 TUN이 필요한 앱을 확인하세요. 매번 변수 하나만 변경하고 변경 전후 결과를 기록하세요.

  1. TUN을 끄고 시스템 프록시만 활성화한 뒤 브라우저 요청이 연결 로그에 나타나는지 확인하세요.
  2. 이미 사용 가능하다고 확인된 노드를 수동으로 선택해 테스트 중 자동 정책 그룹이 전환되지 않도록 하세요.
  3. 규칙 모드와 전역 모드를 각각 테스트해 규칙 적용 문제인지 판단하세요.
  4. 실패한 요청의 도메인, 대상 주소, 적용된 규칙, 정책 그룹, 아웃바운드 노드, 오류 발생 시간을 확인하세요.
  5. 다른 네트워크로 전환해 동일한 테스트를 반복하고 문제가 현재 가정용 인터넷이나 로컬 네트워크와 관련 있는지 판단하세요.
  6. 기본 프록시가 안정적으로 작동한 뒤 TUN을 켜고 가상 인터페이스, 경로, DNS가 예상대로 변경되었는지 확인하세요.

문제 정보를 제출해야 한다면 운영체제 버전, 클라이언트 버전, mihomo 또는 다른 코어 버전, 설정 출처 유형, 네트워크 환경, 재현 단계, 민감 정보를 삭제한 로그 일부를 포함하세요. 로그에는 오류 전후의 맥락을 남기되 구독 주소, 인증 정보, 노드 자격 증명은 제거해야 합니다. ‘노드 시간 초과’라는 네 단어만으로는 보통 문제 계층을 판단하기에 부족합니다.

전체 점검 순서는 다음과 같이 정리할 수 있습니다. 직접 연결 네트워크 확인 → 코어 시작 상태 → 구독 및 설정 로드 → 노드 프로토콜 매개변수 → 정책 그룹과 규칙 적용 → DNS 조회 경로 → 시스템 프록시와 포트 → 방화벽과 권한 → TUN 경로. 연결 경로를 따라 진행하는 편이 클라이언트를 계속 재설치하거나 설정을 무작위로 바꾸는 것보다 재현 가능한 결론을 얻기 쉽습니다.

Clash 다운로드