Clash 노드 타임아웃 연결 불가: 순서대로 점검하는 7단계

노드 목록의 지연 시간이 timeout으로 표시되거나, 연결할 때 '프록시 서버에 연결할 수 없습니다'라는 메시지가 뜨거나, 브라우저가 계속 로딩만 돌다가 페이지를 열지 못하는 경우—사용자 입장에서는 이 세 가지를 모두 '노드 타임아웃'이라고 부르지만 원인은 전혀 다릅니다. 대부분은 노드를 하나씩 바꿔가며 시도하지만, 수십 개를 바꿔도 여전히 timeout이라면 문제는 노드에 있지 않습니다.

아래 일곱 단계는 '클라이언트 내부에서 외부 회선 순서'로 배열했습니다. 각 단계마다 바로 실행할 수 있는 확인 동작과 판단 기준을 제시합니다. 건너뛰지 말고 순서대로 진행하세요. 앞 단계의 결과에 따라 다음 단계를 실행할지가 결정됩니다.

먼저 네 가지 타임아웃 유형을 구분한 뒤 점검 시작

시작하기 전에 유형을 한 번 나눠 보세요. 같은 timeout이라도 어느 단계에서 발생했는지에 따라 범위를 미리 좁힐 수 있습니다.

증상	가능성 높은 원인	우선 점검 단계
모든 노드의 지연 시간 테스트가 timeout	구독 만료, DNS 해석 실패, 로컬 포트 충돌	1단계 → 2단계 → 3단계
특정 노드만 timeout	해당 노드가 내려갔거나 일시적으로 사용 불가	1단계
지연 시간은 표시되는데 브라우저에서 페이지가 열리지 않음	시스템 프록시 미적용, 규칙이 REJECT로 매칭	4단계 → 5단계
특정 앱만 timeout, 다른 앱은 정상	해당 앱이 시스템 프록시를 사용하지 않음, 분할 규칙 미적용	4단계 → 5단계

판단 기준은 간단합니다. 지연 시간 테스트는 커널 자체의 프로브 경로를 사용하고, 브라우저는 시스템 프록시나 TUN 어댑터를 사용합니다. 전자가 실패하면 커널에서 노드까지 구간에 문제가 있고, 전자는 정상인데 후자가 실패하면 트래픽 처리나 규칙 분할에 문제가 있습니다.

1단계: 구독 갱신과 노드 정보가 최신인지 확인

구독 링크에는 유효 기간과 트래픽 한도가 있습니다. 만료되면 클라이언트가 오류를 띄우지 않고 노드 목록의 지연 시간이 전부 timeout으로 바뀌는 경우가 많습니다. 그래서 첫 단계는 항상 노드 교체가 아니라 구독을 수동으로 갱신하는 것입니다.

구체적인 작업 순서

클라이언트의 '구독' 또는 '프로필' 페이지에서 현재 사용 중인 프로필을 찾아 '업데이트'를 실행하세요. '다시 불러오기'만 누르면 안 됩니다. 다시 불러오기는 로컬의 예전 파일을 읽을 뿐이라 노드 정보가 바뀌지 않습니다.
업데이트 후 노드 수가 0이 되지 않았는지, 목록에 노드 이름과 지연 시간 열이 제대로 보이는지 확인하세요.
생성된 설정 파일을 열어 proxies 섹션의 노드 server 필드가 여전히 유효한 도메인이나 IP인지 확인하세요. 사업자가 노드 도메인을 바꾸면 예전 설정은 통째로 무효가 됩니다.

명령어 한 줄로 구독 링크 확인

curl -sI -o /dev/null -w '%{http_code}\n' "구독 링크"

200이 반환되면 주소에 접근할 수 있다는 뜻입니다. 403, 404, 410은 구독 주소가 만료되었거나 다시 발급받아야 한다는 뜻이고, 200인데 설정 내용이 비어 있다면 보통 트래픽 소진입니다.

구독을 받아올 수 있다고 노드가 쓸 수 있는 건 아닙니다

일부 사업자는 트래픽이 소진된 뒤에도 기본 필드만 담긴 설정 파일을 반환합니다. 클라이언트는 정상적으로 로드되고 노드도 표시되지만 연결은 전부 타임아웃됩니다. 이 경우 사업자 관리 페이지에서 남은 트래픽과 만료일을 반드시 확인해야 합니다.

