이 글의 목차
노드를 직접 선택하면 웹페이지가 열리는데 지연 시간 측정은 실패하고 자동 선택에서도 그 노드를 고르지 않을 때가 있습니다. 구독을 다시 가져오기 전에 측정 조건을 확인하세요. Mihomo에는 테스트 대상의 응답이 1밀리초보다 빠르면 성공한 측정값이 0으로 잘리는 특정 문제가 있었습니다.
노드는 쓸 수 있는데 지연 시간 측정은 왜 실패할까요?
공식 PR #3316에는 같은 노드의 측정 기록에 alive: true와 delay: 0이 남으면서 개별 노드 지연 시간 API는 503을 반환하고, 자동 그룹도 이 0을 유효한 측정값이 없는 상태로 취급할 수 있는 현상이 설명되어 있습니다. 주로 같은 호스트, LAN 또는 매우 가까운 에지의 테스트 대상에 해당하며 모든 측정 실패를 뜻하지는 않습니다.
GUI 클라이언트는 코어 오류를 실패나 시간 초과로 통합해 표시할 수 있어 화면에 0ms가 직접 보이지 않을 수도 있습니다. Timeout 하나나 alive: true만으로 이 결함을 확인할 수는 없습니다. 같은 노드, 같은 테스트 URL, 비슷한 시간대의 결과를 함께 확인해야 합니다.
비슷해 보이는 세 가지 상황 구분하기
| 현상 | 확인할 내용 |
|---|---|
| 테스트는 빠르게 끝나지만 이전 코어가 0으로 기록하고 실패도 표시함 | #3316의 시간 처리 조건에 해당하는지 확인하고 지원되는 경로로 수정 버전을 적용하세요. |
| DNS·TLS·연결 오류가 있거나 실제 요청이 timeout을 초과함 | 해당 로그에 따라 점검하세요. 밀리초 미만의 측정 오류 수정으로 모든 시간 초과를 설명할 수는 없습니다. |
| Provider 갱신 후 자동 그룹이 전환되지 않지만 위와 같은 측정 증거는 없음 | 당시 기록을 보관하고 그룹 상태를 별도로 확인하세요. 동일한 문제이며 이미 수정되었다고 판단하지 마세요. |
v1.19.33에서 바뀐 것은 시간 측정 방식입니다
v1.19.33 정식 릴리스에는 #3316이 포함되어 있습니다. 해당 버전의 고정된 소스에서는 URLTest의 정상 반환 경로에서 경과 시간을 정수 밀리초로 변환한 값이 0이면 1로 기록합니다. 유효한 지연 시간이 없음을 나타내는 0과 구분하기 위한 처리입니다. unified-delay가 켜진 경우 두 번째 요청이 성공했을 때의 측정값도 이 공통 처리를 거칩니다.
이 1ms는 측정값의 최솟값입니다. 실제 네트워크 요청이 정확히 1밀리초 걸렸다는 뜻도, 속도 향상을 보장한다는 뜻도 아닙니다. 테스트에는 여전히 연결, HTTP 요청, 설정된 상태 코드 판정이 포함되므로 대상·노드·클라이언트의 실제 조건을 각각 확인해야 합니다.
timeout을 늘리면 대기 시간이 바뀌고 tolerance는 자동 그룹의 전환 허용 차이에 영향을 줍니다. 어느 쪽도 0으로 잘리면서 사라진 유효한 측정값을 복구하지 못합니다. 두 값을 반복해서 바꾸는 방식으로 이 수정의 효과를 확인하지 마세요.
어느 노드와 URL에서 실패했는지 먼저 기록하세요
메뉴 이름은 클라이언트마다 다릅니다. 앱에 있는 코어 정보, 시작 로그, 노드 지연 시간 측정, 연결 기록 기능을 사용하면 됩니다. 확인하려고 external-controller를 켜거나 포트를 외부에 노출하거나 secret을 공유할 필요는 없습니다. 클라이언트 버전으로 실행 중인 Mihomo 버전을 대신 확인할 수도 없습니다.
측정 결과를 실제 연결과 대조하기
실행 중인 코어와 현재 설정 확인
코어 정보나 이번 시작 로그에서 전체 버전을 기록하고 활성 설정, 노드 이름, 테스트 URL을 적어 두세요. 다른 디렉터리에 있는 코어 파일의 버전으로 대신하지 마세요.
개별 노드·자동 그룹·Provider 검사 구분
실제로 적용된 설정의 검사 위치와 url, timeout, interval, expected-status, unified-delay를 확인하세요. 그룹의 url은 해당 proxies에 사용되고, use로 가져온 Provider에는 별도의 상태 검사가 있습니다. 같은 대상을 검사한다고 가정하지 마세요.
같은 조건에서 소수의 테스트 반복
같은 노드를 선택해 클라이언트의 개별 노드 테스트를 실행하고, 실제 요청 하나가 그 노드를 거쳤는지 연결 기록에서 확인하세요. 시간과 오류를 남기세요. 웹페이지가 열리는지와 테스트 요청이 성공하는지는 서로 다른 관찰입니다.
확인할 수 있는 증거만 사용
기존 로컬 진단에서 delay/history를 볼 수 있다면 같은 노드와 URL의 0 기록을 실패 결과와 대조하세요. 볼 수 없다면 화면과 로그를 보관하고 미확인 상태로 남기세요. UI의 Timeout만 보고 밀리초 미만이었다고 추정하지 마세요.
테스트 URL의 응답 상태 코드가 expected-status와 다르거나 로그에 이름 해석·인증서·연결 오류가 나오면 그 원인부터 처리하세요. 1ms 미만의 결과를 만들려고 서버를 구성하거나 테스트를 과도하게 반복하거나 인증서 검증을 끄지 마세요.
수정 버전을 적용하고 실제로 반영됐는지 확인하려면?
현재 설정, 클라이언트 데이터, 복원 가능한 이전 버전을 별도로 백업하세요. 앱에서 코어를 따로 업데이트할 수 있다면 앱이 인정하는 정식 경로로 #3316이 포함된 버전을 선택하세요. 지원하지 않는다면 관리자가 수정 포함을 확인한 정식 클라이언트 패키지를 사용하고 앱 내부 파일을 덮어쓰지 마세요.
업데이트 후에도 테스트 대상을 유지하기
새 코어가 실제로 시작됐는지 확인
v1.19.33에는 수정이 포함된 것이 확인되었습니다. 업데이트 후 클라이언트의 지침에 따라 다시 시작하고 코어 정보나 새 로그를 읽으세요. 앱의 업데이트 성공 알림만 확인하고 끝내지 마세요.
같은 노드와 같은 대상으로 재측정
같은 설정과 테스트 URL을 복원한 뒤 개별 노드 테스트를 먼저 하고 원래 자동 그룹이나 Provider 검사도 관찰하세요. 각 검사 위치끼리 따로 비교해야 하며 서로 다른 대상의 결과를 업데이트 전후 비교에 사용하면 안 됩니다.
실제 사용 중인 요청도 확인
클라이언트 연결 기록이 예상한 노드를 가리키는지 확인한 뒤 이전에 사용할 수 있었던 웹페이지나 앱 요청을 검증하세요. 기존 진단을 볼 수 있다면 유효한 시간이 0으로 기록되어 잘못 실패하는 현상이 사라졌는지 확인하세요. 모든 노드가 1ms로 표시될 필요는 없습니다.
아직 지원되는 수정 패키지가 없다면 노드가 실제로 작동하는지 확인한 후 직접 선택해 임시로 사용할 수 있습니다. 이 방법은 시간 처리를 수정하지 않으며 자동 장애 전환이 복구됐다는 증거도 아닙니다. 확인할 수 없다면 원래 설정을 유지하고 정식 업데이트를 기다리세요. 구독을 삭제하거나 전체 설정을 다시 쓰지 마세요.
어떤 항목까지 확인해야 처리가 끝난 걸까요?
녹색 숫자 하나만 보지 말고 항목별로 확인하세요
- 실행 중인 코어의 전체 버전을 기록하고 업데이트 경로와 실제로 불러온 설정을 확인했습니다.
- 업데이트 전후에 같은 노드와 테스트 URL을 사용했고 각 검사 위치의 상태 코드 조건과 시간 단위를 구분했습니다.
- DNS, TLS 검증, timeout, tolerance, 구독을 동시에 바꾸지 않아 다른 변경을 수정 효과로 오인하지 않았습니다.
- 원래의 개별 노드 측정과 실제 요청을 다시 확인했습니다. 자동 그룹이나 Provider의 상태 검사는 따로 관찰했으며 수동 테스트 한 번으로 전체가 복구됐다고 판단하지 않았습니다.
- 계속 실패하면 구체적인 오류, 시간, 민감 정보를 가린 결과를 보관하고 실제 시간 초과·상태 코드 불일치·Provider 갱신 문제를 구분해 기록했습니다.
이 글은 공식 수정과 해당 버전의 고정된 소스를 바탕으로 시간 처리 조건을 설명합니다. 코어를 다운로드하거나 사용자 환경에서 직접 재현한 결과는 아닙니다. 업데이트 후에도 실패한다면 새로 나타난 구체적인 오류에 따라 점검하세요. v1.19.33이 모든 지연 시간 측정 문제를 해결한다고 볼 수는 없습니다.
업데이트 후 다른 문제가 생기면 어떻게 복원하나요?
영향을 받는 작업을 중단하고 원래 지원되는 업데이트 경로로 저장해 둔 이전 버전을 복원한 다음 그 버전에 대응하는 별도 백업을 복원하세요. 두 버전이 같은 데이터 디렉터리에 동시에 쓰지 않게 하고 유일한 백업을 덮어쓰지 마세요. 복원 후 실제 코어, 설정, 수동 선택, 실제 요청을 확인하세요.
이전 버전으로 돌아가면 시간 처리 결함도 다시 나타날 수 있으므로 사용 가능한 환경을 복원하는 용도로만 보세요. 관리자에게 제보할 때는 OS, 코어 전체 버전, 검사 위치, 민감 정보를 가린 URL, 시간, 구체적인 오류를 첨부하세요. 구독 토큰·제어 키·개인 정보를 제거하고 이슈가 닫혔다는 이유만으로 패키지에 수정이 포함됐다고 판단하지 마세요.