{"record":{"id":"6933cacc4918585c","repo":"XTLS/Xray-core","slug":"packet-size-too-large","errorCode":null,"errorMessage":"packet size too large: ","messagePattern":"packet size too large: ","errorType":"exception","errorClass":null,"httpStatus":null,"severity":"error","filePath":"common/mux/reader.go","lineNumber":41,"sourceCode":"\t\treader: reader,\n\t\teof:    false,\n\t\tdest:   dest,\n\t}\n}\n\n// ReadMultiBuffer implements buf.Reader.\nfunc (r *PacketReader) ReadMultiBuffer() (buf.MultiBuffer, error) {\n\tif r.eof {\n\t\treturn nil, io.EOF\n\t}\n\n\tsize, err := serial.ReadUint16(r.reader)\n\tif err != nil {\n\t\treturn nil, err\n\t}\n\n\tif size > buf.Size {\n\t\treturn nil, errors.New(\"packet size too large: \", size)\n\t}\n\n\tb := buf.New()\n\tif _, err := b.ReadFullFrom(r.reader, int32(size)); err != nil {\n\t\tb.Release()\n\t\treturn nil, err\n\t}\n\tr.eof = true\n\tif r.dest != nil && r.dest.Network == net.Network_UDP {\n\t\tb.UDP = r.dest\n\t}\n\treturn buf.MultiBuffer{b}, nil\n}\n\n// NewStreamReader creates a new StreamReader.\nfunc NewStreamReader(reader *buf.BufferedReader) buf.Reader {\n\treturn crypto.NewChunkStreamReaderWithChunkCount(crypto.PlainChunkSizeParser{}, reader, 1)\n}","sourceCodeStart":23,"sourceCodeEnd":59,"githubUrl":"https://github.com/XTLS/Xray-core/blob/7d214f8b094f75322fa3990f8aadad1c912f24f5/common/mux/reader.go#L23-L59","documentation":"PacketReader.ReadMultiBuffer read a uint16 length prefix for a UDP-over-mux packet that exceeds buf.Size (the maximum buffer Xray allocates, a few KB). The peer claims a single packet larger than any legal buffer, so the reader refuses instead of attempting an oversized allocation.","triggerScenarios":"XUDP/packet transfer where the 2-byte size prefix is > buf.Size; typical when a stream is misaligned (reading the middle of a packet as a length prefix), the peer has a bug, or the data is corrupted.","commonSituations":"Mux carrying UDP (XUDP) with stream desynchronization after an earlier parse error, or clients that forward jumbo UDP datagrams without fragmentation.","solutions":["Check the reported size value: near 65535 suggests reading garbage (desync); slightly above 8192 suggests an oversized datagram from the client.","Ensure client-side XUDP writes packets within buf.Size limits (split large payloads at the application layer).","Verify both sides use the same XUDP/mux version; earlier frames may have been misparsed, desynchronizing the length-prefix stream.","Look at preceding log lines for the original parse error that caused the desync and fix that first."],"exampleFix":null,"handlingStrategy":"try-catch","validationCode":"// Client side: before writing a packet into a mux/XUDP stream, check size:\nif len(payload) > int(buf.Size) {\n    return fmt.Errorf(\"packet of %d bytes exceeds mux limit %d; split at application layer\", len(payload), buf.Size)\n}","typeGuard":null,"tryCatchPattern":"mb, err := pr.ReadMultiBuffer()\nif err != nil {\n    if strings.Contains(err.Error(), \"packet size too large\") {\n        // stream is desynced or peer sent junk: tear down, never skip bytes and continue\n        return nil, err\n    }\n}","preventionTips":["Never send single UDP payloads larger than buf.Size over XUDP.","Treat any length-prefix anomaly as fatal for the connection — there is no resync point.","Fix the first parse error in the log; desync usually originates earlier."],"tags":["mux","xudp","udp","protocol","xray"],"backgroundTag":null,"analyzedSha":"7d214f8b094f75322fa3990f8aadad1c912f24f5","analyzedAt":"2026-08-15T14:26:24.325Z","schemaVersion":2},"datasetVersion":"2026-08-15T22:17:37.221Z"}