2단계: DNS 해석과 노드 도메인

노드 도메인 해석 실패는 timeout의 흔한 원인이면서 '노드가 죽었다'고 오해하기 쉬운 항목입니다. Clash 커널은 자체 dns 섹션으로 노드 도메인을 해석하며, 시스템 DNS와는 별개의 설정입니다. 시스템 DNS를 바꿔도 커널에 반영되지 않을 수 있습니다.

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  proxy-server-nameserver:      # mihomo 전용: 노드 도메인 해석 시 사용
    - https://1.1.1.1/dns-query

proxy-server-nameserver는 mihomo(Clash Meta)에서 추가된 필드로, '노드 도메인 해석' 작업만 신뢰할 수 있는 DNS에 맡겨 중국 본토 DNS가 오염된 IP를 반환해 TCP 핸드셰이크 단계에서 타임아웃되는 상황을 막습니다. 원본 Clash 커널에는 이 필드가 없어서 nameserver-policy로 노드 도메인마다 서버를 지정해야 합니다.

확인 방법

nslookup 노드 도메인과 nslookup 노드 도메인 1.1.1.1을 실행해 두 결과 차이가 크면 DNS 오염이 있는 것입니다.
커널 로그에 [DNS] resolve xxx failed가 나타나거나 같은 도메인을 반복 재시도한다면 해석 문제로 확정할 수 있습니다.
fake-ip 모드를 사용할 때 연결 목록의 대상 주소가 198.18.x.x로 표시되는 것은 정상이며 오류가 아닙니다.

3단계: 포트 점유와 로컬 리스닝

커널은 기본적으로 7890(mixed-port, HTTP와 SOCKS 혼합), 7892(redir-port), 7893(tproxy-port)을 리스닝하고, 제어 인터페이스는 기본 127.0.0.1:9090을 사용합니다. 포트 중 하나라도 점유되어 있으면 커널이 아예 시작되지 않거나 일부만 시작될 수 있는데, 일부 클라이언트 화면에는 여전히 '실행 중'으로 표시됩니다.

포트 점유 확인 명령어

Windows: netstat -ano | findstr :7890로 PID를 확인한 뒤 작업 관리자에서 어떤 프로세스인지 확인합니다.
macOS：lsof -i :7890
Linux：ss -lntp | grep 7890

두 가지 처리 방법

점유 중인 프로세스를 종료한 뒤 커널을 재시작합니다. 흔한 점유 주체는 이전에 완전히 종료되지 않은 커널 프로세스, 다른 프록시 프로그램, 로컬 포트를 리스닝하는 개발 도구입니다.
설정의 mixed-port를 변경하고(예: 7897), 시스템 프록시, 브라우저 확장 프로그램, 명령줄 도구의 프록시 포트도 함께 바꿉니다.

설정만 바꾸고 시스템 프록시를 바꾸지 않으면 복합 장애가 생깁니다

커널은 실제로 7897을 리스닝하는데 시스템 프록시는 여전히 7890을 가리키면 '노드 지연 시간 테스트는 정상인데 브라우저는 전부 타임아웃'되는 증상이 나타납니다. 노드 문제처럼 보이지만 실제로는 포트 불일치입니다.

4단계: 시스템 프록시와 TUN이 실제로 트래픽을 처리하는지

커널이 실행 중이라고 해서 트래픽이 처리되는 것은 아닙니다. 시스템 프록시와 TUN은 서로 다른 처리 방식이므로 점검 전에 현재 어느 방식을 쓰는지 먼저 확인하세요.

시스템 프록시 확인 위치

Windows: '설정' → '네트워크 및 인터넷' → '프록시'에서 '프록시 서버 사용'이 켜져 있고 주소가 127.0.0.1, 포트가 설정의 mixed-port와 같은지 확인합니다.
macOS: '시스템 설정' → '네트워크' → 현재 네트워크 서비스 → '세부사항' → '프록시'에서 HTTP와 HTTPS 두 항목이 모두 체크되어 있고 같은 포트를 가리키는지 확인합니다.
Linux: GNOME은 '설정' → '네트워크' → '네트워크 프록시'에서 확인합니다. 터미널의 명령줄 도구는 http_proxy 환경 변수를 따로 설정해야 합니다.

TUN 모드 확인 위치

