이 글의 목차
지연 시간이 Timeout으로 표시되면 탐지 요청이 제시간에 돌아오지 않았다는 뜻일 뿐입니다
Clash의 지연 시간 버튼은 설정에 지정된 시험 주소에 접속해 정해진 시간 안에 결과를 기다립니다. Timeout은 노드 접근 불가, 시험 URL 차단, DNS 실패 또는 현재 네트워크 차단 때문에 발생할 수 있습니다. 이 결과만으로 컴퓨터 전체의 인터넷이 끊겼다고 볼 수 없고 영상, 다운로드, UDP의 실제 동작을 곧바로 나타내지도 않습니다.
반대로 지연 시간이 수십 밀리초여도 장기 연결이 안정적이라는 보장은 없습니다. 노드를 진단할 때 "상태 검사 결과"와 "실제 작업 요청"을 따로 기록해야 보기 좋은 숫자에 잘못 이끌리지 않습니다.
두 시험이 답하는 질문
| 시험 | 확인할 수 있는 내용 |
|---|---|
| 노드 지연 시간 / health check | 시험 URL이 제한 시간 안에 응답하는지 |
| 브라우저에서 대상 웹사이트 열기 | 웹 요청이 예상 규칙에 따라 선택한 출구에서 완료되는지 |
| 긴 다운로드 또는 스트리밍 응답 | 연결 지속성, 패킷 손실, 중간 전환 |
| 게임 또는 음성 통화 | UDP 지원, 지터, 실제 회선 품질 |
자동 선택을 끄고 노드를 수동으로 바꿔 한 번 비교하세요
주 정책 그룹에서 구체적인 노드 하나를 선택하고 url-test, fallback 또는 load-balance를 사용하지 마세요. 모드는 Rule로 유지하고 Connections를 연 뒤 같은 웹페이지 또는 앱 동작을 반복합니다. 출구를 고정해야 성공과 실패가 같은 경로에서 발생합니다.
대상 도메인, 일치한 규칙, 노드 이름, 로그 오류를 기록하세요. 연결 페이지에 요청이 없다면 앱이 Clash를 거치지 않은 것입니다. DIRECT로 표시되면 규칙이 해당 노드를 사용하지 않은 것이며 요청이 노드로 전달되었음을 확인한 뒤에도 시간 초과가 날 때 노드 연결을 검사합니다.
유효한 재시험에서 보관할 정보
- 고정 노드 이름과 프로토콜 유형
- 같은 대상 주소 또는 앱 동작
- Connections의 규칙과 출구
- 로그의 timeout, reset 또는 DNS 오류
노드 하나만 실패하면 노드를 바꾸고 모두 실패하면 구독 상태부터 확인하세요
- 노드 하나만 시간 초과됨
- 단일 노드 중단, 혼잡 또는 서버 포트 변경일 가능성이 큽니다. 같은 지역의 다른 노드로 비교하세요.
- 같은 프로토콜의 모든 노드가 시간 초과됨
- 현재 커널이 설정 필드를 지원하는지와 로컬 네트워크가 해당 프로토콜을 제한하는지 확인하세요.
- 같은 구독의 모든 노드가 시간 초과됨
- 구독 만료, 트래픽 소진, 서비스 공지를 먼저 확인한 뒤 속도 측정을 계속할지 결정하세요.
- 현재 Wi-Fi에서 여러 구독이 모두 실패함
- 휴대전화 핫스폿으로 비교하세요. 문제 범위가 로컬 네트워크, DNS 또는 방화벽에 가깝습니다.
- 웹페이지는 되지만 게임 또는 음성 통화는 실패함
- UDP와 TUN 제어는 따로 검증해야 하며 웹 지연 시간으로 대신할 수 없습니다.
범위를 확인한 뒤 설정을 바꾸세요. 노드 하나만 고장 났는데 DNS와 TUN을 조정하면 오히려 새 문제가 생깁니다. 같은 네트워크에서 모든 구독이 실패한다면 새 노드를 계속 구매해도 원인을 밝히기 어렵습니다.
timeout, refused, reset, DNS error를 같은 방식으로 처리하지 마세요
i/o timeout / context deadline exceeded
제한 시간 안에 경로가 완료되지 않았습니다. 노드, 네트워크, 대상 주소를 비교하세요.
TLS handshake timeout / handshake failed
연결이 핸드셰이크 단계에 도달했지만 완료되지 않았습니다. 노드 프로토콜, 시스템 시각, 커널 호환성, 현재 네트워크를 확인하세요.
connection refused
대상 호스트에는 도달했지만 포트가 거부되었습니다. 노드 서비스 또는 포트 설정이 바뀌었을 수 있습니다.
connection reset by peer
연결 후 상대 또는 중간 장비가 연결을 재설정했습니다. 프로토콜 호환성과 네트워크 안정성을 확인하세요.
no such host / DNS error
도메인 이름 해석이 완료되지 않았습니다. Clash DNS와 시스템 DNS 경로를 확인하세요.
unsupported / parse error
설정과 커널 기능이 일치하지 않으며 네트워크 지연 문제가 아닙니다.
로그 시각은 방금 실행한 시험 동작과 맞아야 합니다. 백그라운드 구독 업데이트, 상태 검사, 브라우저 요청이 로그를 동시에 기록할 수 있어 마지막 행만 캡처하면 다른 대상을 고르기 쉽습니다.
핫스폿으로 한 번 바꿔 현재 네트워크와 노드 중 어디의 문제인지 판단하세요
같은 고정 노드에서 같은 대상을 가정용 Wi-Fi와 휴대전화 핫스폿으로 각각 한 번 요청하세요. 핫스폿은 성공하고 Wi-Fi는 실패한다면 노드 자체는 작동하므로 라우터 DNS, 방화벽, IPv6 또는 통신사 경로를 확인해야 합니다. 둘 다 실패하면 같은 구독의 다른 노드로 바꾸세요. 저녁 혼잡 시간에만 명확히 느려지고 낮에는 복원된다면 시험 시각과 지속 속도를 기록하세요. 설정 오류보다는 회선 혼잡에 가깝습니다.
같은 프로토콜 그룹 전체가 실패하고 다른 프로토콜은 정상이라면 프로토콜 유형과 커널 버전을 기록해 구독 제공자에게 설정을 확인하세요. Reality, XTLS Vision 같은 전송 또는 flow 이름만으로 노드 품질을 판단하지 말고 같은 환경에서 얻은 비교 결과를 사용해야 합니다.
변수를 최소화한 네 번의 비교
노드 A + Wi-Fi
고정 대상을 반복하고 로그를 남깁니다.
노드 A + 휴대전화 핫스폿
접속 네트워크만 바꿉니다.
노드 B + 기존 Wi-Fi
노드만 바꾸고 가능하면 같은 프로토콜을 유지합니다.
다른 프로토콜 노드 + 기존 Wi-Fi
앞선 비교로도 구분할 수 없을 때만 사용합니다.
자주 끊겼다가 복원되면 정책 그룹이 출구를 바꾸는지 확인하세요
url-test는 탐지 결과에서 지연 시간이 낮은 노드를 선택하고 fallback은 현재 노드를 사용할 수 없을 때 순서대로 전환합니다. 탐지 간격이 너무 짧거나 tolerance가 작거나 시험 URL이 불안정하면 출구가 자주 바뀌어 로그인 세션, 다운로드, 스트리밍 연결이 중단될 수 있습니다.
정책 그룹을 임시로 select로 바꾸고 노드 하나를 고정하세요. 연결 끊김이 사라진다면 노드 자체가 아니라 상태 검사 매개변수 또는 자동 전환 방식의 문제일 수 있습니다. 자동 그룹을 복원할 때는 안정적인 시험 URL을 사용하고 interval을 적절히 늘리며 url-test에 tolerance를 설정하세요.
proxy-groups:
- name: 自动选择
type: url-test
include-all: true
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 80
lazy: true원래 작업으로 돌아가 시간 초과가 실제로 사라졌는지 확인하세요
웹 문제는 로그인과 페이지 로드까지 완료하고 다운로드 문제는 일정 시간 동안 전송을 관찰하며 음성 통화나 게임은 UDP와 세션 안정성을 확인하세요. Connections에 예상 규칙과 고정 출구가 계속 표시되고 로그에서 같은 오류가 더 이상 나타나지 않아야 합니다.
특정 시험 URL이 정상 색상으로 바뀐 것만 확인했고 원래 상황은 계속 시간 초과된다면 진단이 끝나지 않았습니다. 노드, 네트워크, 시각, 오류의 네 정보를 구독 제공자에게 전달해야 회선 또는 서버 문제를 찾을 수 있습니다.