XTLS/Xray-core · error

read bytes: invalid size: %d

Error message

read bytes: invalid size: %d

What it means

After reading the Varint length of a Bytes field, the reader requires 0 <= length < 1024. This error fires when the decoded length is negative or >= 1024, which cannot be a legitimate field size in this protocol and almost always means the stream is corrupted or desynchronized — the reader is interpreting payload bytes as a length prefix.

Source

Thrown at transport/internet/finalmask/xmc/protocol.go:320

func (v *UUID) writeTo(w io.Writer) error {
	_, err := w.Write(v[:])
	if err != nil {
		return fmt.Errorf("write UUID: %w", err)
	}
	return nil
}

type Bytes []byte

func (v *Bytes) readFrom(r io.Reader) error {
	var length Varint
	err := length.readFrom(r)
	if err != nil {
		return fmt.Errorf("read bytes: %w", err)
	}

	if length < 0 || length >= 1024 {
		return fmt.Errorf("read bytes: invalid size: %d", length)
	}

	buf := make([]byte, length)

	_, err = io.ReadFull(r, buf)
	if err != nil {
		return fmt.Errorf("read bytes: %w", err)
	}

	*v = append([]byte(*v), buf...)

	return nil
}

type RestBytes []byte

func (v *RestBytes) readFrom(r io.Reader) error {
	buf, err := io.ReadAll(r)

View on GitHub (pinned to 7d214f8b09)

Solutions

  1. Verify both endpoints use the same protocol version and padding preset.
  2. Confirm the address actually serves this Minecraft-based protocol (not a status/legacy endpoint).
  3. Audit recent changes to packet struct field order or optional-field conditions.
  4. Treat persistent occurrence as a hard failure: the stream cannot be resynchronized; drop the connection.
Defensive patterns

Strategy: validation

Validate before calling

if err := bytesField.readFrom(r); err != nil { /* ... */ }
// pre-empt: only route connections you know speak this protocol;
// verify first bytes look like a valid handshake before enabling the codec

Try / catch

if err := bytesField.readFrom(r); err != nil {
    if strings.Contains(err.Error(), "invalid size") {
        return fmt.Errorf("stream desync or wrong endpoint: %w", err)
    }
    return err
}

Prevention

When it happens

Trigger: Any prior read consuming the wrong number of bytes (mismatched field order, wrong packet ID dispatch, padding schedule mismatch) so this reader starts mid-payload; or a malicious/garbage endpoint sending an out-of-range varint.

Common situations: Client and server built from different protocol versions (field order changed); pointing the transport at a plain TCP service that sends arbitrary bytes; a proxy mangling the byte stream; fuzzing input reaching the decoder.

Related errors


AI-assisted analysis of XTLS/Xray-core@7d214f8b09 (2026-08-15). Data as JSON: /api/errors/dac86316a37709da. Report an issue: GitHub.