이 글의 목차
노드 옆의 시간 초과 메시지가 눈에 띄어도 실제로 하려는 작업이 실패했다는 뜻은 아닙니다. 웹페이지, 오래 걸리는 다운로드, 음성 연결은 요구 사항이 다르므로 실제 사용 상황에서 확인해야 합니다. 노드 하나와 대상 하나를 고정해 속도 측정 결과, 연결 기록, 로그를 서로 비교하세요.
지연 테스트가 Timeout일 때 실제 접속도 실패할까?
Timeout은 구성에 지정된 테스트 주소가 제한 시간 안에 응답하지 않았다는 뜻입니다. 노드에 접근할 수 없거나 테스트 URL이 차단되거나 DNS가 실패하거나 로컬 네트워크가 접근을 막을 수 있습니다. 이것만으로 컴퓨터 전체가 인터넷에 연결되지 않았다고 판단하거나 영상, 다운로드, UDP 성능을 판단할 수는 없습니다.
같은 노드로 실패했던 사이트를 열거나 앱에서 같은 동작을 실행하고, 실제 결과와 지연 시간 테스트 결과를 기록하세요. 지연 시간이 낮더라도 다운로드가 계속 진행되는지, 긴 응답이 끝까지 완료되는지는 각각 확인해야 합니다.
두 시험이 답하는 질문
| 시험 | 확인할 수 있는 내용 |
|---|---|
| 노드 지연 시간 / health check | 시험 URL이 제한 시간 안에 응답하는지 |
| 브라우저에서 대상 웹사이트 열기 | 웹 요청이 예상 규칙에 따라 선택한 출구에서 완료되는지 |
| 긴 다운로드 또는 스트리밍 응답 | 연결 지속성, 패킷 손실, 중간 전환 |
| 게임 또는 음성 통화 | UDP 지원, 지터, 실제 회선 품질 |
노드를 고정하고 요청이 해당 노드로 전달되는지 확인
주 정책 그룹에서 구체적인 노드 하나를 선택하고 url-test, fallback 또는 load-balance를 사용하지 마세요. 모드는 Rule로 유지하고 Connections를 연 뒤 같은 웹페이지 또는 앱 동작을 반복합니다. 출구를 고정해야 성공과 실패가 같은 경로에서 발생합니다.
대상 도메인, 일치한 규칙, 노드 이름, 프로토콜 유형, 로그 오류를 기록하세요. 연결 화면에 요청이 없으면 앱이 Clash를 거치는지 확인하세요. DIRECT로 표시되면 규칙을 확인하고, 요청이 노드에 전달된 뒤에도 시간 초과가 나면 노드 연결을 확인하세요.
단일 노드, 동일 프로토콜, 전체 구독 장애 처리
- 노드 하나만 시간 초과됨
- 단일 노드 중단, 혼잡 또는 서버 포트 변경일 가능성이 큽니다. 같은 지역의 다른 노드로 비교하세요.
- 같은 프로토콜의 모든 노드가 시간 초과됨
- 현재 커널이 설정 필드를 지원하는지와 로컬 네트워크가 해당 프로토콜을 제한하는지 확인하세요.
- 같은 구독의 모든 노드가 시간 초과됨
- 구독 만료, 트래픽 소진, 서비스 공지를 먼저 확인한 뒤 속도 측정을 계속할지 결정하세요.
- 현재 Wi-Fi에서 여러 구독이 모두 실패함
- 휴대폰 핫스폿으로 바꿔 비교하고 로컬 네트워크, DNS, 방화벽 중 어디서 문제가 생기는지 확인하세요.
- 웹페이지는 되지만 게임 또는 음성 통화는 실패함
- UDP와 TUN 제어는 따로 검증해야 하며 웹 지연 시간으로 대신할 수 없습니다.
노드 하나가 실패했다고 DNS와 TUN을 함께 변경할 필요는 없습니다. 같은 네트워크에서 여러 구독이 실패하면 접속 네트워크를 비교하는 편이 더 유용합니다.
로그에서 시간 초과, 연결 거부, 연결 초기화, 이름 해석 실패 구분
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에서는 실패하면 노드는 작동하므로 라우터 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은 응답하지만 원래 작업은 계속 시간 초과되면 노드, 네트워크, 시간, 오류를 기록해 구독 제공업체가 회선 또는 서버 문제를 찾을 수 있도록 전달하세요.