TUN은 관리자 또는 root 권한이 필요하며, 대부분의 클라이언트는 시스템 서비스를 설치하는 방식으로 처리합니다(Clash Verge Rev의 '서비스 모드', Clash for Windows의 Service Mode). 활성화한 뒤에는 라우팅 테이블에서 확인할 수 있습니다.

Linux / macOS: ip route에서 TUN 어댑터와 198.18.0.0/16 라우팅 항목이 보여야 합니다.
Windows: route print에 TUN 어댑터에 해당하는 경로가 나타나야 합니다.

명령어 한 줄로 전체 경로 연결 여부 확인

curl -x http://127.0.0.1:7890 -o /dev/null -s -w '%{http_code} %{time_total}s\n' https://www.gstatic.com/generate_204

204가 반환되고 수백 밀리초 안에 끝나면 커널, 노드, 규칙 경로는 정상이며 문제는 시스템 프록시 설정이나 특정 앱에 있습니다.
000이 반환되거나 오랫동안 응답이 없으면 커널 쪽에서 이미 실패한 것이므로 1단계로 돌아가 다시 점검하세요.

비교 항목	시스템 프록시	TUN 모드
처리 범위	시스템 프록시 설정을 읽는 앱	모든 TCP / UDP 트래픽
권한 요구 사항	일반 사용자로 가능	관리자 / root 또는 시스템 서비스 설치
DNS 처리	대부분 시스템 DNS 사용	커널 `dns` 섹션에서 일괄 처리
대표적인 문제	앱이 시스템 프록시를 읽지 않음, 포트 불일치	서비스 미설치, 라우팅 미등록

5단계: 규칙 매칭과 분할 결과

규칙은 위에서 아래로 단락 평가되며, 처음 매칭된 규칙이 해당 연결의 경로를 결정합니다. 규칙을 잘못 쓰거나 규칙셋을 갱신하지 않아도 타임아웃으로 나타납니다.

rules:
  - DOMAIN-SUFFIX,example.com,REJECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

흔한 잘못된 작성 방식 세 가지

MATCH를 중간에 배치: 모든 트래픽과 매칭되므로 그 뒤에 있는 규칙은 절대 실행되지 않습니다.
IP-CIDR에 no-resolve 누락: 연결마다 DNS 해석을 먼저 수행하므로 해석이 느리거나 실패하면 전체가 타임아웃으로 나타납니다.
대상 도메인이 REJECT로 처리되거나 DIRECT로 빠지는데, 로컬 직접 연결 자체가 현재 네트워크에서 차단된 경우입니다.

어떤 규칙에 매칭되었는지 확인하는 방법

Dashboard의 '연결' 페이지를 열면 각 연결에 대응하는 '규칙'과 '프록시 체인' 두 열을 볼 수 있습니다. 커널 로그에도 [TCP] 1.2.3.4:443 → match GEOIP,CN => DIRECT 같은 기록이 출력됩니다. 어떤 연결이 REJECT로 매칭되면 브라우저에서는 즉시 오류가 나는 대신 요청이 계속 응답 없이 대기하는 형태로 나타납니다.

6단계: 커널 로그와 지연 시간 측정 방식

로그 레벨은 기본이 info이므로 타임아웃을 점검할 때는 먼저 debug로 올린 뒤 문제를 한 번 재현해 로그가 어느 단계에서 멈추는지 확인하세요.

log-level: debug
external-controller: 127.0.0.1:9090
unified-delay: true
tcp-concurrent: true

unified-delay: true: 지연 시간을 전체 핸드셰이크 소요 시간으로 계산해 실제 체감에 더 가깝고, 어떤 유형의 노드가 타임아웃되는지 파악하기 쉽습니다.
tcp-concurrent: true: 같은 도메인에 여러 IP를 동시에 탐색해 일부 IP에 접근할 수 없어 전체가 타임아웃되는 상황을 피합니다.
external-controller: Dashboard 접속 주소로, 설정해 두면 브라우저에서 로컬 패널을 열어 실시간 로그와 연결 목록을 볼 수 있습니다.

로그에서 봐야 할 네 가지 핵심 줄

