2dust/v2rayN · error · Exception

Received NTP response is too short.

Error message

Received NTP response is too short.

What it means

Thrown when the received datagram (udpReceiveResult) is null or shorter than 11 bytes (4+1+4+2). Despite the 'NTP' wording this guard is tester-agnostic; it asserts any reply is long enough to carry a minimal header. A null/short result means both send/receive attempts failed to yield usable data.

Source

Thrown at v2rayN/ServiceLib.UdpTest/UdpTestService.cs:142

                var currentRoundTripTime = stopwatch.Elapsed;
                if (currentRoundTripTime < roundTripTime)
                {
                    roundTripTime = currentRoundTripTime;
                }
            }
            catch
            {
                if (attempt == 1 && roundTripTime == TimeSpan.MaxValue)
                {
                    throw;
                }
            }
        }

        if ((udpReceiveResult?.Length ?? 0) < 4 + 1 + 4 + 2)
        {
            throw new Exception("Received NTP response is too short.");
        }

        if (udpReceiveResult != null && _udpTest.VerifyAndExtractUdpResponse(udpReceiveResult))
        {
            return roundTripTime;
        }
        else
        {
            throw new Exception("Failed to verify and extract UDP response.");
        }
    }
}

View on GitHub (pinned to e01717d832)

Solutions

  1. Confirm the target host/port is reachable through the proxy (e.g. the default DNS 8.8.8.8:53 must be egress-allowed).
  2. Increase operationTimeout to allow slow UDP replies.
  3. Verify the proxy actually relays UDP to the target (some proxies accept UDP ASSOCIATE but drop outbound UDP).
  4. Try a different tester/target to determine whether the target or the relay path is the problem.
  5. Make the message tester-agnostic (the literal says 'NTP' but applies to DNS/STUN/McBe too) so the cause is not misdiagnosed.

Example fix

// before - misleading 'NTP' label for a generic length check
if ((udpReceiveResult?.Length ?? 0) < 4 + 1 + 4 + 2)
{
    throw new Exception("Received NTP response is too short.");
}

// after - generic, informative message
if ((udpReceiveResult?.Length ?? 0) < 4 + 1 + 4 + 2)
{
    throw new Exception($"UDP relay returned no usable reply (length={udpReceiveResult?.Length ?? 0}); target may be blocked or the proxy does not relay UDP.");
}
Defensive patterns

Strategy: try-catch

Validate before calling

// Pre-check reply presence/length before the strict guard
var len = udpReceiveResult?.Length ?? 0;
if (len < 4 + 1 + 4 + 2)
    throw new Exception($"UDP relay returned no usable reply (length={len}); target blocked or proxy does not relay UDP.");

Type guard

static bool HasMinReplyLength(byte[] reply, int min) => reply != null && reply.Length >= min;

Try / catch

try
{
    await SendUdpRequestAsync(host, port, timeout);
}
catch (Exception ex) when (ex.Message.Contains("too short"))
{
    // both attempts yielded no/short data; target unreachable through proxy
}

Prevention

When it happens

Trigger: After the 2-attempt send/receive loop, udpReceiveResult is null (both attempts threw) or its length is < 11 bytes. The attempt loop only rethrows if attempt==1 AND no successful roundTripTime was recorded, so reaching this check implies attempts failed silently or returned a stub.

Common situations: Proxy accepted the UDP relay but the target never replied (e.g. blocked DNS/ NTP/STUN port); reply was lost over UDP; target server unreachable through the proxy; response arrived but was shorter than expected (truncated relay packet); both attempts timed out.

Related errors

AI-assisted analysis of 2dust/v2rayN@e01717d832 (2026-08-13). Data as JSON: /api/errors/056ecf510f3dc076. Report an issue: GitHub.