로그 예시	의미	돌아갈 단계
`dial tcp 1.2.3.4:443: i/o timeout`	커널에서 노드까지 핸드셰이크 실패	1~3단계
`[DNS] resolve xxx failed`	노드 도메인 해석 실패	2단계
`match GEOIP,CN => DIRECT` 이후 응답 없음	직접 연결로 처리됐지만 네트워크에서 차단됨	5단계
`listen tcp 127.0.0.1:7890: bind: address already in use`	다른 프로세스가 포트 점유	3단계

지연 시간 테스트 주소 통일

테스트 주소를 https://www.gstatic.com/generate_204로 고정하세요. 클라이언트마다 기본 테스트 주소가 달라서, 통일해야 플랫폼 간 지연 시간 값을 비교할 수 있고 여러 기기에서 대조하기도 편합니다.

7단계: 네트워크 환경과 회선 품질

앞의 여섯 단계는 모두 로컬에서 확인하는 항목이고, 마지막 단계는 회선에 관한 것입니다. 판단 방법은 간단합니다. 같은 설정을 휴대폰 핫스팟에서 한 번 테스트해 보세요.

공용 Wi-Fi, 학교 네트워크, 회사 네트워크는 아웃바운드 포트 차단이나 SNI 간섭을 하는 경우가 많습니다. 같은 설정이 핫스팟에서는 정상이고 현재 네트워크에서는 전부 타임아웃이라면 네트워크 측 제한으로 볼 수 있습니다.
시스템 시간 오차: VMess 등 프로토콜은 타임스탬프에 의존하므로 90초 이상 차이가 나면 핸드셰이크가 바로 실패하고 증상은 역시 timeout입니다. Linux / macOS에서는 date -u로 표준 시간과 비교하고, Windows에서는 w32tm /resync로 다시 동기화하세요.
IPv6 우선: 노드 도메인에 A와 AAAA 레코드가 모두 있는데 로컬에서 IPv6에 접근할 수 없으면 일부 클라이언트가 IPv6를 먼저 시도한 뒤 되돌아가면서 첫 패킷 타임아웃이 발생합니다. 설정에 ipv6: false를 추가해 확인할 수 있습니다.
MTU와 공유기: 일부 PPPoE 환경에서는 TUN의 MTU를 9000에서 1500 이하로 낮춰야 합니다. 그렇지 않으면 큰 패킷이 버려져 '웹페이지는 열리는데 동영상과 다운로드가 계속 멈추는' 증상이 나타납니다.

일곱 단계 요약표

순서	단계	확인 방법	판단 기준
1	구독 갱신	`curl -sI "구독 링크"`	200 반환, 노드 수가 0이 아님
2	DNS 해석	`nslookup 노드 도메인 1.1.1.1`	기본 해석 결과와 일치
3	포트 점유	`netstat -ano \| findstr :7890`	해당 포트를 점유한 다른 프로세스가 없음
4	시스템 프록시 / TUN	`curl -x http://127.0.0.1:7890 …`	204 반환
5	규칙 매칭	Dashboard '연결' 페이지	매칭된 규칙과 프록시가 예상과 일치
6	커널 로그	`log-level: debug`	dial timeout과 DNS 실패 기록 없음
7	네트워크 환경	휴대폰 핫스팟에서 재측정	핫스팟에서는 정상으로 복구

점검 중 하지 말아야 할 세 가지

설정을 바꾸면서 동시에 테스트하지 마세요. 한 번에 한 항목만 바꾸고 저장한 뒤 커널을 재시작해 다시 재현해야 어느 항목이 효과가 있었는지 판단할 수 있습니다.
노드 교체로 문제를 해결하려 하지 마세요. 모든 노드가 타임아웃이라면 문제는 클라이언트나 로컬 회선에 있으므로 노드를 바꿔도 결과는 달라지지 않습니다.
구독으로 생성된 설정 파일을 직접 편집하지 마세요. 다음 구독 갱신 때 변경 사항이 덮어써지므로, 사용자 정의 내용은 클라이언트의 확장 설정이나 Merge 오버레이에 작성해야 합니다.

이 일곱 단계를 순서대로 짚어 보면 대부분의 타임아웃 문제는 구독, DNS, 포트, 트래픽 처리 방식, 규칙, 로그, 네트워크 환경 중 한 지점으로 좁혀집니다. 노드를 하나씩 시도하는 것보다 먼저 원인을 찾고 수정하는 편이 훨씬 빠릅니다.